写周报之前需要认清

周报意味着总结

• 写清楚过去一周做了什么，尤其是
• 过去一周，在核心业务上做了什么
• 周报的重点在于描述，描述你深处的环境，而描述需要：思考

周报意味着思考

• 你需要有一个完整的思考：业务，技术，团队
• 时间线上的思考：过去，现在，将来
• 问题线上的思考：问题，快速/简单解决，完整解决
• 优先级上的思考：有限的资源如何应对无限的事情？时间差

你的思考范围

• 业务的思考

公司/团队整体面对的业务：应该是什么样的，现在是什么样的，差距在哪里

合作方/业务方/使用方是什么样的，他们提出了什么样的要求，面临什么样的问题

竞对是什么样的，与我们相比有什么优势，如何快速追平

兄弟部门是什么样的，他们到了什么阶段，遇到了什么问题

• 技术的思考

我们的系统是否具有充分的健壮性和扩展性

瓶颈在哪里，性能瓶颈还是功能瓶颈

排查问题是否足够迅速，覆盖场景是否足够全面

系统的各个层面的治理是否充分

• 团队的思考

团队现在遇到的问题或者困境是什么，如何解决

团队是否积极向上，是否具备自我良性循环的机制？

• 完整的思考

考虑方方面面

a. 覆盖：业务，技术，团队

b. 覆盖：正向，逆向

不光要考虑做一件事情会怎么样，还要考虑不做会怎么样

c. 覆盖：公司决策，团队分解，个人执行

开始写周报

汇报周期

• 一般来说是一周，不然为什么要叫周报？

现阶段工作的核心指标

• 紧跟OKR，是OKR的延伸或者分解

是否可以超出OKR的范围？

当然可以！但是，这往往说明OKR需要调整，最终要回归到OKR

• 跟OKR一样，核心工作是大事，不是鸡毛蒜皮的小事
• 用数字衡量！有时间约束！有场景范围！缺一不可

核心指标本周完成进度

• 在核心指标上的进度
• 有里程碑，有衡量方法之后的进度，不能是拍脑袋。拍脑袋的进度写在“本周完成工作事项”里面
• 谨慎填写，可以没有核心进度

本周完成工作事项

• 可以写的随意一些，日常的工作都可以写上来
• 大部分时间，主要在写这个

下周工作计划

• 很重要，这才是周报的精髓：自我的承诺
• 核心进度没有，惭愧不惭愧？本周完成工作没几项，丢人不丢人？请务必向前看，做好下周的计划
• 自我承诺要尽量完成，所以不要承诺很简单的事情，因为没有意义；也不要承诺和很难的事情，因为完成不了

遇到的问题

• 个人遇到的问题，困惑；如果有解决方案，那么同时也列出来；如果没有，也不妨写出来
• 团队遇到的问题，同样的，最好有解决方案

几个关键字

完整

• 完整性是一切的基石
• 换一种说法是：保持开阔的视野和头脑

量化

• 分解和量化，是必要的步骤

思考

• 思考是一切的核心
• 行动步骤是思考出来的，不是别人指挥和命令的

承诺

• 计划和承诺是实现的方式

写日报的意义

对自己的意义

• 梳理思路：对自己思路的整理
• 总结思考：对当前工作的总结，同时也是反思“如果再做一次能不能做的更好”
• 未来预期：对未来（接下来一天或多天）工作的展望

预期很重要

没有预期很容易造成节奏缓慢，目的性不强等问题

在开始工作之前有合理的预期，是达成目标的开始

对组织的意义

• 成员间相互了解
• 相互了解对方做的事
• 相互监督和帮助

开始写日报

思考并开始

• 给自己15分钟时间

5分钟思考，10分钟撰写并修改

不要花费过长的时间，日报15分钟足够了

日报毕竟只是一个简洁的总结，如果针对某一个事项或者问题有深入的分析，可以单独wiki中填写，在日报中填写链接

• 量化思考

少用/不用形容词

多用数字，从数字中明确结果和期望

当前的工作

• 手上有几件事，整体期望是啥样

分清楚主次

哪些事情是主要工作，哪些工作是临时工作和突发工作（比如排查问题）

哪些事情投入了多少精力，占用了多少时间

• 每件事情的进度，以及是否满足期望

计划当日完成哪些工作，什么进度

实际当日完成哪些工作，什么进度

如果进度提前了，为什么

如果进度落后了，为什么，怎么解决（能不能追回来）

• 事情的结果和分析

结果是什么样？

结果之后是否要需要关心？（功能上线就结束了么？）

如何分析结果之后的效果？（线上的使用率，正确率，等等）

遗留工作/接下来的计划

• 和以上很像

几件事情，分别是什么，整体期望是啥样

接下来一个/几个工作日的期望是啥样，如何量化说明

遇到的问题

把自己遇到的问题分享出来，当然也不是什么问题都需要分享

a. 有普遍性的，别人也会出现的问题

b. 比较严重的问题，有一定深度的问题，可以采用贴wiki的方式

c. 没有解决/不好解决/解决成本比较高的问题

几个关键字

预期

首先得有“这个事情应该什么样”

在这个基础上谈“怎么做”

最后总结“做到了什么程度”

量化

尝试量化工作，并用量化的结果衡量进度

避免宽泛的形容词：完成一小部分，完成大部分，基本完成

避免无意义的量化：（第一天）完成90%，（第二天）实现95%

主次

弄清楚哪些是主要工作（需要结合OKR，当前业务重点，等等），哪些是临时/突然工作

分析清楚两者的占比

是否真的在主要工作上投入了恰当的精力？

是否在非主要工作上过多的投入了精力？

思考

发现问题，解决问题

不能麻木的看见问题也放着不管

有问题，思考，寻找解决方案，然后解决

明确目标

明确要解决的业务或者技术问题

• 设立标准：怎么样算解决？当前的状况是什么样？理想的状况是什么样？
• 明确问题：当前有什么问题，带来了什么问题

粗估成本收益

• 投入的成本：包括设计，实现，验证，切换
• 获得的收益：显性的，包括功能，效率，故障率，等等；隐形的，包括结构，使用，扩展，等等

对业务和系统有深刻的认知

• 千万注意：什么样是一整套方案，什么样是打补丁方案。前者从根本上解决问题，后者解决表面问题
• 在整体的基础上，确定影响范围

敢想：做正确的事

• 清楚认知当前的本质问题，然后做正确的解决方案
• 针对本质的问题和解决方案，不妥协。考虑拆分项目，分批次实现等方案，来降低复杂度
• 针对细节的问题和解决方案，可以适当妥协。但不能危害整体的目标

确定整体范围

评估影响范围：外部

• 影响哪些对外接口
• 影响哪些外部业务和系统
• 影响哪些外部使用方

评估影响范围：内部

• 影响哪些内部核心数据结构
• 影响哪些内部底层模型
• 影响哪些内部业务和系统
• 影响哪些内部使用方

制定整体计划

整体要有期望

• 有deadline要求：根据deadline倒推计划
• 无deadline要求：推算一个相关靠谱紧凑的计划

成功标准明确

• 明确定义成功和失败标准，能清楚的衡量这些标准，能简单的获得基准数据

广度优先 vs. 深度优先

• 广度代表了对整体的把握，广度意味着优先全面思考问题，不遗漏主要的影响范围
• 深度代表了对细节的把握，深度意味着在某个相对独立的领域的认真细致的梳理，不遗漏任何细节
• 先广度 -> 后深度
• 广度往往不能并行，深度往往可以并行

穷尽多种方案

• 方案往往不止一种，把不同思路的可对比的方案罗列出来，进行比较
• 比较的点要能逻辑说明好坏，或者数字比较优劣
• 讨论并选择最合适的方案，然后执行

制定执行计划

能并行执行

• 合理拆分，接口清晰，标准明确
• 此时再细致考虑资源问题，根据并行度投入资源

设计切换和回滚方案

实现排查问题的机制和工具

设立测试基准和新老逻辑/数字比对基准

• 测试是标准化的，测试组件/case也是标准化的

常见策略

拆分

• 多条业务线，一条一条拆分进行
• 几个步骤，拆分进行；未进行的步骤使用原有方案或者毛招方案

比对

• 同时运行新老两个流程，比对结果是否正确
• 当结果完全一致或者正确率达到一个阈值时，进行切换

适配

• 对使用方来说，接口保持不变，因此没有任何变化
• 把新实现的逻辑适配到老的接口上