Синонимами кнопочного мышления можно назвать экранное мышление или преждевременную концептуализацию. Суть мышления кнопками можно раскрыть на десятке примеров из практики, но пока – история, которая наверняка случалась с каждым. Представьте: к вам приходит клиент и рассказывает о падении конверсии на сайте. А вы в ответ: «Давайте кнопку покупки сделаем побольше и поярче!» Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Это и есть кнопочное мышление.
Практика показала, что есть три типажа людей-генераторов кнопочных решений. Речь не о конкретных позициях в проекте, потому что лажать может каждый член команды. Программисты, QA, дизайнеры, заказчики, инвесторы и конечные пользователи – потенциальные создатели кнопок.
Представьте ситуацию, в которой Заказчик приносит проблему. Он делится этой проблемой с Торопыгой. Что делает Торопыга в ответ? Чувствует давление, как будто Заказчик ждёт ответа, причём мгновенно. Пауза затягивается, а ответа в голове не появилось – напряжение возрастает. В своём воображении Торопыга уже видит, как его, беднягу, обвиняют в некомпетентности, и выдаёт первое пришедшее в голову решение. В лучшем случае бесполезное, в худшем – вредное.
Как быть, если вы заметили за собой недуг торопыжничества? Во-первых, осознайте, что невозможно знать все ответы. Придумывание налету – не признак профессионализма. Во-вторых, брать паузы в переговорах и на совещаниях – норма. Берёте паузу, идёте думать. Приносите с собой варианты решений, риски по каждому, плюсы и минусы[1].
Решалы – ребята-профи, которые в IT собаку съели. Спроси – сразу ответят. Хотя и не факт, что за плечами у них серьёзные проекты и десятки лет опыта.
Для Решалы входящие проблемы и задачи видятся типовыми, уже решёнными. По фреймворку Cynefin Framework[2] Решалы видят мир в квадратике Obvious, ну, максимум – в Complicated. Другими словами, у них всегда есть готовое решение, надо только выбрать категорию проблемы. Не понимая того, что они лишают себя шанса преподнести бизнесу проработанное решение и вырасти на новой задаче.
Бизнес-решала пострашнее Разработчика-решалы, потому что любит проталкивать Pet Features в продукт. Pet feature – это такие любимчики, как милые домашние питомцы, цель их существования в продукте неясна, но они почему-то по душе тому, кто платит за разработку.
Неожиданно в голове у человека появляется чувство, что если он не поднимется с колен и не поведёт за собой команду, то конец проекту, продукту и даже компании. Он берёт на себя роль Спасителя, поднимает флаг и ведёт людей за собой. Спасители мыслят кнопочно с особым фанатизмом.
Если вы решили, что это ситуационное лидерство[3], о котором так много сказано в гибких подходах разработки, то будете правы. Только не всё ситуационное лидерство одинаково полезно. Проблема возникает, когда во время подъёма человек перестаёт слышать других и адекватно оценивать ситуацию. Его решения становятся ультимативными: он на войне, он Спаситель, он вершит судьбы.
Если вы заметили Спасителя в проекте, постарайтесь вывести человека из этого состояния. Медленно, но непреклонно и жёстко. Чем раньше, тем лучше. Впереди его ждут сожаления о решениях, принятых в состоянии аффекта.
Не знаю, к какой части себя присоединить, но я и сам великий генератор кнопок и быстрых решений. 10 лет опыта и скорость мозга не дают мне усомниться в своей правоте. Я решаю со страшной скоростью и наслаждением.
Наверняка в мире живут айтишники со стальной волей. Они способны держать себя в жёстких рамках, не вываливаться в роль Решалы или Спасителя. Я к таким не отношусь и периодически скатываюсь в одну из ролей, а иногда в их комбинацию.
Когда я это осознаю, бью себя по щекам, колю булавкой и торможу подобное решательство. Не всегда успешно, но я всё равно стараюсь. Кажется, со временем становится лучше.
С источниками кнопочного мышления разобрались. Теперь узнаем, что с ними делать. Почему мы даём Решалам порулить? Почему не отбрасываем поверхностные идеи? Как предотвратить собственное решательство?
Когда я думал о фильтрах, не пропускающих кнопочные идеи, вспомнились User Story[4]. Мы используем истории для формирования задач проекта в повседневной практике. Сила User Story в том, что они заставляют описывать ценность. Нет ценности в истории – нет лишней кнопки в интерфейсе.
Работа строится следующим образом. Вносишь в работу идею -> опиши в виде User Story. Ответь на вопрос «Чтобы что?».
Хочешь кнопку выгрузки отчёта в Excel. Ок, чтобы что? Чтобы было на всякий случай? В мусорку, не берём в работу.
Бухгалтер Оля сказала, что ей так нравится? В мусорку, не берём в работу.
