为什么很多资深工程师，做管理后却带不动研发团队？

想要毁掉一个研发团队，只需要几个昏招。但要想管好一支研发团队，就得先管人、再理事。

一、管好团队，先回到人的本身

很多研发负责人都是技术出身，解决具体技术难题是他们的长项，但系统的团队管理经验，大多需要在实践当中慢慢积累。不管是想要更高质量的交付，还是做更多的技术预研，研发团队的管理最终都要回归到对人的管理上。

想要充分释放团队的价值，就绕不开大家常说的“选用育留”。

1.选

选，就是找到合适的人，搭建团队能力的起点。

选人的核心，其实不一定要追求行业顶尖的大牛。我们可以先想清楚团队当前最关键的诉求：现在需要的到底是能独当一面的人还是可以长期培养的人？

根据业务需求，管理者需要建立清晰的人才能力模型，并以此作为招聘的标准。这样就能在合理可控的成本范围内，招到更适配团队当前阶段的人选。

2.用

用，是知人善任，把个人的价值充分释放出来。

这一核心是要扬长避短，把不同特点的人员放到合适的工作岗位上。比如，经验尚浅的研发同学，可以先从难度适中的业务模块入手，在实战当中积累项目手感；经验丰富的工程师，则可以承接复杂度更高的项目，同时也可以承担导师角色，带动其他伙伴共同成长。

尊重每个人的能力边界，并给到对应的挑战与支持，才能够充分发挥出团队每个人的能力。

3.育

育，则是要持续提升团队整体能力，搭建人才梯队。

这就包含两个层面的目标：一方面要提升整体的专业能力，借助项目复盘、知识沉淀、技术分享等活动，带动全员的技术能力迭代；另一方面是要抓好梯队建设，把核心的技术和经验沉淀下来，不能让关键技术只掌握在少数几个人手里，做好人员备份，最大程度减少人员流动给业务带来的风险。

但能力之外，成员的主观意愿同样值得我们重视。研发负责人更需要搭建持续学习、允许复盘试错的环境。在这种氛围下，团队中的每一个人才愿意主动成长。

4.留

留，重点是要留住核心骨干。

留人不等于留住所有人。一方面，我们可以通过合理的激励，留住真正能创造价值的核心人员；另一方面，想要留住人，不能只依靠薪资待遇。团队所做的业务是否有价值、做事流程是否顺畅、工作环境是否公平等等，都会地影响大家的去留。

当然，我们也要看到：选用育留是管理的基础，并不是管理的全部。我们的研发团队不是在真空环境中工作的，大家能力的发挥与配合的效果，会受到内外部的环境、业务特性、流程环节等多种因素共同影响。

如果只管人，能力再强的团队也交付不了价值。

二、交付价值，要在事上用功

从一个企业总的发展方向来说，企业组建研发团队，投入大量的人力成本，最终目的不是要写出多么漂亮的代码或实现多么先进的技术，而是要通过交付物，为企业创造真实的收益和看得见的价值。

也就是说，研发团队中所有工作的意义，最终都要回归到交付这件事上。

但交付这件事说起来容易，做起来很难。不管是产品研发还是项目管理，业内一直有个“不可能三角”的说法：在项目交付中，不可能做到更好更快更便宜。

想要在这三个要求中找到平衡，我们可以关注：交付的东西到底有没有价值？交付的效率高不高，以及交付的质量能不能过关？

先看做的事有没有价值？做对的事，比把事做对更重要。

在实际做研发时会发现，倘若需求一开始就和业务方向没对齐，哪怕把代码写得再精致、上线再快，也很难拿到想要的效果。

通常企业里，产品定位与需求价值的判断，大多由产品和业务团队主导。这套模式能够很好地覆盖市场视角与客户体验，但也容易缺少来自研发视角的建议与反馈。结合过往的产研实践，我们会建议研发负责人和产品经理做一些调整，比如：

第一，研发负责人要前置参与到立项和需求评审中。从技术层面对需求提出筛选建议，能更全面地审视哪些需求最有价值。

第二，产品经理要在产品层面对需求做分级管理，优先保障高价值需求。需求梳理时，可以将所有需求分为P0（核心业务、紧急必做）、P1（常规迭代、提升体验）、P2（优化需求、可延后落地）三个等级。研发过程中，将研发资源向P0、P1需求倾斜，再严控P2需求插队挤占迭代资源，提高整体的交付价值。


聊完价值，再来看如何把事做快？

交付效率低，是很多研发团队的通病。需求反复调整、跨部门协作不一致、各类评审无序混乱……这些流程中的浪费和重复返工，都容易拖慢整体效率。

想提效率，无非是用两条腿走路：流程机制、工具建设。

流程上，先把协作规则梳理清楚。比如需求变更必须提交审批，通过了才能调整排期，从源头减少变动。

工具上，可以搭一套自动化研发体系。配置代码检查、自动化测试、CI/CD工具，自动完成代码校验和基础测试，把工程师从重复劳动里解放出来，让他们把精力花在真正该花的地方。

最后再看如何把事做好，交付的质量能不能过关？

很多人名义上做敏捷，实际上做的是“先上线再说，有问题后面迭代”；或者是面对项目进度的压力，开始压缩方案、缩减测试环节，以此换取更快的短期上线节奏。

可结合我们以往很多客户的经验，线上问题的修复成本会远高于开发阶段；一些严重的质量问题，不仅会消耗用户信任，还会给企业带来实实在在的损失。所以质量管理需要更关注前置防范。

更重要的是，质量不是只靠测试这一个环节决定，需要在全流程中逐步构建：从代码规范、单元测试，到代码评审、自动化测试，再到灰度发布、线上监控告警，质量管理的意识可以融入每一个工作环节。

而且日常还可以持续解决技术债务。研发负责人可以在每次迭代中，预留10%左右的排期来修复历史的技术债务、做重构等等。这种方式可以更早地解决产品质量问题。


虽然上面林林总总讲了一些管理思路，但具体落地到底该怎样做？另外，要判断价值、要提高流程效率、要做质量门禁管理，这些步骤都得梳理详细的流程。而且流程一多，光靠个人自觉，执行就容易走样。

为了解决上述这种问题，我们禅道团队梳理了一套自身的软件研发流程，在《禅道软件团队研发流程规范3.0》中固定了下来。单拿迭代冲刺里的质量门禁举例，就设置了一些具体的落地措施：

• 单元测试：每个方法必须有对应的单元测试脚本，且必须成功通过。
• 本地代码扫描：扫描结果没有错误。
• 性能门禁：响应时间小于500ms，SQL数量小于100。
• 提交限制：单次commit修改行数≤50，单次push修改行数≤200……

这些流程和工具的门禁，就像一条自动化的质量流水线，让不符合标准的产品无法进入下一个环节。大家按照其中的流程规范在团队内落地，就能更直接高效地完成研发流程体系的搭建。

如果哪位朋友需要《禅道软件团队研发流程规范3.0》，可以给阿道留言【3.0】领取。希望这个流程规范能为大家带来研发团队管理中的新思路。

一套高效的研发团队管理体系，从这里就已经开始。