Александр Бындю - Антихрупкость в IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы уберечь ваши нервы, делюсь выработанной стратегией борьбы с кнопочным мышлением:

1. Когда к вам пришли с кнопочной идеей, спросите себя, почему они принесли такое решение, почему оно не нравится вам, какие вопросы выявят корень проблемы. Только после этого начинайте говорить.

2. Поймите, что коллеги не со зла лезут с кнопочными идеями. Никто не хочет навредить или саботировать. Все пытаются принести пользу.

3. Управляйте на уровне достижения бизнес-целей, а не задач.

4. Ставьте перед командой проблемы, а не приходите с решениями.

5. Делайте короткие итерации (одна неделя или короче), постоянно собирайте обратную связь от команды и от клиентов.

6. Проводите валидацию идей как можно раньше, убивайте идеи до этапа реализации.

Рекомендации одинаково банальные и действенные. Мне в работе помогает.

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