Вы говорите разработчикам, что теперь на каждую задачу надо писать автотесты. Они кивают, ведь и сами давно об этом говорят. Но когда очередная задача приходит в тестирование – тестов нет.
Вы просите аналитиков описывать проблему пользователя в каждой задаче. Они соглашаются, ведь это поможет тестировать, а значит, улучшит качество их любимого продукта. Но когда очередная задача приходит в тестирование – описания проблемы нет.
Вас просят проверять прогоны автотестов перед каждым релизом. Вы радостно поддерживаете эту идею, ведь вы любите автотесты. Но через неделю на летучке все обсуждают, что в мастере уже три дня падает один из тестов и никто этого не замечал.
Что это? Саботаж? Немая забастовка? Инфантильность? Мой ответ – это наш мозг.
Аттеншн – занудство и теория
Уже несколько лет из каждого утюга кричат про модель психики, придуманную Канеманом и описанную в книге “Думай медленно… решай быстро”. Канеман разделил мозг на две системы:
быструю, автоматическую, принимающую решения “подсознательно”, без значительных интеллектуальных усилий, и
медленную, “рациональную”, ответственную за принятие сложных решений.
Еще быстро вспомним, что мозг от природы ленивый и старается не тратить силы зря, а значит по умолчанию активна быстрая система.
Сейчас самое время задать вопрос – И чё?
Аттеншн – субъективные выводы
А теперь возвращаемся к ситуациям из начала статьи. Представим, что происходит в голове всех этих “вредителей”.
Разработчик написал код по задаче. Перечитал постановку, убедился, что ничего не забыл. Запустил приложение локально (надеемся) и проверил, что основной сценарий работает. Выдыхает, закрывает задачу, вводит потраченное время и идет в бэклог выбирать новую задачу. Всё на автомате, ведь он работает по этому сценарию последние 2.5 года.
Аналитик читает запрос от пользователей, исследует существующую систему, продумывает решение и аккуратно вносит изменения в ТЗ. В его голове загружено решение проблемы, именно этим он занимался всё последнее время. И именно это вносит в задачу, автоматически.
Ну вы поняли.
Аттеншн – непрошенные советы
Как можно с этим бороться? Я предлагаю намеренно подключать систему 2 в тех случаях, когда вам нужно вывести человека из автопилота. Делаю это либо через фокусирование внимания, либо через создание преград. На примерах:
Тестирую задачу – вижу отсутствие багов, не вижу тестов – переоткрываю задачу. Это создает неудобство разработчику, раздражает, представляя негативную мотивацию. Плюс при переключении на эту задачу он выйдет из автопилота и подключит рациональную систему. Вероятность того, что действие “написать тесты” войдет в автоматическую цепочку выше, т.к. разработчик стремится избежать неприятных эмоций от переоткрытия, и явно обращает на это внимание.
Создаем шаблон тикета и добавляем пункт о проблеме пользователя. Теперь при написании постановки аналитик точно обратит на это внимание, выйдет из автоматического режима заполнения задачи “по привычке”. А через пару итераций это станет новой привычкой.
Создаем задачу на релиз, в которой прописываем все необходимые действия, включая прогон автотестов. Отключаем автопилот, подключаем внимательную систему 2, не оставляем шансов “забыть” (ну и стабилизируем тесты, чтобы отбить привычку игнорировать падения, но это тема другой статьи).
Короткий вывод
Другие люди искренне готовы меняться ради улучшения качества продукта. В саботировании нововведений виноват автопилот, с ним и боремся. А людей любим и бережём. Всем бобра.
