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

技术开发人员如何制定自己的OKR
2022年05月13日 08:48 CSDN程序人生

作者 | 贺卓凡

出品 | ImportSource(ID:importsource)

最近是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写不出来了。

财经自媒体联盟更多自媒体作者

新浪首页 语音播报 相关新闻 返回顶部