Ретроспектива хакатона: как разобрать опыт команды без поиска виноватых
Как провести ретроспективу после хакатона: восстановить события, отделить факты от оценок, выбрать улучшение и договориться о его проверке в следующей работе.
После финала легко объяснить всё одним событием: победили благодаря идее или проиграли из-за сбоя. Такая история удобна, но редко помогает работать лучше. Ретроспектива рассматривает решения, взаимодействие и условия, которые команда может изменить в следующий раз.
Договоритесь о встрече, когда участники смогут спокойно обсудить опыт. Не превращайте её в обязательный разбор сразу после бессонной работы или эмоционального объявления результатов. Цель встречи состоит в выборе полезного изменения, а не в вынесении оценки каждому человеку.
Отделите разбор работы от судьбы проекта
Решение продолжать продукт и обсуждение командного процесса связаны, но требуют разных вопросов. Проект может оказаться неперспективным при хорошей совместной работе. И наоборот, сильная идея не устраняет проблемы с передачей задач и проверкой сборки.
В Scrum Guide ретроспектива предназначена для поиска улучшений качества и эффективности. Для хакатонной команды можно использовать сам принцип осмысленного разбора; это не означает, что вся её работа автоматически становится Scrum.
Если нужно обсудить дальнейшее развитие, выделите отдельное время и используйте план продолжения после хакатона. Тогда разговор о владельце будущего продукта не вытеснит вопросы о том, почему текущая сборка появилась слишком поздно.
Восстановите короткую хронологию
Соберите опорные события: выбор сценария, первый запуск, смена решения, консультация, общая сборка, запись и сдача. Используйте заметки, историю задач и сохранённые версии. Не нужно восстанавливать каждую минуту; достаточно моментов, которые изменили ход работы.
Попросите участников сначала записать свои наблюдения самостоятельно. Так менее разговорчивые люди получают возможность внести опыт до того, как группа примет объяснение самого уверенного выступающего. Затем объедините записи и уточните расхождения.
Разделяйте событие и оценку. «Первый общий запуск был за час до дедлайна» описывает проверяемый момент. «Мы плохо планировали» является выводом, который ещё нужно разобрать. Начинайте с первого и выясняйте, какие решения к нему привели.
