Шаблон за статусен доклад по проект: седмичен формат, пример — и как докладът се сглобява сам от резюметата (2026)

Статусният доклад по проект е кратка страница с фиксиран формат, която казва на хората извън ежедневната работа докъде е стигнал проектът: по план ли е, какво се е променило от предишния доклад, какво може да се обърка и какво се иска от читателя да реши. Пише се с определена периодичност, при повечето проекти седмично, и страницата е всеки път една и съща. Така читателят сравнява тази седмица с миналата, вместо да чете от нулата.

Това ръководство започва със занаята: форматът, шаблон, който можете да копирате, попълнен пример и по-кратка седмична версия за ръководител на екип, който докладва нагоре. После следва механиката: кога докладът е достатъчен и кога все пак си струва да свикате среща за статус, къде се пише докладът в инструментите, които екипът ви вече използва, и какво се случва между срещите и страницата. Защото най-трудната част от доклада не е писането. Тя е половин часът преди това, когато ръководителят преглежда седмица разговори и чатове, за да разбере какво всъщност е договорено.

Какво е статусен доклад по проект — и какво не е

Около един проект кръжат четири документа и докладът е този, който най-често се бърка с останалите:

Резюмето е за една среща, докладът е за седмицата във всички тях. Стендъпът показва пречките на хората, които могат да ги разчистят. Докладът казва на някой по-далечен дали тези пречки застрашават срока. Дневникът на решенията пази защо, а докладът казва само, че решение е взето или още е нужно. Ако докладът се пише трудно, причината почти винаги е по-нагоре: срещите през седмицата не са оставили запис за резултатите си и ръководителят ги възстановява по памет в петък следобед.

Седмичният формат: шест блока, една страница

Доклад, който се чете всяка седмица, трябва да се събира на един екран и да запазва една и съща форма. Шест блока, в този ред:

1. Заглавна част. Проект, отчетен период, автор, дата на следващия доклад. Читателите първо търсят периода. Докладът без период е страница с твърдения без „от кога".
2. Общ статус в един ред. Зелено, жълто или червено, или по план, под риск, извън плана, плюс едно изречение защо. Цветът обобщава блоковете по-долу и не е усещане. Ако блокът за рисковете казва, че доставчик се е забавил с две седмици, редът не може да казва зелено.
3. Напредък от последния доклад. От три до шест реда за това, което е завършено, всеки като резултат, а не като дейност. „Процесът на плащане е на преглед при клиента" е факт; „работихме по плащането" не е.
4. Следващ период. Какво екипът се ангажира да завърши до следващия доклад, всичко с отговорник. С този блок ще се сверява блокът за напредък на следващата седмица.
5. Рискове, проблеми и нужни решения. Рискът е нещо, което може да се случи; проблемът е нещо, което вече се е случило. Всеки ред: какво, ефектът върху срока или бюджета, отговорникът и какво се иска от читателя, включително „нищо, за сведение". Нужните решения имат собствен ред с датата, до която проектът има нужда от отговора.
6. Отворени действия. Всяко действие от всяка среща през периода, което още е отворено, с отговорник и срок, като закъснелите са отбелязани. Повечето доклади пропускат именно този блок, а читателят го използва, за да прецени дали цветът в блок 2 е честен.

Три неща се оставят навън: диалози (кой какво е казал), дневници на дейността (часове, проведени разговори) и всичко, по което читателят не би могъл да действа. Докладът е за човек, който ще отдели четири минути. Всеки ред трябва да издържи на въпроса „какво би направил читателят по различен начин, ако знае това?"

Шаблон за статусен доклад по проект

Копирайте го в документ, съобщение в канал или canvas. Квадратните скоби са запълващи полета.

[Проект] — статусен доклад за [период, напр. 20–24 октомври]
Автор: [име] · Изпратен: [дата] · Следващ доклад: [дата]
Общо: [по план / под риск / извън плана] — [едно изречение защо]

Свършено от последния доклад
– [Резултат, като факт] — [отговорник]
– [Резултат] — [отговорник]
– [Резултат] — [отговорник]

Следващ период (до [дата на следващия доклад])
– [Резултат за предаване] — [отговорник]
– [Резултат за предаване] — [отговорник]

Рискове и проблеми
– [Риск или проблем] — ефект: [срок / бюджет / обхват] — отговорник: [име] — искане: [решение до дата / за сведение]

Нужни решения
– [Въпрос, с вариантите на масата] — нужно до [дата] — от [име]

Отворени действия
– [Задача] — [отговорник] — срок [дата] — [отворено / закъсняло от дата]
– [Задача] — [отговорник] — срок [дата] — [отворено]

Редът е умишлен. Спонсор, който прочете само първите три реда, получава цвета и причината; който стигне до края, получава действията, които обясняват цвета. Пазете заглавията еднакви от седмица на седмица, защото стойността на формата е в сравнението.

Пример: попълнен седмичен статусен доклад

Малък софтуерен проект, двуезичен екип, клиент, който чете доклада всеки понеделник:

Order portal v2 — статусен доклад за 20–24 октомври
Автор: Mateusz · Изпратен: 24 октомври · Следващ доклад: 31 октомври
Общо: под риск — sandbox средата на платежния доставчик пристигна с четири дни закъснение; датата на пускане се запазва само ако интеграционният тест мине до 29 октомври.

Свършено от последния доклад
– Процесът на плащане е на преглед при клиента; два коментара са отворени — Ana
– Импортът на продукти от ERP работи всяка нощ в staging — Priya
– Текстовете на интерфейса на испански и румънски са готови; френският е на 80% — Luca

Следващ период (до 31 октомври)
– Тест на платежната интеграция в sandbox средата на доставчика — Priya
– Одобрение от клиента на процеса на плащане — Ana
– Френските текстове са готови, трите езика са прегледани — Luca

Рискове и проблеми
– Забавяне на платежния sandbox (проблем) — ефект: пускането на 7 ноември се запазва само ако тестът мине до 29 октомври; иначе 14 ноември — отговорник: Priya — искане: за сведение, решението е по-долу
– Време за преглед от клиента (риск) — ефект: всеки кръг отнема 3 дни; трети кръг измества одобрението след прозореца за теста — отговорник: Ana — искане: клиентът да събере коментарите в един кръг

Нужни решения
– Ако тестът пропадне на 29 октомври: пускане на 14 ноември с плащания, или на 7 ноември само с плащане по фактура, а картовите плащания да се добавят по-късно — нужно до 30 октомври — от клиента

Отворени действия
– Изпращане на доставчика на списъка с разрешени IP адреси — Priya — срок 21 октомври — закъсняло от 21 октомври
– Потвърждаване на прозореца за пускане в продукция с хостинг партньора — Mateusz — срок 28 октомври — отворено
– Отговор на двата коментара по плащането — Ana — срок 27 октомври — отворено

Забележете какво примерът не казва: колко срещи са проведени, кой е говорил, колко часа са отишли. Читателят научава с един ред, че датата е под риск, и с един блок какво се иска от него да реши.

Седмичен доклад за ръководител на екип

Седмичният доклад на ръководител на екип към собствения му мениджър е по-кратък събрат на проектния доклад. Читателят е един човек, обикновено с по-малко от две минути, и въпросите са три: изпълнява ли екипът ангажиментите си, какво пречи и какво ви трябва от мен. Четири блока се събират в чат съобщение:

Екип [име] — седмица от [дата]
Статус: [по план / под риск] — [един ред]
Доставено: [два или три резултата, всеки с име]
Пречи: [една или две пречки, всяка с кого може да я разчисти]
Нужно от вас: [едно решение или ресурс, с дата] — или „нищо тази седмица"

Две правила правят доклада четим с месеците. Първо, „Нужно от вас" никога не е празно случайно: пишете „нищо тази седмица", за да знае мениджърът, че мълчанието е умишлено. Второ, „Доставено" изброява имена на хора, защото седмичният доклад е и мястото, където ръководителят прави работата на екипа видима за някой, който не я вижда всеки ден. Ако екипът вече води ежедневен стендъп с именувани пречки, „Пречи" е копие на тези, които още стоят в петък.

Седмичният доклад заменя седмичната среща за статус за по-голямата част от това, което срещата е носела, тоест информацията. Какво не може да замести, е описано по-нататък.

Кога среща за статус все още е нужна

Срещата за статус е живата форма на доклада: всеки казва на ръководителя или на спонсора докъде е стигнал, в една стая, на цената на времето на всички. Щом съществува писмен доклад, срещата е оправдана само когато страницата не може да свърши работата. Четири случая:

• Решение с компромис. Докладът може да изброи вариантите, но не може да преговаря за тях. Когато в „Нужни решения" има запис, чийто отговор зависи от това, от какво са готови да се откажат две заинтересовани страни, тридесет минути с двете в една стая струват повече от две седмици отговори до всички.
• Датата се измества. Забавяне рядко се приема от страница. Разговорът за това какво се мести заедно с нея, обхват, бюджет или старт на друг проект, е среща, а докладът е материалът за предварително четене.
• Рискът е прекрачил прага си. Седмицата, в която рискът става проблем, хората, които носят последствията, трябва да го чуят от ръководителя и да могат да задават въпроси, а не да го прочетат в понеделник.
• Нова заинтересована страна. Който не е чел предишните шест доклада, има нужда от една сесия, за да схване формата на проекта; след това страницата стига.

Срещата за статус не е за четене на доклада на глас. Ако всяка точка от дневния ред е „доклад от X", отменете я и изпратете страницата; ръководството за ритъма на срещите разглежда кои повтарящи се срещи заслужават мястото си. Когато срещата се проведе, водете я по доклада: блоковете за рисковете и решенията са дневният ред, а ефективната среща завършва с тези точки, отбелязани като решени, отворени или отложени. При заинтересовани страни, които говорят различни езици, за самата среща стаята има три възможности: преводач човек (ръководството за преводач в Zoom показва как се настройва това), собствените субтитри на платформата или пространство, което превежда за всеки участник поотделно. Докладът, написан веднъж, е отделен въпрос.

Къде се пише докладът в инструментите, които вече използвате

Всяка голяма платформа оставя след срещата нещо, от което може да се изгради статусен доклад, и всяка спира на различно място. Само документирано поведение, от страниците на самите доставчици, с месеца, в който е проверена всяка страница:

Две неща са еднакви навсякъде. Това, което срещата оставя, е един документ на среща, на единствения език, на който е говорила стаята; а дали следващите стъпки от миналата седмица са изпълнени, документът не знае — ръководителят отива и проверява, преди да напише „готово". Страната на платформите със субтитри на живо — това, което Teams и Google Meet показват на екрана по време на разговор — не променя документа след това. Бележниците са същата категория с една стъпка по-нататък: тези, сравнени в алтернативи на Otter.ai, пишат резюме на среща, а докладът, който обхваща месец срещи, остава отделна страница.

Как докладът се сглобява сам от резюметата

InterMIND е пространство за комуникация, в което проектът живее в канал, така че суровината за доклада има очевидно място. Всяка среща в канала завършва с резюме — обобщение, решения, задачи с отговорници и дати — написано от самата среща и доставено по имейл, като съобщение в канала и като линк в събитието в календара. Всеки влязъл член го чете на собствения си език: записът се превежда за всеки читател, а не се пише веднъж на езика, на който случайно е говорила стаята; същото важи и за чата в канала около него, в който всеки член пише на собствения си език. Всеки член може да редактира резюмето, всяка редакция пази автор и история на ревизиите, а каналът пази резюмето на всяка минала сесия — така „свършено от последния доклад" е преглед на резюметата от седмицата, а не възстановяване по памет.

Задачите носят статуса си със себе си. Една задача се показва като за изпълнение, изпълнена или неизпълнена с причина, а в организация с включени страници за статус на екипа отворените задачи от по-ранни сесии се преценяват при писането на следващото резюме: задача, за която някой е докладвал, че е свършена, се отбелязва като изпълнена; задача, обсъдена, но незавършена, се отбелязва като неизпълнена с причината, казана с думите на срещата; задача, за която никой не е заговорил, остава отворена. Това е блокът „отворени действия" от шаблона, воден от срещите, а не от ръководителя.

От страниците за статус на екипа идва останалото от доклада. Една страница за последните 7, 28 или 90 дни изброява задачите, проблемите, важното и спешното на организацията и парите, които са заложени, а всеки ред носи дословния цитат от резюмето, на което се основава; задачата стои, докато някой не я затвори, а след четири седмици без движение се отбелязва като заседнала. Ръководителят пише реда за тенденцията и цвета — преценката — върху страница, която срещите вече са попълнили. Същата страница се чете и през свързан асистент: ръководител, който работи в Claude, ChatGPT, Copilot или Gemini, пита за отворените задачи и проблеми през седмицата и получава редовете с цитатите им. Страниците за статус на екипа са функция в предварителен достъп при платените планове: администраторът на организацията ги включва в Settings → Advanced, след като приеме алфа условията (страницата Функции в предварителен достъп описва всяка от тях).

Когато докладът трябва да стигне до система за записи, домакинът добавя копие на резюмето на произволен адрес — входяща пощенска кутия на CRM или на тракер за проекти — и всяко резюме на срещата или канала се изпраща и там след еднократно потвърждение на адреса; механиката е в копие на всяко резюме от среща във вашия CRM, по имейл, а същото резюме пристига и като webhook или Zapier тригер за екипи, които го публикуват сами в тракер.

Клиентска страна, която трябва да вижда резюметата, се кани в канала по имейл и влиза с безплатен акаунт, като чете на собствения си език; външните участници в канал не струват нищо на домакина. Гост на една среща се присъединява с линк, без акаунт и безплатно — от телефон, в браузъра — и чува срещата на живо на собствения си език. След това за госта няма запис — акаунтът е безплатен и именно той прави записа достъпен. Домакинът осигурява пространството и при платен план плаща само за членовете, активни през последните 28 дни; членовете, които замлъкнат, запазват достъпа си безплатно.

• Отворете пълно резюме — истински запис, изготвен от същия код, който пише вашите.
• Изпробвайте демото на живо — без регистрация; говорете и чуйте стаята, преведена за всеки слушател.

Докладът като занаят оцелява във всеки инструмент: някой пак трябва да каже дали проектът е по план и защо. Това, което не е нужно да оцелява, е петъчният половин час — връщането през седмица разговори, на един език, за да се разбере какво е договорено и дали някой го е направил.

Често задавани въпроси

Какво е статусен доклад по проект?

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

Какво трябва да включва седмичният статусен доклад?

Шест блока: заглавна част с отчетния период; един ред общ статус с причината; напредък от последния доклад като резултати, а не дейности; ангажиментите за следващия период с отговорници; рискове, проблеми и нужни решения, всеки с ефекта си и искане; и всяко отворено действие с отговорник и срок, като закъснелите са отбелязани. Оставете навън диалозите, часовете и всичко, по което читателят не може да действа.

Как се пише статусен доклад по проект?

Тръгнете от предишния доклад: блокът му „следващ период" е чеклистът за тази седмица, а отворените му действия са или изпълнени, или още отворени. След това преминете през резюметата от срещите през седмицата за това, което е решено и добавено. Статусния ред пишете последен, след блока с рисковете, за да съвпада цветът с фактите. Изпращайте го в един и същ ден всяка седмица, до един и същ списък, и пазете заглавията еднакви от доклад на доклад.

Каква е разликата между статусен доклад и среща за статус?

Статусният доклад се пише и чете асинхронно; срещата за статус е същата информация, предадена на живо, на цената на времето на всички в стаята. Щом съществува доклад, срещата е оправдана, когато страницата не може да свърши работата: решение с компромис между заинтересовани страни, дата, която се измества, риск, който току-що е станал проблем, или нова заинтересована страна, на която веднъж е нужна формата на проекта. Среща, чийто дневен ред е „доклад от всеки", е доклад, четен на глас.

Различава ли се седмичният доклад за ръководител на екип от статусния доклад по проект?

По-кратък е и е адресиран до един човек. Седмичният доклад на ръководител на екип към мениджъра му отговаря на три въпроса в четири блока — статус в един ред, какво е доставил екипът с имена, какво пречи и кой може да го разчисти и какво е нужно от мениджъра и до кога — и се събира в чат съобщение. Статусният доклад по проект е по-дълъг, обхваща период и набор от заинтересовани страни и носи рискове, решения и отворени действия от всички срещи на проекта.

Колко често трябва да се изпраща статусният доклад по проект?

Седмично при повечето проекти: достатъчно често, за да се хване забавяне в рамките на седмица, и достатъчно рядко, за да има всеки доклад нещо ново. На две седмици е подходящо за дълги, устойчиви проекти с малко решения; ежедневното докладване е за седмица на пускане или инцидент и е друг, по-кратък документ. Каквато и да е периодичността, денят и списъкът с получатели не трябва да се менят — доклад, който пристига в различен ден всяка седмица, не се чете като поредица.

Трябва ли клиентът да получава статусния доклад?

Да, ако клиентът плаща за проекта и решение в доклада е негово — блокът „нужни решения" е писан за него. Където е възможно, пишете един доклад за всички, а не клиентска и вътрешна версия; докладът с две версии се разминава и вътрешната става истинската. Извън споделения доклад остава вътрешната подробност на екипа — индивидуално представяне, оценки в процес на договаряне, — която е за собствените бележки на ръководителя.

Източници: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" suggests next steps; Slack — Meeting agenda template (canvas). Страниците за бележките на Microsoft, бележките на Google Meet и Slack са проверени през октомври 2026; обявата на Google за следващите стъпки е проверена през септември 2026; страниците на Microsoft за резюмето и на Zoom за резюмето на срещата са проверени през август 2026. Доставчиците променят плановете, функциите и списъците с езици с времето; проверявайте страниците им за актуалното състояние.