关于okr:OKR-八问-关于-OKR-的常见问题与思考

写在后面

随着 OKR 在国外英特尔、谷歌等公司，国内字节跳动、华为等公司的成功实践，越来越多的企业意识到 OKR 对于组织倒退的重要性，开始纷纷引入 OKR。引入 OKR 企业文化，一款弱小的 OKR 工具必不可少，CODING OKR 能够为企业提供丰盛的过程实际和合作揭示，晋升员工敬业度并促成公司经营和产研运维一体化的胜利 。下文将以 CODING OKR 为例，论述大多数企业在推广 OKR 时会遇到的问题以及一些思考。

网络上常见的 OKR 定义

1、OKR 与 KPI 的区别

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 的中心思想特地相似，都须要麻利执行，疾速拥抱变动。

2、OKR 推广多久能力感触到成果？

OKR 自身并不简单，相较于其余传统的管理工具来说，简略易操作，越是简略的事物越有生命力。一般来说，OKR 在企业中运行一个周期后（个别状况下一个周期是指一个季度，但也可执行双月 OKR，例如飞书），团队就能够把握 OKR 制订、对齐、跟踪、复盘等各个环节的操作流程和办法。通过两三个周期后，团队能够依据本身工作的理论状况，对 OKR 的操作进行一些优化，使其与理论的工作场景和业务流程更匹配。四个周期当前，团队将会更多地思考如何用 OKR 促成自我成长和实现组织指标。所有这些变动，带给团队最大的播种就是感触到心愿，并推动他们更加被动地促成这些踊跃的变动。

OKR 和其余治理形式一样，都是为了帮忙组织进步资源利用的效率，资源的数量和品质对利用企业资源的目标并不会产生间接影响。 咱们使用 OKR，该当谋求突出 OKR 聚焦策略、重视逻辑、对齐协同、自下而上、公开通明、踊跃反馈的特色 ，只有在实践中一直强化这些特色，OKR 能力施展其应有的作用。

3、OKR 的最终后果是否应该与绩效或奖金挂钩？

OKR 不是员工评估的代名词，也不是为了考核员工，而是时刻揭示每个人的外围工作是什么，OKR 与公司的指标以及每个员工如何为这些指标做出奉献无关，绩效评估（齐全是评估员工在固定期间的绩效）应独立于其 OKR。当企业开始接触 OKR 时，管理者们广泛表白了这样的担心：既然 OKR 和考核无关，团队在实际时会有积极性吗？这种担心其实反映出三个问题：

一、管理层对 OKR 的意识不够；
二、管理层不确定本人有没有能力和心力促成员工的外在能动性，放心没有外在引诱会导致工作推动乏力，这其实也是治理中的一种柔弱体现；
三、管理层自身在执行 OKR 的中后期不够保持和动摇，OKR 提倡对齐协同，实现组织的合力。

适度激励集体，会弱化协同的力量，导致外部竞争，毁坏公开通明的场域。所以绝对于集体的激励，咱们更应该器重对于团队的激励。

4、怎么发展 OKR 制订探讨会议？

制订 OKR 的议程个别为：

1. CEO（或 Team Leader）论述愿景和大指标，以及介绍以后行业变动、竞争环境和趋势判断等内容；
2. COO（或小组组长）兼主持人会把初拟的业务指标和事件画到白板上，或用投影仪展示；
3. 就筹备的重要业务指标和事件展开讨论；
4. 依据本身的职责定位，每个人把本人认为重要的 O 写在 CODING 集体指标栏上，如果不在刚刚探讨的业务指标和事件里，就在填写时加上标注；
5. 每人解读本身设定的 O，有时为了节约工夫，也会离开按小组出现和解读；
6. 投票确定 O，并创立在 CODING 团队指标对应地位；
7. 用同样的流程确定 KR，关联对应事项；
8. 确定 OKR 的负责人和执行验收工夫。

指标详情页提供了残缺的指标状况

5、如何掂量团队成员对 OKR 的接受程度，确保 OKR 顺利推广？

团队须要建设 OKR 推广、跟进、复盘、评分四大阶段中的三种文化氛围，即：尊重、反馈与认可。

尊重

最后尝试推广 OKR 的半年到一年中，须要激励员工自主设定集体指标，同时联动团队指标的掂量后果，自主执行和反馈，团队管理层不做强干涉，定期察看和帮助即可。尽管很多 OKR 文章通知咱们“团队指标大于集体指标”的理念，然而倡议后期执行时反其道而行之，激励员工依照 OKR 的 SMART 准则，先思考本人的价值和能力边界，再摸索关联和延展性，同时通知员工，咱们都实现了大概 60% 的指标，这才表明咱们的指标是正确的，无妨大胆一点。

集体指标的设定、进度查看和调整

反馈

我了解很多 HR 或者 Team Leader 在推广 OKR 初期时，会放心团队成员的接受程度。其实员工都心愿可能被“受权”和“激励”，而不是管理者对他们的工作指指点点，员工也心愿向管理者表白本人的观点，而不是致力工作一年，最初才晓得经理对其工作体现的褒贬；员工也渴望定期将本人的指标、打算与别人分享，同时也心愿理解共事工作的停顿状况。

公开、通明的 CODING OKR 能够帮忙激发他们从不同角度思考问题 ：这些是我 / 你 / 咱们应该关注的正确的事件吗？如果我 / 你 / 咱们实现了它们，会被视为一个微小的胜利吗？你对我 / 咱们如何能力做得更好有什么倡议吗？

反馈能够是十分有建设性的，但前提是它必须足够具体。在倒退型组织中，反馈通常是由人力资源部门主导和安顿的。在更为成熟的组织中， 反馈多是不受约束、实时和多方向的，并且多是不分工夫、不分地点在组织内以开放式谈话的形式进行的 。对企业来说，员工与下级之间实现双向交流的机会是十分贵重的，比方员工能够询问管理者须要本人做什么能力取得成功，同时管理者也能够晓得本人须要从员工那里取得什么帮忙。类比 CODING 中麻利 Scrum 文化的导入，其中有五大流动别离为：

1. 待办事项整顿会议（Backlog Grooming Meeting）；
2. 迭代打算会议（Sprint Planning Meeting）；
3. 每日站会（Standup Meeting）；
4. 评审会（Retrospective Meeting）；
5. 反思会（Retrospective Meeting）。

Scrum 五大流动

参照上图，在 OKR 推广循环周期里，也能够召开一些 OKR 启动会、撰写评估会、季度执行复盘会、优良 OKR 执行表彰会等等。CODING 中的 Scrum 是麻利的一种，CODING OKR 也是麻利的一种 ，施行次要看人，强调是自组织、自驱动的，只有一直地在理论利用中认真领会，能力感触到企业和组织随着麻利或 OKR 的循序渐进变得越来越高效和具备创新力。

认可

• 激励共事间认可： 当员工的成就取得共事的统一认可时，就会激发一种感恩的文化；
• 建设明确的规范： 正确辨认员工目前进行的是口头还是后果：实现非凡我的项目、实现公司指标，还是展现公司价值；
• 分享有利于减少认同感的故事： 能够应用实时通信工具、公司外部知识库或 CODING Wiki 分享这些成就背地的故事，赋予认可更多的意义，进步认可产生的频率和可获得性。即使是很小的成就，也该当予以投诉。比方为在截止日期前竣工而付出的额定致力、对提案进行润色欠缺，或者是做一些在管理者看来是理所应当的小事。

6、OKR 是否提倡部门全员公开可见？

是的， 公开通明是 OKR 的重要准则之一 。例如字节跳动有个十分有特色的治理理念，叫做「基于上下文，而不是基于管制」（Context,not Control），即心愿员工能在残缺的信息根底上判断事件该怎么做，激励员工被动思考，而非强调流程、上下级与命令。在字节跳动，大家的 OKR 是公开的，即便是入职第一天的员工，也能够间接看到张一鸣的 OKR。

“比方咱们有十分多的跨部门单干，‘散会坐在一起却不意识对方是谁’的状况很常见，我常常的做法是，拿起手机，关上他的头像，看一眼他的 OKR，半分钟就晓得他的主要职责和工作重点是什么了。”因而在字节跳动，OKR 不仅是自上而下拆解的后果，除了与下属无关，还与本部门共事、跨部门共事无关，是高效沟通与协同的根底。应用 CODING OKR 即可依据组织架构设定不同角色的查看权限，当然，咱们激励全员公开可见。

在「团队治理」->「权限配置」中为相应的用户组设置权限

7、OKR 中的 KR 应该怎么写？颗粒度应该如何把握？

• 如果你的 KR 超过 2 行，它很可能是不清晰的。
• 如果你的 KR 形容中充斥着外部团队术语，例如“公布 CI 元数据串联和门禁能力”，那它们通常就不是好的 KR。 真正重要的不是“公布”这个动作，而是其所造成的影响（Impact）到底是什么 。为什么“元数据串联”很重要？更好的表述是这样的：“公布 CI 元数据串联和门禁能力，晋升研发标准，减少数据流视角”或者简略写成：“晋升研发标准，减少数据流视角”。
• KR 请应用实在日期 ，如果所有 KR 的截止日期都是季度最初一天，你制订的打算就很可能是有问题的。
• 确保你的 KR 是可度量的 ，KR 必须是每个季度末能够进行主观评分的。“晋升注册用户数”不是一个好的 KR，“在 6 月 1 日前晋升日均注册用户数 25%”则是一个好的 KR。
• 确保度量指标是清晰的 ，如果你说“一百万用户”，你要指明这指的是全时段用户，还是只是 7 天沉闷用户。
• 必须是产出导向，而非动作导向 。如果你的 KR 蕴含有像“征询”、“帮忙”、“剖析”、“参加”这样的词汇，那么它形容的实际上是动作而非后果。与之相同，如果形容的是这些动作对最终用户所带来的影响，例如：“在 6 月 7 日前更新自动化用例库，实现疾速、精准的自动化执行”，就是一个合格的 KR，而“更新自动化用例库”则不是。
• 必须能自证其是否已实现 ，这个证据是可轻易获取的和可信赖的。例如证据能够是 CODING 上的 Wiki、网盘或是具体的一个我的项目动静，比方我的项目内的变更列表、文档链接、已公布的品质报告等。

反对要害后果的新增和编辑，反对调整指标权重

8、程序员如何制订 OKR？

程序员的工作怎么量化？Bug 数？代码行？版本数？但这些指标都是不可行的。或是比拟团队间的代码行、Bug 数、版本数或者分享次数？这些其实都不行。前瞻性的工作谁违心做，有危险的工作谁违心做？例如引入 ElasticSearch 实践上能够晋升搜寻性能，但可能在引入的这一年反而会带来很多问题，而能带来多少收益还不确定，这时该如何制订 OKR？

假如技术总监接管到 CEO 指定的大的战略目标是“用户量增长 20%”这样的指标，他就应该依据团队的资源优势去制订本部门成员能够了解且着手的 KR，例如：

1. 影响用户增长量的技术指标有“安装包大小”、“App 启动工夫”、“App 解体率”、“App 耗电状况”等等，假如通过剖析后技术团队认为目前安装包太大，并且 App 启动工夫较长，那么能够将这两项相干的优化作为技术团队的 OKR：App 安装包从 20M 缩减到 8M、App 启动工夫从 2s 优化到 500ms，而这两个 KR，业务负责人简直是不可能提出来的。
2. 影响用户良性反馈的起因之一是发版节奏过慢，过慢则是因为版本多而测试环境有余，测试环境有余是因为机器不够，那么能够得出一个指标：解决测试环境有余导致版本期待的问题。合成进去的 KR 能够是“增加 4 台测试环境机器”（是的，尽管是一件很简略的事件，但这也能够作为 KR），也能够是“引入 Docker，反对一台机器搭建 20 套环境”（这个 KR 比拟合乎技术人员的了解）。
3. 影响用户剖析和增长的起因之一是外部合作和需要流转过慢，产研侧往往须要一周的工夫能力把用户故事拆分至对应版本，拆分和评估用户故事的过程很可能是通过一些易用性不强的工具来记录和揭示。而从新评估一个研发项目管理工具就尤为重要。CODING 是一个蕴含代码治理、我的项目协同、测试治理、继续集成、制品库、继续部署、团队知识库等工具的一站式软件研发治理平台，在我的项目协同环节有迭代治理、需要细分和灵便跟进的看板视图，很适宜创新型企业灵便的治理需要和疾速迭代。

弱小灵便的项目管理性能，让团队高效协同

通过以上形式进行思考和合成，最终技术团队要做的事件如下：

• 应用 CODING 疾速落地麻利开发与 DevOps 开发方式，实现研发效力降级。
• App 安装包从 20M 缩减到 8M。
• App 启动工夫从 2s 优化到 500ms。
• 引入 Docker，反对一台机器搭建 20 套环 境。

总结

OKR 是麻利的策略业务管理以及我的项目布局和组合治理的一个重要框架，心愿通过 CODING 能帮忙团队将 OKR 的启动、撰写、跟进、复盘四个阶段执行得更加欠缺，随时记录团队成员周期内实现的挑战及为团队做出的奉献。