以有限应对无限-互联网产品研发过程中的 5 种等级

一个互联网产品的生命周期大概可以分为需求阶段，研发阶段，运营阶段。 在需求阶段，通常我们会有需求优先级； 在研发阶段，会有转测 BUG 等级，BUG 的严重程度； 在运营阶段，会有线上 BUG 等级，线上事故等级。

为什么会有等级或者优先级？其背后的根本原因是资源是有限的。 在有限的资源内，如何更好地完成需求，修复线上问题，处理线上事故是我们在研发管理过程中要反复面对的问题。 而这个要反复面对的问题，业内通用的解决方式是定优先级，也就是我们常说的 P0，P1……

1. 需求优先级

需求优先级，指产品需求的优先级，哪些需求先做，哪些需求后做，哪些需求不做，其关注的是业务价值或者要解决问题的价值。

需求优先级一般有 3 个，P0，P1，P2 在资源有限的前提下，P0 是必须要做的，P1 是在 P0 做完后有空余人力可以去做，P2 现阶段基本可以不做。

当业务方问为啥我们：“这个需求没有咋没有排上，我都提了这么久了，你们是怎么评估优先级的？” 我们需要有一些相对客观的逻辑或方法来回复业务方。

需求的评估可以分两步：

第一步：从需求的角度来看，任何一个需求一定服务于某个战略 / 某个目标 / 某个场景，需要根据其服务的目标来做第一次的优先级评估。

  • 如果是服务于战略，根据战略的级别和影响范围来评估，比如是公司级的战略项目优先级肯定要高一些；
  • 如果是服务于某个目标，这里的目标可能是合同或者营收，根据合同的金额，合同的客户以及营收的大小来评估，比如一个合同金额为 500 万和一个合同金额为 5 万的需求，会有比较明显的优先级区别；
  • 如果是服务于某个场景，那这个场景一定有对应的目标人群，根据目标人群的特征、数量和其影响范围来评估，比如有些需求在业务关键链路上，优化可以影响的用户量比较多，又或者某些影响核心链路可用性的技术建设需求，当核心链路不稳时，所有用户都会受影响，此时需要评估为最高优先级；

在以上评估的基础上，还需要基于具体的实现做第二步的评估：

  • 参考需求实现的成本和难度，对于开发成本低，周期短，但价值高的需求，需要给予更高一些的优先级，其实就是看一下性价比；
  • 对于存在关联关系的需求，可能适当地调整优先级，比如某个需求 A 优先级高，另一个需求 B 优先级低，但是在做需求 A 的时候，再加点点人力就可以顺便把需求 B 给做了，此时可以适当调整，这里主要考虑的是事情的完整性，基于减少了认知成本和沟通成本的出发点；
  • 对于存在依赖关系的需求，可以适当调整优先级，比如在开发某个产品时，可以先把 MVP 版本的需求先做了，实现主体流程先跑通，或者某些需求在前后端上有依赖，可能需要后端先行等等。

以上只是我们评估的逻辑，换成更高大上的说法有如下一些方法：

  • 卡诺模型（ KANO 模型）：必备需求 > 期望需求 > 超出预期需求 > 无差异需求
  • 维格斯法：分为四个纬度进行评估：收益(Benefit)、损害(Penalty)、成本(Cost)、风险(Risk)。收益和损害是从客户角度出发，而成本和风险则从实现角度出发。
  • 波士顿矩阵：由用户价值维度和公司价值两个维度将需求分成了 4 个象限：明星需求，问题需求，金牛需求，瘦狗需求。
  • RICE 方法：包含 覆盖率，影响，信心和努力 4 个部分。对要素进行排名并根据这 4 个因素计算得分，以确定优先级。
  • WSJF 优先级：加权最短作业优先，项目成本 = 用户商业价值 + 时间成本 + 降低风险 / 新机会
  • 工作量和影响矩阵：也称为「价值与复杂性」矩阵，将工作量和影响组合分为 4 个象限
  • MoSCoW 方法：必须具备 > 应该具有 > 可能具有 > 非必要
  • 艾森豪威尔矩阵（时间管理四象限）：马上要做(重要紧急) > 计划要做(重要不紧急) > 备选(紧急不重要) > 不需要做(不重要不紧急)

2. 转测 BUG 等级

转测 BUG 等级关注的是对测试执行的影响，这里之所以叫转测 BUG，是为了和线上运营时的线上 BUG 做区别。

转测 BUG 在 CMMI5 标准中可以分为 3~5 个等级，在实际研发过程中，我们常常将其分为 4 个等级，这里的等级属于处理的优先级，即对我们处理的时间和先后顺序有要求，如下：

等级 说明
P0 马上解决，表示 BUG 需要马上解决，否则就无法达到预期，测试执行完全没法操作
P1 急需解决，表示 BUG 的修复很紧要，关系到系统主要功能模块是否正常，严重影响测试执行
P2 高度重视，表示 BUG 有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现，对测试执行有影响，但是可接受
P3 正常处理，表示 BUG 按个人计划解决，不影响需求的实现，在需求上线发布前需要确认解决或确认可以不予解决，对测试执行影响较小

以上是 BUG 的处理优先级，但是我们在确认 BUG 时还有一个维度是严重程序，如下：

严重性 说明
致命（非常严重） 在流程、数据或安全方面存在重大问题，导致软件不具可用性，或核心功能项无法使用，如系统崩溃、无法启动、实现和需求严重不符等导致测试无法进行
严重 由于设计的缺陷，导致软件使用中存在较明显的障碍，或者局部功能错误，但可以采取其他变通的操作实现，如功能未实现、功能错误，通讯错误等
一般 由于编码不够完善，使某个小功能无法使用，或者对特殊的操作与要求不能支持
提示 存在某些细微的缺陷，但不影响程序正常应用或该功能在下次升级版本中可以实现

对于转测 BUG 的优先级和严重性，有如下一些注意事项：

  1. 优先级和严重性并不总是一对应。有时候严重性高的 BUG，优先级不一定高，甚至不需要处理，而一些严重性低的 BUG 却需要及时处理，具有较高的优先级。如界面单词拼写错误，但是如果是系统名称或公司名称的拼写错误，则必须尽快修正，因为这关系到系统和公司的市场形象；
  2. 修复 BUG 不是一件纯技术问题，有时需要综合考虑项目周期、质量风险和修复成本等问题。例如如果某个严重的 BUG 只在非常极端的条件下产生，则可能没有必要马上解决，又或者修复一个 BUG 需要重新修改系统的整体架构，可能会产生更多潜在的 BUG，而且产品由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，需要通盘考虑后，以确认是否需要修正。

3. 产品模块等级

在讲线上 BUG 等级前我们需要先讲一下产品模块或产品链路等级。因为不管是线上 BUG 还是线上事故，其优先级的判定都依赖于产品模块的等级，在产品模块等级的基础上叠加影响范围 / 影响时长之类的因素才能构成线上 BUG 等级和线上事故等级。一般我们将产品模块等级分为以下 3 个等级：

等级 说明
P0 核心功能流程，是一个产品安身立命的根本，最最基础的功能，如电商场景下的浏览商品、商品详情、支付购买等
P1 非核心流程，却是重要的业务模块，如电商的优惠劵兑换、商详页里面的用户评论，在系统遇到问题时，可以降级的部分
P2 非核心流程，当不可用时，用户可以接受晚点再来，如一些运营活动，个人信息的展示等

基于产品模块等级我们讲一下在运营阶段常见的线上 BUG 等级和线上事故等级。

4. 线上 BUG 等级

线上 BUG 是指在线上环境中发现的 BUG，是相对于转测 BUG 来说，其关注点是对用户使用的影响，其优先级的评定也是根据用户影响范围及程度来决定的。 在实际执行中我们通常会根据客服的反馈和 BUG 所在的业务的重要程度来决定处理优先处理。

等级 说明 反应时长 处理周期
P0 因程序导致的 P0 级业务流程不可用，影响所有用户或大面积用户，或对用户/公司造成了实际经济损失，闪退 5分钟 1 小时内
P1 因程序导致的 P0 级业务流程不可用，但只影响部分用户正常操作，或 P1 级业务流程不可用，但影响所有用户 / 大面积用户 10 分钟 24 小时内
P2 因程序导致的 P1 级非核心业务流程异常，若持续故障将可能大面积影响用户体验 1 小时 1 周内
P3 因程序导致的 P1 / P2 非核心业务流程异常，影响少量用户使用体验 2小时内 两到三周内

5. 线上故障等级

线上 BUG 专指由于程序的问题导致的线上问题，而线上故障是对所有对线上业务产生了一定范围影响的线上问题。

线上故障和线上 BUG 不相同，线上 BUG 不一定会产生线上故障，而线上故障也不一定是由线上 BUG 造成的。如 DDoS 攻击，机房断网，域名到期等等都有可能产生线上故障。

线上故障等级关注的是对业务的影响范围和持续时长，实际应用中我们用可用性 SLA(Service-level Agreement)来描述和约束线上故障。其优先级如下：

等级 说明 反应时长 处理周期
P0 P0 级业务流程不可用，影响所有用户或大面积用户，或对用户/公司造成了实际经济损失 5分钟 1 小时内
P1 P0 级业务流程不可用，但只影响部分用户正常操作，或 P1 级业务流程不可用，但影响所有用户 / 大面积用户 10 分钟 12 小时内
P2 P1 级非核心业务流程异常，若持续故障将可能大面积影响用户体验 30 分钟 1 周内
P3 P1 / P2 非核心业务流程异常，影响少量用户使用体验 1 小时内 两三周内

6. 后记

优先级是我们以有限应对无限的策略，在没有办法的情况下可以这样用，但是如果人力充足是否就不需要优先级了？

答案是：依旧需要。

对于优先级更深层次的思考是 ROI，如何让研发投入产生更大的价值，是我们要不停思考的问题。

 

晋级 7 问 – 技术晋级答辩中常见问题解析

在一些大一些且相对正规的互联网企业，每年都会有一到两次的晋级答辩，在晋级答辩的过程中，台上要晋级的同学努力准备好 PPT ，希望在有限的时间内能说明通道评委能相信自己所说，能认可自己是一个和晋级标准能力对应的同学。而台下的评委，则从 PPT 中，从提问过程中确认台上的同学是否符合自己认知范围内某个级别的标准，给出相对客观公平的分数，最后得出一个晋级与否的结果。当然「无利不起早」，一般过了级的同学在加薪以及组织范围内的重要程度会有所提升和偏重。

但是今天我们不聊如何晋级答辩，我们来看看作为一个评委来如何提问。

有人说：「世界上最难的事有两件，一是把自己的思想装进别人的脑袋，二是把别人的钱装进自己的口袋。」

作为一个评委如何提出问题，找到对方想要告诉你的观点/论点以及相应的论据，并评估其准确性，并规避掉大多数的陷阱，这是一个批判思考的过程。

那么我们如何能系统的提出问题，了解到自己想要的信息，或达到自己的目的？

当别人想把思考装进我们的脑袋时，他一般会提出一个问题，并引出一个论点，针对这个论点提供一些论据来佐证，以让你相信他。

首先我们对对方表述的内容做一个结构化的梳理，大概的结构如下：

问题：
结论：
理由：

结论是晋级者在晋级述职时在 PPT 或表述时要传达给评委的多个观点，是晋级者想让评委相信的内容

评委心声：他想让我相信什么 / 他想表述的观点是什么

结论就是一个个观点，这些观点需要其他观点和证据来进行支撑。没有证据支撑的断言，不能称为结论，而只能称为纯观点。

评委心声：你为什么会有这个结论，这个结论是从哪里来的，有没有什么可量化的数据支撑

一般来说，评委大多数都会基于晋级者客观的表现和自我的认知来打分，而晋级者的水平参差不齐，为了不错过那些确实有能力，但是在表达方面有所不足的同学，需要提问得到自己想要的信息。

在晋级同学讲完后，评委一般会基于 PPT 内容来提问，以确认其表述的准确性或希望晋级者能有更好一些的回答表现来证明有自己的做事逻辑和方法论，以确认有类似的问题也能解决，是能力达到了的表现。

晋级答辩对于晋级者和评委来说都是一个考验，晋级者尽可能多的把自己的能力展现出来，而评委尽可能公平公正的评判。 晋级对于评委来说，是工作，也是考试，整个过程相当于连续 N 场的考试，考核评委看人识人的水平，而在这个过程中，评委可能通过倾听晋级者的讲述得到一个初步的评价，同时通过提问来佐证自己的判断，以下是关于评委提问的常见逻辑，其主要出发点并不是为难晋级者，而是想通过提问找到能佐证晋级者能力的项，以做到相对公平。

1. 问定义

在晋级者讲述时经常会有一些模糊指向的词，而这些词在晋级者平常工作中经常遇到，以为评委知道，然而评委第一次接触并不了解。特别是一些表义比较泛的词语，在不同的语境都有着不同的含义，比如“架构”这个词，不同的人在不同的时期，在不同的场景对它的定义就不同。所以评委会在晋级者表述观点中有一些模糊性指向的词语的时候，或者存在意思不明确 / 有歧义的情况时候，做出提问。

比如在我们晋级中常常会说：做了服务性能优化，接口速度快了很多 这里评委可能会问：

  • 这里的服务是指什么服务？
  • 这里的性能是指什么？
  • 优化是做了什么操作
  • 快了很多是多少？从多少提升到多少？如何量化的？

服务和性能等词语都是比较泛的，比如性能可能是查询的性能或者写入的性能，并且不同的性能其对应的优化方案完全不一样，有些是技术点的优化，有些可能是整个架构的调整。

晋级提示: 精准用词，减少歧义

2. 问过程

一个事情只有有了好的过程，才会有好的结果，并且没有好的过程的好结果是不可重复的。 对过程提问主要是想了解并确认晋升的同学在项目中的扮演的角色，具体的工作，发挥的作用，以及对项目的掌握度。 特别是一些在 PPT 或者讲述的时间有些信息没有讲清楚的同学，评委此时需要通过提问的方式来把这个项目信息补充完整。常常通过以下的维度来提出问题：

2.1 背景原因

  • 为什么要做这个方案 / 系统？背后的思考是什么
  • 这个项目要解决的核心痛点是什么？
  • 为什么是你来做这个？
  • 你在项目中的角色是什么？
  • 在项目执行过程你个人的价值如何体现的？

2.2 技术细节

  • 某个技术点是如何实现的，讲一下细节？
  • XXX 模块为什么要这样设计？有没有更好的方案？
  • 这里为什么要用 XXX 缓存？为什么要使用这样的缓存设计？可以不用缓存吗？
  • 业务领域为什么要这样划分？当时的思考是怎样的？
  • 这里为什么要用 XXX 协议？如果换成 YYY 协议会怎样？

2.3 方案风险

  • 做方案时有没有参考业界的方案，是哪些方案，方案的优劣是怎样的？
  • 为何选择当前这个方案？
  • 在评估方案时，考量的维度有哪些，为什么是这些维度？各维度的权重如何？
  • 对当前有进行全面的风险分析吗？分析结果是什么？
  • 如果分析出来的风险发生，如何应对？

2.4 数据指标

  • 为什么要用 XXX 指标？背后的逻辑是什么？
  • 这个项目产生的可量化的效果数据是怎样的？当初的预期是怎样的？达成情况如何？
  • 项目开始时定的目标是 3 倍，为什么这里是 3 倍而不是 5 倍 10 倍，有什么依据？
  • 这些数据是如何得出来的？
  • 为什么这里的提升是 30%？能不能到 50% ？如果要到 50% ，需要做什么？为什么当时不做？

晋级提示: 科学决策方案、可量化数据、能重复过程

3. 问难度

不同的级别对于难度的要求不一样，难度这个项能在一定程度上区分是否满足某个级别的要求。 在答辩过程中评委可能会针对相应的级别提出一些有难度的问题，这里的难度不局限于某个技术难点，可能是某些行业内最新的动态，或者某个经典策略/方案/架构，或者最新的架构/语言/范式等等，比如：

  1. 项目中你觉得最难的点是什么？ 为什么这个才是最难的？
  2. 可以谈一下你对现在业界比较流行的 XXX 的看法吗？
  3. 你对业界现在最热的 XXX 怎么看？为什么没有用到你这个项目里面来？

晋级提示: 有难度才有区分度

4. 问大局观

在高阶一些的级别中，对于事情的大局观是一个比较看重的项。 这里的大局观是指从宏观角度看问题，分析问题，从更大的整体来解决问题，实现技术价值的全局最大化，而不仅仅是局限于自己的一亩三分地。常见问题如下：

  • 你所在项目的上下游是哪些？整个链路是如何联接的？
  • 在这个项目上你有影响产品经理什么吗？如果有的话，是哪些？如何影响的？
  • 你对项目最大的影响/改变是什么？当时是如何思考的？

晋级提示: 大局观决定了高度，尽在掌握

5. 问方法论

思考和总结是高阶一些的级别需要特别体现的内容，一般会落地成方法论，表示这个项目我这次能做成，下一次还能做成，有自己做事的节奏和方法。比如你讲某个地方的优化使用了缓存，此时需要对于缓存使用有自己的方法论，对于缓存其适用场景，优劣势，原理都尽在掌握，下次遇到类似的问题还可以解决，而且可能还是不同的方案，但是做事的方法和逻辑一样。

  • 从这个项目你学到了什么？你最大的收获是什么？
  • 如果还有 XXX 项目，你会怎样做？
  • 你做 XXX 决定的逻辑框架是什么？
  • XXX 背后的思考是什么？

晋级提示: 持续的成功才是能力

6. 问业务价值

技术最终还是服务于业务产生价值，而在晋级中如何把在做的东西的业务价值体现出来，也是要着重思考的。 如果你在讲述过程中没有提起或者提得不那么明显或清晰，那么评委可能会就此提问，可能的问题如下：

  • 这个项目的用户是哪些人？他为用户带来了什么？
  • 如何衡量你这个项目的价值？项目价值衡量的维度是否合理？
  • 从公司层面（部门/某个大一些的组织）看，你认为这个项目贡献情况如何？
  • 你当前组织的业务目标是什么？你这个项目是如何服务于这个业务目标的？如果没有这个项目业务目标会怎么样？

晋级提示: 将技术与业务价值和公司（部门）目标关联上

7. 问学习成长

  • 你在 PPT 上有讲架构能力有所欠缺，你打算如何提升这方面的能力？
  • 你有提到持续学习，你将如何持续学习，学习什么，有什么计划，预计会有什么样的收益？
  • 想象一下，一年后的你是怎样的？三年呢？五年呢？

晋级提示: 学习能力是必备能力之一

8. 技术晋级常见问题

以下是两个常见的问题集

8.1 性能优化

做了 XXX 优化，性能提升了很多

  • 为什么要做这个优化？做这个优化的出发点是什么？
  • 这里的性能是指什么？
  • 提升了很多是多少？从多少提升到多少？如何量化的？
  • 性能提升后对用户有什么影响？有什么业务价值？
  • 在系统中还有类似的性能问题吗？有没有系统思考过产生这个问题的原因？
  • 从研发流程或研发制度上有没有可以优化的点来规避这些性能问题？

8.2 信息系统

做了一个系统

  • 为什么要做这个系统？做这个系统的初心是什么？
  • 能解决什么问题，能带来什么效果
  • 能给公司带来什么价值？如何衡量这个价值？
  • 带来的这些价值如何服务于公司级的业务目标？
  • 系统的架构是怎样的？
  • 系统设计的时候有没有参考业界的方案？
  • 当时做方案选型的时候是如何评估的，重点是考察了哪些点？为什么要考察这些点，当时的思考是什么？
  • 你在这个系统过程中扮演的是什么角色？
  • 系统的优势和不足在哪里？
  • 这个系统下一步如何发展

9. 后记

晋级对于我们来说意味着「升职加薪」，意味着我们的能力、知识、技能等得到某种官方的认可。 同时也意味着将来要承担更多的责任，也会被更多的期待。

晋级并不是结束，而是下一个开始。

最后，今天是五一劳动节，祝大家节日快乐。

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

聊聊周报-团队管理和自我管理的利器

在职场多年，但凡大一点点的公司，周报/日报大多成了标配，而各家公司对于周报的要求也不相同，大家写周报的方式也不相同，有些是为了应付一下，如有这样写的： 本周周报：完成了上周工作，和领导交待的事项，下周继续；

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

周一做了 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