Перевірка вигод і ретроспектива без пошуку винних

Критерії успіху проєкту мають дві половини, і перевірити їх можна в різний час. Виконання (дата, бюджет, обсяг) вирішується в день запуску. Результат — чи зробив запуск те, заради чого був, — потребує часу, щоб статися.

У Klasna фізика відкрилася 1 лютого, у межах бюджету, з дев’ятьма репетиторами. 15 лютого цю половину можна перевірити й чесно назвати. Половину результату — ні: 120 учнів, які купили пакет до 28 лютого, і троє з чотирьох, які досі ходять на четвертому тижні. Кількість бронювань у середині лютого — сигнал прогресу, а не перевірка.

Саме тому перевірка вигод (benefits check) відбувається через тижні після запуску й порівнює результат із критеріями, записаними в брифі, а не з тим, яким запуск здавався. День запуску показує, що команда виконала роботу; він не може показати, чи родини прийшли й лишилися.

Тож Leo може оголосити про виконання сьогодні. Оголошення про успіх має почекати на числа, інакше це слово означає лише, що проєкт закінчився.

Перевірка вигод вимірює кожен критерій тоді, коли число може існувати, і позначає кожне ще раннє число. Перевірка завчасно дає не гірше число, а інше — про меншу групу.

У Klasna ціль бронювань діє до 28 лютого, тож бронювання перевіряють 1 березня. З відвідуваністю на четвертому тижні складніше. Учень, який купив 20 лютого, доходить до четвертого тижня лише в середині березня. На 1 березня показник відвідуваності охоплює тільки покупців першого тижня, невелику групу, тож він ранній і має це казати. Повна перевірка для всіх, хто купив у лютому, — 28 березня.

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

Перевірка вигод існує, щоб вирішити, що буде далі: що виправити, що лишити і що припинити. Вона дивиться лише вперед.

Тому вже витрачені гроші для рішення не мають значення. У Klasna до лютого витрачено більшу частину стелі в 600 000 грн. Якщо бронювань менше за ціль, спокусливо сказати, що витрати зобов’язують компанію продовжувати, доки все не окупиться. Але витрачені гроші пішли, хоч що обере Klasna; вони не аргумент ні за, ні проти. Це те саме правило про витрачене, що й під час перепланування, тепер застосоване в кінці проєкту.

Правильні питання дивляться вперед. Де саме результат не дотягнув до критеріїв? Скільки коштуватиме кожен наступний крок звідси і що він змінить? Слабкий крок воронки може бути дешево виправити; цілий напрям може бути варто зупинити. Будь-яка відповідь походить із порівняння результату з критеріями й варіантів між собою, а ніколи — з того, що вже оплачено.

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

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

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

Ретроспектива проєкту (project retrospective) озирається на те, як ішов проєкт, щоб знайти, що наступний має робити інакше. Ретроспектива без звинувачень дивиться на факти й рішення, а не на людей: що ми знали, що обрали і що план зробив імовірним.

У Klasna проблему з тестом знайшли за три дні до відкриття, і Danylo готовий узяти провину на себе: «це був мій тест». Погляд без звинувачень починається з іншого. Факт: перевірку на телефоні з розривом зв’язку провели 28 січня. Рішення: у листопаді план поставив приймання на останній тиждень. Тож корисне питання — чому план поставив цю перевірку так пізно. Відповідь Vira: у листопаді ніхто не записав відключення як умову тесту — ні Danylo, ні вона, ні план.

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

Ретроспектива найкраще працює як фіксована послідовність, щоб обговорення рухалося від того, що сталося, до того, що змінюється:

1. Зібрати факти: хронологію й дані.
2. Розглянути рішення і те, що було відомо, коли їх ухвалювали.
3. Знайти, що в плані чи процесі зробило такий результат імовірним.
4. Погодити щонайбільше три дії, кожну з власником і датою.
5. Внести дії в шаблони й чеклісти, якими користуватиметься наступний проєкт.

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

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

У Klasna «тестувати раніше» — правильний урок і марна дія: ні власника, ні дати, ні місця, де житиме зміна, тож ніхто її не виконає. Робоча версія: «До чекліста запуску додається перевірка на телефоні з розривом зв’язку на першому демо. Власник: Danylo. До 15 березня». Вона змінює документ, яким користуватиметься наступний запуск, тож спрацює, навіть якщо цей проєкт ніхто не пам’ятатиме. Як каже Danylo, це зміна чекліста, а не обіцянка старатися більше.

Є ще дві пастки. Обіцянка про людину («Danylo уважніше ставитиметься до тестів») нічого не змінює й порушує правило без звинувачень. Список із дванадцяти покращень, «які треба пам’ятати», — це жодного: без власників і з надто багатьма пунктами всі вони згасають. Лишай щонайбільше три дії, кожну з власником і датою.

Проєкт закривається підсумковим звітом, що вміщається на одну сторінку й закінчується підписом спонсора. У ньому:

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

У Klasna сторінка йде до Leo, і проєкт закривається, коли він її підписує. Дві речі туди не входять: список того, хто спричинив кожну затримку, що порушує правило без звинувачень, і переписка проєкту, яка ховає відповідь, заради якої існує сторінка.

Звіт короткий навмисно. Його читачі — спонсор сьогодні й лід наступного проєкту через рік, і обом потрібні ті самі кілька фактів.

Як це складається докупи: перевір виконання зараз, а результат — коли він існує, вирішуй, дивлячись уперед, учися без звинувачень і лиши дії з власниками у звіті на одну сторінку. Останній кейс застосує все це до реальних лютневих чисел.