Библиотека управления

Impact Mapping: карты влияния для эффективных программных продуктов и проектов

Гойко Аджич Глава из книги «Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке»
Издательство «Альпина Паблишер»

Три ключевых функции

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

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

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

Стратегическое планирование

Impact mapping является отличным способом привлечь к совместной работе руководителей технического и бизнеснаправлений с самого начала проекта или этапа. Это позволяет сформировать одинаковое понимание границ проекта с обеих точек зрения.

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

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

При стратегическом планировании для эффективного использования impact maps требуется выполнение следующих двух условий:

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

Требования к качеству

Impact map наглядно показывает, какие влияния с точки зрения бизнеса должны быть реализованы при помощи разрабатываемого программного продукта. Благодаря визуализации можно определить требования к ожидаемому качеству на уровне продукта как единого целого и гарантировать, что все участники проекта понимают эти требования одинаково.

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

Чтобы эффективно использовать impact maps для определения требований к качеству, необходимо согласие заинтересованных сторон о том, что:

  • цель разработки — поддержка желательных изменений
  • в поведении действующих лиц;
  • контрольные показатели действительно выражают ожидания заинтересованных сторон в части этих изменений.

Управление дорожными картами

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

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

Чтобы использовать impact map для управления дорожными картами, необходимы следующие условия:

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

Impact maps позволяют решать типичные проблемы

Одна из уникальных особенностей метода impact mapping, отличающая его от остальных подходов, — возможность с его помощью избежать наиболее распространенных проблем, возникающих как на стадии планирования, так и в ходе разработки.

Расползание границ проекта

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

Неверные решения

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

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

«Любимчики» или ненужная функциональность

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

Неверные исходные предположения

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

Возможность избежать случайных приоритетов

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

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

Помимо прочего, в крупных организациях impact maps помогают довести общую картину до многочисленных заинтересованных лиц, которым нужно координировать свои решения. Это способствует синхронизации их приоритетов и позволяет находить компромиссы в тех случаях, когда их ожидания не могут быть одновременно удовлетворены в полном объеме.

Решение бизнес-задач, а не функционал как таковой

Джон Макманус и Тревор Вуд-Харпер, в течение семи лет исследовавшие деятельность коммерческих IT-компаний в странах Евросоюза, составили следующий список пяти основных причин, почему IT-проекты терпят неудачу:

  • Общие причины, связанные с состоянием бизнеса.
  • Бизнес-стратегия потеряла актуальность.
  • За время разработки программного продукта в компании изменились бизнес-процессы.
  • Неудовлетворительное управление требованиями.
  • Потенциальные преимущества от разработки продукта не были четко обговорены или были завышены.

Очевидно, что многие из существующих методов управления проектами и качество коммуникации относительно требований к готовому программному обеспечению не в состоянии в полном объеме обеспечить достижение необходимых бизнес-результатов. Эта проблема характерна не только для IT-индустрии. Как показали исследования поведения командующих офицеров и командиров танковых взводов армии США, если сообщать личному составу только ответы на вопросы «что» и «как», невозможно должным образом подготовить его адекватно реагировать на непредвиденные проблемы. Однако именно этим грешат многие модели, использующиеся в настоящее время для управления требованиями. В быстро меняющихся ландшафтах (таких как разработка программных продуктов) гораздо важнее дать участникам ответы на вопросы «зачем» и «чего следует опасаться».

Именно к этому и стремятся различные методики управления требованиями на основе целей. Цель таких методик — переориентировать руководство проектами с разработки заранее известного списка конкретного функционала на поддержку бизнес-задач и желаемые изменения в поведении пользователей. Конечно, эти идеи вовсе не новы, но все же наибольшую популярность они обрели в начале 2000-х годов, побудив, в частности, интерес к этой проблематике в академических кругах — особенно если говорить о модели I*6. Но на мой взгляд, эта модель слишком сложна и по этой причине вряд ли получит широкое распространение.

Чтобы предотвратить расползание границ проекта во время разработки программы Excel для компании Microsoft, Скотт Беркун использовал простой мэппинг между целями, функциями и требованиями. Он убедил заинтересованные стороны сократить количество бизнес-целей, поставленных в рамках одного релиза. Затем он обозначил границы проекта, настаивая на том, чтобы каждая функция была увязана с соответствующим требованием, а каждое требование — с целью, которую оно поддерживает. Беркун позднее писал, что такой мэппинг позволил командам разработчиков принимать эффективные решения следующих типов: какие элементы функциональности следует добавить или исключить; как переопределять приоритеты при изменении бизнес-целей; какие именно элементы функциональности являются критически важными для достижения успеха.

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

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

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

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

Постановка измеримых целей

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

Ключевым признаком здесь является измеримость — если цель измерима, то легче определиться и с остальными обязательными элементами. Например, формулировка «рост числа пользователей» является некорректной. Очевидно, что решение, позволяющее в течение года увеличить количество пользователей на 50%, будет радикально отличаться от решения, которое позволит увеличить их количество на 200% в течение двух месяцев. После того как мы договоримся, чего именно, в каком количестве и как быстро мы хотим достичь, становится гораздо легче оценить, является ли данная задача вообще осуществимой. В книге «Конкурентный инжиниринг» (Competitive Engineering) Том Гилб показывает, каким образом выбор измеримых целей помогает убедиться в их правильности и сфокусироваться на их реализации. Именно акцент на измеримости позволил мне остановить несколько обреченных на провал проектов прежде, чем они начались; в конечном итоге удалось синхронизировать ожидания всех заинтересованных сторон и сформулировать новые цели, которые были одновременно и измеримыми, и реалистичными.

Impact maps хорошо вписываются в идеологию SMART, потому что они помогают нам подвергнуть тесту на измеримость не только основную бизнес-цель, но и влияния, которые мы стремимся поддержать.

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

Как избежать «Тщеславных метрик»

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

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

Параметры двухуровней

Параметры — чрезвычайно острый инструмент. Они отлично помогают нам фокусироваться, но могут принести и огромный вред, если мы сделаем акцент не на том, на чем нужно. Распространенная проблема с измерениями состоит в том, что они способны превратиться из средства контроля в самоцель. Джеймс Скотт, автор книги «Благими намерениями государства», предупреждает, что между параметрами разных уровней возможен конфликт: например, конфликт между показателями, обеспечивающими понимание и контроль со стороны людей, находящихся «снаружи» измеряемого процесса, и показателями, имеющими важное значение для людей «внутри» процесса, на которых они влияют напрямую. Приводя примеры из разных областей — от строительства крупных городов до научного лесоводства, Скотт показывает, что использование отдельных параметров для целей внешнего контроля часто делает систему слишком сложной и непонятной для тех, кто находится «внутри» проекта, приводя к серьезным неудачам. Например, несколько экономических катастроф при организации крупных ферм были вызваны тем, что основное внимание уделялось показателям, связанным с размерами участков и посевными квотами, а также разделению участков на более мелкие для того, чтобы правительственным организациям было их легче контролировать. Оказалось, что планы зачастую были просто нереализуемыми, поскольку на бумаге сельскохозяйственная земля выглядела как аккуратные участки прямоугольной формы, в то время как в действительности на ней могли быть реки и болота, а также различные типы почв. «Внешние» параметры были не в состоянии учесть факторы, важные для фермеров, например, такие как потенциальная урожайность, выживаемость различных сортов и потребности разных культур в разном уходе. Скотт также показывает, как проекты с преобладанием «внешних» параметров терпят неудачи, поскольку участники, занятые решением своих частных задач, продолжают фокусироваться на этих показателях даже в тех случаях, когда это наносит прямой ущерб достижению главной цели.

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

Адаптивное планирование

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

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

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

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

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

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

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

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

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

Итеративная разработка

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

В докладе, опубликованном консалтинговой компанией Forrester Research, утверждается, что большинство организаций придерживается идеологии гибкой разработки только для решения технических задач — при этом принятие бизнесрешений остается вне рамок процесса и это ведет к значительным упущенным выгодам. Многие организации применяют схему, которую Дэйв Уэст назвал Water-Scrum-Fall. На первой стадии до начала разработки принимается большая часть бизнес-решений, на второй происходит собственно итеративная разработка, а завершается все долгим процессом утверждения бизнес-результатов.

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

Целостное видение

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

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

Более эффективная приоритизация

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

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

Итеративная разработка итеративная, а не инкрементальная разработка

Еще одна типичная ошибка, которую делают команды, состоит в том, что они разрабатывают продукт фрагмент за фрагментом, но бизнес-ценность возникает только в конце проекта, когда все готовые части соберутся вместе. Широко известен пример «Моны Лизы», с помощью которого Джефф Паттон иллюстрирует разницу между инкрементальной и итеративной разработкой.

Impact maps позволяют разделить проект на отдельные ветви и работать над отдельными влияниями, заставляя нас думать о том, как их быстро реализовать, и удерживая разработку в истинно итеративном режиме.

Пользовательские истории

В современных гибких методологиях стандартом при управлении проектами де-факто являются пользовательские истории. Они нужны, чтобы определить границы проекта (не привлекая чрезмерные усилия к предпроектному анализу) и обеспечить гарантии, что на каждом этапе проекта будет создана очевидная бизнес-ценность.

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

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

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

Пользовательские истории должны быть честными

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

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

Impact maps помогают сохранить пользовательские истории честными — поскольку каждая история должна занять свое логичное место на карте. Но, чтобы мы смогли найти для нее это место, в ней должно быть указано соответствующее заинтересованное лицо и желательное влияние. Это заставляет участников проекта более тщательно продумывать пользовательские истории и точнее их формулировать. Если для пользовательской истории на карте не находится подходящего положения, то, по всей вероятности, ее следует исключить из текущего цикла разработки.

Дизайн-мышление

Дизайн-мышление — это подход к решению проблем, использующий творческое мышление и ставящий себе целью стимуляцию инноваций и обеспечение роста бизнеса.

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

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

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

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

Кроме того, impact maps могут содействовать в использовании четырех из десяти ключевых инструментов дизайнмышления, перечисленных Жанной Лидтка и Тимом Огилви в книге «Думай как дизайнер: Дизайн-мышление для менеджеров»:

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

Эффективные совещания

По мнению Дэвида Сиббета, существует три причины, почему визуализация делает совещания более эффективными:

  • Значительно повышается вовлеченность, поскольку участники обсуждают идеи в наглядном графическом представлении.
  • Мышление происходит на более высоком уровне («общая картина»), что позволяет группе легче выявлять закономерности, сравнивать имеющиеся идеи и находить новые.
  • Улучшается групповая память, поскольку результаты совещания фиксируются в виде картинок, по которым впоследствии легче отслеживать исполнение.

Сиббет утверждает, что визуализация делает команды умнее: «Визуализация добавляет 80 пунктов к групповому IQ», поскольку она высвобождает энергию, интеллект и творческие способности участников совещания.

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

Говоря о продуктивности совещаний, еще одним интересным аспектом impact maps является сходство вопросов, задаваемых при их составлении, с вопросами, используемыми в модели командообразования по версии Гибба-Дрекслера-Вайсборда. Еще в 1960-х годах Джек Гибб, Марвин Вайсборд и Алан Дрекслер предложили модель построения команд, базирующуюся на результатах исследований групповой динамики и организационного развития. Они структурировали свою модель вовлеченности вокруг четырех основных вопросов: «зачем мы здесь?», «кто ты?», «что мы делаем?» и «как мы собираемся сделать это?». Их модель помогает синхронизировать цели команд с целями организации и напрямую коррелирует с порядком обсуждения при создании impact maps. На практике это означает, что сама структура карт непосредственно способствует продуктивному обсуждению и сплочению отдельных игроков в группу, объединенную общей целью.