Ваша команда сильнее, чем она сама думает

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

1. Образ нужного результата и понимание продуктового контекста кратно усиливает разработку. Коллега привел шесть конкретных практик про то, как помочь разработчикам понимать этот контекст.

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

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

4. Обсудили, что описание бага должно быть двухмерным: когда из названия и описания становится как можно быстрее понятно а) что и как конкретно должно работать + б) что конкретно и при каких условиях не работает правильно сейчас.

Иллюстрация для этого принципа — в заголовке поста.

Спасибо всем коллегам ☺️ за активное обсуждение и открытость к новому опыту.

@startwithease