Как подготовить ретроспективу команды с ИИ

Как подготовить ретроспективу команды с ИИ: поручите модели черновую группировку разрешённых обезличенных заметок и сверку заданных статусов прошлых действий. Обсуждение, установление причин и решения остаются за командой. ИИ работает с текстом до встречи: собирает наблюдения в темы, сохраняет исходные ID, отмечает неизвестное и формулирует вопросы. Встречу проводит человек.

Определите допустимый материал и согласуйте применение ИИ

Первый шаг — договориться, какие заметки вообще попадают в обработку. В Scrum Guide (scrumguides.org) ретроспектива описана как событие, где команда исследует, как прошёл спринт, в разрезе людей, взаимодействий, процессов, инструментов и Definition of Done, а затем выбирает самые полезные изменения. Руководство подчёркивает прозрачность: важные решения опираются на наблюдаемое состояние артефактов, а инспекция без прозрачности вводит в заблуждение.

Практический вывод для подготовки: модели отдавайте только тот материал, который команда готова видеть в общей сводке. Обезличивайте заметки заранее — уберите имена, должности, оценки конкретных людей. В условном примере ниже заметки N1–N6 не содержат имён и оценок. В реальной команде даже такие строки могут раскрывать участников по контексту; допустимость передачи проверяют отдельно.

Согласуйте обработку до сбора заметок. Зафиксируйте три вещи: какие источники заметок разрешены, кто их обезличивает и куда попадает результат. Отдельно проговорите границу роли ИИ: модель не проводит встречу, не оценивает работников и не выводит согласие команды из частоты повторений в заметках. Частое упоминание темы показывает, что о ней говорили, и не доказывает, что команда с чем-то согласилась.

Полезно развести четыре типа высказываний, которые легко смешиваются в одной куче заметок:

Такое разделение защищает от главной ошибки подготовки: модель получает сырые заметки и по инерции дописывает причины, которых в них нет. Если в заметке сказано, что задача ждала доступ два дня, это наблюдение о задержке. Причина задержки остаётся неизвестной, пока команда её не назвала.

Ещё одно согласование касается хранения. Сводка с ID исходных заметок полезна только тогда, когда сами заметки доступны для сверки. Держите их в одном месте и не редактируйте после генерации сводки: иначе ID перестанут указывать на то, что было на входе.

Соберите факты спринта и прошлые действия

Второй шаг — собрать два независимых набора данных. Первый: заметки текущего спринта. Второй: прошлые договорённости со статусом исполнения. Эти наборы отвечают на разные вопросы. Заметки описывают, что происходило. Статусы прошлых действий показывают, где договорённость исполнили; полезность результата команда проверяет отдельно.

В Scrum Guide сказано, что команда определяет самые полезные изменения для повышения эффективности, а самые значимые улучшения берутся в работу как можно скорее и могут попасть в Sprint Backlog следующего спринта. Отсюда практика: у каждого прошлого действия есть ответственный и проверочная точка.

Учебный пример, который используется дальше как условный вход. Спринт команды no-code приложения, 2–13 ноября 2026. Прошлое действие A0: перед началом сборки проверять наличие утверждённого текста, ответственный — координатор. Статус: выполнено для задач T1 и T2, для T3 не выполнено. Заметки спринта:

• N1: «T1 прошла приёмку с первого раза, использовали готовый чек-лист».
• N2: «T2 ждала доступ к тестовому аккаунту два дня».
• N3: «T3 начали без утверждённого текста, после согласования перестроили два блока».
• N4: «Мне помог готовый чек-лист».
• N5: «В единственном тесте клавиатурой нельзя было отправить форму».
• N6: «Неясно, какой доступ нужен до начала теста».

Это учебный набор. Настоящая встреча не записывалась, вызов модели не проводился; сводка ниже составлена вручную. Он показывает структуру входа: короткие обезличенные строки, у каждой свой ID, ни одной оценки человека.

Собирая факты, держите три правила. Первое: одна заметка — одна строка с ID, чтобы потом сослаться на источник. Второе: не пересказывайте заметку своими словами при сборе, иначе при сверке будет трудно понять, что было на входе. Третье: статус прошлого действия фиксируйте по задачам, где оно применялось. Запись выполнено для T1/T2, для T3 не выполнено сохраняет статус каждой задачи. Слово «частично» можно добавить как итог после этой проверки.

Проверка полноты перед генерацией: у каждой заметки есть ID, у каждого прошлого действия есть ответственный и статус, в тексте нет имён и оценок. Если хотя бы один пункт не выполнен, вернитесь к сбору. Модель не восстановит пропущенный статус и не догадается, к какой задаче относилось действие.

Дайте полный промпт нейтральной группировки

Третий шаг — передать модели весь вход одним блоком. Промпт ниже решает задачу: сгруппировать заметки в темы, сохранить исходные ID, отметить неизвестное, поставить вопросы команде и отдельно проверить прошлое действие. Скопируйте его целиком и подставьте свои строки.

Подготовь сводку к ретроспективе только из A0 и N1–N6. Таблица: тема, наблюдение, исходные ID, неизвестное, вопрос команде. Не делай оценки людей, не назначай причин и решений. Сохрани одиночную проблему формы. Отдельно проверь выполнение A0.

A0: перед началом сборки проверять наличие утверждённого текста; ответственный координатор; выполнено для T1/T2, для T3 не выполнено.
N1: T1 прошла приёмку с первого раза, использовали готовый чек-лист.
N2: T2 ждала доступ к тестовому аккаунту два дня.
N3: T3 начали без утверждённого текста, после согласования перестроили два блока.
N4: Мне помог готовый чек-лист.
N5: В единственном тесте клавиатурой нельзя было отправить форму.
N6: Неясно, какой доступ нужен до начала теста.

Что менять под себя: список строк после инструкции — [ваши заметки с ID] и [ваше прошлое действие со статусом]. Формулировки ограничений в первой части промпта оставьте: они задают нейтральность группировки. Если у вас несколько прошлых действий, добавьте их отдельными строками с тем же форматом «действие, ответственный, статус по задачам».

Вариации той же задачи, если базовый промпт нужно расширить:

1. Группировка по темам с ограничением: не больше пяти тем, остальное собери в блок прочее с ID. Проверьте, что одиночная проблема формы при этом остаётся отдельным пунктом.
2. Проверка прошлых действий: для каждого действия выведи список задач, где оно выполнено, и список задач, где не выполнено.
3. Отдельный проход по одиночным заметкам: вынеси заметки, которые не объединяются ни с одной другой, в отдельный список.
4. Вопросы вместо причин: для каждой темы сформулируй один открытый вопрос команде, причина остаётся неизвестной.
5. Сверка полноты: перечисли ID заметок, которые не попали ни в одну тему.

Каждая вариация добавляется к базовому промпту отдельной строкой. Так модель получает один связный вход и не теряет исходные ограничения.

Сохраните одиночный важный комментарий отдельно

Четвёртый шаг касается заметок, которые не вписываются в общие темы. В учебном наборе это N5: в единственном тесте клавиатурой нельзя было отправить форму. В этом учебном разборе проблема доступности получает самостоятельную строку, чтобы её можно было обсудить и проверить.

Опасность группировки в том, что модель по инерции присоединит такую заметку к близкой теме. N5 может уехать в блок про тестирование, где растворяется среди других строк. Тогда на встрече о проблеме формы никто не вспомнит, потому что в сводке она перестала быть отдельным пунктом.

В промпте для этого есть прямая инструкция: «Сохрани одиночную проблему формы». Она работает как явное указание не объединять заметку с другими. Для нашего набора дополнительную команду можно записать так: сохрани N5 отдельным пунктом, не объединяй с другими темами.

Одиночной здесь назовём заметку, у которой нет второй строки о той же проблеме. Это не означает, что событие всегда происходило только один раз. В нашем наборе N1 и N4 относятся к чек-листу, N2 и N6 — к доступам, N3 связана с A0. N5 сообщает о конкретной неудачной проверке формы и сохраняется отдельно.

Проверка после генерации: найдите в сводке строку про форму и убедитесь, что она стоит отдельно. Если модель объединила её с другой темой, отправьте команду: вынеси N5 в отдельную тему, остальное не меняй. После нового ответа проверьте всю таблицу: просьба сохранить остальное сама по себе не гарантирует неизменность других строк.

Покажите сводку с ID исходных заметок

Пятый шаг — собрать результат в таблицу, где у каждой темы видны исходные ID. Это делает сводку проверяемой: любой участник встречи может открыть заметку и сверить, что модель ничего не дописала.

Колонка «неизвестное» здесь ключевая. Она удерживает сводку от преждевременных выводов: по доступам видна задержка в два дня, а причина организации доступа остаётся неустановленной. По чек-листу видно, что он помог, а влияние на время не измерено. В ручном эталоне причины остаются неизвестными. После ответа модели проверьте каждую строку: если причина добавлена без исходной заметки, удалите её и сохраните вопрос для команды.

Отдельная строка про A0 показывает, как выглядит проверка прошлого действия. Правило выполнено для T1 и T2, для T3 не выполнено. Итог — частичное выполнение. Формулировка «выполнено частично» точнее, чем «выполнено» или «не выполнено», и опирается на список задач.

Длительность проверки зависит от объёма материала. Пройдите по строкам и откройте каждую указанную заметку по ID. Убедитесь, что наблюдение в таблице соответствует тексту заметки, а в колонке «неизвестное» нет утверждений, которых команда не давала.

Подготовьте вопросы к обсуждению вместо выдуманных причин

Шестой шаг — превратить сводку в повестку. В руководстве Miro (miro.com) ретроспектива описана как структурированная встреча для осмысления прошлого спринта и поиска улучшений, а среди шагов названы синтез обратной связи в темы и формулировка действий с ответственными и сроками. Там же отмечена возможность каждого участника высказаться.

Из этого следует роль вопросов. Модель готовит их по темам, где осталось неизвестное, и передаёт команде. Вопрос открывает обсуждение и не подменяет его готовым ответом. По теме доступов можно спросить: какой доступ нужен до старта теста? Фраза о том, что доступы задерживает отдел инфраструктуры, приписала бы причину, которой в заметках нет.

Порядок обсуждения удобно строить от проверки прошлого к новым темам. Сначала A0: где правило сработало, где нет. Затем темы текущего спринта по одной. В конце — одиночные заметки, которые не вошли в темы. Такой порядок не даёт общим темам вытеснить отдельный пункт.

В руководстве Miro упомянут и приём сбора обратной связи до встречи: если задать вопросы прямо на ретроспективе, часть команды промолчит. Заготовки заметок и сводка решают эту задачу: участники приходят с уже собранными наблюдениями, а встреча уходит на обсуждение.

Ещё один ориентир из того же руководства — держать фокус на одном спринте. Ссылки на старые проблемы уводят анализ в сторону. Сводка с ID помогает удержать границу: в ней только заметки текущего спринта и прошлое действие, взятое на проверку.

Оформите только согласованные действия с ролями и проверкой

Седьмой шаг идёт после встречи. Действия команды задаются отдельным входом, и вывести их из заметок нельзя. В учебном примере команда согласовала два решения:

• A1: координатор добавляет поле «Ссылка на утверждённый текст» в карточку; проверка на следующем спринте — у всех начатых задач поле заполнено.
• A2: тестировщик добавляет ручную проверку отправки формы клавиатурой; результат заносится в чек-лист каждой новой формы.

Только A1 и A2 оформляются как решения. Сроков, которых команда не дала, в записи не появляется. Проверочная точка — следующий спринт.

Форма записи действия держит три элемента: что делаем, кто отвечает, как проверим. В A1 действие — добавить поле, ответственный — координатор, проверка — заполненность поля у начатых задач. В A2 действие — добавить ручную проверку, ответственный — тестировщик, проверка — запись результата в чек-лист.

Отрицательная проба показывает, что в решения не попадает. Формулировка «все согласились, что разработчик виноват в задержках» отклоняется: во входе нет ни согласия команды, ни оценки человека, ни установленной причины. Такая строка не становится решением, потому что опирается на отсутствующие данные.

Проверка перед публикацией записи: у каждого действия есть ответственный и проверочная точка, ни одно действие не назначено моделью, ни один срок не добавлен сверх сказанного командой.

Вернитесь к ним на следующей встрече

Восьмой шаг — проверить исполнение A1 и A2 на следующей встрече. У A1 сравните карточки начатых задач с условием заполненности поля. У A2 откройте чек-листы новых форм и найдите результат ручной проверки клавиатурой. Пустая запись означает отсутствие подтверждения в этих материалах; причину команда выясняет отдельно.

Практически это значит, что запись решений становится входом следующей подготовки. A1 и A2 переходят в набор прошлых действий со статусом по задачам — так же, как A0 в разобранном примере. На следующей встрече проверка идёт по тем же трём элементам: что делаем, кто отвечает, как проверим.

Порядок повторной проверки: возьмите прошлые действия, отметьте по задачам, где они применены, и передайте статус в промпт вместе с новыми заметками. Модель выведет выполнение отдельной строкой, а команда обсудит расхождения.

Что стоит сохранить между встречами: заметки с ID, сводку с исходными ссылками и запись согласованных действий. Эти три файла дают следующей подготовке полный вход и позволяют сверить, что решение не потерялось.

Частые вопросы

Что такое ai retrospective и чем она отличается от обычной?

Это ретроспектива, в подготовке которой участвует модель: она группирует обезличенные заметки, сохраняет исходные ID и готовит вопросы. Встречу проводит человек, обсуждение и решения остаются за командой. Модель работает с текстом до встречи и не участвует в разговоре.

Какой инструмент подойдёт как ai retrospective tool?

Подойдёт любой сервис, который принимает текстовый промпт и возвращает таблицу. Ключевое требование — возможность передать весь вход одним блоком и получить ссылки на исходные ID. В руководстве Miro упомянуты шаблоны ретроспектив и цифровые стикеры для сбора обратной связи до встречи.

Как подготовить ai sprint retrospective, если заметок много?

Соберите заметки с ID, обезличьте их и передайте промптом с ограничением на число тем. Одиночные заметки вынесите отдельными пунктами. Если тем получилось слишком много, добавьте строку про лимит и повторите генерацию.

Можно ли поручить модели оценку работы команды?

В этом процессе модель получает задачу группировки заметок и прямое ограничение на оценки людей и причины. Ответ проверяет человек: промпт не гарантирует соблюдения запрета. Решения и согласие команды фиксируются отдельно после обсуждения.

Что делать, если модель дописала причину, которой не было?

Уберите строку точечной правкой и повторите ограничение из промпта. Проверьте колонку «неизвестное»: причина должна оставаться там, пока команда её не назвала. Сверьте наблюдение с заметкой по ID.