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

陈先生528

今天，我主要带来以下三大主要观点的分享：
1、高效的研发团队需要有合理的组织架构：技术 Leader 需要学会如何结合自身的环境，设计技术团队的人员架构；
2、高效的研发团队需要高效的研发流程：高效的研发团队需要一个敏捷的研发流程。最经典的就是 Scrum 敏捷。在实行 Scrum 敏捷的过程中，我们踩过很多的坑，所以我也会将这些感悟进行分享；
! g! ~5 n  t9 n& I3 r6 t3、高效的研发团队需要灵活的考核机制：技术 Leader 如何通过一些 OKR 和辅助手段帮助技术人员输出价值。
# M+ u. R4 }0 V* r5 n

GTLC 现场，黄勇正在进行分享
' o3 t5 W  l! h2 d) D# m& E高效的研发团队需要合理的组织架构
2014 年，我曾任阿里架构师一职。从当时积累的经验来看，我习惯先制定人员组织结构，再考虑定义技术架构。
2015 年，我离开了阿里，来到特赞担任 CTO。当时公司内部有一套相对可行的核心业务，但核心业务增长缓慢，因此需要拓展更多创新业务。因为市场上成功的创新项目和案例较少，所以整个技术团队方向感特别不明确，技术团队缺乏活力，研发绩效难于考核。对于我自己来说，加入的时候也很迷茫，更谈不上所谓的项目管理了。
业务提需求，我们加班加点完成，项目上线了却看不到效果，看不到用户的评价，这时的团队内部非常焦虑。对于老板、业务人员而言，他们都在质疑技术团队到底提供什么价值？在价值感没有树立之前，更不用说跨团队的协同，推动事情都非常困难。同时，公司当时的腰部力量人员少、能力较弱，又缺少通过管理等科学的手段来追求效率。
针对这个问题，我的第一步是对所有研发团队人员进行 1 对 1 沟通，谈他的职业规划、理想、人生，搞清楚这些同事的需求是什么。
" S3 V8 _" v- ~/ A% W$ ?之后，我开始建立横向的职能团队和纵向的项目团队。以项目线作为核心，以职能线作为辅助，横向的职能线是不变的，纵向的项目线是动态的。当一个项目完成以后，这个项目的人会被释放掉去做其他的项目，但是整个框架不变。每一个项目的周期尽可能短，基本上两周左右可以上线一个新的项目，敏捷迭代的速度都能满足。因为公司当时属于较早期阶段，大家都考虑怎么能够让公司活下来，所以职能线设置的主要目的是关注同事们的成长和贡献。
9 F/ Z# n6 L7 A/ Q# ~7 ]4 e5 N
1 B3 c, G, K) y7 v同时，在职能团队里，我还需要定义不同的委员会，例如前端委员会、后端委员会、产品委员会、技术委员会等等。每一个团队都有一个领导作为队长，队长由大家投票选出，然后通过面试进行选拔，任职期是半年，每半年轮换一次。这个队长需要具备的条件，第一他在专业领域中要能力强；第二需要具备一定的分享精神，愿意帮助同事团队来分享。在半年时间里，队长要创造价值，让团队认可他，建立他的影响力，从而提升他的领导力。
" O$ F$ [6 [8 b4 Y3 r5 b( ^, \每一个委员会直接的成员互通都是开放的，比如后端委员会的人员可以加入前端委员会，但是新加入某一个委员会，则需要通过一道面试。我们每年刷新一次组织内部，做一个小的调整，但是框架是固定的。
公司的项目团队主要有三大分类，包括功能团队、效率团队、创新团队：
0 y2 T& i" [7 o; P! x3 T功能团队相当于突击队，当市场发掘到一个很好的 idea 时，就交给功能团队，让他们以最快速度落地、上线，收集数据，看到效果。
$ N9 P9 I+ `5 b* M效率团队则是对已有产品的优化和迭代，这些工程师更加精通于业务和数据，他们会从底层分析为什么我们要做这一次升级，这个升级到底改变了什么样的数据指标等等，因此会深度理解业务的背后本质。
+ X2 X$ `7 Q- B4 R创新团队则是基于整个战略框架去探索未来的前沿性项目。
我们打造了一个下图这样的矩阵式结构，整个架构支持扩展。比如一个团队不够，可以横向扩展三个四个。

* x" ~; ^3 e4 J) z9 U  ?; h在这个过程中，功能团队负责产品从 0 到 1 的过程，之后会把接力棒交给效率团队，让其做一些迭代的优化，相当于在功能团队的基础上做二次开发，进行升级改造的工作。其中，当功能团队交给项目团队时，项目团队会做关键性评审，包括源代码、文档的评审等等，还有一些业务背景和知识的交流。
" N) ?$ X9 Q* V搭建合理的研发团队架构是技术领导力的一种表现。作为技术团队的领导，接手一个团队，一上来就进行推导重来是一件风险非常大的事情。与其这样不如先把每个人搞清楚，定义一套架构，帮助研发团队走向他们希望的方向，下一步才是技术架构。把组织架构定义好以后，实际上也就把人心管理起来了。作为技术管理者，一旦影响力得到了提升，大家对你的认可度高了，之后做决策才会得到更好的执行。
: x5 j, }" v$ ], |0 ?$ {" d高效的研发团队需要高效的研发流程
% x' Z0 F6 {5 q+ Q) ]当时，公司的产品框架是，产品委员会的产品专家们去收集一些业务上的需求拉入需求池。注意这个需求池不是让业务方自己来提，而是需要我们的产品专家们搞明白对方有什么需求，之后再把一些信息填充到需求池当中，这个信息是由产品专家进行管理。
4 _" u% n- P, P4 i# @9 C) r当然，需求池当中有五花八门的需求，那么我们就需要做一个过滤。这个过滤包括：纯粹新的功能会交给功能团队执行，功能上的迭代升级会交给效率团队，未来的一个思路会交给创新团队。
- S, J) C7 l/ d! ~# a/ M& y0 f这三种不同的团队在日常开发过程当中一定会积累技术债，也就是一些“难啃的骨头”。那么，这些问题会交给技术专家，由技术委员会管理所有的技术债，技术委员会会根据情况会逐步去偿还这些技术债，让我们的架构变得更好。
7 Y* t: j+ _/ B, I7 r. ~/ V  L
我建议公司内部最好要有这么一幅“产品生命线“图，让在职的员工们通过这些流程先跑起来，并能够从内心认可它。第二步是对一些新进来的员工进行内容培训，或者用导师带着新员工的方式，一起跑几个项目，这样他的习惯和各个方面就跟我们整个团队保持一致了。

当一个项目上线了之后，其实这个项目的价值才真正开始，所以我们要不断收集数据、不断验证项目的假设到底能否成功，中间会有一个验证期的概念。项目启动时，我们会在这里定一个项目的 OKR 管理目标。项目目标一个就可以了，因为我们已经把项目拆分足够小。因此，在项目上线后，我们每天会不断地进行验证，评估功能上线的价值是否有达到。这样，一段时间后会做一个复盘，评估整个项目的 OKR。
& b9 S% G8 i. m* D2 W9 I同时，附带给大家介绍一下复盘四步法，总结下来就是 16 个字——审视目标、回顾过程、分析得失、总结规律。我们在每一步都融入复盘的思想，让团队习惯复盘的文化，从而一起进化和协作。
! Y6 H- z% r) u7 a; T此外，我当时还面临一个很大的挑战，即如何解决跨部门协同问题。
相信很多公司都有这样的问题，业务团队很不耐烦地去问产品团队，产品团队会说功能上线这么久了，为什么总是得不到反馈？曾经，我们业务团队也有一位同事有类似的抱怨，即需求提了很久了，但是一直都得不到解决。
( X3 s) G4 H- K9 e' j8 d这个问题发生的根结在于，各自团队的利益不同，两拨人在一起就容易产生一些不和谐的因素。
# U: M" `* A) [" W对于这个问题的解决方案，我们内部想了一个被称为“特赞之声”的解决方案。即通过一种游戏化的方法来解除跨部门协同的障碍。游戏的过程是：
% ?8 l% H0 X& _3 w: m# F内部将有需求的卡片，有反馈的，有脑洞的卡片固定在墙上。其中，需求卡片多数是业务部门提，等项目上线以后，需求方可以提反馈；脑洞卡片是每个人都可以提，只要对产品有利、有价值的 idea 都可以提，提完以后上墙。
1 Q; s0 s# M3 Y7 u同时，我们依托于一些虚拟货币（不是区块链币，它被称之为“特赞币”）来促进对卡片的处理和反馈。
, V0 q9 Y- n2 l9 |5 T* K  `2 X3 O业务人员作为需求方，也同样是“币”的用户，比如市场部门给他发了 10 个币，销售部给他发 20 个币，他作为业务方要来提需求，则可以要花掉“币”。那么，产品部门看到需求就会去找业务人员了解需求，这样联动感就有了。另外，在项目上线以后，我们也可以让业务方通过这个卡片提反馈，提反馈的过程就可以赚到“币”。“币”的总量是恒定的，我们不会增加币的数量，所以可以让需求、反馈、点子充分的在业务、研发部门之间流动。
$ T3 M5 C: X7 B& v. k' B
有了这个机制之后，我们跨部门协同问题有了明显的改善。业务人员提需求也会非常的谨慎，因为需求要花币，币用完了就不能做事了。
3 H# m8 J* ~- k- O9 W) E5 D通过这个事例，我想跟大家总结的是，让组织内部人与人互动起来，尤其是不同工种、职能团队的人互动起来，这就是技术领导力。你要搞清楚怎么能让大家玩起来，怎么能通过互动解决真实的问题，这是领导力的一个表现。
高效研发团队需要灵活的考核机制
那么，对于高效研发团队的养成来说，如何建立更灵活的考核机制，实行更好的绩效管理呢？
OKR 是一项很好的工具，它会在项目当中体现，也会在个人层面体现，每个人都会有个人的 OKR。
- k& R/ T: @0 fOKR 的定义方法是，第一步先把组织级别的 OKR 制定出来，第二步是部门 OKR，包括产品、技术、运营、市场……每个部门都有自己的 OKR，也称为团队目标，最后才是第三级员工的。
目标向上对齐
在 OKR 上，需要注意的第一个点是目标向上对齐，即员工个人定义的 OKR 要看团队，团队的 OKR 要看公司；横向 OKR 也要对齐，要做协同。OKR 制定后，内部需要有一套系统来管理这一套数据，每隔一段时间会做更新同步。

( w7 s/ V9 W5 [0 l% ~那么，什么内容放在 KPI 里面？又有什么内容放在 OKR 里呢？我认为，要求员工必须做的，不能打折扣的，只看结果的，就把它放在 KPI 里面。
- g4 N1 c/ ^) a, f5 }1 zKPI 只关心结果，不关注过程，OKR 是既关注结果又关注过程。
! r' R  b6 f, Q我们用 OKR 的话，一定不要拿着 OKR 就说要用它做绩效考核。因为大家定 OKR 会非常保守，就是为了考核为了拿奖金，所以 OKR 就用坏了，就成 KPI 了。

) b4 H' U4 }5 n9 V# {, i5 `定期更新和复盘
在 OKR 上，需要注意的第二个点是定期更新和复盘。它是一个关注过程的工具，所以一定要注重过程。所以在研发团队当中，如果能把 KPI 和 OKR 用好，其实就是技术领导力的一种提升。
同时，KPI 如果用好了也是非常不错的一项工具，如果能够与 OKR 再相互结合，威力则更强。

总结
- A# z" l' \* V提升技术领导力，打造高效研发团队，最重要的是三件事：
5 D8 L2 g3 A& ?( }( }  Y5 R第一、要搭建合理的研发团队架构，这才是高效研发的基础，不是一上来就大刀阔斧改架构或者是招人，这些都不是优先级最高的事情。
0 D5 ?! w& j7 U$ e! d' f$ }# ~* k第二，只有团队自己制定的流程或者是制度，大家才会更高效地去执行。
第三，OKR 和 KPI 有效结合，才能实现 1+1>2 的价值。
- h4 |7 w- z. l3 W9 L1 L/ X4 B领导者是告诉团队需要去哪里，管理者是告诉团队、如何达到目的。显然，团队中有一些是领导者，有一些是管理者。管理者的未来方向是要成为领导者，你要变成领导者就要提高你的影响力，要通过一些 OKR 等方法不断优化你的团队、提高效率，最终告诉他要去哪里。

" u6 C8 z+ r# |& ]/ N% [

freedom1

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