Рис. 4. Разделение проблем и решений

Техника изучается за пару дней. С помощью Impact Mapping мы прокладываем путь от решений до цели, расставляем приоритеты, отсекаем Pet Feature, которые идут со стороны бизнеса и со стороны команды. Единственная сложность – процесс создания Impact Mapping: он требует навыков эффективной коммуникации.

Кейс: Требуется больше всплывающих окон

Представьте IT-отдел внутри компании. Руководители отдела маркетинга, финансов и прочих ставят ему задачи. Приходит начальник, который отвечает за точки продаж, и требует добавить всплывающее сообщение раз в 10 минут на рабочем месте. Работников на местах обяжут нажимать «ОК» в модальном окне каждые 10 минут, чтобы понять, на месте работник или нет. Задача как задача; IT-отдел взял да и сделал. Прошло время. Работники на местах ужились с новшеством.

В IT-отдел пришёл начальник маркетинга и попросил добавить всплывающее сообщение, чтобы работник выходил на улицу и раздавал листовки. Сообщение по задумке всплывает каждые 30 минут, в результате должны повыситься продажи. Задача как задача; IT-отдел взял да и сделал.

На местах это вылилось в противоречивый сценарий. Работник видит сообщение о том, что надо идти на улицу и раздавать листовки. Он выходит и раздаёт, а в это время всплывает сообщение: «Ты на месте?»

Почему так произошло? Никто не контролировал целостность системы. Многоголовый Product Owner приносил задачу, разработчики брали задачу, не создав целостной картинки поставки ценности, поэтому они не увидели противоречий.

Кейс: Зачем делаем?

Заказчик пришёл с идеей сделать приложение для курьеров. Заказчик – федеральная компания, сотни филиалов по стране. Цель продукта – оптимизация работы курьеров.

До работы с нами у проекта накопилась полугодовая история. Заказчику сделали ТЗ, реализовали часть мобильного клиента, но не сделали серверную часть. С этой историей заказчик пришёл к нам. Мы начали проект по нашему процессу[9], и уже к концу Customer Journey Mapping заказчика осенило. Они поменяли бизнес-модель, запустили ряд экспериментов в бизнесе и обещали вернуться к нам через три месяца. В итоге вернулись через полгода с перестроенной компанией, которая стала готова для создания нового продукта. Продукт мы сделали и успешно запустили. Мы считаем это успехом, так как не позволили потратить время на что-то бесполезное.

Если цели IT-отдела или IT-продукта не сформулированы, то это благодатная почва для кнопочных решений. Перефразируя фразу из монолога Жванецкого[10]: Если нет цели, то куда бы ты ни шёл – получается вперёд.

Когда мы берём задачу, то сопоставляем её стоимость с отдачей в достижении цели. А если цели нет? Значит, и соизмерять не с чем. Отсюда рождается стиль работы, при котором задачи реализуются, потому что прикольно эти задачи реализовывать. В таких отделах разработки кипит жизнь, фичи добавляются, идут непрерывные релизы. При этом бурном движении результат не просматривается.

Кейс: Покажем, потому что можем

Продукт – SaaS-инструмент для партнёров топовой e-commerce России. Диалог с IT-подразделением заказчика:

– Давайте выведем договоры в интерфейсе, – говорит разработчик со стороны заказчика.

– Чтобы что? – отвечаем мы.

– Они уже лежат в БД, можно легко вывести.

– Как это поможет достигнуть целей продукта?

– Без договоров невозможно заплатить!

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

В таких случаях помогает только возврат к целям проекта и фильтрация с помощью Impact Mapping (раздел l, глава 2).