Давайте продолжим обсуждение инструментов и методов по соблюдению сроков проектов, учитывая что предыдущий топик вызвал достаточно активную дискуссию и более двухсот человек добавили топик себе в избранное. На этот раз пост будет более унылым, постараюсь дать более подробные рекомендации в текстовом виде.
Следующий набор рекомендаций выглядит так:Убедитесь, что срок действительно жесткий
Не берите на себя проекты с нереальными сроками
Планируйте методом «набегающей волны»
Периодически пересматривайте оценку проекта
Оценивайте проект эмпирически
Привлекайте к первоначальной оценке команду
Убедитесь, что срок действительно жесткий
Самым удивительным моментом многих «супер-срочных» проектов является то, что срок у них не является на самом деле жестким. А результатом является давление на команду, жертвы функционалом и в самом худшем случае качеством. Команде или менеджеру проекта необходимо убедиться, что жесткость срока носит объективный характер, например, дата мероприятия для представления продукта, на которую невозможно повлиять. Примером не жесткого срока может служить ранняя оценка сроков проекта без детального анализа, озвученная руководству: ее необходимо пересмотреть и провести соответствующие переговоры по изменению сроков.
Не берите на себя проекты с нереальными сроками
Еще одним антипаттерном является взятие командой на себя обязательств по реализации проекта с нереальным сроком, причем часто это понятно до старта проекта. Проблема заключается в том, что команда рассматривает такое вынужденное взятие проекта как приказ «сверху» и ответственность за сроки остается только формальная. По неудачному завершению проекта команда скажет: «Мы же вас заранее предупреждали, что сроки выдержать не возможно». Обычно самым верным решением для такого типа проектов, является резкое сокращению объема реализуемого функционала для первого релиза.
Планируйте методом «набегающей волны»
Для больших проектов очень важно иметь грамотный и реальный план работ. Давайте возьмем пример с картой, по которой Михаэль Вольф строил план. Она фактически на всём протяжении была одного масштаба и из-за этого начались проблемы в самом начале проекта. Правильным методом в данном случае было бы планирование «набегающей волной» (Rolling Wave Planning): для первого участка, который мы собираемся пройти мы делаем более подробный план, используем карту с большим масштабом, смотрим фотографии местности, а участки, которые мы пройдем позже — рассматриваем на карте с небольшим масштабом.
Для проектной деятельности в рамках PMBoK такой подход означает более подробную декомпозицию работ в ИСР для первых этапов реализации проекта. В гибких методологиях применяет такой же подход: мы храним элементы беклога с высокой важностью, разбитыми на небольшие «кусочки», а элементы беклога с низкой важностью храним в виде больших эпиков. Т.е. у команды есть подробный беклог на один-два спринта вперед.
С другой стороны то, что мы не расписываем весь функционал проекта позволяет нам избежать Big Upfront Design подхода и долго запуска разработки, не говоря уже про то, что достаточно большая часть требований (макетов дизайна и т.д.) просто «протухнет», когда до нее дойдет очередь.
Периодически пересматривайте оценку проекта
При использовании водопадного подхода необходимо пересматривать оценку сроков завершения в конце каждого этапа работ, а если используется метод критической цепи такую оценку можно делать более оперативно с помощью буфера проекта. В итеративных методологиях такую переоценку рекомендуется делать по завершении очередной итерации.
Дело в том, что оценки сделанные на ранней стадии проекта, как правило содержат очень большое количество неопределенности. Со временем эта неопределенность уточняется (часть рисков снимается) и оценку можно дать более точной. Классической иллюстрацией к вышесказанному является «конус неопределенности»:
Оценивайте проект эмпирически
Оценка на основе скорости работы команда является достаточно точной, поэтому ее стоит использовать во всех проектах, где это возможно. Запустите несколько спринтов и определите, сколько функционала (например, в сторипоинтах) ваша команда делает и посчитайте общий срок завершения проекта. Такое планирование основанное на фактах позволяет получить достаточно точные оценки.
Привлекайте к первоначальной оценке команду
Достаточно часто приходится оценивать проекты на очень ранней стадии. Как было сказано выше такая оценка не имеет ничего общего с действительностью не очень точна. Повысить точно можно, привлекаю к оценки команду (либо ее ядро) с самой ранней стадии, плюс команда будет разделять ответственность за указанные сроки.
Ссылки
Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения
