Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.

Синонимами кнопочного мышления я считаю «экранное мышление» или преждевременную концептуализацию. Я раскрою мышление кнопками на десятке примеров из практики. А здесь для начала история, которая наверняка случалась с каждым. Представьте к вам приходят и рассказывают о падении конверсии на сайте. А вы ему сразу: «Давайте кнопку покупки сделаем побольше и поярче!». Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Вот в таких случаях я говорю о кнопочном мышлении.

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

Кто генерирует кнопочные идеи

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

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

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

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

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

Решалы лишают себя шанса преподнести заказчику проработанное решение и вырасти на новой задаче.

Заказчик-решала пострашнее разработчика-решалы, потому что любит проталкивать Pet Features в продукт.

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

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

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

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

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

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

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

Мимикрирующие User Story и хитрые Product Owner’ы

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

User Story как фильтр

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

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

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

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

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

Вы заказчик и вы так видите? Другого «чтобы что» нет? В мусорку, не берем в работу. (хотя Pet Feature мы иногда реализуем, но для начала проговариваем риски и показываем бесполезность этой затеи).

Хитрые Product Owner’ы

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

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

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

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

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

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

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

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

Хоть и формат User Story соблюден, но без погружения и дополнительных вопросов в работу не принимаем. Копаем, ищем корни проблемы. Задаем открытые вопросы, используем 5 Why. Со временем узнаем корень проблемы и записываем в User Story:

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

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

Хочу...

Чтобы...

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

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

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

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

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

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

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

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

Преждевременные решения

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

При поспешных решениях между проблемой и идеей возникает слепая зона. Цепочка рассуждений и выводов остается за кадром:

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

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

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

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

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

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

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

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

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

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

Сколько стоят 1000 строк кода?

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

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

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

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

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

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

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

Кейс: Нужно больше всплывающих окон

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

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

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

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

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

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

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

Движение без цели

В продолжение к формулированию цели. Если цели IT-отдела или IT-продукта не сформулированы, то это благодатная почва для кнопочных решений. Перефразируя фразу Жванецкого из монолога: Если нет цели, то куда бы ты ни шёл — получается «вперёд».

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

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

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

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

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

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

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

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

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

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

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

Саморефлексия и душевный покой

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

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

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

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

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

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

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

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

Замечайте кнопочное мышление за собой, замечайте за коллегами, рассказывайте заказчикам и учитесь работать с запросами пользователей. Помогайте друг другу в преодолении недуга. Пишите ваши истории в комментарии, давайте вместе смеяться над неправильным и стремиться к правильному.

UPD: Перевел статью в свой англоязычный блог.

Оригинал: https://habrahabr.ru/post/302382/