有些的好一些，记了个流水账，大概是这样：

周一做了 XXX
周二完成了 XXX
周三对接了 XXX
……

再好一些的，对这些流水账做了一个分类：

上周完成：
重点事项：XXX
非重点事项：XXX
临时工作：XXX
下周计划：
重点事项：XXX
非重点事项：XXX

再好一些的，就会加一些可衡量的内容，或者一些量化的数据。 如此种种 还有更好一些的，都写成小作文了。 然而不管上面的这些如何，大家「苦周报久矣」。是什么让我们觉得周报是种负担，为什么我们不想写周报？

我们可以先看一下周报到底是什么？

1. 周报是什么

从公司管理的角度来看 周报是公司流程化管理的一部分，是正式沟通地一种手段或方式，其目的是为了更好的向下管理和向上反馈。 作为管理者可以通过周报了解一线的情况，如项目的进展，工作的动向；作为普通员工可以通过周报系统性地表述一线的状况。

从个人成长的角度来看 周报是个人反思成长的载体，是自我管理的一种方式，其核心逻辑是：在过去一周你的时间花在了哪里，解决了什么问题，过程中有什么思考，个人有哪些成长。

2. 周报怎么写

2.1 明确受众和主题

写周报和写其它文档一样，需要明确要写的东西是给谁看的，会有一个目标或目的，大的思考结构逻辑如下：

对象：这个周报是写给谁看的，受众是谁？

主题：你想在周报里面主要写什么内容

目标/目的：为什么要写这份周报 / 希望周报受众了解什么 / 希望他/他们给予你什么帮助

在搞清楚以上这些问题后，基本上要写什么就确定了，目标确认，接下来就是要怎样达到这个目标。 针对不同的受众，需要有不同的逻辑。在职场中，看我们周报的人无外乎上级、团队/下属和自己，下面我们就这三个维度看看一份合格的周报应该怎么写。

2.2 写给上级的周报

写给上级的周报主要是向上汇报，向上管理，其主要作用是让你的上级清楚知道你/你的团队在这周主要做了什么，其关键有 4 点：

1. 有成果 一周你的团队肯定有产出，挑重点或上级关注的点呈现，不要太细节，大的事项就可以了；
2. 有数据 对于成果的展现尽可能做到具体而有数据，可衡量或可量化，以确保上级能精确了解状态和相信结果
3. 有思考 作为管理者，思考团队的问题是你的本职工作，在周报中要特别体现这点；
4. 有格局 有格局是指不要把自己的眼光只停留在自己的一亩三分地，至少尝试站在你的上级的角度来思考问题。

作为一个技术管理者，一个合格的周报大概如下：

1. 核心事项同步，你的上级当前的 OKR/KPI 关联的事项，你作为一个信息源提供信息，因为你的上级需要通过你拿到一线的情况，对于核心事项中需要上级协助的点也一并体现出来，加粗，需要上级协助的点要明确具体，大概标准是上级看到了就知道自己要做什么才能帮助到你；
2. 业务里程碑，记录在业务事项推进过程中的阶段性成果，以业务价值为主，对于有明显价值或者有明显变化的予以体现；
3. 研发流程、效率和质量，记录研发管理过程中出现的流程变更，组织结构的变动，效率的改进、质量的优化和线上的问题等等，如研发需求延期，线上事故复盘总结，人员变更（离职，转岗，入职，并说明情况）。对于一些问题或较大一些的事项，建议以 STAR 原则表述，Situation（情景）、Task（任务）、Action（行动）和Result（结果），同时在后面附加相关文档，如果问题需要上级来协调，在这部分内容中用加粗等较明显的方式标出；
4. 思考和总结, 这里主要是体现你的思考和总结，可能你会想我哪有那么多总结和思考，这是一个问题，但是是可以解决的问题。如果在一周中你有持续思考团队的价值，团队的问题，并把这些思考和问题记录下来，在周报中一定可以呈现；
5. 人才培养 这一项根据实际情况来，如果有长期的人才培养专项，可以单列体现，如果只是间歇性的，考虑整合到第 3 项。

在写周报之前，需要阶段性和上级沟通确认他在关注哪些事情。因为随着时间的推移，关注点是会变化的，此时我们需要调整我们周报的内容。

2.3. 写给团队的周报

写给团队的周报主要是从你的角度来看整个团队做了什么？哪些做得好的？哪些做得不好？当前团队状态是怎样的？思考如何改进？ 并把你所看到的内容表述给团队成员看，让整个团队了解我们的方向和进展。

写给团队的周报的逻辑大概如下：

1. 工作内容和业务价值的关联和进展 我们在做什么，做的东西的进度如何，做的东西服务于哪个业务的哪个目标，将会产生哪些业务价值；
2. 问题和卡点 过程中我们有遇到哪些问题或卡点，解决了没有？解决了，是如何解决的？没有解决，需要哪些努力或协助，现在进展如何。如一些人员的变动，组织流程的变更，公司级的变更周知，大家捅的娄子，线上的事故，需求延期等等；
3. 里程碑 过程中我们有达成哪些激动人心的小目标，如某大功能上线，某业务增长超出预期，某基建阶段性产出等；
4. 时间维度的交付逻辑 落到细节上，从时间维度看，我们这周在哪些业务线交付了哪些内容，下周要交付哪些内容，哪些内容会跨更长的周期；
5. 状态 整体团队、业务等状态如何，团队成长如何；
6. 思考和总结 过程中我们有哪些思考和总结。

团队的周报更多的是从团队管理者的角度来看问题，抓大放小，持续思考。

2.4. 写给自己的周报

其实我平时很少单独给自己写周报，一些要写给自己看的东西基本都在写给团队的周报和写给上级的周报中，但是如果只是写给自己看的话，也是可以单独拎出来的。

写给自己的周报，其目的是强迫自己思考，如果不思考，你的周报将会流水账式的，每周例行公式的写本周总结，下周计划。 写给自己的周报其核心是自我反省和个人成长，反思一周工作中的表现和思考，一周中自己的学习和成长。

个人周报大概逻辑如下：

1. 本周重要产出 每个人的工作都是为企业创造价值，我们在对本周进行总结时，需要把与业务价值相关联的事项拎出来，关注重要的事项，最多列三项，并且 review 这些事项的进展，问题以及下周我们要解决的点；
2. 下周重点事项 列出下周要做的重点事项，有些是从本周的重点事项中引申出来的，还有一些是新增的；
3. 问题和思考 列出工作中的问题和卡点，把问题反馈出来，并把思考总结的方案也写出来；
4. 总结和成长 对个人一周内的成长做一些总结，是否比上周更好一些了？在哪些方面有所进步，技术基础技能，软技能，知识性的？技能性的？这里是关系个人成长关键的一节。

于公问自己：规划的三件事情有没有做好？三件事是怎么做的？成果怎么样？下周应该怎么去规划？

于私问自己：相比上周你有进步吗？有投入时间提升自己吗？投入了多少时间？有没有系统性地去规划自己的成长？

3. 写周报中的术

3.1 如何提高写周报的效率

1. 养成写工作经验笔记的习惯；
2. 养成系统性地回复问题，并在临时文档中存下来的习惯；
3. 养成写日报的习惯。

3.2 STAR 原则

STAR 原则即情景(Situation)、任务/目标(Task/Target)、行动(Action)和结果(Result) 四个英文单词的首字母组合，STAR 原则是结构化面试当中非常重要的一个理论，常用于面试过程中涉及实质性内容的谈话程序。

我们写周报和面试时类似，都有给一个不熟悉某块东西的人讲清楚一个事情的逻辑，在这个场景下 STAR 原则会让你事半功倍，其结构化表述如下：

情景(Situation)：事情的背景是什么，在什么情况下发生的； 任务/目标(Task/Target)：明确要做什么，目标在哪； 行动(Action)：针对以上的情景和目标，做详细分析的，你采用了什么行动方式； 结果(Result)：有什么可衡量的结果。

如果要表述的是事故或问题类的，可以把原因分析和后续规避方案等加上。

4. 其它注意事项

• 尽量不要有数据类的报表，数据类的报表通过数据系统来解决；
• 细节不要写，要有重点，有主次；
• 流水账不要写，要有结构化的表述；
• 请求帮忙和协助最好是符合 SMART 原则，协助的点要明确具体，大概标准是上级看到了就知道自己要做什么；
• 抓大放小，放开平时讨论的细节，更多地对大目标大问题进行讨论，思考目标达成，业务价值等重要的问题；
• 要有观点，要有重点，要有想法，要有业务，要有数据。

5. 结语

写作并不难，重要的是思考，对于周报也一样。

如果你不能对自己想要在周报中表达的内容和观点有清晰、准确的认知，那么你将根本无法写好周报。

如果你在带一个团队，如果你想在团队中执行周报的逻辑，那么先思考一下你的目的是什么？ 是想让同学们养成工作计划/思考/总结的习惯？还是想让他们快速成长？还是想拿到一线的情况？ 对于技术管理者来说，周报是一个管理动作，而我们在做管理的时候不要做无效的管理动作，思考一下本质的逻辑。

写了这么多，斟酌反复，还是觉得有些想说的没有说出来，就这样吧。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com