Недавно помогал коллеге готовиться к ретро, он помочь попросил. Кейс такой: у них провалился проект, и буквально всё пошло не так:
1. Сорвали сроки.
2. Огромный перерасход бюджета.
3. Почти по каждой задаче фактические затраты разработчиков превысили оценки.
4. Конверсия упала, пользовательский путь запутался.
5. Куча ошибок прямо на релизе, из‑за чего службу поддержки неделю держали на переработках.
Нужно было разобраться, как проводить такие ретроспективы, где и как собирать информацию, какие этапы у ретро, что готовить заранее, а что разбирать с командой. Ещё разобрались, кого приглашать, какие выводы получить и как затем применять их в работе, чтобы встреча не стала мероприятием ради мероприятия.
У ребят своя специфика, но то, что мы используем в продуктовых командах, не сильно отличается — адаптируйте под свою компанию, команду и особенности, и можно применять.
Первое, что нужно сделать — обозначить общую проблему, желательно одной фразой, например: «+83 % человеко‑часов, сорван релиз, ошибки на основных пользовательских пулях в проде».
После того как проблему обозначили, собираем все данные, которые доступны. Понимаю, что не у всех производство обложено метриками и дашбордами. Чтобы собрать инфу, пересматривать запись каждого дейли наверное не нужно, но попытайтесь собрать максимум. При проблеме, сформулированной выше, сразу приходит в голову:
• план/факт часов из трекера;
• список дефектов;
• история коммитов и релизов;
• все изменения требований и сметы;
• ключевая коммуникация и этапы принятия решений.
На этапе сбора информации очевидные проблемы, которые раньше почему-то не замечали, могут бросаться в глаза, фиксируйте их в сводке, например: четыре месяца правок копили на тестовом стенде, а не проводили регулярные релизы.
Если команда небольшая, соберите информацию с каждого до общей встречи. Проведите с людьми интервью один на один, запишите проблемы и причины, которые они видят. Особенно полезно делать это заранее, когда накоплено взаимное недовольство: снимает напряжение, чтобы на встрече обсуждать факты, а не обвинять друг друга.
Составляем сводку на доске в Миро. Таблицы кому‑то удобны, но доска нагляднее. Выписываем:
• проблему;
• гипотезы причин от команды;
• метрики и цифры, которые удалось собрать;
• при желании — цепочки событий и принятых решений.
Сама ретроспектива. Проводить стоит онлайн. Ребята думали, что часа хватит, но выяснилось, что нужно 2-3, иначе объемный проект не обсудить.
• Открываем встречу. Объясняем, что ищем причины и пути улучшения, чтобы в следующий раз не допустить факапов; фокус на фактах, а не на обвинениях.
• Разбираем причины. Методик куча, но можно разложить на четыре стрима. Для проблемы «копили изменения четыре месяца» получается:
Записываем всё, что нашли. Банально, но не критикуйте в моменты сбора причин. Сначала вытягиваем всё, что можем, потом отсекаем лишнее.
• Генерируем решения вместе с командой. Опять же, любой фреймворк приоритезации, хоть точками голосуйте, главное - это отсеять лишнее и выделить основные решения, которые затем распределим по людям.
• Выделенные решения можно оформить по SMART, назначить ответственных и поставить дедлайны, ну, сами знаете :)
Обычно не делают, но кажется полезным. Занесите результаты ретро во внутреннюю базу знаний. Если её нет, самое время завести: без фиксации выводы теряются, ошибки повторяются, команда топчется на месте.
Когда будете копаться в старых переписках, может показаться, что занимаетесь фигней, много работы, а реальные задачи «горят». Но без таких разборов сложно построить систему, которая будет учиться на своих ошибках и не повторять худшие сценарии. Попробуйте у себя несколько раз, думаю, что поможет.
1. Сорвали сроки.
2. Огромный перерасход бюджета.
3. Почти по каждой задаче фактические затраты разработчиков превысили оценки.
4. Конверсия упала, пользовательский путь запутался.
5. Куча ошибок прямо на релизе, из‑за чего службу поддержки неделю держали на переработках.
Нужно было разобраться, как проводить такие ретроспективы, где и как собирать информацию, какие этапы у ретро, что готовить заранее, а что разбирать с командой. Ещё разобрались, кого приглашать, какие выводы получить и как затем применять их в работе, чтобы встреча не стала мероприятием ради мероприятия.
У ребят своя специфика, но то, что мы используем в продуктовых командах, не сильно отличается — адаптируйте под свою компанию, команду и особенности, и можно применять.
Первое, что нужно сделать — обозначить общую проблему, желательно одной фразой, например: «+83 % человеко‑часов, сорван релиз, ошибки на основных пользовательских пулях в проде».
После того как проблему обозначили, собираем все данные, которые доступны. Понимаю, что не у всех производство обложено метриками и дашбордами. Чтобы собрать инфу, пересматривать запись каждого дейли наверное не нужно, но попытайтесь собрать максимум. При проблеме, сформулированной выше, сразу приходит в голову:
• план/факт часов из трекера;
• список дефектов;
• история коммитов и релизов;
• все изменения требований и сметы;
• ключевая коммуникация и этапы принятия решений.
На этапе сбора информации очевидные проблемы, которые раньше почему-то не замечали, могут бросаться в глаза, фиксируйте их в сводке, например: четыре месяца правок копили на тестовом стенде, а не проводили регулярные релизы.
Если команда небольшая, соберите информацию с каждого до общей встречи. Проведите с людьми интервью один на один, запишите проблемы и причины, которые они видят. Особенно полезно делать это заранее, когда накоплено взаимное недовольство: снимает напряжение, чтобы на встрече обсуждать факты, а не обвинять друг друга.
Составляем сводку на доске в Миро. Таблицы кому‑то удобны, но доска нагляднее. Выписываем:
• проблему;
• гипотезы причин от команды;
• метрики и цифры, которые удалось собрать;
• при желании — цепочки событий и принятых решений.
Сама ретроспектива. Проводить стоит онлайн. Ребята думали, что часа хватит, но выяснилось, что нужно 2-3, иначе объемный проект не обсудить.
• Открываем встречу. Объясняем, что ищем причины и пути улучшения, чтобы в следующий раз не допустить факапов; фокус на фактах, а не на обвинениях.
• Разбираем причины. Методик куча, но можно разложить на четыре стрима. Для проблемы «копили изменения четыре месяца» получается:
– Процессы: нет плана релизов, ритма поставок;
– Люди: на проекте не было техлида, который полностью отвечал за проект;
– Технологии: нулевое покрытие тестами;
– Требования: после согласования основных контрактов вносились изменения в ТЗ и макеты.
Записываем всё, что нашли. Банально, но не критикуйте в моменты сбора причин. Сначала вытягиваем всё, что можем, потом отсекаем лишнее.
• Генерируем решения вместе с командой. Опять же, любой фреймворк приоритезации, хоть точками голосуйте, главное - это отсеять лишнее и выделить основные решения, которые затем распределим по людям.
• Выделенные решения можно оформить по SMART, назначить ответственных и поставить дедлайны, ну, сами знаете :)
Обычно не делают, но кажется полезным. Занесите результаты ретро во внутреннюю базу знаний. Если её нет, самое время завести: без фиксации выводы теряются, ошибки повторяются, команда топчется на месте.
Когда будете копаться в старых переписках, может показаться, что занимаетесь фигней, много работы, а реальные задачи «горят». Но без таких разборов сложно построить систему, которая будет учиться на своих ошибках и не повторять худшие сценарии. Попробуйте у себя несколько раз, думаю, что поможет.