复盘
目前工作中的一个现状是，在季度开始的时候需要自己思考方向、规划工作；可能还需要自己说服上级和产品业务侧争取资源。本篇文章是对近期一次季度规划及评审经历的一次复盘和反思。感觉暂时拿捏不准应该起一个什么样的题目，暂定为无题。
我是如何做的
大概过程分为3部分：
- 撰写评审文档
- 讨论、评审文档
- 总结、对齐结论
撰写评审文档
评审文档的撰写，我大概花费了2~3个工作日。自己目前的体会是，评审文档的撰写是一个不断细化的encoder-decoder过程。另外2-3个工作日有点略慢，这部分应尽量总结出自己的模板化文档，后续不断打磨，加快自己撰写相关文档的速度，提升文档的质量。
O-KR-KA
O1: 提升线上AAA功能BBB指标CCC个点
KR1: 模型层面，在模型自测集上DDD指标达到EEE
KA1: 开发模型层面的badcase分析工具
KA2: 撰写模型层面的badcase分析文档
KA3: 模型优化方案实现
KA4: 模型优化方案变体1
KA5: 模型优化方案变体2
KA6: 模型优化方案变体3
KR2: 集成库层面，在集成测试集上，AAA功能BBB指标达到CCC个点
KA1: 开发集成库层面badcase分析工具
KA2: 撰写集成库层面的badcase分析文档
KA3: 调研、设计优化方案，输出优化方案文档
KA4: 评审优化方案文档
注1： 集成库层面的badcase分析报告为该文档子部分，一同评审
注2：模型层面badcase分析报告为该文档子部分，一同评审
KR3: 完成AAA功能的优化上线
KA1: (锁定版）单元测试
KA2: (锁定版)集成测试
KA3: (锁定版)上线
O2: 提供FFF能力
KR1: 开发功能原型，具备FFF能力
KA1: 和产品同时确认功能概念范围和产品形态
KA2: 撰写功能服务接口openapi、测试方案、测试集需求文档（包含标定文档）
KA3: 评审上述文档
KA4: 获取数据，提交标定任务
KA5: 测试方案代码构建
KA6: 伪服务开发并期待开发侧同时联调伪服务
KA7: 调研、并输出功能FF方案
KA8: 评审该方案
KA9: 方案实现
KR2: 在自测集上，GGG服务能HHH指标 达到III
KA1: 方案变体1
KA2: 方案变体2
KR3: 完成FFF能力的上线
KA1: (锁定版)单元测试
KA2: (锁定版)集成测试
KA3: (锁定版)上线
这里面抽象出来的两个O模板，基本上代表了目前的（业务侧）算法工程师两个很典型的任务：（1）优化线上服务；（2）开发新算法功能；相比较于优化线上服务，一般开发新功能会对指标的要求更加宽容一点，毕竟是第一个版本，另外会增加额外的产品形态、接口设计、指标对齐等任务。
在撰写OKR的时候，我采用的是自顶向下的方式，即先设想O, 再设想KR, 最后细化KA。
任务网络图与计划
任务网络图是在KA的基础上，增加时间这一因素，并且还会考虑到任务的并行性。一般对于可支配资源较多的人员，可以做到任务并行的点会比较多。但是对于大部分普通的软件（算法）工程师通常绘出的任务网络图会是一个如下图的两条平行的串行任务时间线，分别对应上述的两个O。
这里在O1和O2的时间线也是有一定的并行成分在的，这是因为以下一些经验：
- 如果O1和O2也完全串行，最终的结果大概率是季度结束的时候O1完成度较高，但O2的完成度“细碎”
- 在实现O的过程中，建议将两个O的分析、沟通事项前置，分析和沟通可以发现问题，这样可以及早的调整O
- 资源的充分利用和避开稀缺资源高峰，虽然对于单兵作战的软件（算法）工程师可支配的人员只有自己，但其实还有隐含的数据和gpu显卡这两个长周期资源，数据的周期可以拉长一点，GPU训练模型的时间也有较大的空隙可以完成其他任务，再有 应尽量将两个O的显卡利用放在季度的第二个月，否则会出现第三个月大家为了赶进度，资源抢占现象严重。
| 第一周 | 第二周 | |
|---|---|---|
| N月事项 | a. 开发集成库层面badcase分析工具 b. 撰写集成库层面badcase分析报告 |
a.开发模型层面badcase分析工具 b.撰写模型层面badcase分析报告 c.调研、设计方案，输出优化方案报告 d.评审优化方案报告 |
| 第一周 | 第二周 | 第三周 | 第四周 | 第五周 | |
|---|---|---|---|---|---|
| N+1月事项 | a. 和产品同事确认功能的定义范围、形态 b.撰写功能服务接口openapi、测试方案、测试集需求文档（包含标定文档） c.评述上述文档 d.获取数据，提交标定任务 e.测试方案代码实现 f.伪服务开发并期待开发侧同事联调伪服务 |
a.调研并输出功能方案 b.方案原型实现 |
a.变体1 b.方案评审 |
a.变体2 b.方案原型实现 |
a.变体3 b.变体1 |
| 第一周 | 第二周 | 第三周 | 第四周 | |
|---|---|---|---|---|
| N+2月事项 | a.变体2 b.单元测试 c.集成测试 d.上线 |
a.单元测试 b.集成测试 c.上线 |
a.反馈 | a.机动 && 可以考虑下一季度的事项 |
资源需求 && 风险项
OKR制定完后，应该筛选出需要其他同事配合的点，比如后端资源，数据资源这个需要提前让业务中间人知晓，并和相关人员提前沟通，纳入他们的本季度OKR里面。
资源需求
- 相关同事配合讨论、评审文档
- N月18日，需要评审规划文档，相关人员：技术Leader, 产品经理B, 我，同事A
- N月26日，需要评审优化方案报告，相关人员：技术Leader，我，同事A
- N月29日，需要评审功能的定义范围和产品形态，相关人员：产品经理B，我，邀请参与：技术Leader，同事A
- N+1月1日，需要评审服务接口openapi、测试方案、测试集需求文档（包含标定文档）
- N+1月6日，需要评审O2优化方案，相关人员：技术Leader，产品经理B, 我，同事A
- 后端同事资源
- N+1月2日，需要集成伪服务，相关人员：后端同事
- N+1月2日，需要拉取数据，相关人员：后端同事
- N+2月6日，需要上线O1优化版本，相关人员：后端同事
- N+2月13日，需要上线O2优化版本，相关人员：后端同事
- 数据相关
- N月26日~N+1月9日，O1数据清洗
- N+1月2日~N+1月18日，O2数据标定
- GPU卡
- N+1月9日~N+2月6日，gpu卡集中使用（不要集中在N+2月的用卡高峰）
风险项
- 指标定的比较有挑战性
其他
应该也要罗列一些其他的一些事项，例如O的必要性、业务背景、需求来源、业务价值等。
讨论、评审文档
上述只能说完成了”革命事业“的一半，甚至可能还不到，实际的讨论会涉及的因素会更加复杂。线下讨论会之前，建议先进行如下预热工作：
- 将相关 人员拉入一个讨论群
- 将评审文档发至群内，由本人讲明线下会议的讨论点和议题，大家可以依据讨论点和议题进行有针对性的审阅
- 相关人员如果有任何问题建议先在线评论，方便本人提前在线下会议前提前思考准备，或者直接在线回复。
经实际实践下来，在线下讨论会的时候会遇到如下问题：
- 角度不同，产品的角度和技术的角度事实上不一定是一致的，例如产品认为如果该功能的准确率只能达到60%，就很难对用户交待，就会认为收益不大；但技术认为应该提前准备，循序渐进，价值前景大（可能也和技术人员会有一定的心思：认为这样的任务会更有技术积累）。
- 技术方案 && 可行性，有参会者会在会上询问是否已有技术方案以及预期指标是否能够达到，对于该点技术方案是否应该在第一次项目启动会上进行，以及如何回答预期指标是否能够达到这样的问题，还需要再思考。
撰写评审纪要、结论
会议应该速战速决，在半个小时到 1个小时内解决，且应该要有会议纪要以及结论文档发出。我目前自己总结的会议纪要模板如下：后续可继续打磨。
| 主题 | 2024年Q3-OKR-Plan讨论/评审 |
|---|---|
| 相关人员 | 我（主持人）、Leader L、技术骨干D、产品经理M、业务接口人H |
| 相关文档 | xxx |
| 会议纪要 | 我： 介绍本次会议的议题： (1)O1和O2的产品业务价值，需要和业务侧同事达成一致 (2) O1和O2需要写于相关人员O, 达成目标对齐； (3)资源需求中的后端开发同事相关资源，需要业务接口人提前沟通，协调 (4)O1和O2的权重计划是7：3 介绍本次会议的目的： (1)完成后后续周会按照文档中的计划，对齐进度，沟通问题 其他人： |
| 会议结论 | (1)调整O2的目标为XXX指标，而非XXX能力，原因是XXX能力在整体的用户分布中经讨论是小概率事件 (2)调整O1:O2的权重为3：7 |
反思
自己的一些疑惑：可行性分析和技术方案是否需要在这里做出来，目前的理解是如果该需求是从技术侧发出也即技术说服产品则需要做，因为根据此次经历，在这种情况下说服别人认同自己想做的事情，需要证明，否则别人很难发表（支持）意见。那这可能就需要把自己私下付出更多的精力，在季度开始之前即把技术方案和可行性分析做好。反之，则需要产品侧给出产品业务价值的证明。
感觉自己沟通甚至谈判这块是下一步需要加强的一个点。
