Сегодня обсуждали с коллегами гипотезу, которая может помочь повысить продуктивность команды разработки больше, чем в четыре раза. Если делать все правильно 😉
Гипотеза очень простая:
1. Каждый разработчик привык решать конкретные задачи. Из названия и описания задачи ему должно быть понятно, какой результат нужен клиенту — как должен работать продукт после того, как задача будет выполнена.
Сотрудник может сообщить о фишинговом сайте в один клик через браузерный плагин
2. У разработчиков больше половины рабочего времени может уходить на исправление багов — ошибок в продукте, когда он работает некорректно.
Баги — это отдельный тип задач. Их заводит команда контроля качества.
3. Название багов обычно формулируют как негативный результат: проблему, которую обнаружила команда контроля качества:
Не работает браузерный плагин
4. При такой формулировке возникает несколько нежелательных эффектов, которые снижают мотивацию и производительность команд разработки:
— У разработчиков не появляется понимания, какой целевой результат нужно сделать: как правильно должен работать продукт, что нужно в результате решения задачи (баг — такая же задача, которую надо брать в работу).
Да, где-то в глубине описания может найтись целевое, правильное поведение системы. Но туда еще нужно добраться.
— Из-за этого возникает эффект фрейминга, а также эффект Что видишь, то и есть, которые изучали Канеман и Тверски. По такому же принципу работает пропаганда и новости.
В результате разработчикам кажется, что продукт не работает как следует и с ним одни проблемы.
— Каждый баг в подобной формулировке осознается как опыт негативного взаимодействия внутри команды.
Наиболее эффективно работают команды, у которых соотношение позитивных и негативных взаимодействий находится выше, чем 3:1. Если баги занимают хотя бы половину спринта, мы имеем соотношение 1:1 или еще хуже.
В результате у команды пропадает креативность, нарушается работа в потоке и снижается продуктивность.
Можно ли это исправить?
Да, и очень просто:
1. Достаточно называть баги, как любые другие задачи: формулировать понятный целевой результат в названии и описании.
Браузерный плагин корректно устанавливается и работает в Яндекс Браузере последней версии
Разумеется, все нужные условия воспроизведения бага также должны остаться в описании.
2. Баг становится такой же задачей с понятным, нужным для клиента результатом. Работа над багами не создает негатива, а формирует позитивное взаимодействие внутри команды.
3. Позитивно настроенные команды начинают работать в 4.5 раза более эффективно.
Начните с простого: ставьте задачи правильно.
@startwithease
В тему:
ТРИЗ: сформулировать ИКР — идеальный конечный результат, — как первый шаг для решения изобретательской задачи.
Позитивное подкрепление как ключ к воспитанию животных, людей и самого себя.
Ясный образ целевого результата как первый пункт успешных изменений.
Канал Арсения, моего коллеги, который помог разобраться в теме с точки зрения когнитивных искажений и научных обоснований подхода.
Я никогда не присоединюсь к движению против войны. Позовите меня, когда появится движение за мир
— Мать Тереза