如何高效地提升团队效能？在进行团队管理之前，你可能需要认清效能问题的本质是什么，进而再搭建提升团队效能的策略。那么，提升业务团队的效能，可以遵循哪些步骤？本篇文章里，作者结合实战经验做了总结分享，一起来看。

效能问题表面上看是一个团队产能问题，但根据近一年的实践经验，并非这么简单，以下谈谈我对技术团队效能的理解和管理的一些方法。

一、团队效能本质仍是人心问题

市面上最近都在谈研发效能度量，研发效能度量/价值度量一直以来都是一个难题，因为对于绝大多数公司来说，研发和业务就是绑定的，公司通常都只谈业务价值而不谈技术价值，研发团队是成本中心。

举个例子，微信研发团队在10亿日活用户的用户量下把支付功能的可用率做到了99.9999999%，业务觉得这是理所应当的，要不然研发就是拖后腿，但实际上对于技术来说这是件很难的事。整个公司层面看数据的时候，只看交易笔数、交易金额、交易佣金，并不看支持功能的可用率。

真让研发来讲价值，也挺尬的，上价值上高度是研发同学非常不擅长的事，所以每次给机会给研发同学，研发同学也很难讲得清楚自己的价值，技术只是创造了一些可能性，不好衡量这些可能性的价值，没有业务收入、成本这些来的直接。

在这些因素的加持下，技术团队就变成了一个玄学部门，有点食之无味弃之可惜的意思，没有这个团队或者大规模削减预算吧，好像又不太行，到时候系统各种出问题用户不干了，但到底应该投多少资源呢，技术团队到底创造了多大的价值呢，怎么衡量技术团队的好坏呢，玄之又玄。

所以后来就开始讲技术交付，意思就是技术侧在多大程度上支撑了业务的发展，相关指标有需求交付比例等。再后来又看团队效能，意思就是技术侧到底干了多少活，干得多快多好，慢慢地技术侧陷入了一种自卷的状态。

在预算层面，也只能参考同行保障一定营收百分比的预算投入，对外则宣称持续保障对技术的投入，实则根本不知道应该加大还是缩小，或者说加大技术投入并不一定能带来相应的回报。

在以上这些混乱的局面下，让我来谈对于产研团队效能的理解。

我理解这还是一个人心问题，在技术价值无法直接货币化的情况下如何让大家认可你的价值、认可技术团队花的这些钱。

再具体一点讲，是如何打造一支具有战斗力的团队、如何提升业务对于技术的信心、如何让团队感受到自我的价值的问题。这个过程中需要一半Manager的基础能力，一半Leader的个人魅力。

我把整个过程总结成下图这个循环。

二、共识目标，规划资源

在大公司里非常容易出现的一个问题是业务产品研发的规划脱节，因为各个角色做规划的时候下意识地认为自己做规划就好，下游理应配合自己完成工作，最后发现天天都有预期外的资源协调项目延期之类的幺蛾子。

上下游之间应该共识目标，把各自的目标变成共同的目标，这个过程跟做预算有点像，有兴趣的同学可以去了解下公司做预算的过程，本文就讲讲产品和研发之间怎么去做目标共识。

在《B端产品规划一揽子工具》一文中已经讲了产品怎么去做年度、季度、双周迭代的规划，这里不再赘述。

研发规划其实也是一样的道理，需要有自己年度、季度的规划。在季度初，需要产品研发一起开一个统战会，全员参加，会前大家把自己认为应该在这个季度做的事写在一张清单上，会上大家用标准的STAR来阐述「在什么背景下，要解决什么问题，需要做哪些事，预期能实现哪些提升或改善」。

这个过程通常要持续一个小时左右，过程中还要确定每个任务的负责人、优先级，其他异常问题都可备注出来，例如需要大量研发资源、需要8月30号上线。

这个环节大家就都清楚接下来一个季度要干什么了，然后肯定会有资源不足的问题，那么就需要砍需求。

怎么砍呢，按照优先级把列表排序下，由各个任务的负责人与组长一起评估资源够不够，把明显资源不足且优先级低的事划掉，把重要但资源不太充足的需求标出来。这个过程通常持续二十分钟左右，其实就是所有人来领活，并且自己主动评估工作饱和度。

然后是所有人一起review这张表，再次共识那些一定要保障的需求和被干掉的需求。对于那些资源不够的需求，要求需求提出人缩减需求范围，先实现需求的一部分，并且排出一个大家共同认可的优先级，此后有资源冲突，大家可以自行根据这张表调整资源分配。这个会给组长很多待办：

敲定会议上的一些争议点；去找大家都认为应当补充的资源，找不到资源还得再砍任务；一些复杂的任务需要消除风险，做一些预研性的工作；最最重要的是找上下游共识工作项，伺候好上游知晓下游。

其实这张表排完之后资源肯定还是不足的，之后还会砍，但是大家就有一个共识，就是这个活是相互认可的，是业务你认为有价值的活，是产品研发测试一起要干的活，咱们是绑定的。

三、培养习惯，稳定交付

如果把「统战会」理解为工厂生产产品的排产过程，那么之后的一个季度时间里就是生产的过程，如果产能不稳定，那么就无法按承诺交付，接着就影响销售运营等上下游，团队产能也会越来也差，行为自由散漫，进入一个恶性循环。所以一定要花时间培养产研团队按承诺交付的习惯。

具体的做法是一个个的戴明循环，现在互联网圈里又称敏捷迭代。

敏捷迭代强调的是每个迭代周期（两周或三周）都能交付一些东西，可以是一个需求的技术设计方案，也可以是一个功能点的上线。每个迭代内的任务在迭代第一天就确定了（需求清单），并需要进一步做任务拆解和排期，形成团队的迭代任务看板。每个迭代还需要有个迭代日历，明确各角色关键任务的截止日期。

配合迭代日历要开的会是迭代回顾会，大家一起看看这个迭代有哪些做的好的地方，哪些地方需要改善。配合任务看板要开的会是每日站会，检查每日任务的完成情况。在每日站会和回顾会上追问为什么任务延期，为什么没有报风险，为什么没有按承诺交付，同时强调这不是指责大家、不是push大家，而是要大家非常负责任地评估工作量、尽力按承诺完成任务。

团队一开始会因为这种压力变得不敢承诺，看起来团队产品是下降了。但是经过一两个迭代，团队成员发现自己是能按承诺交付的，并且对自己的能力和工作越来越了解，这个时候就要开始鼓励大家敢于承诺、努力实现承诺。

在大家都唯唯诺诺不敢承诺的时候，找那种明显敢于承诺并实现的承诺的人来树典型，在回顾会上鼓励或嘉奖；或者适当拔高团队成员自己立的目标，利用痛点问题的急迫性引导大家主动承接任务。整体研发产能就能开始逐渐释放，并且这是稳定的产能。

这种状态需要保持三四个迭代，巩固大家的信心。这个时候就很舒服了，你想要的东西在预期时间就一定能交付，剩下就交给时间了。

正常都会想再提一提团队的产能，但是我个人的经验是不要去挑战人性，如果把大家压的很厉害的话虽然看起来产能是高了，但团队凝聚力战斗力是往下走的，真有什么事儿没人愿意出来给你顶起来。所以只能是每个迭代用一两个确实非常有使命感有价值的事来让大家挑战产能，把团队对于你的信任用在最关键的地方。

一个有稳定交付能力的产研团队自然而然会慢慢赢得上下游合作伙伴的信任。但仅仅是按承诺交付、稳定输出，只是让大家对于自己工作能力有一个认知，还是没有自我价值的认同，没有自我激励效应。

四、共同回顾，自驱进步

想要构建前文中提到的激励正循环，还需要采取一些手段。这里我采取的是上游激励下游的方式，产研的上游有业务、运营、用研等部门，拉上每个部门的接口人一起开个产品回顾会，大概就是茶话会的形式，让各个部门来讲讲功能上线前后他们工作的变化。

例如让运营来讲讲功能上线前后他们工作感受的变化、相关运营指标的变化，以及未来期望产研做哪些功能；让业务讲讲收入和成本的变化，以及做哪些事能更好地帮助业务创收降本；让用研部门讲讲用户行为和体验的变化，做哪些事情能进一步提升用户体验。

一开始开这种会的时候研发可能是无感的，因为他们并不care产品如何业务如何了，但在「培养习惯，稳定交付」这个部分，研发都越来越负责、越来越投入的时候，他们自然而然会在这个会上感受到「我是被需要的，我的工作是有价值的，我应该做点什么去解决用户的问题」。

这个会的待办就是产研团队每个人去列出自己认为接下来应该做的事，跟第一章节「共识目标，规划资源」形成闭环。

五、总结

总的来说，提升效能最终是要提升上游对于你团队的信心，否则效能再高都会被挑战。除了上文说到的常规管理手段外，其实还需要个人魅力和价值创造。

个人魅力体现在团队凝聚力和上下游对你的信心上，而价值创造则是基石，如果不能扎扎实实创收降本，那么管理做得再好也白搭。但价值创造这块我自己都没想明白整个运作体系，等想明白了再跟大家分享。

本文由 @彬哲 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。