Zero backlog за 12 місяців: прискорення у 4 рази, що змусило бізнес благати про паузу

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

Привіт! Мене звати Сергій Жердієв, і я Product Manager у холдинговій IT-компанії Boosta. У цьому кейсі хочу поділитись, як за рік ми з команди, де 52% беклогу складалися з багів, прийшли до порожнього беклогу, 4 днів Lead Time і 2–3 релізів на тиждень. Далі — коротко про шлях і практичні інструменти, які ви можете одразу застосувати у своїй команді.

Ця стаття буде корисною не тільки безпосередньо для Product Manager, а і в першу чергу для Project Manager, оperation-спеціалістів, лідерів технічних команд або керівників стартапів, які відчувають невизначеність у процесах розробки.

Важлива ремарка: інформація наближена до реальних даних через NDA.

5 сигналів, що ваш проєкт потоне без зміни процесів

Перш ніж розповісти про наш шлях, поділюся ключовими маркерами, які сигналізують про критичні проблеми:

• 20%+ Reopens — кожна п’ята задача повертається на доопрацювання після тестування.
• Беклог росте швидше за тестування — ви генеруєте задачі швидше, ніж встигаєте їх перевіряти.
• Немає чіткої оцінки задач — розбіжність між оцінкою та реальністю понад 30%.
• Деплойне тестування > 8 годин — ви витрачаєте більшу частину робочого дня на перевірку перед релізом.
• Релізи раз на 2+ тижні — ви не встигаєте швидко реагувати на зміни ринку.

Якщо ви впізнали свою команду хоча б у трьох пунктах — читайте далі.

Проблема: де ми були

У липні 2023 року наша команда перебувала в критичному стані:

• Не було QA — тестування виконували бізнес-підрозділи.
• 52% беклогу — баги — половина всіх задач була технічним боргом.
• Деплойне тестування: 54 людиногодин — на 1 реліз.
• Lead Time: 18–21 день — від ідеї до продакшну проходило три тижні.
• Релізи раз на 2–3 тижні — повільна реакція на потреби бізнесу.
• Розбіжність оцінок: 40% — планування не працювало.

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

Рішення, які ми впровадили

У жовтні 2022 року у ролі Product Manager я прийшов ще до не зовсім великої стартап-команди, яка розробляла вебпродукт. Протягом року я займався продуктовою роботою і саме так зіткнувся з болями бізнес-юнітів, коли завдання рухалися геть повільно — попри те, що вистачало ресурсу команди розробки.

Оскільки в мене було системне мислення і необхідний бекграунд, я проявив ініціативу в усуненні блокерів, і ми з керівництвом вирішили тимчасово змінити мою роль на Project Manager. Мені довірили очолити трансформацію процесів розробки. Це був виклик, але я розумів: якщо не покращимо систему зараз, команда просто згорить. Нижче розповім детально, що ми змінили.

1. QA та процеси тестування

Суть: найняли in-house QA-спеціаліста замість тестування силами бізнесу.

Як переконав CEO: провів аналіз часових витрат команди. Показав, що SEO-команда витрачає 54 людиногодин на кожен деплой і пропускає критичні баги, що призводить до 500-х помилок, що неприпустимо для SEO-продукту.

Ключовий результат: через три місяці скоротили деплойне тестування з 54 до 12 годин, через рік — до 1 години.

2. Перейшли на Story Points і метрики

Суть: відмовилися від оцінки в годинах на користь Story Points за шкалою 1–3.

Чому саме 1–3:

• 1 SP — проста задача, декілька десятків хвилин.
• 2 SP — середня задача, день-два роботи.
• 3 SP — комплексна задача або невизначена.

Важливо: ми не прив’язували Story Points до годин — це груба помилка. У нашому випадку задача в 1 SP — це легко, 2 SP — середньої важкості та недовго, 3 SP — невизначеність.

Як навчили команду: використав американську літературу (Gerald M. Weinberg «Quality Software Management») для підготовки до змін.

Ключовий результат: розбіжність між оцінкою та реальністю знизилася із 40% до 18% за квартал.

3. Змінили методологію: Scrum → Kanban

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

Чому Scrum не працював:

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

Що впровадили в Kanban:

• Тижневі цикли замість двотижневих спринтів.
• Дейлі-стендап до 10 хвилин (ранкова зарядка + швидка зміна пріоритетів за потреби в термінових кейсах).
• Планування + грумінг кожен четвер (1–1,5 години разом).
• Демо + ретроспектива кожні два тижні (статистика + інсайти).
• Календар відпусток у Google Sheets (коефіцієнт доступності від 0 до 1).

Ключовий результат: Lead Time скоротився з 18–21 дня до 9 днів за квартал.

4. Розклали процес на Lead/Cycle Time

Суть: декомпозували цикл розробки на чотири етапи та почали вимірювати кожен у днях.

Етапи життєвого циклу задачі:

1. Initial Time — підготовка задачі (постановка, рев’ю з Project Manager-ом, пріоритизація разом із Head of Product, грумінг із замовниками та технічною командою).
2. Development Time — розробка задачі (включно з TODO статусами).
3. Testing Time — тестування задачі (включно з TODO статусами).
4. Deploy Time — деплой.

Формули:

• Cycle Time = Development Time + Testing Time
• Lead Time = Initial Time + Cycle Time + Deploy Time

Що виявили: найбільші батлнеки були на стадії підготовки й тестування.

Як виправили:

• Створили Handbook-документ із шаблонами задач (систематизували через ШІ всі таски за кілька років).
• Впровадили структуру user story: Reason (чому?) → Action (що?) → Acceptance Criteria (який результат?).
• Найняли ще двох QA-спеціалістів (беклог тестування наповнювався у 2 рази швидше, ніж команда встигала тестувати).

Ключовий результат: Lead Time знизився до 4 днів, Cycle Time — до 2 днів.

5. Автоматизували планування через WIP-ліміти

Суть: впровадили метрику WIP-ліміту (Work In Progress) для прогнозування пропускної здатності команди.

Як рахуємо WIP-ліміт. Формула:

Приклад розрахунку:

1. Історичні дані: команда в середньому закриває 30 задач на тиждень.
2. На наступному тижні один розробник у відпустці (коефіцієнт 0,8).
3. WIP-ліміт = 30 × 0,8 = 24 задачі.
4. Наприкінці тижня після деплою звільнилося 5 слотів.
5. На плануванні озвучуємо: можемо взяти 5 нових задач.

Додатково: поділили потік на два типи — ASAP (термінові) й загальний потік. Якщо потрапляє ASAP-задача, виділяємо ресурс і швидко випускаємо на продакшн.

Ключовий результат: передбачуваність планування зросла, команда перестала перевантажуватися.

Метрики ефективності: що ми відстежували

Наш перехід на систему оцінювання почався з того, що я провів аналіз поточної ситуації за допомогою інструментів аналітики Jira. Вбудовані, базові репорти показали, що розробники оцінювали задачу в умовні 4 години, реальність показувала розбіжність від 6 до 8 годин. На всьому обсягу задач ми мали похибку, непорівнянну з реальністю. Це приводило до того, що ми неправильно оцінювали свої можливості й планували задачі з overhead.

Після того, як ми перейшли на вищезгадані Story Point, з’явилася необхідність у додаткових метриках. Розповім про них детальніше далі.

Ефективність процесів

На етапі життєвого циклу команди в методології скрамбану ми використовували число Story Point, виконаних за попередній проміжок часу для планування наступного. Пізніше ми прийшли до метрик пропускної здатності команди, Lead Time і Cycle Time.

• Lead Time — повний цикл від створення до релізу.
• Cycle Time — час розробки + тестування.
• Deployment frequency — частота релізів.
• Failure rate — відсоток багів у беклозі.

Головне, що ми почали робити, це декомпозувати цикл розробки задачі на чотири основні етапи:

• Підготовка задачі (постановка, рев’ю, пріоритизація, грумінг).
• Розробка задачі.
• Тестування задачі.
• Деплой.

Ефективність спеціалістів

Для зниження числа критичних багів необхідно було зробити суворіше ставлення до пропуску таких багів на продакшн. Перша та значуща метрика, яка фігурувала в перформанс-калькуляторах технічних спеціалістів, це Reopens — відсоток перезапуску задачі після тестування до загального числа виконаних задач за квартал.

Друга — метрика перформансу. Ми пройшли декілька стадій для того, щоб отримати її в тому вигляді, у якому вона є зараз:

Стадія 1. Просто міряли, скільки Story Point виконував розробник за квартал. Після цього ми зрозуміли, що такий підхід неорганічний через time-off, коли розробник із будь-яких причин не може закривати свій скоуп робіт.

Стадія 2. Почали рахувати, скільки Story Point виконує розробник у середньому за день протягом спринту (два тижні). Такий підхід також був неефективним, оскільки задачі на три Story Point могли переходити зі спринту в спринт, що негативно впливало на метрику на широких діапазонах і не вирішувало проблему відпускних днів. Уже на цьому етапі ми застосовували такий самий підхід і до тестувальників, за винятком функції, яку вони виконували. Тут ми базувалися на загальній оцінці складності задачі від розробника, але не давали оцінювати задачі тестувальникам, оскільки оцінки корелювали в 95% випадків. Якщо розробник оцінив задачу на два Story Point, то і тестувальник оцінював задачу так само.

Стадія 3. Трансформація в метрику «потужності». На цій стадії ми врахували всі можливі чинники та привели метрику до спільного знаменника. Ми вже перебували в канбан-методології.

Метрика «потужності» (фінальна версія):

Що враховуємо:

• Тільки бізнес-задачі (баги не зараховуються).
• Час від стадії «взято в роботу розробником» до «передано тестувальнику».
• Час на реворк також входить у знаменник.

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

Що виключили: вплив відпусток, хвороб та інших зовнішніх чинників.

Результат: де ми опинилися

Впровадження всіх цих підходів було супершвидким і місцями нелогічним, у нас були злети й падіння метрик, однак через рік ми змогли прийти до статусу 0 беклогу. Це дало змогу нам зайнятися тими рефакторингами, на які в команд часто не буває часу.

Фінальні метрики:

У жовтні 2024 року, після року роботи Project Manager, я повернувся на роль Product Manager. Процеси були налагоджені, команда працювала як годинник, і настав час знову фокусуватися на продукті.

Checklist: як повторити трансформацію за 90 днів

За перші 30 днів

Тиждень 1–2: Аудит поточного стану

• Порахуйте час на деплойне тестування (у людиногодинах).
• Виміряйте відсоток багів у беклозі.
• Зафіксуйте поточний Lead Time (від створення задачі до релізу).
• Порахуйте розбіжність між оцінкою та реальністю виконання задач.
• Виміряйте Reopens (відсоток повернень задач після тестування).

Тиждень 3–4: Впровадження базових метрик

• Перейдіть на Story Points (шкала 1–3 для простоти).
• Навчіть команду оцінювати задачі (проведіть воркшоп).
• Почніть відстежувати Reopens для кожного спеціаліста.
• Створіть простий дашборд у Google Sheets або Jira.

За 60 днів

Тиждень 5–6: Впровадження QA

• Обґрунтуйте CEO необхідність QA, якщо його немає (використайте цифри з аудиту).
• Найміть in-house QA-спеціаліста.
• Створіть базу документації для QA (чеклісти, критичні сценарії).
• Проведіть онбординг із фокусом на специфіку продукту.

Тиждень 7–8: Перехід на Kanban

• Проведіть ретроспективу: чому Scrum не працює.
• Впровадьте тижневі цикли замість двотижневих спринтів.
• Налаштуйте дейлі-стендап до 10 хвилин.
• Створіть календар відпусток із коефіцієнтами доступності.

За 90 днів

Тиждень 9–10: Налаштування Lead Time / Cycle Time

• Декомпозуйте процес на етапи (Initial → Development → Testing → Deploy).
• Почніть вимірювати кожен етап у днях.
• Знайдіть батлнеки (найдовші етапи).
• Створіть план усунення батлнеків.

Тиждень 11–12: Впровадження WIP-лімітів

• Порахуйте середню пропускну здатність команди за тиждень.
• Впровадьте формулу WIP-ліміту з урахуванням відпусток.
• Поділіть потік на ASAP і загальний.
• Налаштуйте планування на основі історичних даних.

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

Замість висновку: 4 принципи, що працюють

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

2. Навчіться домовлятися. Ви на перетині двох вогнів: команда розробки й бізнес-замовники. Задача Project Manager — гасити вогонь і приводити до перемир’я. Щотижневі демо + ретро стали нашим головним інструментом комунікації.

3. Мисліть системно. Думайте спочатку про проблему, а потім про її рішення, не навпаки. Ми не наймали QA, поки не зрозуміли, що проблема саме в тестуванні, а не в розробці.

4. Метрики — ваша зброя. Без цифр ви не зможете переконати CEO, команду чи себе. Кожне рішення має бути підкріплене даними.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.