1 ноября
Бесплатный аудит кадровых и бухгалтерских процессов – спецпредложение от ООО «СМАР ЛИГАЛ»
4 | 5 | 4 | 6 |
Наш эксперт Максим Якубович рассказывает про две модели жизненного цикла проекта и анализирует плюсы и минусы каждой из них.
На мой взгляд, жизненный цикл проекта (ЖЦ) служит следующим целям:
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. Чем больше опыта у руководителя и команды проекта по работе с разными моделями ЖЦ, тем больше вероятности, что под конкретный проект они выберут наиболее подходящую модель. И уже под нее – разработают наиболее адекватные методы и инструменты планирования, контроля и внесения изменений в проект.
Мой совет будет таким: анализируйте опыт выполненных проектов, чтобы лучше понимать, какая модель ЖЦ и в каком случае лучше подойдет. И продолжайте изучать эту тему. Возможно, кто-то в данный момент описывает новую модель ЖЦ проекта для вашей отрасли и в скором времени собирается опубликовать ее для нас.
1 ноября
Бесплатный аудит кадровых и бухгалтерских процессов – спецпредложение от ООО «СМАР ЛИГАЛ»
1 ноября
МТБанк открыл phygital-офис в центре Минска. Что это за отделение и почему там нет касс?
1 ноября
Открыта регистрация на Форум по управлению интернетом Belarus IGF-2024
31 октября
Форум для белорусского бизнеса "Лига экспорта" пройдет в Минске 10 декабря
30 октября
BFS 17-й сезон: живая музыка, дух путешествий и инновационные гаджеты
28 октября
10 лет с VOKA: от небольшой ТВ-платформы до онлайн-кинотеатра номер один в Беларуси
28 октября
Запускаем акцию — «Заяви о себе с Про бизнес»!
24 октября
Аккредитив с дисконтированием от Белагропромбанка: деньги за товар сразу на счете