Продолжаем разговор про планирование проекта. Составив в прошлый раз реестр результатов мы определились, какие конкретные результаты будут созданы. Теперь надо наметить путь к ним. Это сложно:

• Во-первых, проект по определению это что-то новое, и обычно довольно большое. Поэтому придумать, какие работы нужны для достижения отдаленных результатов требует большого количества мыслетоплива. Это мучительно.
• Во-вторых, как только вы набрасываете большое количество работ, в них сразу же становится сложно ориентироваться, особенно — вашим бизнес-пользователям. Они будут вас игнорить, им будет сложно качественно проработать план, а виноват окажется руководитель проекта.

И вот здесь хочу поделиться приемом, который не все применяют, а вернее, мало кто: прежде, чем набрасывать список работ, мы разработаем product flow diagram (инструмент из моего любимого PRINCE2, кстати). Не придумал, как это емко перевести на русский язык, приблизительно — диаграмма декомпозиции продукта проекта (помним, как отличаются и чем похожи результаты и продукты проекта). Проще показать на примере.

Это реальная диаграмма декомпозиции продукта одного из моих проектов. Мы получили ее в ходе нескольких сессий совместно с бизнес-пользователями. Каждое звено здесь — результат, продукт или промежуточный продукт проекта, а стрелочки показывают, что в какой очередности надо получать.

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

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

Помимо того, что это просто красиво, это удобно:

• Позволяет увидеть костяк плана, пока его не завалило отдельными работами. Это гораздо проще обсуждать с ключевыми пользователями. Диаграмму на иллюстрации все еще реально обсудить на одном совещании. План из 200+ работ можно только презентовать, со всеми ограничениями формата.
• Промежуточные продукты — это важные вехи. Можно их использовать для планирования отдельных блоков работ: в крупных проектах их может создавать отдельная команда, а в маленьких они станут ключевыми результатами в операционном плане.
• К промежуточным результатам тоже можно описать требования. Это очень полезно, потому что на этом постоянно происходят срывы: команда разработки ждет от пользователей выгрузку данных текущих систем, выгрузка приходит, но в кривом формате. Проблема. Или команда разработки передает модули в тестирование, а пользователи не знают, с какой стороны к ним подходить: не прописали, что должен быть промежуточный продукт «сценарии тестирования», не заложили в план, не сделали.

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

Диаграмму на картинке я разработал в программе Flying Logic Pro. Программа удобна тем, что автоматически перестраивает диаграмму, чтобы минимизировать пересечения линий, а также позволяет сворачивать и разворачивать целые блоки на схеме. Если вам кажется, что это пустяки, попробуйте разработать схему из сотни блоков, после этого поговорим :) Также она позволяет готовую диаграмму экспортировать в МС Проджект. Правда, она платная, причем довольно сильно платная.

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