文章
主题列表

最新资讯
再读德鲁克#2 如何提升生产率
一家500人的北京IT公司,专门做企业大数据服务。为了加强管理,他们利用项目管理系统做项目挣值分析(Earned Value),要求团队先做预算,然后按项目任务完成情况报工,监控实际与计划对比。这就是典型传统会计成本监控。监控已发生的任务,但无法帮我们避免一些可能发生的风险。

我问技术总监:“你们公司的核心竞争力是什么?”
答:“我们的开发团队都很有经验,开发质量也满足客户要求。”
问:“你们如何衡量开发团队的质量和生产率?”
答:“我们半年前开始利用项目管理系统,每个月按照项目是否有超时或超出预算。”
问:“生产率不等同于项目是否延期,其实与同行相比,你们已经算不错,很多其他企业连这些项目基本监控都缺乏,但如果你们也衡量软件开发团队的生产率和质量,你们会更清楚自己是在什么水平?是否在进步?如果你们有团队的生产率和质量数据,你便更好监控项目,可以从团队的生产率和质量数据预测项目可否按期完成。”

如果我们想知道有什么好方式帮助软件开发团队提升生产率,可先回看上世纪人们如何提升工业生产率。

在20世纪初,科学管理的先行者泰勒(Frederic TAYLOR) 先生开始对劳动者做任务分析和管理,研究各个制造业工人的工作,记录劳动者每个动作,和完成动作的体力和时间,研究如何去除多余的动作。

他的结论是:无论什么工作,都是重复性,如果把那些步骤写下来,任何人不需要什么特别训练,熟练后都可以成为一流大师。

当时他的理论被不少美国工会强烈攻击,很简单,当时很多兵工厂都有工会,学徒制,要入行必须当多少年学徒,还也要有熟人推荐才进得来。为什么这么刁难,原因很简单,如果你可以最后当成那些兵工厂的领班或工人,你的薪水可能比医生还高。

可能是这个原因,二战时,希特勒在日本偷袭珍珠港以后,错误地认为美国不能在短间可以追得上德国的工业化程度,他就决定跟美国宣战,(宣战前美国,因有内战痛苦经历,国内反战声音巨大,导致在一战时几乎都没有参战,不重视发展军工,缺乏军工方面的人才,比如缺乏军用设备(如光学、镜片)的专业技工)。但事与愿违,美国借用了泰勒先生那一套方式,快速建立兵工厂,大量生产飞机、坦克等等设备,生产力后来居上,超越了德国、日本,最终获得二战胜利。

20世纪,制造业的体力劳动者生产率增长了50倍[2],但现在大部分已发展国家,传统的工业生产只占总生产的小部分,大部分是服务业或知识工作。

所以在21世纪,我们的新挑战是如何能同样提高知识工作者的生产率。

任务是什么 (Define the Task)

知识工作与体力劳动不同,知识工作者的工作大都不是预先安排好。比如汽车生产线,工人只需要按照程序安装组件就可以,劳动者只问“怎样做才能做得最好?”。但知识工作中,知识工作者主要问“任务是什么?”。

100多年前,20世纪初,当时没有互联网,没有电商。如果你不想亲自去百货公司买东西,你可以把钱寄到百货公司邮购,但这需要很多人手数寄来的现金。当时"SEARS"百货公司,

不采用传统的数钱方式,用磅来称寄来邮购信件有多重,从而判断里面有多少硬币,多少钱,连信封也不打开。这种方式就可以大大减少所需的人手,在短短两年间,把这一块服务的生产率提高十倍。


如果保险公司也问:“任务是什么?” 答案应是“对死亡申请赔偿要尽快,也最省钱。”

保险公司本来每次有事发生,客户要补偿时,保险公司传统都要检查三十个以上不同条件。

为了增加生产率,保险公司决定只检查以下关键4项:
一、这个保险单是否还有效?
二、他申请的金额是否与合同匹配?
三、那个人名跟那个死亡证是否对应?
四、受保人是否对应?

最终把本来要平均十五分钟的事情减到三分钟。

现在很多保险公司只对百分之二的抽样做控制,i.e.只对五十分之一的索偿完整地检查所有项,其他都是按上面这种快速方式处理。

医院也可以利用问“我的任务是什么?”这个问题来提高服务的生产率。很多医院花很多时间要求本人填写的资料,进医院前。甚至有些病人,急诊的病人,因为他们可能已经不清醒,无法填写很详细的表格。如果我们用刚才那个问题,这答案是,入院的手续最重要的是希望识别病人的姓名、性别、年龄、地址和如何收费?就是在一个病人,他的门卡上面有的信息。用这个方式可以大大简化入院服务,生产率也自然提高。

所以在服务业我们要增加生产率,最重要不是像以前劳动工人那种看他每个步骤,更重要的是你要想你的任务是什么?

专心工作(Concentrate on the Task)

另外一个常常影响服务生产率的问题是不能专心集中工作,例如很多医院都说缺护士,但其实每年都有不少的新毕业员工加入,病人也没有大量增加,为什么会人手不够呢?

其实很多浪费是由于护士不是做本职工作“护理病人‘,而是花了大部分时间在填写报告,而非医护工作。


高校老师也一样,主要任务本应是教学生,但其实花了很多时间开会,例如一些委员会会议。

销售人员也一样,不是专注与客户沟通,而是花很多时间在无谓的内部会议,填写报告。很多销售员,平均每天起码花不低于三分之一的时间在这类客服工作,跟销售无关。

所以每个行业服务人员都应该问这个问题:“我们受聘主要是要干什么的?我们这个工作主要提供什么价值?”

比如某百货公司,员工的回应是“销售”。但其他百货公司,可能是"客服"。所以针对不同的目标,公司应该回顾整个团队是否花了很多时间做一些没有价值的工作。

不能单看数量,质量同样重要(Define Performance)

除了问工作是什么以外,也要问怎么做才有效?

比如一个建筑绘图员,不仅仅衡量图的数量,也要取决于他绘图的质量。其他服务,无论是工程、银行、医院、报社也一样。

例如,药厂实验室科学家,质量最重要,数量其次:如果能研发一个一年销售50亿的“明星”药品,肯定比一年发明超过50个‘一般’药品 (年销售2000~3000万)好。

团队有自主权,自我管理(Partnership with the People)

1.定义任务
2.专注
3.定义性能质量

如果我们能一步步完善以上三点,就应该不难,与上一个世纪一样,大大提高服务的生产力。

以上3点能否有效,取决于管理者能否把知识工作者当成“资产”,而不是“成本”。

不能再像以前,把工人只是当作一双手,知识工作者要与前线人员团队合作,才有效。有不少公司,比如IBM一直都有已经采取这种方式多年。日本的工业也一样,本来企业家以为可以继续用二战前那种专制的管理方式,但引起很多罢工,后面也改了。在以前工业生产时代,管理者与前线团队互相合作,支持他们只是一种最佳实践,但现代,这是唯一的方式。

学习环境(Learning Environment)

管理者要支撑支持前线人员组成自主团队。让他们不断改善服务,达到目标。现代,业务环境快速变化,服务人员也要终身学习才跟得上。培训只是开头,更重要的是他们如何把学到的用于工作中。如果每个人都当内部讲师,不仅仅其他员工受益,讲师本身也受益,进步。比如,找某明星销售人员,让他在全国的年会分享成功经验,教大家怎么做好市场工作,培训过程中,他自己也会思考那些是成功要素,更进步。

对软件开发的启发

你觉得以上德鲁克先生在1991年针对如何提升知识工作者生产率[1]的建议,适用于软件开发吗?下面每一点看看:

任务是什么

上面的例子:处理保险申报、百货公司邮购等,都是精益(Lean)概念,把有限精力放在最有价值的东西,减少浪费。2000年,17位软件开发大师针对软件开发问题,如项目延期、失败等问题,发表了敏捷宣言,包括:

  • 不浪费时间写一些对客户没价值的文档,专心写好代码。

  • 不浪费时间做一个三个月的详细项目计划。而集中精力把后面两周可以做到什么详细计划好。

  • 每一轮两周冲刺后,与客户沟通,得到反馈才知道哪些开发出来的是对客户有价值,哪些不是客户要到便立马停止。不像以前等到整个瀑布式开发,最终交付才知道。

  • 极限编程(eXtreme Programming,敏捷的一种)提倡测试驱动开发TDD,道理也一样,如果你这个小程序模块,没测试好就集成到整个系统中,后面会产生很多无谓的返工,必须每个模块都先测试好。

这些背后都是精益,越来越多软件研发项目使用敏捷开发。

专心工作,不分心

最近周末抽空编写Python小程序。
但因很久没编码了,所以一天能完成的程序不多,几十行代码。但发现编写程序需要很高的专注力,原因很简单,写文章就算有错别字人家还可以看得懂,但写程序错了一个字就跑不通了。所以我每写一段代码都会依据TDD原则,写十来行就用一个小模块就去测试。这样才可按计划完成当天要完成的练习题。
所以不要分心这点在软件开发特别重要。
但很多开发人员都要同时兼顾4-5个项目,还要维护一些老项目的出厂后的缺陷,其中有些更要紧急处理。可想象这些开发人员如何能专心写好程序?但不专注便很容易引起后面返工。

确保质量

如何提升软件开发质量?最终还是取决于代码质量。如果代码本身写不好,测试多完美,质量不会好到哪里。需求没做好也是常常影响质量的问题,大量的变更也会影响代码质量。

不要以为把质量做好,会影响生产率。其实生产率不会下降,反而会提高。( 我们过去几年利用量化敏捷管理帮助一些敏捷团队,确实验证了我们帮助团队注意,提高代码质量,降低交付后的缺陷率,生产率没有下降,反而提升。)

所以管理者必须重视并关注软件开发质量。

怎样衡量

怎样衡量保险公司,百货公司,药厂等的生产率都很明确, 但如何衡量软件开发生产率一直有争议,大家只知道不应该数代码行数。
如果你请开发团队对一个新的开发项目做估算,他们听完需求后告诉你,估计需要三到四个人月。
但人月不是规模大小,它是工作量。这表示估算时已经假定了团队的生产率。
也正因为没有衡量规模,导致软件开发团队没有提升生产率的动力,为什么?
道理很简单,如果同样开发一新软件,某团队创新新方法,可以把三个人月的工作减少到两个人月,但客户不会给你三个人月的钱,因为你只用了两个人月,只按两个人月付费。
没有度量就没有管理,所以必须要能衡量软件规模,才可以谈如何提升生产率。
前面提到敏捷能精益原理帮助软件开发提升,但如果你问敏捷开发团队过去几年生产率提升多少?我估计你得不到答案。原因是敏捷从2000年开始,都集中说编码开发的最佳实践,缺乏可比的规模单位。
很多敏捷团队使用故事点(Story point),但一个公司的故事点跟另外一个公司的故事的无法比较,甚至一个公司里面团队A跟团队B之间的故事点也比不了。
但如果使用功能点估算规模,团队之间的生产率,缺陷率等便可比。
你可能问“功能点我们都听过,其实七十年代都已经出来了,但会如果你说的这么好,为什么这么多年都不能在软件行业普及?”
原因很简单,本来的传统功能点如 IFPUG 、 NESMA,主要用来结算,不是用来估算。结算就是当你已经完成产品开发,按每一个页面有多少输入输出,多复杂等等,计算算这个软件的规模大小。但实际上,在现在这个千变万化的年代,你有多少项目可以一开始就有明确需求?绝无仅有。大部分时候,客户也不一定完全了解他要什么,只可以说给你一个大致的概念,常需要用一两个月时间逐步的边开发边了解,逐渐明确。
所以团队很难使用传统功能点,来做规模估算;但近几年,使用功能点结算越来越及,很多政府已经规定使用功能点来客观衡量软件规模大小。
针对传统的功能点算法难以用于早期项目估算这困难,我们有一套量化敏捷开发方法(类似简化功能点),按照需求的“实体”数和“行为”数做规模估算,补充敏捷开发缺乏可比规模的不足。估出来功能点虽然与传统功能点数有偏差,但因敏捷每冲刺只是2-4周,精确度不需要像以前瀑布式开发那么准。
现在科技发达,越来越多工具可以帮我们在开发完以后,从实际的开发完的代码去反过来算这个项目的实际功能点数(算实体、行为有多少)。

总结

有些软件开发公司可能一直收集很多缺陷统计、工作量统计、进度统计等,但是如果缺乏规模,还是无法判断生产率和质量。所以这个是软件开发规模度量提升生产力的第一步。

有度量,便可以尝试创新和改善,例如自动化。
有些公司已经开始探讨用自动化测试去提升生产率。我们的经验是,不少公司还是半途而废,最后失败。

如果高层有很高要求,例如不能增加人手,生产率便必须提高,这种环境导致团队必须转成自动化,自动化测试便会成功,但反过来,测试说千万个理由,很难用自动化,测试人员继续增加,越来越多反对声音,长久还会回到手工测试,生产率难以提升。正如德鲁克先生所说,如要有提升,必须抛弃老的方式,终身学习,把自己的技术提升。更重要是管理层有很高的要求 和 坚持。

反馈

一北京资深董事:
大工业时代,实际上也是标准化产品大规模生产时代,既能保证质量,边际成本也很低。信息化时代,既有类似的通用软件产品,还有专门满足个性化需求的解决方案,我们属于后者。怎么在非标的解决方案交付中做出盈利和规模,是个问题。我们的思考是:一要有产品化思维,采用平台化技术尽可能提高复用模块的思路,唯有这样才能保证交付时间、成本、质量;二是提高人的素质;三是采用科学规范的过程管理。

一上海总监:
文章中关于lean的解读很好,我们作为电子政务软件提供商,曾经很长一段时间都在努力追求工作交付物的标准化,如果大功能点不能标准化,就拆解成小功能点,以确保最小单位是标准化的,这样我们在不同项目中可以快速适应需求的变更。后面我们发现这样的努力,年复一年,效果不好,我们标准化的努力永远跟不上变更的速度。所以,我们转变了方法,只对客户看不见的技术底座进行标准化,看得见的部分,需求往往多变,我们追求需求引导能力和快速响应能力,这样我们在这种转变之后,对项目交付生命周期中的一些环节,比如需求评审环节更注重,而对功能组件的细分减少了投入。

一杭州高级经理:
宋老师好,刚刚认真看了几篇文章,发现每次看您的文章都深受启发,受益匪浅!首先,关于信息化方面,我觉得内部信息是公司自我提升的基础,外部信息是公司发展壮大的支撑。而建立一个公司级的信息化平台(包含市场、项目等等数据)又是较为复杂和庞大的工作,但相信,只要领导支持,公司信息化会越来越顺利,公司发展也会越来越成功。其次,关于生产率,我认为除了利用工具保证个人或团队的工作效率外,最重要还是我们自身对工作的态度,每个个体不同,对工作的认识也不同,所以我更看重的是自我管理,态度不认真,用再好的工具也是白搭。

一北京项目总监:
从德鲁克对知识工作者生产率的描述,引申出工作生产率提升的基本要素是 任务的描述、专心工作、质量的重要性,这一点,在中国人看来,也和中国人内心的修养有关,首先强调自我任务的识别,自我专心工作,自我质量的控制。从这一点看,中、外对生产率的认识是一致的,或者在对知识工作者这个高级工作者群体上,达成了一致。

References

1. Drucker, P.: "The new Productivity Challenge" HBR Nov-Dec, 1991.
2, Drucker, P.: 21 世纪的管理挑战 Management Challenges for the 21st Century


关注公众号可查看往期文章:


联系我们

电话:18921395967
QQ:1228021190
微信:processis2009
地址:香港/北京/江苏
官网:www.processis.org
邮箱:claire@processis.org