提到周报，有不少同学都会把它当做一种“负担”，是周末休息前的“拦路虎”，甚至前一阵子有大厂爆出有部门高调官宣取消周报的消息。

到底周报有没有用？项目周报应该怎么写才最有效率？

今天我们就这个主题跟大家唠唠。

我要~这周报有何用？

对我工作经历有所了解的同学都清楚，我一直是比较推崇敏捷的工作思路的。敏捷里对于何时应该写文档有一个比较有意思的论断：对于传递和理解信息有帮助的文档是有益的，其他的文档都是“邪恶”的。

周报亦是文档的一种，同理：对于传递和理解信息有帮助的周报是有益的，其他的周报都是“邪恶”的。

比如，你团队里就三两个人，每天干的事情彼此都一清二楚，Leader还要求写个周报，那多多少少有些“官僚”内味儿了。

再比如，在Scrum Team中，每天都有站会来回顾昨天的任务，明确的今天的安排以及整体进度，再要求Team成员出一个周报，就有些多余了。

所以，秉承着“paper work能不写就不写”的原则，我在担任Scrum Master的时候，团队成员是无需写周报的。因为他们工作内容我都清楚，我来对外输出即可。

包括我自己在对外传达Team进展的时候，也尽量避免“写”周报，引导关注Team进展的相关人等学会看燃烬图，学会去看Team的白板--实时进展都在板上，你要“日报”都可以。

碰到实在拗不过的“领导”，我也是拍张Team白板照片，插进PPT里，3两行字补充一下就完了，用不了5分钟。

哈哈，是不是很“头铁”？

都说屁股决定脑袋，周报既然是“老板”要的，我们在“吐槽”周报麻烦的同时，不妨花几秒钟的时间从“老板”的角度考虑考虑。

做个假设，比如你是一个100人的部门的头头，甚至是个上千人公司的CEO，你怎么去收集和下达信息？

拉群？开会？开大会？一人一句听都听不过来，记都记不住，更别谈去伪存真，支撑决策了。

怎么破？应对这个问题很自然的反应是组织分级，不同级的组织负责收集和传达相关的信息。

不同级别的组织负责人负责收集本组织的相关信息上报，同时负责把需要组织成员了解的信息传达到位。

自然而然的，工作周作为一个不太长也不太短的时间区间，比较适合成为工作汇总上报的周期。于是，霹雳一声震天响，“周”报就这样诞生了。

所以，网上戏谑的“你不写周报老板怎么合并周报呢”这种说法从某种角度上并没有错，事实的确如此。

但，如果认为老板写周报仅仅是简单的全量复制+粘贴那就有失偏颇了。

因为真的这么干，组织分级只是让信息更快的汇聚，并没有起到分层过滤的作用，对于中大型组织的决策管理者来说并没有太多帮助：信息还是那么海量稀碎。

笔者认为，写周报实际上就是一个信息汇总和提炼的过程：过滤无用信息，突出重要信息，化繁为简，达到有效向上传递信息的目的。

好的周报，能让重要信息变成“八百里加急”，迅速摆到上级决策者的案前并让他看进去，触发他的后续行动；坏的周报，也会“报喜不报忧”，掩盖一些实际情况。

但无论好坏，都应当承担“信息过滤”的功能，否则组织层级越多，周报自然变得又臭又长，不得要点。

到这里，我们基本讲清楚了，周报主要是上级用来获取信息的。既然如此，就应该花最少的时间传达最主要的信息即可。

注：当然，周报只是上级获取信息的重要手段，并不是唯一手段，兼听则明，偏信则暗嘛。

我想大家并不是讨厌周报，而是讨厌“花里胡哨，又臭又长而又言之无物”的周报。在实际工作中，笔者对于团队的要求是，写周报不应当超过30分钟，而笔者自己的周报用时也尽量控制不超过1个小时。

如果超过了这个时间，建议无论上下级都应当做些调查，问题到底在哪里？是记录事项过于琐碎，还是获取相关数据过于耗时，有的放矢的去做调整。至于在排版和字体上下“大”功夫，只要不是对外的文档，我认为都是没有太多必要的。

看到这里，可能有同学会问：周报的主要功能是向上传达信息，又不得不写，那对于我们自己难道就没有任何价值么？答案是当然有。

比较容易想到的是，周报是自己一周工作的总结，可以对应自己的短期目标实事求是的做个Review，看看下周的工作方向和节奏是否需要调整。

另外，还可以突出遇到的问题，向上级寻求支援。

同时，也可以记录一些自己的工作心得和收获。你的直接上级是有责任对于你的工作做辅助和支持，从而帮助你在专业领域中不断提升的。周报毫无疑问是一个天然的官方通道道。

综上，周报的主要作用是上传信息，所以务必简洁，突出重点。所以我们才会说周报是信息传递的必要手段，是不可或缺的。

前文提到的某大厂“废除周报”，倒是博了眼球，但在笔者看来，其实是“因噎废食”了。

项目周报如何写？

项目周报亦是周报的一种，那么其作用无外乎是向项目组内外传递项目状态，必要时寻求支持。

如何简洁快速的完成项目周报呢？今天给大家一个简单的实例，让大家5~6页纸搞定。

大的原则还是精简篇幅，与立项报告类似，让阅读者不一定要通读全文，当获取了自己足够想了解的信息，就可以离开。

第一页：“无需更新的”项目概览

这页就是项目立项通过时的相关项目信息。项目经理通常无需在写周报的时候更新。那么为什么还放这一页呢？原因有二：

其一，对于项目周报阅读者来说，可能对于项目并不完全了解前因后果，这一页可以帮助阅读者更好的进入项目场景。比如在多个项目的过堂会上，需要看的项目可能有十几二十个，哪记得住那么多项目的具体目标和项目里程碑？有这么一页就有了上下文，后面的讨论就更加有的放矢。

其二，对于项目经理来说，也不失为一个Review项目整体目标的机会。项目经理的日常工作通常比较琐碎，很容易忙于解决具体问题而忽略了项目整体目标。在忙碌了一周，开始写周报的时候，哪怕不用更新任何一个字，快速过一眼当初立项时的项目目标，从一定程度上避免“只见树木，不见森林”，也算是一个提醒自己不要让项目跑偏的好机会。

第二页：项目整体状态和当周进展

麦肯锡告诉我们结论先行。

所以这一页开始应该直接了当地把结论告诉阅读者：项目状态是否健康。

通常我们使用的是项目状态晴雨表。项目经理需要根据项目情况挑选唯一一个天气标识来表示项目状态：

先简单解释一下各个图标的含义：

晴天：一切顺风顺水

晴转多云：有部分与项目计划有出入，但项目组可以通过调整和调动组内资源追上进度

多云：与项目计划出入较大，需要外部资源支持

暴雨：SOS，需要尽快决策是否提前中止项目

有的同学可能会问，之前我们用过红黄绿的三档状态，大老师你为啥要加一档，你不是一贯崇尚简洁么？

因为不够细，可能会产生误解。

报告是给“老板”看的，就需要从老板的角度去考虑。

我们假设用的是绿红黄三个档位来标识项目状态。如果你是老板看到项目状态全是“绿”的，会怎么想？一定是你们项目目标设置的太保守了，没有挑战呀。

随即会很自然的认为黄色是正常情况：这样项目目标有挑战，你们赶赶进度都能回来。

这样，就很容易忽略那种确实需要外部支持才能够把项目拉回正轨的情况，错失了调整机会。只有爆红灯了才觉得“悔之晚矣”.....

所以实操中我们使用4档状态比3档效果更好：

如果项目整体状态是1,2档，后面的内容就可以不仔细看了，项目组自己可以搞定；

状态是3档则需要仔细了解一下项目组的困境，给予额外的支持；

4档则需要迅速决策，及时止损。

以上项目状态图标就是我说的结论先行。其他内容（包括后续几页）都是佐证结论的。

首先第一个论据是项目时间线。举例如下：

对于项目管理来说，时间是唯一没有任何争议的度量角度，所以“项目时间线”是最容易让阅读者掌握项目整体进展的方法：需要与整体状态自洽不冲突。

如果与相关里程碑的日期有较大偏差，项目整体状态仍是“大太阳”，则需要项目经理做出解释并给出能够支持这个结论的事实依据。

所以这部分也是给项目经理一个对于项目整体进展评价的思考机会。

这页剩下的没什么特别：

本周做了哪些事情，取得了哪些成果，下周规划。

简明扼要。

以上就是第二页的内容。对于项目细节不需要了解那么多的人，看完这页是不是就可以“走”了？

第3~5页：项目关键指标情况

对照第一页的项目目标，将当前项目关键指标的达成情况做一个展示。

通常这部分是最容易跑偏的，做成花里胡哨，长篇累牍。所以我们实操中的要求是：只放与项目关键指标情况的内容，其他数据仅作为辅助说明使用。严格限制篇幅。

毫无疑问，这部份也应该是整个周报里面比较耗时的。建议项目经理去思考如何更高效的获得相关的指标数据，最好能做到可以实时获取。否则写周报的时间可能大多花在“等”数据上，你的周报30分钟肯定搞不定啦！

第6页：项目风险及应对

常规操作，也不做过多解释。填表格。

项目有风险，需要及时应对。所以，这一页也必不可少。

特别是项目是“多云”状态，应对措施需要借助外部资源的时候，这一页需要把相关诉求讲清楚，才能更及时的获得项目组外的助力。

行笔至此，史上最简洁项目周报完成！鼓掌撒花。

如前文所述，虽然周报上报信息是单向的。但周报阅读者，特别是Owner或者Sponsor都可以针对周报内容和项目组有互动。

比如对于项目整体状态的判断是否同意，对于项目风险及其应对方式是否认同，从而给项目组一些指导建议甚至给予项目更多的资源倾斜，让项目实施更加“顺滑”。

最后，想说的是：项目是一种聚焦目标的组织形式，目标感需要贯穿项目的整个生命周期。所以，即便是写周报都应该紧盯项目目标，传递真正有用的信息，周报亦不能“范围蔓延”。

我给大家提供的项目周报模板远远谈不上完美，希望抛砖引玉，大家都去想想如何让项目经理们把时间花到真正有用的地方去，而不是在papaer work上耗费精力。

今天周末，项目经理们，你的项目周报写完了么？Happy Weekend！