微软和谷歌是如何对开发人员进行绩效考核的？或者说对于开发人员要如何考核绩效？

虎威将军

这是本人设计的一张项目管理流程图，供大家参考。

此图中，对于普通开发人员的考核是通过周计划、每日任务验收进行的，而对于项目负责人，则是通过项目周汇报和里程碑的达标率实现的。

期待大家批评指教。



原文地址：https://www.zhihu.com/question/20268132

队长是我

第一条 研发人员绩效考核激励方案设计
1． 公司基本现状及当前面临的主要问题
目前，企业面临的主要问题包括：
1） 产品开发要求不断增加，项目组不断增加，项目协调工作剧增
2） 维护工作和项目开发工作难以界定，项目计划难以准确制订
3） 原有的年终绩效考核已不再适应目前的开发任务要求，员工工作热情低落
4） 由于一人可能在多个项目中承担责任，项目中矛盾剧增
由此，企业管理层希望能通过改善绩效考核体系解决或缓解企业在产品开发中出现的问题。
2． 基于项目考核的公司研发人员绩效考核方案
根据企业项目开发的实际情况，以项目考核代替部门考核更适应企业现状，并易以实施制定项目考核方案。
第二条   项目团队整体考核方案
对于项目总奖金及项目团队各层面奖金总额，采用如下计算方案：
项目总奖金=P*B*项目合同成本
项目管理层奖金=50%*项目总奖金
项目成员奖金总额=50%*项目总奖金
项目成员个人奖金=S*项目成员奖金总额
在本方案中，b=(1~2)%，公司决策层将根据项目规模，项目难度等因素确定b的具体取值。
有关P,S的计算方案如下，
1． 项目团队考核实施
根据公司实际情况，项目团队考核具体方案如下所述：
l 考核目标：为了更好地强化研发项目管理，对已经立项的研发项目按照预定的项目
考核节点对项目整体完成情况进行考核，从而实现对整个项目团队的考核。
l 考核方案：表1


为了促进项目管理水平的提高，尤其是促进项目计划的准确性，方案对工时考核系数P1和项目总进度考系数P3分员设置了最高值1.5，1.2;另一方面，从研发和测试部门间均衡性出发，对项目完成质量系数设置最高值2。
上表中各系数权重值为(0~1),并保证如下等式：
W1+W2+W3=1
1． 考核频率
方案主要采用如下的考核频次：
1） 项目结项，并实现用户项目回款后进行
2） 按照公司认可的预设项目周期进行考核
第三条  项目团队个考核实施
  项目个人考核主要由项目经理完成，该考核应纳入公司整体绩效考核体系，并得到公司批准。具体实施方案如下所述。
l 考核目标：为了更好的完善研发中心项目管理和部门管理机制，保证研发项目的按期，高效，高质完成，并促进公司内员工自身的发展，特制订该考核方案。该方案将以项目考核为主要目标和主要方法。考核目确定由核心考核目标和辅助考核目标两部分组成。
l 考核指标体系：从考核方式的角度对该方案的实施，即指标体系进行说明。
从考核可操作性角度分析，方案将上述考目标按照指标的获得方式分为客观定量考核和主观定量考核，并希望通过随着公司研发项目管理的逐渐成熟，考核经验的逐渐累积，各考核指标可逐步采用客观定量考核获得，对于核心考核目标尤为如此。
受现阶段发展情况所限，方案中只有“工时考核”采用客观定量考核方法，具体公式参见下文。而对于辅助考核目标，则主要由项目经理或其他相关人员依据员工的工作表现，以主观评价打分方式获得。对于核心考核目标中的“完成质量”目标，目前因无法完全采用客观定量考核方法获得，则以主观评价为主，客观数据为辅的方式获得。各指标的具体计算方式如下。
1． 工时考核


说明：
i. C1=考核期间完成任务工时/考核工时/有效工时比例
ii. 考核工时：按照每天8小时计算的考核期间的完成标准工时
考核工时=8*考核期间考勤天数
iii. 考核期间完成任务工时= 项目工时 + 任务工时
项目工时：由项目经理根据在项目考核期内，项目成员完成的任务的核定工时，核定方法将采用经验法或类比法（即估算值）
任务工时：由部门经理根据项目成员在本月完成的非项目工作，如日常软件维护，软件变更，软件实施等部门安排的任务单工时，上述工作应以任务单为准。若任务工时包含必须通过加班方式来完成的任务，则该部分工时需乘以相应的加班系数。加班工时系数如下表所示：


好//了，篇//幅//有//限，/就//不//和//大//家一//一展//示//了，需要完整资料可以看主页或给我发消息

继续前进

OKR是目标管理工具，不是绩效管理工具，所以，说谷歌把OKR当成绩效考核工具，这种说法有那么点不靠谱的味道。
当然我们也不是微软谷歌，只是一个公司规模近200的，研发占一半的创业公司的玩法，仅供百人左右研发团队参考。



Worktile & PingCode的研发全景图

以上是研发管理全景图，是我们团队过去几年逐步形成的研发管理经验，其中主要包括以下内容：

• 研发管理的的核心是构建一个开放、自学习、自驱动的组织文化和仪式感，这是打造高效研发团队最内核的基础。
  
• 左边是工具和方法，主要包括：以OKR驱动的目标管理，基于Scrum的敏捷，和逐步完善的DevOps。
  
• 右边是制度和规则，核心包含：研发团队的绩效和考核、跨部门合作、其他仪式感驱动的各种规则，尤其是构建自学习的环境与分享机制。
  

上面的每一点都足以拿出来写一篇长文，这里我们只对研发场景下的OKR进行讨论。

要谈清楚方法，就需要先了解清楚问题，研发管理之所以令人头疼，核心的问题不外乎以下一些方面：
一、研发管理一直很难

1、研发团队的管理难题





难以KPI化与考核的工作
这在绝大部分公司都是非常难解决的事情，其中也包括Facebook、谷歌等著名企业，他们在这件事情上也都存在非常大的挑战和难度。
很多公司希望通过bug数，功能数，代码行数，跟公司营收绑定，看加班数等等来解决研发的KPI问题。但本质上来说，都没有从根本上解决研发如何去度量的问题，而是采用比较偷懒的方式试去图解决研发效率问题。
这样带来的结果肯定是事与愿违的，不管是代码、BUG数还是其他。比如说，如果因为BUG数太多，KPI就低的话，一线的程序员完全有方法尽量减少BUG，而减少BUG最有效的方法，就是减少在产品上的创新和对外输出，所以这些方法本质上和最终要达成的实际目标是相反的。
离代码很近，离用户很远

另外一个现实且无奈的问题是：工程师和产品经理好像是在象牙塔里做研发和产品，和用户往往离得太远太远。这种问题带来的伤害远比其他事情来得更加彻底，但本质上这是研发规则上没有解决好的问题，导致工程师本身并没有任何的动力去贴近用户和客户场景，而这又和前面聊到的目标有很深的上下游关系。
我们常常说要做用户喜欢的产品，但那些反人类智商的产品，往往是产品经理和工程师合谋的结果。如果说研发管理的目标是提高效能，那么首先同步研发团队朝着统一的目标，就是效能管理最重要的第一步。
因此，以什么样的制度去驱动研发抬起头来看客户场景，是一切研发管理的核心工作之一。
跨部门战争

因为低头干活，所以往往研发团队的目标和业务团队的目标并不一致，研发体系和业务体系的跨部门战争，简直罄竹难书：

业务认为：怎么这么多bug，一个小问题需要花这么久的时间才能修复。
研发认为：业务的智商不够用，这么好的产品就是无法准确传达给客户。
业务面对客户点头哈腰；而研发觉得客户是业务的客户，不是研发的客户。
业务对需求排期是12345；而研发对需求排期往往是54321。
业务给客户承诺就像谈恋爱，把星星摘下来也敢接着；研发认为你承诺的，你去写代码实现吧！
业务认为研发高工资吹着冷气，自己天天在外面跑晒太阳；研发认为，业务提成那么高，这产品是我做的，我咋没提成呢？

这种剪不断、理还乱的关系，是很多公司的普遍现象。跨部门的不理解，必然带来团队之间的内耗，信息的折扣和效率低下也自然产生。
跨部门战争更重要的影响是造成对客户服务与理解的偏差与推诿，没有任何公司或者团队能在一个不流畅的环境下成就对客户的100%满意度。
2、企业的普遍现状

对于大部分企业和团队来说，如何管理好程序员、Tester、Designer、产品经理、运维等整个泛研发组织和团队，怎么让效率提升，让目标非常好的执行，本质上都是一件很难的事情。
我们曾对很多客户团队做过这样的小测试，测试的内容是让大家投票选出公司最重要的三个目标，当然，其中会混淆6-8个不那么重要的目标。
而大家选出的TOP3 目标往往和公司最高层认为的三个目标有巨大的差异。
这表明了什么呢？
研发管理本质上为了提高研发效能，让团队执行效率、公司的发展速度可以更快。但这个测试结果暴露出的是企业管理上存在的一个本质问题：如果企业管理层、中层和执行层在公司的目标上都还存在巨大分歧，哪怕你团队的执行效率非常高，程序员能力素质非常好，但由于大家并不朝一个方向去努力的，最后产生的合力其实是被稀释的。
这也就意味着，要解决研发管理和研发效能问题，首先应该让大家对目标的认知是统一的。如果一致性都不存在，这个团队就很难说是一个高效的团队，也很难去用其他方法，无论是敏捷Scrum、Kanban、瀑布，还是任何一种研发管理方式去解决这个根本问题。
而如果大家的目标是统一的，这个团队就未必需要OKR，如果不一致，甚至存在南辕北辙的现状，那OKR一定能帮你改善这个现状。

在前面两小节，我们大概的总结了研发面临的各种主要问题，这也是Worktile & PingCode过去遇到的问题和场景。但因为有“遇到问题就试图解决这个问题”这样一些价值观。于是我们自己就有各种折腾，这其中就包括OKR在研发团队的推行。
在2015年我们就已经开始落地OKR，前后有三次内部推进的尝试，其中至少有两次是失败的，整个过程充满了很多挫折和所谓的坑，但我们始终认为这件事情本身是有价值的。后来也因为逐步的尝试和积累，以及和客户的共创，我们的收获越来越多。并且在2017年将OKR以工具的形式在Worktile落地，随后在PingCode落地。经过逐步的发展，2018年我们开始对外提供一些布道。
目前我们已经为500多家企业客户提供OKR的咨询服务，有1000多家企业在使用Worktile & PingCode的工具进行OKR目标管理。

研发OKR的实例

如果要在公司落地OKR，你很大概率遇到的第一个挑战是：团队似乎从来没思考过目标是什么。第二个挑战是不知道如何写出正确的O和KR。
第一个难点可能在公司高层决定支持后就解决了，但写出正确的O和KR会是一个长期且非常大的挑战。如何正确的写OKR也是一个大大的话题，这里我们只通过几个案例给大家进行展示。(具体的方法论大家可以通过这个知识库了解：OKR从认知到落地)
比如谷歌现在的CEO，他曾定过一个非常简单的OKR，O：创造世界上最好的浏览器；第一年的KR1：用户数超过2000万；第二年的KR1：用户数超过5000万；第三年的KR1：用户数超过一亿。



站在当时来看，这个目标看起来非常有挑战并且不可实现。
在实现的过程中，第一年只有约2百万的达成，第二年约3千万，但是第三年整个Chrome浏览器的用户达到了1.2亿。所以回过头分析，我们能发现，OKR不是KPI化的东西，如果把它变成KPI，这位CEO可能在第一年就已经从谷歌离职了。
而且，谷歌团队当时基于这个目标往下延伸子目标的时候，定的一个KR是：Chrome浏览器渲染速度达到IE的10倍以上。这看起来也是非常难以实现的目标，但在目标周期结束的时候，Chrome引擎的渲染速度大概是IE的56倍。
因此，某种意义上说，OKR还具备非常大驱动能力，能够激活整个团队，并朝着有挑战性的目标不断往前进。
说完谷歌的例子，我们再来看一些典型的Tech Lead案例




这是技术负责人比较常见的两个目标，比如第一个“确保V7.3，高效按时发布”是目标O，这个目标的两个关键点就在于诠释什么是按时，什么是高效，下面的KR就是围绕这两个点去支撑目标。
Engineer案例


一线工程师常见目标，可能是具体交付某个东西的增长，实现日活增长等一些事件。在OKR的定义上也和Tech Lead案例并无差别，所以通常情况下我们也说O是定性的，KR是定量的，KR辅助大家更好的理解O。
前面几个小节主要是从不同层级视角去看目标是如何定义的，有一个大致概览体验。接下来，回到OKR和研发在Worktile & PingCode 团队的实践。
三、Worktile&PingCode是如何利用OKR来解决研发管理问题的

从我们落地OKR的这几年来看，OKR对于解决研发管理问题，至少达成了两个非常重要的意义，第一是研发团队内部的目标对齐。第二是驱动研发部门、业务部门、职能部门，实现更好的沟通和融合的机制，这也是更重要的一点。
就比如我们在PingCode打造的时候曾定过一个目标是“成功发布智能化研发管理工具PingCode” ，在这个目标和关键结果定义好之后，研发团队和业务团队就要根据它产出自己团队的子目标。
研发团队“高质量的完成产品研发”
销售团队“提高全员对PingCode产品的认知”
客户支持团队“提供有价值的测试客户的反馈”
......
各团队子目标都是用以支持上面“成功发布智能化研发管理工具PingCode”这一大目标的。


1、改善跨部门战争

因此，要实现成功发布PingCode这个目标，在公司内部团队之间就要思考、沟通、达成一致的一个基本标准是：什么是成功发布。
比如上线一周新增DAU达到多少；从免费到付费的转化率达到哪个指标；NPS要大于多少；用户反馈的严重BUG少于多少个等，才算成功？
这样目标就落地到一个个具体的KR，而背后支持这几个KR达成的不一定都是研发人员，比如NPS它一定要涉及客户支持部门，付费转化一定要涉及销售或者市场部门等等。因此从O到KR实现的过程就需要不同的团队去承担相应的职责。
目标逐步往下分解，一个个子目标的产生就是不同团队负责人为上面的目标承担职责的过程。但这并不是目标量化分解工具，它是一个目标达成从上而下对齐的过程。
比如：研发团队的目标是“高质量完成PingCode的研发”，定义出来的关键结果是“编写80%以上的测试用例”、“提前两周在内部能够上线6个应用模块”，也就是说，研发团队需要提前两周完成内部测试等过程，才能保证这个团队对目标的支持。




对于跨部门来说，比如“提高全员对PingCode产品的认知”，因为大家共同认为成功发布的一个标志是整个公司内部，尤其是业务线的同事对新的产品价值、功能有很清晰的认知。那业务部门就会为了“成功发布”这个目标，驱动整个销售部门去定义自己的子目标，比如是”95%以上的销售成员要通过新产品的考核“、”编写完整的产品销售解决方案“等等。


在整体的目标定义之后，研发和业务部门对这个目标有一个对齐的过程，自然就实现了跨部门对一个目标统一协作的过程，这个过程中建立的跨部门沟通融合机制和目标价值的统一，在一定程度也缓解了跨部门战争的频发现状。
2、OKR和敏捷开发的结合——研发内部目标对齐

Worktile & PingCode研发管理结构

• 战略层
  

这张图展现的是我们Worktile & PingCode团队在OKR和敏捷开发实践过程中结合的经验梳理。在最上层的是公司愿景、目标（战略层），这本质上是OKR要解决的问题，通常是公司管理层要关注事物。它的周期相对较长，可能是一年或者数年，之前谷歌案例就是三年的长周期目标。

• 项目层
  

公司战略级目标往下去落地，就会到项目级的这一层，这是研发和产品的管理层需要去关注的。
从OKR（也就是公司的战略级目标）延伸下来就是Plan一级，Plan一级是通过研发三层需求来定义的（史诗、特性、用户故事）。我们会在史诗和特性这一层定义研发和产品管理相对中周期的项目，比如说史诗用季度定义，特性则是对应月度。这样就实现了从战略层到产品层，目标逐步往下传递对齐的过程。在工具层面，我们是用PingCode Plan （项目集）来管理Plan这一层的。

• 执行层
  

具体到执行这一层，我们通过PingCode Agile（敏捷开发管理）这个产品去实现短周期项目的落地，比如我们会把一个特性分解成具体的用户故事去往下落地，这一部分在产品组的周期大概都是几天。当然，过程中产生的bug和工程师所要执行的任务，在工具层也都是通过PingCode Agile 产品去落地。
具体研发过程

研发过程我们通常是通过Scrum执行，具体负责的可能包括工程师、测试、设计师和产品经理等，在这里，项目的颗粒度会变的更加具体，比如0.5个工作量周期等。
我们在研发管理的过程中，会把OKR从战略层落到项目层以及执行层，最后往下分解到基于Scrum管理的具体研发过程，从上到下形成一个完整的连接，并且与前面所提到的工具化结合形成一个完整的格局。


OKR驱动研发，我们内部只是落地到部门级，因为考虑到整个体系如果不够完善的时候，落地到个人级反倒会增加很大成本。因此我们只落到部门级，在部门下我们是通过敏捷的方法，以特种部队的小组形式去管理。
在敏捷方法中有个概念是迭代周期，我们的迭代是双周；OKR也有周期复盘的制度，而我们的OKR是以月来定义周期。因此两个迭代刚好能对应一个OKR的周期，这两个周期的匹配也能够驱动整个OKR目标和整个迭代的往下延伸。这也是目标在整个研发组织内部对齐的过程。
OKR并不定义所有的工作，它只会定义最核心的关键点。也正是因为这点，我们通过OKR尤其是KR去优化产品的backlog的优先级。举个例子，比如说在一个周期里，其中一个KR可能涉及产品功能的迭代，而在研发的backlog中它的优先级并不是最高。从某种意义上来说，OKR的定义会修正backlog的优先级，通常在机制上Scrum Master和OKR Master会做一定的复盘，来实现整个目标的对齐和修正。
在复盘会议，我们会同时打开OKR目标树和Scrum的看板，基于这两个图开展复盘会议，去落地目标和整个敏捷迭代。
用一句话来总结就是：大方向由OKR保证并且影响优先级，小迭代和任务计划基于敏捷的原则执行，OKR+Scrum是极其有价值的组合工具。当然，仅仅是OKR也只是解决一部分研发管理的问题，就像开头的那张图，除OKR之外，我们还配套360度考核、特种部队、职级等方式来解决研发管理的问题。
最后一点

无论你想要落地OKR还是敏捷Scrum，善用过程和目标管理工具都是十分有必要的，因为专业的工具对团队本身来说都是极有价值的，比如你要去落地OKR，通过Excel或者是Google Docs，在整个公司目标透明化、目标分解、打分、与项目任务关联等等，整个过程都会面临比较大的挑战。
配备专业化的工具是解决这一问题的不错选择，就比如研发管理工具PingCode；
在【需求拆解、编写说明、跟踪项目、测试记录】上（PingCode Agile搞定），【文档管理】（PingCode Wiki）、【OKR管理】PingCode Goals 搞定；还包含【源码管理】（gitlab,github,svn搞定）,【部署管理，持续集成】(Hudson搞定)
所以是从用户需求收集到代码落地、产品发布覆盖整个研发流程的管理，而这对管理层实现研发管理的工具化、数据化以及可视化，都是极有价值的。
附上链接：PingCode

同花顺

本人在这两个公司都做过开发。
微软：级别低的，看老板对你的感觉，级别高的，看number（用户量，利润，性能提升比例。。）
谷歌：级别低的，看周围人(peers)对你的感觉。级别高的，看number.
没人真正关心日报周报季报。本人从来不写这些玩意，OKR从来不鸟.

同花顺

不过什么考核形式，最主要的适合于这个岗位
我原来对开发岗位也类似于这种模式考核，后来发现考核最主要的不是这个流程，也不是考核里面的指标
而是真正评估被考核人的上级
只有其上级在每一阶段真正起到管理的作用，及时评价与反馈，这个才能真正起来绩效管理的作用。
不能流于形式

长长的路

关于这一点我非常赞同周思博同学的观点，虽然是10多年前提出来的，但是我觉得非常正确：
有害的薪酬激励

他总结道：“激励（或者贿赂）在工作场所就是没用”。 把Demarco和Lister进一步指出：任何形式的工作场所的竞争，任何奖励和处罚计划，甚至那种传统的老式的“发现某人做对一件事情了然后奖励他们，” 统统弊大于利。给一些人积极反馈（就像那些傻X公司给员工颁牌匾一样）暗示着说他们就是为了那块东西才那样做的； 暗示着如果不给他们点儿什么饼干的话他们就没办法独立工作； 这就是贬低和侮辱。

大多数的软件经理没有选择，他们只能接受公司现有的这套绩效考评系统。 如果你正处在这个位置上的话， 要避免团队自杀的方法就是给团队里每个人都杠杠的评价。 但是在这个问题上如果你有选择的话， 我建议你里任何形式的绩效考评， 绩效奖金， 或者是愚蠢的每月员工计划之类的项目远远的。