В шапке
Выбор жизненного цикла для проекта

Выбор жизненного цикла для проекта

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

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

  • Хорошо проработанная модель жизненного цикла проекта позволяет определить иерархическую структуру работ проекта,
  • ЖЦ проекта во многом определяет, какой подход (методологию) для управления проектом выбрать, а выбор подхода повлияет на методы и инструменты планирования и контроля проекта.

Глобально существует 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. Чем больше опыта у руководителя проекта и команды проекта по работе с разными моделями ЖЦ проекта, тем больше вероятность того, что под конкретный проект они смогут выбрать наиболее подходящую для него модель ЖЦ проекта, а под эту модель - наиболее адекватные методы и инструменты планирования, контроля и внесения изменений в проект.

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

Комментарии (0)
Войти как