Алгоритм приоритизации фидбека
· 2 мин
Когда команда смотрит демо новой фичи, которая вот-вот уже готова выйти в продакшен, у кого-то обязательно будет фидбек.
“Тут немного не так.”
“Здорово, если здесь будет немного по-другому.”
“А как насчёт вот этого?”
В такой ситуации продакт менеджеру важно оценить, что является блокером (blocker) для релиза, то есть без чего фичу нельзя выкатывать пользователям, а что может и подождать.
Я руководствуюсь таким алгоритмом:
Это баг, запрос на новый фукнционал или запрос на изменение заранее оговоренного функционала?
-
Если баг, насколько он критичен, чтобы пофиксить его прямо сейчас vs. после релиза? Если не критичен, добавляем его в бэклог и идём дальше. Если критичен, то фиксим сейчас.
-
Если новый функционал, не оговоренный в требованиях, идея сразу идёт в бэклог. Нам не нужно увеличивать scope релиза. Это называется “scope creep” — когда scope разрастается из-за несвоевременных предложений и неспособности их приоритизировать.
-
Если изменение заранее оговоренного функционала, что вызвало этот запрос? Появилась ли новая информация, которая делает предыдущие требования нерелевантными? Если дело в новой информации, принимаем взвешеное решение. Если внесение изменений сделает фичу экспоненциально лучше при минимальных затратах времени, то можно рассмотреть в виде исключения. В противном случае — в бэклог.
Продакт менеджер — главный чирлидер, который вдохновляет команду на свершения, а также приносит пользователям радость. Но он же должен иметь и внутренний стержень, чтобы быть главным кайфоломщиком, который скажет “нет, бл.ть”, облачённое в “это очень классные идеи, но давайте не будем увеличивать scope, шипнем, соберём метрики, послушаем фидбек, а потом решим стоит ли вносить суперские изменения, которые вы предлагаете”.
При слабом продакт менеджере такую функцию может выполнять менеджер команды разработки или техлид. Тогда в команде возникает здоровое трение, которое учит продакт менеджера находить правильный баланс между счастьем пользователей, сроками и инженерными ресурсами.