Шахісти високого рівня після кожної партії, навіть виграної, сідають і розбирають її. Хід за ходом. Де був сильний хід, де слабкий, де суперник міг покарати й не покарав, де сам пропустив краще продовження. Цей розбір іноді триває довше за саму партію. Аматор після виграшу радіє, після програшу злиться й іде грати наступну. Професіонал учиться на кожній. Різниця в рівні через рік виходить величезною.
Компанії здебільшого грають як аматори. Проєкт закінчився, усі видихнули, хтось отримав премію, хтось догану, і одразу наступний проєкт. Помилки, які коштували тижнів і грошей, за місяць забуваються. А за пів року повторюються в новому проєкті, і всі щиро дивуються: як же так, знову?
Ретроспектива це не пошук винних
Одразу застережу головне, бо саме на цьому спотикається більшість спроб. Ретроспективний аналіз це не розбір польотів в армійському сенсі, де шукають, кого покарати. Щойно розбір перетворюється на пошук винних, люди починають захищатися, приховувати помилки й перекладати відповідальність. І аналіз втрачає сенс, бо найцінніша інформація, про те, що насправді пішло не так, лишається несказаною.
Цивільна авіація давно це зрозуміла. Розслідування авіаційних подій побудоване на принципі: мета зрозуміти, що сталося, а не покарати. Пілоти повідомляють про свої помилки й небезпечні ситуації, бо знають, що повідомлення використають для покращення системи. Саме тому авіація стала одним із найбезпечніших видів транспорту. Не тому, що пілоти не помиляються, а тому, що кожна помилка стає уроком для всіх.
Якщо на ретроспективі шукають винного, наступного разу помилку просто сховають. Шукайте не хто, а чому.
Три запитання, з яких усе починається
Можна вигадати складні формати з картками й кольоровими стікерами, і іноді вони корисні. Але суть будь-якої ретроспективи зводиться до трьох запитань.
- Що пройшло добре і це треба закріпити? Удачі розбирають рідше, ніж невдачі, і дарма. Якщо не зрозуміти, чому щось вийшло, наступного разу це не повториться.
- Де ми втратили час, гроші чи нерви? Конкретно: на якому етапі, через що, скільки.
- Що саме ми змінимо в наступному циклі? Не «будемо уважнішими», а конкретна дія з конкретним відповідальним.
Третє запитання найважливіше й найчастіше провалене. Ретроспектива без змін це просто спільна скарга на життя. Приємно виговоритися, але нічого не змінюється. Правило, яке я використовую: на виході ретроспективи має бути від однієї до трьох змін, не більше. Кожна має відповідального й термін. На наступній ретроспективі насамперед перевіряємо, чи зробили.
Як проводити, щоб був толк
Із практики кілька речей, які сильно підвищують користь.
Починайте з фактів, а не з думок. Відновіть хронологію: що відбувалося й коли. Які були домовленості, коли змінилися вимоги, коли виявили проблему. Дивовижно, наскільки по-різному учасники памʼятають той самий проєкт. Хронологія вирівнює картину й прибирає суперечки «а я думав, що...».
Копайте до кореня. Зірваний термін це симптом, а не причина. Чому зірвали? Бо пізно отримали дані від клієнта. Чому пізно? Бо не домовилися, хто їх запитує. Чому не домовилися? Бо на старті не було переліку залежностей. Оце вже причина, і її можна виправити на рівні процесу. Метод «пʼяти чому» звучить наївно, але працює.
Керівник говорить останнім. Якщо першим висловиться начальник, решта підлаштується під його думку. Хай спершу скажуть ті, хто робив роботу руками.
Записуйте. Підсумки ретроспективи мають потрапити в базу знань компанії, інакше за рік нова людина наступить на ті самі граблі, бо не знала, що вони там лежать.
Не лише для проєктів
Ретроспективи зазвичай повʼязують із командами розробки та Scrum, де їх проводять кожні два тижні. Але той самий підхід працює на рівні всієї компанії. Раз на квартал зібратися з ключовими людьми й чесно подивитися: що вийшло, що ні, які рішення виявилися правильними, які ні. Які клієнти принесли прибуток, а які лише клопіт. Які процеси допомагають, а які стали бюрократією. Це не замінює стратегічного планування, але робить його значно точнішим, бо планування без аналізу минулого будується на тих самих ілюзіях, що й минулий план.
Ми в Ingello проводимо розбір після кожного клієнтського проєкту й після кожного великого внутрішнього експерименту. Багато наших сьогоднішніх правил роботи, від того, як ми оцінюємо проєкти, до того, як оформлюємо прототипи, виросли саме з таких розборів. Кожне правило це колись наступлені граблі.
Що зробити завтра
Візьміть останній завершений проєкт чи етап. Зберіть на годину тих, хто в ньому брав участь. Почніть із хронології, потім три запитання: що закріпити, де втратили, що змінюємо. Заборонте шукати винних і говоріть останнім. На виході запишіть не більше трьох змін із відповідальними й датами. За місяць перевірте, що з цього зроблено. Якщо бодай одну зміну справді впроваджено, Ви вже граєте не як аматор.
