Action items — это действия, которые команда записывает в конце ретроспективы: кто, что и к какому сроку меняет в работе. Единственный критерий качества такой записи — через две недели можно однозначно ответить, сделана она или нет. Всё остальное в ретро — разогрев: встреча, после которой ничего не изменилось, была разговором, а не ретроспективой.
При этом именно на действиях ретро ломается чаще всего. Сценарий одинаковый у сотен команд: проблемы обсудили, три пункта записали, разошлись — а через две недели открыли доску и молча начали новую, потому что смотреть на прошлую неловко. Дальше — как разорвать этот цикл: формулировка, ритуал проверки и работа с хронически невыполненными задачами.
Почему action items умирают
Причин, которые покрывают почти все случаи, четыре.
У действия нет владельца. «Команда наведёт порядок в тестах» — значит, не наведёт никто: ответственность, разделённая на семерых, равна нулю. Владелец — не тот, кто делает всё сам, а тот, с кого спросят статус.
Действий слишком много. Пять-семь пунктов с одной встречи — почти гарантия, что не сделают ни одного: спринт и так полон, а список из прошлого ретро психологически уже «прошлый». Три сделанных из трёх записанных мотивируют; один из семи — добивают.
Действие сформулировано как пожелание. «Улучшить коммуникацию», «внимательнее относиться к оценкам» — у таких записей нет момента, когда они становятся выполненными. Это не действия, а лозунги.
Никто не проверяет. Самая недооценённая причина. Даже идеальные формулировки умирают, если следующая встреча начинается с чистого листа. Выполнение действий держится не на дисциплине исполнителей, а на предсказуемости проверки: все знают, что в начале следующего ретро список откроют вслух.
Первые три причины лечатся правилами формулировки — про них дальше. Четвёртая — ритуалом, и он важнее правил.
Формула рабочего action item
Рабочее действие собирается из четырёх частей: глагол результата + исполнитель + срок + признак выполнения. Признак выполнения — то самое, что отличает действие от пожелания: событие или артефакт, который либо существует, либо нет.
| Плохо | Что не так | Рабочий вариант |
|---|---|---|
| Разобраться с флаки-тестами | «Разобраться» не бывает выполненным | Оля помечает флаки-тесты в CI и заводит тикет на каждый — до конца спринта |
| Улучшить онбординг | Нет ни владельца, ни результата | Дима пишет чек-лист первой недели новичка — к следующему ретро |
| Меньше созвонов | Нет меры: меньше — это сколько? | Отменяем статусный созвон по средам на два спринта, статусы — в тред. Следит Настя |
| Обсудить с соседней командой API | «Обсудить» — процесс, не результат | Игорь договаривается с платформой о формате версионирования и приносит решение письмом — до пятницы |
Заметная закономерность: в плохих формулировках глаголы «разобраться», «улучшить», «подумать», «обсудить». В рабочих — «пишет», «отменяем», «помечает», «приносит решение». Если действие не удаётся переформулировать через глагол результата, это сигнал, что команда ещё не решила, чего хочет, — верните тему в обсуждение или честно отложите.
И про сроки. «До конца спринта» работает, «как будет время» — нет. Но не превращайте срок в дедлайн с последствиями: action item — это договорённость команды с собой, а не обязательство перед менеджером. Просроченное действие — повод спросить «что мешает», а не «кто виноват».
Сколько действий записывать
Одно-три с встречи. Это не признак слабого ретро — наоборот: команда, которая две недели подряд закрывает по два действия, за квартал меняет процесс сильнее, чем команда с семью записанными и нулём сделанных.
Тем, что не влезло, ничего не грозит. Важная тема наберёт голоса и на следующей встрече — а если не набрала, значит, команда не считала её важной уже сейчас, просто жалко было вычеркнуть.
Отдельный случай — действия, которые не помещаются в спринт: «переехать на новую версию фреймворка» за две недели не делается. Такие пункты дробите до первого шага: не «переезжаем», а «Саша собирает список блокеров переезда — к следующему ретро». Первый шаг либо сделан, либо нет, и это возвращает проверяемость.
Где действия живут после встречи
Правило простое: действия должны быть видны там, где команда работает, — а не в протоколе, который никто не откроет. Файл «retro_notes_final_2.docx» в общей папке — кладбище решений.
Минимальный рабочий вариант — закреплённое сообщение в командном чате или задачи в трекере с общим тегом. У обоих есть слабое место: к третьему ретро закрепы теряются, а тег забывают ставить.
В Scruma этот слой встроен: действие, записанное на доске во время обсуждения, автоматически живёт на странице задач команды. Там четыре вкладки — «Мои», «Открытые», «Закрытые» и «Все», просроченные подсвечены, и по каждой задаче видно, из какого ретро она пришла: можно открыть тот самый отчёт и вспомнить контекст решения. Страница открывается с вкладки «Мои» — каждый первым делом видит свои обязательства, а не общий список.
Куда бы вы ни складывали действия, держите один принцип: источник один. Если список существует в трёх местах — в протоколе, в чате и в трекере, — то настоящего среди них нет ни одного, и на следующем ретро команда будет спорить, какой из списков актуален.
Ритуал проверки: пять минут в начале следующего ретро
Единственный механизм, который надёжно держит action items живыми, — предсказуемая проверка. Работает так: первые пять минут каждого ретро — разбор действий прошлой встречи, вслух, по списку, до сбора новых карточек.
По каждому пункту — один из трёх исходов:
- Сделано — фиксируем и, если результат виден, коротко называем его. Это не формальность: сделанные действия — главное топливо формата, команда должна видеть, что ретро меняет жизнь.
- Не сделано, ещё актуально — переносим осознанно, вслух, с вопросом «что мешает». Один перенос — норма. Второй — сигнал: действие либо слишком большое (дробите до первого шага), либо не тому назначено.
- Не сделано и уже неважно — вычёркиваем без чувства вины. Устаревшее действие в списке хуже вычеркнутого: оно приучает команду, что на список можно не смотреть.
Пяти минут хватает, потому что пунктов немного — если вы записываете один-три, как выше. Если проверка съедает пятнадцать минут, проблема не в ритуале, а в длине списка.
Начинать встречу с проверки полезно ещё и психологически: разговор стартует с фактов и результатов, а не с чистого листа. Подробнее о структуре самой встречи — в пошаговом плане ретро.
Если действия хронически не выполняются
Три встречи подряд список переносится целиком — это уже не про дисциплину, это диагноз. Полезно различать три случая.
Действия не уровня команды. «Договориться с отделом безопасности об ускорении проверок» может висеть месяцами, потому что команда не управляет чужим отделом. Такие пункты — не action items, а эскалации: их нужно нести руководителю, в точной формулировке, с историей «мы упираемся в это третий спринт». Честное «мы не можем решить это сами» продуктивнее вечного переноса.
Действия-пустышки. Список выполняется на бумаге — «обсудили», «подумали», «синхронизировались» — а в работе ничего не меняется. Это ошибка формулировок, возвращайтесь к формуле с глаголом результата. Хороший вопрос для самопроверки: «что я увижу через две недели, если это сделано?» Если ответ «ничего осязаемого» — действие не действие. Больше таких вопросов — в подборке для ретроспектив.
Команда перегружена. Действия сформулированы правильно и назначены верно, но спринт не оставляет на них ни часа. Тогда договоритесь о правиле: действие из ретро — это задача спринта, она попадает в планирование наравне с продуктовыми. Изменение процесса — тоже работа, а не факультатив после работы; пока команда считает иначе, ретро будет производить списки, а не изменения.
Как это в Scruma
Когда ретро в Scruma завершается, участникам приходит письмо-отчёт, где задачи разбиты на два блока: «Ваши задачи» — отдельно, остальные — ниже. Напоминание приходит само, и отговорка «я забыл, что на мне» перестаёт работать. Полный отчёт со всеми действиями открывается по ссылке из письма.