- PVSM.RU - https://www.pvsm.ru -
Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.
Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.
Синонимами кнопочного
Для тех, кто любит смотреть, а не читать, есть видео и слайды [2].
Практика показала, что есть три типажа людей-генераторов кнопочных решений. Речь будет не о конкретных позициях в проекте, потому что лажать может каждый член команды. Программисты, QA, дизайнеры, заказчики, инвесторы и конечными пользователями — потенциальные создатели кнопок.
Представьте ситуацию, в которой заказчик приносит проблему. Он делится этой проблемой с Торопыгой. Что делает Торопыга в ответ? Чувствует давление, как будто заказчик ждет ответа, причем незамедлительного. После вопроса заказчика висит пауза, а ответа в голове не появилось, напряжение возрастает. В своем воображении Торопыга уже видит, как заказчик обвиняет беднягу в некомпетентности. Поэтому заказчику выдается решение преждевременное и необдуманное.
Как быть, если заметили за собой недуг торопыжничества? Во-первых, осознайте, что невозможно знать все ответы. Придумывание налету не признак профессионализма. Во-вторых, брать паузы в переговорах и на совещаниях — норма. Берете паузу, идете думать. Приносите с собой варианты решений, риски по каждому, плюсы и минусы [3].
Решалы — ребята профи, которые в IT собаку съели. Спроси — сразу ответят. Хотя и не факт, что за плечами у них серьезные проекты и десятки лет опыта.
Для Решалы входящие проблемы и задачи видятся типовыми, уже решенными. По фреймворку Cynefin Framework [4] Решалы видят мир в квадратике Obvious, ну максимум в Complicated. Т.е. у них решение уже готово, надо только выбрать категорию проблемы.
Решалы лишают себя шанса преподнести заказчику проработанное решение и вырасти на новой задаче.
Заказчик-решала пострашнее разработчика-решалы, потому что любит проталкивать Pet Features в продукт.
Неожиданно в голове у человека, появляется чувство, что если он не поднимется с колен и не поведет за собой команду, то конец проекту, продукту и даже компании. Он берет на себя роль Спасителя, поднимает флаг и ведет людей за собой. Спасители мыслят кнопочно с особым фанатизмом.
Да это же ситуационное лидерство [5], про которое так много сказано в гибких подходах разработки. Да, так и есть. Только не всё ситуационное лидерство одинаково полезно. Проблема возникает когда во время подъема человек перестает слышать других и адекватно оценивать ситуацию. Его решения начинают быть ультимативными, он на войне, он спаситель, он вершит судьбу.
Если вы заметили Спасителя в проекте, то постарайтесь вывести человека из этого состояния. Медленно, но жестко, чем раньше, тем лучше. Ему самому потом будет грустно от своих решений, принятых в состоянии аффекта.
Не знаю к какой части себя присоединить, но я и сам великий генератор кнопок и быстрых решений. 10 лет опыта и скорость
Наверняка в мире живут айтишники со стальной волей. Они способны держать себя в жестких рамках, не вываливатся в роль Решалы или Спасителя. Я к таким не отношусь и периодически скатываюсь к одной из ролей, а иногда в их комбинацию.
Когда я это осознаю, бью себя по щекам, колю булавкой и торможу решательство. Не всегда успешно. И всё равно тренеруюсь, кажется со временем становится лучше.
С источниками кнопочного
Когда я думал о фильтрах, не пропускающих кнопочные идеи, вспомнились User Story [6]. Мы используем истории для формирования задач проекта в повседневной практике. Сила User Story в том, что они заставляют описывать ценность. Нет ценности в истории — нет лишней кнопки в интерфейсе.
Работа строиться следующим образом. Вносишь в работу идею → опиши в виде User Story. Ответь на вопрос «Чтобы что?».
Хочешь кнопку выгрузки отчета в Excel. Ок, чтобы что? Чтобы было на всякий случай? В мусорку, не берем в работу.
Бухгалтер Оля сказала, что ей так нравится? В мусорку, не берем в работу.
Вы посовещались внутри отдела экономистов, нарисовали кнопку в интерфейс и теперь хотите, чтобы мы ее добавили? Чтобы что? Потому что это ваша идея и она вам нравится? В мусорку, не берем в работу.
Вы заказчик и вы так видите? Другого «чтобы что» нет? В мусорку, не берем в работу. (хотя Pet Feature мы иногда реализуем, но для начала проговариваем риски и показываем бесполезность этой затеи).
User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы. Product Owner'ы и stakeholder'ы поняли, что через User Story не пройти, потому что приходится искать ответ на вопрос «Чтобы что?». А это сложно, если ты пришел с Pet Feature. Сложно, но сильно хочется.
Product Owner'ы подстроились под новую модель постановки задач. Они научились играть в эту игру.
Я как корпоративный клиент
Хочу скачивать отчет о движениях денежных средств
Чтобы видеть, что баланс стал отрицательным
Неопытный разработчик или дизайнер примут такую историю за правильную. Но присмотритесь к ней внимательно. Перечитайте это историю и попробуйте прикинуть, какие вопросы у вас возникнуть к Product Owner'у.
Я бы для начала поинтересовался о дальнейшей жизниь скачанного отчета. О жизни пользователя, который скачает этот отчет. Что он найдет в отчете? С помощью чего найдет нужное? Как он отделит нужное от ненужного?
Хоть и формат User Story соблюден, но без погружения и дополнительных вопросов в работу не принимаем. Копаем, ищем корни проблемы. Задаем открытые вопросы, используем 5 Why [7]. Со временем узнаем корень проблемы и записываем в User Story:
Я как корпоративный клиент
Не понимаю в каком состоянии счет и из-за этого ухожу в минус
Хочу…
Чтобы…
Уже лучше, потому что мы поняли откуда пришло кнопочное решение со скачиванием отчета. Теперь мы знаем, что клиент теряет деньги, если оперативно не получает информацию о счете.
Следующий шаг — понять как мы поменяем жизнь корпоративного клиента, чтобы он решил эту проблему. Gojko Adzic в книге Quick Ideas To Improve Your User Stories [8] указывает на то, что лучше прописывать в User Story дельту между тем, как пользователь жил до релиза и тем, как он заживет после релиза. Получаем такую историю:
Я как корпоративный клиент
Не понимаю в каком состоянии счет и из-за этого ухожу в минус
Хочу останавливать работу, если баланс стал критично низким
Чтобы не терять деньги
Мы остановим работу пользователя и трату денег, когда баланс станет отрицальтельным. Когда мы озвучиваем предложение пользователям, они не верят, что можно автоматически остановить работу. Для пользователя боль потери денег настолько сильная, что они сами придумали скачивание отчета, они готовы смотреть в отчет, искать в нем ответ на вопрос об отрицальном балансе.
В последней версии User Story кнопочное решение убрано. Раскопана корневая проблема. Предложено решение, которое закроет корневую проблему. Появился шанс нанести пользу после релиза, а не добавить еще одну кнопку для скачивания еще одного отчета.
Некоторым людям неймется выпалить решение. Они как будто играют в Свою Игру или Брейн Ринг. Ждут вопрос и на скорость предлагают решение.
При поспешных решениях между проблемой и идеей возникает слепая зона. Цепочка рассуждений и выводов остается за кадром:
Мы не принимаем одно решение, копаем корень проблемы, определяем действующих лиц. После прокладывания пути из цели, действующих лиц и корня проблемы кнопочное решение теряет былую прочность:
Увидев корневую проблему или потребность, мы накидываем много возможных решений:
Обратите внимание, что теперь видно выбор, но сам выбор сделать сложнее. У меня есть предположение, что люди намеренно останавливаются на первом решении, которое кажется подходящим. Ведь если идти дальше, то придется выбирать, оценивать риски каждого решения, плюсы и минусы, работы прибавляется. Кроме того, чем шире выбор, тем меньше радость итогового решения.
Глубокое бурение проблемы затратно, никто не стремится в это болото. Но если мы создаем полезное решение, то пересиливаем себя и раскрываем слепую зону.
Представьте сцену в магазине. Вы набрали продуктов в корзину и подошли к кассе. Кассир пробил товары, взвесил фрукты и овощи, назвал стоимость. Типичная ситуация для покупки продуктов.
Сцена один в один при создании IT-продукта. Вы сидите на кассе, приходит заказчик с корзиной фич и решений. Вы оцениваете, взвешиваете, говорите ему стоимость.
Давайте вернемся в магазин и переиграем ситуацию. Вы подходите к кассе, выкладываете покупки. Продавец вам говорит: «Зря вы взяли помидоры Шеди Леди для рагу из кролика. Этот сорт слишком сладкий, для рагу не подойдет. Возьмите сорт Маленький принц, рагу с ними отменное».
Давайте посмотрим что изменилось. Почему вы благодарны кассиру и хотите его обнять? Он узнал вашу цель. После этого он предложил решение, которое двигает вас к цели, а не молча согласился с предложенным решением. Ценность покупки в этом магазин выросла, удовлетворение выросло, вы захотите приходить в этот магазин снова.
Теперь вернемся к IT. Для выявления целей, понимания пути достижения целей, формирования выбора из решений я рекомендую Impact Mapping [14]:
Техника изучается за пару дней. С помощью Impact Mapping мы прокладываем путь с решений до цели, приоритизируем решения и пути, отсекаем Pet Feature, которые идут со стороны бизнеса и со стороны команды. Единственная сложность — процесс создания Impact Mapping, он требует навыков фасилитации.
В IT-отдел пришел начальник маркетинга и попросил добавили всплывающее сообщение, чтобы работник выходил на улицу и раздавал листовки. Сообщение по задумке всплывает каждые 30 минут, в результате должны повысится продажи. Задача как задача, IT-отдел взял да и сделал.
На местах это вылилось в противоречивый сценарий. Работнику всплывает сообщение, что надо идти на улицу и раздавать листовки. Он выходит и раздает, а в это время всплывает сообщение: «Ты на месте?».
Почему так произошло? Никто не конролировал целостность системы. Многоголовый Product Owner приносил задачу, разработчики брали задачу без вопросов.
До работы с нами у проекта накопилась полугодовая история. Заказчику сделали ТЗ, реализовали часть мобильного клиента, но не сделали серверную часть. С этой историей заказчик пришел к нам. Мы начали проект по нашему процессу [16] и уже к концу Customer Journey Mapping заказчика осенило. Они поменяли бизнес-модель, запустили ряд экспериментов в бизнесе и обещали вернуться к нам через 3 месяца. Мы считаем это успехом, т.к. не позволили потратить время на бесполезный продукт.
В продолжение к формулированию цели. Если цели IT-отдела или IT-продукта не сформулированы, то это благодатная почва для кнопочных решений. Перефразируя фразу Жванецкого из монолога [17]: Если нет цели, то куда бы ты ни шёл — получается «вперёд».
Когда мы берем задачу, то сопоставляем стоимость задачи с эффектом, который задача окажет на достижение цели. А если цели нет? Значит и соизмерять не с чем. Отсюда рождается стиль работы, когда задачи реализуются, потому что прикольно эти задачи реализовать. В таких отделах разработки кипит жизнь, фичи добавляются, идут непрерывные релизы. При этом бурном движении, результат не меняется.
В таких случаях помогает только возврат к целям проекта и фильтрация с помощью Impact Mapping.
Чтобы уберечь ваши нервы, делюсь выработанной стратегией борьбы с кнопочным
Рекомендации одинаково банальные и действенные. Мне в работе помогает.
Замечайте кнопочное
Автор: AlexanderByndyu
Источник [18]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/125172
Ссылки в тексте:
[1] мышления: http://www.braintools.ru
[2] видео и слайды: http://blog.byndyu.ru/2016/05/it.html
[3] варианты решений, риски по каждому, плюсы и минусы: http://blog.byndyu.ru/2015/02/customer-satisfaction_25.html
[4] Cynefin Framework: http://en.wikipedia.org/wiki/Cynefin
[5] ситуационное лидерство: https://en.wikipedia.org/wiki/Situational_leadership_theory
[6] User Story: https://en.wikipedia.org/wiki/User_story
[7] 5 Why: https://en.wikipedia.org/wiki/5_Whys
[8] Quick Ideas To Improve Your User Stories: https://www.amazon.com/Fifty-Quick-Ideas-Improve-Stories-ebook/dp/B00OGT2U7M
[9] Image: https://3.bp.blogspot.com/-V_KZuQ3h2rM/V0vk4uFnpvI/AAAAAAAACQw/gLpowJVXftAkFyFgbQcPTAPq1BdE01TpQCLcB/s1600/%25D0%2591%25D0%25B5%25D0%25B7%25D1%258B%25D0%25BC%25D1%258F%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9.png
[10] Image: https://4.bp.blogspot.com/-SX8H2QpKI8k/V0vldCNaa4I/AAAAAAAACQ0/Ww_IIpszwqEYJ9YpOmpyqJ9OYX_eG0cGgCLcB/s1600/%25D0%2591%25D0%25B5%25D0%25B7%25D1%258B%25D0%25BC%25D1%258F%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9.png
[11] Image: https://4.bp.blogspot.com/-7U0IuDQi_lQ/V0vl2gyyv6I/AAAAAAAACQ8/zrdOhtBrNFolNfXBVF_BVY3SoyhWwD1LwCLcB/s1600/%25D0%2591%25D0%25B5%25D0%25B7%25D1%258B%25D0%25BC%25D1%258F%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9.png
[12] Image: https://3.bp.blogspot.com/-32F3Z_tWgzQ/V0vmZWG-VAI/AAAAAAAACRE/BJcj7MtdfLMC6dJ9PAncZ_bha9Xb-E70gCLcB/s1600/%25D0%2591%25D0%25B5%25D0%25B7%25D1%258B%25D0%25BC%25D1%258F%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9.png
[13] Image: https://4.bp.blogspot.com/-kYq-SSKNYzs/Vz7wBrzr5dI/AAAAAAAACQY/fCkx3X5hMkwTnK4eom7QtqlOze1Vn0iiQCLcB/s1600/%25D0%2591%25D0%25B5%25D0%25B7%25D1%258B%25D0%25BC%25D1%258F%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9.png
[14] Impact Mapping: http://blog.byndyu.ru/2014/12/impact-mapping.html
[15] Image: https://1.bp.blogspot.com/-j5akAl3jJdU/V0vpnesKLOI/AAAAAAAACRU/ZEF0skJYR1wivu8e9nXPT9upX4O1b1QoACLcB/s1600/%25D0%2591%25D0%25B5%25D0%25B7%25D1%258B%25D0%25BC%25D1%258F%25D0%25BD%25D0%25BD%25D1%258B%25D0%25B9.png
[16] нашему процессу: http://blog.byndyu.ru/2015/12/blog-post.html
[17] из монолога: https://www.youtube.com/watch?v=ZvcsUD6Du9U
[18] Источник: https://habrahabr.ru/post/302382/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.