Не плач за мною, Velocity

Друге видання Agile Practice Guide від Project Management Institute підтверджує те, до чого багато хто з нас прийшов нелегким шляхом: фреймворк ніколи не був найголовнішим.

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

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

Дев'ять років між двома виданнями

Перший Agile Practice Guide вийшов у 2017 році, коли в PMI були проблеми з репутацією. Розробники вважали, що PMBOK це діаграми Ганта й краватки, а в повітрі витав слух, що Agile остаточно скасує проєктних менеджерів.

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

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

Фреймворки додають одинадцять пунктів до ймовірності успіху

За даними Pulse of the Profession 2026 від PMI, успішними стають 72% проєктів із фреймворком і 61% проєктів без нього. До того ж 35% фахівців з управління проєктами зізнаються, що їхній останній складний проєкт жив узагалі без жодного конкретного фреймворка. Подумайте, скільки наша індустрія витратила на сертифікати та заламіновані постери зі спринтовими циклами, і погляньте на чек. Одинадцять пунктів.

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

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

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

Velocity розповідає, що сталося, але ніколи не скаже чому

Як я читаю нове видання, velocity лишається особистим інструментом команди, і не більше. Нею не варто нікого оцінювати. Стара порада вийти на стабільну velocity за чотири-вісім ітерацій зникла, а разом із нею й розділ про earned value.

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

Дайте людям цифру, і вони її принесуть. Квоти продажів у Wells Fargo підштовхнули тисячі працівників до шахрайства, і 2020 року банк заплатив 3 мільярди доларів, щоб закрити справи з DOJ та SEC. Story points ніхто не роздуває до таких масштабів, але завищених оцінок я бачила достатньо, щоб упізнати сам механізм.

Тому PMI веде команди до потоку, тобто до cycle time, work in progress і кумулятивних діаграм потоку. Прогнози радить подавати як шанси, наприклад 85% імовірності закінчити до червня, бо зобов'язання обіцяє зусилля, а не гарантує результат. Вимірюйте систему, в якій працює людина, а потім додайте метрики, які клієнт цінував би ще більше, як-от задоволеність чи дохід на користувача.

Ваша ретроспектива схожа на ситуацію із заручниками

Уявіть звичайну ретроспективу в Zoom. Камери вимкнені, учасників вісім, говорять двоє. Фасилітатор звертається до тих, хто мовчить, чує щось невиразне і починає картати себе. Цей ритуал можна повторити сто разів, і нічого не зміниться, бо бракує головного, безпеки.

1996 року Емі Едмондсон дослідила вісім відділень медсестринського догляду в лікарнях і побачила протилежне до того, що очікувала. Відділення з найсильнішим керівництвом виявляли найбільше помилок із ліками, від 2,3 до 23,7 на тисячу пацієнто-днів. Її висновок був такий: хороші лідери не множили помилки, просто медсестри з ними не боялися про помилки говорити. Згодом Google упродовж двох років, починаючи з 2012-го, вивчав 180 команд і поставив психологічну безпеку на перше місце серед п'яти знайдених чинників.

Волонтери PMI, які працювали над посібником, почули цей натяк. У першому виданні безпеці дісталося рядок чи два, а в другому їй присвячено окремий розділ, з рівнями та описом того, що лідер винен команді.

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

Ось вам експеримент. Оберіть одну команду, приберіть velocity зі всіх звітів на один квартал, поставте мету підвищити її психологічну безпеку і перед стартом прочитайте розділ про психологічну безпеку в Agile Practice Guide. Революції не потрібні.

Де посібник розчаровує

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

Кожен розділ завершується півсторінковою секцією про Gen AI, і вони тонкуваті, тож поруч з окремим стандартом PMI про ШІ виглядають дописаними нашвидкуруч. Початківці також марно шукатимуть, що таке story point, що показує burndown-діаграма і як зібрати кросфункціональну команду, бо цю роботу досі виконує старе видання, і прочитати варто спершу його. А оскільки PMI не називає переможця, свобода вибору лягає на ваші плечі. Для зрілої команди це добре, для незрілої проблема, а таких і досі вистачає.

Куди це, на мою думку, рухається (мій прогноз, не PMI)

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

PMO, який існує, щоб ганятися за проєктними менеджерами з віником і вимагати оновлень, замінить AI-дашборд. А earned value, частина про гроші, виживе під новою назвою, імовірно, з «product» усередині.

У чому насправді ваша робота

Моя менті нещодавно помітила, що її Copilot пише статус-звіти краще за неї, і глянула на мене так, ніби я застала її на крадіжці. Я сказала їй ось що.

Це ніколи не була твоя робота.

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

Тож моє запитання до вас.

Якби завтра ваші інструменти написали всі звіти з вашого календаря, що залишилося б таке, що можете зробити лише ви? І чи добре ви це вмієте?

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

Джерела: PMI, Agile Practice Guide Second Edition та Pulse of the Profession 2026, випуск про складні проєкти. Amy Edmondson, дослідження 1996 року про вісім лікарняних відділень медсестринського догляду (огляд). Google re:Work, Project Aristotle (огляд). Меморандум Paul Weiss для клієнтів про врегулювання справ Wells Fargo з DOJ та SEC, лютий 2020 року.