本文由 简悦 SimpRead 转码， 原文地址 www.zhihu.com
anytao
anytao分享一些我们研发团队管理的方法，不完全针对绩效管理，所以这可能不是一个合格的回答，但本质上还是围绕研发团队的目标管理，解决研发工作的有效性和效率方面。
我司规模近 200，研发占一半多创业公司 Worktile，仅供百人左右研发团队参考。
（正文开始）
很多人可能以为研发团队的管理和协作比销售和业务简单很多，而实际情况是……. 格子男们并不那么容易管理，面向代码世界的复杂度，可能远比面向现实世界的复杂度还要高。
作为致力于团队协作的公司，我们研究了很多国内和海外牛逼公司的研发模式和研发管理，例如 OKR 在谷歌、Facebook 的应用，Uber 的高效会议制度，阿里的绩效体系，腾讯的产品流程。 除了在自身团队做了 N 次不同的试验和反思，我们将很多不错的经验分享给用户，并收到不错的反馈。
要谈清楚方法，就需要先了解清楚问题，研发管理之所以令人头疼，核心的问题不外乎以下一些方面：
1、研发团队的管理难题
- 难以 KPI 化与考核的工作
这在绝大部分公司都是非常难解决的事情，其中也包括 Facebook、谷歌等著名企业，他们在这件事情上也都存在非常大的挑战和难度。
很多公司希望通过 bug 数，功能数，代码行数，跟公司营收绑定，看加班数等等来解决研发的 KPI 问题。但本质上来说，都没有从根本上解决研发如何去度量的问题，而是采用比较偷懒的方式试去图解决研发效率问题。
这样带来的结果肯定是事与愿违的，不管是代码、BUG 数还是其他。比如说，如果因为 BUG 数太多，KPI 就低的话，一线的程序员完全有方法尽量减少 BUG，而减少 BUG 最有效的方法，就是减少在产品上的创新和对外输出，所以这些方法本质上和最终要达成的实际目标是相反的。
- 离代码很近，离用户很远
另外一个现实且无奈的问题是：工程师和产品经理好像是在象牙塔里做研发和产品，和用户往往离得太远太远。这种问题带来的伤害远比其他事情来得更加彻底，但本质上这是研发规则上没有解决好的问题，导致工程师本身并没有任何的动力去贴近用户和客户场景，而这又和前面聊到的目标有很深的上下游关系。
我们常常说要做用户喜欢的产品，但那些反人类智商的产品，往往是产品经理和工程师合谋的结果。如果说研发管理的目标是提高效能，那么首先同步研发团队朝着统一的目标，就是效能管理最重要的第一步。
因此，以什么样的制度去驱动研发抬起头来看客户场景，是一切研发管理的核心工作之一。
- 跨部门战争
因为低头干活，所以往往研发团队的目标和业务团队的目标并不一致， 研发体系和业务体系的跨部门战争，简直罄竹难书：
业务认为：怎么这么多 bug，一个小问题需要花这么久的时间才能修复。
研发认为：业务的智商不够用，这么好的产品就是无法准确传达给客户。
业务面对客户点头哈腰；而研发觉得客户是业务的客户，不是研发的客户。
业务对需求排期是 12345；而研发对需求排期往往是 54321。
业务给客户承诺就像谈恋爱，把星星摘下来也敢接着；研发认为你承诺的，你去写代码实现吧！
业务认为研发高工资吹着冷气，自己天天在外面跑晒太阳；研发认为，业务提成那么高，这产品是我做的，我咋没提成呢？
这种剪不断、理还乱的关系，是很多公司的普遍现象。跨部门的不理解，必然带来团队之间的内耗，信息的折扣和效率低下也自然产生。
跨部门战争更重要的影响是造成对客户服务与理解的偏差与推诿，没有任何公司或者团队能在一个不流畅的环境下成就对客户的 100% 满意度。
2、企业的普遍现状
对于大部分企业和团队来说，如何管理好程序员、Tester、Designer、产品经理、运维等整个泛研发组织和团队，怎么让效率提升，让目标非常好的执行，本质上都是一件很难的事情。
我们曾对很多客户团队做过这样的小测试，测试的内容是让大家投票选出公司最重要的三个目标，当然，其中会混淆 6-8 个不那么重要的目标。
而大家选出的 TOP3 目标往往和公司最高层认为的三个目标有巨大的差异。
这表明了什么呢？
研发管理本质上为了提高研发效能，让团队执行效率、公司的发展速度可以更快。但这个测试结果暴露出的是企业管理上存在的一个本质问题：如果企业管理层、中层和执行层在公司的目标上都还存在巨大分歧，哪怕你团队的执行效率非常高，程序员能力素质非常好，但由于大家并不朝一个方向去努力的， 最后产生的合力其实是被稀释的。
这也就意味着，要解决研发管理和研发效能问题，首先应该让大家对目标的认知是统一的。如果一致性都不存在，这个团队就很难说是一个高效的团队，也很难去用其他方法，无论是敏捷 Scrum、Kanban、瀑布，还是任何一种研发管理方式去解决这个根本问题。
而如果大家的目标是统一的，这个团队就未必需要 OKR，如果不一致，甚至存在南辕北辙的现状，那 OKR 一定能帮你改善这个现状。
**(具体的 OKR 推行的方法论大家可以通过我们这个内部的知识库了解：** )OKR 从认知到落地
二、Worktile&PingCode 是如何利用 OKR 来解决研发管理问题的
以上是研发管理全景图，是我们团队过去几年逐步形成的研发管理经验，其中主要包括以下内容：
研发管理的的核心是构建一个开放、自学习、自驱动的组织文化和仪式感，这是打造高效研发团队最内核的基础。
左边是工具和方法，主要包括：以 OKR 驱动的目标管理，基于 Scrum 的敏捷，和逐步完善的 DevOps。
右边是制度和规则，核心包含：研发团队的绩效和考核、跨部门合作、其他仪式感驱动的各种规则，尤其是构建自学习的环境与分享机制。
上面的每一点都足以拿出来写一篇长文，但这里我们不做过多的扩展，只对研发场景下的 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 的看板，基于这两个图开展复盘会议，去落地目标和整个敏捷迭代。
以上基本就是我们 Worktile & PingCode 在落地 OKR 和敏捷的一些过程和经验。用一句话来总结就是：大方向由 OKR 保证并且影响优先级，小迭代和任务计划基于敏捷的原则执行，OKR+Scrum 是极其有价值的组合工具。
当然，无论你想要落地 OKR 还是敏捷 Scrum，善用过程和目标管理工具都是十分有必要的，因为专业的工具对团队本身来说都是极有价值的，比如你要去落地 OKR，通过 Excel 或者是 Google Docs，在整个公司目标透明化、目标分解、打分、与项目任务关联等等，整个过程都会面临比较大的挑战。
虽然这里有打广告的嫌疑，工具本身就是极有意义的东西。PingCode Goals 作为国内首款面向研发团队的 OKR 管理工具，除了能解决上面提到的问题，还具备提醒机制，能够协助团队自动养成目标进度更新的习惯，以及建立起目标管理的标准流程。
除此之外，PingCode Goals 的优势还在于与 Agile（敏捷开发）、Testhub（测试管理）、Plan（项目集）、Wiki（知识库） 等子产品，覆盖从用户需求收集到代码落地、产品发布整个研发流程的管理，而这对管理层实现研发管理的工具化、数据化以及可视化，都是极有价值的。
当然，要解决研发管理的问题仅仅是 OKR 这些东西肯定是远远不够的，就比如说，我们还有 “特种部队” 机制，研发下乡，技术委员会，打造开放的组织的文化…..
推荐阅读：
1、研发团队管理：一种广泛存在于谷歌、小米、阿里等公司的研发组织架构设计 - anytao 的文章
2、敏捷开发：我们团队从 8 人到百人的敏捷之路 - anytao 的文章
白起
量化管理只能适用于竞争激烈而合作少的场合，比如劳动密集型的手工制造。
对研发团队进行细致的量化管理，既不现实，也无必要。
研发团队靠的是成员之间互相配合，更多是合作关系，并非竞争关系；量化管理强行抹煞了合作关系，刻意强化竞争关系。须知整体并非部分之和，研发团队是不可拆分的－－你能把一个人的不同器官拆开，讨论手的贡献大还是脚的贡献大吗？真的讨论出一个结果来，又有什么意义？手和脚如果能分家了，这还是一个人吗？同样，如果程序员、策划真的能够单独考核，他们为啥还要呆在团队里面，为啥不去独自创造价值？那，团队还是团队吗？
为了提高效率，出发点可以理解，但是更应该着眼于如何帮助成员合作，帮助成员沟通 (大部分人并不擅长沟通)，鼓励成员沟通。就我所见到的绝大部分情况，成员不做事或者进展缓慢并不是因为压力不够，也不是因为没有激励，也不是因为想偷懒；而是因为缺少沟通，工作上确实遇到障碍了。只要帮他们扫清障碍，他们就会很开心的继续前进。
如果你是一个 HR, 那么量化管理是一个免不了的任务，就随随便便走走形式吧，不要当真。如果你是团队负责人，就把精力更多花在沟通上，比花在考核上效果要好得多。
另外，也同意 bluepy 的看法，量化指标是可以的，但是不要用来做考核。量化指标是用来衡量整个项目状况的，好比体检时候的指标，看到指标异常就可以引起警惕，去看看到底有没有问题了。
张诚阳同学提问的进度报表，时间周期之类的，是另外一个很复杂的问题了，这里只简单的说说。
进度上通常分为几个里程碑。但是每个里程碑的要求，一定是对项目整体的评估，而不是分解后工作任务的累积；须知整体并非部分之和，并不是分解下来的工作凑到一起就成了完整的项目了；这中间有大量的集成整合的工作，评估一定要评估集成之后的整体项目。关于整体项目，很容易弄出很多量化指标，只要记着 “整体并非部分之和” 这一点就行了，那种累加出来的指标是靠不住的。
盐选推荐关注个人成长而不是评分和奖励，以此改善绩效
在《辛普森一家》动画片中有一集名为「家长–教师协会解散」（The PTA Disbands），剧中春田镇小学老师罢工，抗议学校在薪水、教学用品和食物上的投入太少。学校停课，孩子们都只能各干各的事情。有一些孩子整天玩游戏，另有一些到处捣蛋。二年级的丽莎 · 辛普森惊慌失措：
丽莎：但是如果没有州里批准的大纲和标准化测试，我的学习就要完蛋了。 玛姬 · 辛普森（丽莎的母亲）：亲爱的，或许你应该放松一点儿。 丽莎：放松？我不能放松！也不能放弃，缓和或…… 我只能想出两个同义词？我的天啊！我变笨了！ 玛姬：好吧，最后你会发现没什么的。几天之后，丽莎的状况变得更糟了： 丽莎：快看看我！给我评评分，给我排个名！我很好、很好、很好，啊我太聪明啦！给我评评分！ 玛姬：荷马，我有些担心孩子。丽莎有点儿神经质了。今天早上我撞见她撕坏了自己的雨衣。
我们每个人身上都有些许丽莎 · 辛普森的影子。小时候我们按高矮排队。有人给我们评分，告诉我们哪些行为属于出众的、令人满意的或是需要改进的。等我们长大一些，就会在班级里排名，与全国的平均水平做比较。我们申请大学的时候，会仔细考虑每一所学校的排名。我们生命的头 20 年都在与他人比较。
等到我们成年之后，再创造的工作环境也与之类似，这也就一点不奇怪了。这就是我们所了解的。
谷歌也未能免俗。我们需要员工了解自己的表现，而我们的考评体系也从最初复杂得有些滑稽逐步得到改善。一路走来，我们有很多惊人的发现。你们可以看到，我们仍在继续努力，但是我相当自信我们走的方向是对的。运气好的话，我可以帮助你们避免前进路上一些头痛的事情和走一些弯路。
服输
今天的绩效管理体系最大的问题在于它们替代了切实管理员工的关键行动。密歇根州立大学的心理学博士伊莱恩 · 普拉克斯现任该领域的顶级咨询公司 PDrI 主席，她发现「这个问题有一个关键，绩效管理降档为一些指标，经常在规范的行政体系下变得支离破碎…… 尽管正式的绩效管理体系本意是要推动…… 公司期望沟通、短期目标设定和持续性指导等日常活动…… 但是这些行为似乎已经与正式的体系偏离了很远」。[1]
换言之：多数组织采用的绩效管理都成为墨守成规的官僚流程，不是为了改善绩效，而是为了管理而管理。员工恨它，经理恨它，就连人力资源部也恨它。
关注过程而不关注目的，使狡猾的员工有了机会钻这个体系的空子。我曾经共事过的一名销售部主管唐（尽管这不是他的真名）在我们做评级、确定分红前的三个月就会开始来我的办公室。每年 10 月，他就开始做铺垫。「今年很困难，但是我们的团队非常努力，渡过了难关。」唐会这样汇报。到了 11 月，他会再次更新状况：「销售的伙计们的表现超出预想，逆势而上。」到了 12 月，我们就会听到一些详细的汇报：「小型商业团队已经完成了 90% 的任务，但是老兄，这个团队真是像英雄一样才赢得了这些订单。还要顺便说一句，我真不敢相信一月份时竟然会定下这么疯狂的目标。简直不可能完成！」
我一直都没有意识到唐在耍花样，直到后来有一年，我们决定将分红的时间比往常推后一个季度，但是没有告诉唐。他提前 6 个月开始铺垫谈判。坦率地讲，他这种行事方式也是他能成为一名优秀销售人员的原因，但是这段插曲也使我认识到体系中耍花招的程度有多严重。
事实上，没有人喜欢当前的绩效管理状态。薪酬协会（WorldatWork）和希博森咨询公司（sibson Consulting）调查了 750 位高级人力资源从业人员，发现接受调查的人群中 58% 给自己公司的绩效管理体系评出了 C 或更糟的成绩。只有 47% 的人感觉这个体系有助于组织「实现战略目标」，仅有 30% 的人感觉员工信任这套体系。[2]
面对这种情况，时下常见的反应是妥协。