«Мета» в IT: теорія обмежень для тих, хто не хоче в бізнес-школу, але мусить релізити

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

Привіт, DOU! Я Роман Поботін, Lead AQA / SDET з понад 10 роками досвіду в індустрії. За цей час я пройшов шлях від Intern QA Engineer до ліда команди, провів близько 200 співбесід і бачив десятки різних процесів розробки.

Зазвичай я ділюся короткими думками у соцмережах, але ця тема занадто масштабна для одного поста. Навряд чи хтось у здоровому глузді намагається «натягнути» класичну теорію управління заводом 80-х років на сучасну розробку ПЗ, але саме в книзі Еліяху Ґолдратта «Мета» (The Goal) я знайшов можливі відповіді на питання: чому ми так багато працюємо, але так повільно релізимо?

Особистий рестарт: 2016 vs 2026

Вперше цю книгу я прочитав у 2016 році, коли навчався на магістратурі з менеджменту. Це був лише мій перший рік роботи у QA, і тоді сприйняття було максимально приземленим та технічним. Я бачив у ній інструкцію для «цеху», де все зрозуміло і лінійно.

Сьогодні, через 10 років рефлексій, успіхів та помилок, я перечитав її знову. Тепер я бачу її кардинально інакше — не як технічний посібник, а як глибоку філософію процесів. Це усвідомлення того, що локальна оптимізація окремої ролі часто є ворогом для результату всієї команди.

Про що ця стаття

Ця стаття — не про тестування, вона про те, як працює вся команда (Backend, iOS, Android, QA, Product Owner, Designer, Business Analyst) як єдиний потік цінності.

Книгу «Мета» зазвичай вивчають на MBA як бізнес-новелу про порятунок заводу через керування верстатами та запасами. На перший погляд це максимально далеко від світу розробки та двотижневих спринтів. Але якщо подивитися глибше, наш SDLC (Software Development Life Cycle) — це такий самий потік (flow).

Важливо розставити крапки над «і»: ми звикли звинувачувати QA в затримках, але в реальності «вузьке місце» може бути де завгодно:

• У Business Analyst, який не встигає описувати вимоги або адаптувати їх до змін після знаходження помилок чи зміни пріоритетів.
• У Product Owner, який не встигає апрувити вимоги.
• У дизайнера, який малює повільніше, ніж кодять розробники.
• У DevOps, який став вузьким горлечком деплою.

Теорія обмежень (TOC) вчить нас дивитися на команду як на єдиний організм. Якість — це спільна справа всієї команди, і помилково вважати, що за неї відповідає лише QA.

Три показники. Про що ми насправді звітуємо

Забудьте про складні метрики ефективності окремих працівників. Ґолдратт каже, що для успіху системи нас цікавлять лише три речі.

Пропускна здатність (Throughput)

Це швидкість, з якою фічі стають доступними клієнту. Важливо: написаний код, який лежить у Git, або білд, який тухне в очікуванні деплою — це ще не результат. Throughput зараховується лише тоді, коли клієнт почав користуватися функціоналом. Якщо Backend написав API, але Mobile ще не інтегрував — Throughput = 0.

Приклад. Уявіть, що ви розробили ідеальну кнопку «Купити в один клік». Backend написав логіку, Designer зробив її красивою, а QA перевірив на стейджингу. Але поки застосунок не пройшов рев’ю в App Store і реальний покупець не зміг на неї натиснути — ваш Throughput дорівнює нулю. Ви витратили ресурси, але система ще не «заробила» цінність.

Запаси (Inventory)

Це наше незавершене виробництво (Work in Progress — WIP). Все, у що ми вклали гроші, але ще не «продали» клієнту: написані специфікації, готові макети, код на стадії Code Review, тікети в колонці «Ready for QA».

Чому надлишок запасів — це отрута для команди? Багато менеджерів люблять, коли у кожного розробника черга завдань на місяць вперед. Але в TOC це катастрофа:

• Заморожені гроші. Компанія вже заплатила зарплату аналітикам і дизайнерам, але продукт не приносить користі.
• Ризик застарівання. Поки фіча лежить у величезному беклозі чи в черзі на тестування, вимоги ринку змінюються. Ми ризикуємо випустити те, що вже нікому не потрібно.
• Прихований хаос. Величезні запаси створюють «шум». Це як «тестовий шум», коли за кількістю ми втрачаємо сенс. За горою некритичних задач ми втрачаємо фокус на справді важливих речах.

Приклад. У вас є 15 повністю готових макетів у Figma для нового профілю користувача, які Business Analyst вже перетворив на тікети в Jira. Але Backend-команда ще навіть не починала розробку API під ці екрани. Ці макети — це ваші «запаси», які «припадають пилом» і не приносять жодної цінності.

Операційні витрати (Operating Expense)

Гроші, які ми спалюємо щодня, щоб система працювала. Це зарплати, оренда офісу, хмарні сервіси. Будь-яка активність, яка не наближає нас до релізу (наприклад, мітинги заради мітингів або генерація звітів, які ніхто не читає), збільшує витрати, не впливаючи на пропускну здатність.

Приклад. Команда місяцями розробляла та ретельно тестувала критичну фічу. Все під контролем. Але перед самим релізом відповідальний QA зі сторони клієнта вирішує зібрати 20 людей (всю команду та стейкхолдерів) в одну зустріч на годину, щоб вони просто «поклацали» продукт у пошуках багів.

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

Локальна ефективність vs. Продуктивність системи

У багатьох командах панує культ локальної ефективності. Це ситуація, коли кожен окремий спеціаліст (чи то Backend, чи QA) завантажений роботою на 100%. Ми звикли вважати, що якщо розробник «горить» роботою і видає код пачками, то він — топ-перформер. Але з точки зору системи це не завжди так.

• Локальна ефективність — це здатність окремого «вузла» (людини чи відділу) працювати з максимальною потужністю. Наприклад, коли розробник пише тести чи код максимально швидко.
• Продуктивність системи — це здатність усієї команди наближатися до мети, тобто релізити цінність. Ваш результат — це результат усієї команди, а не окремо закритих тасок.

Порівняльна таблиця

У чому пастка?

• Створення хаосу. Максимізація швидкості там, де немає обмеження, лише роздуває технічний борг та запаси.
• Тестовий шум. Надлишок коду без можливості його вчасно перевірити перетворюється на баласт, що демотивує команду.
• Ілюзія прогресу. 100 закритих тасок у Jira не мають значення, якщо жодна з них не потрапила до релізу через затор на етапі тестування чи апруву.
• Втрата фокусу. Справжній лід розуміє, що результат системи — це не сума зусиль кожного, а швидкість проходження фічі через усі етапи.

Справжній Senior чи Lead розуміє: інколи для того, щоб вся команда стала продуктивнішою, комусь одному потрібно... Зупинитися. Якщо ваша робота не несе цінності для фінального релізу прямо зараз, вона може бути просто «баластом», який заважає іншим.

Пляшкові та не пляшкові горлечка. Як знайти свого «Гербі»?

У книзі був персонаж Гербі — найповільніший хлопчик у поході, який визначав швидкість усього загону. В IT ми називаємо це «пляшковим горлечком» (Bottleneck).

Як відрізнити:

• Пляшкове горлечко (Bottleneck) — ресурс, потужність якого менша або дорівнює попиту на нього. Потік застрягає саме тут.
• Не пляшкове горлечко (Non-bottleneck) — ресурс, який має надлишкову потужність. Вони часто простоюють, і це нормально.

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

• Якщо розробники чекають на макети — пляшкове горлечко у дизайні.
• Якщо розробники простоюють без задач — пляшкове горлечко у Business Analysis / Product Owner.
• Якщо задачі висять у статусі «Ready for QA» — пляшкове горлечко у тестуванні.

Магія малих партій. Чому «вдвічі менше» — це «втричі швидше»

У книзі герої змогли врятувати завод, просто урізавши партії деталей удвічі. В розробці ПЗ це працює ідеально через зменшення розміру User Story.

Коли ми беремо в роботу величезну «epic-фічу» на 3 тижні розробки, ми створюємо гігантський «Запас» (Inventory), який рухається по системі як тромб.

Зменшення партій дає:

• Швидкий фідбек. QA може перевірити перший ендпоінт API вже сьогодні, а не чекати, поки буде готовий весь модуль.
• Менше помилок. Знайти та виправити баг у 50 рядках коду значно дешевше, ніж дебажити 5000 рядків перед релізом.
• Скорочення Lead Time. Час від ідеї до релізу падає в рази, бо потік стає рівномірним, без пікових навантажень.

П’ять кроків фокусування. Як розширити обмеження

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

1. Знайти обмеження (Identify). Зрозумійте, хто саме гальмує потік зараз.
2. Експлуатувати (Exploit). Зробіть так, щоб вузьке місце не витрачало час дарма. Якщо це QA — заберіть у нього мітинги та написання документації, нехай тільки тестує. Тут важливо автоматизувати рутину, а не мислення.
3. Підпорядкувати все інше (Subordinate). Це найважче психологічно. Всі інші (не пляшкові горлечка) повинні працювати в ритмі обмеження. Це означає, що іноді розробникам треба зупинитися і не писати новий код, щоб не створювати нові запаси, а допомогти розгребти завал (наприклад, написати автотести). Пам’ятайте: інколи ми маємо підстрахувати колег, щоб зробити продукт кращим разом.
4. Розширити (Elevate). Тільки тепер ми інвестуємо. Тут на допомогу приходить автоматизація, використання AI як мультиплікатора або найм персоналу.
5. Повторити. Увага! Як тільки ви розшили одне місце, обмеження перестрибне на інше. Процес вдосконалення нескінченний.

Практичний кейс. Коли QA стає «пляшковим горлечком»

Уявіть класичну ситуацію: розробники працюють як скажені, але реліз стоїть, бо «тестування занадто довге». Розберемо це через алгоритм.

Крок 1. Знайти свого «Гербі» (Identify)

Відкриваємо Jira. Колонки розробників майже порожні (або вони починають 101-шу нову фічу), а в Ready for QA «висить» 40 тікетів. Це і є ваш «Гербі». Пропускна здатність усієї команди зараз дорівнює швидкості одного-двох тестувальників.

Крок 2. Витиснути максимум без бюджету (Exploit)

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

• Геть порожні мітинги: забороніть QA ходити на 2-годинні «синки», де він просто слухає. Кожна хвилина на мітингу — це мінус одна перевірена фіча.
• Приберіть рутину: нехай розробник сам підготує тестові дані або напише скрипт для цього. QA не має витрачати годину на створення «юзера з особливими правами» вручну.
• Жодного «вайб-тестингу»: скасуйте хаотичні зідзвони на 20 людей для «демонстрації сирих фіч». Це створює шум, але не наближає реліз.

Крок 3. Підкорити систему обмеженню (Subordinate)

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

• Стоп-кран для розробників: замість того, щоб брати нову задачу і збільшувати «завал», розробники йдуть на допомогу: пишуть автотести, фіксять баги в оточенні або самі проганяють частину регресії.
• Логіка проста: краще одна фіча в продакшені, ніж десять «майже готових» у колонці QA.

Крок 4. Прокачати обмеження (Elevate)

Тільки якщо попередні кроки не допомогли — інвестуємо ресурси:

• Автоматизація: впроваджуємо автотести, які реально економлять дні ручної роботи.
• AI-асистенти: використовуємо ШІ для генерації складних тест-кейсів чи моків.
• Найм: тепер можна шукати ще одного інженера, бо ви точно знаєте, що система вперлася у фізичну межу.

Крок 5. Не дати інерції перемогти (Repeat)

Як тільки ви «розшили» QA, ви помітите магію: тепер «Гербі» переїхав. Наприклад, Product Owner не встигає апрувити готові фічі, або BA не готує вимоги вчасно. Не зупиняйтеся — починайте цикл заново для нового вузького місця.

Замість висновку. Професійна «сродність» та сила команди

Чому я, як QA Engineer, пишу про менеджмент потоку? Тому що переконаний: ми не повинні бути просто виконавцями.

Справжня «сродна праця» — це коли ти розумієш, як твій внесок впливає на кінцевий результат і не відчуваєш себе просто «клікатором». Це перехід від мислення «я свою задачу зробив» до мислення «ми доставили цінність клієнту».

Теорія обмежень вчить нас найголовнішого: локальна оптимізація — ворог системи. Якщо дизайнер малює макети на рік вперед, а розробники не встигають — дизайнер не молодець, він шкідник, що створює запаси. Якщо розробники пишуть код, який QA не встигають перевіряти — це не продуктивність, це марнотратство.

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

P.S. Це не магія, і з першого разу може не «злетіти»

Давайте будемо реалістами: прочитати статтю про завод і застосувати її до живої команди розробників — це дві великі різниці.

У книжці все відбувається в контрольованому середовищі, де деталі не змінюють свою форму посеред конвеєра. У нас же вимоги мутують, API ламаються, а люди вигорають. Спроба механічно накласти теорію обмежень на IT без зміни культури може призвести до ще більшого хаосу або мікроменеджменту.

Цей текст — не інструкція до дії «роби раз, роби два». Це спроба змінити вектор мислення: перестати дивитися на свою роботу як на ізольований острів і побачити всю річку цілком.

Якщо ця тема вас зачепила, я дуже раджу не зупинятися на цій статті. В ідеалі — прочитайте оригінал Еліяху Ґолдратта. Якщо ж часу на цілу книгу немає (ми ж всі працюємо в IT, я розумію), то хоча б перегляньте цей короткий екскурс в теорію (PDF), щоб зрозуміти математику процесу.

Будуйте процеси, які працюють на вас, а не проти вас.

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