随着 OKR 在国外英特尔、谷歌等公司，国内字节跳动、华为等公司的成功实践，越来越多的企业意识到 OKR 对于组织发展的重要性，开始纷纷引入 OKR 。引入 OKR 企业文化，一款强大的 OKR 工具必不可少，CODING OKR 可以为企业提供丰富的过程实践和协作提醒，提升员工敬业度并促进公司运营和产研运维一体化的成功。下文将以 CODING OKR 为例，阐述大多数企业在推行 OKR 时会遇到的问题以及一些思考。
OKR 的定位首先是沟通工具，是一个 plan-do-check-action 的循环，OKR 要求的是如何更有效率地完成一个有野心的项目，所以众多项目管理工具厂商喜欢设计 OKR 。而 KPI 的本质是一种管理工具，它主要是从结果上来考察绩效，不关注过程，一切用指标来说话。KPI 强调的是如何保质保量的完成预定目标。
KPI 理论上是必须严格按照 SMART 标准制订的，是否达到甚至达到比例多少（小于 100% 还是大于 100%）都是要能测量的。而 OKR 目标的设定是要有野心、有一些挑战、有些让你不舒服的。一般来说，“最佳”的 OKR 分数在 0.6-0.7 之间，如果某人拿到了 1 分，那么他的 OKR 制订的目标显然是野心不够的；但是低分数的人也不应该受到指责，而是应通过工作上的数据，帮助他改进下一季度的 OKR 目标。CODING OKR 也即将引入评分系统和评分报告，帮助企业更快速地建立反馈机制，帮助员工更好的树立责任感。
CODING OKR 可以关联事项，通过关联事项的完成情况去标示进度并且动态记录，从而去评估 OKR 的最初制定和最终完成是否有强关联导向，方便负责人随时灵活调整。
基于 OKR 是挑战舒适区的定义来看，承诺目标可以理解为 KPI，超常规设定目标可以理解为 OKR 。OKR 是路径，KPI 是结果，不变的是结果，变的是路径，KPI 有非常强的结果导向，而 OKR 需要多个迭代循序渐进，这跟 CODING 提倡的敏捷 Scrum 的中心思想特别类似，都需要敏捷执行，快速拥抱变化 。
OKR 本身并不复杂，相较于其他传统的管理工具来说，简单易操作，越是简单的事物越有生命力。一般来说，OKR 在企业中运行一个周期后（一般情况下一个周期是指一个季度，但也可执行双月 OKR，例如飞书），团队就可以掌握 OKR 制定、对齐、跟踪、复盘等各个环节的操作流程和方法。经过两三个周期后，团队可以根据自身工作的实际情况，对 OKR 的操作进行一些优化，使其与实际的工作场景和业务流程更匹配。四个周期以后，团队将会更多地思考如何用 OKR 促进自我成长和实现组织目标。所有这些变化，带给团队最大的收获就是感受到希望，并推动他们更加主动地促进这些积极的变化。
OKR 和其他管理方式一样，都是为了帮助组织提高资源利用的效率，资源的数量和质量对利用企业资源的目的并不会产生直接影响。我们运用 OKR，应当追求突出 OKR 聚焦战略、注重逻辑、对齐协同、自下而上、公开透明、积极反馈的特征，只有在实践中不断强化这些特征，OKR 才能发挥其应有的作用。
OKR 不是员工评估的代名词，也不是为了考核员工，而是时刻提醒每个人的核心任务是什么，OKR 与公司的目标以及每个员工如何为这些目标做出贡献有关，绩效评估（完全是评估员工在固定期间的绩效）应独立于其 OKR 。当企业开始接触 OKR 时，管理者们普遍表达了这样的担忧：既然 OKR 和考核无关，团队在实践时会有积极性吗？这种担忧其实反映出三个问题： 一、 管理层对 OKR 的认识不够； 二、 管理层不确定自己有没有能力和心力促进员工的内在能动性，担心没有外在诱惑会导致工作推进乏力，这其实也是管理中的一种懦弱表现； 三、 管理层本身在执行 OKR 的中后期不够坚持和坚定，OKR 倡导对齐协同，实现组织的合力。
过度激励个人，会弱化协同的力量，导致内部竞争，破坏公开透明的场域。所以相对于个人的激励，我们更应该重视对于团队的激励。
制定 OKR 的议程一般为：
团队需要建立 OKR 推行、跟进、复盘、评分四大阶段中的三种文化氛围，即：尊重、反馈与认可。
最初尝试推行 OKR 的半年到一年中，需要鼓励员工自主设定个人目标，同时联动团队目标的衡量结果，自主执行和反馈，团队管理层不做强干预，定期观察和协助即可。虽然很多 OKR 文章告诉我们“团队目标大于个人目标”的理念，但是建议前期执行时反其道而行之，鼓励员工按照 OKR 的 SMART 原则，先思考自己的价值和能力边界，再探索关联和延展性，同时告诉员工，我们都实现了大约 60% 的目标，这才表明我们的目标是正确的，不妨大胆一点。
我理解很多 HR 或者 Team Leader 在推行 OKR 初期时，会担心团队成员的接受程度。其实员工都希望能够被“授权”和“激励”，而不是管理者对他们的工作指指点点，员工也希望向管理者表达自己的观点，而不是努力工作一年，最后才知道经理对其工作表现的褒贬；员工也渴望定期将自己的目标、计划与他人分享，同时也希望了解同事工作的进展情况。
公开、透明的 CODING OKR 可以帮助激发他们从不同角度思考问题：这些是我 /你 /我们应该关注的正确的事情吗？如果我 /你 /我们完成了它们，会被视为一个巨大的成功吗？你对我 /我们如何才能做得更好有什么建议吗？
反馈可以是非常有建设性的，但前提是它必须足够具体。在发展型组织中，反馈通常是由人力资源部门主导和安排的。在更为成熟的组织中，反馈多是不受约束、实时和多方向的，并且多是不分时间、不分地点在组织内以开放式谈话的方式进行的。对企业来说，员工与上级之间实现双向交流的机会是非常宝贵的，比如员工可以询问管理者需要自己做什么才能取得成功，同时管理者也可以知道自己需要从员工那里获得什么帮助。类比 CODING 中敏捷 Scrum 文化的导入，其中有五大活动分别为：
参照上图，在 OKR 推行循环周期里，也可以召开一些 OKR 启动会、撰写评估会、季度执行复盘会、优秀 OKR 执行表彰会等等。CODING 中的 Scrum 是敏捷的一种，CODING OKR 也是敏捷的一种，实施主要看人，强调是自组织、自驱动的，只有不断地在实际应用中仔细体会，才能感受到企业和组织随着敏捷或 OKR 的循序渐进变得越来越高效和具有创新力。
是的，公开透明是 OKR 的重要原则之一。例如字节跳动有个非常有特色的管理理念，叫做「基于上下文，而不是基于控制」（ Context,not Control ），即希望员工能在完整的信息基础上判断事情该怎么做，鼓励员工主动思考，而非强调流程、上下级与命令。在字节跳动，大家的 OKR 是公开的，即使是入职第一天的员工，也可以直接看到张一鸣的 OKR 。
“比如我们有非常多的跨部门合作，‘开会坐在一起却不认识对方是谁’的情况很常见，我经常的做法是，拿起手机，打开他的头像，看一眼他的 OKR，半分钟就知道他的主要职责和工作重点是什么了。”因此在字节跳动，OKR 不仅是自上而下拆解的结果，除了与上司有关，还与本部门同事、跨部门同事有关，是高效沟通与协同的基础。使用 CODING OKR 即可根据组织架构设定不同角色的查看权限，当然，我们鼓励全员公开可见。
如果你的 KR 超过 2 行，它很可能是不清晰的。
如果你的 KR 描述中充斥着内部团队术语，例如“发布 CI 元数据串联和门禁能力”，那它们通常就不是好的 KR 。真正重要的不是“发布”这个动作，而是其所造成的影响（ Impact ）究竟是什么。为什么“元数据串联”很重要？更好的表述是这样的：“发布 CI 元数据串联和门禁能力，提升研发规范，增加数据流视角”或者简单写成：“提升研发规范，增加数据流视角”。
KR 请使用真实日期，如果所有 KR 的截止日期都是季度最后一天，你制定的计划就很可能是有问题的。
确保你的 KR 是可度量的，KR 必须是每个季度末可以进行客观评分的。“提升注册用户数”不是一个好的 KR，“在 6 月 1 日前提升日均注册用户数 25%”则是一个好的 KR 。
确保度量指标是清晰的，如果你说“一百万用户”，你要指明这指的是全时段用户，还是只是 7 天活跃用户。
必须是产出导向，而非动作导向。如果你的 KR 包含有像“咨询”、“帮助”、“分析”、“参与”这样的词汇，那么它描述的实际上是动作而非结果。与之相反，如果描述的是这些动作对最终用户所带来的影响，例如：“在 6 月 7 日前更新自动化用例库，实现快速、精准的自动化执行”，就是一个合格的 KR，而 “更新自动化用例库” 则不是。
必须能自证其是否已完成，这个证据是可轻易获取的和可信赖的。例如证据可以是 CODING 上的 Wiki 、网盘或是具体的一个项目动态，比如项目内的变更列表、文档链接、已发布的质量报告等。
程序员的工作怎么量化？ Bug 数？代码行？版本数？但这些指标都是不可行的。或是比较团队间的代码行、Bug 数、版本数或者分享次数？这些其实都不行。前瞻性的工作谁愿意做，有风险的工作谁愿意做？例如引入 ElasticSearch 理论上可以提升搜索性能，但可能在引入的这一年反而会带来很多问题，而能带来多少收益还不确定，这时该如何制定 OKR ？
假设技术总监接收到 CEO 指定的大的战略目标是“用户量增长 20%”这样的指标，他就应该根据团队的资源优势去制定本部门成员可以理解且着手的 KR，例如：
影响用户增长量的技术指标有“安装包大小”、“App 启动时间”、“App 崩溃率”、“App 耗电情况”等等，假设经过分析后技术团队认为目前安装包太大，并且 App 启动时间较长，那么可以将这两项相关的优化作为技术团队的 OKR：App 安装包从 20M 缩减到 8M 、App 启动时间从 2s 优化到 500ms，而这两个 KR，业务负责人几乎是不可能提出来的。
影响用户良性反馈的原因之一是发版节奏过慢，过慢则是因为版本多而测试环境不足，测试环境不足是因为机器不够，那么可以得出一个目标：解决测试环境不足导致版本等待的问题。分解出来的 KR 可以是“添加 4 台测试环境机器”（是的，虽然是一件很简单的事情，但这也可以作为 KR ），也可以是“引入 Docker，支持一台机器搭建 20 套环境”（这个 KR 比较符合技术人员的理解）。
影响用户分析和增长的原因之一是内部协作和需求流转过慢，产研侧往往需要一周的时间才能把用户故事拆分至对应版本，拆分和评估用户故事的过程很可能是通过一些易用性不强的工具来记录和提醒。而重新评估一个研发项目管理工具就尤为重要。CODING 是一个包含代码管理、项目协同、测试管理、持续集成、制品库、持续部署、团队知识库等工具的一站式软件研发管理平台，在项目协同环节有迭代管理、需求细分和灵活跟进的看板视图，很适合创新型企业灵活的管理需求和快速迭代。
通过以上方式进行思考和分解，最终技术团队要做的事情如下：
OKR 是敏捷的战略业务管理以及项目规划和组合管理的一个重要框架，希望通过 CODING 能帮助团队将 OKR 的启动、撰写、跟进、复盘四个阶段执行得愈加完善，随时记录团队成员周期内完成的挑战及为团队做出的贡献。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.