百人研发团队的难题：研发管理、绩效考核、组织文化和OKR

什么是研发团队？简单的说，你熟悉的那帮穿格子衬衫，以步伐员为焦点构成的团队，就是研发团队。
原来，你以为格子男们是很乖很闷骚的那种，管理和协作起来比贩卖和业务简单很多，而现实情况是，格子男们并不那么轻易管理，面向代码天下的复杂度，大概远比面向财物天下的复杂度还要高。

作为致力于团队协作的公司，我们研究了很多国内和外洋牛逼公司的研发模式和研发管理，比方OKR在谷歌、Facebook的应用，Uber的高效集会制度，阿里的绩效体系，腾讯的产物流程。

除了在自身团队做了N次差异的试验和反思，我们也想将很多不错的履历分享给用户。要谈清楚方法，就先相识清楚标题，研发管理之以是令人头疼，焦点的标题无外乎以下一些方面。

研发管理的典范标题

1. 难以KPI化和稽核

任正非有句名言：钱分好了，管理的大部分标题就办理了。我对此深表同意，可标题是，怎么能分好钱确实非常检验本领、履历和智力的。研发之难，恰恰难在无法KPI化工作本身，全部那些试图KPI化工程师和码农的做法，最闭幕果都啼笑皆非、面貌可憎、吃力不讨好。

在我已往履历，另有客户现实的研发管理里，试图KPI化研发工作不绝是差异团队积极的实验，包罗和不限于以下方式：

• 办理Bug数
• SLA
• 功能完成度
• 加班，007就比996牛逼，996就比955更值得夸奖
• 营收捆绑
• NPS

这些看起来可以数字化的指标，除了证实研发管理者通过偷懒的方式做绩效稽核外，可以说毫无代价，也无法给公司和构造带来正向的鼓励。

2. 离代码很近，离用户很远

别的一个现实且无奈的标题是，工程师和产物司理似乎是在象牙塔里做产物和研发，和用户通常离得太远太远。这种标题带来的伤害大概远比其他变乱来得更加彻底，但本质上这是研发规则上没有办理好的标题，导致工程师本身并没有任何的目的和动力去贴近用户和客户场景。

我们常常说要做用户喜好的产物，但那些反人类智商的产物，通常是产物司理和工程师同谋的结果。如果说研发管理的目的是进步效能，那么起首同步研发团队朝着同一的目的，就是效能管理最紧张的第一步。

因此，以什么样的制度去驱动研发抬起头来看客户场景，是统统研发管理的焦点工作之一。

3. 跨部分战役频发

由于低头干活，以是通常研发团队的目的和业务团队的目的并不是划一的，研发体系和业务体系的跨部分战役，简直罄竹难书：

• 业务以为，怎么这么多bug，一个小标题须要花这么久的时间才气修复
• 而研发以为业务的智商不敷用，这么好的产物就是无法正确转达给客户
• 业务面对客户颔首哈腰；而研发以为客户是业务的客户，不是研发的客户
• 业务对需求排期是12345；而研发对需求排期通常是54321
• 业务给客户允许就像谈爱情，把星星摘下来也敢接着；
• 研发以为你允许的，你去写代码实现吧
• 业务以为研发高工资吹着冷气，本身天天跑在表面晒太阳；研发以为，业务提成那么高，这产物是我做的，我咋没提成呢

这种剪不绝、理还乱的关系，是很多公司的广泛征象。由于跨部分的不明确，一定带来团队之间的内耗，信息的扣头和服从低下天然产生。而更紧张的影响是跨部分战役造成对客户服务与明确的弊端与推诿，没有任何公司大概团队能在一个不流通的情况下成绩对客户的100%满足度。

那么怎样办理以上标题呢？

从研发管理全景图提及

下面的研发全景图，是我们团队已往几年渐渐形成的研发管理履历，此中重要包罗以下内容：

• 研发管理的的焦点是构建一个开放、自学习、自驱动的构造文化和仪式感，这是打造高效研发团队最内核的底子。
• 左边是工具和方法，重要包罗：以OKR驱动的目的管理，基于Scrum的敏捷，和渐渐美满的DevOps。
• 右边是制度和规则，焦点包罗：研发团队的绩效和稽核、跨部分互助、其他仪式感驱动的各种规则，尤其是构建自学习的情况与分享机制。

打造开放与竞合的构造架构和文化

一个构造要抖擞活力、自驱动、任务必达的信心，开放而透明的文化是绩效管理的核武器。总体来说，不管你的方法和制度多么丰富和美满，无论怎样也不大概驱动僵化、枯燥、没有活力的团队产生极其高效的代价。

以是，我们在谈研发效能的时间，注意力总会合在别人家的团队是符合管理的，而忽略了团队激活的焦点起首是塑造超强自由度、透明度和任务感的团队文化。

从服从这个角度去看，没有透明度的提效都是打扣头的，在一个构造里服从低下的重要缘故因由并不是实验力，而是透明度。须要层层审批和报备的构造，设定层层关卡和信息围墙的团队，服从肯定好坏常低下的，单点的实验力提升并不改变整个团队的低效基因。

以是，打造开放与竞合的构造架构和文化，至关紧张。

1. 特种队伍

怎样计划研发团队的构造架构，是个大大的思考题。我们团队履历过好反复差异的构造形态，也常常性的将研发团队举行构造调解，简单说，一个研发团队的脚色重要是以下几类：

• 产物司理
• 计划师
• 服务端工程师
• 前端工程师
• 测试
• 其他

以什么样的构造方式调配以上资源，是个非常检验团队管理的变乱，比方很多公司会将计划团队作为完全独立的部分，其他团队和项目按需调配计划资源，计划团队就像公司的乙方脚色，通过资源调配来匹配实验。

而另一种形态则是广泛存在于Facebook等互联网公司的方式，计划、产物司理、开辟、测试构成短小干练的特种队伍，在研发团队中以小组形态组合，就像一个研发业务的接口一样，有清楚的输入和清楚的输出，有清楚的目的和清楚的边界。

显然，打起仗来，特种队伍方式的小组，从实验到目的都是超等刁悍的，也同时能方便研发构造绩效稽核的落地与鼓励。

特种队伍的另一个利益是，每个小组的职能和目的是固定的，在产物研发大架构下实验一个准确的目的和单元。但小构成员可以转岗大概调配到其他小组，从而制止了研发职员的枯燥和无寻衅的标题。

2. 仪式感

仪式感是团队管理的调味品，也是必须品，就像你用饭离不开盐一样。研发团队管理者，比方CTO脚色的人，须要故意识的在团队中计划有代价的仪式感，来增长团队磨合、默契与调味。好的仪式感，就像宗教仪式一样，能不绝增强团队目的的实验、文化的塑造以及阶段的鼓励。

比方，我们本身团队就有很大仪式性的东西在实验：

• OKR的阶段同步
• 把巨大版本发布变成研发团队的阶段鼓励
• 管理层的固定One One访谈
• 研发职员的每月访谈，同步到公司月报
• 花心思的团建
• 每月的产物稽核
• 师徒制
• 走出去，加入各种外部的技能大会
• 。。。

另有很多其他的仪式和规则，而且以上险些每个规则都值得拿出来说道说道。

3. 用户体验委员会

在Worktile团队，我们创建了构造架构之外的一些假造构造，假造构造的计划可以很好办理跨部分沟通与信息同步的标题，以用户体验委员会为例，将公司里研发、计划、产物、贩卖、客户乐成的同事构成一个假造委员会。

委员会主席本质上就是这个构造的秘书，通过定期的集会大概讨论，将办理用户体验上的标题作为焦点目的来办理。委员会的茶话会，每次都能高效推进很多方面的变乱：

• 就用户体验的巨大标题充实讨论，产物和研发从差异视角收听意见，贩卖和客户乐成更多代表了来自一线用户的发起。
• 促进跨部分的相互明确，很多时间跨部分的战役，来自于相互的不明确和看不起。比方，我们在某次茶会中，就一个很久以来的焦点需求做了讨论，贩卖端原来以为是一个简单的需求，结果讨论下来发现，这个简单需求着实在客户方也有非常差异的明确，完全颠覆了产物已经草创的计划方案。反过来，贩卖同事也完全明确了为何产物方案是云云之难的缘故因由。
• 指定举措方案，快速驱动产物研发落实改进方案。用户体验委员会不是只讨论，更紧张的是驱动举措方案，快速办理用户关心的体验标题。

4. 技能委员会

同样在研发团队，我们通过技能委员会来实现跨研发团队的技能沟通、分享和技能选型。技能委员会包管了公司始终以科技驱动贸易的底子不被稀释，汇聚团队中技能本领最强的圈子更加自驱动的投入技能贡献，重要的工作目的包罗：

• 公司级的技能方案
• 前沿技能研发小组研发岗的职级评审，技能委员会负担对技能本领的职级评估
• 驱动公司技能进步和学习，比方构造黑客马拉松、技能分享、对外技能输出
• 向市场和贩卖输出技能内容研发下乡

5. 研发下乡

就是让研发走向客户，贴近客户需求，相识客户状态，然后返来美满产物以满足客户需求。Worktile本身是企业服务产物，客户需求在B端是及其复杂而多样的，憋在办公室是无法做出好产物的，以是须要从制度上驱动研发、产物和计划走向客户，而不是待在象牙塔。

研发下乡给了每个研发职员固定的指标，须要下乡到客户现场，以是贩卖和客户乐成有了正当的来由要求研发同事完成指标，从另一个方面也增强了研发和业务部分的共同与协作，由于双方有了共同KPI的时间，各人绑在一起去做好一件事的动力就变得很强。

6. Polish Week

Polish Week是来自硅谷的盛行文化，让研发团队在一个告急迭代之后，有充足的时间可以苏息一下，然后会合火力办理来自客户的需求大概标题，这种制度计划好坏常高效的方法，可以短时间会合军力办理遗留标题。

7. 技能分享和走出去

5年下来，我们技能团队每周分享已经正常举行了几百次，研发团队中的每个人都或多或少完成过对于所在部分的技能分享。新人来到团队，可以从已往数百次分享留下来的知识劳绩非常多的遗留知识。

（在研发体系共享的技能分享池）

别的一方面，Worktile 的焦点客户原来就是研发团队和工程师，市场维度须要研发职员可以或许不绝共享有代价的技能内容，而技能分享机制恰恰提供了驱动工程师内容创作的泥土。

每次内部分享的内容，着实完全可以继承优化成外部可以传播的内容，通过市场本领实现二次传播，同时也可以或许将团队中有活力和分享精力的小同伴，推到前台去技能大会大概公司构造的技能分享大会分享。

基于OKR和Scrum的研发管理

源于业务关系，我们在N个差异的客户场景做过测试，就是把团队老大的目的在公司群里做个调研，比力打脸的现实是，99%的情况下老大想的目的和实验层明确的目的不是一回事，而且大部分时间差异都非常大。因此，回到在研发团队大概公司层实验OKR，本质上要办理的焦点标题是：上下同欲。

俗话说，上下同欲者胜。如果目的这件事都没法告竣划一，那么统统效能和服从的优化都是无稽之谈。由于你服从越高，但方向不对，大概偏离方向跑的更远，这不是很尴尬的变乱么？

因此，我们可以通过相识OKR来在团队形成一个根本的本领，这就是战略同步和战略沟通，从而实现目的同一这件事。（OKR的根本知识，保举去Worktile OKR专题页相识）

（OKR是战略同步和战略沟通工具，服务于团队的任务和愿景）

1.写好O和KR是实验OKR最难的第一步

在研发团队落地OKR，本身并不是一件特别轻易的变乱，Worktile 团队履历了将近3年的反复实验才渐渐找到OKR实验的感觉，而全部难点中，在开始阶段是怎样写好你的O（目的）和KR（关键结果）。

（一个典范的研发O和KR界说）

以是，开始阶段须要不绝在情势上包管OKR的实验，这个好坏常须要且须要对峙的变乱，然后不绝打磨每个周期里的O和KR的界说。下面是一些OKR模板大全，看看良好团队OKR是怎样界说的：

• 产物司理的OKR模板大全

• 技能和研发的OKR模板大全

2. OKR + Scrum的方法论

本文并不能将Scrum睁开来讨论，由于这着实是一个大大大的话题，在我们团队实验Scrum有个大图景，此中包罗了：敏捷开辟、代码托管、连续集成、连续摆设和连续发布。

下面这张图是以最底子的敏捷开辟为例，从怎样开会、怎样界说团队规模、怎样脚色分别、怎样迭代、怎样测试，有非常专业且详细的管理细节。

不外，回到落地Scrum，同时又关注OKR的研发团队来说，Scrum + OKR是一个及其有代价的组合工具，我们本身的履历是以以下方式团结的：

• 部分级OKR驱动 + 部分内敏捷驱动，OKR不到个人层级，但团队中的牛人可以OKR驱动

• 迭代与OKR周期匹配，Sprint Meeting和OKR Review Meeting团结

• OKR辅助优化产物Backlog的优先级

• Scrum Master 到场 OKR Master 目的修正

我们总体在公司层将OKR实验的单元控制在部分层级，并没有逼迫个人订定个人的O和KR，以是回到研发团队管理上，部分的大方向和大目的靠OKR包管。而部分内的迭代，Product Backlog和Sprint Backlog则以敏捷的周期和原则实验。

大方向由OKR包管，而且影响优先级，小迭代和任务筹划，基于敏捷的原则实验，简直是完善配搭。

3. 集会制度

我们保举以Sprint Meeting和OKR Review Meeting为焦点的复盘和筹划集会。

Worktile研发团队，通常会定期在每周五的上午有一个非常长的同步集会，焦点内容是基于Scrum的一个Sprint迭代来复盘进度和贰言办理，产物和研发在一起高效沟通当前版本的进度和标题，并快速协商办理方案，指定实验人。

而另一方面，我们会在例会中共同复盘和更新研发团队的目的树，投影将打出两个页面，一个是迭代的故事板，一个是OKR的目的树。

对研发团队而言，通过OKR例会和Scrum例会，很好的规范了每次集会的焦点内容，服从天然非同反响。

（例行的Scrum集会，同时复盘迭代的进度和OKR目的告竣）

4. 逐日站立

逐日15分钟的站立集会，是敏捷型研发团队的必修课。快速交换昨日希望和标题，快速商量办理，然后快速筹划本日的工作安排，天天花很小的时间复盘，这才是小步迭代。

固然，如果对着Worktile的迭代故事板去讨论，就免去了在墙上贴一大堆的标签，感觉很爽很到位。

（天天发生的短小干练的站立集会）

5. 落地OKR的各种坑

实验OKR，一些坑是初次体验的团队常常犯的标题，总结下来重要是以下方面:

• 和绩效稽核挂钩

• 一上来就全员实验

• 变成目的分解工具

• HR负责，而不是团队老大

OKR不是灵丹仙丹，更像一个二把刀大夫，你信就能行，你不信就不可。OKR提供了根本的方法论、仪式、流程和规则，可以或许为团队构建根本的目的同步框架，现实落地须要公司决议层有对峙走下去的刻意，实验一次不可，要再调解然后接着来。我们本身团队从开始打仗到本日，OKR的实验上已经是第三次才渐渐找到感觉。

谈谈研发绩效

纵横江湖这么多年，着名的外企，头部的公司，小而美的外洋企业，特别官僚的国内公司，包罗我们一起共建和共创的客户，我履历和相识的公司至少上百家以上。

但是讲真，在研发绩效管理上做的好的，凤毛麟角。本身而言，研发的绩效、目的、管理和处罚，从来都是一件难的变乱，不要试图以过于简单的方案来办理。

我曾见地过一家500人研发团队的公司，为了指标化研发的KPI，将研发工作细分成几千个指标，然后通过几千个指标的动态结果来引导绩效和方向。这种实验骨骼清奇，但我从过往履历里表达了深深的猜疑。我们所熟悉的那些牛逼闪闪的公司，没有一家是如许做的，更多的方式照旧停顿在人类智力可以明确和共识的方式上：

• 360度

• 职级

• Peer Review

• 项目制处罚

• 分级稽核

下面，将我们本身在运行的绩效和处罚方法，做一些浅尝辄止的分享。

1. 360度

我们在研发绩效制度上，重要实验360稽核，每半年一个周期，年中稽核占30%的权重，年底稽核占70%权重。包罗了自评、同事、直属上级、HR和老板，稽核的焦点是以个人对公司影响力作为最紧张的尺度。

因此稽核前的述职过程对每个人至关紧张，由于你须要说清楚我在这个周期里，做了哪些有代价的变乱，带来了哪些故意义的结果，存在哪些标题，以后怎样制止息争决。

我们的部分稽核，直接由部分总监的360度结果来取代，以是这意味着部分总监的个人稽核结果，就是部分团体的结果，会影响部分团体的系数。

有稽核就有处罚。360稽核是决定一个个体和团队一年的夸奖大概处罚，做得好的和做的欠好，都由这个结果来评定。

奖金由结果决定，我们通常会界说公司、部分和个人三级系数，差异的系数代表了差异的寄义，然后加权出来的结果代表了你能拿到多少夸奖：

• 公司系数：根本由公司的总体营收和团体目的告竣情况有关，决定了公司总奖金池和调薪池的多少。

• 部分系数：也就是部分总监的个人系数，决定了部分在公司多个部分的排序，以及该部分总的夸奖系数。

• 个人系数：就是个人的稽核结果，决定了个人在所在部分的排序，以及个人总的夸奖系数。

这三个因素加权到一起，根本就为每个人和每个部分界说了一年的收获。

360度大概不是最佳的绩效方案，但这是当下广泛实验的规则里最有用的办法和方式。固然，实验360度稽核有很多实验的细节，这些是施行过程中很紧张的均衡，每个稽核竣事都要复盘做哪些调解。

总体而言，夸奖和处罚也没有永世的绝对公平，只有相对的。但是在规则界说上，怎样实现按照影响力评价，就能最大水平的包管能者多劳这一根本知识。

2. 职级驱动

职级体系是研发型团队最有代价的工具，职级体系是一个职业序列，可以方便的界说一个人对公司影响力的评级和序列，而不是职位序列。以是，对于资深的工程师大概架构师来说，他的职级可以比本身的部分向导高，但职位可以略低。

职级体系同时界说了薪资范围和期权范围，从而让职级成为一个步伐员向上通道的必经之路，缘故因由是职级大概界说他在公司维度下薪资的上限，必须职级提升才气突破某个薪资瓶颈。

职级的代价在于：它是清楚界说的透明规则，包罗薪资范围、期权、附加福利、评级尺度。如许的透明尺度可以或许最大水平上变更每个人向上发展的积极性。比方，职级对应的附加福利中，我们会包罗你每年可以加入外部培训的额度，这对学习型工程师都好坏常好的小福利。

（职级体系）

职级体系不是一个简单的工具，须要思量很多细节和适配差异公司的规则，比方怎样评级职级，技能委员会对研发岗位每个人的技能本领界说，职级评价的周期，每个职级的要求。

总体而言，职级是个有用工具，可以或许好的驱动那些有向上野心的团队成员，以最透明和公平的方式在向上的通道进步。

多说一句，我们在研发团队是以OKR+ 360度 + 职级体系来创建相对美满的管理体系，而在业务团队，包罗贩卖、客户乐成、市场团队，则更加突出KPI的导向性，以是KPI也不是毒药，KPI要善用到符合的地方，以及以符合的方式。

3. 分级稽核

分级稽核是我们在渐渐实验的方案，还没有完全落地，只是一个探究阶段的东西。实验分级稽核的缘故因由是，任何构造和团队，都知识性的依照2-7-1原则，肯定有20%的牛人来长远的带来公司进步，也大概率上有70%的实验层须要靠规则和良好的脚色来影响进步。

以是稽核的方式上不能实验同一的规则，否则要么对牛人定了太低的尺度，要么对一样寻常本领的人定了太高的尺度。

另一方面，分级稽核也可以或许从规则上驱动70%的小同伴，有积极向20%进步的动力和尺度。固然，我们还在观察和实验，这里仅仅抛砖引玉。

4. 总夸奖和总营收挂钩

这一条原来是一个知识性的结论，只是这个期间太多融资了的公司并没有很好的明确夸奖的本质，很多时间拿融资的钱夸奖，是不道德的。以是，让总营收和总夸奖挂钩，是最公道，也最义正辞严的方式。

这一条在我们的逻辑里，就是由总营收来影响绩效稽核的公司级系数，这个系数由焦点管理层来界说即可。

工具化

工欲善其事必先利其器，这是真理。工具的焦点代价，不是仅仅通过工具进步服从，更紧张的是，利用工具可以或许为团队修睦水渠。

研发团队本身的管理、绩效、工作流程有很多可以水渠化的变乱，以是用一个好的工具可以或许最有用的资助研发团队修睦水渠，然后告竣团队的目的。

固然，重要保举的是我们本身在用，而且很有用的自家工具：Worktile。焦点缘故因由是对研发团队而言，Worktile可以或许资助办理的重要是以下两个方面：

• 基于敏捷的全流程项目管理

• 基于OKR的目的工具

1. 通过Worktile项目管理（Scrum和Kanban）驱动敏捷研发全流程

如今已经有几十万团队通过Worktile协同工作，此中研发团队占比是最高的，源于我们提供了对敏捷全流程的完备工具链支持，以及更好的产物体验：

• 支持Scrum和Kanban两种敏捷实践方式

• 基于敏捷方法论的完备迭代、故事板、需求、任务和缺陷管理

• 丰富的报表和数据统计，对研发决议管理一览无余

• 买通研发和业务，更好的跨部分协作支持

落地敏捷，须要可以或许支持全流程的简单工具，Worktile为你提供了所需的统统。

2. 通过Worktile OKR工具落地OKR的实验

Worktile是国内首家将OKR落地到工具化的产物，为团队实验OKR提供了更好，更方便，更数据化的支持，重要包罗：

• OKR的实验全流程管理，从启动、周期、打分和评审

• 基于公司、部分和个人分级的O和KR管理

• 一个基于目的体系的目的树

• 基于目的实验的主动化运营分析，同统计报表告知团队OKR实验和更新的情况

• 主动目的更新提示

（在Worktile以更有用的方式界说OKR）

OKR是个简单的方法论，工具本身并不复杂，但主动化方式显然好过Excel共享方式带给团队的代价。这些都是Worktile已经修睦的水渠，你只需将水引入即可。

总结

好了，这是一篇汇聚研发团队，从管人到管事的一些点滴履历，背后投射的是一个百人规模研发团队在已往发展之路上不绝迭代的履历和方法。

每个团队都是独特而与众差异的，以是履历和方法也不愿定得当全部，只是渴望一些大概的思绪，能带给你的团队一些迁徙转变和启发。

步伐员群体，也是独特而与众差异的一群可爱的家伙，他们有孤芳自赏的风俗，也有改天换地的雄心，他们不会循规蹈矩，更不会不绝被996束缚手脚，驱动这群难搞的人不是一件轻易的事，须要站在开辟者的视角去明确他们的工作和兴趣，然后共创出可以或许实验、可以或许鼓励、可以或许数字化的方案，这是我们Worktile在试图积极的方向，也是我们本身献给本身工程师们的礼品。

接待你贡献你们团队的履历，私信我，大概留言，咱们看看另有什么更好的办法，解放天下步伐员。

本文作者：Worktile CEO anytao

文章泉源：Worktile官方博客

接待访问交换更多关于技能及协作的标题。

文章转载请注明出处。