Шахматисты высокого уровня после каждой партии, даже выигранной, садятся и разбирают её. Ход за ходом. Где был сильный ход, где слабый, где соперник мог наказать и не наказал, где сам упустил лучшее продолжение. Этот разбор иногда длится дольше самой партии. Любитель после выигрыша радуется, после проигрыша злится и идёт играть следующую. Профессионал учится на каждой. Разница в уровне через год получается огромной.
Компании в большинстве своём играют как любители. Проект закончился, все выдохнули, кто-то получил премию, кто-то выговор, и сразу следующий проект. Ошибки, которые стоили недель и денег, через месяц забываются. А через полгода повторяются в новом проекте, и все искренне удивляются: как же так, опять?
Ретроспектива это не поиск виноватых
Сразу оговорю главное, потому что именно на этом спотыкается большинство попыток. Ретроспективный анализ это не разбор полётов в армейском смысле, где ищут, кого наказать. Как только разбор превращается в поиск виноватых, люди начинают защищаться, скрывать ошибки и перекладывать ответственность. И анализ теряет смысл, потому что самая ценная информация, о том, что на самом деле пошло не так, остаётся несказанной.
Гражданская авиация давно это поняла. Расследование авиационных происшествий построено на принципе: цель понять, что произошло, а не наказать. Пилоты сообщают о своих ошибках и опасных ситуациях, потому что знают, что сообщение будет использовано для улучшения системы. Именно поэтому авиация стала одним из самых безопасных видов транспорта. Не потому, что пилоты не ошибаются, а потому, что каждая ошибка становится уроком для всех.
Если на ретроспективе ищут виноватого, в следующий раз ошибку просто спрячут. Ищите не кто, а почему.
Три вопроса, с которых всё начинается
Можно придумать сложные форматы с карточками и цветными стикерами, и иногда они полезны. Но суть любой ретроспективы сводится к трём вопросам.
- Что прошло хорошо и это нужно закрепить? Удачи разбирают реже, чем неудачи, и зря. Если не понять, почему что-то получилось, в следующий раз это не повторится.
- Где мы потеряли время, деньги или нервы? Конкретно: на каком этапе, из-за чего, сколько.
- Что именно мы изменим в следующем цикле? Не «будем внимательнее», а конкретное действие с конкретным ответственным.
Третий вопрос самый важный и самый часто проваливаемый. Ретроспектива без изменений это просто совместная жалоба на жизнь. Приятно выговориться, но ничего не меняется. Правило, которое я использую: на выходе ретроспективы должно быть от одного до трёх изменений, не больше. У каждого есть ответственный и срок. На следующей ретроспективе первым делом проверяем, сделали ли.
Как проводить, чтобы был толк
Из практики несколько вещей, которые сильно повышают пользу.
Начинайте с фактов, а не с мнений. Восстановите хронологию: что происходило и когда. Какие были договорённости, когда изменились требования, когда обнаружили проблему. Удивительно, насколько по-разному участники помнят один и тот же проект. Хронология выравнивает картину и убирает споры «а я думал, что...».
Копайте до корня. Сорванный срок это симптом, а не причина. Почему сорвали? Потому что поздно получили данные от клиента. Почему поздно? Потому что не договорились, кто их запрашивает. Почему не договорились? Потому что на старте не было списка зависимостей. Вот это уже причина, и её можно исправить на уровне процесса. Метод «пяти почему» звучит наивно, но работает.
Руководитель говорит последним. Если первым выскажется начальник, остальные подстроятся под его мнение. Пусть сначала скажут те, кто делал работу руками.
Записывайте. Итоги ретроспективы должны попасть в базу знаний компании, иначе через год новый человек наступит на те же грабли, потому что не знал, что они там лежат.
Не только для проектов
Ретроспективы обычно связывают с командами разработки и Scrum, где они проводятся каждые две недели. Но тот же подход работает на уровне всей компании. Раз в квартал собраться с ключевыми людьми и честно посмотреть: что получилось, что нет, какие решения оказались верными, какие нет. Какие клиенты принесли прибыль, а какие только хлопоты. Какие процессы помогают, а какие стали бюрократией. Это не заменяет стратегическое планирование, но делает его намного точнее, потому что планирование без анализа прошлого строится на тех же иллюзиях, что и прошлый план.
Мы в Ingello проводим разбор после каждого клиентского проекта и после каждого крупного внутреннего эксперимента. Многие наши сегодняшние правила работы, от того, как мы оцениваем проекты, до того, как оформляем прототипы, выросли именно из таких разборов. Каждое правило это когда-то наступленные грабли.
Что сделать завтра
Возьмите последний завершённый проект или этап. Соберите на час тех, кто в нём участвовал. Начните с хронологии, затем три вопроса: что закрепить, где потеряли, что меняем. Запретите искать виноватых и говорите последним. На выходе запишите не больше трёх изменений с ответственными и датами. Через месяц проверьте, что из этого сделано. Если хотя бы одно изменение реально внедрено, Вы уже играете не как любитель.
