如何写周报

写周报之前需要认清

周报意味着总结
  • 写清楚过去一周做了什么,尤其是
  • 过去一周,在核心业务上做了什么
  • 周报的重点在于描述,描述你深处的环境,而描述需要:思考
周报意味着思考
  • 你需要有一个完整的思考:业务,技术,团队
  • 时间线上的思考:过去,现在,将来
  • 问题线上的思考:问题,快速/简单解决,完整解决
  • 优先级上的思考:有限的资源如何应对无限的事情?时间差
你的思考范围
  • 业务的思考

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

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

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

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

  • 技术的思考

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

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

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

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

  • 团队的思考

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

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

  • 完整的思考

考虑方方面面

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也是标准化的

常见策略

拆分
  • 多条业务线,一条一条拆分进行
  • 几个步骤,拆分进行;未进行的步骤使用原有方案或者毛招方案
比对
  • 同时运行新老两个流程,比对结果是否正确
  • 当结果完全一致或者正确率达到一个阈值时,进行切换
适配
  • 对使用方来说,接口保持不变,因此没有任何变化
  • 把新实现的逻辑适配到老的接口上