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

У нас одночасно йде кілька проєктів. Один проєктний менеджер координує в середньому три–чотири клієнтські проєкти (іноді два, якщо вони складніші). Щоб не втрачати динаміку і тримати стабільно високу якість, ми запровадили щотижневі звіти.

Клієнтів не цікавить кількість мітингів чи листів - їх цікавить результат:

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

Як побудована система

У нас є Delivery Director, який щотижня переглядає результати роботи PM-ів і бачить загальну картину по всіх проєктах.

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

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

Основні показники, які ми відстежуємо

‍

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

Один із ключових індикаторів. Допустимий рівень - 5–10% некритичних багів, які швидко виправляються.

Якщо критичних помилок більше, це сигнал змінювати процес тестування або посилювати перевірку завдань перед релізом.

‍

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

Показує якість виконання. Орієнтир - 15–20%.

Якщо цей показник росте, причиною може бути нечітке формулювання вимог або неповне тестування.

‍

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

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

Для цього ми використовуємо тестові середовища і поступові «канаркові» релізи.

‍

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

Мета - не менше 85%.

Іноді клієнти додають термінові задачі, але ми намагаємось винести їх у наступні спринти, щоб не ламати план.

‍

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

Відстежуємо, наскільки часто зсуваються дедлайни.

Причини бувають різні - від перевантаження до затримки з боку клієнта.

Ми прагнемо тримати цей рівень у межах 10–15%.

‍

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

Якщо задача стоїть три–чотири дні без змін, це сигнал для PM.

Ми одразу виводимо такі задачі в окремий список, щоб зрозуміти, як їх розблокувати.

‍

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

Дозволяє оцінити адекватність оцінок і навантаження команди.

Конкретної цифри немає - важлива динаміка і реалістичність планування.

‍

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

Показує, скільки задач команда реально виконує за спринт.

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

‍

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

Для кожної метрики встановлені цільові значення.

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

Ми не ставимо планку «бетоном».

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

Зараз ми також працюємо над системою бонусів для PM-ів, які стабільно тримають цільові показники.

Це мотивує менеджерів бути уважнішими, а клієнти отримують більш передбачуваний результат.

‍

Шаблон звіту

Ми підготували готовий шаблон тижневого звіту з усіма метриками - його можна адаптувати під будь-який проєкт.

Завантажити шаблон можна у нашому Telegram каналi.