Протокол встречи, который никто не прочитал

На одном из проектов Заказчик поставил обязательное условие - по итогам встречи составлять полный протокол и рассылать всем участникам до конца рабочего дня. ПМы поймут: Заказчик, который сам просит фиксировать договорённости, - на вес золота.
Проблему была в том, что в первый месяц мои протоколы читали от силы двое из шести собравшихся, а во второй - уже никто не читал. И когда я напоминал стейкхолдерам о принятых ранее решениях, для всех это было неприятным сюрпризом. Сами понимаете, говорить - "Но я же всё фиксировал в протоколе..." - ничего не значит, скорее, наоборот: "Дмитрий, нужно было подсветить этот момент отдельно!". Ну и все эти вопросы в личку «а что там решили по срокам?» — раздражали до зубовного скрежета: ну всё же написано и лежит у вас на почте!

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

Я руковожу IT-проектами больше 4 лет, сейчас — параллельно до пяти проектов в B2B. При таком объёме коммуникация со стейкхолдерами перестаёт быть «между делом» — это отдельная, вполне измеримая статья времени: протоколы, статус-отчёты, письма с обоснованием сроков, презентации для комитетов, где решения принимают пока ещё люди (ЛПР), которые физически не были на предыдущих встречах и не в курсе контекста.

Примерно год назад я начал системно использовать Claude в этой части работы — не чтобы писать за меня, а чтобы разгрузить черновую часть. Три ошибки, которые я сначала совершил, можно собрать в короткий гайд.

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

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

Скажете - база, я скажу - огромная повестка на каждой встрече. Я просил AI «сделай протокол по этим заметкам» — и получал связный пересказ обсуждаемых тем в хронологическом или логическом порядке. Читать такое никто не хочет, даже если текст написан грамотно.

Что сработало — явно задать структуру на входе, а не полагаться, что AI сам поймёт, что важно:

Промпт: "Разбери заметки встречи на три блока: 1. Принятые решения (коротко, фактом) 2. Задачи с ответственным и сроком (если срок или ответсвенного не называли явно — пометь "уточнить") 3. Открытые вопросы, которые упоминали, но не решили.
Не пересказывай ход обсуждения — только результат".

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

Третья ошибка была тоньше первых двух. На одном проекте один и тот же статус приходилось доносить по-разному: IT-дирекции — с техническими деталями и обоснованием решений, руководству — с фокусом на сроки и риски, рабочей группе — с конкретикой по задачам. Расписывать три версии от руки каждый раз — не вариант, объём не позволяет. А переписывать «на глаз» из одной версии в другую оказалось рискованно: пару раз в разных версиях всплывали чуть разные цифры по срокам, потому что я обновил один документ и забыл поправить остальные.

Решение — держать один эталонный источник (тот самый структурированный протокол) и пересобирать версии из него под конкретную аудиторию через AI, а не редактировать копии независимо друг от друга. И обязательный финальный шаг — сверка всех версий друг с другом перед отправкой, тем же способом, что я использую для проверки проектной документации на противоречия (уже писал в посте для vc).

AI не решает, что стейкхолдеру говорить прямо, а что — аккуратно обходить, потому что момент не подходящий. Не считывает, что руководитель отдела на встрече промолчал не потому, что согласен, а потому что не хочет спорить при коллегах. Это остаётся моей работой — и, честно говоря, ровно та часть, из-за которой профессия PM не сводится к администированию процессов.

Раньше протокол после встречи отнимал у меня до 1 часа. Сейчас — 10 минут, потому что черновая сборка структуры не требует творческого усилия, а моя энергия уходит туда, где она действительно нужна: в формулировки, тон и то, что стоит сказать между строк.

Если знакомая ситуация — делитесь в комментариях, как вы боретесь с «прочитал протокол только случайный аналитик». Возможно, соберу следующий материал с конкретными шаблонами структур под разные форматы коммуникации — статус-отчёты, письма с обоснованием сроков, презентации для ЛПР.