Исторически сложилось, что я больше сторонник четких планов. Waterfall и PMI подход мне близки по духу, хотя не чужды и некоторые аспекты Agile.
Так вот, начинается проект и артефакт, доказательство того, что проект существует это устав проекта. Для тех кто мало знаком или незнаком поясню, что это за зверь. Согласно идеологии PMI это документ, который описывает верхнеуровневые цели, сроки, бюджет, риски, ресурсы, закупки, дает формальные полномочия менеджеру проекта, а также, что немаловажно определяет название проекта.
Обычно такой документ готовит менеджер проекта, согласовывает со спонсором, заказчиком и другими ключевыми заинтересованными сторонами.
Так вот, на счет названия . В одной из фирм, где я работал, не было четкого определения, что такое проект. То есть была некая деятельность, некий поток, который назывался проектом, но по факту этим не являлся. Это было допущение. Окей, давайте назовем это проектом и как минимум определимся с названием, чтобы все понимали о чем мы говорим. С названиями была путаница, когда спонсор говорил — «Какой прогресс по проекту интеграции решений?», то руководитель направления и менеджер думали каждый о своем. Руководитель направления называл этот проект «интеграция клиентов», а менеджер проектов «оптимизация БД». Каждый думал на своем уровне.
Далее. У Agile и Scrum нет бюджета и сроков даже верхнеуровневых, т.к. все гибко и может поменяться в любой момент. Да, Agile может оценить примерный срок завершения, но только лишь после нескольких спринтов, когда будет оценена производительность команды. Но цели, то есть. Мы же знаем, что мы хотим сделать.
Приведу пример. Есть две команды разработки. У обеих одинаковый проект — разработать мобильное решение для контроля качества продуктов питания.
Команда А работает по Waterfall. Команда Б работает по Scrum. Разные подходы к планированию и разработке. Но цель одна. Так почему бы на старте ее не зафиксировать? Какова вероятность, что команда Б посреди спринта поймет, что клиенту не нужно приложение для контроля качества, а нужно приложение для записи футбольных матчей? Очень мала. С большей вероятностью они все таки придут к изначальной цели.
С названием, сроками, бюджетом более или менее понятно. А что с рисками?
PMI относится к этому достаточно формально, я писал об этой в одной из статей. На мой взгляд, процесс управления рисками это довольно самостоятельная вещь. Поясню, что я имею в виду.
Процесс управления рисками состоит из этапов:
1) Идентификация
2) Анализ
3) Планирование
4) Мониторинг
По сути, это итеративный процесс. Его можно применять и в операционной деятельности и в Agile.
При старте проекта, существует один глобальный риск — проект может провалиться. Так почему бы не оттолкнуться от этой мысли и сделать так, чтобы этого не случилось? Да на старте пока мало данных. Но на то они и высокоуровневые риски, чтобы показать заинтересованным сторонам, что может пойти не так.
Итого, что мы имеем — устав проекта это документ, который позволяет всем ключевым сторонам договориться об одной терминологии, о глобальных целях, о высокоуровневых рисках. Все понимают куда мы идет, чего мы хотим достичь и что может случиться.
