Какие бывают жизненные циклы проекта и почему важно об этом знать

Наш эксперт Максим Якубович рассказывает про две модели жизненного цикла проекта и анализирует плюсы и минусы каждой из них.

На мой взгляд, жизненный цикл проекта (ЖЦ) служит следующим целям:

1. Хорошо проработанная модель ЖЦ позволяет определить иерархическую структуру работ.

2. ЖЦ проекта во многом определяет, какой подход (методологию) для управления проектом выбрать. Это, в свою очередь, влияет на методы и инструменты планирования и контроля.

Глобально существует 2 ключевых подхода к формированию ЖЦ проекта, о которых я расскажу.

Водопадная модель

Первое ее официальное описание встречается в статье Winston W. Royce (хотя автор и не использовал термин «водопад»), вышедшей в 1970 году. Сам термин, как считается, впервые был введен в 1976 году.

Модель построена на предположении – сначала в проекте должно появиться понимание, что именно команда проекта должна получить в итоге работы. Потом нужно ответить на вопрос «Как мы это сделаем?». После происходит реализация запланированных результатов проекта и затем – приемо-сдаточные испытания.

Поэтому водопадный ЖЦ часто изображают в виде 4-х этапов, не пересекающихся во времени:
 

Этот жизненный цикл обычно привязан к технологии выполнения работ, поэтому для некоторых сфер разработаны отраслевые «водопадные» ЖЦ проекта. Их использование позволяет стандартизировать подходы к структурированию проекта, накапливать статистику по стандартным этапам проекта и т.д.

Плюсы водопадного ЖЦ проекта, на мой взгляд, следующие:

1. Команда проекта и заказчик последовательно получают ответы на вопросы: «Что нужно получить?», «Как мы это сделаем?», и только после этого приступают к реализации задуманного.

2. Спланировать объемы работ, сроки и бюджет становится намного проще, т.к. мы имеем ответы на самые сложные в проекте вопросы.

Минусы водопадного подхода:

1. Оценка сроков и стоимости всего проекта на этапе «Концепции» затруднена – не проработаны требования к результатам проекта.

2. Как правило, работа над первыми двумя этапами занимает много времени. Срок реализации всего проекта становится, на взгляд заказчика, слишком большим.

3. Часто на этапе «Реализация» требования к результатам проекта все же начинают изменяться. Вносить изменения в разрабатываемый продукт проекта зачастую становится сложно.

4. Пользователи впервые увидят результаты только на четвертом этапе – «Завершение», а то и после него. Обратная связь от пользователей поступает слишком поздно, когда цена внесения изменений в результаты проекта уже слишком велика.

Итерационная модель

Для устранения упомянутых выше минусов можно использовать итерационный ЖЦ проекта. Его суть заключается в делении всего проекта на серию мини-проектов (итераций). В каждом из них происходит получение ответов на вопросы «Что?» и «Как?», реализация задуманного и его проверка. По окончании каждой итерации заказчик принимает решение, можно ли показать то, что уже получилось, будущим пользователям. Это помогает побыстрее понять, сделан ли востребованный продукт, или его разработчики в чем-то ошибаются. 

Плюсы итерационного ЖЦ проекта:

1. Пользователи результатов проекта и другие заинтересованные стороны могут увидеть прототип продукта на одной из ранних итераций (когда уже есть что показать).

2. Требования к результату (продукту) проекта могут уточняться по итогу каждой итерации. Это дает возможность быстро вносить изменения в создаваемый результат.

3. Управление изменениями требований к результатам проекта достаточно простое, т.к. сводится к расстановке приоритетов для каждого требования.

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

5. Знакомясь с приращением функционала по окончании каждой итерации, у заказчика формируется понимание о продукте. Это облегчает приемо-сдаточные испытания в конце.

Минусы итерационного ЖЦ проекта:

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

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

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

Какую модель ЖЦ проекта выбрать?

Ответ на этот вопрос зависит от нескольких факторов:

1. Готовности заказчика потратить время и деньги на проработку требований к результатам проекта до того, как начать разрабатывать продукт(ы) проекта.

2. Степени вовлеченности заказчика проекта. Его готовности тратить свое время на проект.

3. Типа контракта на проект.

4. Масштаба и трудоемкости проекта.

5. Степени инновационности результатов проекта.

6. Требований к безопасности продуктов проекта.

Как мне кажется, для некоторых проектов можно скрещивать два подхода к жизненному циклу проекта. К примеру, для проекта, использующего водопадный ЖЦ, можно внутри этапа «Реализация» использовать итерационную модель. Это поможет нарастить функциональность создаваемого продукта.

В реальности существует большее количество жизненных циклов, чем описано здесь. Но все они, на мой взгляд, являются модернизациями водопадной или итерационной модели. Например, V-образная модель ЖЦ проекта была разработана на базе водопадной – как одна из ее разновидностей.

Спиральная модель основана на разбиении проекта на итерации. Но в нее встроены дополнительные требования (например, анализ рисков на каждой итерации, снижение рисков в следующей итерации и обязательное использование прототипа для разработки продукта проекта).

Подведем итоги:

1. Руководитель проекта может не использовать ни одну из существующих моделей ЖЦ проекта, но в этом случае он изобретает велосипед для своего проекта.

2. Нет единственной подходящей для любого проекта модели ЖЦ.

3. Чем больше опыта у руководителя и команды проекта по работе с разными моделями ЖЦ, тем больше вероятности, что под конкретный проект они выберут наиболее подходящую модель. И уже под нее – разработают наиболее адекватные методы и инструменты планирования, контроля и внесения изменений в проект.

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