技术开发人员如何制定自己的OKR

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

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

技术OKR为什么难写？

好多技术主要是跟迭代做需求。这时候想的是我只要按时把需求完成就可以了。但日常迭代本来就是你应该做的事情，你应该去想你如何才能更好地更快地完成你的工作。由于技术OKR不像业务OKR有明确的业务指标且最终是指向用户价值的，久而久之技术OKR有时候就会沦为形式。这些形式化的OKR其实没有任何的指导意义，反而浪费大家时间，这样的OKR要趁早删掉。

全程“虚词”，没法衡量

技术OKR和通用OKR一样不能只有虚词，要有可衡量的指标或者数据。全程“持续、大力、全力、快速”的话，复盘的时候你自己都不知道怎么衡量“全力”是使出了多少力气。这些虚词可以有，但也要附带可衡量的内容。要么是上线个什么功能，要么是把目前存在的什么问题给解决掉，要么把某某的xx率提高到多少？要么是持续做某件事几次。总之得有个实际的内容可以衡量。

OKR制定原则

• 设置O的原则

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

• 设置KR的原则

1. 能量化尽量量化 ：就是要有数字指标。
2. 不能量化要细化：不能量化的你就写工作内容本身。
3. 不能细化要流程化：有的工作内容是重复性很高的工作。程序员有时候会时不时的接到一些类似取数据的工作，那么这些工作怎么体现在OKR里呢？这时候你可以把这个取数工作给流程化、文档化，这样就能体现出你的价值了。
4. 明确完成时间。最好明确完成时间，这样你的关键结果更具体。比如：4月5日前完成xxx项目上线。

OKR参与原则

本着自下而上和自上而下相结合的原则。有的公司的OKR完全是自上而下对齐结果，这样就会让一线员工没有参与感，也不鼓舞人心。所以自下而上的OKR比例至少占到40%。先让每个员工自己去盘点当下遇到的问题，我们要去往哪里，然后把这些写入自己的OKR。这样做的另外一个好处就是，往往一些细节上的问题只有操作者自己才知道的，通过这样的方式让整个企业运作在Deep Dive的层面。

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

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

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

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

1、功能交付类。比如上线某个项目或某个功能等；

2、性能优化类。比如当下你的项目某些API性能较差，可以写降低某某API响应时间从300ms到200ms等；

3、代码优化类。比如完成xxx模块的重构，抽离xxx组件供所有模块使用等；

4、代码质量类。比如线上bug小于1个等；

5、迭代交付类。比如迭代交付平均周期小于8天；

6、技术文化类。比如至少输出5篇技术博客，至少做3次技术分享；

7、指标完善类。比如增加bug来源字段到bug统计中等；

8、组件开发类。比如至少20个业务方接入；

9、团队管理类。比如至少3人轮岗，每周与一位技术小伙伴对话，培养1-2位自驱闭环的产研负责人等；

10、规范标准类。比如制定CodeReview规范。

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