Управление проектом, как оставаться на плаву - метафора

Метафора: водонепроницаемые переборки, разделяющие корпус корабля на отсеки, помогают ему сохранять плавучесть при пробоинах, аналогично, разделение проекта на этапы помогает ему не пойти в разнос.


Рассмотрим проект по разработке сайта (веб системы, если угодно). Легко выделить типовые этапы:
  • сбор и анализ требований, 
  • проектирование и подготовка документации, 
  • разработка дизайна, 
  • верстка и реализация функциональных элементов, 
  • наполнение материалами, 
  • запуск.
Если какой-то из этих этапов, обычно разработка, бывает рискованно длинным, его также можно разбить на этапы (версии, шаги).

Внутри, каждый из больших этапов обычно представляет собой итеративный процесс, который тоже полезно разбить на подэтапы: планирование, реализация, тестирование и демонстрация заказчику, и опять планирование, и так далее (то есть, при необходимости - повторить).

Этапы проекта должны быть как отдельные отсеки в трюме корабля. Если какой-то отсек получил пробоину и залит водой - не страшно. Главное, чтоб вода не попала в соседние с ним. Даже если залиты несколько отсеков, до определенного предела корабль может сохранять плавучесть. Аналогично, и проект в целом может быть успешным, даже если возникли проблемы на каких-то этапах – не страшно, главное, чтобы эти проблемы не перешли на смежные этапы.

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

Если есть этапы, то проблему легко локализовать внутри текущего этапа - все равно, что задраить люки в водонепроницаемых переборках, отделяющих затопляемые отсеки - не дать воде проникнуть в соседние.

Какими должны быть этапы проекта, чтобы исполнять роль таких отсеков ограниченных переборками?
  1.  Должны быть понятны и формализованы границы этапа – например, этап ограничен подписанием документов (договоров, технических заданий, актов). Причем, эти границы должны быть понятны всем участникам проекта и у заказчика, и у исполнителя.
  2. Информация, передаваемая между этапами, должна иметь контролируемый объем и форму - только вот это и ничего другого. Например, после этапа проектирование на следующие этапы передается только Техническое Задание, а все имевшиеся на данном этапе обсуждения и метания уже не имеют значение. Значение имеет только то, что зафиксировано в Техническом Задании.
    Аналогично, после этапа разработки дизайна значение имеют только те 3-4 картинки, которые появляются в итоге бурных дискуссий и фантазий, все остальное остается надежно замкнутым за переборкой - границей этапа. И лучше, если этот факт будет зафиксирован актом сдачи-приемки работ.