7.2 Ретроспектива и оценка проекта
Хорошо вести проект во время исполнения важно, но что по-настоящему укрепляет следующий проект — то, что происходит после завершения текущего: рефлексия и оценка.
В этом разделе мы рассмотрим, как одновременно рефлексировать о результатах, процессе, команде и организации и как использовать структурированные методы, чтобы выводить наружу успехи, которые стоит повторять, и ошибки, которые стоит избегать.
Почему ретроспективы важны
Когда проект заканчивается, большинство участников сразу переходят к следующему заданию. Если пропустить ретроспективу, обычно остаётся:
- Факторы успеха, которые никто не может чётко назвать — и поэтому не может повторить
- Ошибки и упущения, которые незаметно повторяются
- Инсайты, застрявшие в голове одного человека и не доходящие до команды
Ретроспектива — не про обвинение прошлого, это стратегический ход, чтобы повысить шансы следующего проекта.
Четыре измерения ревью проекта
Чтобы получить целостную картину, смотрите на проект под четырьмя углами:
- Результаты: были ли цели достигнуты? качество, поставка, стоимость, удовлетворённость
- Процесс: были ли эффективны планирование, отслеживание прогресса и управление изменениями?
- Команда: была ли понятна совместная работа, роли и коммуникация?
- Среда: были ли подходящими внешние факторы — стейкхолдеры, структура, инструменты?
Взгляд на все четыре сдвигает разговор с «получилось / не получилось» к инсайтам с реальной глубиной.
Методы оценки: KPT, 5 «почему», 360-градусная обратная связь
KPT (Keep / Problem / Try)
- Keep: что сработало хорошо и должно продолжаться
- Problem: что не сработало
- Try: идеи для улучшения
5 «почему»
Доводите проблемы до корня, спрашивая «почему?» пять раз подряд. Это уводит за пределы симптомов и приводит к настоящей причине.
360-градусная обратная связь
Соберите обратную связь со всех вовлечённых, чтобы команда увидела себя с разных углов — это вскрывает динамики, которые с одной точки зрения было бы не заметить.
Использование AB для ретроспектив
AB даёт ретроспективе на что опереться:
- Просматривайте истории задач и комментарии, чтобы увидеть, как реально текли решения
- Используйте burndown- и Гант-представления для анализа темпа и того, где появлялись задержки
- Делитесь шаблонами ретроспектив (формат KPT) как общими документами
- Собирайте откровенную обратную связь через анонимные комментарии или опросы
В итоге получается ревью, основанное на фактах и движимое диалогом, а не соревнование по памяти.
Как сделать ретроспективы устойчивыми
Чтобы ретроспективы не сползли в ритуал:
- Назначайте их как часть закрытия, а не как опциональное дополнение
- Вовлекайте всю команду, а не только PM
- Стройте разговор как улучшение, направленное в будущее, а не поиск виноватых
- Возвращайте результат в шаблоны проектов и WBS для следующего раза
Резюме: ретроспективы запускают улучшение
Ретроспектива — не о сожалении о прошлом, а о проектировании лучшего следующего проекта. Превращать инсайты в общее командное знание, а не в личные уроки, — признак учащейся команды.
Как это выглядит в AB
В AB Project Management страница «Ретроспектива» в Wiki проекта фиксирует KPT в формате, который сможет искать следующая команда. Закрепите её на главной проекта — это первое, что увидит любой позже. Задачи с тегом Урок несут индивидуальные выводы с владельцами — а AI-ассистенты, подключённые через MCP, можно попросить обобщить историю изменений проекта в черновик ретроспективы, чтобы стартовать обсуждение.
→ Далее перейдите к статье 7.3 Передача знаний для будущих проектов и узнайте, как фиксировать и передавать уроки эффективно.