Еженедельный отчёт PM по проекту: структура, шаблон и правила подготовки

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

Хороший weekly report отвечает на три вопроса: что изменилось за неделю, что будет проверено дальше и где проект может потерять срок, бюджет, качество или управляемость. По такому отчёту можно оценивать не только состояние проекта, но и качество работы PM: видит ли он риски, отделяет факты от шума, заранее поднимает решения и умеет держать контур управления без ручного контроля.

• Синхронизировать ожидания. Руководитель, клиент и команда видят одну картину: статус, результаты, риски и следующий контрольный результат.
• Убрать зависимость от устных пояснений. Проект не должен жить только в звонках, чатах и личной памяти PM.
• Раньше видеть отклонения. Yellow или Red появляются до того, как срок уже сорван или бюджет потрачен.
• Сократить лишние встречи. Если статус понятен из письма, встреча нужна только для решений и спорных вопросов.
• Оценивать управляемость проекта. В отчёте видно, какие риски сняты, какие решения зависли и что стало более предсказуемым за неделю.

Если по итогам встречи нужно зафиксировать решения и задачи, используйте отдельный протокол: как фиксировать итоги встреч на ИТ-проекте. Если нужен формат самой встречи по статусу, см. материал что такое status meeting.

Базовый режим — раз в неделю, в пятницу днём, например до 16:00. Вечером отправлять не стоит: у PM должно остаться время на уточнения, а у руководителя и клиента — возможность прочитать отчёт до выходных. Если у команды другая рабочая неделя или клиентский ритм, важнее фиксированная периодичность, чем именно пятница.

Статус должен показывать управленческое состояние проекта, а не настроение команды. Если проект технически активен, но есть зависшее решение клиента, риск по сроку или изменение объёма, статус не должен оставаться Green только потому, что разработчики заняты.

Если сомневаетесь между Green и Yellow, выбирайте Yellow и объясняйте причину. Yellow — это не провал, а раннее предупреждение. Red — не повод скрывать проблему, а сигнал, что требуется управленческое решение.

• Общий статус. Одна строка: цвет и причина. Не пишите длинную историю проекта в первом абзаце.
• Что изменилось за неделю. Фиксируйте изменения, которые влияют на план, ожидания, риски, объём или принятие решений.
• Полученные результаты. Используйте проверяемые формулировки: «показан прототип», «принят сценарий», «получен доступ», «закрыт дефектный блок», «согласован состав интеграций».
• Следующий контрольный результат. Указывайте не просто «работаем над модулем», а «демо сценария оплаты до 24 июля» или «согласованный список полей обмена до 22 июля».
• Риски и действия. Риск без действия превращает отчёт в жалобу. Должны быть владелец, срок проверки и текущее действие.
• Что требуется от внутреннего руководителя. Не больше трёх пунктов: решение, эскалация, подтверждение change request или помощь со стороны исполнителя. Если запросов больше, значит PM не выделил главное.
• Что требуется от клиента. Формулируйте так, чтобы клиент видел цену задержки: какой результат сдвинется, если ответа не будет.
• Изменения объёма, сроков и стоимости. Любое изменение обязательств должно быть видно письменно, даже если пока нет финального решения.
• Следующая неделя. Пишите через результаты, а не через занятость команды.
• Что стало более управляемым. Показывайте снятые риски, введённые правила, стабилизированные процессы, закрытые зависимости.
• Формат пунктов. Внутри разделов лучше использовать короткие списки: один пункт — один факт, риск, результат или запрос. Длинные абзацы допустимы только для краткого пояснения статуса.

Что изменилось за неделю:

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

Полученные результаты:

• Показан прототип главной страницы кабинета.
• Клиент принял сценарий авторизации.
• Команда завершила API для карточки поставщика.
• QA начал проверку загрузки файлов.

Следующий контрольный результат: до 24 июля показать демо сценария «поставщик обновляет документы, менеджер проверяет и отклоняет с комментарием».

Что требуется от внутреннего руководителя:

• Подтвердить, можно ли выносить историю банковских реквизитов в отдельный change request, если оценка превысит 16 часов.

Что требуется от клиента:

• До 22 июля выдать тестовый доступ к учётной системе.
• До 23 июля подтвердить, кто принимает сценарий отклонения документов.

Изменения объёма, сроков и стоимости: новое требование по истории реквизитов пока не включено в обязательства этапа. Влияние будет оценено отдельно.

Следующая неделя:

• Завершить демо сценария проверки документов.
• Получить доступ к учётной системе.
• Согласовать решение по истории реквизитов.

Что стало более управляемым:

• Роли пользователя и сценарий авторизации больше не требуют ручных уточнений.
• Список доступов вынесен в отдельный контрольный пункт.

1. Зафиксировать один шаблон. Не начинать с сложной системы отчётности. Достаточно структуры из этой статьи и правила отправки раз в неделю.
2. Выбрать получателей. Минимум: PM, руководитель проекта или аккаунт, клиентский представитель. Для рисковых проектов добавляется руководитель компании или delivery lead.
3. Договориться о времени. Например, каждую пятницу до 16:00. Если клиент работает по другому календарю, выбрать другой фиксированный слот.
4. Первые две недели проверять качество отчётов. Руководитель должен смотреть не стиль письма, а наличие статуса, фактов, рисков, следующего результата и запросов.
5. Не превращать отчёт в бюрократию. Если проект маленький, отчёт может занимать одну страницу. Важно не количество текста, а управленческая ясность.
6. Связать отчёт с проектными артефактами. Риски должны попадать в RAID или отдельный список рисков, решения — в decision log, изменения объёма — в change log или договорной контур.

Для регулярных проектных встреч можно использовать связанный материал типы встреч на ИТ-проекте. Еженедельный отчёт хорошо работает рядом с weekly sync и status meeting, но не дублирует их.

Тема письма: Weekly report: [проект], [период], [Green/Yellow/Red]

Проект:
Период:
PM:

1. Общий статус
Green / Yellow / Red.
Краткая причина статуса.

2. Что изменилось за неделю
- Существенное изменение 1.
- Существенное изменение 2.

3. Полученные результаты
- Что завершено, принято или показано.
- Что можно проверить.

4. Следующий контрольный результат
Что должно быть получено:
Дата:
Критерий проверки:

5. Риски и действия
Риск:
Влияние:
Ответственный:
Что уже предпринимается:
Дата следующей проверки:

6. Что требуется от внутреннего руководителя
1.
2.
3.

7. Что требуется от клиента
Запрос:
Дата:
Что будет заблокировано без ответа:

8. Изменения объёма, сроков и стоимости
Что изменилось:
Влияние на обязательства:
Следующее действие:

9. Следующая неделя
- Главный результат 1.
- Главный результат 2.

10. Что стало более управляемым
Какой риск снят, процесс введён или контур больше не требует постоянного ручного контроля.

• Посмотреть карту документации и артефактов проекта.
• Собрать roadmap проекта из требований.
• Настроить фиксацию решений и задач после встреч.