Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке - читать онлайн книгу. Автор: Гойко Аджич cтр.№ 14

При составлении impact map мы уже на входе должны иметь правильно сформулированную измеримую цель. Поэтому важно проводить обсуждение в два этапа: на первом мы формулируем цель и подбираем контрольные параметры, а на втором – рисуем саму карту.

В человеческой психологии есть что-то, что заставляет нас полагать, будто бы определенный набор функциональных возможностей и является решением. Большинство моих прошлых проектов начиналось с того, что заказчики предъявляли «список покупок» или функционала, который им хотелось бы иметь в готовом продукте. Бизнес-цели зачастую существовали лишь в голове у руководителя со стороны бизнеса и редко когда были зафиксированы в явном виде или сообщались другим участникам проекта. Такая практика с самого начала обрекает задачи по разработке программного обеспечения на неудачу по двум причинам:

• Лица, ответственные за бизнес-результаты, как правило, не разбираются в технических вопросах. Поэтому крайне низка вероятность, что предлагаемые ими решения являются оптимальными (самыми недорогими, наиболее быстрыми с точки зрения реализации, наименее рискованным или лучшими по любым другим параметрам, которые делают решение идеальным в данном контексте). И если бизнес-цели не сформулированы перед началом проекта в явном виде, то технические специалисты не могут предложить более эффективное решение, даже если оно существует.

• Но даже если первоначальное решение и является правильным, технологический ландшафт меняется столь быстро, что за время жизни проекта исходные гипотезы могут полностью утратить актуальность. Если бизнес-цели остались для разработчиков тайной, то они попросту будут не в состоянии понять, что ситуация изменилась и теперь требуется иное решение.

При создании хорошей дорожной карты первым делом следует убедиться, что у нас есть ясная миссия, с которой согласны все заинтересованные стороны. Лучший способ сформулировать такую миссию – указать бизнес-цели проекта.

Заставьте рабочую группу продумать возможные бизнес-цели и записать их на маркерной доске, чтобы их было удобно обсуждать и сравнивать. Убедитесь, что все заинтересованные лица солидарны в вопросе бизнес-целей, которые должны быть достигнуты в ходе проекта или отдельного этапа. Если возможно, убедите рабочую группу, что в рамках отдельного этапа должна отрабатываться всего одна задача или цель.

Если вы испытываете трудности и никак не можете сформулировать бизнес-цель, начните с заявленного клиентом списка необходимого функционала и определите, на чье поведение он будет влиять и каким именно образом. Затем выясните, почему именно эти изменения в поведении имеют такое важное значение. Возможные в этой связи вопросы могут звучать так: «Почему эта функция так важна?» или «Какую пользу должен принести данный функционал?». Продолжайте спрашивать, пока не выйдете на обсуждение финансовых аспектов проекта. Этот подход напоминает метод «Пяти почему» ^[15], применяемый в бережливых подходах. Крис Мэттс утверждает, что бизнес-цель должна в явном виде отражать намерение сэкономить, заработать или защитить деньги.

Отправной точкой при составлении impact maps являются четко сформулированные цели проекта. Мой опыт подсказывает, что даже в тех случаях, когда бизнес-цели определены (например, «рост числа игроков»), крайне полезно обсудить показатели, которыми будет измеряться их достижение. Обычно это позволяет внести дополнительную ясность относительно достижимости этих целей и распределить их в порядке важности. После того как вы ознакомитесь со «списком покупок» (документы, описывающие границы проекта, списки фич, предлагаемые к реализации пользовательские истории и т. д.) и обозначите потенциальные бизнес-цели, следует дополнительно конкретизировать их, выбрав ключевые параметры.

В книге «Конкурентный инжиниринг» Том Гилб дает ряд ценных советов, касающихся точного измерения целей. В моей практике особенно полезной оказалась упрощенная версия его списка, состоящая из пяти пунктов:

• что мы собираемся измерять (Гилб называет это «объект измерений»);

• как мы будем измерять его («параметр»);

• какова ситуация на данный момент («бенчмарк»);

• минимально допустимое значение, точка безубыточности для инвестиций («ограничение»);

• целевой показатель («цель»).

Обсуждение и сравнение этих параметров для различных влияний приводит к куда более целенаправленной разработке. В качестве примера сравним цели снижения затрат на IT и увеличения числа игроков. В частности, можно утверждать, что небольшое увеличение расходов на IT вполне оправдано, если в результате число игроков существенно возросло. Подвергайте сомнению все – в том числе конкретные целевые показатели и ограничения. Убедитесь, что цели являются реалистичными и могут быть достигнуты за имеющееся в вашем распоряжении время.

Недавно я проводил серию консультаций, в ходе которых выяснилось, что первоначальный список включает порядка 20 целей. Обсудив их вместе с возможными способами измерения, мы вычеркнули 17 из 20 – они оказались не такими уж важными.

Не беспокойтесь, если в ходе первого совещания выяснится, что вы еще не располагаете всеми необходимыми цифрами. Нужно просто назначить ответственных лиц, которые подготовят их ко второму совещанию. В этом одна из причин, почему лучше сразу планировать две встречи, дав командам достаточно времени между ними, чтобы они могли лучше подготовиться. Распространенная ошибка – выбирать в качестве объекта измерения то, что и так легко отслеживается, вместо того, что нам действительно нужно.