Методология «stage-gate», как «встроенный» способ обеспечения качества в проектах разработки новых продуктов Петр Малоенко, свободный РМР Встреча «без галстуков»

Проблема управления качеством : спецификация vs ценность Современная парадигма управления качеством связывает понятие качества с созданием ценности для клиента. Однако, в условиях всё увеличивающейся сложности целевых продуктов и изменчивости среды, а также нарастающей специализации ролей, часто : -Заказчик ( и, часто, Исполнитель) при начале сотрудничества неясно представляет себе желаемый результат; - Потребности Заказчика изменяются за время выполнения проекта. В такой обстановке человечество породило гибкие методологии. Однако…

Особенности гибких методологий - Предварительные пожелания Заказчика фиксируются в т.н. customer story и не являются окончательными; -Проект представляет собой последовательность ограниченных во времени циклов, в результате каждого из которых выпускается работоспособная версия продукта с постепенно наращиваемым функционалом; - Содержание и качество каждого цикла планируется вместе с Заказчиком в начале каждого цикла и подтверждается вместе с Заказчиком в конце цикла; - В конце каждого цикла командой проекта проводится «разбор полётов» с целью улучшения качества разработки ( т.к. следующий цикл по технологии, как правило, похож на предыдущий)

Преимущества и недостатки гибких методологий ПРЕИМУЩЕСТВАНЕДОСТАТКИ - Иногда, итерации – единственный способ достичь прогресса - Не всякий продукт может быть создан итерационным методом - Заказчик быстро получает простейшую работоспособную версию продукта -Неопределённость количества циклов, конечных сроков, требуемых ресурсов затрудняет планирование - Короткие итерации и постоянная вовлечённость Заказчика снижают риск сделать «не то» -Не всякий Заказчик способен плотно взаимодействовать с командой - Плотные коммуникации и постоянный «разбор полётов» способствуют повышению качества - Особые требования к команде и инфраструктуре

Методологии типа «stage-gate» Проект делится на несколько последовательных фаз (stage) на которых создаются всё более совершенные модели продукта, вплоть до последней, безусловно годной к использованию. Например ( для разработки): концепция, виртуальная модель+прототип, рабочий образец, промышленный образец, серийная продукция. Между фазами помещаются процедуры валидации (gate), когда принимаются решения о вхождении в следующую фазу, а требования к проекту ( по содержанию, качеству, стоимости, срокам и т.п.) могут быть некоторых пределах скорректированы. Длительность фаз различается и определяется временем, необходимым для создания очередной модели продукта, его валидации и корректировки бизнес-кейса и плана проекта.

Примеры Исслед ование Разработка Образец ОПП Производство G2G1G3G4 Разработка новой сложной продукции для массового производства Бизнес- концепция Архитектурн ая планировка Проектирование Строительство Ввод в эксплуатацию G2 G1 G3 G4 Аудит и анализ Разработка решения Пилотно е внедрен ие Промышленное внедрение Поддержка G2G1G4 Автоматизация бизнес-процесса Девелопмент G3 Пром. образец $1000$10000$ ТЭО Вирт. модель+ прототип Рабочий образец Серийный продукт $10000

Процедуры валидации на фазах для проектов РНП После того, как результат фазы получен и протестирован, происходит несколько контрольных ревью : 1. Team Review - обзор модели продукта, его характеристик и рисков на уровне команды проекта. 2. Market Validation – получение обратной связи от потенциальных потребителей или агентов рынка. 3. Design Review – технический обзор модели продукта с участием внутренних экспертов высокого ранга 4. Gate Review – обзор обновлённого бизнес-кейса и плана проекта на уровне бизнес-руководства, принятие решения о судьбе проекта. После каждого ревью продукт может быть отправлен на доработку или полную переработку или даже представлен к закрытию ( на гейте).

«Stage-gate» как компромисс между «водопадом» и agile Критерий«Водопад»Stage-gateAgile Требования Максимально фиксированы в ТЗ на весь проект Фиксированы в ТЗ на весь проект, но уточняются по мере выполнения фаз Фиксируются в как начале проекта, так и в начале каждого цикла Изменения Не приветствуются.Могут вноситься с ограничениями на основании результатов каждой фазы Могут вноситься в начале каждого цикла Готовый к использованию продукт По окончании проекта На последних фазах проекта По истечении нескольких начальных циклов, в конце каждого цикла Срок и стоимость Зафиксированы базовым планом Фиксируются, но уточняются на гейтах Оцениваются приблизительно Вовлечение Заказчика РедкоУмеренно Часто Обязательные процедуры валидации Как правило, в начале и в конце Умеренно, на каждой фазе Много, в каждом цикле Риски внешнего контракта На Исполнителе СбалансированыНа Заказчике

«Встроенное» качество и роль ОУП Таким образом, видно, что часто обеспечение и контроль качества продукта и проекта «встроено» непосредственно в жизненный цикл проекта. Соблюдение процедур жизненного цикла является важнейшим средством обеспечения качества проекта. Это задача Офиса управления проектами. Также, ОУП обеспечивает качество через : - Повышение квалификации РП; - Выравнивание нагрузки на РП и членов проектных команд; - Адекватное управление портфелем проектов; - Обеспечение коммуникационной среды и управления знаниями.

Тайна «проектного треугольника» Срок Стоимость Содержание/ качество Элементарный уровень : Качество Срок Срок Качество Есть ещё один – парадоксальный - эффект : Качество Срок Срок Качество Переделки не съедают время Заказчик не успеет передумать

Спасибо за внимание ! Петр Малоенко 8 (916) ,