Шаблон тижневого звіту PM — як тримати прозорість і не палити час команди

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Ми ведемо багато паралельних проєктів. Один проєктний менеджер зазвичай координує 3-4 клієнтські проєкти (інколи два, якщо вони складніші). Щоб не втрачати динаміку й тримати якість стабільно високою, ми запровадили щотижневі звіти. Клієнтів не цікавить, скільки було мітингів чи листування, їх цікавить інше: чи все зроблено вчасно, у рамках бюджету, без зайвих багів і з максимальною професійністю. Саме на це спрямована наша система звітності.

У нас є Delivery Director, який щотижня переглядає результати PM-ів і відслідковує загальну картину. Кожен проєкт закріплений за конкретним PM і виділеною командою. Ми уникаємо перетину ресурсів між різними клієнтами: команда працює тільки над своїми проєктами. Це дозволяє досягати більшої глибини та стабільності. У роботі ми використовуємо Jira й тайм-трекери, а дані автоматично збираються у зведений звіт, який показує картину в порівнянні з попереднім тижнем і аналогічним періодом минулого місяця.

Які показники ми відслідковуємо

% задач з багами.

Це один з найважливіших індикаторів. Ми вважаємо допустимими лише 5-10% некритичних багів, які швидко виправляються. Якщо критичних помилок більше, це сигнал, що потрібно змінювати процеси тестування й підвищувати вимоги до перевірки завдань перед релізом.

% повторних виправлень задач.

Цей показник показує, наскільки якісно команда справляється з поставленими завданнями. Ми орієнтуємося на рівень 15-20%. Якщо показник зростає, це означає, що вимоги були нечітко сформульовані або тестування не врахувало всі сценарії.

% доробок після релізу.

Ми уважно слідкуємо, щоб цей показник не перевищував 15%. Коли після релізу доводиться переробляти велику частину функціоналу, це говорить про слабкий контроль якості ще до виходу у продакшн. Для цього ми використовуємо тестові середовища й плануємо поступові «канаркові» релізи.

% задач, закритих у строк.

Наша мета — не менше 85%. Звичайно, клієнти можуть раптово кидати термінові задачі, але ми намагаємося винести їх у наступні спринти, щоб не ламати план. Цей показник напряму показує, наскільки реалістичні наші оцінки й наскільки добре команда тримає фокус.

% задач з перенесеними строками.

Тут ми відслідковуємо, наскільки часто доводиться зрушувати дедлайни. Іноді це відбувається з незалежних причин, наприклад, затримки з боку клієнта. Але ми все одно намагаємося тримати цей рівень у межах 10-15%.

% «завислих» задач.

Якщо задача «висить» три-чотири дні без жодних змін, це сигнал для PM. Причиною може бути завантаженість команди або затримка з боку клієнта. Такі задачі ми оперативно виводимо в окремий список, щоб зрозуміти, як їх розблокувати.

Середній час виконання задачі.

Це допомагає нам оцінювати, наскільки адекватними були початкові оцінки й чи справляється команда з навантаженням. Ми не женемося за конкретною цифрою, але використовуємо її як орієнтир для планування.

Середня швидкість команди.

Показує, скільки задач команда реально може виконати за спринт. Це базовий індикатор стабільності роботи. Якщо швидкість падає, ми аналізуємо, чи проблема у кількості багів, завислих задачах або перевантаженні членів команди.

Як ми працюємо з цілями

Для кожної метрики встановлені цільові значення. Якщо показники виходять за межі норми два тижні поспіль, PM повинен знайти причину і запропонувати план дій. Якщо ситуація повторюється три тижні підряд — підключається Delivery Director і разом з командою приймає рішення, що змінювати у процесах.

Ми не ставимо планку «бетоном». Наш підхід поступовий: щотижня піднімаємо стандарти, але робимо це обережно, щоб команда зростала стабільно й без вигорання. Зараз ми також працюємо над системою бонусів для PM-ів, які досягають цільових показників. Це мотивує менеджерів працювати ще уважніше, а клієнти отримують ще більш передбачуваний результат.

Ми також підготували готовий шаблон тижневого звіту з усіма метриками, який можна використовувати у своїх проєктах. Завантажити його можна за посиланням docs.google.com/...​F2P1PKbM/edit?usp=sharing.