Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке - [21]
Предварительные итоги
Impact maps вместе с измерением контрольных показателей позволяют повысить сосредоточенность проектов на целях, синхронизировав их с глобальными стремлениями организации. Но именно поэтому impact maps могут превратиться в очередную ловушку, которая приведет к провалам, сравнимым с провалами в городском строительстве и сельском хозяйстве, от которых предостерегает Джеймс Скотт. Он показывает, каким образом планы, сфокусированные на достижении одного конкретного результата (как правило, коммерческого характера) поначалу имеют все шансы преуспеть («нельзя отрицать чрезвычайную силу подобного подхода для увеличения урожаев»). Однако при этом возникают «слепые пятна» по отношению ко всему, что осталось вне суженного поля зрения проектантов, в частности, долгосрочные результаты и влияние, которое оказывается на третьи стороны. Такие проблемы, как правило, остаются незамеченными до тех пор, пока они не начинают негативно влиять на изначальные цели проекта. Но в этот момент часто уже слишком поздно что-либо менять.
Чтобы избежать этой ошибки и получить от impact maps максимальную отдачу, рекомендуется использовать их для управления итеративной среднесрочной разработкой: отдельными компонентами продукта и отдельными этапами проектов. Все время между совещаниями, посвященными актуализации карт, необходимо отcлеживать вероятные влияния, которые мы можем непреднамеренно оказать на третьи стороны, а также долгосрочные эффекты, которые, возможно, выпали из нашего поля зрения, ограниченного картой. Не забывайте, что связи, показанные на impact map, являются всего лишь гипотезами, которые могут в итоге оказаться неверными. Все это похоже на то, как если бы вы пользовались реальной картой незнакомой местности: сначала вы проходите некоторое расстояние в заданном направлении, после чего сверяетесь с картой, чтобы понять, где вы в конечном счете оказались. Измерение расстояния, на которое вы продвинулись к цели, помогает решить, стоит ли продолжать движение в избранном направлении или пора предпринять какие-либо другие действия. После того, как поставка первых компонентов функциональности состоялась, необходимо измерить результаты. Если добавленная функциональность не позволила получить ожидаемые итоги, это указывает на неверные исходные гипотезы. Если же гипотеза подтвердилась, то инвестиции в разработку данной части карты следует продолжить.
Если цель состояла в том, чтобы помочь игрокам приглашать своих друзей, проверьте, действительно ли они их приглашают. Если ответ на этот вопрос «да», то вы сняли риск, что исходная гипотеза была неверна, и теперь можете безопасно инвестировать больше усилий в это направление. Создайте дополнительные возможности для рассылки приглашений и снова оцените достигнутый эффект. Не забудьте при этом убедиться, что верна и гипотеза более высокого уровня. Если игроки приглашают друзей и друзья присоединяются к нашей игре – все хорошо. Но если они получают приглашения, но не включаются в игру в тех количествах, на которые вы рассчитывали, то вся идея, что новая функциональность, связанная с рассылкой приглашений, приведет к росту числа игроков, должна быть поставлена под сомнение. Относитесь к таким ситуациям как к экспериментам, продемонстрировавшим отрицательный результат. Серьезно задумайтесь о том, чтобы отказаться от функциональности, не обеспечившей того эффекта, на который вы рассчитывали.
По мнению Тома Гилба, стоимость каждой итерации в ходе проекта не должна превышать 2 % от общего объема инвестиций. Эрик Рис рекомендует проводить регулярные совещания, в центре внимания которых должен быть вопрос о том, стоит ли придерживаться избранного курса или необходимо коренным образом изменить направление разработки. С самого начала договоритесь с командой, как часто вы собираетесь оценивать, насколько вы продвинулись к цели: например, раз в неделю или раз в месяц. Постарайтесь сразу определить, какого рода события должны указывать на необходимость поддержания или изменения курса и в какие сроки.
Если разработка не достигла минимальных целевых показателей, пора переосмыслить стратегию. Обсудите, не следует ли изменить технические способы реализации необходимых влияний или переключиться на работу над другой областью карты. Проанализируйте, не проявились ли какие-либо непредусмотренные долгосрочные последствия, не возникли ли какие-либо закулисные действующие лица или сторонние влияния, которые не были учтены в ваших планах. Если вы несколько раз подряд не смогли разработать необходимые элементы функциональности, проанализируйте, является ли ваш план вообще осуществимым и следует ли вам вообще продолжать инвестиции или лучше остановиться. Не бойтесь пересматривать ключевые цели и контрольные показатели. Дуглас Хаббард рекомендует подходить к измерениям итеративно и вносить корректировки в объект измерений в зависимости от результатов.
И наконец, если вы уже добились ожидаемой цели, остановитесь. Не имеет значения, что израсходован не весь бюджет – так даже лучше. После того как вы достигнете финальной контрольной точки, этап следует считать завершенным независимо от технического способа, которым вы решили задачу. Пора провести совещание с участием принимающих решения лиц, обсудить
