Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке - [5]
• Это скоростной метод. Один из моих клиентов недавно заметил, что его компании потребовались бы несколько месяцев, чтобы достичь того, что нам удалось всего за два дня. По этой причине метод прекрасно вписывается в итеративные модели, которые в настоящее время начинают широко использоваться при разработке программных продуктов.
По существу, impact maps стоит заниматься просто для того, чтобы помочь себе создавать продукты и реализовывать проекты, которые действительно делают жизнь пользователей лучше.
Что такое Impact mapping?
Impact mapping – это способ визуализировать границы проекта и основные гипотезы, созданные совместными усилиями лиц, принимающих технические и бизнес-решения. Это ментальная карта, возникающая в ходе обсуждения ответов на следующие четыре вопроса:
Цель
Центральная часть impact map должна отвечать на самый важный вопрос: зачем мы это делаем? Это цель, которую мы стремимся достичь.
Может показаться, что стремление в самом начале проекта получить ясный ответ на этот вопрос – всего лишь проявление здравого смысла. Однако мой опыт показывает, что лишь немногие из разработчиков точно знают, какие бизнес-цели преследует заказчик. Иногда их описывают в каком-либо формальном документе, но чаще всего бизнес-цели существуют лишь в головах заинтересованных лиц. Даже в тех редких случаях, когда бизнес-цели доводятся до разработчиков, они зачастую сформулированы весьма смутно.
Исследование, проведенное Гэри Кляйном на материале аварийно-спасательных служб и армейских подразделений, показало, что при осуществлении любой деятельности люди на местах должны понимать конечные цели операции, иначе они не в состоянии правильно реагировать на непредвиденные проблемы. Если очередной релиз или проект в целом позволяет достичь поставленной бизнес-цели, то это успех с точки зрения бизнеса, даже если в итоге разработанный продукт будет отличаться от того, что было предусмотрено первоначально. В то же время, если программный продукт точно соответствует задуманным спецификациям, но при этом не позволяет решить поставленную бизнес-задачу, его следует признать провальным. Это верно даже тогда, когда разработчики не без оснований обвиняют клиента, что он сам толком не понимает, чего хочет.
Поместив ответ на вопрос «ЗАЧЕМ?» в центр impact map, мы получаем возможность убедиться, что все знают, зачем они выполняют те или иные действия. Это помогает командам лучше соотносить свою текущую деятельность с конечной целью, точнее формулировать требования к функциональности и находить оптимальные с точки зрения дизайна решения.
Обозначенная цель дает разработчикам инструмент для пересмотра первоначальных планов по мере поступления новой информации. Поэтому верно сформулированные цели, как правило, соответствуют критериям SMART: они конкретны, измеримы, ориентированы на совершение конкретных действий, достижимы и ограничены во времени.
Цели не должны описывать сам продукт, процесс его создания или устанавливать границы проекта. Они обязаны объяснять, почему данный продукт будет полезен.
Целям следует определять проблему, которую предстоит решить, а не воспроизводить решение. Избегайте включать в описание цели какие-либо конструктивные ограничения, касающиеся готового продукта.
Крис Мэттс предлагает сначала сформулировать, в чем состоит бизнес-ценность проекта, а затем объяснить, каким образом в результате осуществления задумки ситуация изменится, – обозначив при этом цели в качестве этапов постепенного приращения бизнес-ценности. Это особенно эффективно, если у вас уже есть набор ключевых показателей, по которым будет оцениваться эффективность данного продукта.
Для коммерческих продуктов и организаций старайтесь формулировать цели таким образом, чтобы связь с зарабатыванием денег была очевидной.
• Открыть торговлю ценными бумагами в Бразилии в марте следующего года.
• За три месяца увеличить конверсию пользователей на 20 %.
Действующие лица
Первый уровень impact map дает ответы на следующие вопросы: на чье поведение мы хотим воздействовать? Кто сможет произвести желаемый эффект? Кто способен помешать? Кто является потребителем или пользователем нашего продукта? На кого наш продукт повлияет? Это и есть те действующие лица, чье поведение может сказаться на результатах проекта.
Джеральд Вайнберг определяет качество как «ценность, предоставляемую кому-либо». Чтобы обеспечить высокое качество результатов, мы сначала должны выяснить, кто эти люди и какую ценность они хотят обрести, воспользовавшись продуктом или результатами нашего проекта. В дополнение к тем, кто непосредственно получит ценность от пользования нашим программным продуктом, мы также должны учитывать интересы множества других людей, чьи решения будут так или иначе влиять на успех продукта или исход проекта. Программное обеспечение работает не в вакууме, и редко когда изначально удается поставить под контроль поведение всех действующих лиц, так или иначе с ним связанных.
У людей есть свои собственные потребности, цели и предпочтения, которые имеют значение, если мы действительно хотим достичь какой-либо бизнес-цели. И тем не менее большинство моделей управления акцентирует внимание на конкретных функциях программного обеспечения, а не на людях, для которых оно будет полезным. Затем где-то в середине работы из ниоткуда появляется новое действующее лицо, и все коренным образом меняется. Как вариант, кто-то с достаточными полномочиями может вообще неожиданно приостановить разработку.
