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

贺卓凡 2023-10-07 10:28:49

最近是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
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告