软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT数据分析 IoTA
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
IoT行业生态工作台
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
可信分布式身份服务
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
商标注册
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
安全治理云图 Compass
认证测试中心 CTC
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
更新时间:2021-03-18 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时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品

关闭导读