З технічного погляду бізнес-процес поводиться як будь-яка інша система з пропускною здатністю. Коли потік на вході зростає, система підказує це затримками у певних місцях. У розробці такі затримки помічає моніторинг навантаження на сервіс. В операційній роботі компанії ми відстежуємо їх через п'ять метрик замість дашбордів. Вони показують, де процес варто підсилити, щоб він масштабувався разом із компанією.

Час циклу

Час циклу показує, скільки минає від моменту, коли задача заходить у роботу, до моменту, коли вона завершена. Це найчесніша метрика зі всіх, бо її неможливо підробити оптимізмом на планерці. Задача або пройшла систему за три дні, або пройшла за три тижні.

Небезпечний сигнал з'являється тоді, коли час циклу росте, хоча самої роботи в задачі не побільшало. Розробники пишуть код у тому ж темпі, рішення ухвалюються без затримок, а задача чомусь усе одно повзе до фінішу довше, ніж раніше. Уся втрачена швидкість ховається в паузах між активними діями, коли задача просто лежить і чекає своєї черги. І що швидше росте компанія, то довшими стають ці простої.

Кількість передач між командами

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

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

Ручні втручання

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

Технічно тут бракує автоматизації на критичному шляху роботи. Поки компанія маленька, ручні кроки коштують дешево. Варто їй вирости вдвічі, і ті самі кроки перетворюються на постійне джерело затримок та помилок.

Повторна робота

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

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

Ескалації

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

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

Метрики міняють саме процес

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

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

За таким підходом стоїть позиція, на якій ми в SharksCode будуємо роботу. Людина для нас залишається головною цінністю. Саме тому наша увага спрямована на систему. Виконавців ми не контролюємо. Коли інженер цілий тиждень руками зводить звіт чи шукає загублений контекст, ці витрачені години насправді коштують компанії набагато дорожче. Адже так втрачається час, який можна було б витратити на складнішу і цікавішу роботу. Метрики перевантаження показують саме ці місця, де рутина забирає в команди простір для головного. Кожне виправлення цей простір повертає.