Проект представляет собой масштабную и сложную задачу, для реализации которой имеет смысл разбить ее на части. Для этого используют жизненные циклы проекта.
На мой взгляд, жизненный цикл проекта (ЖЦ) служит следующим целям:
- Хорошо проработанная модель жизненного цикла проекта позволяет определить иерархическую структуру работ проекта,
- ЖЦ проекта во многом определяет, какой подход (методологию) для управления проектом выбрать, а выбор подхода повлияет на методы и инструменты планирования и контроля проекта.
Глобально существует 2 ключевых подхода к формированию ЖЦ проекта:
- Водопадная модель
- Итерационная модель
Описание водопадной модели проекта появилось раньше итерационной модели. Первое официальное описание модели водопада приписывается статье автора Winston W. Royce, вышедшей в 1970 году, хотя автор и не использовал в статье термин «водопад». Впервые термин "водопад", как считается, был введен в 1976 году.
Водопадная модель построена на предположении о том, что сначала в проекте должно появиться понимание того, что команда проекта должна получить в итоге работы над проектом. Потом нужно ответить на вопрос «как мы сделаем это?», после чего должна произойти реализация запланированных результатов проекта и приемо-сдаточные испытания. Поэтому водопадный ЖЦ часто изображают в виде 4-х этапов, не пересекающихся во времени:
Надо отметить, что водопадный жизненный цикл обычно привязан к технологии выполнения работ, поэтому для некоторых отраслей экономики разработаны отраслевые «водопадные» ЖЦ проекта. Использование отраслевых водопадных моделей позволяет стандартизировать подходы к структурированию проекта, накапливать статистику по стандартным этапам проекта и т.д.
Ключевые плюсы водопадного ЖЦ проекта, на мой взгляд:
- Команда проекта и заказчик последовательно получают ответы на вопросы: «Что нужно получить? Как мы это сделаем?», и только после этого приступают к реализации задуманного.
- Спланировать объемы работ, сроки и бюджет после второго этапа становится намного проще, т.к. мы имеем ответы на самые сложные в проекте вопросы.
Минусы водопадного подхода:
- Оценка сроков и стоимости всего проекта на старте этапа «Концепция» затруднена, т.к. не проработаны требования к результатам проекта.
- Как правило, работа над первыми двумя этапами занимает много времени, срок реализации всего проекта становится, на взгляд заказчика проекта, слишком большим.
- Часто на этапе реализации требования к результатам проекта все же начинают изменяться, несмотря на попытку собрать все требования и описать подходы к их реализации на втором этапе ЖЦ проекта. Вносить изменения в разрабатываемый продукт проекта на этапе реализации зачастую становится сложно.
- Пользователи результатов проекта увидят их впервые на четвертом этапе, а то и по завершению проекта. Обратная связь от пользователей поступает слишком поздно, когда цена внесения изменений в результаты проекта уже слишком велика.
Устранить указанные минусы водопадной модели должен был итерационный ЖЦ проекта. Суть этого подхода – деление проекта на серию мини-проектов (итерации), в каждом из которых получаем ответы на вопросы «Что?» и «Как?», реализуем задуманное и проверяем. По окончании каждой итерации заказчик проекта принимает решение, можно ли показать то, что уже получилось, представителям будущих пользователей, чтобы быстрее понять, сделали мы то, что ими будет востребовано, или в чем-то ошиблись.
Плюсы итерационного подхода к ЖЦ проекта:
- Пользователи результатов проекта и другие заинтересованные стороны проекта могут увидеть прототип продукта на одной из ранних итераций (когда уже есть что показать).
- Требования к результату (продукту) проекта могут уточняться по итогу каждой итерации, что дает возможность быстро вносить изменения в создаваемый результат проекта.
- Управление изменениями требований к результатам проекта достаточно простое, т.к. сводится к расстановке приоритетов для каждого требования.
- Планирование каждой итерации проходит достаточно легко, т.к. несложно оценить объемы работ на итерацию и отобрать столько задач, сколько команда способна реализовать с учетом ее производительности.
- Знакомясь с приращением функционала продукта проекта по окончанию каждой итерации, у заказчика проекта формируется понимание о продукте по мере продвижения по проекту. Это облегчает приемо-сдаточные испытания продукта в конце проекта.
Минусы итерационного ЖЦ проекта:
- Трудно рассчитать количество итераций на проект, не зная, сколько раз будут изменяться требования к результатам проекта и насколько изменения будут существенны. Исходя из этого, трудно спрогнозировать бюджет и срок реализации проекта.
- Плохое управление приоритетами требований к результатам (продуктам) проекта может привести к тому, что выделенный на проект бюджет закончится, а продукт проекта не будет готов.
- Этот подход требует серьезного вовлечения представителя заказчика проекта, т.к. нужно планировать каждую итерацию вместе с командой проекта, расставлять приоритеты по требованиям к продуктам проекта, принимать результат каждой итерации и давать обратную связь по итогам демонстрации результата итерации.
Какую модель ЖЦ проекта выбрать?
Ответ на этот вопрос зависит от:
- Готовности заказчика потратить время и деньги на проработку требований к результатам проекта до того, как начать разрабатывать продукт(ы) проекта.
- Степени вовлеченности заказчика проекта. Его готовности тратить свое время на проект.
- Типа контракта на проект.
- Масштаба и трудоемкости проекта.
- Степени инновационности результатов проекта.
- Требований к безопасности продуктов проекта.
И т.д.
Как мне кажется, для некоторых проектов можно рассмотреть вариант скрещивания двух подходов к жизненному циклу проекта. К примеру, для проекта, использующего водопадный ЖЦ, можно внутри этапа «Реализация» использовать итерационный подход для наращивания функциональности создаваемого в проекте продукта.
На самом деле, существует большее количество ЖЦ проекта, чем описано в статье, но все они, на мой взгляд, являются модернизациями водопадной или итерационной модели.
Например, V-образная модель ЖЦ проекта была разработана на базе водопадной модели и является ее разновидностью.
Спиральная модель ЖЦ проекта основана на разбиении проекта на итерации, но в эту модель встроены дополнительные требования (например, анализ рисков на каждой итерации, снижение рисков в следующей итерации и обязательное использование прототипа для разработки продукта проекта).
Подведем итоги:
- Руководитель проекта может не использовать ни одну из существующих моделей ЖЦ проекта, но в этом случае он изобретает велосипед для своего проекта.
- Нет единственной подходящей для любого проекта модели ЖЦ проекта.
- Чем больше опыта у руководителя проекта и команды проекта по работе с разными моделями ЖЦ проекта, тем больше вероятность того, что под конкретный проект они смогут выбрать наиболее подходящую для него модель ЖЦ проекта, а под эту модель - наиболее адекватные методы и инструменты планирования, контроля и внесения изменений в проект.
Поэтому мой совет будет таким: анализируйте опыт выполненных проектов для того, чтобы лучше понимать, какая модель ЖЦ проекта в каком случае лучше подойдет для вашего проекта, и продолжайте изучать тему ЖЦ проектов. Возможно, кто-то в данный момент описывает новую модель ЖЦ проекта для вашей отрасли и в скором времени собирается опубликовать ее для нас.