Комментарии 5
Прикольный кейс) надо взять на заметку))
Т.е. вы просто заново переоткрыли такие вещи, как факторный анализ + технические спринты.
Мои поздравления!
Спасибо вам за комментарий. Согласны, что наше решение может выглядеть очевидным. Тем не менее с такой проблемой сталкивается большинство команд. Каждая отдельная команда имеет свои особенности и существует в своем контексте, все это ведет к тому, что известные и "давно обкатанные" методы могут потребовать адаптации для конкретной команды. Мы решили поделиться нашим опытом, надеемся, что он кому-нибудь пригодится и тогда мы будем рады, что наш кейс и статья полезны.
"В приоритете бэклога команд закономерно стояла разработка фичей и устранение дефектов, напрямую влияющих на бизнесовые показатели и продуктовые метрики. В итоге из мелких исправлений начал копиться внушительный беклог."
"В итоге мы приняли решение вернуть процесс исправления дефектов обратно в ведение команд."
"На том этапе мы понимали, что, так как команда уже достаточно загружена, то работа на входящих запросах без какой-либо системы будет малоэффективна."
Ваша проблема в не приоритетах, а в том, что команда уже сейчас перегружена текущими задачами и её надо расширять. Проблема в постоянной спешке (надо сделать ещё вчера), из-за чего используются неоптимальные решение (пресловутые "костыли"), отсутствие контроля за качеством (раз, два и в продакшен), съехавшие шрифты и прочее по мелочи.
Решением является расширение команды разработки, чтобы увеличить общую производительность и начать разгребать backlog с мелкими дефектами. Либо уменьшение скорости разработки новых фич при сохранении текущего размера команды, чтобы освободившееся время можно было потратить на приведение в порядок того, что ранее уже разработали.
Ситуация в которой беклог больше, чем команда может обработать встречается у больших и маленьких команд. Это реалии бизнеса, в которых важно наладить внутренние процессы и ранжировать входящие запросы. Таким образом правильно налаженный процесс позволяет снизить техдолг, распределить нагрузку и работать с запросами, которые не влияют напрямую на метрику и соответственно оценить их важность сложно.
Bug policy. Что делать когда работа с дефектами — это хаос и ужас