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

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

Скотт показывает, что масштабные первоначальные планы редко способны пережить контакт с реальностью, поскольку «на местности» всегда найдутся свои особенности, а у планирующей инстанции неизбежно не хватит знания тонкостей: «…Слишком большое число неизвестных в городском планировании делают любое решение проблематичным или же для него приходится прибегать к героическим предположениям»[10]. Поэтому при составлении планов, драйвером которых является достижение определенных показателей, свойственные таким планам недостатки должны быть уравновешены адаптивным характером самого процесса планирования.

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

Книга Тима Харфорда «Через поражения – к победе. Законы Дарвина в жизни и бизнесе»[11] полна удивительных рассказов о глобальных планах, обернувшихся эпическими бедствиями, начиная с неудачных попыток Российской империи в XIX веке реорганизовать горнодобывающую промышленность, заканчивая тщетными стараниями американских военных контролировать мятежи на территории Ирака и недавним обвалом банковского сектора. Харфорд противопоставляет эти провалы успехам, таким как разработка самолета Spitfire и господство компании Google в интернете, предлагая в качестве инструмента следующий контрольный список:

• Альтернативы: поиск свежих идей и тестирование нестандартных подходов.

• Масштаб тестирования: новые идеи должны тестироваться в небольшом масштабе, чтобы неудачи не превращались в катастрофы.

• Отбор: стремление получать обратную связь и желание учиться на своих ошибках.

Харфорд называет этот контрольный список «принципами Пальчинского» в честь русского инженера Петра Пальчинского, еще в начале XX века сделавшего вывод, что «проблемы, с которыми мы сталкиваемся в реальном мире, более сложны, чем мы думаем», поскольку им свойственно как человеческое, так и локальное измерение и высока вероятность, что эти факторы не останутся стабильными ввиду изменяющихся обстоятельств. Я уверен, что подобные ситуации знакомы любому, кто имеет хоть какой-то опыт участия в реальных проектах по разработке программного обеспечения. Чтобы решать такие проблемы, Харфорд призывает использовать адаптивное планирование и открыть линии коммуникации между планировщиками и теми, кто «работает в поле».

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

Разработка – измерение – обучение

В своей книге «Бизнес с нуля» Эрик Рис предложил новаторский подход к дизайну продуктов, процессу разработки и управлению компаниями. В его основе лежат две важные идеи: получение обратной связи через целенаправленное тестирование гипотез и короткие циклы разработки. В книге Риса не слишком много говорится о том, как выбирать гипотезы для тестирования или как приоритизировать процесс тестирования в рамках цикла разработка – измерение – обучение. Impact mapping прекрасно дополняет идеи экономичного управления стартапами, давая нам возможность визуализировать гипотезы и не упускать из вида общую картину. В результате мы в состоянии решить, какие предположения наиболее целесообразно проверить и какие из них лучше всего соответствуют глобальной цели проекта.

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

Среда, в которой ведется разработка программного обеспечения и реализуются соответствующие проекты, меняется слишком часто, чтобы долгосрочные планы и необходимый дизайн можно было во всех деталях разработать заранее. Итеративные модели принимают этот факт как данность. Тем самым они позволяют учесть появляющуюся в ходе проекта новую информацию и улучшить результаты. Множественные итерации за последнее десятилетие стали основным методом разработки программного обеспечения, особенно в рамках гибких методологий. В масштабах отрасли мы научились гораздо лучше интегрировать в свои продукты информацию, поступившую в виде обратной связи. И тем не менее, если мы действительно хотим вывести принятие бизнес-решений на основе обратной связи на качественно новый уровень, нам еще предстоит пройти достаточно долгий путь.