Дата публікації:
Публікація:
Керівник відкриває картку проєкту й бачить: 68% виконано, дедлайн через три тижні. Через три тижні проєкт не закривається. Ще через два — теж. При цьому жодна з цифр не була неправдивою: відсоток рахувався коректно, дедлайн стояв той, що погодили.
Це поширена ситуація, і пояснення в неї не таке очевидне, як здається. Річ не в поганій дисципліні звітування й не в тому, що хтось приховував проблеми. Річ у тому, що обидва показники за своєю природою описують намір, а не реальність.
Відсоток виконання й дедлайн належать до одного класу величин: вони описують, як проєкт мав би виглядати відносно початкового плану. Це метрики наміру. Вони корисні для комунікації із замовником і безпорадні як інструмент управління, бо вимірюють відхилення від рішення, ухваленого в момент, коли про проєкт було відомо найменше.
Є інший клас показників — ті, що описують не план, а поведінку роботи. Скільки разів завдання поверталося на доопрацювання. Наскільки систематично команда помиляється в оцінках і в який бік. Скільки часу робота не виконувалася, а чекала. Ці величини не порівнюють реальність із планом — вони показують саму реальність, і тому здатні пояснити те, чого не пояснює відсоток.
Ці два класи показників лежать в основі того, як влаштований SalesUp Project Management for Creatio, доступний на Creatio Marketplace з липня 2022 року. Діаграма Ґанта в ньому — те, що зазвичай очікують побачити першим. Але поруч із нею на фоні працює набір розрахунків історії змін статусів, який описує не план, а механіку роботи команди.
Показник, який рідко читають правильно, — кількість разів, коли завдання вже вважали завершеним, а потім повертали в роботу.
Прийнято сприймати цю цифру як оцінку виконавця. За логікою процесу, систематичні повернення частіше вказують на дефект формулювання, ніж виконання. Завдання, яке тричі закривали й тричі відкривали, зазвичай було описане так, що допускало кілька прочитань — і кожна ітерація була спробою вгадати, яке з них мали на увазі.
Цінність цієї метрики розкривається на масиві. Одиничне повернення нічого не означає. Але коли їх видно по десятках завдань, з’являється розподіл: певний тип робіт, певний замовник вимог, певна стадія проєкту. Це вже діагноз, і лікується він на етапі аналізу, а не на етапі виконання. Саме тому кількість повернень входить до переліку розрахунків, які встановлюються разом із нашим продуктом за замовчуванням — не як опція для просунутих, а як базовий показник.
Друга метрика процесу — різниця між запланованим і фактично витраченим часом. Її теж часто використовують неправильно, перетворюючи на інструмент оцінювання людей.
Оцінка трудовитрат — прогноз, зроблений в умовах неповної інформації, і помилятися він буде завжди. Питання не в тому, чи є розрив, а в тому, чи він випадковий. Коли ці різниці накопичуються за кілька місяців, стає видно, наскільки вони хаотичні: розрив може виявитися систематичним для певного типу завдань або певної команди й повторюватися приблизно в тій самій пропорції.
Це не привід для розбору польотів. Це поправочний коефіцієнт, який робить наступне планування більш чесним — за умови, що дані збираються автоматично й не залежать від того, чи згадав хтось заповнити звіт наприкінці тижня.
Третя метрика — найбільш контрінтуїтивна. Це не час виконання роботи, а час перебування завдання в кожному окремому стані.
Ця величина ламає звичну картину проєкту, у якій затримка асоціюється з повільним виконанням. Календарна тривалість складається не лише з роботи, а й з очікування: завдання чекає перевірки, узгодження, звільнення потужності, рішення суміжної команди. Ця частина не видна в жодному зведеному звіті, бо звіт фіксує результат, а не паузи між результатами.
Коли керівник бачить, що вагома частка сумарного часу зосереджена на етапі перевірки, характер розмови з командою змінюється. Вона перестає бути розмовою про старанність і стає розмовою про пропускну здатність — а це вже питання, яке має рішення.
Є технічна умова, без якої попередній показник не працює зовсім.
Завдання, створене в п’ятницю о 18:00 і взяте в роботу в понеділок о 10:00, астрономічно чекало 64 години. За робочим календарем — годину або дві, залежно від графіка команди. Різниця між цими двома цифрами не косметична: без урахування календаря будь-яка метрика реакції на розподілених командах перетворюється на шум, у якому вихідні, свята й різниця часових поясів повністю з’їдають сигнал.
Для компаній, що працюють у кількох країнах, це різниця між показником, за яким ухвалюють рішення, і цифрою, яку доводиться щоразу пояснювати вголос. Тому в нашому продукті тривалість перебування в статусах рахується одночасно в кількох вимірах, включно з календарними годинами за налаштованими робочими календарями.
Окремий проєктний трекер здатен зібрати всі ці показники. Чого він не здатен зробити — це поставити їх поруч із контрактом, рахунком і фактичною вартістю години.
А саме на цьому стику метрики процесу перестають бути внутрішньою кухнею команди й починають говорити мовою бізнесу. Продукт дозволяє рахувати прибутковість проєкту й порівнювати фінансові показники в реальному часі з фактично витраченим на завдання часом та його вартістю. Це означає, що відхилення в годинах читається як відхилення в маржі — не наприкінці кварталу, після вивантаження в таблицю, а тоді, коли на нього ще можна вплинути.
Метрики не керують проєктом — ним керують люди. Але саме набір показників задає рамку розмови на статус-мітингу.
Там, де вимірюють лише відсоток і дедлайн, розмова неминуче зводиться до питання «чому ми запізнюємось» — питання, на яке немає конструктивної відповіді, бо воно спрямоване в минуле. Там, де видно повернення, розриви в оцінках і час очікування, розмова стає іншою: конкретною, з визначеною точкою прикладання зусиль.
Це не питання інструмента. Інструмент лише робить певні речі видимими або залишає їх невидимими. Але вибір того, що саме бачить команда, — уже управлінське рішення, і ухвалюють його задовго до того, як проєкт починає запізнюватися.
Найчастіше запит звучить як “нам потрібна діаграма Ґанта”. А через два місяці після впровадження команда дивиться зовсім не на неї — вона дивиться на те, скільки завдання пробуло в очікуванні. Діаграма Ґанта показує план. Історія статусів показує, що з ним сталося
— Микита Калініченко, Marketplace Leader, Sales’Up.
