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

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

Хороший еженедельный отчёт отвечает на три вопроса:

• что изменилось за неделю;
• что будет проверено дальше;
• где проект может потерять срок, бюджет, качество или управляемость.

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

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

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

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

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

Шаблон отчёта

Схема 1. Как источники собираются в еженедельный отчёт

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

1. Статус проекта — Green / Yellow / Red и короткая причина.
2. Что изменилось за неделю — существенные сдвиги, решения и новые вводные.
3. Результаты недели — 1–3 проверяемых результата: что завершено, принято, показано или доступно для проверки.
4. Следующий контрольный результат — что должно быть получено, дата и критерий проверки.
5. Риски и действия — главные риски недели: влияние, ответственный, действие и дата проверки. Полный список рисков ведётся отдельно, если он нужен.
6. Что требуется от руководителя — до трёх решений или действий.
7. Что требуется от клиента — ответ, доступ, согласование, материалы или решение с датой.
8. Изменения объёма работ, сроков и стоимости — что изменилось, как влияет на обязательства и какое действие нужно дальше.
9. Следующая неделя — 1–3 главных фокуса.
10. Что стало более управляемым — какой риск снят, процесс введён или контур больше не требует ручного контроля.

Источники данных для отчёта

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

Схема 2. Как подготовить отчёт

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

1. Собрать факты недели из трекера, чатов, встреч, демо, релизного контура и документов.
2. Отделить существенные изменения от ленты задач и рабочих обсуждений.
3. Выбрать 1–3 результата недели, которые можно проверить или принять.
4. Сформулировать следующий контрольный результат: что должно быть получено, к какой дате и как это проверить.
5. Проверить риски и вынести в отчёт только главные риски недели.
6. Указать ответственного, действие и дату проверки по каждому главному риску.
7. Сформулировать, какие решения или действия нужны от руководителя.
8. Сформулировать, что требуется от клиента и что сдвинется без ответа.
9. Проверить изменения объёма работ, сроков и стоимости.
10. Написать короткий статус Green / Yellow / Red и отправить отчёт.
11. После отправки перенести решения, риски и изменения в постоянные артефакты: журнал решений, реестр рисков, журнал изменений или договорный контур.

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

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

Если Yellow или Red регулярно возникает из-за поздних блокеров и зависших решений, проверьте как распределены владельцы задач и ответственность команды.

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

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

Проверка перед отправкой

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

• Понятен ли общий статус Green / Yellow / Red и причина статуса?
• Есть ли 1–3 результата недели, которые можно посмотреть, принять или проверить?
• Понятно ли, какой следующий контрольный результат ожидается и к какой дате?
• У каждого главного риска есть ответственный, действие и дата проверки?
• Ясно ли, какие решения или действия нужны от руководителя?
• Не скрыты ли изменения объёма работ, сроков или стоимости?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тема письма: Еженедельный отчёт: [проект], [период], [Green/Yellow/Red]

Проект:
Период:
Проектный менеджер:

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

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

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

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

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

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

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

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

9. Следующая неделя
- Главный результат или фокус 1.
- Главный результат или фокус 2.
- Главный результат или фокус 3, если он действительно нужен.

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

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