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

Зачем нужен протокол

Протокол совещания решает три задачи, и ни одна из них не про «зафиксировать, что встреча была». Он закрепляет договорённости, чтобы через месяц не спорить, о чём условились. Он назначает ответственность — у каждого действия появляется имя и дата. И он переносит контекст тем, кого на встрече не было, без пересказа в коридоре.

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

Семь разделов протокола

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

1. Шапка. Тема, дата, время начала и конца, кто вёл встречу. Продолжительность — не формальность: она показывает цену вопроса, когда через полгода решают, стоит ли собираться снова.
2. Участники. Кто был и кто приглашён, но не пришёл. Различие важное: отсутствовавший не связан решением автоматически, но обязан быть о нём извещён. Явный список отсутствующих — это список тех, кому нужно отправить протокол лично.
3. Контекст. Одно-два предложения о том, почему встреча вообще состоялась. Через три месяца это единственное, что позволит понять остальное.
4. Решения. Главный раздел. Что именно постановили — списком, каждое отдельным пунктом, с указанием, кто принял решение.
5. Задачи. Действия, вытекающие из решений: формулировка, один ответственный, срок.
6. Открытые вопросы. То, что обсудили, но не решили. Раздел, который чаще всего выбрасывают — и зря: именно он не даёт вопросу потеряться до следующей встречи.
7. Материалы. Ссылки на документы, макеты, дашборды, о которых шла речь.

Решения: как формулировать

Самая частая ошибка в этом разделе — записывать процесс вместо результата. «Обсудили сроки», «поговорили про бюджет» — это описание того, как прошло время, а не того, к чему пришли. Решение должно читаться как утверждение, которое можно проверить на истинность.

Рабочая формула: что постановили + на каком основании + кто решил. Основание нужно, потому что решения пересматривают, и через месяц вопрос будет не «что решили», а «почему решили именно так».

Отдельно про формулировку «решили вернуться к вопросу»

Это не решение, а его отсутствие. Если вопрос действительно отложен, у отсрочки должны быть владелец и дата: «Вопрос тарифной сетки отложен до 15 сентября, к нему возвращается Игорь после данных за август». Такая запись идёт в раздел открытых вопросов, а не в решения.

Задачи: что делает их выполнимыми

Задача из протокола отличается от задачи в трекере только тем, что её никто не будет уточнять. Значит, она должна быть самодостаточной: по формулировке понятно, что считается сделанным.

• Глагол действия в начале. «Прислать», «согласовать», «собрать» — а не «смета» или «вопрос по доступам».
• Критерий готовности. Куда прислать, в каком виде, кому показать. Без него задача закрывается по ощущению исполнителя.
• Ровно один ответственный. «Команда разработки» означает, что не сделает никто: ответственность, разделённая между людьми, не принадлежит никому.
• Дата, а не срок «на следующей неделе». Относительные сроки протухают в момент, когда протокол читают позже.

Три ошибки, которые обесценивают протокол

1. Стенограмма вместо протокола. Дословная запись разговора — это исходник, а не документ. Читать её никто не будет: полезное там перемешано с уточнениями, шутками и возвратами к уже решённому. Стенограмма нужна как источник, из которого протокол извлекается, — но подменять его собой она не может.
2. Решения без владельца. Запись «решили ускорить найм» без имени означает, что никто не начал. Проверка простая: если по каждому пункту вы можете назвать человека, которому завтра писать, — раздел готов.
3. Протокол через два дня. Точность памяти падает быстро, а вместе с ней и ценность документа: спорные формулировки уже не восстановить, и участники начинают вспоминать по-разному. Практический срок — тот же день, пока встреча свежа хотя бы у автора.

Готовый шаблон

Разметка в Markdown — вставляется в любой редактор, таск-трекер или базу знаний без правки.

# Протокол: [тема встречи]

**Дата:** [дд.мм.гггг], [время начала]–[время конца]
**Ведёт:** [имя]
**Участники:** [имена через запятую]
**Отсутствовали:** [имена; если все были — «нет»]

## Контекст
[1–2 предложения: почему собрались]

## Решения
1. [Что постановили]. Основание: [почему]. Решил: [имя, роль].
2. …

## Задачи
| Что сделать | Кто | Срок |
|---|---|---|
| [Глагол + объект + критерий готовности] | [одно имя] | [дд.мм] |

## Открытые вопросы
- [Вопрос]. Возвращаемся [дд.мм], владелец: [имя].

## Материалы
- [Название](ссылка)

Конструктор протокола

Заполните поля — протокол соберётся по шаблону выше. Ничего никуда не отправляется: всё считается прямо в браузере, страница не хранит введённое.

Чек-лист перед отправкой

Восемь проверок, каждая из которых ловит свой класс проблем. Отметьте пункты — счётчик покажет готовность.

Что из этого можно не делать руками

Разделы «решения», «задачи» и «открытые вопросы» извлекаются из расшифровки разговора: их формулировки почти всегда звучат вслух. Whisperer ведёт стенограмму встречи и собирает из неё структурные заметки с action items — дальше остаётся вычитать формулировки и проставить недостающие даты. Ручной работой остаётся то, что и должно ей быть: решение о том, что вообще считать решением.

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