Задаетесь ли вы иногда вопросом, а ту ли методологию я, как руководитель, выбрал для своего проекта? Верной ли дорогой веду проект к успеху?
Насчет успеха — есть очень интересный отчет «Chaos Report» (пока за 2013й год) от известнейшей группы Standish Group о состоянии дел в управлении проектами со списком факторов, приводящих к успеху выполнения проекта и подробным анализом таких факторов с разных сторон и под разными углами. Рекомендую глубоко изучить его на досуге, запланировав для этого как минимум несколько часов в спокойной обстановке. Также ребята из Стратоплана регулярно проводят опрос «Какая методология используется в вашем проекте» и получают очень веселые и показательные результаты. Реальность же такова, что у меня за почти 10 лет управления проектами ни разу не получалось использовать какую-либо методологию в ее каноническом, книжном, классическом виде. Подозреваю, что у вас дела обстоят похожим образом. Всегда есть какие-то обстоятельства, которые заставляют нас из, к примеру, Scrum’а конструировать зверька под названием ScrumBut (Скрам, Но). Про более тяжелые методологии речь даже не идет. Водопад в чистом виде в software development — вообще довольно большая редкость. Периодически встречаю, что на словах он задекларирован, а в реальности по результатам аудита там что угодно, но не водопад.
Расскажу вам одну историю. Руководил я одной программой проектов (группа проектов), где в контракте было указано, что мы работаем с заказчиком по Fixed Price и у нас водопад. Нюанс был в том, что водопад был на каждый релиз, который в свою очередь длился примерно 4-6 месяцев. Такие себе небольшие водопадики, длиной до полугода. Жестокая реальность показала, что если fixed price в такой схеме еще можно сделать прибыльным, то водопад — совсем никак не приживается. Система была настолько сложная, старая, большая, связанная с еще порядка 30 другими системами, ответственная и часто используемая бизнес пользователями заказчика, что изменения приходили пачками каждую неделю. Мы никак не могли заморозить рамки проекта (scope) на срок даже в 1 месяц, не говоря уже про период в 6 месяцев. С другой стороны, более гибкая методология здесь тоже не подходила. Ответственность за корректную и стабильную работу системы настолько высока, а объем кода и модулей внутри системы настолько велик, что никак нельзя обходиться минимумом документации и хаотичной разработкой — дальнейшая поддержка всего этого хозяйства очень скоро стала бы невозможной (почти так и было, когда я пришел в эту программу).
Что же делать? Как управлять проектами, где из-за высокой сложности, объема, ответственности системы перед заказчиком и величины возможных последствий из-за простоя/поломки, требуется водопад (minimum agility), а из-за частых изменений бизнеса у заказчика требуется что-то вроде scrum’а (maximum agility)? И я нашел решение!
Читать далее Персональная методология проекта →
