大家好，关于全员培训网站源码分享很多朋友都还不太明白，今天小编就来为大家分享关于全员培训app的知识，希望对各位有所帮助！
近几年，OKR得到越来越多企业组织的选择。很多科技公司以及以产品和客户为中心的组织都在大量使用OKR。这些公司用OKR来追踪产品团队的成效。
然而并不是所有公司都能收到好的效果。那么，问题出现在哪里？OKR适合所有团队吗？到底如何制定OKR?有没有可参考的案例？本文从以下7个方面为您分享：
1.为什么需要OKR？
2.OKR的理论来源是什么？
3.OKR适合什么样的团队？
4.常见的产品技术部门OKR类型有哪些？
5.如何制定OKR？
6.OKR目标管理法实施步骤是什么？
7.落地案例：OKR带给我们的6点变化
希望这些内容能对您有所帮助。
01为什么需要OKR
1.目前信息高度碎片化的时代，没有一个目标高度集成与统一的方法，会极大地降低团队的工作效率，导致项目重复研发，无用功能研发、项目Delay甚至失败；
2.OKR的目标导向会使项目更高效精准地落地；
3.使团队发挥最大的主观能动性，提升产品的自驱力，促进团队的良性循环；
4.OKR经过硅谷等诸多大中小公司实践验证过，推广成本可控；
02OKR的理论来源
OKR是一个目标管理工具，它要帮助企业解决的问题非常明确，就是“如何让一把手的战略思考，能够有效地转化为组织上上下下具体的行动”。
为什么明明有了战略，却不能转化为组织上上下下的具体行动？问题出在现代企业组织存在四个“割裂”。
哪四个？分别是“高层与基层”“想象与现实”“部门与部门”“计划与实施”之间的割裂。形象一点说，也可以表述为“上下”“内外”“左右”，以及“前后”四个方向的割裂。
这些问题，其实都是企业管理中的老问题，有没有办法解决，让战略能够真正落地？有。这就是OKR的理论来源。
1954年，被称为“大师中的大师”的管理学家彼得·德鲁克撰写的《管理的实践》出版。在书中，德鲁克提出了一个划时代的概念，叫“目标管理”。
德鲁克说，企业的使命和任务必须转化为目标。组织最高层管理者在确定组织目标后，要对它再进行有效分解，转变成各部门的目标。部门管理者又要通过这些目标来对下级进行管理，包括考核、评价，和奖惩。
德鲁克的意思是，如果我们把组织管理看成一个金字塔，那最上层是使命、愿景、战略，你可以理解为企业这艘大船航行的方向。最下面就是战略执行，包括具体的项目、任务。
如何保证上面和下面不脱节？你要在中间插入一个连接器，把上面的战略分解为一层层、一个个的目标，以及实现目标的手段。
当然德鲁克只是提出了“目标管理”的理念，他没有细说这个以目标为中心的连接器具体长啥样。真正把它描绘清楚的，是英特尔公司的传奇CEO安迪·格鲁夫。
它最早实践了德鲁克的理念，在英特尔推行目标管理，并取名为“目标与关键结果法”，这就是我们今天看到的OKR。
OKR是Objective&KeyResults首字母的缩写。安迪·格鲁夫要求各个层级的管理者、员工，都要用统一的标准形式来描述自己的工作。
其中O表示目标，排在前面，说的是“我和团队想要完成什么”；KR是一系列可衡量的关键结果，排在后面，说的是“我如何确保自己正在朝目标前进”。
03OKR适合什么样的团队
先决条件
并非所有的产品技术团队都适合独立引入OKR方法。如果要让这个方法在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征：
1.产品技术团队能够对产品的设计、开发和交付整体负责；团队具备主控性，而不是受制于多个部门的配合；
2.非项目服务业务模式，产品技术团队服务的是本企业的产品，而不是客户的产品，否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励OKR的实施。
3.公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量；销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是面向企业的产品则要视情形来看。
同时，这三个基础条件也决定了产品技术主管一般都是公司的核心管理人员，对公司的资源分配，协调其他部门的工作能够起到关键影响。
如果以上提到的先决条件不存在，那么这样的团队独立实施OKR的成效是不乐观的。
实际上，如果缺乏自治度和管理关注度的产品技术团队本身也很难有动力来自行发起目标管理。即使做，一般也只是为了响应公司从上至下的管理要求而已。
04常见的产品技术部门OKR类型
当我辅导了十家科技企业的OKR制定沟通会议以后，我发现这类企业的OKR选择有非常明显的规律。团队相对容易达成一致的目标意图（Objective）大体会分成这么几类：
一、产品特性交付里程碑
这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任，所以容易有这样习惯性的思维——本季度发布某某特性，交付2.0版本产品等。
在这个动因下，产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付2.0版本？2.0版本主要解决的问题是什么？除了形式上的交付，用什么KR能够更好地定义交付成功？
一个好的产品交付目标应该揭示背后的商业意图。比如：「通过2.0解决客户自助部署问题」，「通过3.0解决合作伙伴增加销售选项」就是更加完整的目标描述。
正是因为如此，这类目标所配套的关键结果（KeyResults）也要能够反映出意图达成的KPI（请中性理解这里的KPI含义）。发布时间本身不应该成为KR，发布后能够形成的一个关键数据指标才是。
比如上面「通过2.0解决客户自助部署问题」的Objective可能需要配套一个KR：自助部署页面的UV数量，它反映了这个特性交付带来的客户价值，每有1000个UV，说明可能有1000个用户得到了自助部署系统的帮助。在第二个例子中，合作伙伴销售中新产品的占比可能是一个有价值的KR。
在产品特性交付目标方面，我还经常发现一个常见困难，就是每个季度的OKR周期很难保证一个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如「完成单元测试」、「完成数据架构设计」等。
二、提升开发和运维质量
在产品型公司的早期，因为经验和能力的原因，在产品开发和运维过程（DevOps）中存在大量缺陷。有一些质量问题也可能是因为「MVP」理念导致的。这些可能都是创业公司不可避免的阶段。
但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投入，不仅无法转化满意的客户，而且会让整个团队士气低落。
但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成和管理上，有时候是难以顾暇，有时候是没有意识到产品质量对于提高销售效率的重要性。
与其等到部门之间相互指责和推诿，有全局观的CTO应该尽快聚焦在提升质量的目标上。在达成这类目标时，产品技术团队的自治能力至关重要。
技术产品的质量提升目标不难设定用于衡量的关键结果（KR），但指标选择的过程最好依然是从下至上的，因为非专业人员很难有相关的知识背景。
如果是和软件缺陷有关的质量改进，这个关键结果最好能够落在测试流程内部（用例的数量和覆盖度，测试的自动化程度等），而不是去衡量客户投诉率这样的滞后性KR；如果是和运维质量相关的目标，KR则更容易选择一些，因为有足够多的监控工具来直接提供有意义的指标。
我说这类KR容易识别，有个前提，就是KR的选择制定能够充分地发挥主管工程师的领域知识，而不是管理者由上至下制定，简单说，就是让专业的人来测量。
三、运营改善相关
产品运营的职能划分在不同公司不一样，但有很多互联网企业很重视产品运营，并且意识到产品设计和研发团队对运营管理的直接驱动力。所以，也有不少产品技术团队会直接提出和运营改善有关的目标，这通常发生在企业的成长阶段。
AARRR（获取，激活，转化，留存和推荐）是建立运营改善目标的最佳模型，它揭示出一个产品的总体成功来自这五个基本运营环节的成功。
产品运营绩效目标的达成依靠的是方法、智力的投入，比如通过UserOnboardingDesign（用户上手指南设计）提升新用户激活度，而它带来的产出在财务上却非常显要。
卓越的产品运营能够大幅降低平均营销成本，提升用户终生价值。从这个角度看，来自产品技术团队的相关目标设定，能够大幅影响公司的最终绩效。
这类目标的描述可以非常直白，面对惨淡的留存，产品团队应该意识到“提升用户留存”是一个显然的目标意图，但是在每个公司的具体业务中，它的描述可以更加明确，比如「通过游戏化设计来加强用户留存」，「通过Onboarding模块加强用户留存」等。
目标的设定越明确，在OKR执行过程中的任务设计就越顺畅，在复盘时头脑也更加清醒，不会被干巴巴的数字所制约。
和开发运维质量提升相关的目标类似，产品运营的KR制定也有它的专业性要求，比如有关用户留存的KR，专业领域内有几十个可以使用的指标，到底哪个指标能够反映当下目标的实现度？次日留存和次月留存可能有完全不同的暗示。这需要专业的产品运营自发来选择指标，而不是等待管理层派发指标。
同样，前面提到的目标描述的具体度也会影响我们选择KR时候的精确度。当OKR的执行结果和个人的奖惩脱钩的时候，我们就可以自发和客观地选择最科学的指标来衡量目标达成度。
四、提升产品市场适配度
对于产品技术团队来说，这是一个高难度的目标。但对大多数企业来说又是产品化过程中极容易遭遇的问题——产品不对路。
产品的功能和特性和客户的实际需求存在断层，这是一个普遍的企业失败原因，不仅在产品早期可能出现，在扩张阶段也可能再次遇到。杰佛瑞·摩尔在经典著作《跨越鸿沟》中阐明了出现这种情况的必然性。
尤其是科技产品，早期用户和主流用户在需求和心理上的巨大差异使得一个新产品在进入早期市场和拓展主流市场的不同阶段面临完全不同的市场接受度。
产品市场部门很难独立定义这样的目标。不仅可能缺乏足够的决策信息，也很难有这样的决策权威，因为它很容易挑战到一个公司的品牌和市场定位，细分市场选择。
所以，这类目标的设定通常都需要和管理层，销售业务部门建立充分的沟通，对每个企业来说，都是头等大事。
在理想情况下，产品技术团队从第一天起就十分重视客户导向的产品开发流程，产品的每一步定义都小心谨慎地获得客户验证，每一个特性扩展也都保持足够的自律。
但在企业实践中，这种理想情况很难达成。即便全员都高度客户导向，也有选择和取舍上的困难。我发现科技型企业在这个问题上的试错成本总是最高的。
设定好这一类的目标的前提是企业对「理想客户对象」有更加明确的定义，如果不能定义清楚目标客户，那么所谓的适配度提升就缺失了参照对象。
假设这个步骤能够达成共识，那么产品技术团队就需要和销售业务团队仔细沟通产品应该怎样改进才能更好地满足这类目标客户的需求。在以季度为周期的OKR执行中，聚焦解决那些能够有助于提高产品市场适配度的关键特性。
这时候，选择对应市场的销售转化率作为KR可能是更明智的做法。因为所谓的需求匹配，最终是依靠客户的买单来证明的，在客户买单之前，我们很难找到可靠的前导性指标。对于面向个人用户的产品，验证要更加容易一些，一般留存率和活跃度指标都能够很好地反映需求匹配度。
这个类型的OKR叙述起来比较抽象，我举一个比较典型的例子。比如一个SaaS产品在运营两年后，产品功能和模块越来越繁复，导致产品在面对任何一个具体客户的时候无法用简明的陈述和演示来说明清楚产品价值。如果通过OKR工作法来解决此类问题，就可能涉及到这类短期目标。
比如「强化产品针对服务型企业的CRM特性」。与此相关的KR可以是服务型企业的成交转化率或者留存率。虽然这个KR不得不滞后衡量，但它的确是反应这个意图目标的实现程度。
五、技术选型变更和偿还技术债
在业务成长到一个阶段时，有一些技术团队会意识到紧迫的架构调整、技术选型升级等偿还技术债问题。
这更加是一个需要由下至上设定目标的领域，因为很少有公司的管理层和其他业务部门关注这一点。如果业务发展顺利，用户不断增长，那么该发生的事情一定会发生。警惕性高的CTO们会未雨绸缪，在频繁宕机之前，把问题提前解决。
设定这类目标时，要重视的是和管理层达成共识，因为这些技术工作必然会影响功能特性开发，锁死一些常规事务的进展，也可能涉及一些可控风险。如果没有事先的沟通，很可能会发生不必要的冲突。
当然，这些目标是否应该成为产品技术部门某季度必须面对的关键目标，这不能是CTO的主观臆断。它应该建立在数据的客观分析和预测上。
衡量这类目标的KR也不难识别，甚至纯技术层面的压力测试就能够很好地回答这个问题。
我们有没有让基础构架更加健壮？我们能否承受每小时100万次以上的访问？设定了这类目标和关键结构，就公开给其他部门的同事，这样既能够让团队周知这些事务的重要性，争取支持，也能够激励营销和销售部门，建立更强的业务拓展信心。
05如何制定OKR
一、好的OKR是长什么样子？
听完上面的解释，可能对很多人来说OKR还是有点抽象，这边举个例子：
【范例】
我们是一个电商平台，我们想帮助买家更容易搜寻到想要的东西并购买。
Objective：提升搜索效率
KeyResult1：首次搜索结果页的商品访问次数提升X%
KeyResult2：用户搜索到下单行为的转化率提升Y%
这里的目标是改善搜索的效率，所以第一个指标看的是「第一页的搜索结果是否更相关了」，第二个指标看的是「用户看了之后有没有进一步动作/购买」，如果结果更相关、用户都有往下一步前进，那么搜索的效率就变得更高了。
如果大家看以上的案例，可以发现，目标只会定义方向，而关键结果则会和我们怎么执行有关系。两者加起来，让人一看就可以知道你为什么要做这件事情、怎么做、以及最后理想成果的样貌。
不太好的OKR范例
好的，看完范例之后，那我们再来看看什么叫做不那么好的OKR！
那再让我来举一个例子：
【范例】
我们是一个电商平台，我们想帮助买家更容易搜索到想要的东西并购买。
Objective：提升搜索效率
KeyResult1：搜索转化率提升X%
KeyResult2：开发三个以上功能提升用户搜索体验
KeyResult3：搜索带来的收入提升10%
错误一：指标定义太过模煳
在电商世界大家常常把转化率挂在口中，但这转化率到底是从哪里转换到哪里？在定义OKR的时候一定要非常明确，案例里的KR1来说的话，光写出转化率是不够的，写出详情页到下单的转化率，或者浏览到详情页的转化率才是正确的做法。
错误二：关键结果和目标没有直接相关性
在KR2中，范例提到想要开发三种新功能，但是在实际的产品开发中，真的是功能越多越好吗？这可不一定，所以在订OKR的时候最好避免「做多少功能」这样的写法。
不过！这不代表我们不能放上「执行面关键结果」，有些情况下，其实使用执行性的关键结果是更好的，比如说，假设我们的目标是要去了解一个新的产品领域，在这种探索问题的阶段，就可以写「执行X场用户访谈来了解用户」这样子的执行性KR，因为研究做得越多，我们就会更了解这个新的产品领域，两者是有明确直接相关性的。
另外一种也很适合放在OKR中的「执行面关键结果」是采用率，比如说如果我们要将旧系统迁移到新的系统，比起说「我们完成了多少个功能的迁移」，不如说「有多少百分比的用户已经开始使用新系统的功能来达成目标」等等，换一个角度以用户的目标来思考，也会帮助自己设定更好的OKR。
错误三：把商业影响当作产品成果
这一点其实并不是真正的「错误」，而比较是我个人对于产品团队OKR的看法。我们的确可以把商业影响放在目标上或关键成果上，尤其在组织等级的OKR，这似乎是蛮合理的，但是若要用在产品团队上，我个人认为这并不是最好的产品指标。
当我们做了新的产品功能或改动，这叫做团队的产出，当我们的产出实际影响了用户行为、产生价值，这时候会创造出的是用户的行为成果，而当用户的行为成果转换成了商业价值，那么才会带来商业影响。
在产品团队的营运中，产品经理与团队成员们应该要长期关注的是用户行为的成果以及用户成果与商业影响的关联性，而非只关注商业影响。我做的功能是否有解决用户问题？解决这个用户问题是否可以替公司带来正向影响？而不是思考如何去用各种手段刺激营收的增加。
用成果当作KeyResult有一个很大的好处，就是因为成果是人类的行为，所以它们通常都是可衡量、也可直接观察到的，非常符合OKR的定义。
当我们只关注营收，不关注用户成果的时候，除了可能会变成乱枪打鸟，而且还可能产生很多所谓的DarkUXpattern，比如说在电商网站上常常会跳出折价券对话框，一个按钮是「登入获取折价券」而另一个按钮上面写着「我不想要有折扣」。这样的设计我想或许对营收有帮助？但是这真的有解决用户问题吗？用户当然还是想要有折扣，但这样的文字好像有点…
不过就算把关注点放在用户成果，我们还是要非常关注用户行为和商业成果两者的关联性，毕竟公司要可以赚钱才可以生存。所以在设定OKR时锁定的用户行为，也要和商业影响有明确的正相关才行！（例如用户看越多商品、搜索越多、加入购物车越多，都代表他们找到好物，也代表会替公司赚钱，这些都是不错的指标）。
总结来说，我个人是比较推崇把产品团队的OKR主要关注点放在用户的行为改动上，这样的关注点比较能够兼顾商业影响与用户问题两大天秤，不会一昧的倒向一侧。
二、OKR的优缺点
OKR不是什么用了就会让产品突飞猛进的仙丹，它就只是一把很好用的测量工具，端看你的用法，也会有不同的优缺点产生。
1.优点：
（1）专注于成果（Outcome）而非产出（Output）
OKR定得好的话，它可以很有效地鼓励大家专注在成果而非产出。
从目标开始思考要做什么产品改动的话，项目与成果的连结性自然就会产生。在规划项目的过程中，可以提醒自己「做这件事情会帮助我的OKR吗？」「如何最小化的成本测试目前的点子或策略方向是否有帮助达成OKR？」，透过不断地反思，可以加强产出与成果两者的连结。
如果做了某功能之后，发现一直没有达成我们期望的成果。只要还是同样的成果，就可以调整项目方向，不用硬着头皮做没有效用的投资。
（2）有一把尺来衡量进度、判断优先顺序
产品的优化是永无止境的，如果只是做「对」的事，有的时候很难取舍，但当有了OKR后，团队会有明确的承诺和责任，可以专注在真的可以帮助成果的事，避免和主要目标不相关的事情占用团队的精力。
如果能够搭配Dashboard，每周或双周检视OKR的进展，也会比较有回馈感，知道自己有在向前迈进。如果没有，也能借此提醒自己是否应该试试不同做法。
（3）协助达成共识
把目标写出来之后，可以清楚看见不同团队的目标和最终成果是否有相冲突，如果有的话，就可以在规划阶段提前先协调沟通。
如果某OKR需要其他团队的认同才能达成，也可以讨论看看是否两个团队共用同一项OKR，当目标相同时，资源和优先级都会更好讨论。
例如，我目前的团队在内容策略，需要隔壁的推荐算法团队支援才有办法交付成果，两个团队讨论过后决定共用一个「借由个人化内容达成更高」的OKR（*非真实OKR，只是举例用），并且定期开会，一起讨论点子来共同贡献相同的目标。
2.缺点：
（1）定义不当的话容易沦为待办清单
OKR的框架很好，但目标和KR的制定需要练习，如果太专注在执行的「方式」和「时限」，而非专注在专注在成果（outcome），就没有办法达到OKR的本意。
Output是你的「输出」，是你直接产出的第一手结果，在数位产品中可能是个功能，在内部营运中可能是一套新的流程。
而Outcome是「成果」，是你的输出带给人们的影响，在数位产品中是每个功能带给用户的效益、改变的行为，在内部营运中是新的流程被运用后的那份价值。
（2）KeyResult定得过高，带给团队不必要的挫折与压力
我不知道该不该说这是缺点，感觉只要是目标框架，不管是KPI、OKR还是其他，都有可能会有这个问题，毕竟人类天生就不擅长做假设与预估。
但我很肯定的是我刚开始用OKR的时候，每一次都定得过高，这种情况可能持续了不只一季两季，而是持续了一年两年，虽然一直下调还是很难达到。
我只能说各位Leader请面对现实，OKR不是用来鞭策大家然后逼迫大家加班烧脑的，OKR是来定方向的。
不是说定得很高就更有机会达标！达不到就达不到，试着找到无法达成的原因加以调整，也同时修正OKR让它更靠近现实吧！虽然可能需要好一阵子的练习，但只要领导者愿意修正并接受自己估计错误这件事，相信团队不会过度责难的。
3.运用不当时可能造成团队各自为政的情况
如果因为OKR划清楚界线后，过度保护自己的目标而忽略其他人的目标，容易带来团队保护自己资源、各自为政、互不支持的负面效应，这个时候上面提过的「共用OKR」就是一个有效的方法来突破这种状况。
共用OKR有几种常见的方向，最常见的莫过于在紧密合作的成员身上（e.g.A和B团队有共同的项目要推动，共享一个OKR），也可以是在垂直组织上（e.g.所有「买家体验」相关的团队。
大家共用一个目标，共同协助买家找到喜欢的商品并购买），也可以是用在横向组织上（e.g.全公司的设计团队都必须一起遵守设计标准）。尽早找出和你相依性高的团队，一起定目标吧！
三、手把手教学：如何带领团队一起定OKR？
我的领导风格比较是带领大家一起协作，所以会希望让团队成员都可以参与目标的设定，以下和大家分享我和团队一起订OKR的步骤与流程，让第一次尝试的人有个方法可以参考。
假设你已经有很明确的团队愿景和目的，只是要规划下一个季度或年度的话，可以往下看。
步骤一：定义目标（Objectives）
首先，我会收集团队对于下一个季度的想法。
如果你的团队是会对于目标有想法的，可以问大家「到下一个季度结束之前，我们想要达成什么？」，整理想法之后做总结；
如果你的团队习惯自上而下的目标制定方式，那么你可以先定出一个目标草稿，分享给大家，问大家「这个目标大家觉得优点是什么，缺点是什么，是可行的吗？」，整理反馈之后做总结。
步骤二：定义关键成果（KeyResults）
目标有个方向之后，接着可以问大家「我们该如何知道我们正在朝这个目标前进?」
我会建议不要直接问「我们要用什么指标」或「我们该如何衡量」，不是每个成员都会对商业指标和衡量方式有熟悉度，所以当你这样问的时候，有些人会不知道说什么。问上面的这种开放式问题，会比较容易开启对话！
一样，收集反馈，询问大家为什么觉得这样衡量是好的，再总结。
步骤三：写出第一版草稿、获取团队与合作伙伴的反馈
最后，OKR还是必须由少数人来做取舍与决定，所以产品经理可以把大家的反馈听进去之后，写出第一版草稿，并且分享给团队与相关的伙伴们获取反馈。
让团队参与OKR的定义好处多多，定出来的目标更容易让团队买单，也更容易创造责任感（ownership）。
06OKR目标管理法实施步骤
一、准备阶段：
1.确定目标
这个事情需要团队Leader来主导，一般是由产品经理或是项目经理来主导，带领大家花半天的时间来讨论，业务场景、核心功能是什么、要解决用户的哪些需求。
2.团队成员
假设这个APP需要1个产品，1个UI设计师，4个研发人员。这个时候作为产品经理需要说服团队每一个人，来保证大家认可并一致朝着这个目标努力。
二、OKR实施方法：
如果是软件研发的团队OKR目标主要关注研发质量、提升用户体验和产品转化；如果是运营团队，OKR目标可以参照收支、运营转化指标等。
三、OKR四象限：
1.本周关注的任务——明确事情优先级顺序，建议P1任务不要超过3个，总任务不超过5个，这样可以使团队目标聚集从而更加高效。
2.未来四周的计划——未来四周会推进的任务列表，主要是给其他相关业务部门了解后续工作的，可以有负责人以邮件或者会议形式灌输，这样的话才不至于后期相互扯皮推诿。
3.OKR当前的状态——展示出OKR的最终目标（有点类似双11前，很多电商公司喜欢在办公区域拉横幅），关键结果需要可以量化为具体数值的。5/10是本周的信心指标，10是100%可以完成，5是指50%可以完成（有一半的信心完成），5是比较好的状态指标，需要团队一起努力才能完成目标，这样可以激发大家的斗志。
4.状态指标——主要是3类，一个是用户端反馈，一个是团队状态，还有就是软件状态。这些指标会影响到最终目标实现，需要从中挑选出最重要的2个的状态指标。
四、OKR实施过程与效果验证
1.OKR每周目标制定：每周一完成制定，需要拉上团队成员一起参与制定本周OKR任务计划，总结上周工作情况，有问题的话需要大家一起商讨来解决。这里推荐大家首次需要给团队来个动员会，可以取一个霸气的代号名称，例如“诺曼底行动”“联盟计划”“U计划”之类的给目标赋予一定的战略意义。
2.OKR每周总结：每周五下班前1小时组织大家庆祝本周完成情况，可以提前买点饮料和零食。不是批评反思会，团队Leader只需要肯定大家本周的工作，让大家相互之间了解工作进展情况。
3.OKR教练：OKR教练需要对OKR任务目标的设置提出一些规范化更加符合业务场景的建议和改进意见。OKR教练可以由一位思维缜密，对业务了解熟悉OKR的人来担任。
4.OKR效果验证参考标准：完成度60-70%为Good，40%以下为Bad。
5.OKR常见问题与建议：
（1）推行不利，这个需要团队leader对于OKR管理方法有很强的贯彻意识，不是实验性质，带领大家一起制定，有参与感的话，成功率会更高；
（2）周一是沟通交流，不是工作汇报，周五是庆祝会，不需要很严肃；
（3）OKR周期过短，设置OKR的周期最少3个月；
（4）个人OKR，不强求很细致，需要的话可以由Leader来跟每个人单独沟通制定；
（5）所有的目标都应该是协商制定的。
07落地案例OKR带给我们的6点变化
一、我们为何引入OKR？
我们团队于2015年成立，最初只有几个人，主要负责业务方向是垂直电商。最开始的电商研发小队，接到这个时间紧任务重的从0到1的建设任务，也是鸭梨山大。
好在团队梯队比较健全，有深耕互联网多年的老司机，有初出茅庐的应届大学生，在互帮互学的氛围引领下，逢山开路遇水架桥，逐渐在一片混沌的情况下开辟了新气象。最终我们把国内电商这块硬骨头啃了下来，收获了业务团队的信任和兄弟团队的称赞。
在这种团队风貌的影响下，越来越多的业务交接过来，小队也逐渐变成了小组，变成了大组，直至成长为如今的平台产品研发中心，负责整个vivo互联网平台类方向的研发工作。在这风云变幻的8年里，我们见证了互联网的飞速发展，也经历了组织架构调整，业务调整，团队合并，我们改变了很多，但始终保持着那份初心。
一路走来我们收获了非常多的荣誉，同时也遇到了相当多的困难，特别是在团队规模持续扩大的情况下，我们的团队管理面临着巨大的挑战：
1.团队目标对不齐，项目协作总困难
这是在当时非常常见的问题，多发生在上下游有依赖的项目中。比如某一个项目，同时有多个团队在支撑，而这些团队都有各自的产品规划和目标。这就导致在项目版本中，经常出现A团队觉得有个需求非常重要紧急，需要B团队配合，却发现B团队因为要执行自己的计划而出现资源冲突。
2.角色视角有偏差，Roadmap拍脑袋
即使在同一个项目团队，也会存在因为角色的不同而在一些事情上出现分歧，一个产品从研发的视角来看要让其稳定高性能的运行，此时他就会想着做对外接口的性能优化；从产品经理的视角来看就想让产品具备更完备的功能，不停的增加新功能。
因为资源的有限，是先进行接口性能优化还是开发产品新功能呢？两拨人争执不下，每个人都说自己的优先级高，这个时候我们怎么做决策呢？
3.版本人力空转，资源协调不及时
我们的团队负责的项目很多，大的项目十几人参与，小的项目一个人负责几个，出现“旱的旱死，涝的涝死”的情况再正常不过了，有些项目这段时间特别的忙，版本的排期都是根据最终交付时间进行倒排，而此时此刻另外一些项目却只有零星的小需求，不慌不忙。
4.学习进取成空谈，完成任务是唯一
为了打造一支学习型的团队，公司专门建设了一个线上学习平台，上面有各种类别的学习视频，并且规定每个员工每年必须参与学习多长时间，即使这样效果也不甚理想，每年到年底的时候很多人都需要进行冲刺，毕竟学习是痛苦的，让大家快乐的学习貌似变成了一件不可能的事情。
5.绩效考核遭质疑，什么样才算是优秀？
一个高绩效员工所产出的创新效果数倍于一个能力中等的人，同时优秀人才创造的出色成果还能感染激励更多的出色人才，可见优秀的人是多么的重要。
那么如何识别优秀的人才呢？以前我们用环评+自评+KPI三套组合拳的方式来评定优秀，导致员工比较质疑这个结果的公平性，因为环评+自评本身非常主观，并且KPI又不够透明，管理者总是需要直面这样的挑战：为什么这个人表现平平，绩效比我好？
上面列举了我们团队之前趟过的一些坑，其实说到底还是怎么管理团队的问题，包括如何调动员工积极性，如何发挥每个人的主观能动性，这也是我们一直在思考的方向。在16年，我们就已经逐渐意识到，原有的类KPI的绩效考核方法对于研发岗位变得不适用了。随后我们去寻找新的管理办法，调研了主流的管理方式，发现它们都与vivo互联网的文化和团队实际情况无法完美契合。
向外求无果的情况下，我们开始摸索新的管理理念来打造高绩效团队，同时积极寻找更加优秀的管理工具，期望能够将沉淀下来的经验更好地落地和推广。19年的夏天，部门开始学习、引入OKR管理工具。在学习OKR了相关理论书籍后，我们惊奇的发现原来一直苦苦找寻的，能解决我们痛点的工具，就这样出现了我们的面前，直叹相见恨晚。
二、OKR带给我们的改变
我们团队的愿景：持续成长为行业一流的技术团队，并打造出了一支自组织、高绩效的标杆团队。目前由三大互联网服务端研发团队组成，人员规模在两百人左右，业务整体可以划分三个方向（三驾马车）：平台产品，营销产品，创新产品。三大业务方向相辅相成，都有着各自的责任和使命。
（1）平台产品：主要包括业务平台与效率中台两大模块，完善沉淀，稳定支撑业务发展的项目。
（2）营销产品：主要包括线上营销与线下营销两个模块，主要是能力组合复用，助力营销变革。
（3）创新产品：主要包括管理创新与技术创新两个模块，创新产品主要是源于业务，发掘新的可能。
无论团队人员规模还是业务复杂度，都不难看出，对于团队成员以及业务的管理面临着不小的挑战。
从19年正式引入OKR起，为了应对不断变化的业务，以及不断调整的组织结构，在团队和业务发展中，我们不断实践和优化符合我们团队特色的管理方式，集百家之长，成一家之言，逐渐沉淀出一套逻辑清晰的管理理念。
引入OKR三年多来，让我们一直坚持的“面向未来的组织”的管理理念遍地开花，给我们团队带来了方方面面的改变。团队的凝聚力、氛围以及生产力得到了极大提升，以下是我们认为比较重要的改变。
1.专注团队最重要目标
人生之要事在于确立伟大的目标与实现这目标的决心。——歌德
首先，我们需要制定出好的目标，需要足够“伟大”，同时又要让所有人都能够有参与感。在引入OKR后，我们的目标是通过自上而下+自下而上双向产生。
在公司确定年度规划和战略目标后，我们会根据自身业务和团队的特点，制定具有挑战性的目标以支撑战略的落地；接着团队成员主动去思考，制定出衡量实现此目标的关键结果，以此解决目标的制定与目标的执行割裂的问题，让团队成员都有参与感，自主感。
其次我们会为每条关键结果指定负责人，通常是由提出人负责，当然也可以协商由其他人负责。在负责人owner制度下，可以更好的发挥主观能动性，从心理学角度激发完成承诺的欲望。
最后使用在线的OKR管理工具来保证目标的透明性和公开性，通过每周OKRtips来提醒员工持续专注于自己的OKR目标，通过两周一次的OKR庆功会来持续激励和反馈困难。多措并举之下，团队成员自始至终都专注于最重要的目标。
2.聚焦价值挑战不可能
有的人可能会讲定目标那还不简单，但是我们认为，目标不能太多，需要集中优势兵力解决核心问题，让组织保持专注。资源是有限的，为了保证组织的专注，目标的制定必须要聚焦价值。
这样事情就变得简单多了，当我们进行两个人目标PK的时候，就比较张三的目标与李四的目标的价值，每个人对自己提出的目标进行价值论证，同时论证的过程也逼迫着我们深入思考，思考我们的目标对用户的价值，对产品的价值，对组织的价值，然后大家一起评估，最终确定我们这个季度的目标。
这个时候有人就会反驳说，难道没有引入OKR，你们就不思考价值？目标的制定肯定会思考，参考上一节，没有引入OKR的时候，目标是少数人在制定，大部分是自己说服自己，而引入OKR之后，目标是大家一起制定的，那么这个时候就需要每个人都要对目标进行思考。
如果你想要自己的目标脱颖而出，那你就要把你的目标的商业价值说的非常清楚，比如为产品提高百分之多少的日活，带来多少收入，节省多少开支。
目标制定聚焦于价值，也逐步改变了我们绩效评估的方式。以往我们绩效评估，看的是员工在一个绩效周期业务版本、上司任务的产出，员工被动接受任务；
随着我们对目标价值的追求，绩效评估也变得更为简单，考察员工在绩效周期内带来的价值即可，员工主动挖掘任务，解决团队最核心的问题。
3.团队高效协作
季度初设定了有挑战的目标，那么如何在季度末保证目标的关键结果达成呢？制定目标容易，难的是目标的达成。
从一个创意到可运行的产品或服务、再到让客户认可价值，然后客户开始使用，到最终愿意为之付费，整个过程的每个环节难度都在增大，每个环节都需要我们组建合适的团队来完成。
从前文中关于我们中心的介绍可看出，团队负责的业务形态不同，每个业务的优先级、重要性也不同，每个项目运行的周期都呈现出忙闲交替的现象，作为管理者通过什么手段来合理的调度人力资源？一个KR负责人评估当前KR完成需要的人力不足时该怎么办？一个团队战斗力爆表的成员，完成了自己负责的KR外还想做更多的事情怎么办？
针对上面的现象，我们建设了伙力平台：一个用于管理人力池、招募人才和认领任务的系统。我们期望能够通过这个平台解决上面的问题时，而此时面临的最大的问题，就是如何保证员工认领任务的积极性。
对于普通员工来说，需要走出舒适圈，面对不了解的需求，不熟悉的伙伴，本身就是一件非常具有挑战的事情，如果没有一个好的团队氛围，必然会导致意愿下降，没有人参与，没有人发布，恶性循环，最终流于形式。
得益于OKR的目标公开透明，和层层分解的思路，员工对组织目标有更加清晰的认知，对于共同目标的达成有更强的意愿。只有大团队的胜利，才能证明小团队的努力是有价值的，才能证明个人的努力是成功的。在这样共赢的氛围下，强化了人与人的信任和协作，弱化了内耗和竞争，伙力平台的能力得到了最大程度的发挥。
从伙力平台上线到现在一年多的时间里，一共发布了35个任务，共有72个同事申请，实现了408个人日的火力输出，不仅帮助我们协调了项目间的人力，更促进了团队共同成长，让优秀的人脱颖而出。不断的成功和胜利，让员工更加相信组织，相信队友，带来良性循环，实现了我们集中力量办大事的愿景。
4.浓厚的学习氛围
为了践行我们的核心价值观（学习是我们公司的核心价值观之一），为了更好的解决业务发展中的技术难题，同时也为了员工的自我成长，我们很有必要去营造一个浓厚的学习氛围。
作为一个管理者，建设一个学习型的团队是其工作内容的一部分，针对研发团队如何建设呢？通常的做法是：指定一个负责人，让其组织团队的成员轮流在固定的时间固定的场所给大家分享他的知识和经验，比如读书笔记，设计的方案，线上遇到的问题……。
既然有现成的模型可以照搬，那对于我们这样执行力强的团队来说，说干就干，于是我们制定了一个规则：每周四晚上七点半大家轮流进行分享。一周一次，轮流分享，团队的人也比较多，一年下来一个人也分享不了几次，从明面上看，这个任务完成的难度不是很大，负责人也是拍着那坚实的胸脯信心满满。
半年后的一天负责人突然说：不行了，分享搞不下去了，首先是没有子弹了（没有可以分享的内容了），库存已搬空；其实是参与学习的人也没激情了，很多时候参加的人数都少于5个人，既没有想分享的人，也没有想学习的人。问了下不参加的理由，有要紧急发版的，有要配合测试的，都有各自的说法。
如何解决没有子弹的问题？我们决定换一种分享模式试试，于是我们又组织了读书会，大家一段时间内一起阅读同一本书，一个月分享一次读书心得，分享的形式就是口述，这非常轻量化了，我们想这样大家应该能坚持下去吧。事实证明我们还是太天真，这次比上次的分享会坚持的时间还要短，就搞了几期然后就悄无声息的结束了。
在我们遇到OKR之后，形势反转了，我们把“营造快乐进取的学习型团队氛围”作为一个目标来跟踪，每个季度制定不同的KR来支撑O的达成。
在这种方式下，我们将原来的指派式转变为主动报名，同时OKR的目标牵引又能够让负责人专注于目标的执行和达成，学习的氛围发生了180°的大逆转，教与学变成了水到渠成的事情，很多新的思路和创意也在碰撞中产生。快闪分享、技术沙龙、源码领读、算法专题、读书会、好文分享等是中心内技术学习的专题活动，形式多样丰富，为中心内成员搭建学习交流平台。
5.持续的内部创新
当今世界，新技术、新产品、新服务、新模式层出不穷，传统商业模式面临颠覆性的挑战，创新是企业的灵魂，创新是企业发展的不竭动力，对于手机行业公司来说，创新将显得更为重要。对我们团队而言创新主要体现在新能力和新项目的孵化。
我们首先是通过OKR的目标牵引和激励策略，来培育创新土壤，鼓励创新。
众所周知，一个创意从诞生到落地，最大到难关是开始行动，99%的创意在行动之前就被自我扼杀了。所以我们需要建立鼓励创新、包容失败的氛围，降低员工踏出第一步的难度。
其次是聚焦创新目标，跟踪创新过程。
通过持续的激励，让员工能够有足够的动力去长期投入创新目标的完成；通过阶段性的对齐，让团队能够了解目前的进展和瓶颈，利用群体智慧来共同解决困难。以此来呵护创新萌芽的成长壮大。
最后是关注创新结果，保持正向激励。
因为创新这一目标，本身就是极具挑战和不确定性的，因此总结和复盘时，我们并不追求此OKR的完成度，而是以目标是否有价值、是否具备挑战性、员工是否付出足够的努力为衡量标准，即使最终这个KR没有完成，也并不影响到员工的绩效考核。在这样的理念下，保证了创新氛围的可信和持续，让创新变成一件水到渠成的事情。
三年来，在围绕着创新制定目标的牵引下，中心已经成功孵化出了6个组件和12个服务，在公司内部累计已经超过千余个系统使用，并且我们也在开源上面做探索，让这些组件和服务能为更多的人服务。
通过OKR实践，我们扭转了曾经“畏惧犯错，不敢失败，不敢试错”的氛围，打造“乐于创新，敢于突破，勇于挑战”的文化。
6.员工生产力提升
员工生产力的提升可以说是执行OKR科学管理的必然结果。OKR执行的一个特点：自下而上，即自主，是内在动机的一个基本心理需求。
OKR理念强调在目标设定时，要有相当一部分目标是员工自己提出来的，而不是上级指派的。只有这样，员工才会感知到目标是自己的目标，不是他人强加给自己的目标，从而显著增强对目标的承诺感，最终带来员工生产力的提升。
海外商城的建设就是一个很好的案例。最初海外只有印度市场提出建设官方商城的需求，我们只需将内销商城系统复制一套，并部署到印度当地即可，这种方法简单高效，但是我们并未止步于此.
当时我们预见到，海外其它市场需求也必将接踵而至，为了能够快速应对未来全球化业务的发展，我们做了充分的竞品分析、技术调研、架构设计、脑暴碰撞，经过一段时间的摸索和打磨，我们打造出了一套通用的全球化解决方案，包括多语言文案系统、多时区通用组件、多国家隔离框架、多机房域名部署方案等等，一套系统可满足多地区多品牌的需求，极大地提升了人效，在业务需求真正到来之时，可最快7天部署一套新商城。
这些能力较好的支撑了商城当前业务的发展需要，同时赋能其它外销业务解决相关难题，多语言平台还一举获得公司级设计驱动奖。
海外能力的建设，从设想到确立目标到落地，是员工自发自主自下而上去完成的，科技时代需要技术创新力，知识工作者需要突破既有经验和惯性束缚，OKR科学的管理机制给与了员工更大的发挥空间，生产力提升水到渠成。
以上是我们在引入OKR之后发生的六点明显变化，这些变化既是因也是果，它们互相形成了一个良性循环的飞轮，朝着我们的愿景：“持续成长为行业一流的技术团队，并打造出了一支自组织、高绩效的标杆团队”不断前进。
内容来源：
第1、6部分内容来源：简书，作者：Matt小特，链接：https://www.jianshu.com/p/896e8b1d4b28
第2部分内容来源公众号：逻辑思维，作者：得到高研院。第3、4部分内容作者：任向晖，任向晖：明道创始人，转载自公众号：小众消息。第5部分内容来源公众号：产品经理骆齐，作者：骆齐。第7部分内容来源公众号：vivo互联网技术，作者：vivo互联网平台产品研发团队。
以上内容版权均属于原作者，如有侵权，请联系删除。
全员培训网站源码分享和全员培训app的问题分享结束啦，以上的文章解决了您的问题吗？欢迎您下次再来哦！