ретроспектива проєкту (project retrospective)
Також називають: ретроспективи проєкту, ретроспективу проєкту, ретроспектива без пошуку винних, ретроспектива, ретроспективи
Зустріч наприкінці проєкту чи етапу, на якій команда розбирає, що сталося, чому і що зробити інакше наступного разу. Вона без пошуку винних: питає, що в плані, процесі чи інформації призвело до результату, а не хто винен, і закінчується кількома змінами з власниками.
Ретроспектива проєкту (project retrospective) — це зустріч наприкінці проєкту чи етапу, на якій команда розбирає, що сталося, чому, і що наступний проєкт має зробити інакше. Її результат — не відчуття завершеності, а кілька конкретних змін із власниками.
Добра ретроспектива — без пошуку винних. Вона дивиться на факти й рішення, а не на людей: що ми знали тоді, що обрали і що в плані, процесі чи інформації зробило такий результат імовірним? Причина практична. Коли ретроспектива шукає винного, люди вчаться приховувати проблеми, а план, який створив проблему, лишається тим самим. Оцінювати рішення за тим, що знали на момент його ухвалення, а не за тим, як усе обернулося, також допомагає уникнути упередження заднім числом.
Корисний порядок: зібрати факти (хронологію, дані), розглянути ключові рішення та інформацію, на якій вони трималися, знайти причини в плані чи процесі й погодити не більше трьох дій, кожна з яких каже, що змінюється, хто відповідає і до коли. «Краще комунікувати» і «уважніше тестувати» — не дії; «до чекліста запуску додано перевірку X на етапі Y, власник Z, до дати D» — дія.
Уроки, що лишилися на слайді, наступний проєкт забуде. Уроки, записані в шаблони, чеклісти й дані для оцінок, використовують навіть ті, хто не був на зустрічі. Порівняння оцінок із фактом з минулих ретроспектив — одні з найкорисніших вхідних даних для планування наступного проєкту.
Приклад
Запуск фізики в Klasna стартував 1 лютого 2027 року, але за три дні до старту, 28 січня, команда виявила, що діагностичний тест ламається на телефонах при обриві зв'язку. У лютому на телефонах завершили лише 35 % розпочатих тестів проти 64,71 % на комп'ютерах, а телефони дали 67,92 % усіх початих тестів.
Запитання з пошуком винного звучало б так: «Чому Danylo це пропустив?». Версія без пошуку винних: що ми знали в листопаді і чому план поставив перевірку на телефонах на останній тиждень? Відповідь стосується плану: ніхто (ні Danylo, ні Vira, ні план) не записав відключення й слабкий зв'язок як умову тестування, а приймальне тестування поставили на самий кінець.
Нотатки з чернетки, переписані як дії:
Попередні ретроспективи Klasna вже показують, чому друга дія важлива: у трьох минулих запусках 142 оцінені дні перетворилися на 168 фактичних (168 ÷ 142 = 1,18), а найбільше перевищували строки перевірки — у 1,688 раза.
Типові помилки
- Шукати винного. Пошук винних учить приховувати проблеми й лишає план без змін; питайте, що план зробив імовірним.
- Судити заднім числом. Оцінюйте рішення за тим, що знали на момент їх ухвалення.
- Забагато дій. Дванадцять дій означають жодної; лишайте не більше трьох.
- Розмиті дії. «Краще комунікувати» не має ні власника, ні дати; пишіть, що змінюється, хто і до коли.
- Лишати уроки на слайді. Вносьте їх у чеклісти, шаблони й дані для оцінок, якими користуватиметься наступний проєкт.
Вивчити в курсі
- Перевірка вигод і ретроспектива без пошуку винних · Як перевірити результат через кілька тижнів після запуску за критеріями успіху, провести ретроспективу на фактах і рішеннях, перетворити уроки на дії з власниками й закрити проєкт звітом на сторінку.