最近是Q4刚开始，又到了制定季度OKR的时候了，我发现很多技术开发小伙伴依然不知道怎么制定自己的OKR。要么就写“持续做每个迭代”，要么就“持续维护某个系统”，要么就是“积极响应产品需求”。

前提：这里假定你对OKR已经有了一定的认识，假定你已对OKR制定要遵循的通用原则SMART比较熟悉。

技术OKR为什么难写？

好多技术主要是跟迭代做需求。这时候想的是我只要按时把需求完成就可以了。但日常迭代本来就是你应该做的事情，你应该去想你如何才能更好地更快地完成你的工作。

由于技术OKR不像业务OKR有明确的业务指标且最终是指向用户价值的，久而久之技术OKR有时候就会沦为形式。这些形式化的OKR其实没有任何的指导意义，反而浪费大家时间，这样的OKR要趁早删掉。

全程“虚词”，没法衡量

技术OKR和通用OKR一样不能只有虚词，要有可衡量的指标或者数据。全程“持续、大力、全力、快速”的话，复盘的时候你自己都不知道怎么衡量“全力”是使出了多少力气。

这些虚词可以有，但也要附带可衡量的内容。要么是上线个什么功能，要么是把目前存在的什么问题给解决掉，要么把某某的xx率提高到多少？要么是持续做某件事几次。总之得有个实际的内容可以衡量。

OKR制定原则

设置O的原则

O要制定的有挑战性，要有远方的感觉。

设置KR的原则

• 能量化尽量量化 ：就是要有数字指标。

• 不能量化要细化：不能量化的你就写工作内容本身。

• 不能细化要流程化：有的工作内容是重复性很高的工作。程序员有时候会时不时的接到一些类似取数据的工作，那么这些工作怎么体现在OKR里呢？这时候你可以把这个取数工作给流程化、文档化，这样就能体现出你的价值了。

• 明确完成时间：最好明确完成时间，这样你的关键结果更具体。比如：4月5日前完成xxx项目上线。

OKR参与原则

本着自下而上和自上而下相结合的原则。有的公司的OKR完全是自上而下对齐结果，这样就会让一线员工没有参与感，也不鼓舞人心。

所以自下而上的OKR比例至少占到40%，先让每个员工自己去盘点当下遇到的问题，我们要去往哪里，然后把这些写入自己的OKR。

这样做的另外一个好处就是，往往一些细节上的问题只有操作者自己才知道的，通过这样的方式让整个企业运作在Deep Dive的层面。

日常类重复工作怎么写入OKR

这个是很多人经常提到的问题，所以这里专门说一下。对于日常持续重复的类似取数等工作，自己可以写把脚本文档化之类的，总之就是让重复的事情变得尽量不去重复，甚至提供一个通用的能力让这些事情花的时间更少，对于这类日常工作可以考虑遵循DRY原则来制定你的OKR。

可以参考的几个OKR制定方向

下面给大家提供一些不同方向的技术OKR思路供参考：

• 功能交付类。比如上线某个项目或某个功能等；
• 性能优化类。比如当下你的项目某些API性能较差，可以写降低某某API响应时间从300ms到200ms等；
• 代码优化类。比如完成xxx模块的重构，抽离xxx组件供所有模块使用等；
• 代码质量类。比如线上bug小于1个等；
• 迭代交付类。比如迭代交付平均周期小于8天；
• 技术文化类。比如至少输出5篇技术博客，至少做3次技术分享；
• 指标完善类。比如增加bug来源字段到bug统计中等；
• 组件开发类。比如至少20个业务方接入；
• 团队管理类。比如至少3人轮岗，每周与一位技术小伙伴对话，培养1-2位自驱闭环的产研负责人等；
• 规范标准类。比如制定CodeReview规范。

总之你就记住一个原则：当下存在哪些问题，你要去往哪里。这样你就不愁你的OKR写不出来了。

作者丨贺卓凡

来源丨公众号：ImportSource（ID：importsource）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

直播预告丨B站大数据体系建设的技术选型与落地实践

dbaplus社群携手哔哩哔哩四位大数据专家，围绕“B站大数据体系建设的技术选型与落地实践”这一主题开展线上直播分享，针对离线平台、流式数据集成、OLAP、数据治理等议题进行深入探讨，给大家提供企业级大数据体系建设管理经验参考。

• 观看方式：线上直播间/dbaplus社群视频号
• 直播日期：2023年10月13日（周五）
• 直播时间：14:30-17:30
• 直播地址：B站大数据体系建设的技术选型与落地实践

最新活动丨XCOPS智能运维管理人年会

报名地址：2023 XCOPS智能运维管理人年会-广州站 �-�百格活动