# Ретроспектива продукта — как провести и какие решения принять Ретроспектива в промышленной компании обычно заканчивается одним из двух способов: либо совещанием, где все по очереди рассказывают, что мешало работать, либо поиском ответственного за недобор плана. Оба варианта не дают того, ради чего встречу собирали, — понимания, что именно из наших действий сработало, а что нет, и что мы поэтому меняем. Разбираю формат, который у меня работает на квартальных итогах и на разборах пилотов. ## Разделить разбор фактов и разбор людей Практика безоценочного разбора пришла из инженерных команд и из военных послеоперационных обзоров, и суть её одна: пока участники защищаются, они не говорят правду, а без правды разбор бесполезен. Разбирается не человек, а система — почему принятое решение выглядело разумным в тот момент, какой информации не хватало, что в процессе позволило ошибке дойти до последствий. Безоценочность не отменяет ответственности. У каждого вывода есть владелец и срок, требования к работе остаются прежними. Разница в направлении: ответственность смотрит вперёд, на изменения в процессе, а не назад, на виноватого в уже случившемся. Для B2B-продукта с длинным циклом у этого есть практическое следствие. Между решением и его результатом проходят месяцы, за которые меняется рынок, курс, состав команды у заказчика. Назначать виноватого за результат, отстоящий от решения на полгода, бессмысленно технически — связь между действием и итогом слишком слабая. Разбирать имеет смысл качество самого решения на момент, когда оно принималось: какие данные были, какие альтернативы рассматривались, что мы тогда считали правдой. ## Шаг 1. Собрать факты до встречи, а не на ней Главная причина пустых ретроспектив — разбор начинается с воспоминаний. Через квартал участники помнят не события, а свою интерпретацию событий, и встреча превращается в спор интерпретаций. Я готовлю фактурную основу заранее: план и факт по деньгам, движение сделок по этапам с датами, список гипотез, которые проверялись, с результатом по каждой, перечень вех — выполненных и просроченных, с фактической датой. Отдельно — что изменилось во внешних условиях. Эта сводка рассылается за день-два, чтобы на встрече обсуждали не цифры, а их причины. По итогам пилота добавляется ещё один блок: что мы обещали себе проверить и что фактически проверили. В ретроспективе одного MVP на экспортном направлении именно эта сверка оказалась главным содержанием — часть заявленных гипотез так и не была проверена, потому что ресурс ушёл на операционку, и это был более важный вывод, чем результаты тех гипотез, до которых дошли руки. ## Шаг 2. Пройти четыре вопроса, а не свободное обсуждение Свободный формат «что было хорошо, что плохо» даёт ровно тот результат, который заслуживает, — список жалоб и список благодарностей. Рабочая структура жёстче. Что мы предполагали в начале периода. Формулируются исходные гипотезы и планы в том виде, в котором они были, без задним числом улучшенных формулировок. Что произошло на самом деле. Только факты из подготовленной сводки, без объяснений. Объяснения на этом шаге запрещены — они всплывают позже и мешают увидеть расхождение. Где расхождение и почему. Здесь разбирается каждая значимая разница между ожиданием и фактом. Ключевой вопрос по каждой: это ошибка гипотезы, ошибка исполнения или изменение внешних условий. Три разных диагноза с тремя разными выводами. Ошибка гипотезы — меняем продукт или сегмент. Ошибка исполнения — меняем процесс, людей или ресурс. Внешние условия — меняем план, но не логику. Что делаем иначе. Конкретные изменения с владельцем и сроком, не больше трёх-пяти. Список из пятнадцати улучшений не выполняется никогда. ## Шаг 3. Дойти до решения о судьбе продукта Ретроспектива направления отличается от разбора спринта тем, что на выходе должно быть решение не только про процесс, но и про сам продукт. Вариантов всего четыре: продолжаем как есть, продолжаем с изменением, ставим на паузу, закрываем. Этот выбор нужно делать явно и вслух. По умолчанию всегда срабатывает первый вариант — продолжаем как есть, — причём не потому, что он обоснован, а потому что никто не вынес вопрос на обсуждение. Так направления живут годами на остаточном финансировании, не давая ни результата, ни высвобождения ресурса. На квартальной ретроспективе по одному направлению вывод оказался не про темп работы, а про саму продуктовую рамку: каталожные решения не находили спроса, и продукт разворачивался в сторону кастомизации под конкретные задачи заказчика. Никакая работа над исполнением внутри старой конструкции этого бы не дала. На другом направлении итог MVP был прямо противоположным — гипотеза не подтвердилась на цифрах, и правильным решением стала остановка, а не ещё один квартал попыток. Как принимается такое решение по формальной процедуре, я разбирал отдельно: [[Как принять решение закрыть продукт или направление]]. ## Шаг 4. Зафиксировать так, чтобы к этому вернулись Выводы ретроспективы умирают в протоколе встречи. Чтобы этого не происходило, изменения должны переехать в те документы, по которым команда реально работает: в план следующего периода, в регламент процесса, в критерии квалификации, в шаблон расчёта. Запись «улучшить взаимодействие с производством» изменением не является. Второй элемент фиксации — проверка выполнения на следующей ретроспективе. Первый пункт повестки — что мы решили в прошлый раз и что из этого сделано. Без этой сверки ретроспектива превращается в ритуал: одни и те же проблемы всплывают каждый квартал, всем это заметно, и доверие к формату исчезает. ## Частые ошибки Проводить ретроспективу только после неудач. Разбор успешной сделки полезнее, потому что даёт воспроизводимый механизм, а не список того, чего избегать. После крупного закрытого контракта имеет смысл разобрать, что именно сработало и можно ли это повторить. Собирать только свою команду. В промышленном продукте решения принимаются на стыке продаж, производства и финансов, и разбор без смежников описывает четверть картины. Смешивать ретроспективу и планирование в одной встрече. Планирование всегда побеждает — разбор сворачивают, чтобы успеть обсудить следующий квартал. Лучше два отдельных сеанса, причём разбор первым. Уходить в поиск виноватого при разборе денег. Как только речь заходит о недоборе плана, формат ломается быстрее всего. Помогает жёсткое правило: сначала полный проход по фактам и расхождениям, персональные разговоры — после и отдельно. Формулировать выводы так, что их невозможно проверить. «Стали лучше понимать рынок» — не вывод. «Убрали из целевого профиля сегмент N, потому что за квартал ни одна сделка не дошла до КП» — вывод. ## Вывод Ретроспектива продукта — это процедура с фактурой, подготовленной заранее, жёсткой структурой из четырёх вопросов и обязательным решением о судьбе направления на выходе. Разбирается качество решения на момент его принятия, а не результат спустя полгода, и разбирается система, а не человек. Проверка полезности простая: если по итогам не изменился ни один рабочий документ и ни одна цифра в плане следующего периода, встреча была разговором, а не ретроспективой. ## Мои кейсы по теме - [[Ретроспектива MVP в Индии]] - [[Ретроспектива продукта быстровозводимых конструкций]] - [[Ретроспектива и план на второй квартал]] - [[Итоги MVP аутсорсинга персонала АПК]] ## Связаться Если у вас похожая задача — обсудим ваш продукт: [[email protected]](mailto:[email protected]), Telegram [@falcolupus](https://t.me/falcolupus) или [MAX](https://max.ru/u/f9LHodD0cOJd5VFHyaG9k7YpP7BW9s55ZYkjWX6P8j51xBYS3XgDfnOxz3U). Работаю удалённо в любом часовом поясе.