Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 13)
В случае если в проекте обнаруживается худший сценарий – политический конфликт между стейкхолдерами, – применяется метод «Проект смерти».
Политический конфликт между стейкхолдерами – это ситуация, когда группировка, объективно (по KPI) заинтересованная в провале проекта, имеет сопоставимый аппаратный вес по сравнению с группировкой, заинтересованной в его успехе. Поскольку оценка аппаратного веса всегда неточна, существует реальный риск неудачи проекта по политическим мотивам с возложением ответственности на ПМ и команду разработчиков. В этом случае ПМ должен четко разграничить сферы ответственности путем официальной фиксации своей позиции.
1. Пишется служебная записка (или другой официальный документ) о том, что наступление «крайне маловероятного события Х» (которое ПМ ожидает в случае реального возникновения политического конфликта) является угрозой успешности проекта.
2. Команде открыто сообщается, что в проекте возможен форс-мажор, который очевиден ПМ и наступление которого можно будет предсказать заранее.
3. Всем аффилянтам, заинтересованным в успехе проекта (прежде всего – потенциальным потребителям), сообщается, что существует риск «события Х», которое может воспрепятствовать созданию замечательного, всеми ожидаемого продукта.
Результат. ПМ «играет на стороне проекта» и пытается изменить настроения стейкхолдеров в пользу проекта («сведем счеты в другой раз, тут, кажется, намечается успех, который всем пригодится»).
Во всех остальных случаях потенциальный повод для конфликта может быть устранен, и поэтому он вписывается в качестве ограничения (например, «в проекте не должно быть дизайнера») в общую таблицу ограничений.
В случае если повод не может быть устранен (личный конфликт, вызванный прошлыми событиями), необходимо избегать его путем использования других, не столь токсичных ресурсов. Например, если заранее известно, что один из разработчиков точно не сработается с другим, от кого-то из них следует отказаться. Или когда становится ясно, что поставщик бесплатного ресурса может перекрыть кислород, если его пожелания к продукту не будут выполнены, от такого бесплатного ресурса также следует отказаться.
Технические ограничения – это перечень того, что точно не надо делать в проекте с технической точки зрения. Многие из этих ограничений очевидны только для отдельных аффилянтов («технология ХХХ не работает – проверено на трех проектах»), поэтому с целью их выявления следует провести специальный опрос.
Отдельно следует проанализировать ценности каждого стейкхолдера (а в идеале – и остальных аффилянтов) на предмет наличия жестких ограничений по какому-либо из факторов PESTLE. Например, стейкхолдер может иметь убеждения в отношении отдельных социальных групп («Этот продукт будут покупать лесбиянки? На фиг такой продукт!»), экологии («наш продукт не должен загрязнять окружающую среду») или политики («с помощью такого продукта люди смогут обмениваться не прослушиваемыми сообщениями, что подорвет нашу демократию»). Все эти ограничения вписываются в общую таблицу.
В соответствии с принципом устранения повода соответствующий раздел анализа продукта по PESTLE в дальнейшем просто
В этом разделе анализируются экономические интересы аффилянтов. Для стейкхолдеров это бюджет проекта, себестоимость производства продукта, стоимость рекламы и маркетинга, динамика окупаемости и все прочие элементы бизнес-плана. Для остальных аффилянтов – их личные экономические интересы, то есть денежная и неденежная цена ресурсов, ожидания динамики зарплаты и бонусов и т. д.
Интересы стейкхолдеров в части сроков проекта и сроков выполнения отдельных этапов записываются как ограничения во времени. Интересы других аффилянтов, связанные с какими-либо сроками (например, срочные контракты с поставщиками, консультантами и т. п.) также вписываются в этот раздел.
В экономических ограничениях были прописаны суммы затрат за весь период в обезличенной форме. Финансовые ограничения связаны с конкретизацией бюджета: откуда деньги, как и у кого их брать, где хранить, каким образом расходовать. Например, один стейкхолдер выделяет на проект людей, а другой – деньги; если в процессе выяснится, что разработчики «справляются и так», возникнет повод сэкономить. Поэтому появляются ограничения вида «один миллион – если сразу, и только полмиллиона, если потом». В идеале под проект должна составляться схема финансирования с четко расписанными траншами, условиями их выделения и действиями в случае невыделения.
Конечным результатом анализа ресурсов является полная организационно-ресурсная схема проекта с ограничениями. Как и ранее, эта схема содержит сведения из матрицы 3 × 3, только теперь все ее клеточки заполнены.
Сама схема оформляется в удобной самому ПМ форме и отправляется в архив. Для дальнейшей работы сохраняются только выбранные из схемы критически важные компоненты: требования, ограничения, потенциальные конфликты и карта доступа к ресурсам.
С этого момента команда проекта сформирована, правила игры для совместной деятельности заданы (организационно-ресурсная схема), ресурсы и пути доступа к ним определены. Теперь (и только теперь) можно приступать к собственно проектированию.
2. Продукт
Второй по значимости риск в любом проекте (после конфликта между стейкхолдерами) – выпуск продукта, который не будет востребован потребителем. Как уже говорились ранее, от 80 до 95 % новых продуктов терпят неудачу при выходе на потребительский рынок; в заказных разработках процент неудач меньше, но главным образом потому, что такие разработки принято оплачивать даже при довольно посредственном результате.
Поэтому современная разработка продукта – это прежде всего кропотливое и методичное изучение потребителей. Успешный продукт – это не то, что разработчик знает, как сделать, а то, что потребитель хочет купить. DaShe предоставляет в распоряжение ПМ набор методов, формализующих изучение потенциальных потребителей и позволяющих в буквальном смысле слова
Подход DaShe существенно отличается от традиционного способа разработки продукта, при котором первоначальная идея сразу же переводится в функции, а они оцениваются по затратам на реализацию и потенциальной прибыли. Разработка продукта, начинающаяся с
Цель разработки продукта в DaShe – формирование бэклога, функционального описания минимально жизнеспособного продукта, который на следующих этапах будет реализован (разработка), а потом много раз переделан (
Несмотря на популярность (в литературе) идей о разработке продуктов специальными продуктовыми командами, в DaShe предполагается, что созданием бэклога занимается сам ПМ, привлекая к отдельным операциям уже набранную команду проекта. Связано это с тем, что методы разработки продукта хотя и трудоемкие, но доступны любому грамотному человеку, а их результативность зависит не от личных талантов исполнителя, а от его мотивации и работоспособности.
Создание бэклога представлено в DaShe как последовательный процесс конкретизации описания продукта; однако помимо перечисленных ниже этапов от ПМ в ходе работы над продуктом потребуется и применение части методов из раздела «Разработка». Почему? Да потому, что к любому из этапов может (и, вообще говоря, должна) быть привлечена команда проекта, а в этом случае возникает совместная работа, требующая планирования, организации, мотивации и т. д. Соответствующие методы содержатся в разделе 3, в который по мере ознакомления с разделом 2 следует периодически заглядывать.