Кейс: Решения без проблемы

Новый заказчик обсуждает с нами модернизацию IT-продукта. Пока рассказывает о продукте, вспоминает о проблеме – клиенты уходят в минус и перерасходуют ресурсы без оплаты. Сервис берёт деньги по мере выполнения операции, но предсказать расходы заранее нельзя. По мере рассказа заказчика посещает идея: обрубать доступ и оставлять клиента без результата.

Обсуждение прервали, раскопали проблему пользователей. Выяснилось, что пользователи не понимают, сколько денег остаётся в каждый момент времени, поэтому не могут оперативно принимать решения. Мы предложили показывать им расходы и текущий баланс в режиме онлайн. Заказчик удивился и сказал: «А что, так можно?»

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

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

Давайте вернёмся в магазин и переиграем ситуацию. Вы подходите к кассе, выкладываете покупки. Продавец вам говорит: «Зря вы взяли помидоры „шеди леди“ для рагу из кролика. Этот сорт слишком сладкий, для рагу не подойдёт. Возьмите сорт „маленький принц“, рагу с ними отменное».

Посмотрим, что изменилось. Почему вы благодарны кассиру и хотите его обнять? Он узнал вашу цель. После этого он предложил решение, которое двигает вас к цели, а не просто молча согласился с предложенным решением. Ценность покупки в этом магазине выросла, удовлетворение выросло, вы захотите приходить в этот магазин снова.

Теперь вернёмся к IT. Для выявления целей, понимания пути достижения целей, формирования выбора из решений я рекомендую Impact Mapping [8] :

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

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

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

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

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

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

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

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

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

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

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

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