再读德鲁克#3 从管理外包人员到全面质量管理
|
有一家电力行业的软件开发部，因为要控制全职员工的人数，所以很多开发人员都是以外包形式聘用，以下这个表是我们抽看的三个项目的数据，第一列是这个项目的功能点数，倒数第二列是项目的缺陷数。  可以看出，项目的缺陷密度差异很大。与第一个项目团队沟通，发现写完代码没有单元测试，也没有评审代码，所以估计系统测试缺陷密度这么低，并不表示代码质量好，只是测试力度不够(项目1本来报给我的测试用例数是34，后来再说227才对)。 |
从以上的例子，就看到如果项目管理不善，质量问题可以很严重。
下面我们先回顾德鲁克先生2002年'They are not Employees,they are people'文章[1]的重点，然后再探讨管理者如何提高知识工作者的质量与生产率。
临时工（Temp） 与 专业雇主组织
临时工（Temp）这行业早在50年代开始崛起，开始的时候主要负责一些简单岗位：文员、前台、电话操作员等，后来慢慢扩大到各种岗位，甚至总裁都有临时工。
专业雇主组织 Professional employee organization (PEO)
曾经，有顾问公司统计过一般公司管理员工的成本，约占总成本的25%~30%，所以如果有公司可以帮企业省去这部分成本，企业肯定愿意。这就是PEO公司的商业模式，它在90年代快速崛起，主要为客户提供企业管理人员，包括行政、人事等。
这两类公司为企业创造什么价值？为什么这么受欢迎？
德鲁克先生用一个小型医院为例：一家有三百个病床规模的医院，大概有3000员工。其中有一半多是专业的知识工作者，除了医生、护士外、还有其他很多辅助角色：如物理治疗、化验、X光等专业岗位，但在这类医院里，每个专业可能只需要几位。医院的主管也不可能每个专业都懂，他如何管理手下各种专业人员呢？而且由于每个专业的人数不多，升迁的机会也几乎是零。例如，这医院的化验室专员全院只有三位，没有任何上升机会。但如果这些专业人员是受聘于PEO外包公司，有能力化验人员可能会被调到一些更大的医院去。而这些人也愿意用这种形式去服务医院。
这种现象也不仅仅适用于医院，一些百货公司、金融服务公司也常用这种方式，以获得专业性强的员工。所以这种无论临时工公司或者PEO公司，无论对员工或者雇主都有价值和吸引力。
这些Temp供应商 和 PEO 说能帮助企业管理员工，提升效率。你相信吗？让我们先听听大陆软件开发的管理者 和 临时工的 心声：
外包问题
| 某北京IT总监的外包心得分享：
1.外包的主因是降低风险 |
不少企业为了控制全职员工人数，会把软件开发项目外包出去。
但承包商人员水平与积极性难以保证，很可能导致软件质量出问题。
部分公司内IT员工的心声：
通过外包途径招聘人员的技能、质量不太能够符合项目要求，需要花费大量时间、精力去做培训，希望公司招聘外包人员时，考虑人员质量，解决项目实际人员需求。
外包公司写的代码质量与我们自己写的相差甚远，也没有做单元测试，没有做静态代码检测，写完代码也没有做人工走查，导致我们后面很多返工。
最大的问题是项目成就/责任感低，能少做的尽量不多做。因太多因素影响项目总体成败，我们（承包商）认为只要完成SOW里的内容就算项目成功。
虽然公司经常组织学习甲方的产品，培训考试，项目质量主要由发包商项目经理(PM)控制，我们对项目质量关注度少，主要听PM安排。
部分外包承包商员工的心声：
[SOW=Statement Of Work 可简单理解成项目需求范围 ]
知识工作者 与 系统
“现代企业都依赖知识型团队， 比较50年前以劳工为主的企业， 更需要关注每一个员工的健康成长。知识工作者最能为公司产生价值。甚至企业的成败也依赖于知识工作者的表现。
企业不可能大量招聘卓越的人，所以管理者的挑战是如何使普通人做出超凡的事。好比杰出的指挥家能领导一普通乐团演奏出非凡的乐章。”
公司的创新大部分依赖于知识工作者，所以我们无论是用外包形式或者正常聘用，知识工作者是企业的核心资源(capital)。
以前的工业时代，是劳动者支撑系统制造产品，在当今的知识型社会恰恰相反，企业系统要支持知识工作者，让他们能发挥效益。
从外包人员的心声，和其产出软件的质量，都能觉得他们当中的很多人缺乏积极性。所以不要以为单靠加强培训就会有效果。
具体有什么方法呢？
|
一家工厂舍弃了传送带生产方式,学习丰田生产方式(Toyota Production System TPS)，权力下放给一线员工。企业总工有以下感想: ..去巡视生产现场的时候,有一位女员工对我说：'以前每一次往生产线跟前一坐,我满脑子就都是怎么还不到5点呢?但现在上班成为一件让人高兴的事。' 听了她的话以后,我更加相信生产改革的方向没有走错。..
|
为什么丰田生产方式这'系统'能改变生产现场员工的积极性?
丰田故事
二战后50年代,丰田汽车规模很小，经营很困难，在破产边缘。但丰田英二先生明白美国批量生产线的弊端，意识到未来的汽车生产必须是Just-In-Time：
每一辆都是按客人订单订制：例如，颜色，配置，左右钛等
从钢材原料开始，整个生产线，零等待，零浪费
每个工作步骤所需配件按生产需要到达 （不晚，也不早到），把生产过程中的配件降到零
安排总工大野耐一去美国汽车公司考察， 他从美国的超市（非汽车公司）得到如何做Just-In-Time的启发。回国后就开始在丰田致力推动。
开始时，很多人都觉得这个愿景好像是远不可及的梦想。今天Just-In-Time已成为汽车制造的主流，例如：日产在英国牛津(Oxfordshire)专门生产mini 车的 工厂便能做到：
每天生产1000辆车
每68秒出一辆
从钢材原料开始，整个生产线没有任何中间等候，24小时后便生产出汽车
管理外包人员的挑战
问：我们不是讨论如何管理软件开发外包人员吗？为什么转到讨论丰田生产方式？我们都不是生产业，有什么关系？
答：德鲁克先生2002年的文章强调：不能依赖外包公司帮你管理， 还是必须靠管理者自己。
很多软件开发公司缺乏相关度量。例如，只管项目有没有延误，客户有没有投诉等水面上看得见的东西；但不知道生产率(每人每天生多少功能点)/现在是什么水平等水面以下看不见的情况。没有度量就无法谈改进，无法管理。
管理者也不能仅看表面的数据，如项目延误，成本是否超支，更需要看过程中知识工作者的生产率和质量是否有提升。
外包人员每天工作都是被动地应付客户的投诉；只想被安排的任务不延误，不会想怎样提升整个开发的效率与质量。工作自然没有动力。
反过来，如果大家都知道自己的生产率水平， 像丰田有具体的阶段改进目标。管理者辅导团队如何利用智慧，找出问题的根因，实施应对措施，看能否达到预期提高（而不是靠喊'要努力，努力’）。公司便可以生产出更多新产品，使客户满意，增加收入, 公司根据各团队贡献，鼓励团队分享成果,形成持续改进(PDCA)良性循环。
有这类“系统”才能根治外包人员的管理问题。
为什么丰田能成功地把汽车生产做到 Just-In-Time ，超越西方的巨头，使日本汽车制造过程成为世界'标准'？但我们不能单从表面看这'系统'的方法和技巧，例如大家都熟悉的看板管理（他的竞争对手通用、福特、肯定都学过），所以更重要是了解背后的管理思路:
以忙碌为耻
不吝惜智慧，但要吝惜汗水
从心里相信“大家的力量”
不是靠“一个不平凡的人”，而是依靠“一百个平凡人”来创造亮眼的成绩
生产产品就是培养人才
“做事业最关键是人.......'培养人才'为基础”总裁丰田英二先生
有一位丰田员工被问到“丰田生产方式到底是什么”的时候,这样回答: “就是在人的智慧建起的基础上,立起了自动化和及时生产这两根支柱。”
他所说的“人的智慧”是指“在一线工作人员的智慧”。
不以“我们公司”作主语
不是从“专业”的角度，而是从“顾客”的角度生产产品
创业大忌 - 闭门造车,所以丰田的原则，对客户有用就一定做出来，但对客户无用，或者不想要，就绝不生产。
很多软件公司现在已经开始从以前的瀑布式开发(几个月后才有产品出来),变成敏捷冲刺，每2周便与客户回顾，看是否是他们要的东西。我们QAD的方式基于SCRUM的基础上，也要求客户把需求分成“实体”与“行为”写需求，自动计算功能点数，也帮助开发人员减少误解客户需求。
标杆管理 (Benchmarking)
丰田（如下图）很注重各种标杆，例如内部标杆、竞争性标杆等。软件开发也应该同样利用数据来制定量化目标，例如生产率。最近行业也要求做功能点估算来统一软件报价，有了功能点，团队就可以利用它来衡量软件团队的生产率，它也有不同行业的标杆做参考。
收集每迭代项目数据，建立标杆
我们要求每个迭代项目组都需要提供数据，填进模板中，开始时因公司还没有历史数据的基线，我们就借用行业数据，从下图看到C#编码的有效率都是很好（绿色）
因各项目的数据都会汇总在一个公司级的数据表，每个项目组不仅仅看到自己的表现，也可以看到其他项目组的情况。
建立公司标杆不能单靠数据分析员一个人分析判断，而是应由过程改进组与所有相关项目经理一起讨论：
展示（投影)项目多轮迭代数据
这些不同项目的数据类似吗？还是差异大,要分开定基线？
里面有些离散点数据？为什么？
数据准不准确？合不合理？
这样才可以知道数据是否正确，标杆/基线是否适用于项目?
容易实现的目标不是好目标
不是“削减一成”，而是通过“取消一个零”来发现浪费
不追究责任，而是追究原因
丰田的大野耐一先生说：
做到一半是不行的，只有一个期限，“到完成为止”
当工程师报了有问题就必须要求工程师查找原因、提供数据，但很多时候这个工作并不简单，但大野耐一先生决不放弃，必须找到根因。
我们辅导量化敏捷开发, 每迭代回顾都要收集数据，并做根因分析：在软件开发，当遗漏到系统测试的缺陷多，便要做讨论，探讨是什么原因？例如：是开发质量问题或测试力度不够，开发的编码有不良习惯，例如拷贝代码，用很大的类等（详见附件A'软件开发质量')。针对代码质量问题，团队便做培训，用新的方式看看会不会有改善？
同样，本来自动化测试的效率在头2、3个迭代都是比较弱（粉红）的，我们与测试人员探讨自动化测试脚本的不足，并针对改善后，后面的迭代就有显著改善(绿)。
预防同类问题再发生
有一家专门做电力的软件公司，它为了加快发布的频率，已经在2年前开始做到每2周自动发布，但他们还是很关注发布的质量，所以发布前都有多轮的审批，确保质量，才允许发布。
如果项目经理赶不上某次发布的，他们就会走一个失效分析 (FMEA)，回顾整个过程，哪步出问题？背后什么原因？如何避免同样的问题以后发生。
成长比成功更重要
要培养人才，“改变体制”比“改变人”更有效
有些工厂只依赖张贴标语、海报，希望可以减少工地的事故发生率，但丰田不注重喊口号，而是动手干实事，包括机械保安、设备保安等
| 叫人做之前自己先做一遍给他们看
本田技研工业在中国创立广州本田的时候,派往当地的都是即将退休的经验丰富的中高年龄层技术人员,这批技术人员成为了厂里的中坚力量。正因为他们的努力,广州的本田工程才获得了成功。 |
软件开发如何确保质量？比如一个团队有些新人，绝不能简单分派任务，让他自己随意写代码，组长要先想好整个架构，主要有哪些类，之间有什么关系，每个方法和类要注释说明，然后分配给新手去执行，避免事后返工。学校里编码练习也不会只描述需求，通常会指出需要那些类、方法，有什么作用，防止学生走偏。
但软件开发人员的能力有高低之别，如何让新手可以跟高手有效学习呢？代码评审其实是很有效的培训，比单靠讲课更有效。我们会建议团队按高手的时间来安排评审，让新手从中学习。不一定预定在哪天哪时，以便减少对高手时间安排的影响（他时间宝贵），也能取得培训效果。
所有人参与改进
| 带诚意去赢得协作
B先生所在的A公司曾以丰田生产方式为基础进行了生产改革。 于是B先生去找大野先生,在听他诉说了自己面临的窘境以后,大野先生对他说: “你这一两天跟我一起去工厂转转吧!”并于百忙之中抽出时间带B先生参观了丰田的工厂以及附近的协作企业的工厂。这期间,大野先生什么话都没说,只在第二天下午问B先生:“怎么样,你明白了吗?” 从那以后, B先生再也不找“因为我手里没有权力”之类的借口,而总是带着诚意去找对方协商,不久以后,他成功地对A公司实施了生产改革。 |
我们开始要求企业拿出试点项目来做量化敏捷开发（QAD）时，阻力也很大，我们只好挑一些愿意并有能力的先锋团队。过了几个月后，其他本来观望的项目组看到确实有效，也愿意加入。所以在公司推动过程改进必须先试点后推广。
因为与以往的做法截然不同，必须经历：
学习 - 尝试 - 学习 - 尝试执行
不断循环才开始把握。团队也会问老师收集了几轮数据了。不知道有什么用处？但我们不直接给答案，而是重新提醒他们各种学过的分析技巧与方法，让他们自己尝试找答案。
反过来，如果团队没有经历这个过程，只遵循老师制定的一套固定方法，项目组很可能评估过后，便恢复以前，不能持续。
推动量化敏捷开发也一样,不能单依赖一套固定方法，我们利用CMMI量化管理的实践重点，例如量化目标、度量可操作定义、基线预测模型等。首先教他们用简化功能点，使每个团队都有可比的规模大小基数，然后让他们收集每一迭代的缺陷数，工作量和一些可控因素，引导他们如何分析这些迭代数据，制定本项目的下一迭代的量化目标。虽然我们会提供一些统计分析的技巧，给他们参考，但是还靠项目经理与团队自己讨论，看用什么方式达到量化项目管理的要求。
总结
这3篇'再读德鲁克'，从信息化挑战开始，我们探讨管理者应如何做好数字化、智能化管理，收集哪些数据，帮助企业管理。然后我们再回顾有哪些方法，可以帮助知识工作者提高效率和质量。这篇我们从管理外包的问题开始，引申到丰田生产方式的一些案例，了解管理者的'系统'。
丰田故事让我们看到“系统”如何帮公司培养知识工作者，发挥人的无限智慧， 为公司增值。
汽车制造大部分利用自动化机器，但当今软件开发生产和质量， 非常依赖开发人员的水平， 所以我们更需要建立“系统”，帮助员工快速成长。
前面分享的九个丰田管理思路，其实都能在软件产品开发用上：
以忙碌为耻
培养人才 - 逼他们动脑筋
从心里相信“大家的力量”
不以“我们公司”作主语
标杆管理 (Benchmarking)
容易实现的目标不是好目标
根因分析
成长比成功更重要
所有人参与改进
在互联网年代，数字化管理已经不是未来，在软件产品开发，很多公司已经从以往的瀑布型开发模式转为敏捷开发，以便更好反应客户的需求变化，也让团队效率提升到极限。
2周一冲刺比以往几个月才完成一个项目，本应可以收集十倍的数据（假如项目平均5个月），但碍于敏捷方法缺乏一套度量标准，公司无法形成基线 / 标杆。
4年前,我们开始为企业推动量化敏捷开发(QAD)，团队就可以基于功能点的生产率与质量基线，并在6 - 9个月时间，利用对可控因子的根因分析，可以把缺陷率减半。
从我们过去三年，针对那些已经使用敏捷SCRUM开发的软件开发公司,辅导团队提升到量化敏捷开发， 但管理层千万不要以为这个改变过程轻松、 快速。正好相反， 任何文化的改变都会遇到很大阻力，但只要管理深信必需建立这个“系统”，破釜沉舟，才有希望成为大陆软件开发未来的“丰田”！
反馈
| 上海一总监问：
'可否说明一下市面流行的敏捷开发(如 SCRUM ) , 如何分配任务 , 有那些方法？' |
敏捷一般建议基于I.N.V.E.S.T.原则把需求分解成用户故事。
Independent (from other user stories)
Negotiable (on how to implement)
Valuable (for customers)
Estimable
Small (to complete in a Sprint)
Testable
但具体怎么分每个人可能有不同的想法,而且用故事点 估计规模大小， 但故事点只是项目组自己的定义，不同团队间无法比较，难以利用各项目度量数据，建立公司标杆（基线）。
针对以上不足， 也方便开发/测试能与需求打通, 和团队使用功能点作为规模，估算工作量 / 工期。
我们会教团队按场景(Scenario) 、 实体(Entity) ，行为(Activity)写需求。以便与开发工作 / 测试工作对应。
（实例 注：实体浅蓝色，有框）
团队便容易把与行为对应的开发任务，按优先级，安排到各冲刺中。测试人员也可以从而估算出测试用例数，测试工作量，甚至缺陷数范围。敏捷团队从定性管理，升到定量管理。
References
1. Drucker, P.: 'They are not Employees, They're People' HBR Feb. 2002.
2. Yoshihito Wakamatsu 若松义人: '为什么是丰田' 2007