文档首页 > > 理论实践> 持续规划与设计>

提升团队生产力的公式

提升团队生产力的公式

分享
更新时间:2020/12/24 GMT+08:00

如何衡量生产力

按照完成工作的多少衡量生产力是人们最常用的一种方式,但也是最差的。

我们往往轻易地提交了大量的代码和设计决策,但又不得不在后期以更高的代价修正Bug和重新设计。如果我们仅仅衡量已经完成了多少工作,一个团队的生产力可能很高,但却可能一直没有可以发布的产品。

最理想的标准是通过“交到用户手中的可以工作的有价值的代码量”衡量,这个才是Outcome(结果),而一般公司度量的一直都是Output(产出),有Output但是不一定是Outcome 。

所以我们采用这样的公式衡量生产力:

生产力=已经完成的工作量–用于修正Bug的工作量–用于修正错误设计的工作量

通过这种计算方式,如果大家提交的错误的东西超过正确的东西,完全有可能算出来一个负值。

这才是隐藏在水面下的真正的事实。

加班可以提高生产力吗

加班是一个人们最常用的提高生产力的策略,但是极其错误的。福特公司为此曾经用12年的时间进行了几十项试验,根据最终结果,福特公司及其行业工会最终通过了每周工作40小时的法案。

倒不是因为福特仁慈,作为企业主,他们想到了挣更多的钱的最有效方式。一般人都会认为这是一次劳动力解放,实际不过是经过实验证明的最佳工作时间而已。

试验的结论主要有三点:每周工作小于40小时,工人的工作量会不饱满;每周工作超过60小时,初期生产力会有小幅提高;提高通常不超过三到四周,随后生产力会迅速降低、变负。

福特的这个统计数据的对象是1909年的工人,而现在对于IT行业的从业者来说情况又会如何呢?

这两个公司的结果,一个是1909年的生产工厂,一个是2005年的游戏软件开发公司。

查普曼(Chapman)使用生产出的产品价值作为衡量生产力的标准,海姆尼斯(Highmoonis)使用了理想的时间作为衡量标准,而且他们采用的是敏捷迭代开发方法。这两个图表都表明生产力在短期提高后,迅速降低并开始负增长。

突发性生产力提高

可不可以利用短期加班所带来的突发性生产力提高呢?譬如我们让员工在一周工作超过40小时,但小于60小时,然后在紧接下来的一周里恢复到工作40小时。或者有没有其他什么模式可以让工作安排更有效率?

下图为一个实验:

这里的Crunch意指加班。这个实验表明任何这种尝试,最终都是要付出代价的。任何时候,工作超过40小时,都需要恢复期,无论你怎么调整;一周35~40小时可以这样安排:每天工作10小时,持续四天,然后休息三天;这种“压缩工作周”,不仅可以减少缺勤,在某些情况下,甚至还可能提高生产力10%~70%!

根据美国几个研究机构所做的调查,1/3以上的员工和经理认为灵活工作制度或者四天工作制,能使生产力有显著提升。欧美的企业采用灵活工作时间制度,其实不是为了体现自由,而是灵活工作制度确实能够发挥出人的创造性和生产力。

这个试验结合我们的敏捷开发,可以得到这样的结论:第一,短期,不超过3周的加班冲刺会临时提高生产力;第二,团队有策略的加班可以完成最近的最后期限;第三,加班后,生产力会有同等程度的降低,应该根据这个因素马上调整计划;第四,考虑四天工作制。

知识工作者的绩效

知识工作者与产业工人还是有区别的。研究表明,与手工劳动相比,人在疲劳状态下,创造力和解决问题的能力会显著降低,平均而言,长时间钻研问题,往往给出更低劣的解决方案,特别是当人缺乏睡眠时,这一点尤其明显。

知识工作者每周最好工作35小时,而不是40小时。一旦超过35小时,他们就会疲惫,进而做出愚蠢的决定。而后他们又要为自己的错误加班进行修改和解决。周而复始,进入一个恶性循环。

这个试验给我们三个启示:第一,加班会毁灭创造力;第二,如果在某个问题上卡壳,要么回家,要么找个地方休息休息;第三,保持充足睡眠。睡眠会从根本上提高你解决问题的能力!

超人团队是否存在

我们公司里面有些人,特别是单身年轻人,总是宣称他们加班做了比别人更多的工作,会不会有例外的超人?或超人团队呢?

没有,绝对没有!曾经有很多人做过这样的实验:设置两个基本一致的团队A和B,A加班,B不加班。A团队通常认为他们做了比B团队更多的事情,管理者也会有这种印象,因为他们在座位旁扔了更多的烟头。而实际结果却是B团队创造出了更好的产品!最终交付的价值,才能算是Outcome(结果),否则只能是Output(产出)。

长期加班的团队也会认为他们的生产力会降低,但从来没想过停止加班,因为他们相信,无论如何也比每周40小时高,但实际情况却并非如此!

人们通常会忽略总体开销,再加上固有的一点偏见。首先,就像开头咱们已经提到过的,人们没有衡量程序缺陷所带来的开销、错误设计所带来的开销及机会成本。其次,错误的线性假设。人们一旦看到加班带来的突发性生产力提高,就会假设他们一直做下去,会有同样的效果。第三,因为有些人习惯加班,而正常工作时间的效率却很低。第四,错误的导向。管理者注重基于行为的奖励,而不是基于结果,从而加班的人往往得到更快的提升。

团队大小对生产力的影响

由4~8个人组成的团队生产力最高,比超过10人的团队高出30%~50%,因为超过10人的团队沟通成本急剧增加;但小于4人的团队缺乏足够的应对能力,不能很好地解决范围更广的问题。

可以建议部门领导这么做:首先,按照项目划分成跨职能的小团队;其次,对于大的项目,利用Scrum-Of-Scrums(一种扩展Scrum的方式)把小团队联系在一起;最后制订出创建团队、划分大团队、团队间人员流动的流程/规则。

什么是最具生产力的物理工作环境

研究表明,把属于同一团队的人安排坐在一个专属于该团队的房间里,是最能提高生产力的,可以带来100%的提高!坐在一起意味着更快速地沟通、更高效地解决问题,而更少的来自外部的干扰,也会提高生产力。

最好是有墙隔断的房间。每人至少6平方米,太少也会降低生产力。敏捷开发强调的办公环境都需要为高效沟通服务,集中办公,办公位之间最好没有阻隔板等。墙面用来做看板和状态管理,有一两个专门的小会议室,方便两三个人随时进行小范围的问题讨论和评审,或用于私人谈话、电话及与外部团队的会议等。目标只有一个,就是尽量减少对团队的干扰。很多公司因为不能为团队提供这样的办公空间,他们就会挤占一个会议室封闭开发,搞一个作战室(War-room)出来。效率也会大大提升。

混合团队的绩效要比单一职能的团队高很多,他们能够提出更具突破性的解决方案。此外,团队成员一定要专职,任何一个兼职人员,他的工作效率都会降低15%左右的。

有些时候兼职人员也是不可避免的,所以就需要合理安排好兼职人员的时间和工作量。

团队工作量安排

实验结果表明,安排80%的工作量往往会生产出更好的产品。当给员工安排100%的工作时,实际上剥夺了他们进行思考的空间。我们应该留下20%的时间让员工进行创新性的思考以及过程改进。此外,还应强调的一点是,创造出20个伟大的功能,会比创造出100个平庸的功能,更能盈利。

创新是团队活力的源泉,每个管理人员都应该想办法鼓励团队去创新,留时间让团队去思考如何创新。

提高生产力,是一个持续的过程,不是一朝一夕就能达到的,需要根据你的团队、团队里面每个人及外部环境做适当的调整。

团队授权、测试驱动开发、每周与客户交流一次、适时团建等,凡是能让团队自组织和自管理的方法,也都可以尝试一下。

提升团队生产力的要点

  1. 结果(Outcome)远比产出(Output)重要,因为很多产出不一定有价值,没有价值的东西就是浪费。
  2. 正确衡量生产力的公式:生产力=已经完成的工作量–用于修正Bug的工作量–用于修正错误设计的工作量。
  3. 任何想在短期内迅速提高生产力的想法都是杀鸡取卵的自杀式行为。
  4. 任何时候,工作超过40小时,都需要恢复期,无论你怎么调整。一周35~40小时也可以这样安排:每天工作10小时,持续四天,然后休息三天。上述“压缩工作周”,不仅可以减少缺勤,在某些情况下,可以提高生产力10%~70%。
  5. 每周四天工作制会比五天工作制效率更高。
  6. 短期不超过3周的加班冲刺会临时提高生产力,团队可以有策略地选择加班,用以完成最后的冲刺工作;加班后,生产力会有一定程度的降低,应该马上调整计划。
  7. 按照项目划分成跨功能的小团队;对于大的项目,利用Scrum-Of-Scrums把小团队联系在一起;制订关于创建团队、划分大团队、团队间人员流动的流程/规则。
  8. 混合跨职能团队比单一职能团队效率高。
  9. 关注闲置工作,而不是关注闲置个人。
  10. 好的管理者应鼓励团队创新,选择预留一定时间让团队去思考如何创新,而不能只关注人员的利用效率。

Outcome over Output

要聚焦于全局结果(Outcome),而不是局部工作产出(Output)。

精益软件开发的原则是聚焦全局,而不是进行局部的改进。管理大师彼得·德鲁克说,没有度量就无法管理,没有度量就没有改进。但是我们度量中,往往有一些的误区:喜欢度量工作产出,而不是全局的结果;喜欢局部的数字,而不是全局的结果;喜欢针对个人,而不是面向团队。常见的度量项,例如代码行数、缺陷发现数量(针对测试人员)、缺陷产生数量(针对开发人员)、资源利用率、迭代故事点数等,都是上述误区的体现。

代码行数是越多越好,还是越少越好呢?两个开发人员之间,我们应该用产出的代码行数进行比对吗?甚至同一个开发人员,这个月的代码产出,与下个月的产出,有可比性吗?代码行数多,就意味着产出的价值多么?还是会产生更臃肿,更难维护,更高的复杂度呢?代码行数少,是产出的价值少吗?还是代码效率高?

理想的状态是,用最有效的代码去解决业务问题。结合结对编程,让多于一个开发人员同时理解代码逻辑;结合TDD测试驱动开发,用恰好能够通过测试用例的代码去完成实现,并不断根据需要进行重构;甚至现在“流行”的小黄鸭测试法,此概念参照于一个来自《程序员修炼之道》书中的一个故事。传说中程序大师随身携带一只小黄鸭,在调试代码的时候会在桌上放上这只小黄鸭,然后详细地向鸭子解释每行代码,都是有效的实践。

关于资源利用率,排队理论告诉我们,100%资源占用时,前置时间接近无限大。前面的章节也提到,我们最大的问题,永远都不是空闲的资源,而是流动不畅的价值。约束理论也告诉我们,一切在非瓶颈点进行的优化,都是无效的,要提高瓶颈点的使用率,进行全局优化,而不是局部改善。

在高利用率之下,我们失去了应对非计划工作的空间。一旦有失败/ 故障出现,找到问题的根因和恢复服务是非常困难的。更糟糕的是,还会在整个系统里引发一连串其他的故障,全面恢复这些次生故障需要的时间更是惊人的。在飞轮效应的影响下,恶性事件会带来更大的恶性循环。是时候引入减速机制,是时候对高负荷的工作强度叫停,是时候勇敢的踩刹车了。

时间都去哪儿了?

我们经常发现,还没好好干活,项目就延期了,时间都去哪儿了呢?

《2018 DevOps全球状态报告》指出,即使精英和高效能组织,真正花在工作,即产生价值的工作上的时间,不超过50%,其他时间都花费在计划外工作和返工、修补安全问题、处理缺陷以及客户支持工作上。

“生产力=已经完成的工作量–用于修正Bug的工作量–用于修正错误设计的工作量”公式,清晰地展示了生产力不等于工作量。我们常常把工作量当成了产能,其实,修改缺陷不是工作量,而是浪费;客户支持工作也不是工作量,它往往是产品设计问题!

我们往往喜欢基于行为进行奖励,而不是基于结果,这是一个误区。

赋能领导力

管理者(Manager)和领导者(Leader)是两个我们容易搞混的名词。我们带领的是知识工作者,要做一个领导者,而不是管理者;要将协同力和领导力结合,将使命、行动与结果协同起来,给员工思考、探索、沟通和做事的空间。

杰克·韦尔奇说过:“Before you are a leader, success is all about growing yourself; When you become a leader, success is all about growing others(在你成为领导者之前,成功都同自己的成长有关;在你成为领导者之后,成功都同别人的成长有关)”。效能归根到底是“团队”的事,需要人组建成团队。

作为一个领导者,应该坚持不懈地提升自己团队的能力,指导和帮助团员树立自信心,发挥创造力;深入团队中间,向他们传递积极的动力和乐观精神;以坦诚、透明度和声望,建立起别人对自己的信赖感;有勇气保护团队,敢于做出不受欢迎的决定,说得出得罪别人的话,无论是对团队之外的阻碍,还是团队之内的阻力;鼓励下属发表大胆的、反直觉的或者挑战假定条件的言论,表扬他们的勇气,责备压制别人发表反对意见的人;勇于承担风险,勤奋学习,成为表率。

领导者要懂得放权,赋能,要收回管理者的权力,放手让员工去做;给人以信任和自主权;放弃一些控制权,就可以为团队创造一次提升的机会,也给自己节省出更多时间应对新的挑战。

  

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

  

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!非常感谢您的反馈,我们会继续努力做到更好!
反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

智能客服提问云社区提问