Протокол проектного совещания – один из немногих документов, который одновременно фиксирует договоренности, распределяет ответственность и служит доказательной базой при спорах. Примеры протокола проектного совещания в этой подборке показывают, как один и тот же формат работает в разных контекстах: от короткой планерки до стратегической сессии с несколькими участниками.
В статье собраны образцы под основные сценарии проектной работы – запуск, контрольная точка, кризисная встреча, закрытие этапа. Каждый пример показывает структуру, логику заполнения и типичные формулировки. Ниже также есть блок, который объясняет, как собрать свой протокол с нуля под конкретную задачу.
В подборку вошли примеры протокола проектного совещания следующих форматов:
- Краткий протокол (формат фиксации решений)
- Протокол планерки по запуску нового продукта
- Протокол еженедельного статус-митинга
- Протокол экстренного совещания по срыву сроков
- Развернутый протокол (формат с ходом обсуждения)
- Протокол стартового совещания по проекту внедрения CRM
- Протокол контрольного совещания по строительному проекту
- Протокол совещания по итогам первого этапа разработки
- Протокол с поручениями и сроками (табличный формат)
- Протокол совещания по редизайну корпоративного сайта
- Протокол совещания по запуску рекламной кампании
- Протокол совещания по оптимизации логистики
- Протокол разногласий и согласований
- Протокол совещания по согласованию бюджета проекта
- Протокол совещания при наличии расхождений в позициях сторон
- Протокол закрытия этапа или проекта
- Протокол закрывающего совещания по первому этапу
- Протокол финального совещания по завершенному проекту
Примеры протокола проектного совещания разных видов и форматов: основной FAQ
Что такое протокол проектного совещания. Это официальный документ, который фиксирует: кто участвовал во встрече, какие вопросы обсуждались, к каким решениям пришли, кто и что должен сделать и в какой срок. Протокол не пересказывает разговор дословно – он фиксирует суть и итог.
Чем отличается от обычного протокола совещания. Протокол проектного совещания всегда привязан к конкретному проекту: в нем есть ссылка на этап, версию документа или контрольную точку. Он также чаще содержит таблицу поручений с ответственными и дедлайнами.
Основные форматы:
- Краткий протокол – только решения и поручения, без хода обсуждения. Подходит для коротких планерок и статус-митингов.
- Развернутый протокол – фиксирует ход обсуждения, позиции участников и аргументы. Используется на стартовых и ключевых совещаниях.
- Табличный протокол с поручениями – основная часть оформлена в виде таблицы: задача, ответственный, срок, статус. Удобен для команд с большим числом параллельных задач.
- Протокол разногласий – фиксирует, что стороны не пришли к единому решению, и описывает позиции каждой из них. Нужен при согласованиях между отделами или с заказчиком.
- Закрывающий протокол – подводит итоги этапа или всего проекта, фиксирует выполненные и невыполненные задачи, передает ответственность.
Где применяются. В IT-командах, строительстве, маркетинге, производстве, консалтинге – везде, где есть проекты с несколькими участниками и распределенными зонами ответственности. Протокол нужен не для формальности, а чтобы через две недели никто не говорил "мы такого не решали".
Краткий протокол проектного совещания: формат фиксации решений
Краткий протокол – самый распространенный рабочий формат. Он не описывает ход дискуссии, а фиксирует только итог: что решили, кто отвечает, к какому сроку. Такой документ занимает одну-две страницы и может быть отправлен участникам в тот же день. Его основная задача – дать каждому участнику понятную точку отсчета после встречи.
📌 Протокол планерки по запуску нового продукта
- Сценарий: первая рабочая встреча команды после утверждения концепции продукта
- Адресат: участники проектной команды, руководитель проекта
- Задача: зафиксировать распределение ролей и ближайшие шаги
Пример:
ПРОТОКОЛ № 1
планерки по проекту "Запуск продукта X"
Дата: 14 мая 2025 г.
Время: 10:00–10:45
Место: переговорная комната № 2 / онлайн (Zoom)
Председатель: Иванова А. С., руководитель проекта
Секретарь: Петров Д. В., менеджер проекта
Присутствовали:
- Иванова А. С. – руководитель проекта
- Петров Д. В. – менеджер проекта
- Кузнецова М. Л. – ведущий дизайнер
- Соколов Р. И. – технический директор
- Федорова Н. А. – маркетолог
Повестка дня:
- Распределение ролей и зон ответственности.
- Утверждение плана-графика на первые два месяца.
- Определение ключевых рисков.
Рассмотрено и решено:
По вопросу 1. Утвердить распределение ролей согласно приложению № 1. Соколов Р. И. – ответственный за техническую архитектуру. Кузнецова М. Л. – ответственная за UI/UX. Федорова Н. А. – ответственная за маркетинговые материалы.
По вопросу 2. Принять план-график на период с 15 мая по 15 июля 2025 г. Контрольная точка – 1 июня 2025 г. (готовность прототипа). Петрову Д. В. разместить план в системе управления задачами до 16 мая 2025 г.
По вопросу 3. Зафиксировать три основных риска: задержка поставки стороннего API, нехватка ресурсов на тестирование, смещение сроков по смежному проекту. Ответственный за мониторинг рисков – Петров Д. В. Еженедельный отчет по рискам – каждую пятницу до 17:00.
Следующее совещание: 21 мая 2025 г., 10:00, тот же формат.
Подписи:
Председатель: Иванова А. С. ___________
Секретарь: Петров Д. В. ___________
- Почему подходит: четкая нумерация вопросов и решений по каждому из них не оставляет пространства для разночтений.
- Где работает лучше всего: в командах с регулярными короткими планерками, где нет времени на длинный документ, но важно зафиксировать итог.
- Что важно не испортить: каждое решение должно содержать конкретного ответственного и срок. Расплывчатые формулировки вроде "команда рассмотрит вопрос" бесполезны.
📌 Протокол еженедельного статус-митинга
- Сценарий: регулярная встреча проектной команды для контроля хода работ
- Адресат: команда проекта и куратор
- Задача: зафиксировать текущий статус, отклонения и новые поручения
Пример:
ПРОТОКОЛ № 7
еженедельного статус-митинга по проекту "Редизайн корпоративного портала"
Дата: 19 мая 2025 г.
Время: 09:30–10:00
Формат: онлайн (Telegram-звонок)
Председатель: Громов П. Е., руководитель проекта
Секретарь: Антонова В. С.
Присутствовали: Громов П. Е., Антонова В. С., Лебедев К. О. (разработка), Миронова Т. Н. (дизайн), Власов А. Г. (тестирование).
Статус по задачам прошлой недели:
- Прототип главной страницы – выполнено (Миронова Т. Н.).
- Подключение системы аналитики – в работе, сдвиг на 2 дня (Лебедев К. О.).
- Подготовка тест-кейсов – не начато, причина: ожидание финального макета (Власов А. Г.).
Решения и поручения:
- Лебедеву К. О. завершить подключение аналитики до 21 мая 2025 г.
- Мироновой Т. Н. передать финальный макет Власову А. Г. до 20 мая 2025 г.
- Власову А. Г. подготовить первый пакет тест-кейсов до 23 мая 2025 г.
- Антоновой В. С. обновить доску задач в системе управления проектом до конца дня.
Отклонения от плана: общее отставание по этапу тестирования составляет 2 рабочих дня. Критического влияния на итоговый дедлайн нет при соблюдении новых сроков.
Следующий митинг: 26 мая 2025 г., 09:30.
Подписи:
Председатель: Громов П. Е. ___________
Секретарь: Антонова В. С. ___________
- Почему подходит: блок "Статус по задачам прошлой недели" – ключевое отличие статус-митинга от обычной планерки. Он сразу показывает выполнение и отклонения.
- Как применять: такой протокол удобно вести прямо во время звонка в общем документе, чтобы участники сразу видели финальную версию.
- Что важно не испортить: статус "в работе" без указания нового срока – это не статус. Всегда фиксируйте пересмотренный дедлайн.
📌 Протокол экстренного совещания по срыву сроков
- Сценарий: внеплановая встреча из-за критической ситуации в проекте
- Адресат: руководитель проекта, ключевые участники, куратор
- Задача: зафиксировать причины, принятые антикризисные меры и новые договоренности
Пример:
ПРОТОКОЛ № 3-Э
экстренного совещания по проекту "Автоматизация складского учета"
Дата: 22 мая 2025 г.
Время: 16:00–17:15
Основание для созыва: срыв срока сдачи модуля инвентаризации (плановый срок – 20 мая 2025 г.)
Председатель: Карпов В. Н., директор по развитию (куратор проекта)
Секретарь: Зайцева Е. О.
Присутствовали: Карпов В. Н., Зайцева Е. О., Орлов С. В. (руководитель проекта), Тимофеев Д. А. (разработка), Никитина Л. Р. (аналитик).
Установленные причины отставания:
- Неполная спецификация со стороны заказчика на этапе постановки задачи.
- Трехдневный простой в связи с заменой ключевого разработчика.
- Дополнительные требования, добавленные после старта разработки без корректировки плана.
Принятые решения:
- Перенести срок сдачи модуля на 30 мая 2025 г. Дополнительный перенос недопустим.
- Орлову С. В. подготовить скорректированный план работ с разбивкой по дням и передать куратору до 23 мая 2025 г.
- Никитиной Л. Р. зафиксировать все добавленные требования в реестре изменений до 23 мая 2025 г.
- Тимофееву Д. А. ежедневно направлять краткий отчет о прогрессе Орлову С. В. до завершения этапа.
- Карпову В. Н. уведомить заказчика о переносе сроков и согласовать новый план до 24 мая 2025 г.
Особая отметка: участники совещания подтвердили, что причины срыва зафиксированы объективно. Ответственность за добавление требований без изменения плана несет сторона заказчика.
Подписи:
Председатель: Карпов В. Н. ___________
Секретарь: Зайцева Е. О. ___________
- Почему подходит: блок "Установленные причины" и "Особая отметка" – защитные элементы протокола. Они нужны не для поиска виноватых, а для объективной фиксации ситуации.
- Когда особенно уместен: при работе с внешними заказчиками, когда важно разграничить ответственность сторон в письменном виде.
- Что важно не испортить: в экстренном протоколе нельзя размывать ответственность. Каждое решение – конкретный человек и конкретный срок.
Развернутый протокол проектного совещания: формат с ходом обсуждения
Развернутый протокол фиксирует не только итоги, но и ход дискуссии: кто какую позицию занял, какие аргументы прозвучали, почему было принято именно это решение. Такой формат нужен на стартовых встречах, стратегических сессиях и совещаниях, где важно зафиксировать логику принятых решений, а не только их факт. Он длиннее краткого протокола, но значительно ценнее при разборе спорных ситуаций.
📌 Протокол стартового совещания по проекту внедрения CRM
- Сценарий: первое официальное совещание по старту проекта с участием заказчика и исполнителя
- Адресат: обе стороны – заказчик и команда исполнителя
- Задача: зафиксировать цели, рамки проекта, роли и ключевые договоренности старта
Пример:
ПРОТОКОЛ № 1
стартового совещания по проекту "Внедрение CRM-системы"
Дата: 12 мая 2025 г.
Время: 11:00–13:00
Место: офис заказчика, переговорная "Альфа"
Председатель: Белов А. М., директор по продажам (заказчик)
Секретарь: Романова Ю. В. (исполнитель)
Присутствовали со стороны заказчика:
- Белов А. М. – директор по продажам
- Чернова О. П. – руководитель отдела продаж
- Смирнов В. Д. – IT-специалист
Присутствовали со стороны исполнителя:
- Романова Ю. В. – менеджер проекта
- Захаров М. И. – ведущий аналитик
- Попова Е. С. – технический консультант
Повестка дня:
- Цели и ожидаемые результаты проекта.
- Рамки проекта: что входит и что не входит.
- Роли и ответственность сторон.
- Порядок коммуникаций и отчетности.
- Ближайшие шаги.
Ход обсуждения:
По вопросу 1. Цели проекта.
Белов А. М. обозначил ключевую цель: сократить время обработки входящей заявки с текущих 48 часов до 4 часов. Чернова О. П. уточнила, что помимо скорости важна прозрачность: руководитель должен видеть статус каждой сделки в режиме реального времени. Захаров М. И. предложил зафиксировать цели в формате измеримых показателей (KPI проекта) и согласовать их до начала аналитического этапа. Стороны согласились.
По вопросу 2. Рамки проекта.
Захаров М. И. представил предварительный перечень функциональных блоков. Смирнов В. Д. поднял вопрос об интеграции с действующей 1С. Попова Е. С. пояснила, что интеграция с 1С входит в базовый объем только в части выгрузки счетов; двусторонняя синхронизация – отдельный модуль с отдельной стоимостью. Стороны договорились зафиксировать рамки в техническом задании и подписать их до 19 мая 2025 г.
По вопросу 3. Роли и ответственность.
Стороны согласовали следующее: куратор со стороны заказчика – Белов А. М.; операционный контакт – Чернова О. П.; технический контакт – Смирнов В. Д.; менеджер проекта со стороны исполнителя – Романова Ю. В. Все изменения в требованиях проходят через Чернову О. П. и Романову Ю. В.
По вопросу 4. Порядок коммуникаций.
Еженедельные статус-митинги – каждый вторник в 10:00 (онлайн). Рабочий чат – Telegram. Официальная переписка и согласования – электронная почта. Срок ответа на запросы – не более 1 рабочего дня.
По вопросу 5. Ближайшие шаги.
Захаров М. И. и Смирнов В. Д. проводят техническое интервью 14–15 мая 2025 г. Романова Ю. В. готовит проект технического задания до 16 мая 2025 г. Стороны подписывают ТЗ до 19 мая 2025 г.
Решения:
- Захарову М. И. подготовить KPI проекта и передать заказчику до 14 мая 2025 г.
- Романовой Ю. В. подготовить проект ТЗ до 16 мая 2025 г.
- Черновой О. П. согласовать ТЗ со стороны заказчика до 19 мая 2025 г.
Следующее совещание: 20 мая 2025 г., 10:00, онлайн.
Подписи:
Со стороны заказчика: Белов А. М. ___________
Со стороны исполнителя: Романова Ю. В. ___________
- Почему подходит: блок "Ход обсуждения" показывает логику решений – почему именно так договорились, а не иначе. Это особенно важно для внешних проектов, где каждое изменение может влечь финансовые последствия.
- Термин "KPI проекта": измеримые показатели успеха – например, время обработки заявки или процент сделок, закрытых через CRM.
- Что важно не испортить: в стартовом протоколе критически важно зафиксировать рамки (что входит, а что нет). Именно эта часть чаще всего становится предметом споров.
📌 Протокол контрольного совещания по строительному проекту
- Сценарий: плановая проверка хода работ на строительном объекте
- Адресат: технический надзор, подрядчики, заказчик
- Задача: зафиксировать фактический прогресс, выявленные нарушения и предписания
Пример:
ПРОТОКОЛ № 5
контрольного совещания по объекту "Административное здание по адресу: г. Москва, ул. Проектная, д. 12"
Дата: 15 мая 2025 г.
Время: 09:00–10:30
Место: строительный вагончик на объекте
Председатель: Волков Д. С., технический заказчик
Секретарь: Семенова А. В.
Присутствовали:
- Волков Д. С. – технический заказчик
- Семенова А. В. – представитель проектной организации
- Крылов Н. Г. – прораб генерального подрядчика
- Устинов Р. Т. – представитель субподрядчика (электромонтаж)
- Щербакова И. Л. – специалист по строительному контролю
Рассмотренные вопросы:
1. Фактический прогресс работ.
Крылов Н. Г. доложил о состоянии объекта: монолитные работы выполнены на 80% (план – 85%), кровля – 60% (план – 60%), внутренние перегородки – 35% (план – 40%). Отставание по монолиту и перегородкам объясняется задержкой поставки арматуры на 4 рабочих дня.
2. Выявленные замечания.
Щербакова И. Л. зафиксировала три замечания по результатам осмотра:
– Отсутствие защитного ограждения на отметке +9.000 м (нарушение требований охраны труда).
– Несоответствие марки бетона в секции Б проектной документации (требует лабораторного подтверждения).
– Неполная исполнительная документация по электромонтажным работам (секция А, 1–3 этажи).
3. Позиция подрядчика.
Крылов Н. Г. принял замечания и обязался устранить ограждение в течение одного рабочего дня. По бетону запросил время на организацию лабораторного испытания. Устинов Р. Т. подтвердил, что исполнительная документация будет передана до 19 мая 2025 г.
Предписания и решения:
- Крылову Н. Г. установить ограждение на отметке +9.000 м до 16 мая 2025 г.
- Крылову Н. Г. организовать лабораторное испытание бетона в секции Б и предоставить протокол испытаний до 22 мая 2025 г.
- Устинову Р. Т. передать исполнительную документацию Щербаковой И. Л. до 19 мая 2025 г.
- Семеновой А. В. проверить соответствие фактических работ проектной документации по секции Б и сообщить о результатах до 20 мая 2025 г.
Следующее контрольное совещание: 29 мая 2025 г., 09:00, объект.
Подписи:
Технический заказчик: Волков Д. С. ___________
Прораб: Крылов Н. Г. ___________
Специалист по строительному контролю: Щербакова И. Л. ___________
- Почему подходит: строительный протокол – один из наиболее юридически значимых. Каждое замечание должно быть конкретным: что нарушено, где, кто зафиксировал, когда устранить.
- Термин "исполнительная документация": комплект документов, подтверждающих соответствие выполненных работ проекту: схемы, акты скрытых работ, сертификаты на материалы.
- Что важно не испортить: замечания без конкретного ответственного и срока устранения юридически не работают. Фиксируйте все точно.
📌 Протокол совещания по итогам первого этапа разработки
- Сценарий: завершение спринта или этапа разработки программного продукта, обсуждение результатов
- Адресат: команда разработки, продуктовый менеджер, представитель заказчика
- Задача: зафиксировать, что сделано, что не сделано и почему, принять решения по следующему этапу
Пример:
ПРОТОКОЛ № 4
совещания по итогам первого этапа разработки (спринт 1) по проекту "Мобильное приложение для учета расходов"
Дата: 16 мая 2025 г.
Время: 15:00–16:30
Формат: онлайн (Google Meet)
Председатель: Панова К. А., продуктовый менеджер
Секретарь: Яковлев Т. С.
Присутствовали: Панова К. А., Яковлев Т. С., Дмитриев А. Л. (backend), Ершова Н. В. (frontend), Коробов Г. П. (QA), Ларина С. М. (представитель заказчика).
Итоги спринта 1 (29 апреля – 16 мая 2025 г.):
Выполнено:
- Авторизация и регистрация пользователя.
- Добавление и редактирование транзакций.
- Базовая категоризация расходов (7 категорий).
- Локальное хранилище данных (без синхронизации).
Не выполнено (перенесено в спринт 2):
- Экспорт данных в PDF – не начат из-за изменения приоритетов.
- Push-уведомления – техническая зависимость от еще не готового серверного модуля.
Ход обсуждения.
Ларина С. М. выразила обеспокоенность переносом экспорта PDF, так как эта функция была обозначена как приоритетная для демо. Панова К. А. пояснила, что приоритет был временно снижен в пользу стабильности базовой функциональности. По итогам обсуждения стороны согласились: экспорт PDF возвращается в высокий приоритет и должен быть реализован в первой половине спринта 2. Коробов Г. П. сообщил о 3 критических багах, выявленных при тестировании; все три требуют исправления до начала следующего спринта.
Решения:
- Дмитриеву А. Л. исправить 3 критических бага до 19 мая 2025 г.
- Коробову Г. П. провести регрессионное тестирование после исправлений до 20 мая 2025 г.
- Яковлеву Т. С. зафиксировать перенос задач в системе управления проектом и обновить бэклог до конца дня 16 мая 2025 г.
- Панова К. А. согласовывает план спринта 2 с Лариной С. М. до 21 мая 2025 г.
Следующее совещание: 30 мая 2025 г., 15:00, онлайн (итоги спринта 2).
Подписи:
Председатель: Панова К. А. ___________
Секретарь: Яковлев Т. С. ___________
- Почему подходит: разделение на "выполнено" и "не выполнено" с объяснением причин – стандарт для проектов в agile-подходе. Это честная фиксация реального состояния.
- Термины: "бэклог" – список задач, ожидающих выполнения; "регрессионное тестирование" – проверка того, что исправление бага не сломало другие функции.
- Что важно не испортить: перенесенные задачи должны быть объяснены, а не просто перечислены. Заказчик должен понимать причину, а не гадать.
Протокол проектного совещания с поручениями: табличный формат
Табличный протокол – наиболее удобный формат для команд с большим числом параллельных задач. Вместо того чтобы описывать поручения в тексте, их структурируют в таблицу: задача, ответственный, срок, статус. Это позволяет быстро сканировать документ и использовать его как трекер выполнения до следующей встречи.
📌 Протокол совещания по редизайну корпоративного сайта
- Сценарий: рабочее совещание по текущему ходу проекта с большим числом параллельных задач
- Адресат: кросс-функциональная команда: дизайн, разработка, маркетинг, контент
- Задача: зафиксировать поручения по каждому направлению в едином документе
Пример:
ПРОТОКОЛ № 6
рабочего совещания по проекту "Редизайн корпоративного сайта"
Дата: 20 мая 2025 г.
Время: 14:00–15:00
Председатель: Воронова Е. А., руководитель проекта
Секретарь: Тихонов С. Р.
Присутствовали: Воронова Е. А., Тихонов С. Р., Суворова П. И. (дизайн), Малышев О. Ю. (разработка), Рыбакова Г. В. (контент), Козлов А. Н. (маркетинг).
Краткое резюме обсуждения: обсуждены текущие блокеры по проекту. Основная проблема – отсутствие финальных текстов для трех ключевых страниц, что блокирует верстку. Приняты решения об ускорении контентного этапа.
Таблица поручений:
| № | Задача | Ответственный | Срок | Статус |
| 1 | Финальный текст для страницы "О компании" | Рыбакова Г. В. | 22.05.2025 | В работе |
| 2 | Финальный текст для страницы "Услуги" | Рыбакова Г. В. | 23.05.2025 | Не начато |
| 3 | Финальный текст для страницы "Контакты" | Козлов А. Н. | 21.05.2025 | Не начато |
| 4 | Верстка главной страницы (после получения текстов) | Малышев О. Ю. | 26.05.2025 | Ожидает контент |
| 5 | Финальные макеты внутренних страниц (3 шт.) | Суворова П. И. | 24.05.2025 | В работе |
| 6 | Обновление технического задания с учетом изменений | Тихонов С. Р. | 21.05.2025 | Не начато |
| 7 | Согласование итогового дедлайна с руководством | Воронова Е. А. | 22.05.2025 | Запланировано |
Следующее совещание: 27 мая 2025 г., 14:00.
Подписи:
Председатель: Воронова Е. А. ___________
Секретарь: Тихонов С. Р. ___________
- Почему подходит: таблица с колонкой "Статус" превращает протокол в живой инструмент контроля. Ее можно открыть перед следующим совещанием и сразу видеть, что сделано.
- Как применять: такой протокол удобно вести в Google Docs или Notion – тогда статус можно обновлять прямо в документе без повторного заседания.
- Что важно не испортить: статус "в работе" без обновления к следующей встрече – признак того, что система контроля не работает. Требуйте актуализации перед каждым совещанием.
📌 Протокол совещания по запуску рекламной кампании
- Сценарий: координационное совещание перед стартом масштабной рекламной кампании
- Адресат: маркетинговая команда, дизайнеры, медиапланировщик, руководитель
- Задача: распределить задачи и зафиксировать сроки по каждому направлению
Пример:
ПРОТОКОЛ № 2
совещания по запуску рекламной кампании "Летняя распродажа 2025"
Дата: 13 мая 2025 г.
Время: 10:00–11:00
Председатель: Медведева Т. Г., директор по маркетингу
Секретарь: Балашов И. С.
Присутствовали: Медведева Т. Г., Балашов И. С., Крутова Д. Л. (SMM), Шевцов А. Р. (дизайн), Игнатьева Е. Н. (контекстная реклама), Борисов Ю. К. (медиапланирование).
Краткое резюме: кампания стартует 2 июня 2025 г. Согласованы форматы, каналы и бюджетная разбивка. Все материалы должны быть готовы к 28 мая 2025 г. для прохождения модерации.
| № | Задача | Ответственный | Срок | Примечание |
| 1 | Медиаплан по каналам (VK, Яндекс, Telegram) | Борисов Ю. К. | 15.05.2025 | Согласовать с Медведевой Т. Г. |
| 2 | Баннеры для контекстной рекламы (5 форматов) | Шевцов А. Р. | 20.05.2025 | Передать Игнатьевой Е. Н. |
| 3 | Посты для VK и Telegram (10 публикаций) | Крутова Д. Л. | 22.05.2025 | Согласовать с Медведевой Т. Г. |
| 4 | Настройка рекламных кабинетов | Игнатьева Е. Н. | 25.05.2025 | После получения баннеров |
| 5 | UTM-метки для всех ссылок | Балашов И. С. | 24.05.2025 | Передать Игнатьевой Е. Н. и Крутовой Д. Л. |
| 6 | Финальная проверка всех материалов | Медведева Т. Г. | 27.05.2025 | Перед отправкой на модерацию |
Следующее совещание: 26 мая 2025 г., 10:00 (финальная проверка готовности).
Подписи:
Председатель: Медведева Т. Г. ___________
Секретарь: Балашов И. С. ___________
- Почему подходит: колонка "Примечание" в этом шаблоне заменяет длинные текстовые пояснения – каждая задача сразу привязана к зависимости или условию.
- Термин "UTM-метки": специальные параметры в ссылках, позволяющие отследить, из какого рекламного канала пришел пользователь.
- Что важно не испортить: зависимости между задачами (например, "после получения баннеров") должны быть видны в протоколе. Иначе срыв одной задачи незаметно блокирует следующую.
📌 Протокол совещания по оптимизации логистики
- Сценарий: совещание по внутреннему проекту улучшения операционного процесса
- Адресат: руководители смежных подразделений: склад, закупки, транспорт, IT
- Задача: согласовать план мероприятий и распределить ответственность между отделами
Пример:
ПРОТОКОЛ № 3
совещания по проекту "Оптимизация логистических процессов"
Дата: 14 мая 2025 г.
Время: 11:30–12:30
Председатель: Степанов Г. В., операционный директор
Секретарь: Нечаева Т. Б.
Присутствовали: Степанов Г. В., Нечаева Т. Б., Фролов Е. О. (склад), Сидорова М. И. (закупки), Кузьмин А. П. (транспортный отдел), Новиков Р. Д. (IT).
Краткое резюме: зафиксированы узкие места в текущем процессе: задержки при приемке товара, ручной ввод данных, отсутствие автоматического уведомления о готовности заказа. Согласован план устранения.
| № | Мероприятие | Ответственный | Срок | Ожидаемый результат |
| 1 | Аудит текущего процесса приемки товара | Фролов Е. О. | 21.05.2025 | Карта процесса с узкими местами |
| 2 | ТЗ на автоматизацию ввода данных при приемке | Новиков Р. Д. | 28.05.2025 | Готовое ТЗ для разработки |
| 3 | Анализ поставщиков с регулярными задержками | Сидорова М. И. | 23.05.2025 | Реестр проблемных поставщиков |
| 4 | Настройка автоуведомлений о готовности заказа | Новиков Р. Д. | 04.06.2025 | Уведомления работают в тестовой среде |
| 5 | Пересмотр маршрутов доставки по Москве | Кузьмин А. П. | 30.05.2025 | Новая схема маршрутов с экономией времени |
| 6 | Сводный отчет по итогам первого месяца оптимизации | Нечаева Т. Б. | 16.06.2025 | Отчет для операционного директора |
Следующее совещание: 4 июня 2025 г., 11:30.
Подписи:
Председатель: Степанов Г. В. ___________
Секретарь: Нечаева Т. Б. ___________
- Почему подходит: колонка "Ожидаемый результат" делает поручение проверяемым. Не просто "сделать аудит", а "карта процесса с узкими местами" – понятно, что должно появиться на выходе.
- Как применять: для внутренних операционных проектов такая таблица работает лучше текстового перечня поручений: легче сканировать, легче ставить галочки.
- Что важно не испортить: ожидаемый результат должен быть конкретным артефактом – документом, отчетом, настройкой – а не размытым "улучшением ситуации".
Протокол разногласий и согласований на проектном совещании
Не каждое совещание заканчивается единогласным решением. Когда стороны не пришли к общей позиции или когда одна из сторон выразила несогласие с принятым решением, это нужно фиксировать отдельно. Протокол разногласий защищает всех участников: он показывает, что позиции были услышаны, но договоренность достигнута именно такая. Такой образец протокола особенно важен при согласованиях между подразделениями или с внешним заказчиком.
📌 Протокол совещания по согласованию бюджета проекта
- Сценарий: совещание между командой проекта и финансовым подразделением по утверждению бюджета
- Адресат: руководитель проекта, финансовый директор, куратор
- Задача: зафиксировать согласованный бюджет и разногласия, которые остались
Пример:
ПРОТОКОЛ № 2
совещания по согласованию бюджета проекта "Внедрение системы электронного документооборота"
Дата: 17 мая 2025 г.
Время: 14:00–15:30
Председатель: Лазарев В. Ю., директор по развитию
Секретарь: Овчинникова А. С.
Присутствовали:
- Лазарев В. Ю. – директор по развитию (куратор проекта)
- Пономарева Е. Р. – финансовый директор
- Горбунов С. А. – руководитель проекта
- Овчинникова А. С. – помощник руководителя проекта
Предмет обсуждения: запрошенный бюджет на реализацию проекта – 2 400 000 рублей. Финансовый директор предложила сократить до 1 800 000 рублей.
Позиция руководителя проекта (Горбунов С. А.):
Сокращение бюджета более чем на 15% без изменения объема работ невозможно. Основная статья расходов – лицензии на программное обеспечение (840 000 рублей) и интеграционные работы (620 000 рублей). Эти статьи не подлежат сокращению без исключения функциональных блоков.
Позиция финансового директора (Пономарева Е. Р.):
Утвержденный бюджетный лимит на второй квартал не позволяет выделить более 1 800 000 рублей. Предложение: реализовать проект в двух очередях; первая очередь – в пределах лимита.
Принятые решения:
- Принять концепцию поэтапной реализации: первая очередь – в пределах 1 800 000 рублей, вторая очередь – в третьем квартале 2025 г.
- Горбунову С. А. подготовить скорректированный план с разделением на очереди до 21 мая 2025 г.
- Пономаревой Е. Р. подтвердить возможность выделения второго транша в третьем квартале до 21 мая 2025 г.
- Лазареву В. Ю. утвердить скорректированный план до 23 мая 2025 г.
Зафиксированное разногласие: Горбунов С. А. выразил несогласие с поэтапным подходом, указав на риск потери функциональной связности системы при разделении на очереди. Его позиция зафиксирована в протоколе. Окончательное решение принято куратором проекта Лазаревым В. Ю.
Подписи:
Председатель: Лазарев В. Ю. ___________
Финансовый директор: Пономарева Е. Р. ___________
Руководитель проекта: Горбунов С. А. ___________
- Почему подходит: блок "Зафиксированное разногласие" – ключевой элемент такого протокола. Он не замалчивает несогласие, а легитимно его фиксирует. Это защищает и того, кто был против, и того, кто принял решение.
- Когда особенно уместен: при любых финансовых согласованиях, где важно понимать, кто какую позицию занял и кто принял финальное решение.
- Что важно не испортить: позиция несогласной стороны должна быть изложена корректно и без интерпретаций. Пишите так, как человек сам сформулировал свою позицию.
📌 Протокол совещания при наличии расхождений в позициях сторон
- Сценарий: совещание по спорному вопросу между двумя подразделениями в рамках совместного проекта
- Адресат: руководители подразделений и арбитр – вышестоящий руководитель
- Задача: зафиксировать позиции, договоренность или порядок разрешения спора
Пример:
ПРОТОКОЛ № 8
совещания по урегулированию разногласий по проекту "Единая база клиентов"
Дата: 21 мая 2025 г.
Время: 16:00–17:00
Председатель: Ефимов А. В., генеральный директор
Секретарь: Кириллова Н. С.
Присутствовали:
- Ефимов А. В. – генеральный директор
- Марков Д. Л. – директор по продажам
- Ульянова Т. В. – директор по IT
- Кириллова Н. С. – помощник генерального директора
Предмет разногласия:
Отдел продаж настаивает на интеграции базы клиентов с внешней CRM-системой (SaaS-решение). IT-департамент предлагает разработку собственного модуля на базе действующей инфраструктуры.
Позиция отдела продаж (Марков Д. Л.):
Внешнее SaaS-решение доступно немедленно, не требует разработки и обеспечивает нужный функционал. Задержка из-за собственной разработки ведет к потере клиентов уже сейчас. Ориентировочная стоимость: 120 000 рублей в год.
Позиция IT-департамента (Ульянова Т. В.):
Внешнее решение создает риски: зависимость от вендора, хранение данных за пределами периметра компании, невозможность кастомизации. Собственный модуль потребует 3 месяца и 350 000 рублей, но будет полностью под контролем.
Решение председателя:
Ефимов А. В. принял следующее решение: на период разработки собственного модуля (3 месяца) использовать внешнее SaaS-решение с ограниченным набором данных (без персональных данных клиентов). Параллельно IT-департамент ведет разработку. После сдачи собственного модуля – миграция данных и отказ от SaaS.
Поручения:
- Маркову Д. Л. выбрать и согласовать SaaS-решение с Ульяновой Т. В. до 26 мая 2025 г.
- Ульяновой Т. В. подготовить план разработки собственного модуля до 28 мая 2025 г.
- Кирилловой Н. С. зафиксировать договоренность в приложении к договору с IT-подрядчиком.
Подписи:
Председатель: Ефимов А. В. ___________
Директор по продажам: Марков Д. Л. ___________
Директор по IT: Ульянова Т. В. ___________
- Почему подходит: когда стороны не пришли к согласию самостоятельно, протокол фиксирует арбитражное решение. Это избавляет от ситуации, когда каждый через месяц помнит "свое" решение.
- Термин "SaaS-решение": программное обеспечение, доступное по подписке через интернет, без установки на серверы компании.
- Что важно не испортить: в таком протоколе обязательно должно быть видно, кто принял финальное решение и на каком основании. Анонимное "было решено" здесь не работает.
Протокол закрытия этапа или проекта: образцы документов
Закрывающий протокол подводит официальный итог этапа или всего проекта. Он фиксирует, что было выполнено, что передается, кто принял результат и на каких условиях. Без такого документа команда рискует оказаться в ситуации, когда заказчик через полгода говорит: "Мы это не принимали". Закрывающий протокол – это точка, которая ставится осознанно.
📌 Протокол закрывающего совещания по первому этапу
- Сценарий: завершение первого этапа проекта, передача результатов заказчику
- Адресат: руководитель проекта, представитель заказчика, куратор
- Задача: зафиксировать приемку результатов этапа и условия перехода ко второму
Пример:
ПРОТОКОЛ № 9
закрывающего совещания по первому этапу проекта "Разработка корпоративной системы отчетности"
Дата: 23 мая 2025 г.
Время: 11:00–12:00
Председатель: Щукин Р. О., куратор проекта
Секретарь: Логинова В. А.
Присутствовали:
- Щукин Р. О. – куратор проекта
- Логинова В. А. – менеджер проекта (исполнитель)
- Беляев С. Н. – технический руководитель (исполнитель)
- Горохова И. П. – представитель заказчика
Результаты первого этапа, представленные к приемке:
- Техническое задание на систему (версия 1.2, утверждена 5 мая 2025 г.).
- Прототип интерфейса (10 экранов, передан 20 мая 2025 г.).
- Архитектурная схема базы данных.
- Отчет об анализе требований.
Результаты приемки:
Горохова И. П. подтвердила соответствие результатов первого этапа техническому заданию. Замечаний по существу нет. Зафиксировано одно пожелание: уточнить логику фильтрации в прототипе интерфейса – не блокирует приемку, учитывается в задачах второго этапа.
Решения:
- Принять результаты первого этапа без замечаний.
- Логиновой В. А. сформировать пакет документов для оплаты первого этапа до 24 мая 2025 г.
- Логиновой В. А. внести пожелание по фильтрации в бэклог второго этапа до 24 мая 2025 г.
- Второй этап начинается 27 мая 2025 г. согласно утвержденному плану.
Подписи:
Куратор: Щукин Р. О. ___________
Менеджер проекта: Логинова В. А. ___________
Представитель заказчика: Горохова И. П. ___________
- Почему подходит: блок "Результаты приемки" с явным указанием на отсутствие замечаний – ключевой элемент. Именно он фиксирует факт приемки юридически значимым образом.
- Как применять: к такому протоколу прикладываются все передаваемые документы в виде пронумерованных приложений.
- Что важно не испортить: пожелания, не являющиеся замечаниями, нужно четко отделять от замечаний. Иначе "пожелание" превратится в претензию при следующей встрече.
📌 Протокол финального совещания по завершенному проекту
- Сценарий: официальное закрытие проекта после сдачи всех результатов
- Адресат: все ключевые участники проекта
- Задача: зафиксировать итоги, уроки и передачу ответственности
Пример:
ПРОТОКОЛ № 12
финального совещания по проекту "Запуск интернет-магазина"
Дата: 23 мая 2025 г.
Время: 15:00–16:30
Председатель: Колесников П. Б., генеральный директор
Секретарь: Соловьева Ж. Н.
Присутствовали: Колесников П. Б., Соловьева Ж. Н., Куликов А. Г. (руководитель проекта), Тарасова О. В. (дизайн), Климов В. Д. (разработка), Русакова Н. Е. (маркетинг).
Итоги проекта:
Выполнено в срок:
- Разработка и запуск сайта (сдан 20 мая 2025 г., плановая дата – 22 мая 2025 г.).
- Интеграция с платежной системой.
- Настройка системы аналитики.
- Запуск рекламных кампаний в трех каналах.
Выполнено с отклонениями:
- Мобильная версия сайта – задержка 5 дней из-за правок по дизайну. Сдана 18 мая 2025 г. (план – 13 мая 2025 г.).
- Раздел "Отзывы" – реализован в упрощенном виде; полный функционал перенесен на следующий квартал.
Ключевые уроки проекта:
- Правки дизайна мобильной версии не были включены в первоначальное ТЗ – в следующих проектах фиксировать требования к адаптивности отдельным пунктом.
- Согласование макетов с маркетингом занимало больше времени, чем планировалось – ввести единый срок на согласование (не более 2 рабочих дней).
Передача ответственности:
- Техническая поддержка сайта – Климов В. Д., начиная с 24 мая 2025 г.
- Ведение рекламных кампаний – Русакова Н. Е.
- Обновление контента – Соловьева Ж. Н.
Решения:
- Проект считается завершенным с 23 мая 2025 г.
- Куликову А. Г. подготовить итоговый отчет по проекту до 27 мая 2025 г.
- Колесникову П. Б. утвердить отчет и направить команде до 30 мая 2025 г.
Подписи:
Председатель: Колесников П. Б. ___________
Руководитель проекта: Куликов А. Г. ___________
- Почему подходит: блок "Ключевые уроки проекта" – редкий, но очень ценный элемент. Он превращает протокол из формального документа в инструмент развития команды.
- Как применять: финальный протокол хранится дольше всех остальных. Его стоит сохранять в архиве проектов как образец для следующих команд.
- Что важно не испортить: передача ответственности должна быть именной, с датой. Размытая фраза "поддержка переходит к IT-отделу" без конкретного человека – это не передача.
Как составить протокол проектного совещания. Правила и этапы сборки с примерами
Примеры выше показывают, как работает каждый формат изнутри: что фиксируется, в каком порядке, какими формулировками. Ниже – не абстрактные советы, а разбор сборки протокола по шагам. Этот блок нужен для того, чтобы вы могли составить свой вариант под конкретную задачу, а не переносить чужое содержание без адаптации.
Базовая схема сборки протокола проектного совещания:
- Шаг 1. Шапка документа – реквизиты встречи.
- Шаг 2. Список участников.
- Шаг 3. Повестка дня.
- Шаг 4. Ход обсуждения (для развернутого формата) или краткое резюме (для краткого).
- Шаг 5. Решения и поручения с ответственными и сроками.
- Шаг 6. Особые отметки (разногласия, риски, условия).
- Шаг 7. Дата следующего совещания.
- Шаг 8. Подписи.
Таблица блоков протокола:
| Блок | Зачем нужен | Что сюда подставляется | Пример заполнения |
| Шапка документа | Идентифицировать встречу: кто, когда, по какому проекту | Номер протокола, название проекта, дата, время, место, председатель, секретарь | Протокол № 3 совещания по проекту "Запуск мобильного приложения", 15 мая 2025 г., 10:00, онлайн |
| Список участников | Зафиксировать, кто присутствовал и в какой роли | ФИО, должность или роль в проекте | Иванов А. С. – руководитель проекта; Петрова Н. Л. – ведущий разработчик |
| Повестка дня | Обозначить, что обсуждалось. Служит структурой для раздела решений | Нумерованный список вопросов, вынесенных на совещание | 1. Статус выполнения задач. 2. Согласование нового дедлайна. 3. Распределение ресурсов |
| Ход обсуждения / резюме | Показать логику принятых решений. В кратком формате – только суть | Позиции участников, аргументы, предложения, промежуточные выводы | Соколов В. Д. предложил перенести дедлайн на 7 дней в связи с задержкой API. Команда согласилась при условии ежедневных отчетов |
| Решения и поручения | Зафиксировать итог: что делается, кто делает, к какому сроку | Формулировка задачи, ФИО ответственного, дата исполнения | Соколову В. Д. завершить интеграцию API до 22 мая 2025 г. |
| Особые отметки | Зафиксировать разногласия, риски или условия, которые важно сохранить | Несогласие участника, риск, ограничение, оговорка | Миронов С. В. выразил несогласие с переносом сроков, указав на контрактные обязательства. Позиция зафиксирована |
| Следующее совещание | Обозначить точку следующего контроля | Дата, время, формат | 29 мая 2025 г., 10:00, онлайн |
| Подписи | Подтвердить, что участники согласны с содержанием протокола | ФИО председателя, секретаря и при необходимости других ключевых участников | Председатель: Иванов А. С. ___ Секретарь: Петрова Н. Л. ___ |
Пошаговая сборка на одном кейсе:
Сценарий: небольшая IT-команда проводит плановое совещание по статусу проекта разработки мобильного приложения. Нужен краткий протокол с поручениями.
Шаг 1. Шапка. Определяем реквизиты: проект – "Мобильное приложение для записи к врачу", дата – 15 мая 2025 г., время – 10:00–10:45, формат – онлайн, председатель – Иванов А. С. (руководитель проекта), секретарь – Петрова Н. Л.
Шаг 2. Участники. Перечисляем всех присутствующих с ролями. В этом случае: руководитель проекта, два разработчика, дизайнер, представитель заказчика.
Шаг 3. Повестка. Три вопроса: статус задач, согласование изменения в функционале, распределение задач на следующую неделю.
Шаг 4. Резюме обсуждения. Выяснилось, что интеграция с внешним API задерживается на 3 дня. Заказчик хочет добавить функцию напоминаний – команда оценила трудозатраты в 2 дня дополнительной разработки. Договорились включить в текущий спринт.
Шаг 5. Решения. Три поручения: Соколову завершить API до 22 мая, Кузнецовой реализовать напоминания до 24 мая, Петровой обновить план проекта до 16 мая.
Шаг 6. Особых отметок нет.
Шаг 7. Следующее совещание: 22 мая 2025 г., 10:00, тот же формат.
Шаг 8. Подписи: председатель и секретарь.
Готовая собранная версия:
ПРОТОКОЛ № 5
еженедельного совещания по проекту "Мобильное приложение для записи к врачу"
Дата: 15 мая 2025 г.
Время: 10:00–10:45
Формат: онлайн (Zoom)
Председатель: Иванов А. С., руководитель проекта
Секретарь: Петрова Н. Л.
Присутствовали:
- Иванов А. С. – руководитель проекта
- Соколов В. Д. – backend-разработчик
- Кузнецова Р. Л. – frontend-разработчик
- Морозов Г. А. – дизайнер
- Алексеева Т. Н. – представитель заказчика
- Петрова Н. Л. – менеджер проекта / секретарь
Повестка дня:
- Статус задач текущего спринта.
- Изменение функционала: добавление напоминаний.
- Распределение задач на следующую неделю.
Краткое резюме обсуждения:
Соколов В. Д. сообщил о задержке интеграции с API внешнего расписания на 3 дня в связи с изменением документации на стороне поставщика. Алексеева Т. Н. запросила добавление функции push-напоминаний о записи. Кузнецова Р. Л. оценила трудозатраты в 2 дня. Команда приняла решение включить задачу в текущий спринт без изменения общего дедлайна.
Решения и поручения:
- Соколову В. Д. завершить интеграцию с API до 22 мая 2025 г.
- Кузнецовой Р. Л. реализовать функцию push-напоминаний до 24 мая 2025 г.
- Петровой Н. Л. обновить план проекта с учетом изменений до 16 мая 2025 г.
Следующее совещание: 22 мая 2025 г., 10:00, Zoom.
Подписи:
Председатель: Иванов А. С. ___________
Секретарь: Петрова Н. Л. ___________
Когда схема работает, а где ломается:
- Работает: при регулярных встречах с четким кругом участников и понятной повесткой. Чем регулярнее встреча, тем быстрее заполняется протокол – структура уже знакома всем.
- Ломается: когда повестка не определена заранее. Без повестки невозможно структурировать ход обсуждения и решения.
- Что нельзя выкидывать: ответственный и срок в каждом поручении – это минимум, без которого протокол теряет смысл как инструмент контроля.
- Что можно менять: наличие блока "Ход обсуждения" (для кратких встреч он не нужен), форму таблицы поручений, количество подписей.
- Что нельзя переносить бездумно: формулировки из чужого протокола. Особенно это касается описания разногласий и особых отметок – они должны точно отражать вашу конкретную ситуацию, а не чужую.
Практические советы по составлению протокола проектного совещания
| Аспект | Рекомендация | Зачем это важно |
| Время составления | Отправляйте протокол в день совещания или на следующий рабочий день | Через 3–4 дня детали стираются, возникают разночтения |
| Уровень детализации | Фиксируйте решения, а не пересказ разговора | Длинный стенографический протокол никто не читает |
| Поручения | Каждое поручение – один ответственный, один срок | Коллективная ответственность = ничья ответственность |
| Разногласия | Фиксируйте несогласие честно, без смягчений | Замолчанное несогласие всплывет позже и уже без документального подтверждения |
| Статус задач | На каждом следующем совещании начинайте с проверки предыдущего протокола | Протокол работает только в связке с контролем исполнения |
| Нумерация | Нумеруйте протоколы последовательно в рамках проекта | При спорах легко найти нужный документ по номеру |
| Хранение | Храните протоколы в едином месте, доступном всей команде | Протокол в личной почте одного участника – не протокол |
6 практических приемов, которые делают протокол рабочим инструментом:
- Готовьте шаблон заранее. Откройте документ до начала встречи, заполните шапку и повестку. Это сокращает время на оформление после совещания.
- Ведите протокол в реальном времени. Записывайте ключевые тезисы прямо во время обсуждения, не полагаясь на память. После совещания остается только структурировать.
- Проверяйте поручения перед отправкой. Убедитесь, что у каждого поручения есть ответственный и срок. Если нет – это не поручение, а пожелание.
- Согласовывайте протокол с председателем. Перед рассылкой дайте председателю 15 минут на проверку. Это исключает ситуацию, когда секретарь зафиксировал не то, что было сказано.
- Используйте нумерацию вопросов в решениях. "По вопросу 2 решено…" – такая структура позволяет быстро найти нужный блок в длинном протоколе.
- Не смешивайте форматы в одном документе. Если вы ведете краткий протокол, не добавляйте в него длинные цитаты и пересказ дискуссии. Если нужен развернутый – делайте его сразу таким.
Грамотно составленный шаблон протокола проектного совещания – это не бюрократия, а рабочий инструмент. Он экономит время на выяснение "кто что должен был сделать" и снижает количество конфликтов внутри команды. Чем регулярнее команда ведет протоколы, тем быстрее формируется культура ответственности за договоренности.
Используйте примеры из этой подборки как ориентир для понимания структуры и логики документа, а не как тексты для копирования. Адаптируйте под свой проект, свою команду и свой уровень формальности – и протокол станет частью нормального рабочего процесса, а не обузой.
