Антихрупкость в IT

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

Торопыги

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

Как быть, если вы заметили за собой недуг торопыжничества? Во-первых, осознайте, что невозможно знать все ответы. Придумывание налету – не признак профессионализма. Во-вторых, брать паузы в переговорах и на совещаниях – норма. Берёте паузу, идёте думать. Приносите с собой варианты решений, риски по каждому, плюсы и минусы[1].

Решалы

Решалы – ребята-профи, которые в IT собаку съели. Спроси – сразу ответят. Хотя и не факт, что за плечами у них серьёзные проекты и десятки лет опыта.

Для Решалы входящие проблемы и задачи видятся типовыми, уже решёнными. По фреймворку Cynefin Framework[2] Решалы видят мир в квадратике Obvious, ну, максимум – в Complicated. Другими словами, у них всегда есть готовое решение, надо только выбрать категорию проблемы. Не понимая того, что они лишают себя шанса преподнести бизнесу проработанное решение и вырасти на новой задаче.

Бизнес-решала пострашнее Разработчика-решалы, потому что любит проталкивать Pet Features в продукт. Pet feature – это такие любимчики, как милые домашние питомцы, цель их существования в продукте неясна, но они почему-то по душе тому, кто платит за разработку.

Спасители

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

Если вы решили, что это ситуационное лидерство[3], о котором так много сказано в гибких подходах разработки, то будете правы. Только не всё ситуационное лидерство одинаково полезно. Проблема возникает, когда во время подъёма человек перестаёт слышать других и адекватно оценивать ситуацию. Его решения становятся ультимативными: он на войне, он Спаситель, он вершит судьбы.

Если вы заметили Спасителя в проекте, постарайтесь вывести человека из этого состояния. Медленно, но непреклонно и жёстко. Чем раньше, тем лучше. Впереди его ждут сожаления о решениях, принятых в состоянии аффекта.

Я – могучий генератор кнопок

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

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

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

С источниками кнопочного мышления разобрались. Теперь узнаем, что с ними делать. Почему мы даём Решалам порулить? Почему не отбрасываем поверхностные идеи? Как предотвратить собственное решательство?

User Story как фильтр

Когда я думал о фильтрах, не пропускающих кнопочные идеи, вспомнились User Story[4]. Мы используем истории для формирования задач проекта в повседневной практике. Сила User Story в том, что они заставляют описывать ценность. Нет ценности в истории – нет лишней кнопки в интерфейсе.

Работа строится следующим образом. Вносишь в работу идею → опиши в виде User Story. Ответь на вопрос «Чтобы что?».

Хочешь кнопку выгрузки отчёта в Excel. Ок, чтобы что? Чтобы было на всякий случай? В мусорку, не берём в работу.

Бухгалтер Оля сказала, что ей так нравится? В мусорку, не берём в работу.

Вы посовещались внутри отдела экономистов, нарисовали кнопку в интерфейс и теперь хотите, чтобы мы её добавили? Чтобы что? Потому что это ваша идея и она вам нравится? В мусорку.

Вы заказчик и вы так видите? Другого «чтобы что» нет? Увы, в работу не берём. Иногда можно сделать ставку на Pet Feature, но перед этим следует обозначить риски и чётко проговорить бесполезность затеи.

Хитрые Product Owner'ы

User Story отлично отсеивает кнопочные идеи. Проверено на практике. Однако здесь появляется оборотная сторона проблемы. Product Owner'ы и stakeholder'ы поняли, что через User Story не пройти, потому что приходится искать ответ на вопрос «Чтобы что?». А это сложно, если ты пришёл с Pet Feature. Сложно, но сильно хочется.

Product Owner'ы[5] подстроились под новую модель постановки задач. Они научились играть в эту игру.

Я, как корпоративный клиент,

Хочу скачивать отчёт о движениях денежных средств,

Чтобы видеть, что баланс стал отрицательным.

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

Я бы для начала спросил о дальнейшей жизни скачанного отчёта. О жизни пользователя, который скачает этот отчёт. Что он найдёт в отчёте? С помощью чего найдёт нужное? Как он отделит нужное от ненужного?

Мимикрирующие User Story

Правило User Story соблюдено, но без погружения и дополнительных вопросов в работу оно не работает. Что делать? Копаем, ищем корни проблемы, задаём открытые вопросы, используем принцип 5 Why[6]. Со временем узнаём корень проблемы и записываем в User Story:

Я, как корпоративный клиент,

Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.

Хочу…

Чтобы…

Уже лучше, потому что мы поняли, откуда пришло кнопочное решение со скачиванием отчёта. Теперь мы знаем, что клиент теряет деньги, если оперативно не получает информацию о счёте.

Следующий шаг – понять, как мы поменяем жизнь корпоративного клиента. Gojko Adzic в книге Quick Ideas To Improve Your User Stories[7] указывает на то, что лучше прописывать в User Story дельту между тем, как пользователь жил до релиза, и тем, как он заживёт после. Получаем такую историю:

Я, как корпоративный клиент,

Не понимаю, в каком состоянии счёт, и из-за этого ухожу в минус.

Хочу останавливать работу, если баланс стал критично низким,

Чтобы не терять деньги.

Мы остановим работу пользователя и трату денег, когда баланс станет отрицательным. Когда мы озвучиваем предложение пользователям, они не верят, что можно автоматически остановить работу. Для пользователя боль потери денег настолько сильна, что они сами придумали скачивание отчёта, они готовы смотреть в отчёт, искать в нём ответ на вопрос об отрицательном балансе.

В последней версии User Story кнопочное решение убрано. Раскопана корневая проблема. Предложено решение, которое закроет корневую проблему. Появился шанс принести пользу после релиза, а не добавить ещё одну кнопку для скачивания ещё одного отчёта.

Некоторым людям неймётся выпалить решение. Они как будто играют в «Свою Игру» или «Брейнринг». Ждут вопрос и на скорость предлагают решение.

В спешке между проблемой и идеей возникает слепая зона. Цепочка рассуждений и выводов остаётся за кадром (рис. 1).

Рис. 1. Отсутствие связи между целью и решением

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

Рис. 2. Прорисовка связи между целью и решением

Увидев корневую проблему или потребность, накидываем много возможных решений (рис. 3).

Рис. 3. Множество решений для одной цели

Обратите внимание, что теперь налицо выбор, но сделать его сложнее. У меня есть предположение, что люди намеренно останавливаются на первом решении, которое кажется подходящим. Ведь если идти дальше, то придётся выбирать, оценивать риски каждого решения, его плюсы и минусы. Работы прибавится. Кроме того, чем шире выбор, тем меньше будет радость от итогового решения.

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

Истории из жизни

Кейс: Сужение видения

Идёт планирование релиза. Product Owner заканчивает фразу словами: «…можно отправить почтой». Я сразу останавливаю обсуждение, потому что одной фразой произошло сужение проблематики до одного решения. Остановились и раскопали корень потребности. Почему отправлять? Почему почтой? В мире ведь придумано много способов донесения информации до пользователей. В итоге предложили пять способов рассказать клиентам об обновлениях. Совет: не сводите решение к одному варианту.

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

Новый заказчик обсуждает с нами модернизацию 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 заказчика осенило. Они поменяли бизнес-модель, запустили ряд экспериментов в бизнесе и обещали вернуться к нам через три месяца. В итоге вернулись через полгода с перестроенной компанией, которая стала готова для создания нового продукта. Продукт мы сделали и успешно запустили. Мы считаем это успехом, так как не позволили потратить время на что-то бесполезное.