效能是什么意思(效能名词解释)

如何高效提升团队效能？在团队管理之前，你可能需要认识到有效性问题的本质，然后建立提高团队有效性的策略。那么，可以遵循哪些步骤来提高业务团队的效率呢？在这篇文章中，作者结合实践经验做了总结和分享，一起来看看吧。

从表面上看，效率的问题是一个团队生产力问题，但根据近一年的实践经验来看，并没有那么简单。以下是一些了解和管理技术团队效率的方法。

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

最近，市场正在谈论R&D效率测量。R&D效率衡量/价值衡量一直是一个难题，因为对大多数公司来说，R&D和商业是捆绑在一起的。公司通常只谈商业价值不谈技术价值，R&D团队是成本中心。

例如，微信R&D团队在10亿日活用户中实现了99.999999%的支付功能可用性。企业认为这是理所当然的事情，否则R&D将成为拖累，但实际上这对技术来说是一件非常困难的事情。看全公司层面的数据，只看交易笔数，交易金额，交易佣金，不看支持功能的可用率。

让R&D变得真正有价值是令人尴尬的。R&D学生在价值观方面非常糟糕，所以R&D学生很难在每次有机会的时候明确说出自己的价值观。技术只是创造了一些可能性，没有直接的业务收入和成本，很难衡量这些可能性的价值。

在这些因素的加持下，技术团队变成了一个形而上的部门，也就是说抛弃了就可惜了。没有这个团队或者大规模削减预算，好像都不太好。到时候系统出现各种问题的用户会退出，但是要投入多少资源呢？技术团队创造了多少价值？如何衡量技术团队的好坏，很神秘。

所以后来我开始讲技术交付，技术交付是指技术方在多大程度上支持业务的发展，相关指标包括需求交付比例等。然后看团队效能，就是技术方做了多少工作，做得多快多好，慢慢的技术方就陷入了自我检查的状态。

在预算层面，只能参考同行的预算投入，保证一定比例的营收，对外则宣称持续保证技术的投入。其实我们根本不知道应该增加还是减少，或者说增加技术的投入不一定能带来相应的回报。

在这些混乱的情况下，我来谈谈我对产学研团队有效性的理解。

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

更具体的说，如何打造一个有战斗力的团队，如何提高业务对技术的信心，如何让团队感受到自我价值。这个过程需要一半管理者的基本能力，一半领导者的魅力。

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

二、共识目标，规划资源

大公司非常容易出现的一个问题就是业务产品研发的策划脱节，因为每个角色潜意识里都认为自己策划就好，下游要配合自己完成工作。最后发现每天都有意想不到的资源协调项目延期等等。

上下游要达成一个共同的目标，把各自的目标变成共同的目标。这个过程有点像预算。有兴趣的同学可以了解一下公司的预算流程。本文将谈谈如何在产品和研发之间达成目标共识。

在《B端产品规划包工具》一文中，我们已经讲过如何进行年度、季度、双周迭代的产品规划，这里不再赘述。

事实上，R&D也是如此，需要年度和季度规划。在季度初，我们需要召开产品研发统战会议，全体员工都要参加。会前，大家会把自己认为本季度应该做的事情写在一个清单上，会上由标星解释“在什么背景下，应该解决什么问题，需要做什么，预计会有什么改进或提高”。

这个过程一般持续一个小时左右，每个任务的负责人和优先级都要在过程中确定。其他异常问题可以注意到，比如需要大量的R&D资源，需要在8月30日上线。

这个环节大家都知道下一季度要做什么，然后肯定会出现资源不足的问题，所以需要削减需求。

怎么切？根据优先级对列表进行排序。每个任务的负责人和组长会评估资源是否足够，划掉资源明显不足、优先级低的事情，标出重要但资源不足的事情。这个过程一般持续20分钟左右，其实大家都是来接工作的，积极评价工作饱和度。

然后大家一起回顾一下这个表格，再次就那些必须保证的需求和那些已经被扼杀的需求达成一致。对于那些资源不足的需求，要求需求提出者缩小需求范围，先实现一部分需求，排出一个大家认可的优先级。之后，如果出现资源冲突，可以根据这个表调整资源分配。这会给小组长很多事情做:

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

其实单子做完之后，资源肯定会不足，然后会被砍掉，但是大家有一个共识，这个工作是相互认可的，是你认为对业务有价值的工作，是和产品开发、测试一起做的工作。我们是被束缚的。

三、培养习惯，稳定交付

如果把“统战会议”理解为工厂产品的调度过程，那么下一季度就是生产过程。产能不稳定，不按承诺发货，那么销售运营上下游都会受到影响，团队产能越来越差，行为自由散漫，进入恶性循环。所以，一定要花时间培养生产科研团队言出必行的习惯。

具体方法是戴明循环逐一法，现在互联网圈叫敏捷迭代。

敏捷强调每个迭代周期(两到三周)都可以交付一些东西，可以是需求的技术设计方案，也可以是功能点的推出。每次迭代中的任务在迭代的第一天确定(需求列表)，需要进一步的任务分解和调度，形成团队的迭代任务看板。每个迭代还需要一个迭代日历，它定义了每个角色关键任务的截止日期。

与迭代日历一起召开的会议是迭代评审会议。我们来看看这次迭代有哪些做得好的，有哪些需要改进的。使用任务看板召开的会议是一个每日例会，检查每日任务的完成情况。询问为什么任务被推迟，为什么没有报告风险，为什么没有在每日站会和评审会议上按承诺交付。同时强调，这并不是责备或逼迫大家，而是要求大家非常负责任地评估工作量，尽最大努力完成承诺的任务。

一开始团队会因为这种压力而不敢承诺，似乎团队产品有所下降。然而，在一两次迭代之后，团队成员发现他们可以按照承诺交付，他们对自己的能力和工作越来越了解。这个时候就要开始鼓励大家敢于承诺，努力履行承诺。

在大家都不敢只承诺诺诺的时候，找那种明显敢于承诺并履行承诺的人做典型，在评审会上鼓励或奖励；或者适当提高团队成员自己设定的目标，利用痛点的紧迫性，引导大家主动承担任务。整体R&D产能可以开始逐步释放，这是一个稳定的产能。

这种状态需要三四次迭代来巩固大家的信心。这个时候很舒服。你要的东西可以在预期的时间送到，剩下的交给时间。

正常情况下，我会再次提到团队的生产力，但我个人的经验是不要挑战人性。如果你硬压着大家，虽然看起来生产力很高，但是团队凝聚力和战斗力都在往下走。没有人真的想出来载你一程。所以每次迭代只能用一两件真正非常有意义和价值的事情来挑战大家的生产力，把团队的信任用在最关键的地方。

一个有稳定交付能力的产研团队，自然会赢得上下游合作伙伴的信任。但是，只是如约而至，稳定的输出，只是让大家对自己的工作能力有一个认识，或者说没有自我价值的认可，没有自我激励的效果。

四、共同回顾，自驱进步

为了构建前文提到的正向激励循环，需要采取一些措施。在这里，我采取上游鼓励下游的方式。产研上游有业务、运营、研究等部门，把各个部门的接口拉到一起开产品评审会，大概就是茶话会的形式，让各个部门说说自己的工作在功能推出前后的变化。

比如在运营方面，功能上线前后他们的工作经验的变化，相关运营指标的变化，未来希望产学研做什么功能；让业务说说收入和成本的变化，怎么做才能更好的帮助业务创收和降低成本；让研究部门来说说用户行为和体验的变化，如何进一步提升用户体验。

在这次会议开始时，R&D可能是麻木不仁的，因为他们不关心产品是如何做生意的。但是，当R&D在“培养习惯、稳定交付”这部分越来越负责、越来越投入的时候，他们自然会在这个会上感受到“我是被需要的，我的工作是有价值的，我应该做点什么来解决用户的问题”。

这次会议的待办事项是，生产和研究团队的每个人都要列出自己认为下一步应该做的事情，与第一章“共识目标，规划资源”形成一个闭环。

五、总结

一般来说，提高效率的最终目的是增强上游对你团队的信心；否则，再高的效率也会受到挑战。除了上面说的常规管理方式，其实还需要个人魅力和价值创造。

个人魅力体现在团队凝聚力和上下游对你的信心，而价值创造是基石。如果不能扎扎实实的创收降成本，那么管理再好也是白搭。但是我还没有搞清楚价值创造的整个运作体系。当我做的时候我会与你分享它。

本文由@斌哲原创发布。每个人都是产品经理。未经许可，禁止复制。

来自Unsplash的图像，基于CC0协议。

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