《 “[read]这就是OKR-outline” 》 有 2 条评论

1. 技术开发人员如何制定自己的OKR
   https://mp.weixin.qq.com/s/KIqFe2SGtJM58CyPZPRTPw
   `
   最近是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写不出来了。
   `

   回复

2. 互联网公司管理神话的破灭
   https://mp.weixin.qq.com/s/r_tGDAomd0hr09OvYUBF2A
   `
   价值观，OKR，花名，弹性工作制等……
   在过去的 20 年里，互联网行业为企业管理界贡献了许多花活儿，这其中有些是中国互联网原创的，也有不少是从硅谷学习而来属于全球互联网行业通行。

   当互联网行业处于黄金上升期的时候，几乎每家成功的互联网

   都要或多或少的对外输出一下自己的企业管理方法论，有的是通过创始人演讲，有的是通过出书，也有类似腾讯和阿里巴巴这样的，直接以被投企业家俱乐部的形式来影响自己投资的创业企业。

   然而，随着互联网黄金增长期的结束，全球互联网普及红利（对国内来说是人口红利）的消失，我们惊讶发现从 2020 年开始，许多过去互联网行业高举高打的管理概念正在失效……或者说，它也许从来就没有有效过。

   站在这个时间点去回顾互联网公司曾经沉淀下的那些方法论，我们会发现无论是阿里巴巴、腾讯、字节跳动，还是 Google、Amazon 和 Netflix。他们的企业管理方法论可能都存在错误归因——低估自己所乘着的时代东风，高估了自身的努力（管理行为）。

   因为在企业管理界，有一些明显的错误答案，剩下的全都是“正确答案”。

   这是我看最近一本书《大厂人才》的感受，这本书由穆胜咨询合伙人娄珺（Samantha）出品。书中详细横向评测了字节跳动、腾讯、阿里巴巴、美团、华为等多个大厂的管理体系，并间或的对这些不同模式与传统企业管理制度做了比较。

   原书作者在结论上总结的比较委婉，但我结合自身的大厂工作的体感以及对本书阅读的感受，可以直说：**所有互联网大厂的管理创新，可能都是画蛇添足。**

   以全书反思性最为明显的 OKR 为例，**OKR 的“始作俑者”Google 在 2022 年启用了新的管理工具 GRAD（Googler Reviews and Devlopment, 谷歌员工评价和发展），GRAD 是一种更为绩效（偏向 KPI）而非目标导向的管理工具。**

   根据书中的描述，Google 使用 GRAD 取代 OKR 的主要原因可能有两个，第一个是在过去很长一段时间里，由于 OKR 的反 KPI 属性，导致日常业务中大量的经常性工作无法被考核，OKR 只能作为该公司更大的管理机制 Preformance Management 一环使用，并且只能覆盖 40% 的工作。第二个，则是 OKR 复杂的流程和评价机制本身让员工不堪重负，在许多时候，反复的对齐、拉通、复盘比简单的定期考核一个业务指标是否达成更让人痛苦。

   OKR 在国内的忠实粉丝字节跳动也在 2023 年调整了它们的考核方式与考核节奏，比如从双月回顾改为季度回顾。

   在 OKR 以外，一些曾经在发展早期宣誓要“去 KPI 化”的企业也在最近重新回到 KPI 考核的道路，比如百度和小米。

   阿里巴巴的花名机制，也在实践中与原本的设立初衷背道而驰——原本是为了淡化职级加强扁平化管理，结果真的搞成了“江湖味儿”，公司内“门派林立”。腾讯的“赛马机制”和“自下而上”也一度使得公司缺乏 Big Picture，漏球了信息流和短视频这两个非常重要的业务。

   **从社会学的角度讲，现代企业的本质是个体分工协作的产物。它的作用是将一群人以特定的社会关系结合在一起，实现一个人无法实现的伟业。这意味着巴别塔可以有很多种建成方式，只要没有上帝来捣乱，任何一种方式都可以通天，而“上帝来捣乱”的方法，就是让每个人都觉得自己的方法是对的。**

   从 2023 年全球互联网行业的大裁员和惨状来看，互联网的企业管理方法论创新，别说可能不适用于其他企业，甚至可能连互联网行业自己都不合适。比如，早期的字节跳动被称为“App 工厂”，上一个火一个。从字节跳动在 2017 年全面启用飞书之后，就再也没有上线过任何一个现象级产品。腾讯方法论无法让腾讯复制微信，字节方法论也无法让字节复制抖音。

   这意味着无论是飞书提出的“先进团队先用飞书”还是阿里的“每年将会向社会输出 1000 名在阿里工作 10 年以上的人才”，对于社会上的其他企业来说都是一个陷阱。

   **如果你相信这些从互联网公司来的工具、人才、方法论能够帮助你原本陷入困境的企业重振旗鼓，那你就要倒大霉咯。**

   这个观点倒不是书中提出的，而是我之前从字节的方法论观察到的。众所周知，虽然字节其实并不怎么输出企业管理方法论（比起阿里巴巴），但飞书却从诞生之出将“方法论”与产品捆绑进行销售。飞书在所有的媒体和互联网公司都备受好评，甚至连百度和阿里的一些团队也私下使用飞书进行一些边缘项目的协作，确实配得上“先进团队先用飞书”。

   但是，这个世界本身就是由落后构成的。

   **企业管理界有一些明显的错误答案，剩下的全都是“正确答案”。在吸收别人的经验时，错误的总比正确的更重要。只要你的企业还没黄，就不要轻易效仿别人。**
   `

   回复