如何通过这三个妙招，打造一支高效的研发团队

陈先生528

今天，我主要带来以下三大主要观点的分享：
1、高效的研发团队需要有合理的组织架构：技术 Leader 需要学会如何结合自身的环境，设计技术团队的人员架构；
2、高效的研发团队需要高效的研发流程：高效的研发团队需要一个敏捷的研发流程。最经典的就是 Scrum 敏捷。在实行 Scrum 敏捷的过程中，我们踩过很多的坑，所以我也会将这些感悟进行分享；
/ [; \2 h' a" o+ r& }3、高效的研发团队需要灵活的考核机制：技术 Leader 如何通过一些 OKR 和辅助手段帮助技术人员输出价值。
$ `8 t, ?3 Q! _. `& \* `# i

9 U$ w5 w/ `( T+ j. }5 _GTLC 现场，黄勇正在进行分享
. ?! E1 F/ i; M( k/ S! ]$ P/ S8 I高效的研发团队需要合理的组织架构
2014 年，我曾任阿里架构师一职。从当时积累的经验来看，我习惯先制定人员组织结构，再考虑定义技术架构。
; \0 b/ l; @' N8 l1 X& v  ]! j2015 年，我离开了阿里，来到特赞担任 CTO。当时公司内部有一套相对可行的核心业务，但核心业务增长缓慢，因此需要拓展更多创新业务。因为市场上成功的创新项目和案例较少，所以整个技术团队方向感特别不明确，技术团队缺乏活力，研发绩效难于考核。对于我自己来说，加入的时候也很迷茫，更谈不上所谓的项目管理了。
业务提需求，我们加班加点完成，项目上线了却看不到效果，看不到用户的评价，这时的团队内部非常焦虑。对于老板、业务人员而言，他们都在质疑技术团队到底提供什么价值？在价值感没有树立之前，更不用说跨团队的协同，推动事情都非常困难。同时，公司当时的腰部力量人员少、能力较弱，又缺少通过管理等科学的手段来追求效率。
0 W& e' J: ^: v- n# E% j针对这个问题，我的第一步是对所有研发团队人员进行 1 对 1 沟通，谈他的职业规划、理想、人生，搞清楚这些同事的需求是什么。
之后，我开始建立横向的职能团队和纵向的项目团队。以项目线作为核心，以职能线作为辅助，横向的职能线是不变的，纵向的项目线是动态的。当一个项目完成以后，这个项目的人会被释放掉去做其他的项目，但是整个框架不变。每一个项目的周期尽可能短，基本上两周左右可以上线一个新的项目，敏捷迭代的速度都能满足。因为公司当时属于较早期阶段，大家都考虑怎么能够让公司活下来，所以职能线设置的主要目的是关注同事们的成长和贡献。
2 ~; T) q& N# b  S* L) N
, Q' c  m2 s- `+ \6 `0 j同时，在职能团队里，我还需要定义不同的委员会，例如前端委员会、后端委员会、产品委员会、技术委员会等等。每一个团队都有一个领导作为队长，队长由大家投票选出，然后通过面试进行选拔，任职期是半年，每半年轮换一次。这个队长需要具备的条件，第一他在专业领域中要能力强；第二需要具备一定的分享精神，愿意帮助同事团队来分享。在半年时间里，队长要创造价值，让团队认可他，建立他的影响力，从而提升他的领导力。
# _& {  J4 Y6 [6 ^! q- C. n每一个委员会直接的成员互通都是开放的，比如后端委员会的人员可以加入前端委员会，但是新加入某一个委员会，则需要通过一道面试。我们每年刷新一次组织内部，做一个小的调整，但是框架是固定的。
公司的项目团队主要有三大分类，包括功能团队、效率团队、创新团队：
功能团队相当于突击队，当市场发掘到一个很好的 idea 时，就交给功能团队，让他们以最快速度落地、上线，收集数据，看到效果。
+ g) q5 S8 H. x" b' x效率团队则是对已有产品的优化和迭代，这些工程师更加精通于业务和数据，他们会从底层分析为什么我们要做这一次升级，这个升级到底改变了什么样的数据指标等等，因此会深度理解业务的背后本质。
创新团队则是基于整个战略框架去探索未来的前沿性项目。
我们打造了一个下图这样的矩阵式结构，整个架构支持扩展。比如一个团队不够，可以横向扩展三个四个。
0 t; W! I) c( c- \- h: r
在这个过程中，功能团队负责产品从 0 到 1 的过程，之后会把接力棒交给效率团队，让其做一些迭代的优化，相当于在功能团队的基础上做二次开发，进行升级改造的工作。其中，当功能团队交给项目团队时，项目团队会做关键性评审，包括源代码、文档的评审等等，还有一些业务背景和知识的交流。
搭建合理的研发团队架构是技术领导力的一种表现。作为技术团队的领导，接手一个团队，一上来就进行推导重来是一件风险非常大的事情。与其这样不如先把每个人搞清楚，定义一套架构，帮助研发团队走向他们希望的方向，下一步才是技术架构。把组织架构定义好以后，实际上也就把人心管理起来了。作为技术管理者，一旦影响力得到了提升，大家对你的认可度高了，之后做决策才会得到更好的执行。
高效的研发团队需要高效的研发流程
当时，公司的产品框架是，产品委员会的产品专家们去收集一些业务上的需求拉入需求池。注意这个需求池不是让业务方自己来提，而是需要我们的产品专家们搞明白对方有什么需求，之后再把一些信息填充到需求池当中，这个信息是由产品专家进行管理。
6 s. g  U0 |2 t2 g9 H$ @当然，需求池当中有五花八门的需求，那么我们就需要做一个过滤。这个过滤包括：纯粹新的功能会交给功能团队执行，功能上的迭代升级会交给效率团队，未来的一个思路会交给创新团队。
这三种不同的团队在日常开发过程当中一定会积累技术债，也就是一些“难啃的骨头”。那么，这些问题会交给技术专家，由技术委员会管理所有的技术债，技术委员会会根据情况会逐步去偿还这些技术债，让我们的架构变得更好。
; G/ x1 H% p0 W
我建议公司内部最好要有这么一幅“产品生命线“图，让在职的员工们通过这些流程先跑起来，并能够从内心认可它。第二步是对一些新进来的员工进行内容培训，或者用导师带着新员工的方式，一起跑几个项目，这样他的习惯和各个方面就跟我们整个团队保持一致了。
" v5 ^2 n' r$ H0 i# ?) X
. s8 t* {8 e7 `1 O0 Y% m( q当一个项目上线了之后，其实这个项目的价值才真正开始，所以我们要不断收集数据、不断验证项目的假设到底能否成功，中间会有一个验证期的概念。项目启动时，我们会在这里定一个项目的 OKR 管理目标。项目目标一个就可以了，因为我们已经把项目拆分足够小。因此，在项目上线后，我们每天会不断地进行验证，评估功能上线的价值是否有达到。这样，一段时间后会做一个复盘，评估整个项目的 OKR。
同时，附带给大家介绍一下复盘四步法，总结下来就是 16 个字——审视目标、回顾过程、分析得失、总结规律。我们在每一步都融入复盘的思想，让团队习惯复盘的文化，从而一起进化和协作。
9 N& z1 C/ t) b- g7 c3 O此外，我当时还面临一个很大的挑战，即如何解决跨部门协同问题。
相信很多公司都有这样的问题，业务团队很不耐烦地去问产品团队，产品团队会说功能上线这么久了，为什么总是得不到反馈？曾经，我们业务团队也有一位同事有类似的抱怨，即需求提了很久了，但是一直都得不到解决。
& B. }8 U8 C/ [  O( b) e1 x% x! r这个问题发生的根结在于，各自团队的利益不同，两拨人在一起就容易产生一些不和谐的因素。
0 O! [1 }& L) I' @* A% n6 t  y: K对于这个问题的解决方案，我们内部想了一个被称为“特赞之声”的解决方案。即通过一种游戏化的方法来解除跨部门协同的障碍。游戏的过程是：
内部将有需求的卡片，有反馈的，有脑洞的卡片固定在墙上。其中，需求卡片多数是业务部门提，等项目上线以后，需求方可以提反馈；脑洞卡片是每个人都可以提，只要对产品有利、有价值的 idea 都可以提，提完以后上墙。
同时，我们依托于一些虚拟货币（不是区块链币，它被称之为“特赞币”）来促进对卡片的处理和反馈。
业务人员作为需求方，也同样是“币”的用户，比如市场部门给他发了 10 个币，销售部给他发 20 个币，他作为业务方要来提需求，则可以要花掉“币”。那么，产品部门看到需求就会去找业务人员了解需求，这样联动感就有了。另外，在项目上线以后，我们也可以让业务方通过这个卡片提反馈，提反馈的过程就可以赚到“币”。“币”的总量是恒定的，我们不会增加币的数量，所以可以让需求、反馈、点子充分的在业务、研发部门之间流动。

& J$ W2 q1 T" s' G; ~有了这个机制之后，我们跨部门协同问题有了明显的改善。业务人员提需求也会非常的谨慎，因为需求要花币，币用完了就不能做事了。
5 Z% ]+ E0 w5 Z# u9 r5 J通过这个事例，我想跟大家总结的是，让组织内部人与人互动起来，尤其是不同工种、职能团队的人互动起来，这就是技术领导力。你要搞清楚怎么能让大家玩起来，怎么能通过互动解决真实的问题，这是领导力的一个表现。
' e, l* }" ^3 W% r* y1 C. {* h: x高效研发团队需要灵活的考核机制
( y" Q3 N% X& u& k# K那么，对于高效研发团队的养成来说，如何建立更灵活的考核机制，实行更好的绩效管理呢？
. X! p4 @7 a* t7 n! gOKR 是一项很好的工具，它会在项目当中体现，也会在个人层面体现，每个人都会有个人的 OKR。
4 R* [# R! x" ]" k: i) dOKR 的定义方法是，第一步先把组织级别的 OKR 制定出来，第二步是部门 OKR，包括产品、技术、运营、市场……每个部门都有自己的 OKR，也称为团队目标，最后才是第三级员工的。
目标向上对齐
) U7 |2 L8 G+ ?+ Y7 @  S5 }在 OKR 上，需要注意的第一个点是目标向上对齐，即员工个人定义的 OKR 要看团队，团队的 OKR 要看公司；横向 OKR 也要对齐，要做协同。OKR 制定后，内部需要有一套系统来管理这一套数据，每隔一段时间会做更新同步。
& e4 A( R9 [3 J3 k- m# \
那么，什么内容放在 KPI 里面？又有什么内容放在 OKR 里呢？我认为，要求员工必须做的，不能打折扣的，只看结果的，就把它放在 KPI 里面。
KPI 只关心结果，不关注过程，OKR 是既关注结果又关注过程。
我们用 OKR 的话，一定不要拿着 OKR 就说要用它做绩效考核。因为大家定 OKR 会非常保守，就是为了考核为了拿奖金，所以 OKR 就用坏了，就成 KPI 了。
$ I; {; y! O3 {4 R' ?" }% F' x# v
) G0 u. s0 w8 Z; _( E2 k定期更新和复盘
在 OKR 上，需要注意的第二个点是定期更新和复盘。它是一个关注过程的工具，所以一定要注重过程。所以在研发团队当中，如果能把 KPI 和 OKR 用好，其实就是技术领导力的一种提升。
. ^# R2 s- n* q: g" v同时，KPI 如果用好了也是非常不错的一项工具，如果能够与 OKR 再相互结合，威力则更强。

: q, o' L/ b: k4 q, R总结
提升技术领导力，打造高效研发团队，最重要的是三件事：
第一、要搭建合理的研发团队架构，这才是高效研发的基础，不是一上来就大刀阔斧改架构或者是招人，这些都不是优先级最高的事情。
第二，只有团队自己制定的流程或者是制度，大家才会更高效地去执行。
! p: M$ V, I3 \, {4 s$ c1 h第三，OKR 和 KPI 有效结合，才能实现 1+1>2 的价值。
5 d* V) j' @$ m! ^  }4 ?/ z领导者是告诉团队需要去哪里，管理者是告诉团队、如何达到目的。显然，团队中有一些是领导者，有一些是管理者。管理者的未来方向是要成为领导者，你要变成领导者就要提高你的影响力，要通过一些 OKR 等方法不断优化你的团队、提高效率，最终告诉他要去哪里。

) H6 M& M; O# P+ n9 [6 G

freedom1

同时，在职能团队里，我还需要定义不同的委员会，例如前端委员会、后端委员会、产品委员会、技术委员会等等。每一个团队都有一个领导作为队长，队长由大家投票选出，然后通过面试进行选拔，任职期是半年，每半年轮换一次。这个队长需要具备的条件，第一他在专业领域中要能力强；第二需要具备一定的分享精神，愿意帮助同事团队来分享。在半年时间里，队长要创造价值，让团队认可他，建立他的影响力，从而提升他的领导力。