В самом начале проекта вы собираете информацию о проекте и о задачах, которые перед вами стоят. Это не так просто, как может показаться непосвященному человеку.

Вы постоянно оказываетесь в такой ситуации, что чем больше вы задаете вопросов и получаете ответов — тем больше вопросов возникает и яснее особо не становится. Мы склонные переоценивать свое понимание требований, которые мы получаем от клиента. Думаем, что понимаем, что клиент ожидает, но раз за разом с удивлением обнаруживаем, что ошибаемся.

Так называемый «закон Хоггарта» (Hoggarth’s law) гласит:
«Попытки получить ответы на вопросы в начале проекта проваливаются потому что мы задаем больше неправильных вопросов чем правильных. Усилия должны быть направлены не на нахождение ответов, а на поиск правильных вопросов. Когда правильные вопросы определены — ответы естественным образом будут вытекать из последующей работы и будет более полное понимание целей проекта»

Частая ошибка бизнес-аналитиков (или того, кто выполняет эту роль в начале проекта) — излишняя уверенность в том, что требования собраны полностью и достигнуто полное понимание того, что надо сделать. Часто этому способствует ограниченное время и давление на аналитика, чтобы быстрее приступить к выполнению работы. Типа «главное ввязаться в драку, а там видно будет»

Это приводит к дорогостоящим переделкам уже сделанной работы. В худшем случае может привести даже к переписыванию архитектуры уже после начала проекта и существенному удорожанию стоимости.

Способность определять правильные вопросы приходит почти исключительно с опытом, поэтому за неопытным бизнес аналитиком стоит закрепить более опытного ментора, хотя бы в начале проекта, для избежания описанных выше последствий.

«проекты не проваливаются в конце, они проваливаются в начале».

В реальной жизни проект обычно проходит следующие стадии:

  • Энтузиазм
  • Полное непонимание
  • Разочарование
  • Поиск виноватых
  • Наказание невиновных
  • Награждение непричатных

Чеклист менеджера проектов в начале проекта может выглядеть так:

Размер проекта, производительность, качество

  • Проверить полноту требований
  • Проанализировать альтернативы
  • Проверить нефункциональные требования к производительности: точность, скорость, надежность, доступность и так далее
  • Установить необходимый уровень качества
  • Установить методы контроля за сроками, бюджетом, объемом работ)

Выполнимость проекта с точки зрения времени, бюджета и объема работ

  • Составить матрицу рисков и оценить их влияние и методы реагирования
  • Описать изначальные допущения и установки
  • Подготовить план проекта
  • Определить бизнес-ценность, стоимость её достижения и размер потенциальных доходов от проекта для бизнеса
  • Определить контрольные точки(вехи) проекта для анализа текущего хода проекта, в которых будет приниматься решение о продолжении или остановке выполнения проекта

Процессы в ходе проекта

  • Предположить необходимые ресурсы, их эффективность
  • Установить нормы ожидаемой эффективности
  • Выявить возможности для улучшения эффективности с точки зрения сроков и бюджета

Основные усилия должны быть направлены на то, чтобы в начале работы над проектом, ни у кого не было сомнений о том, почему и как мы делаем проект

Спасибо Белковец Александр. Оригинал статьи тут

прочли: 166

Получай сообщения о новых видео, статьях, документах и событиях раз в неделю!

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

LAMPOVOE IT: сообщество не программистов will use the information you provide on this form to be in touch with you and to provide updates and marketing.