Как продакту оценивать работу команды

Зачем продакту оценивать команду

Сразу оговоримся: продакт — не руководитель команды разработки. Зарплаты, повышения и увольнения чаще всего не на нём. Но продакт работает с командой каждый день и видит её ближе, чем кто-либо ещё. Если продакт не понимает, как работает команда — он не сможет планировать, не сможет защитить ребят перед руководством и не сможет вовремя поднять флажок, что что-то идёт не так.

Оценка команды нужна не для того, чтобы кого-то наказать. Она нужна, чтобы понимать, на что мы способны как группа, где у нас просадки, и куда вкладывать энергию для роста. Без этого продакт работает вслепую — берёт обещания, которые команда не вытянет, или, наоборот, не догружает людей и теряет потенциал.

В этой статье разберём, что реально стоит мерить, чего лучше не трогать, и как превратить оценку в полезный процесс, а не в палочную систему.

Что мерить

Хорошие метрики команды делятся на три группы.

Влияние на продукт и бизнес. Это главное. Сделанная фича запустилась? Метрика двинулась? A/B показал положительный эффект? Это то, ради чего команда существует. Если ваша команда выкатывает много, а метрики стоят — есть проблема, и надо разбираться.

Скорость и предсказуемость. Сколько спринтов команда стабильно довозит то, что взяла. Как часто переносятся задачи. Какой процент времени уходит на баги и ад-хоки. Идеально — стабильная скорость без перекосов.

Качество кода и продукта. Количество багов в проде, время от багрепорта до фикса, флакичность тестов, частота инцидентов. Это видно по дашбордам инфры и трекеру.

Конкретные метрики, которые имеет смысл смотреть:

• Cycle time — от момента, когда задача взята в работу, до релиза.
• Lead time — от появления задачи в бэклоге до релиза.
• Deployment frequency — как часто команда катит в прод.
• Change failure rate — какой процент релизов приводит к инцидентам.
• Spillover rate — какой процент задач переносится из спринта в спринт.

Это так называемые DORA-метрики плюс понятие из скрама. Не надо мерить всё сразу — выбрать 3–4 и смотреть в динамике.

Что не мерить

Некоторые метрики выглядят логично, но на практике портят команду.

Количество коммитов / строк кода. Хороший разработчик может закрыть задачу одним коммитом, плохой — двадцатью. Меряя количество, вы поощряете шум.

Время за компьютером. Сидеть в офисе с 9 до 21 не значит работать. Многие задачи решаются в голове на прогулке.

Количество тикетов. Тикет тикету рознь. Один может быть «поправить опечатку», другой — «переписать платежи».

Story points отдельных людей. Это коллективная единица оценки команды, не личная. Использовать индивидуальные пойнты для оценки — путь к манипуляциям.

KPI без контекста. Если команда не понимает, зачем мы это меряем — она научится игнорировать или гейминг метрики.

Главное правило: метрика, которую невозможно «накрутить», лучше метрики, которую легко.

Как собирать данные

Большую часть данных не надо собирать вручную — она лежит в системах:

• Jira / Linear — cycle time, lead time, spillover.
• GitHub / GitLab — частота релизов, размер PR, время ревью.
• Sentry / Bugsnag — баги в проде.
• Datadog / Grafana — инциденты, аптайм.
• Дашборды продукта — влияние фич на метрики.

Раз в спринт продакт смотрит на сводку, раз в квартал — на тренды. Тратить на это больше пары часов в неделю — перебор.

Дополнительно — качественные источники. Ретро, 1:1 с тимлидом, опросы команды раз в квартал. Цифры показывают, что происходит, разговоры — почему.

Как давать обратную связь

Оценка без обратной связи — мусор. Если вы видите, что spillover вырос, но не обсуждаете это с командой — толку ноль.

Хороший формат обратной связи на ретро:

1. Показать факт: «За последние 3 спринта мы переносим 30% задач, до этого было 10%».
2. Спросить команду, что изменилось. Чаще всего ребята лучше знают.
3. Договориться об одном-двух экспериментах: меньше брать, лучше декомпозировать, дать буфер.
4. Через 2–3 спринта посмотреть, помогло ли.

Не превращать ретро в разбор виновных. Никто не будет открыто говорить о проблемах, если за это потом прилетает.

Индивидуальную обратную связь оставлять тимлиду. Продакт может высказать наблюдение через тимлида, но не делать обходы и не оценивать конкретных разработчиков напрямую.

Частые ошибки

• Сравнивать с другой командой. У команд разные задачи, стек, легаси, состав. Сравнение почти всегда несправедливо и демотивирует.
• Менять метрики каждый месяц. Тренды складываются за кварталы. Если метрика не нравится — копать причину, а не менять саму метрику.
• Использовать оценку для давления. Если команда чувствует, что метрики используются против неё — она начнёт их саботировать.
• Игнорировать качественную сторону. Цифры не покажут, что у тимлида выгорание и команда на грани. Это видно только в разговорах.
• Не делиться результатами. Если продакт меряет, но команда не видит — оценка превращается в шпионаж.

Связанные темы

• Кросс-функциональная работа продакт-менеджера
• Как продакту давать feedback команде
• Как нанимать продакт-менеджера
• Как оценить продакт-менеджера

FAQ

Должен ли продакт смотреть на индивидуальные метрики разработчиков?

Нет. Это зона тимлида. Продакт смотрит на команду как на единое целое.

Что делать, если команда стабильно не довозит?

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

Как мерить qualitative-метрики?

Через 1:1, опросы (eNPS, satisfaction), наблюдения на ретро. Шкала 1–5, простая, регулярная — и динамика во времени.

DORA-метрики работают для маленьких команд?

В целом да, но short cycles и небольшая выборка делают цифры шумными. Смотреть тренды за 6–12 недель, а не отдельные дни.

Кто отвечает за результат — продакт или команда?

Оба. Продакт — за «что и зачем». Команда — за «как и насколько хорошо». Если результата нет, копают вдвоём.

Можно ли использовать velocity для прогноза?

Да, как ориентир. Не как контракт. Velocity — это фотография прошлого, а не гарантия будущего.

---

Тренируйте продуктовое мышление — откройте тренажёр с 1500+ вопросами для собесов.