Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2007-10-11 11:06    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Цели ИТ проекта

   В этом разделе
   Идеальная цель
      Принципы постановки целей
      Specific
      Measurable
      Achievable
      Relevant
      Timed
   Практика целеполагания
      Источник цели, назначение и жизненный цикл ИТ системы
      Идущие вперед
      У семи нянек дитя без глаза
      Обоснование проекта
      Концептуальный документ проекта
   Welcome aboard
      Неисправимый дефект принципа SMART
      Война и мир
   Куда бежать?

В этом разделе  ^

В этом разделе будет рассмотрено целеполагание в ИТ проекте.
- откуда берутся цели ИТ проекта;
- как они ставятся и фиксируются;
- кто за что отвечает в процессе постановки цели;
- какие бывают варианты и отклонения в этом процессе и чем они грозят.
Эти и некоторые другие вопросы будут рассмотрены ниже.

Идеальная цель  ^

Принципы постановки целей  ^

Одни из моих коллег точно знают, как ставить цели ИТ проекта, другие точно знают, что это их не касается. Первые абсолютно правы - вторые счастливы. В этой главе мы рассмотрим, КАК НАДО ставить цели, чтобы в одной из следующих обсудить, почему это невозможно ;)
Основные факты относительно постановки целей крутятся вокруг слова из пяти букв: SMART
-Specific (определенная);
-Measurable (измеримая);
-Achievable (достижимая);
-Relevant (значимая);
-Timed (спалнированная по времени);
Принцип SMART не является новостью или открытием и успешно применяется человечеством столько времени, сколько существует целенаправленная деятельность. Мы же, рассмотрим каждое требование к цели более подробно с точки зрения ИТ проекта.

Specific  ^

Для того, чтобы что-то получить надо представлять, что это такое. И наоборот: если вы слабо представляете, каким будет результат, то результат будет произвольным. Нарушение принципа ведет к одновременно двум вещам: разработчики системы остаются без указаний, что конкретно они должны разработать и как, пользователи системы остаются без нужных им функций.
Так, например, цель "внедрение электронного документооборота" является одинаково бесполезной как для разработчиков, так и для пользователей. Во время постановки этой цели электронный документооборот еще не существует, по этому представить, каким он должен быть, опираясь только на поставленную цель практически невозможно.
Гораздо более полезна в таком случае постановка цели типа: "обеспечение начальству оперативный контроль состояния проекта, путем автоматизации документооборота". Такая постановка содержит указание о пользе для потребителей: оперативный контроль состояния проекта, а так же указание для аналитика, собирающего требования. Очевидно, следующими шагами обследования будет выяснение, что понимается под обзором состояния проекта, из чего получается информация для такого обзора. Скорее всего, информация для контроля будет попадать в систему во время прохождения определенных документов по маршрутам, что и будет являться предметом процессного обследования.
Правильно поставленная цель так же является и контекстом обследования для сбора требований. Так как система служит для достижения целей, то ответить на вопросы: что включать в модель, как декомпозировать и где остановить декомпозицию можно, если все время помнить о поставленных целях. Каждый раз, работая над моделью требований, или архитектурной моделью, или над реализацией системы следует задавать себе один и тот же вопрос: "как это требование или архитектурный элемент или другая часть системы работает на цель проекта или на назначение системы?". Если окажется, что нам не удается связать элемент модели с целью, то или этот элемент лишний (тогда его выкидываем) или цель поставлена недостаточно четко (в этом случае можно уточнить постановку цели).
По этому вопросу, как именно декомпозировать модель, есть одна хорошая идея: первичную декомпозицию удобно делать в соответствии с целями проекта или пунктами назначения системы. Это не догма, но в ходе обследования и архитектурной проработки можно будет четко связать объем работы, с каждой из целей. Это имеет значение, если учесть, что обычно цели имеют разный приоритет. Возможно, чуть позже будет удобно переклассифицировать и перегруппировать полученные элементы модели с точки зрения других соображений - это нормальная ситуация, так как на разных этапах моделирования нам нужны разные вещи.
Ответить на вопрос о глубине детализации модели требований или архитектуры можно, если кроме целей проекта учесть еще и цели моделирования. Для примера приведу один вопрос, вызывающий чуть ли не Holy Wars среди аналитиков: включать ли в модель требований описания интерфейсов или эта проработка должна выполняться позже. В случае с многими подобными вопросами нет однозначного ответа "как правильно", но можно ответить на вопрос "что целесообразно". Чтобы избежать длительных споров и проектного паралича в момент сбора требований, следует четко поставить цель в начале. Целью моделирования, например, может быть "выявить все требования, исходные для формирования логической схемы базы данных" или "получить подробные сценарии работы системы, спецификацию пользовательских функций и модели интерфейсов для утверждения спецификации требований заказчиком". Модель в таком случае находится в перекрестье двух целей: целей проекта и целей этапа (фазы или работы) и мы имеем достаточно информации, чтобы понять, что следует делать и каким должен быть результат.
Из стандартов и методологий, стоящих рядом с созданием ПО, о целях проекта наиболее четко говорится в ГОСТе серии 34 и в методологии создания ПО от Microsoft - MSF. В ГОСТе, описывающем техническое задание (ТЗ) указаны разделы с целями создания и назначением системы, а так же с показателями назначения, которые и служат для фиксации цели проекта. MSF, как методология (в отличие от ГОСТ) говорит о целях гораздо больше. Первым базовым принципом MSF является единое видение проекта. Все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат. Всем должна быть понятна цель проекта. На создание и утверждение концептуального документа, фиксирующего цели, в MSF отводится целая фаза итерации по созданию продукта. Однако, если рассмотреть, подход к выбору цели проекта, описанный в ГОСТ или BABOK, то можно увидеть, что одна фаза итерации на определение цели проекта - это не так уж и много (но об этом мы поговорим немного ниже).

Measurable  ^

Для того, чтобы иметь законченное описание цели следует четко представлять, как проверить, что цель достигнута. Или, другими словами, нельзя требовать то, что невозможно измерить. Опытные разработчики и архитекторы могут поведать нам, что если размытые цели приводят к жарким спорам и проектному параличу над вопросом "что делать", то неизмеримые цели приводят к таким же затруднениям над вопросом "как делать". Споры о выборе технологической платформы (например, использовать ли РСУБД и какую) или длительное "зависание" над вариантом технического решения означает, что у нас не хватает требований, а значит цели плохо измеримы.
В примере с автоматизацией документооборота к формулировке цели "обеспечение начальству обзора состояния проекта, путем автоматизации документооборота" следует добавить критерии достижения. Например, выполнение обзора должно занимать единицы минут (1-19мин), при этом система должна давать ответы на вопросы:
- на каком этапе находится проект (работы каких этапов выполнены полностью, а каких не полностью);
- какие работы незакрытых этапов просрочены (имеют плановую дату завершения раньше сегодняшней, но еще не завершены);
- какие работы незакрытых этапов должны подходить к концу (имеют плановую дату завершения в промежутке между следующим рабочим днем от сегодня и третьим рабочим днем от сегодня);
- какие незаконченные работы незакрытых этапов не начались вовремя;
- должна быть возможность просмотра детализированной информации о интересующих работах: исполнитель, плановые и фактические даты начала-завершения, предшествующие работы, описание существа работ, возможность просмотра связанных с работами документов (исходных, результирующих).
С таким дополнением поставленная цель приобретает объем и четкие критерии достижения. Доказать, что цель достигается, можно, если на некотором тестовом наборе данных показать, как из системы получаются ответы на необходимые вопросы. В приведенной постановке есть только одна проблема. Мы указали, что обзор проекта должен укладываться в диапазон от 1 до 19 минут. Возможно, это не вызвало бы проблем. Однако в жизни реальные наборы данных для подобной задачи могут содержать десятки открытых этапов и тысячи выполняемых работ. В этом случае при требовании заказчика выполнить приемку на материалах реального проекта может оказаться, что операции по обзору проекта не укладываются в минуты. Источник проблемы в том, что мы зафиксировали абсолютную характеристику системы, не указав ограничение - объемы, на которых это должно быть реализовано. Исправить ситуацию можно, имея некоторый опыт разработки и внедрения в конкретной предметной области и представляя типичные объемы и потоки информации при выполнении задач, что позволит задать соответствующие вопросы вовремя. Так, при тысячах и больше анализируемых работ в плане проекта придется разрабатывать специальные формы отчетности, опирающиеся на специальные методы оценки состояния проекта в то время, как при десятках задач в плане (и единицах одновременно выполняющихся) будет достаточно простого сводного отчета с возможностью обращения к дополнительной информации о работах и документах.
Можно видеть, что необходимость измерения результата влечет за собой необходимость измерения задачи, что само по себе уточняет способ ее решения, исключая пробуксовку проекта из-за нехватки требований.
Итак, что должно быть измерено при постановке целей:
- Время и частота получения результатов от системы. Не всегда можно предъявить требования к каждой функции, но это и не нужно. Однако есть разница между получением отчета за 10 секунд и сборкой того же отчета за ночь. Методы реализации системы в первом и втором случае будут отличаться настолько, насколько рогатка отличается от гаубицы. Следовательно, надо четко определить, что важно для достижения целей с точки зрения скорости и зафиксировать эти характеристики.
- Объемы входящей, обрабатываемой и выходной информации, частота взаимодействий с системой. Как уже было показано, связь объемов с быстродействием практически прямая. С частотой взаимодействия связана еще и скорость отклика системы при выполнении важных задач. Например, быстрый автоподбор значений из справочников по первым буквам названия может быть критически важным при больших объемах заносимой информации. Еще пример: занесение трех документов в день может быть выполнено одним способом (примерно так, как работает диалог открытия документа в текстовом редакторе), но если требуется занести несколько тысяч документов в день, отдельной задачей становится обеспечение массовой загрузки и ввода данных. В этом случае важность вопросов:
- откуда берутся тела документов и их атрибуты,
- как по возможности избежать ручного ввода,
- как максимально предотвратить неизбежные ошибки пользователя,
становится такой, что подходы к решению вопросов должны быть зафиксированы на концептуальном уровне.
Время действия и частота применения решения. Есть принципиальная разница между оснасткой для одноразовой миграции данных и учетной системой со сроком эксплуатации в пару десятков лет. Несомненно, во втором случае к системе будут предъявлены повышенные требования, связанные с сопровождаемостью и внесением изменений. Это немножко пересекается со свойством Timed, по этому мы более подробно обсудим вопросы времени чуть ниже.
Другие показатели назначения. Что еще можно измерить кроме времени, объемов и частоты при работе с информацией? Удобство работы, эстетический эффект, соответствие стандартам, современность технического уровня, gameplay (для игр), надежность, безопасность... И любые другие специфические показатели, важные для достижения поставленных целей. Так, например, система, которая служит для выпуска конструкторской документации по российским ГОСТам будет сертифицироваться на соответствие выходных документов соответствующим стандартам, если же это система для расчета металлоконструкций в ходе строительного проектирования, то сертификация будет гораздо более трудоемкой и "жестокой".
Удобство работы и эстетический эффект примерно соответствуют термину из современного мира ИТ - usability. Как измерить usability, похоже, не знает сегодня никто. Точнее, измерение любых тонких характеристик - это предмет исследований (биометрических, маркетинговых, экспертной оценки или специальной сертификации). Для систем учетного и документооборотного класса в качестве одной из важных составляющих usability можно назвать утомляемость пользователей, которая влияет на количество допущенных ошибок. Количество ошибок - это очень шаткая характеристика, которая зависит от конкретного пользователя, но это уже хоть какой-то подход к исследованию.
И последнее, что следует отметить при разговоре об измеримости - это сопоставление с техническим окружением системы. Система не работает в вакууме, обязательно будут предъявлены требования к совместимости с операционными системами, сетевыми протоколами, возможно, по интеграции со смежными системами. Требования к техническому окружению обычно являются наиболее конкретными, а значит, и реализацию их чаще можно измерить без особых проблем. На этапе постановки цели следует указывать только те технические требования, которые являются концептуальными в данном случае: необходимость интеграции с конкретной смежной системой, работа с форматами файлов из унаследованного информационного массива и т.п.

Achievable  ^

В примере с отчетом о состоянии проекта именно мысль о достижимости заставила нас вернуться и описать объемы обрабатываемой информации. Вопрос о достижимости цели при любых поворотах событий - хороший тест на полноту требований. Очень часто бывает так, что различные аварийные и нестандартные ситуации и отклонения оказываются белым пятном при разработке системы. При этом зачастую именно отклонения от формализованных процессов могут составлять большую часть реальных рабочих случаев. Два тестовых вопроса:
- что будет (что должно быть, что делать), если цель не достигается?
- при каких условиях цель не достигается?
помогут серьезно улучшить постановку цели, качество требований, а значит, и качество решения в целом. Поиски ответа на эти вопросы приводят к более четкому формированию ограничений, добавляют важные дополнительные цели и показатели назначения (измерителей цели). В частности, анализ недостижения целей приводит нас к группе требований и показателей назначения, связанных с допустимостью отказа системы, а так же условиями, временем и стоимостью восстановления после отказов и сбоев.
Важно еще и вот что: чем меньше участие в процессе целеполагания исполнителя, тем меньше вероятность достижения цели. В тривиальных случаях заведомо известно, что НЕЧТО легко достижимо. Но даже в таком случае может оказаться, что именно выбранный исполнитель по каким-то причинам не может достигнуть требуемого результата.
Для того, чтобы окончательно убедиться в том, что цель достижима кроме ограничений и согласия исполнителя было бы неплохо получить еще и приблизительный образ решения. На самом деле, чтобы сказать, что эта цель достижима, исполнитель как раз будет выполнять более или менее грубую прикидку структуры решения и плана его реализации. При этом всегда возникает оценка времени и ресурсов, увязанная с требуемым результатом ограничениями и допущениями.

Relevant  ^

Никто не хочет достигать бесполезных целей. Этот факт очевиден для всех. При разработке ПО важно, чтобы функции системы приносили какую-то пользу ее пользователям. В нашем примере с документооборотом польза от ускорения оперативного контроля проектов заключается в повышении качества и своевременности управленческих решений по проекту и очевидна для руководителей. Однако эта же необходимость оперативного контроля вызывает необходимость занесения документов и другой информации в систему рядовыми исполнителями, что для них, в общем случае, является дополнительной нагрузкой. В почти любой системе для групповой работы существует подобный конфликт интересов: кто-то работает больше для обеспечения информацией кого-то другого. Принцип значимости целей для ИТ систем работает на двух уровнях:
- система должна приносить пользу хотя бы одной из заинтересованных сторон,
- баланс интересов всех заинтересованных сторон вокруг системы с учетом дополнительных мотивирующих мер должен быть в пользу разработки или внедрения системы, а не против.
Здесь, скорее, важен не просто баланс, а те действия, которые можно выполнить для изменения баланса в пользу системы: предоставление рядовым пользователям какой-то разгружающей автоматизации, принятие административных мер по мотивации персонала и т.д. Внимание, уделенное интересам в процессе целеполагания, может изменить результирующую цель или включить в постановку цели дополнительные пункты по обеспечению требуемого баланса интересов.
При постановке целей для соблюдения принципа значимости мы должны ответить на вопросы о том, кто является заинтересованными сторонами, каковы их цели, интересы и потребности, связанные с разрабатываемой и внедряемой системой автоматизации. Эта информация также является важной с точки зрения сбора требований, так как источником требований как раз и станут представители заинтересованных сторон.
Последний момент, который хочется рассмотреть в связи с принципом значимости - это двухуровневость решения при внедрении практически любой ИТ системы для нужд бизнеса. Это не так ярко выражено для систем персонального пользования, но практически неизбежно для систем групповой работы. Первый уровень решения - организационный: на уровне регламента фиксируется, что работаем с данной системой, и работаем с системой так, как написано в руководстве пользователя и регламенте, закрепляющем роли пользователей за конкретными сотрудниками. Второй уровень решения - технический, описывающий непосредственно разрабатываемую систему. Естественно, организационное решение вокруг системы призвано решать конкретные задачи бизнеса, а техническое решение призвано поддерживать организационное.
В примере с документооборотом в системе (условно) появляется две роли: работник и начальник. Обязанность работника - заносить в систему данные. Обязанность начальника - контролировать занесение. Сотрудники распределяются по ролям и обязаны работать через систему.
Техническое решение будет состоять (к примеру) из сервера РСУБД и клиентских частей. Для обслуживания сервера и технической поддержки пользователей вводится третья роль: администратор. Можно видеть, что присутствие администратора в организационном решении никак не вытекает из задач бизнеса, но диктуется принятым техническим решением. То есть при проработке концептуального решения, необходимость которой диктует принцип достижимости, мы получаем как цену вопроса, выраженную в различных видах ресурсов, так и дополнительные цели (администрировать систему), ограничения и новые заинтересованные стороны.

Timed  ^

Чуть выше мы уже говорили о факторе времени, теперь осталось добавить несколько слов.
С одной стороны речь идет о том, что слишком сжатые явно нереалистичные сроки лишают проектную команду мотивации, слишком растянутые сроки расслабляют и грозят изменением требований, отсутствие сроков вообще лишает необходимости что-либо сделать.
С другой стороны, интересно отметить, что сроки разработки и внедрения ИТ системы, время до следующей модернизации и до вывода системы из эксплуатации, объединены одним термином: жизненный цикл системы.
Можно сказать, что назначение технического решения - это отработка своего жизненного цикла, поэтому источник всех требований к системе лежит в ее жизненном цикле. Одни из основных параметров жизненного цикла - это время фаз разработки и внедрения, а так же срок эксплуатации.
Требования к срокам разработки и внедрения могут оказать существенное влияние, предопределив выбор (например) в пользу «полукоробочной» настраиваемой системы вместо разрабатываемой. Если покупная система не позволяет достигать многих целей второго и ниже приоритетов, может быть заложено двойное решение: быстрое внедрение первой системы для "закрытия пробоины" с параллельной разработкой полноценной системы и последующей миграцией данных и переходом к ее эксплуатации. Такой план внесет множество специфических требований: с одной стороны какие-то требования к системе могут быть ослаблены (например, по нагрузочной способности), второстепенные потребности могут быть не удовлетворены, но требования, связанные с сопровождаемостью и возможностями миграции данных будут более четкими и вынесутся на концептуальный уровень.
Такое же сильное влияние на цели проекта могут оказать и специфические временные параметры фазы эксплуатации. Одноразовое использование системы позволяет практически не заботиться о сопровождаемости, в то время, как длительный жизненный цикл может предполагать множество модернизаций системы и возникновение соответствующих требований и целей.

Практика целеполагания  ^

Источник цели, назначение и жизненный цикл ИТ системы  ^

Рассмотрев требования к практически полезной постановке целей ИТ проекта, мы переходим к обсуждению источников целей, распределению ответственности и методах фиксации целей.
На происхождение цели ИТ проекта можно предложить как минимум два взаимодополняющих взгляда:
- системное происхождение цели проекта - разрабатываемая система рассматривается, как часть надсистемы, обеспечивающая выполнение функций надсистемы;
- проблемное происхождение цели проекта - разрабатываемая система рассматривается, как средство решения проблем или реализации возможностей заинтересованных сторон.
Первый случай более упорядочен и предполагает точное знание будущего окружения ИТ системы. Обычно первый подход годится для разработки систем управления оборудованием, серверного ПО, конверторов, программ индивидуального пользования. В этом случае на первый план выходит техническое окружение системы и непосредственные требования к функционированию (программные интерфейсы, форматы, требования к быстродействию, надежности и т.п.)
Второй случай исходно несет гораздо меньше определенности, так как технология использования разрабатываемой ИТ системы неизвестна. При разработке системы предстоит разработать как организационный регламент, так и средства, которые его поддерживают. К таким системам относится большинство ИТ систем для групповой работы: учетные, документооборотные, CRM, PLM и т.д.
При использовании любого подхода к определению назначения системы важно понимать, что исчерпывающим источником требований к системе будет ее жизненный цикл (ЖЦ), который в самом распространенном случае состоит из
- создания системы,
- внедрения (ввода в эксплуатацию),
- эксплуатации и
- вывода из эксплуатации.
В зависимости от того, что нам известно о жизненном цикле мы и фиксируем требования к системе. На каждой фазе ЖЦ выявляются люди (заинтересованные стороны), протекающие процессы, и ресурсы, стоящие вокруг ИТ системы и связанные с ней. Каждый из перечисленных компонентов может служить источником требований как концептуальных, так и всех остальных.
Важность охвата всего жизненного цикла при назначении целей проекта можно проиллюстрировать простым примером. Если мы создаем программное обеспечение развлекательного сайта, отдающее страницы и это ставится целью проекта, то после пусконаладки ПО на сервере мы не получим сразу работающий сайт, так как его еще нужно наполнить материалом. После наполнения материалом, возможно, понадобятся действия по раскрутке (привлечению посетителей), так как в общем случае, заказчику нужен посещаемый сайт. В процессе эксплуатации материал, скорее всего, придется обновлять, редактировать и модерировать. В данном случае если целью проекта будет создание ПО для сайта - это нормально, так как наполнение, раскрутка и обслуживание могут быть целями других проектов. но если кроме создания ПО не планировалось больше ничего - это принципиальная ошибка создателей сайта. И с большой вероятностью можно сказать, что если в момент создания ПО сайта никакой достоверной информации о дальнейших фазах ЖЦ не было, то это ПО потребует модификации при первом же столкновении с реальностью эксплуатации.
можно видеть (и это естественно), что источник цели проекта и требований к системе лежит в видении будущего. Кто должен смотреть в будущее, от кого исходит инициатива запуска ИТ проекта: давайте смотреть...

Идущие вперед  ^

можно выделить три наиболее общих заинтересованных стороны вокруг любого проекта:
- заказчик (владелец проекта) - выделяет ресурсы на проект, до старта проекта является лицом, принимающим решение о старте;
- потребитель - будет использовать результаты проекта, является основным источником требований;
- исполнитель - будет выполнять работы в проекте, обеспечивая создание продукта и поддержку его жизненного цикла.
Несмотря на простоту этой классификации, в жизни могут получаться достаточно сложные комбинации. Эту сложность можно показать на примере с созданием сайта. Итак: некоторая Компания создает развлекательный сайт для посещения Аудиторией и продажи рекламных показов Рекламодателям. В данном случае расклад такой:
- Компания: заказчик, потребитель (прибыли, как финансового результата проекта и сервисов по наполнению и управлению сайтом), исполнитель;
- Аудитория: потребитель (развлекательного материала);
- Рекламодатель: потребитель (рекламных показов).
Если увеличить уровень детализации и разделить систему и фазы жизненного цикла, получится следующее:
- создание ПО (исполнитель - отдел разработки, заказчик и потребитель - отдел продаж, потребитель - отдел контента и Аудитория);
- наполнение контентом (исполнитель - отдел контента, заказчик - отдел продаж, потребитель - Аудитория);
- размещение рекламы (исполнитель и потребитель - отдел продаж, заказчик и потребитель - Рекламодатель, потребитель - Аудитория);
- ...
Возможность совмещения ролей, а так же то, что как система с ее жизненным циклом, так и заинтересованные стороны вокруг нее не являются монолитными и при увеличении детализации распадаются на части, порождают многообразие заинтересованных сторон и требований. В чистом виде исполнитель имеет возможность что-то сделать, потребитель в чем-то нуждается, а заказчик является посредником, отвечающим за обмен между исполнителем и потребителем, выдвигающим инициативу запуска проекта, и находящим способ оплатить работу исполнителей, и покрыть расходы за счет потребителей. Это и определяет их полномочия и ответственность в проекте за цели и требования.

У семи нянек дитя без глаза  ^

Учитывая сложность расстановки интересов вокруг большинства сложных программных систем, приходится констатировать: одни из самых больших проблем вокруг проекта - это распределение ответственности и полномочий при установке целей.
Практически всегда происходит вытягивание максимальных полномочий при избавлении от ответственности по максимуму. Это приводит к тому, что реальные исполнители - разработчики софта, получают некачественно поставленные цели (так как тот, кто их ставит, получил полномочия не соответствующие компетенции), при этом ответственность за цели перекладывается на разработчиков или повисает в воздухе.
Чтобы не быть голословным, приведу пример, близкий к разработке коробочного софта. Зовет начальник отдела (или представители отдела продаж) программиста и говорят: надо разработать некую МЕГАСИСТЕМУ. На вопрос, какой она должна быть, следуют философские рассуждения, не приближающие к постановке конкретных целей. На попытку выхода на реальных потребителей выясняется, что таких на горизонте нет, требования собирать негде. Так повторяется много раз. В результате долгих мытарств какие-то требования высасываются из пальца. Но в ответ на простой вопрос: каковы гарантии, что после разработки это все кто-то купит, следует обиженное молчание. В результате наш программист с коллегами тратит пару человеко-лет на разработку МЕГАСИСТЕМЫ, которая не выдерживает первого же столкновения с реальностью.
В ситуации разработки коробочного продукта (как и в любых инвестициях) всегда есть риск, что это не купят. И вопрос только в том, кто несет ответственность за этот риск. В нашем примере за «купят - не купят» и трансляцию требований потребителей несут ответственность маркетологи и продавцы, однако, зачастую эта ответственность переваливается на разработчиков.
В общем случае, разработчик (исполнитель) несет ответственность за техническое решение, заказчик (продавцы, маркетологи или менеджмент при внутренних разработках) несет ответственность за востребованность решения, потребитель отвечает за использование решения себе на пользу.
В жизни случаются самые разные перекосы, связанные с ответственностью за цели. Так, например, в нашем примере с сайтом разработчики ПО не могут нести ответственность за финансовый результат проекта, не могут единолично нести ответственность за посещаемость, так как у них нет ни знаний, ни рычагов, чтобы повлиять на эти параметры. Однако в их силах сделать удобный интерфейс администрирования, обеспечить требуемую нагрузочную способность и надежность - вот это и должно быть поставлено им в качестве целей.
Общей частой проблемой менеджмента является нежелание отвечать за свои слова. Чаще всего цели ставятся устно без фиксации на бумаге, что позволяет всегда переложить ответственность за ошибку. Устная постановка целей также часто приводит к их частому изменению в ходе проекта, что еще больше запутывает ситуацию. Частое изменение целей является показателем или низкой компетенции постановщика, имеющего избыточные полномочия, или объективно большой неопределенности, и то и другое является фактором повышенного риска в проекте. Для того, чтобы не нести бремя этого риска самостоятельно, любой исполнитель, чем бы он не зарабатывал себе на жизнь, ДОЛЖЕН УМЕТЬ ФОРМАЛИЗОВЫВАТЬ И ФИКСИРОВАТЬ НА БУМАГЕ ЦЕЛИ, относящиеся к его области компетенции, ВЫБИВАТЬ ПОДПИСЬ ЗАКАЗЧИКА под этими целями и ПРИТЯГИВАТЬ ЗА ЯЗЫК в случае попытки нагрузить избыточной ответственностью за чужие просчеты.
Если с этим есть проблемы, можно привести аргументацию, которую можно использовать в сложных ситуациях. Если заказчик, кем бы он ни был (юрлицом, начальником, коллегой), пытается выбить подпись под целями, находящимися в области компетенции заказчика (а не исполнителя), например требует гарантии достижения финансовых результатов проекта, можно напомнить ему, что если бы исполнитель мог самостоятельно достигнуть финансовых целей, то он сам был бы заказчиком, а данный заказчик не был бы ему нужен. Если заказчик отказывается от своих предыдущих слов пора переходить на письменную фиксацию. Если заказчик пытается изменить постановку целей, зафиксированных письменно и подписанных им, то можно не сопротивляться, но всегда нужно подсчитать требуемое расширение бюджета проекта, связанное с изменением целей. При живом общении это не так просто, так как среди заказчиков чаще всего встречаются люди, профессионально умеющие давить и склонять к своей точке зрения. Чтобы выстоять в жестких переговорах, можно запомнить три простых правила:
- заказчик не нужен, если ты сам можешь достигнуть поставленной цели (особенно, финансовой);
- любые изменения целей и требований стоят ресурсов, а правило проектного треугольника никто не отменял;
- на любой вопрос вы неизбежно получаете любой ответ (читай, размытые цели приводят к размытому результату).
Как мы уже сказали, для того, чтобы ответственность не размывалась, она должна быть закреплена документально. Пришло время поговорить о документах, связанных с целями.

Обоснование проекта  ^

Один из общих подходов к процессу постановки целей как ИТ проектов, так и любых других приведен в своде знаний BABOK (от Международного Института Бизнес-Анализа IIBA).
Все начинается с того, что каждая организация имеет миссию - документ, фиксирующий ценности и глобальные цели организации. Здесь и далее следует иметь в виду, что даже если такого документа нет - это не значит, что миссия (или другая информация) отсутствует. Первые лица организации владеют информацией о целях организации и вопрос всего лишь в том, скажут они об этом или умолчат. То же самое относится к любым другим документам: их может не быть, но информация есть в головах людей.
На основании миссии организация разрабатывает стратегию, описывающую способ достижения поставленных целей при сохранении заявленных ценностей (ограничений).
На основании стратегии стравятся стратегические цели на определенный период времени (пятилетка, год и т.д.).
На основании стратегических целей разрабатывается способ их достижения: требуемая структура подразделений, бизнес-процессы, описываются требуемые ресурсы.
А на основании анализа текущего положения дел и отличия от желаемого положения дел выдвигаются предложения по переходу к желаемому положению дел. Сюда входят предложения по изменению бизнес-процессов, оргструктуры, технических средств и т.д.
На основе предложений появляется бизнес-план, который призван оценить как затраты на проведение изменений, так и пользу. После рассмотрения бизнес-плана принимается решение о запуске проекта (проектов), проводящих требуемые изменения. В практике общего проектного управления документом, фиксирующим цели проекта, является устав проекта. Устав содержит наиболее общую формулировку целей, несколько ключевых параметров проекта, а так же указание о задействованных ресурсах.
Одной из разновидностей улучшающих изменений в бизнесе является разработка и внедрение или модернизация программного обеспечения. В таком случае для обоснования целесообразности выполнения проекта также служит бизнес-план. Для фиксации назначения и концептуального облика будущей системы служит документ-концепция системы. В MSF под создание и модификацию концепции отводится фаза итерации, в ГОСТ на создание программных систем разработка концепции - отдельный этап проекта.
Еще один термин, связанный с запуском ИТ проекта - технико-экономическое обоснование (ТЭО). Грубо можно сказать, что назначение бизнес-плана для проекта скорее показать образ результата и затраты: что мы получим, сколько и когда требуется привлечь ресурсов и каких. Выход на подсчет рентабельности проекта может быть недостижим из-за трудностей с переводом пользы в денежное выражение. ТЭО же подразумевает более или менее точную оценку срока окупаемости и рентабельности или другого эффекта от реализации проекта.
Обычно финансовая составляющая и достижение бизнес-эффекта находятся вне компетенции разработчиков ПО, поэтому для ИТ проекта наиболее близким документом, фиксирующим цели, служит концепция системы или концептуальный документ проекта с другим именем.

Концептуальный документ проекта  ^

Рассмотрим более подробно информацию, которая должна быть в концептуальном документе. В качестве основы описания взята "рыба" документа vision из RUP. Мой опыт показывает, что приведение содержания документа - "рыбы" вместе с инструкциями по заполнению неэффективно. Поэтому для рассказа о концептуальном документе здесь выбран другой стиль - будут перечислены вопросы, на которые должен отвечать концептуальный документ проекта. Следует отметить, что не существует единственно верного способа создавать программное обеспечение. Поэтому ответы на перечисленные вопросы могут быть частью какого-то документа, частью некоторых документов. вполне возможно, что в маленьких проектах ответы на вопросы не будут зафиксированы на бумаге, но они должны существовать хотя бы в голове разработчиков.
итак, первый вопрос: в чем проблема? Дополнительные к этому вопросу:
- что плохого происходит (может произойти) и у кого, сколько, чего, и кто теряет?
- какие возможности упускаются, сколько, чего и кто может приобрести?
Дополнительные вопросы подводят нас вплотную к технико-экономическому обоснованию проекта. В любом случае мы хотели бы создавать наиболее эффективное программное обеспечение, то есть то, которое наилучшим образом решает проблемы или реализует возможности. Чтобы понять, что будет лучшим, надо сначала понять, какие проблемы мы решаем или какие возможности реализуем.
Второй вопроc: у кого проблемы или возможности, кто еще будет затронут, кто имеет интерес в происходящем, кто предъявляет требования и устанавливает правила игры? Дополнительные к этому вопросу:
- Кому станет лучше и в чем конкретно?
- Кто будет ущемлен и насколько?
- Кто придет призвать к ответу, кого и за что?
- Чьи интересы следует учесть?
Эта группа вопросов приводит к выявлению заинтересованных сторон и их интересов. Кроме основных целей создания ПО следует учесть все интересы вокруг системы, так как эти интересы будут основным источником дополнительных целей и ограничений. В этом месте практически всегда найдутся не только сторонники системы, но и ее противники. Для нейтрализации противодействия некоторых заинтересованных сторон можно предложить им какую-то выгоду от разрабатываемой системы, а можно применить ресурсы вне системы. Самой частой проблемой ИТ проектов является несогласованность интересов вокруг проекта, препятствующая сначала продуктивному сбору требований, а потом внедрению. Частый пример: одна из группировок внутри организации продавливает покупку и внедрение системы документооборотного или учетного класса для удовлетворения своих собственных интересов. Если говорить по-хорошему, то, наверное, внедрение такой системы могло бы принести пользу организации. Но при этом будут упразднены функции некоторых подразделений, в других придется навести порядок. Потенциальные расходы, связанные с организационными изменениями и так велики. Но к ним добавляется сопротивление доброй половины организации, что не позволяет найти подход к согласованию интересов и выявлению требований, которые бы могли сделать систему автоматизации эффективным инструментом бизнеса.
Для того, чтобы выйти на свойства SMART для заинтересованных сторон можно описать, включая доступные характеристики: временные, денежные или в натуральном выражении.
- В чем заключается их интерес?
- В чем заключается их обязанности?
- В чем заключается их работа?
Согласование целей служит основой выработки организационного решения проблемы, которое должно дать представление, как будет устроен бизнес вокруг внедряемой системы автоматизации. Кто будет использовать какие ее функции и для чего, как именно будет получаться польза от системы. Организационное решение должно быть описано в концептуальном документе.
Если говорить о бизнес-приложениях, то все проблемы бизнеса будут связаны с получением каких-то бизнес-результатов. Перечень заинтересованных сторон, их интересов и проблем в конкретных производственных цепочках являются началом обследования организации. В ходе обследования предстоит выяснить, как устроены потоки ресурсов, протекающие через проблемные участки к достижению конкретных бизнес-результатов, улучшаемых внедрением системы, как в этих потоках задействованы заинтересованные стороны. Можно видеть, что если проблемы и заинтересованные стороны не названы, обследование бизнес-процессов для сбора требований становится неэффективным, так как нет никаких критериев охвата, декомпозиции и детализации процессов.
При описании организационного решения мы получаем перечень пользователей создаваемой системы. Для каждого типа пользователя нужно ответить на те же вопросы, что и для заинтересованных сторон: их интерес, их обязанности, их работа - в чем они заключаются.
Кроме организационного решения в концептуальный документ включается техническое решение, которое покажет принципиальную реализуемость организационного решения. Должны быть описаны основные особенности системы, важные на концептуальном уровне: концептуальная, физическая и логическая архитектура, необходимость сопряжения со смежными системами, требования к форматам и т.д. Эти концептуальные решения послужат основой для сбора технических требований к системе, а также для предъявления требований к техническому окружению системы.
И последнее по порядку, но не по значению: требования к окружению. Требования к окружению показывают, что должно быть выполнено и обеспечено вне проекта для успешного функционирования системы. Требования к окружению могут быть организационными (требования к персоналу, к мероприятиям по внедрению и т.д.) и техническими (требования к сети, серверу, специальному оборудованию и т.д.).
Вот краткий список вопросов, которые должны быть освещены в концепции системы. Будет ли концепция частью бизнес-плана или ТЗ или будет самостоятельным документом, важно одно: концептуальный документ обязан содержать ВСЮ ИНФОРМАЦИЮ, ИСХОДНУЮ ДЛЯ СБОРА ТРЕБОВАНИЙ: или концептуальные требования, детализируемые до требований спецификации или указания на то, где взять недостающие требования. Кроме этого концепция должна содержать указания на ПОДХОДЫ К ИЗМЕРЕНИЮ ДОСТИГНУТОГО РЕЗУЛЬТАТА. Естественно, в жизни идеальных документов не бывает, и на это есть как объективные, так и субъективные причины, о которых мы поговорим ниже.

Welcome aboard  ^

Неисправимый дефект принципа SMART  ^

Выше мы обсуждали принцип SMART для постановки целей. Теперь мы разберем принципиальные возражения против буквального следования этому принципу. Источником возражений против принципа SMART являются три вещи:
- принципиальная проблема точности описания,
- объективная неопределенность,
- отказ от персональной ответственности.
Проблему точности описания можно проиллюстрировать такой гипотетической ситуацией. Я прошу принести мне молока. Мне приносят, но оказывается, что я не хотел холодного. Мне подогревают, но оказывается, что молоко кислое. Мне приносят кислого подогретого, но оказывается, что жирность 6% меня не устраивает - плохо утоляет жажду... В результате выясняется, что я хочу пить, и подошла бы простая вода, но воду я не люблю, а чаю сейчас не хочу, поэтому остановил выбор на молоке, но, если подумать, подошла бы и газировка и квас.
Здесь показаны обе части проблемы точности описания: чем точнее я хочу описать желаемое, тем больше слов должен использовать. Единственный способ исчерпывающе описать предмет - это предъявить его. Вторая часть проблемы - это многовариантность цели. Есть множество путей удовлетворения какой-либо потребности, выбор пути зависит от мнения о предпочтительности того или иного варианта, которое может изменяться.
В результате можно сказать, что постановка задачи не может быть исчерпывающе точной и оптимальной. В общем, нет смысла стремиться к постановке оптимальной цели с абсолютной точностью - это невозможно. Практическим критерием хорошей постановки цели является четкое понимание, что будет происходить дальше и отсутствие проблем при реализации цели. Можно видеть, что если понимания перспективы можно достичь и с одного раза, то отсутствие проблем в реализации - это вопрос опыта постановщика, знающего, что важно, а что нет при достижении целей в данной области.
При написании концепции должен действовать своеобразный принцип неопределенности: чем дальше в будущее мы смотрим, тем меньше мы о нем знаем. Концептуальными требованиями и свойствами системы являются те, о которых мы знаем сегодня и они не изменятся к моменту окончания внедрения системы или даже к моменту окончания эксплуатации. Эти соображения ограничивают глубину детализации и объем концепции несколькими страницами и показывают, каким требованиям не место в концептуальном документе, даже если они имеются на момент его составления.
Объективная неопределенность существует всегда, когда мы говорим о будущем. Мы уже говорили о многовариантности целей, достижение которых удовлетворяет потребности. Наше знание о предпочтительности того или иного пути будет уточняться по мере продвижения и может сильно измениться по мере того, как начнут выясняться проблемы реализации. точно так же с течением времени будут меняться интересы заинтересованных сторон. Иногда не сильно, иногда - кардинально. По этому риск на старте существует всегда, и тот, кто ставит цель, должен осознавать этот риск, оценивать его и брать за него ответственность. Для того, чтобы взять под контроль неопределенность, можно фиксировать при постановке цели не только то, что известно, но и то, что нам неизвестно и то, каких изменений мы опасаемся или ожидаем. Несмотря на то, что риски проекта обычно не включают в концепцию, можно явно подчеркнуть и описать границы белых пятен в нашем знании проблемы и заинтересованных сторон, так как неопределенность - это не повод ничего не делать. Проект, который стартует с неопределенностью в целях, должен быть готов к их изменению и переутверждению - это не так сложно, но требует более тесного и открытого взаимодействия с заказчиком и потребителем.
Об отказе от ответственности уже говорилось выше. Добавить можно только то, что это единственное, что можно и нужно устранить при постановке целей. Одна из объективных причин всеобщего перекладывания ответственности является тяга к определенности и неизменности. Выше мы видели, что обеспечить абсолютные гарантии невозможно. Немного исправить ситуацию можно путем обсуждения объективной природы неопределенности с заказчиком, налаженного управления рисками (которое частично возвращает психологическую защищенность от неопределенности), а так же внедрением документальной фиксации целей и требований. Полностью, навсегда и везде устранить попытки ухода от ответственности, похоже, невозможно. И единственным рецептом "выживания" в сложных условиях для разработчика остается четкое знание своих "прав и обязанностей", а так же точное выполнение всех своих обещаний: как обещаний что-то сделать, так и обещаний, что что-то невозможно или не получится.

Война и мир  ^

Из распространенных проблем с целями я знаю еще две, связанные с искажением или сокрытием истинных целей: политкорректность и ситуация противостояния. Самая простая демонстрация первого случая - это то, что в концептуальные документы
и спецификации требований достаточно редко вписывают интересы исполнителя. Никто не пишет, что целью проекта будет проверка новых технологий и методик разработки, или, что целью проекта является получение демонстрационной площадки, куда можно будет привести потенциальных клиентов и продемонстрировать позитивные результаты своей работы. Почему-то считается, что все интересы исполнителя всегда финансовые и только. В реальности все по-другому. Случается даже такое, что проект выгодно спустить на тормозах и ни в коем случае не делать его успешным. Естественно такие факты не всегда доводятся до каждого члена проектной команды, обрекая команду на фактическую неудачу.
Еще более жесткой ситуация становится тогда, когда цели явно и намеренно скрываются. Так, например, бывает при продаже какого-нибудь очень дорогого софта, полезность которого для заказчика, мягко говоря, не доказана. Ни о каком бизнес-плане или ТЭО речи быть не может, так как попытка выйти на рентабельность покажет что, во-первых, стоимость организационных изменений для заказчика сегодня неподъемна, во-вторых, даже при хорошем раскладе с организационным обеспечением внедрения рентабельность проекта внедрения стремится к отрицательным величинам. Почему заказчик идет на такую покупку - это тема отдельного разговора. С точки зрения ИТ разработчика и внедренца есть принципиальная проблема: проект остается без SMART целей, что автоматически делает его неуспешным. Если продавцы в этой ситуации работают грамотно, то акты закрытия этапов будут подписаны без проблем, но добавить в свой послужной список какие-то реальные достижения разработчику не удастся.
Конечно, в ситуациях с искаженными целями не все так однозначно плохо. Если хоть какие-то ресурсы выделяются на разработку, а цели туманны, то можно смело ставить себе цели и использовать ресурсы для их достижения. Вопрос только в том, кто придет призвать к ответу и как быстро...
Как сказал Сунь Цзы, война - это путь обмана. Причем, обмана как чужих, так и своих. Это надо учитывать и понимать, что если организация продает описанными чуть выше методами, то кто-то из ее сотрудников когда-то окажется пушечным мясом.
Разработчик, находящийся в ситуации противостояния тоже может извлечь пользу, четко понимая, по каким правилам здесь идет игра. В любом случае, понимание ситуации еще никогда не вредило.
Несмотря на то, что искажение и сокрытие целей - это не очень приятно, оно в той или иной мере происходит почти всегда. Чтобы уменьшить негативное влияние или даже получить пользу надо хотя бы об этом знать. Всегда полезно поинтересоваться ситуацией вокруг проекта, ведь "кто предупрежден, тот вооружен".

Куда бежать?  ^

Закончить рассуждения о том "как надо" хочется оговоркой о том, что в жизни все получается "как обычно". Неопределенность на старте проектов больше, чем могла бы быть. Проектная документация не идеальна, а политические игры вокруг проекта сводят ее полезность к минимуму.
Несмотря на это, уделение серьезного внимания постановке и (что самое главное) фиксации целей позволяет, во-первых, избежать попадания в заведомо безнадежные проекты, а во-вторых, позволяет существенно повысить качество небезнадежных. Таковы мои выводы на этот счет.
На этом мне остается поблагодарить читателя, дочитавшего материал до конца.
И для закрепления прочитанного, приведу краткие побуждения к действию, следующие из материала этого раздела.
- ВСЕГДА пишите концептуальный документ проекта.
- Ищите подход к ТЭО. Даже если рентабельность отрицательная - вы должны об этом знать, заказчику не обязательно.
- Не берите ответственность за цели вне вашей власти или компетенции, как бы не давили окружающие.
- Научитесь притягивать за язык и ставить на место.
- Смиритесь с тем, что цель не всегда в разработке качественного ПО и эффективном его внедрении. Но что делать дальше - каждый выбирает сам.