Хороший протокол отвечает на три вопроса: что решили, кто выполняет работу и когда команда проверит результат. Краткий пересказ разговора этого не гарантирует. ИИ может сгруппировать реплики и подготовить черновик, но особенно опасно, когда предположение участника превращается в утверждённую задачу. Поэтому обработку встречи стоит строить вокруг доказательств: у каждого решения должен быть фрагмент расшифровки, а у каждой неопределённости — видимая отметка.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb.
Подготовьте расшифровку для анализа
Сохраните дату, тему, список участников и временные метки. Замените клиентские адреса, телефоны и другие ненужные данные нейтральными обозначениями. Не загружайте запись в сервис, который не разрешён правилами вашей организации. Если распознавание неуверенно определило имя или число, оставьте пометку прямо в тексте: модель не должна незаметно исправлять исходные факты.
Длинную встречу разделяйте по темам, сохраняя несколько реплик на границе фрагментов. Иначе фраза «это пока не утверждаем», произнесённая после обсуждения бюджета, потеряется. Для каждого фрагмента используйте постоянный идентификатор, например M01. Так редактор сможет найти основание вывода даже после перестановки разделов.
Сначала извлеките факты, затем напишите протокол
- Попросите выделить предложения, принятые решения, поручения, риски и открытые вопросы. Эти категории нельзя объединять в одну колонку «итоги».
- Для решения запросите точную цитату и временную метку. Если явного согласования нет, статус должен быть «предложение».
- Для поручения извлеките исполнителя, действие, ожидаемый результат и срок. Отсутствующее поле оставьте пустым, а не заполняйте по должности участника.
- Отдельно найдите противоречия: изменённые сроки, отменённые задачи, разные суммы. Более поздняя реплика важна, но не всегда автоматически отменяет раннюю.
- После проверки сформируйте короткий документ с разделами «Решения», «Задачи», «Вопросы на согласование».
Учебный пример: запуск страницы
Допустим, на встрече из 6 участников обсуждали лендинг. В 12:10 прозвучало: «Предлагаю закончить дизайн к пятнице». В 19:40 дизайнер ответил: «К пятнице покажу только первый экран». В 22:05 руководитель подтвердил: «Хорошо, согласуем первый экран, остальное оценим после». Корректная задача — подготовить первый экран к пятнице. Задача «закончить весь дизайн» не подтверждена.
Ещё одна реплика: «Бюджет около 80 тысяч, но надо свериться со сметой». В протоколе это предварительная оценка, а не одобренный бюджет. Если дата встречи — вторник, конкретную дату пятницы можно вычислить, но следует указать, что это интерпретация относительного срока. При работе разных часовых поясов лучше запросить подтверждение даты и времени.
Составь черновик протокола только по расшифровке ниже.
Сначала верни таблицу: тип записи, содержание, участник,
срок дословно, источник с временной меткой, уверенность основания.
Типы: решение, предложение, задача, риск, открытый вопрос.
Не назначай исполнителей и сроки самостоятельно.
Найди поздние уточнения и явные отмены ранних договорённостей.
Затем подготовь краткий протокол и список вопросов участникам.
Расшифровка: [вставьте текст с временными метками].Как провести согласование
Отправляйте участникам не только красивый итоговый текст, но и короткий список неоднозначностей. Вопрос «Верно ли, что первый экран готовит Анна к 23 октября?» полезнее общего «Есть замечания?». Исполнитель подтверждает содержание своей задачи; руководитель встречи подтверждает решения. До этого документ следует обозначать как черновик.
После согласования зафиксируйте версию и дату. Если задачи переносятся в рабочую систему, сохраняйте связь с протоколом и не создавайте дубли при повторной обработке записи. Для следующей встречи готовьте перечень незакрытых действий, а не новый пересказ предыдущего разговора. Такая преемственность помогает заметить поручения, которые формально записаны, но никем не приняты.
Если в обсуждении несколько человек говорят одновременно, не связывайте задачу с ближайшей меткой спикера автоматически. Пометьте участок как неразобранный и прослушайте запись. Для переносимых в трекер задач используйте отдельный идентификатор, например ACT-03, и храните статус подтверждения. Повторная генерация протокола тогда не создаст второе поручение с немного другим названием. Также проверьте задачи, которые участники отклонили: они должны остаться в истории обсуждения при необходимости, но не попасть в активный список. Это особенно важно при встречах, где команда перебирает много вариантов решения одной проблемы.
Проверка перед отправкой
- У всех решений есть подтверждающие реплики.
- Предложения не выданы за обязательства.
- Сроки проверены относительно даты встречи.
- У задач указан измеримый результат, а неизвестные исполнители отмечены.
- Финальная версия не содержит лишних персональных данных.
Частые вопросы
Можно ли сделать протокол только по заметкам?
Да, но пометьте ограничение источника. Заметки могут не содержать отмены и уточнения, поэтому спорные решения нужно подтвердить у участников.
Нужно ли включать всё обсуждение?
Нет. Подробности оставляйте там, где они объясняют принятое решение, ограничение или ответственность. Остальное можно сохранить в приложении.
Для построения проверяемого процесса полезна рамочная методика NIST по управлению рисками ИИ. Она служит общим ориентиром для контроля, а не готовым стандартом оформления протоколов.