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

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

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

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

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

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

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

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

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

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

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

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

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