Решебник начинающего руководителя проекта

Ну все понятно, а начинать-то с чего? \ Старт проекта

Как гласит один из законов Мерфи, «все, что хорошо начинается, кончается плохо. Все, что плохо начинается, кончается еще хуже».

От правильного старта проекта зависит довольно многое. Чем лучше подумать на старте, тем меньше потом придется переделывать. Это совершенно не значит, что надо долго думать и мало делать. Делать-то как раз надо много, и с самого начала.

Проект, в зависимости от того, что надо получить и как, конечно же, стартует по-разному.

Ниже нарисована примерная схема старта, где сверху на этапах указаны действия, а снизу под линией – результат этого этапа.

1. Опишите все, что хочет заказчик. Лучше начать с простого наброска документа от самого заказчика, которое называется первоначальным Видением. Это не Техническое задание, а именно то, как заказчик видит конечный результат. А потом его надо проговорить словами. Как раз в разговоре вы начнете понимать, что важно для заказчика и чего он хочет достичь на самом деле.

Не факт, что именно это написано в Видении. Там может оказаться описание того, КАК заказчик себе представляет решение целевой бизнес-задачи. И не всегда это решение верно.

На первых проектах у тебя может не хватить опыта это понять и предложить, как на самом деле надо. И работа будет отталкиваться именно от Видения заказчика. Это не хорошо и не плохо, это жизнь. И решение, которое придумал заказчик, если даже оно не идеальное, будет работать.

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

В этом пункте используй те же принципы, что и в главе по декомпозиции задач (см. главу «Декомпозиция задач»). На тебя будет валиться куча информации по самым разным аспектам будущего проекта: идеи по реализации, элементы обязательных требований, просьбы по процессам работы и законы, которые влияют на работу отрасли.

Старайся выделять «области» будущего проекта и прописывай там каждый такой факт или требование. В первой версии области могут быть такими:

– Функции продукта.

– Техника и инфраструктура.

– Процессы совместной работы.

– Этапы, контрольные точки и дедлайны.

– Источники информации для будущего сбора требований.

– Пользователи, роли и их ограничения.

– Риски.

– Прочее.