EDA365电子论坛网

标题: 如何通过这三个妙招，打造一支高效的研发团队 [打印本页]

作者: 陈先生528 时间: 2020-9-11 09:45
标题: 如何通过这三个妙招，打造一支高效的研发团队
今天，我主要带来以下三大主要观点的分享：
1、高效的研发团队需要有合理的组织架构：技术 Leader 需要学会如何结合自身的环境，设计技术团队的人员架构；
2、高效的研发团队需要高效的研发流程：高效的研发团队需要一个敏捷的研发流程。最经典的就是 Scrum 敏捷。在实行 Scrum 敏捷的过程中，我们踩过很多的坑，所以我也会将这些感悟进行分享；
3、高效的研发团队需要灵活的考核机制：技术 Leader 如何通过一些 OKR 和辅助手段帮助技术人员输出价值。

GTLC 现场，黄勇正在进行分享
高效的研发团队需要合理的组织架构
2014 年，我曾任阿里架构师一职。从当时积累的经验来看，我习惯先制定人员组织结构，再考虑定义技术架构。
2015 年，我离开了阿里，来到特赞担任 CTO。当时公司内部有一套相对可行的核心业务，但核心业务增长缓慢，因此需要拓展更多创新业务。因为市场上成功的创新项目和案例较少，所以整个技术团队方向感特别不明确，技术团队缺乏活力，研发绩效难于考核。对于我自己来说，加入的时候也很迷茫，更谈不上所谓的项目管理了。
业务提需求，我们加班加点完成，项目上线了却看不到效果，看不到用户的评价，这时的团队内部非常焦虑。对于老板、业务人员而言，他们都在质疑技术团队到底提供什么价值？在价值感没有树立之前，更不用说跨团队的协同，推动事情都非常困难。同时，公司当时的腰部力量人员少、能力较弱，又缺少通过管理等科学的手段来追求效率。
针对这个问题，我的第一步是对所有研发团队人员进行 1 对 1 沟通，谈他的职业规划、理想、人生，搞清楚这些同事的需求是什么。
之后，我开始建立横向的职能团队和纵向的项目团队。以项目线作为核心，以职能线作为辅助，横向的职能线是不变的，纵向的项目线是动态的。当一个项目完成以后，这个项目的人会被释放掉去做其他的项目，但是整个框架不变。每一个项目的周期尽可能短，基本上两周左右可以上线一个新的项目，敏捷迭代的速度都能满足。因为公司当时属于较早期阶段，大家都考虑怎么能够让公司活下来，所以职能线设置的主要目的是关注同事们的成长和贡献。

同时，在职能团队里，我还需要定义不同的委员会，例如前端委员会、后端委员会、产品委员会、技术委员会等等。每一个团队都有一个领导作为队长，队长由大家投票选出，然后通过面试进行选拔，任职期是半年，每半年轮换一次。这个队长需要具备的条件，第一他在专业领域中要能力强；第二需要具备一定的分享精神，愿意帮助同事团队来分享。在半年时间里，队长要创造价值，让团队认可他，建立他的影响力，从而提升他的领导力。
每一个委员会直接的成员互通都是开放的，比如后端委员会的人员可以加入前端委员会，但是新加入某一个委员会，则需要通过一道面试。我们每年刷新一次组织内部，做一个小的调整，但是框架是固定的。
公司的项目团队主要有三大分类，包括功能团队、效率团队、创新团队：
功能团队相当于突击队，当市场发掘到一个很好的 idea 时，就交给功能团队，让他们以最快速度落地、上线，收集数据，看到效果。
效率团队则是对已有产品的优化和迭代，这些工程师更加精通于业务和数据，他们会从底层分析为什么我们要做这一次升级，这个升级到底改变了什么样的数据指标等等，因此会深度理解业务的背后本质。
创新团队则是基于整个战略框架去探索未来的前沿性项目。
我们打造了一个下图这样的矩阵式结构，整个架构支持扩展。比如一个团队不够，可以横向扩展三个四个。

在这个过程中，功能团队负责产品从 0 到 1 的过程，之后会把接力棒交给效率团队，让其做一些迭代的优化，相当于在功能团队的基础上做二次开发，进行升级改造的工作。其中，当功能团队交给项目团队时，项目团队会做关键性评审，包括源代码、文档的评审等等，还有一些业务背景和知识的交流。
搭建合理的研发团队架构是技术领导力的一种表现。作为技术团队的领导，接手一个团队，一上来就进行推导重来是一件风险非常大的事情。与其这样不如先把每个人搞清楚，定义一套架构，帮助研发团队走向他们希望的方向，下一步才是技术架构。把组织架构定义好以后，实际上也就把人心管理起来了。作为技术管理者，一旦影响力得到了提升，大家对你的认可度高了，之后做决策才会得到更好的执行。
高效的研发团队需要高效的研发流程
当时，公司的产品框架是，产品委员会的产品专家们去收集一些业务上的需求拉入需求池。注意这个需求池不是让业务方自己来提，而是需要我们的产品专家们搞明白对方有什么需求，之后再把一些信息填充到需求池当中，这个信息是由产品专家进行管理。
当然，需求池当中有五花八门的需求，那么我们就需要做一个过滤。这个过滤包括：纯粹新的功能会交给功能团队执行，功能上的迭代升级会交给效率团队，未来的一个思路会交给创新团队。
这三种不同的团队在日常开发过程当中一定会积累技术债，也就是一些“难啃的骨头”。那么，这些问题会交给技术专家，由技术委员会管理所有的技术债，技术委员会会根据情况会逐步去偿还这些技术债，让我们的架构变得更好。

我建议公司内部最好要有这么一幅“产品生命线“图，让在职的员工们通过这些流程先跑起来，并能够从内心认可它。第二步是对一些新进来的员工进行内容培训，或者用导师带着新员工的方式，一起跑几个项目，这样他的习惯和各个方面就跟我们整个团队保持一致了。

当一个项目上线了之后，其实这个项目的价值才真正开始，所以我们要不断收集数据、不断验证项目的假设到底能否成功，中间会有一个验证期的概念。项目启动时，我们会在这里定一个项目的 OKR 管理目标。项目目标一个就可以了，因为我们已经把项目拆分足够小。因此，在项目上线后，我们每天会不断地进行验证，评估功能上线的价值是否有达到。这样，一段时间后会做一个复盘，评估整个项目的 OKR。
同时，附带给大家介绍一下复盘四步法，总结下来就是 16 个字——审视目标、回顾过程、分析得失、总结规律。我们在每一步都融入复盘的思想，让团队习惯复盘的文化，从而一起进化和协作。
此外，我当时还面临一个很大的挑战，即如何解决跨部门协同问题。
相信很多公司都有这样的问题，业务团队很不耐烦地去问产品团队，产品团队会说功能上线这么久了，为什么总是得不到反馈？曾经，我们业务团队也有一位同事有类似的抱怨，即需求提了很久了，但是一直都得不到解决。
这个问题发生的根结在于，各自团队的利益不同，两拨人在一起就容易产生一些不和谐的因素。
对于这个问题的解决方案，我们内部想了一个被称为“特赞之声”的解决方案。即通过一种游戏化的方法来解除跨部门协同的障碍。游戏的过程是：
内部将有需求的卡片，有反馈的，有脑洞的卡片固定在墙上。其中，需求卡片多数是业务部门提，等项目上线以后，需求方可以提反馈；脑洞卡片是每个人都可以提，只要对产品有利、有价值的 idea 都可以提，提完以后上墙。
同时，我们依托于一些虚拟货币（不是区块链币，它被称之为“特赞币”）来促进对卡片的处理和反馈。
业务人员作为需求方，也同样是“币”的用户，比如市场部门给他发了 10 个币，销售部给他发 20 个币，他作为业务方要来提需求，则可以要花掉“币”。那么，产品部门看到需求就会去找业务人员了解需求，这样联动感就有了。另外，在项目上线以后，我们也可以让业务方通过这个卡片提反馈，提反馈的过程就可以赚到“币”。“币”的总量是恒定的，我们不会增加币的数量，所以可以让需求、反馈、点子充分的在业务、研发部门之间流动。

有了这个机制之后，我们跨部门协同问题有了明显的改善。业务人员提需求也会非常的谨慎，因为需求要花币，币用完了就不能做事了。
通过这个事例，我想跟大家总结的是，让组织内部人与人互动起来，尤其是不同工种、职能团队的人互动起来，这就是技术领导力。你要搞清楚怎么能让大家玩起来，怎么能通过互动解决真实的问题，这是领导力的一个表现。
高效研发团队需要灵活的考核机制
那么，对于高效研发团队的养成来说，如何建立更灵活的考核机制，实行更好的绩效管理呢？
OKR 是一项很好的工具，它会在项目当中体现，也会在个人层面体现，每个人都会有个人的 OKR。
OKR 的定义方法是，第一步先把组织级别的 OKR 制定出来，第二步是部门 OKR，包括产品、技术、运营、市场……每个部门都有自己的 OKR，也称为团队目标，最后才是第三级员工的。
目标向上对齐
在 OKR 上，需要注意的第一个点是目标向上对齐，即员工个人定义的 OKR 要看团队，团队的 OKR 要看公司；横向 OKR 也要对齐，要做协同。OKR 制定后，内部需要有一套系统来管理这一套数据，每隔一段时间会做更新同步。

那么，什么内容放在 KPI 里面？又有什么内容放在 OKR 里呢？我认为，要求员工必须做的，不能打折扣的，只看结果的，就把它放在 KPI 里面。
KPI 只关心结果，不关注过程，OKR 是既关注结果又关注过程。
我们用 OKR 的话，一定不要拿着 OKR 就说要用它做绩效考核。因为大家定 OKR 会非常保守，就是为了考核为了拿奖金，所以 OKR 就用坏了，就成 KPI 了。

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

总结
提升技术领导力，打造高效研发团队，最重要的是三件事：
第一、要搭建合理的研发团队架构，这才是高效研发的基础，不是一上来就大刀阔斧改架构或者是招人，这些都不是优先级最高的事情。
第二，只有团队自己制定的流程或者是制度，大家才会更高效地去执行。
第三，OKR 和 KPI 有效结合，才能实现 1+1>2 的价值。
领导者是告诉团队需要去哪里，管理者是告诉团队、如何达到目的。显然，团队中有一些是领导者，有一些是管理者。管理者的未来方向是要成为领导者，你要变成领导者就要提高你的影响力，要通过一些 OKR 等方法不断优化你的团队、提高效率，最终告诉他要去哪里。

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

欢迎光临 EDA365电子论坛网 (https://www.eda365.com/)