第4章 研发企业的常见问题与系统性解决方法
4.1 软硬件研发企业的常见问题
4.1.1软件挣钱难的问题
千万不要以为做软件是挣大钱、一本万利的事情。中国目前绝大多数软件企业过着苦日子。软件企业主要有三类盈利模式:
一、承接合同项目,为甲方开发软件系统。
如果软件公司从自由市场上承接合同项目,将遭遇如下困难:
(1)能承接合同项目的软件公司乃至个体户实在太多了,客户会把合同项目的金额砍得很低,单个项目的利润空间本身就小。
(2)项目需求和验收受制于客户。开发过程中,客户会不断变更需求,导致开发方不断修改软件,项目验收被不断地延后,开发方成本(包括机会成本)越来越高。
(3)缺乏规模复制效益。由于合同项目都是针对特定客户(甲方)的特定需求而签订的,即使做成功了一个合同项目,也很难“复制这个项目”直接卖给下一个客户。几乎每个合同项目,开发方都要重新经历“营销、开发、验收和收款过程”。
结局是开发方疲惫不堪地做完项目,挣点养家糊口的小钱,接着干下一个项目。
当我们看到报道,说印度大型独立软件开发商如Infosys,能够承接几亿英镑的信息化项目,不仅眼红而感叹:中国何时有这等实力的独立软件开发商啊!
钱绝对不是问题。几亿英镑算什么,中国上百亿元、上千亿元的项目多的是。花数百万元、数千万元,给一些政府机构做个网站,这样技术含量极低、利润极高的信息化项目简直多得数不过来。
2011年某部花了数千万元开发了火车票订票系统,结果春运几天就瘫痪了,老百姓骂声一片。于是来年再花上亿元重新开发,现在还不知实际运行情况如何,至少证明一点:有的是钱。
问题在于,凡是金额很高、利润极高的信息化项目,基本上都被有权势的人或机构垄断了。社会公共财富的大部分被有权势、却不干活的人或机构瓜分了,最后分点骨头渣子给无权势的软件公司,去干苦力活,挣苦力钱。
这就是中国目前不缺钱、不缺技术、人不笨不懒,却没有强大独立软件开发商的根本原因。这个问题要靠中国法制建设、体制改革来逐步解决。
二、开发并销售通用软件产品
以中国人的聪明才智和巧劲,做软件产品似乎是很好的出路,可实际上这条道路快没有人走了。
凡是面向个人的通用软件产品,由于盗版原因,几乎无法靠卖软件来挣钱,这条财路已经断了,只能改变盈利模式。
只有企业级软件产品,因其推广使用错综复杂而不容易被大量盗版,可以走“通用软件产品盈利模式”。想做好通用的企业级软件产品,难度非常高,不是会编程就可以的。因为企业级软件的需求复杂度远远高于面向个人的软件。开发方必须把自己打造成为“企业级应用的领导者”,否则潜在客户不信任你的方法和产品,那么产品就无法通用。于是客户提出的个性化需求越来越多,开发方做着做着,就回到了“合同项目盈利模式”。
三、运营模式
不承接合同项目,也不卖软件产品,而是通过互联网或移动通信网做运营,靠用户频繁使用软件来盈利。
理论上,运营模式比合同项目模式和通用产品模式更加先进。中国已经有一些很成功的互联网企业,例如腾讯、阿里巴巴、百度、新浪、搜狐、网易、盛大等。成功者很辉煌,引得众人追捧。主要问题:
(1)互联网公司的业务太容易被模仿,同质化竞争严重。每个领域都死掉了成千上万个相似业务的互联网公司,最终只有少数几家可以活下来,极大地浪费社会财富。
(2)互联网公司的另一个大缺点是太浮躁,过分追求快而导致根基不扎实,它们的口号是“互联网公司的3个月相当于传统软件公司的3年”。据我所知,国内绝大多数互联网公司的软件研发管理,要比传统软件公司混乱得多。
任何一个软件产品,诞生它就要花上一年半载,推向市场后还要花多年心血才能把它真正做好。就如人类怀胎需十个月,把人培养好至少花十几年。如果非得要在一个月内就生出来,那只能生下一窝老鼠。
小结:
软件企业要想多挣点钱,就要设法“开源节流”。“开源”主要靠优化盈利模式,使得现有的技术和资源产生更高的效益。“节流”主要靠改进管理,使企业的所有经营环节更加合理,减少不必要的成本,省下来的钱也就成了利润。
关于盈利模式的问题和对策,详见第5章“盈利模式与核心竞争力”。
4.1.2组织结构和人力资源问题
组织结构常见问题:
(1)组织结构臃肿,工作效率低下。
(2)岗位和职责不清晰,而且经常变动,好多人不清楚自己的岗位和主要职责。责、权、利不明。
(3)项目矩阵关系比较复杂,项目成员不知道听“职能经理”还是“项目经理”指挥。
人力资源的常见问题:
(1)不能知人善用,无法发挥团队中每个人的价值,老抱怨员工素质低。
(2)重要岗位用错人,例如把技术水平很高,但是情商低的人提拔到领导职位。不仅荒废了这个技术高手,而且带乱了队伍。
(3)优秀人才难招到,也难以留住。
(4)难以准确地评价研发人员的业绩,缺乏有效激励措施。
关于组织结构人力资源的问题和对策,详见第6章“研发企业人力资源管理”。
4.1.3跨部门协作问题
企业重要的部门如“研发、营销、服务”普遍存在跨部门协作问题:
(1)跨部门人员相互不熟悉对方的工作流程和规范,沟通费劲。
(2)上游传达给下游的需求不够清楚,各方理解有偏差,上游不断变更需求,导致下游不断修改工作成果,频繁浪费。
(3)上游不能及时了解下游的工作进展情况和负荷,不断传达新的任务,下游忙不过来。
(4)由于各部门的目标和利益不同,导致跨部门合作产生矛盾。例如营销部门为了使客户满意、增大销售额,答应了客户太多的需求,或者承接了过多低效益的项目,致使研发部门耗尽有限资源,疲于奔命,哪个项目都做不好。
企业不仅要让每个部门制定内部工作流程,还要把各部门的流程整合起来,形成整个企业的集成化流程。跨部门协作的接口人,不仅要熟知本部门的流程,而且还要了解对方部门的流程,才能够主动灵活地处理比较复杂的跨部门问题。下游一定要有制约上游的机制,否则上游没有做好工作,将使苦难堆积到下游。
本书论述的集成化研发流程(IDP)主要用途之一就是解决跨部门协作问题,详见第11章至第15章。
4.1.5需求问题
客户方的主要问题:客户说不清楚需求,客户经常变更需求。
在国内,客户说不清楚需求、不断变更需求是普遍现象。客户想到啥就说啥,没有系统性和逻辑,今天记不得昨天说了什么;客户说的需求有真有假(伪需求),甚至相互矛盾;即使你费了九牛二虎之力把客户说的话全部都做了,他也不会满意,因为那不是他真正想要的东西,客户还会不断提出新的需求。……
上述问题把开发方弄得疲惫不堪,开发人员们梦想:要是客户能够说清楚需求、不变更需求,那该多好啊?
要真是这样,那才惨那!
如果客户自己把最难的事情都做了,还用得着请软件公司来开发?我们都没有饭吃啦!所以不要抱怨“客户说不清楚需求、客户经常变更需求”,就如医生不能抱怨病人生病一样。
开发方的主要问题:
(1)没有熟练掌握需求工程的各项技能,如需求调研、需求分析、需求定义、需求评审、需求跟踪、需求变更控制等。开发人员在大学里面学了软件工程,教科书里讲的是去头掐尾的需求分析方法,在现实工作中是不够用的,仅仅是需求工程中的1/6活动。
(2)研发企业没有在战略高度上重视“领域需求研究”,仅仅把需求分析当做项目中的一个环节看待。每个项目都从零开始做需求分析,被动地等待客户提出需求、变更需求。而没有主动研究领域需求,提炼出领域需求知识财富,从而引导客户消费。
本书第12章“集成化研发流程之项目研发过程”讲述“需求工程”的一般性方法。第14章“消费者研究和产品概念设计”则更加深入,通过观察分析消费者的言行举止,发掘消费者深层次的需求(或问题),然后创作产品来满足该需求(或解决该问题)。
4.1.6设计和开发问题
技术架构和平台策略问题:
(1)同一系列的产品、甚至一个产品之内,采用了多种编程语言,和多种差异较大的技术。受制于原有的落后技术,先进技术难以无缝引入。若放弃老技术,用新技术重做,风险太大,不敢。若放弃新技术,延后老技术开发新功能,又不甘心。企业需优化技术方案,既不妨碍老客户和当前客户使用(试用)产品,又要使新技术尽快在不久的将来产生更高的效益。
(2)在很多项目中重复地开发相似的功能,互不通用,浪费生产力。没有提炼标准件,没有建设公共技术平台,就无法取得软件复用带来的高效率和高质量。
软件设计问题:
(1)软件用户界面设计是大多数软件公司的弱项,人们不知道怎样才能设计出易用、美观的用户界面,凭着个人的经验与感觉设计软件的用户界面,这样产生的界面往往得不到大众用户的认可。
(2)只关心功能设计,却不会综合考虑产品的性能、可扩展性、可复用性等。
(3)软件设计应当“细到什么程度”很难把握。太粗了的话,对后续开发工作的指导价值不高;反之倘若太细的话,耗费时间就比较多,如果后面不断改进设计的话,前面的设计浪费太多。
软件实现问题:
(1)程序员的编程风格差异较大,代码质量有高有低。大多数软件机构没有编程规范,即使有的话,程序员也没有很好地按规范编程。
(2)相当多的程序员没有养成自我测试的习惯,尤其是对自己代码进行“单步跟踪调试”的习惯。等到测试人员发现Bug之后自己再去改错,此时改错的代价已经增加了很多倍。
4.1.7项目管理问题
软硬件研发项目管理的独特之处是,它是建立在软件工程基础之上的专业化项目管理。一个没有软件工程经验的人,即使他通读PMBOK,哪怕是MBA毕业,也管不好软硬件研发项目。
大多数研发企业的项目管理可以用“三拍”来概括:领导拍脑袋做决定;项目经理拍胸脯作保证;员工拍屁股后走人。
软硬件研发项目管理的范围主要包括:立项管理,结项管理,任务进度管理,项目评审,变更控制,软件质量管理,软件配置管理和文档管理等。每个领域都存在若干常见问题。
项目经理的问题:
(1)大多数项目经理是搞技术出身的,没有系统性地学习过软件项目管理。他们不知道究竟要管什么,更谈不上有好的管理方法,基本上靠自己的威望和感觉来管理项目。这种情况下,项目的进度和质量都难以预测。
(2)国内大部分项目经理有带头干活的权利和义务,他们对项目的进度和质量负最大责任,但是没有财务权。大部分项目没有经费,即使有经费,也得由上级领导审批使用,不能自己作主。有时团队加班干了不少活,项目经理却没有钱“意思意思”,很没有面子。由于项目经理没有财务权,他们就不会关心成本也不懂得如何控制成本。因管理混乱、工作效率低下、进度延误等问题导致“隐性成本”不断增加,钱在不知不觉地流失。
立项管理问题:
(1)自主产品的立项问题:没有“立项调研、可行性分析、立项评审”活动,主要靠公司领导独断;项目团队只知道干活,却不了解产品的开发背景和目标,不清楚用户期望的产品应该是什么样的;在开发过程中经常迷失方向,导致进度延误、费用超支等问题。
(2)合同项目的立项问题:客户需求不清晰、合同内容空洞;开发方在签订合同时给出了一些空头承诺(例如对进度、质量、费用的估计过于乐观),在实际执行时却难以兑现这些承诺。
结项管理问题:
(1)项目结束时,都记得要吃顿饭,却忘记了要总结知识财富、经验教训,以便用于下个项目。
(2)开发人员干完活后,不知道自己的工作成果产生多大的效益,缺乏成就感。不能对员工的业绩进行公正考核,不能很好地激励员工。
(3)项目团队解散后,原项目遗留的问题没有人处理了,把毛病留给客户。
任务进度问题:
(1)许多项目经理肩负重要的开发工作,他们往往把注意力集中在自己的开发工作上,却不知给组员们分配合适的任务。
(2)项目成员汇报工作时,记流水帐,应付了事。懒得动脑筋分析项目遇到的一些问题,例如某些任务的进度延误了,不分析为什么延误了,就顺延。导致问题越积越多。
(3)项目实际执行情况与原定的项目计划严重脱节,领导、客户、营销人员、开发团队都不了解项目真正的状况,项目计划形同虚设。
项目评审问题:
没有界定哪些是“决策评审”哪些是“技术评审”,没有清晰的评审准则和评审人员要求。每次评审会议都请来很多人,大家七嘴八舌,无法形成结论,浪费很多人的精力。
软件配置管理问题:
(1)有些软件公司竟然不使用软件配置管理工具(如SVN、CVS等),用最原始的“复制文件或覆盖文件”方式来保存代码和文档,经常出现“版本混乱、文件无法追溯历史”等低级问题。
(2)不少软件公司已经按照CMMI要求制定了软件配置管理规范,该规范在理论上比较完善,面面俱到,但是实际操作比较麻烦,没有突出重点。久而久之,人们厌烦后就逐渐放弃了规范,按自己的习惯来操作,留下了隐患。
质量管理问题:
(1)有些公司没有质量管理的流程制度,开发人员把完成功能当成终极目标。用户在使用过程中发现许多Bug,导致开发方的纠错性维护代价很高。
(2)有些公司虽然很重视质量管理,按照CMMI 的要求建立了流程制度,但是效果不明显。人们搞不清楚测试、技术评审、质量保证的作用和关系。不懂得内建高质量,却靠修补Bug的方式来提升质量,代价比较高。
(3)很多人误以为提高质量是质量部门的责任,没有意识到任何开发人员、管理人员都会对质量产生影响,都要对质量负责。另外,质量管理人员的权力比较小,很难推动质量改进措施。
(4)没有及时反省过错、预防犯相似的过错。例如在研发过程中不断地产生大量相似的缺陷,然后花费大量时间、精力找出缺陷,再消除缺陷,是巨大的浪费。
变更控制问题:
难以拒绝客户和上级领导的不合理变更要求,项目内部亦随意变更设计和代码等,严重影响项目的开发进度和质量。
4.1.7 产品研发管理问题
国内绝大多数软硬件研发企业从事“合同项目开发”,少数企业从事“产品研发”。产品研发管理的难度远高于合同项目管理。
主要问题之一:合同项目管理方法和经验不适用于产品研发管理
国内很多IT企业长期从事合同项目开发,有丰富的行业经验和不错的研发队伍,它们很想转型做通用产品。有个企业试了几次没有成功,老总问我是否有成功案例可供参考。尽管我拜访过很多IT企业,但是的确没有看到成功案例。老总就问为什么?
我不加思索地答复:做合同项目的公司都很忙,研发部天天被领导和客户催着干活,实在没有精力去做产品。
所有在场的高管们都深有同感,老总哈哈一笑,那就等咱们有空了,好好去做产品吧。
当天晚上我思考了一夜“为什么没有成功案例”。
第二天我见到老总,向他道歉说:昨天我说错了,“忙”只是表象。本质原因是,做合同项目的方式几乎不可能做出好产品。因为合同项目的开发者长期听客户的,没有自己的思想;而做产品必须要有思想,潜在客户接受了思想才会购买产品,否则就是废品。如果你公司有专家研究领域需求,提炼出思想,那么我帮你建立产品研发体系,可能做出好产品。
老总听了沉思一会儿,叹了一口气:我们做了很多年项目,积累了零零碎碎的经验,平时忙得没有精力去思考产品,谈何产品思想啊?看来不仅做产品的方法不对,而且人员的思想境界也不够,需要好好反省改进啊。
主要问题之二:国内现阶段极难找到称职的产品经理(产品负责人)
某IT公司领导向我请教:最近董事长很重视某某领域,我们过去的产品不够好,现在下决心重新做个好产品出来。公司已经任命了新的产品总监,他负责建立产品研发团队。希望您在产品研发方面给予一些指导帮助。
我问:产品总监是谁?做什么?
答:产品总监是董事长信得过的老朋友,他负责所有的管理,他已经把需要招聘的岗位清单列出来了,一名产品经理,一名系统架构师,N名开发工程师,若干测试工程师等。人员不够的话以后随时可以补充。
我问:产品经理是谁?
答:人力资源部正在招聘面试。
……
我把这个事情告诉本公司几位同事,请他们说说这个公司能否做出好产品?
大家答复:似乎没有看到领域专家和很好的设计师,产品成功的可能性很低,。
我说:不是“可能性很低”,而是绝无可能!因为产品总监和产品经理都不懂产品,而且这两个职位重复累赘、自相矛盾,他们能够如期做出平庸的产品都不错了。
大家问:你怎么知道他们不懂产品?
我答:如果产品总监懂产品的话,他就不会去招聘产品经理了。他一出手,就知道是个外行。
大家问:他们正在招聘产品经理呢,也许能够招到好的产品经理。
我答:企图让不懂产品的人力资源部去招聘很好的产品经理,这和买彩票一样不靠谱。优秀的产品经理既是产品思想家(或思考者),又是团队领导者(具备领导力),能够带领团队实现他的产品思想。所以绝大多数成功的产品经理通常就是公司老板自己,例如苹果的乔布斯,腾讯的马化腾,奇虎的周鸿祎。即使不是公司老板,那么也是老板三顾茅庐请来的优秀产品的创造者,例如张小龙,他入腾讯之前就已经开发了著名的Foxmail,多年来我上班时间都在用Foxmail,他入腾讯之后又开发了著名的微信,我不上班的时候经常用微信。若让人力资源部招聘一个人,给他按上产品总监或产品经理的头衔,不等于他具备这样的能力和权力。
大家问:为什么大部分研发企业的董事长、总经理、副总经理们不亲自去做产品呢?
我答:中国不少企业“把客户关系视为第一生产力”,企业高管们的心思、精力几乎全用于搞关系、走捷径了,决策者们情愿沉醉于酒肉(伤身),也不愿沉思于产品(伤脑),怎么可能研发出好产品?只有当中国企业不再成天巴结地方官员和权势客户了,市场会逼着企业用心去做好产品,那个时候研发管理方法、流程和工具才能发挥重要价值。
我谨慎地认为,本书论述的方法论,可以帮助中国研发企业了解产品研发管理的科学做法,至少可以起到启蒙教育作用。但即使有了很好的产品研发管理方法,那也无法保证企业一定能够做出好产品,好方法被合适的人用起来才能发挥价值。我强烈呼吁研发企业的创始人(他们是最懂产品的人)回归到产品研发第一线:亲自思考用户需求,亲自参与产品设计,亲自去做用户体验……,让他们去做对社会最有价值的事情。我相信这也是整个中国民族工业的渴望。
4.1.8管理工具问题
大部分研发企业没有对管理工具进行规划和统一部署。各部门、各项目采用自己熟悉的管理工具,分别用于管理客户问题需求、项目信息、任务进度、代码库、文档库、测试与缺陷跟踪等等,管理工具之间各不兼容,形成信息孤岛。有些工具很老旧了、不好用,但是有数据存在,既不能淘汰,又不能更新。结果这么多杂乱的工具非但成不了财富,反倒成了包袱,十分头痛。
企业需建设与流程配套的集成化管理平台,监控所有项目和人员的工作情况,不断积累知识财富,而且提供更高级的统计分析和决策依据。
小结:本节(4.1)所述问题在软硬件研发企业普遍存在,我们不要等到出了问题之后,再头痛医头、脚痛医脚。我们需要系统性的企业管理方法,避免常见问题一而再、再而三地发生。
早在1986年,美国PRTM公司创作了PACE(Product And Cycle-time Excellence,产品及周期优化)方法论。PACE关注的要素有:
Ø 正确决策
Ø 项目小组构成
Ø 开发活动的结构
Ø 开发工具与技术
Ø 产品战略
Ø 技术管理
Ø 资源管理
PACE算得上是产品生命周期和流程管理领域的方法论鼻祖。PACE诞生之后,很多企业和学术机构不断地提出了适合于本行业的研发管理方法论,概念和术语“之多、之大”令人眼花缭乱、茫然失措。
20世纪90年代初,IBM公司遭受了巨大的经营挫折,年亏损额高达80亿美元。为了摆脱经营困境,IBM实施了以系统性研发管理解决方案为核心的企业再造方案。IBM引进了PACE方法论,并获得了巨大的成功。从1993年到1998年总共节省了120亿美元的费用,产品平均开发周期由4年下降到16个月。在PACE的基础上,IBM总结了一套行之有效的产品开发模式,称之为IPD(Integrated Product Development,集成产品开发)。IBM不仅内部使用IPD,而且还把IPD方案卖给别的企业而赚了不少钱。
1999年,华为公司成为国内第一家引入PACE和IPD的大型企业,据说花费上亿元人民币,方案供应商自然是IBM。华为公司在推广IPD过程中遭遇重重困难,付出了高昂代价,最终评价是成功的。目前华为已经是国内最大的电信设备供应商,也可以说是国内最大、最好的高科技企业。在企业流程改进领域,华为创作了一句广为流传的名言:“先僵化,再优化,后固化”。
相似地,上海贝尔阿尔卡特为了建立适合自身发展需求的研发管理体系(类似于IPD),从2002年开始引入PACE方法论,公司在研发管理体系的投入累计达数千万元人民币。本人是该项目的Process Leader。
我和组员们最初接触PACE的时候,觉得神秘高深,很是仰慕。我们和PRTM公司的咨询师相处了3个多月,最大的工作成果是制订了“新产品开发流程”,如图4-1所示。有一天,我凝视着那幅花费了一百多万元经费而产生的流程图,突然发现:所有的流程细节都是我们自己制订的,咨询师仅仅告诉我们几个先进的概念和术语而已,并没有给予任何超出我意料之外的革新,竟然被他赚了那么多的钱。
我亲身感受到所谓国际先进的研发管理方案,实际上效率低下、浪费很大。PACE和IPD方案适合于指导大型企业的“软硬件产品研发和制造”流程改进,由于涉及面很广,实施过程中会遭遇重重困难,可能导致半途而废;投入经费巨大,见效时间比较长,企业可能挺不住;如果成功,则有巨大的长期收益,但是失败的可能性比成功的可能性高得多。如华为和上海贝尔阿尔卡特之类的研发管理体系,不适合于国内中小型IT企业,因为尝试不起、承担不起。
我吸取了PACE的思想理念,转而创作面向国内企业的研发管理方法论和研发管理平台(MainSoft),并于2004年创业。
图4-1 根据PACE方法论制订的新产品研发流程
国际标准化组织(ISO)为了满足国际经济交往中质量保证活动的需要,在总结各国质量保证制度经验的基础上,经过近十年的工作,于1987年发布了ISO9000质量管理和质量保证标准系列。1994年进行了第一次修订,形成了ISO9000族标准。2000年又进行了重大修订,发布了ISO9000新标准(2000版)。
ISO9000族标准问世至今,已经被全世界几乎所有行业广泛采纳。人们到商店买东西,随处可见“本产品通过ISO9000质量认证”的标记。“产品通过ISO9000质量认证”几乎成为上市销售的必要条件。
尽管ISO9000族标准已经在各行各业普及,功劳莫大。但是人们在实践中发现ISO9000族标准对普通生产型企业帮助很大,但是对以研发为主的IT企业的帮助比较弱。主要原因如下:
(1)ISO9000称得上是“放之四海皆准”的标准,但是适用面越广意味着专业性越弱。例如,生产瓜子的小工厂和生产软硬件系统的企业,都可以采用ISO9000族质量标准。显然前者的成功经验不能套用到后者上。ISO9000标准不可能对“软件、嵌入式系统、集成电路”等领域的质量问题有深入的论述,所以它对IT企业的质量管理缺乏专业性的指导,其专业程度远远不及CMM/CMMI。
(2)基于ISO9000的质量保证活动,其关注的焦点是“输入、输出”是否符合既定的流程。对于普通生产型企业而言,如果“输入、输出”都符合既定的流程,那么基本可以断定产品的质量不错。然而对于高科技企业而言,“输入、输出”都符合既定的流程并不意味着能够生产出高品质的产品,因为研发水平对产品质量的影响更大。对于“软件、嵌入式系统、集成电路”这类以智力创作为核心的产品而言,ISO9000质量标准的指导价值不高。
我对“软件、嵌入式系统、集成电路”此类研发企业的建议是,学习和应用ISO9000质量标准是有意义的,但是不必费时、花钱去搞ISO 9000认证(除非公司策略需要),因为ISO9000对研发的帮助不大,研发行业并不看重ISO9000认证。
4.2.3 过程改进与CMMI
一、过程改进基本概念
人们使用合适的方法、技术、工具才能开发出用户需要的产品。过程是指“人员、方法、技术和工具”的集合,如图4-2所示。
过程被写成文档后,变成了企业的“流程制度”,人们依据“流程制度”开展工作,这叫“法治”。
图4-2 过程示意图
开发产品不能靠人们的意念瞬间完成,它需要比较长的开发过程。一般情况下,好的过程才可能得到好的产品,而差的过程会得到差的产品。当然也有相反的情况,有些人在混乱的过程中创造了很好的产品,也有些人在严谨的过程中研发出商业上失败的产品。但这类现象不具有指导意义,本书不作讨论。
由于公司销售的是产品而非过程,人们常常只把眼光盯在产品上,而忘了过程的重要性。例如,领导对员工们下达命令时经常强调:“我不管你们怎么做,只要时间一到你们交付产品就行。”其实这是一句因果关系颠倒了的话,却在业界普遍存在。
下面的故事给出了警示:如果领导不关心员工怎么做(即做事的过程),往往会得到失望的结果。
公司领导对项目经理小王说:这个软件项目对公司和客户都很重要,你们要好好干,在6个月之内完成,要让客户满意。6个月后我来看你们的成果,为你们庆功。
每个月末,领导照例打电话问小王:“项目进展怎么样了?”
小王每次答曰:“挺好。”
6个月后,领导兴冲冲地问小王:“项目完成了吧,可以交付给客户了吧?”
小王说:“还有一点东西没有完成,再给我们一个月时间,肯定能够完成。”
7个月后,小王说:“出了一些小意外,我们正在解决之中,我保证下个月完成。”
8个月后,小王说:“我们正在修改某些功能,还需要一个月。”
9个月后,小王说:“我们正在完善某些功能,还需要一个月。”
领导和小王日益焦虑……
12个月后,项目终于完成了。领导喜气洋洋地请客户来验收软件,大家都做好了庆功的准备。
客户看了软件后,大吃一惊:“这不是我们想要的东西!”
在12月里,公司和客户都不关心该项目的过程,都不知道软件是怎样开发的,不知道软件做成什么模样了,都等着看最后的结果。结果是,进度延误了6个月,终于开发完成了不符合客户需求的软件。项目团队疲惫不堪,公司和客户损失惨重。
所以,人们既要关注结果,又要重视过程。
过程改进(Process Improvement)是指:根据企业的现实情况和发展需求,优化流程制度,努力提升人们在过程中的工作能力,从而提升产品质量、提升生产率并降低成本。
“过程改进”本身是一件消耗时间、精力和成本的事情,那么企业为什么要做“过程改进”?
答案是:过程改进是企业谋求进步的需要。
企业谋求进步离不开以下两点:(1)企业人士要不断学习新技术,开发新产品,开拓新业务领域。(2)企业人士要不断反省自己,总结经验教训,改正缺点、发挥优点。
过程改进体现了“自我反省、自我改进”的精神,不论对人生还是对企业而言,都是极为重要的。
1981年,美国卡内基梅隆大学软件工程研究所(SEI)应美国联邦政府的要求开发了一种用于评价软件承包商能力,并帮助其改善质量的方法。Watts Humphrey将成熟度框架带到了SEI并增加了成熟度等级的概念,将这些原理应用于软件开发,发展成为软件过程成熟度框架,它提供了评估软件开发过程能力的一种标准。
1987年,基于Watts Humphrey 等人的工作,SEI的Mark Pauk 等人建立了第一个CMM(Capability Maturity Model,能力成熟度模型),即软件CMM。1993年,SEI推出了CMM 1.1。
之后十几年来CMM的改进工作一直不断地进行着,相继有多个学科领域的CMM模型问世,如SE-CMM、SW-CMM、IPD-CMM等。美国国防采购与技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架,即CMMI(Capability Maturity Model Integration,能力成熟度模型集成)。
CMMI的基础源模型包括:软件CMM 2.0版本、EIA-731系统工程,以及IPD CMM (IPD)。2002年1月CMMI 1.1版本正式发布,立即被广泛采用。
2006年8月,面向开发的CMMI(CMMI-DEV 1.2)版本正式发布,如图4-3所示。为了适应更加广泛的应用,SEI计划今后发布另外二种模型,分别是面向服务的CMMI(CMMI-SVC 1.2)和面向采购的CMMI(CMMI-ACQ 1.2)。
图4-3 CMMI 1.2的三种模型
CMMI将能力成熟度分为5个级别:初始级、已管理级、已定义级、量化管理级和优化级。这5个成熟度等级为评价软件过程能力提供了一个有序的级别,如图4-4所示。同时也为过程改进工作指明了方向,让人们分清轻重缓急,指导人们一步一步地改进过程能力而不是企图跳跃式地前进。
图4-4 CMMI的5个成熟度等级
除了成熟度等级,CMMI还有一个重要的概念是过程域(Process Area)。过程域指出了达到某个成熟度等级必须要解决的一族问题。除了初始级以外,每个成熟度等级都有若干个过程域,如表4-1所示。由于成熟度等级是循序渐进的,如果想达到某个成熟度等级,例如CMMI 3级,除了满足CMMI 3级本身11过程域之外,还要满足CMMI 2级的7个过程域,依此类推。
表4-1 CMMI-DEV 1.2的22个过程域
CMMI等级
|
过程域中文名称
|
过程域英文名称
|
过程类型
|
第2级
已管理级
7个过程域
|
需求管理
|
Requirements Management
|
工程
|
项目规划
|
Project Planning
|
项目管理
|
项目监控
|
Project Monitoring and Control
|
项目管理
|
供应商协议管理
|
Supplier Agreement Management
|
项目管理
|
度量分析
|
Measurement and Analysis
|
支持
|
过程和产品质量保证
|
Process and Product Quality Assurance
|
支持
|
配置管理
|
Configuration Management
|
支持
|
第3级
已定义级
11个过程域
|
需求开发
|
Requirements Development
|
工程
|
|
技术方案
|
Technical Solution
|
工程
|
|
产品集成
|
Product Integration
|
工程
|
|
验证
|
Verification
|
工程
|
|
确认
|
Validation
|
工程
|
|
组织过程焦点
|
Organizational Process Focus
|
过程管理
|
|
组织过程定义
|
Organizational Process Definition
|
过程管理
|
|
组织培训
|
Organizational Training
|
过程管理
|
|
集成化项目管理
|
Integrated Project Management
|
项目管理
|
|
风险管理
|
Risk Management
|
项目管理
|
|
决策分析与解决方案
|
Decision Analysis and Resolution
|
支持
|
|
第4级
量化管理级
2个过程域
|
组织过程绩效
|
Organizational Process Performance
|
过程管理
|
|
量化项目管理
|
Quantitative Project Management
|
项目管理
|
|
第5级
优化级2
个过程域
|
原因分析与解决方案
|
Causal Analysis and Resolution
|
过程管理
|
|
组织绩效管理
|
Organization Performance Management
|
支持
|
|
从20世纪90年代至今,软件过程改进成为软件工程学科的主流研究方向,其中CMM/CMMI是该领域举世瞩目的重大成果。CMM/CMMI是世界范围内用于衡量软件过程能力的标准。
人们往往搞不清楚“过程改进”和“CMMI等级评估”之间的关系,经常混为一谈。这里作个比喻来解释:
把“软件过程改进”比喻为“学英语,提高英语能力”,那么“CMMI等级评估”就好比是“英语等级考试”。一般情况下,英语等级考试的成绩反映了英语能力。但是,在特别擅长应试的中国,英语考试成绩很好并不见得英语能力很好,甚至差到“哑巴英语”的程度。这种“特性”传染到软件领域,不少企业虽然通过了高级别的CMMI等级评估,但是其实际的软件过程能力却非常低下。
软件过程改进的真正目的是提高企业的软件过程能力,而不是为了达到CMMI高等级,切勿本末颠倒。
CMMI 1.2厚达560页,既然有了全世界认同的“CMMI宝典”,企业为什么还要研制自己的软件过程规范呢?为了解答这个疑问,我们首先要搞清楚“CMMI是什么”以及“CMMI不是什么”。
CMMI是世界范围内用于衡量软件过程能力的标准,但是CMMI不是软件过程改进的执行标准,世上根本不存在适合所有企业的执行标准。
就如“英语四六级考试”是中国所有大学都认同的大学生英语能力的评估标准,但是“英语四六级考试指南”绝对不是“学好英语的执行标准”。
不能把“CMMI宝典”直接作为企业的软件过程规范,主要原因是:CMMI的560页文本论述了二十多个过程域和数百条实践,但是这些“过程域和实践”没有与“企业的具体业务和组织结构”衔接起来,所以没法直接使用。有些企业死搬硬套CMMI,竟然按照CMMI文本逐个遍历CMMI的所有过程域和实践,这种方式非常迂腐可笑。就像给一个病人治病,不考虑病人需要吃什么药,却把药店里面的药逐个儿吃一遍,以为就能治好病。
既然不能全盘套用CMMI文本,那么究竟该如何应用CMMI?
应当根据企业的实际情况,既要裁剪CMMI过程域和实践,又要补充CMMI没有涉及的过程域和实践。企业领导和软件过程改进工作者必须明白:企业需要吻合商业目标、容易执行的过程规范。
什么是裁剪?
裁剪不是指用剪刀把CMMI厚厚的书剪成薄薄的书,裁剪是要动脑筋的:要分析企业的业务特征,根据自身的人力和财力,选取CMMI文本中一些重要的东西,舍弃其他不重要的东西。至于什么是“重要的东西”,则要根据它对企业的贡献多少来衡量。
CMMI有560页厚了,为什么还要补充过程域和实践?
CMMI对于软件开发过程和项目管理过程的论述非常深入,但是却没有涉及“商务活动”,例如没有谈营销和客户服务等。
企业开发产品的最终目的是卖出产品,赚取利润。如果过程规范中不考虑商务活动,那么会导致开发团队“闭门造车”,很可能开发出“技术上很好的产品,但却是商业上失败的产品”。
五、中国CMMI等级评估问题
中国通过CMMI3级评估的IT企业非常多,据说占了全世界的一半。给人们造成一种错觉:中国IT企业的能力成熟度普遍很高。
而实际情况是:国内绝大多数IT企业快速拿到了CMMI3级以上证书,但是实际的能力很低,连CMMI2级的水平都没有。中国的CMMI等级评估“放水”很严重,基本上给钱就能过级,正常情况下18个月过级周期被压缩到3-6个月。
为什么会出现这种现象?
主要原因是政策需求:(1)大多数地方政府招标项目要求开发商具备CMMI3级资质;(2)地方政府资助企业搞CMMI评估。
上述政策引发了大规模的CMMI等级评估需求,这不是企业正常、自然发展的需求。如果没有上述政策,中国CMMI等级评估需求可能会锐减90%。
一些企业抱有美好的愿望:完全按照CMMI要求去做事,认真地搞CMMI等级评估,在拿到CMMI等级证书的同时,真正地提升了研发管理能力。
但是这个美好愿望几乎不可能实现!
CMMI最初是为美国国防部软件外包服务,全文不考虑企业如何赚钱、如何省钱,其目标是提升过程质量和产品质量,假设企业具有充分必要的人力资源、时间、经费等条件。承包商实施CMMI的成本将计入国防部项目成本(即甲方承担成本)。
而中国民营IT企业不具备上述环境,通常是在“人力资源、时间、经费”很不充分(甚至很不合理)的条件下干活挣钱,打着CMMI旗号,而无法行其实。
如果中国民营IT企业完全按照CMMI要求去做事,认真地搞CMMI等级评估,在拿到CMMI等级证书的同时,命没有了。
所以CMMI的国情是:
(1)如果企业真要提升研发管理能力,那么请忘掉CMMI条款,不要被CMMI束缚,自己该怎么做就怎么做。
(2)如果企业要拿CMMI等级证书,那就得走捷径,不要感到羞愧,也不要指望靠CMMI等级评估来提升研发管理能力。
项目管理协会(Project Management Institution,PMI)于1966年在美国宾州成立,是目前全球影响最大的项目管理专业机构,该机构的项目管理专家认证(Project Management Professional,PMP)被广泛认同。PMI的突出贡献是总结了一套项目管理知识体系(Project Management Body Of Knowledge,PMBOK)。请注意BOK不是Book的缩写。
PMBOK总结了项目管理实践中成熟的理论、方法、工具和技术,也包括一些富有创造性的新知识。
PMBOK把项目管理知识划分为9个知识领域:综合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。每个知识领域包括数量不等的项目管理过程。
PMBOK把项目管理过程分为5个阶段:
(1)启动。开始项目或进入项目的新阶段。启动是一种认可过程,用来正式认可一个新项目或新阶段的存在。
(2)计划。定义和评估项目目标,选择实现项目目标的最佳策略,制定项目计划。
(3)执行。调动资源,执行项目计划。
(4)控制。监控和评估项目偏差,必要时采取纠正行动,保证项目计划的执行,实现项目目标。
(5)结束。正式验收项目或阶段,使其按程序结束。
每个管理过程包括输入、输出、所需工具和技术。各个过程通过各自的输入和输出相互联系,构成整个项目管理活动。
根据重要程度,PMBOK又把项目管理过程分为核心过程和辅助过程两类。核心过程是指那些大多数项目都必须具有的项目管理过程,这些过程具有明显的依赖性,在项目中的执行顺序也基本相同。辅助过程指那些视项目实际情况可取舍的项目管理过程。在PMBOK2000中,核心过程共17个,辅助过程共22个。
PMBOK2000一共有39个项目管理过程,按所属知识领域分为9类,按时间逻辑分为5类,按重要程度分为2类。如表4-2所示,其中灰色字为辅助过程。
表4-2 PMBOK项目管理过程一览表
|
启动
|
计划
|
执行
|
控制
|
结束
|
综合管理
|
|
项目计划编制
|
项目计划执行
|
综合变更控制
|
|
范围管理
|
启动
|
范围规划
范围定义
|
|
范围审核
范围变更控制
|
|
时间管理
|
|
活动定义
活动排序
活动周期估计
进度安排
|
|
进度控制
|
|
成本管理
|
|
资源计划
成本估计
成本预算
|
|
成本控制
|
|
质量管理
|
|
质量计划
|
质量保证
|
质量控制
|
|
人力资源管理
|
|
组织计划
人员获取
|
团队建设
|
|
|
沟通管理
|
|
沟通计划
|
信息分发
|
绩效报告
|
行政收尾
|
风险管理
|
|
风险管理计划
风险识别
定性风险分析
定量风险分析
风险响应计划
|
|
风险监控
|
|
采购管理
|
|
采购计划
招标计划
|
招标
选择供应商
合同管理
|
|
合同收尾
|
PMBOK和CMMI对比简评:
CMMI论述的项目管理方法仅仅适用于软硬件研发项目,但是不适用于其它行业的项目管理;PMBOK论述的方法适用于任何行业的项目管理,但是对软硬件研发项目管理而言,PMBOK的针对性不够强。
CMMI不仅论述项目管理,而且论述整个机构的研发管理;PMBOK的方法局限于项目管理,对于机构研发管理则不够用。
CMMI基本上不谈“成本管理”和“人力资源管理”,它先假设机构有充足的资金和人力资源,通常不切合企业实际情况;PMBOK的“成本管理”和“人力资源管理”可以弥补CMM/CMMI的不足。
建议:对于软硬件研发机构,应采用CMMI为主导的方法论,并结合PMBOK的知识,取长补短。
4.2.5 敏捷开发
2001年,为了解决许多公司的软件团队陷入不断扩大的过程泥潭,一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟(Agile Alliance)。
他们起草了一个旨在鼓励更好的软件开发方法的宣言,称为敏捷联盟宣言(The Manifesto of the Agile Alliance),如表4-3所示。然后在该宣言基础上制定了12条原则用于指导实践。该宣言和12条原则是敏捷软件开发方法的核心。
表4-3 敏捷宣言
我们正在通过亲身实践和帮助他人实践,揭示更好的软件开发方法。我们认为:
个体和交互 胜过 过程和工具
可以工作的软件 胜过 详尽的文档
与客户合作 胜过 合同谈判
及时响应变化 胜过 遵循计划
虽然右项很有价值,但是我们认为左项有更大的价值。
|
敏捷软件开发的12条原则如下:
(1) 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
(2) 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
(3) 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
(4) 在整个项目开发期间,业务人员和开发人员需天天都在一起工作。
(5) 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
(6) 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
(7) 可以工作的软件是首要的进度度量标准。
(8) 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
(9) 不断地关注优秀的技能和好的设计会增强敏捷能力。
(10)简单——把无需做的工作最大化的艺术——是最根本的。
(11)最好的构架、需求和设计出于自我组织的团队。
(12)每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
我对敏捷开发的看法:
我认为“宣言”中的左右4项都很重要,但是不能绝对地说左边4项“胜过”右边4项,这是“一刀切”的结论,没有考虑成千上万个企业的具体情况。
敏捷软件开发宣言和12条原则并非普遍适用。其中(2)、(4)、(5)项看似很好,但是不符合中国软件机构的普遍现状,几乎行不通。我个人比较赞同的是(1)、(3)、(6)、(7)、(12)项。
敏捷开发方法表达了“简单、快速、实用”的软件开发思想,它并不是成熟严谨的理论、也不是事实上的标准(不像CMM、PMBOK那样具有严密的理论体系,被企业广泛接受)。即使人们认同某些原则,但是不同的人往往有不同的理解,实践差异很大。
敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的(如果用对了的话)。但是企图用它指导大型、中型软件机构的研发管理是有很高风险的,它的某些主张是局部观点而不是全局观点,如果把握不好分寸的话可能导致整体混乱,而“整体的混乱”会淹没“局部的好处”。
企业若采用敏捷开发理念来精简流程,为了避免过度简化而导致混乱,至少要做到以下几点:
(1)流程具备完成工作的必要步骤;
(2)流程具备完成工作的必要角色;
(3)每个角色写尽可能少的必要文档;
(4)项目关键点的进度和质量必须受控。
4.2.6 不要迷信所谓的标准
CMMI、PMBOK、ISO9000等标准都是用来参考的,而不是用来“迷信”的。我发现当人们崇拜CMMI时,他的思想意识就不知不觉地被CMM/CMMI控制了,这是非常有害的。
2000年之后,国内软件业界兴起CMM/CMMI等级评估热潮。很多软件过程改进人员把CMMI当圣经看待,完全对照CMMI文本来操作,都不敢想一想是否合理。
其实软件企业即使不采用CMMI,也是有可能把软件研发做得很好的,例如Microsoft、Google并不采用CMMI,它们有自己的研发管理方法。
互联网公司的软件研发人员最喜欢嘲笑“笨重”的CMMI,有例为证:
某互联网公司的领导夜里经常做恶梦,老梦见竞争对手超过自己。有一天,他梦见一个过了CMMI 5级的公司在做总动员,要和本公司竞争,于是他在梦中笑醒了。
企业采用业界推荐的标准时,要舍弃那些听起来很先进,但是对本企业无益处的东西,只选取对企业有实用价值的东西。
4.3 软硬件研发企业集成化管理模型
研发企业的主要使命是研制出符合客户需求的产品(或项目),为客户创造价值,从而为本企业创造效益。企业管理不是企业使命,它是实现企业使命的必要条件(而非充分条件)。凡是好的管理方法,通常都是符合人之常情、易于理解、易于执行的,从理论上讲“管理”应比“研发”简单和容易得多。
但是国内绝大多数研发企业的实际状况是,企业领导和骨干人员们陷入了低级繁杂的事务中不能自拔,他们比总理还忙,比民工还累,却无法研发出好产品。根本原因是:不懂得正确合理的管理方法,以错误的方式用人和做事。研发企业的需求和技术复杂性通常高于非研发企业,因而研发企业的决策过程和执行过程的难度与风险也高于非研发企业。在研发企业里,“正确决策、正确执行”这八个字说起来容易,而做起来则相当困难。
本书作者十余年来专注于软硬件研发企业管理,拜访了数百家企业,访谈了数千人(包括企业领导、中层干部和基层员工),整理分析各种问题,实践各种对策并不断改进方法。本书论述软硬件研发企业的系统性管理方法,目的是帮助研发企业快速、低成本地建立适合于自身的、高效率的企业管理体系。从而让企业领导和骨干人员们从繁杂事务中解脱出来,去做更有价值的事情。
作者是学物理出身的,就以研究物理的方式来研究企业管理:先构思设计理论模型;然后在企业中应用;再根据实际效果来改进理论模型。我花了十多年时间构思和改进“软硬件研发企业集成化管理模型”(见图4-1),这幅模型图被我修改了上千次,本书所有内容都是围绕这个模型开展的。该模型自顶而下分为三层:
第一层:思想理念。主要论述:企业根本目标,企业道德,管理目标(正确决策和正确执行),管理基本方法(法治和人治),企业管理的经济学原理,如何赢得客户等内容。目的是让企业全员对“企业经营过程中的是非对错、轻重缓急”有共同的认知,最大程度地避免内耗,才可能顺利地推行各项管理措施。这个貌似务虚的思想理念,实质上是指导一切务实工作的基本原则,企业领导应高度重视思想理念的宣传教育。
第二层:战略管理。企业战略管理的目的是使企业持续进步、长治久安。企业领导要有前瞻性眼光,要提前去做对企业未来有益的事情。本书倡导战略管理十项措施:企业问题分析、优化盈利模式、优化组织结构与人力资源、优化流程制度、优化企业管理系统、需求研究与解决方案设计、成果标准化与复用、反省过错不二过、量化分析与改进、提升全员技能。上述战略管理措施对应于CMMI4-5级过程域与目标。
第三层:执行过程。执行就是干活,企业全员不论职务高低,都必须按照既定的流程干活。把软硬件研发企业的主要执行过程“产品管理过程、营销客服过程、项目管理过程、项目研发过程、支持过程”集成一起,称之为集成化研发流程(IDP),有三个特色:(1)把数十个过程域按照合理的逻辑集成起来,从宏观上保证企业整体执行过程通畅无阻(而不是顾此失彼)。(2)定义了详细的工作流程,每个人不仅知道自己做什么和怎么做,而且还知道如何配合别人,企业全员有条不紊地开展工作。(3)流程中设立预防机制,避免不合理的需求和决策流入到下个环节,避免企业领导和客户随意指挥研发人员(破坏流程)。该集成化研发流程(IDP)对应于CMMI2-3级过程域和目标。
图4-1 软硬件研发企业集成化管理模型
4.4 研发企业战略管理:持续进步十项措施
任何存活下来的企业都有优点和缺点,兴于优点而败于缺点。企业已有的成功既是财富亦是包袱,“成功”放大了优点而掩盖了缺点,可能使企业陷入危险而浑然不知。无论是初创企业还是成熟企业,都要考虑眼前如何生存和未来如何发展。
企业战略管理的核心是使企业持续进步、长治久安。作者总结了使软硬件研发企业持续进步的十项措施,绘制成为“软硬件研发企业战略管理模型”,见图4-2。
企业要周而复始地开展这十项措施,哪一项都不是轻易能做成功的,要委派责任心强的人员跟踪实施过程。正确的事情要持之以恒地做,错误的事情要及时发现及时解决,才能够持续进步。
图4-2 研发企业战略管理模型
4.4.1企业问题分析
企业问题分析,相当于企业的“体检”,要周期性地开展,目的是及时了解企业面临的各种问题,给出对策,防患于未然。勿要等到“病入膏肓”了才去“体检”,这时体检已经没有用了,要么急救,要么送终。不主动去分析企业的问题,是“困而不知”的表现。
企业问题分析的基本方法:
(1)成立调研分析小组。成员可以是外聘的咨询师,也可以是内部人员,但一定要有丰富的工作经验,有敏锐的洞察力。不仅能够引导被访谈者,而且能够从人们的支支吾吾、只言片语中抓住要害问题。
(2)划定调研的范围,找出该范围内所有岗位的典型人员,以及所有与外界接触的典型人员。
(3)然后访谈,可以一对一,也可以一对多地访谈。访谈的目的是了解每个人遇到的问题以及他们的建议。调研者要善于引导被访谈者,既让他们说出问题和建议,又不能没完没了地聊天、抱怨。
(4)整理所有原始记录,发给被访谈者,请他们查看,并补充遗漏的内容。
(5)归纳分析问题。也许所有问题汇总起来上百条,相互纠结,这是无法下手解决的。一定要归纳出共性的和根源问题,最好不要超过十条。
(6)给出解决问题的对策。对策不在乎是否高明,最重要的是可以执行。事实上,大部分对策不会痛快地诞生,往往要权衡各方利弊,最终产生相对满意的折中办法。
上述(1)(3)(5)(6)最重要,也最能体现调研分析小组的水平。
4.4.2优化盈利模式
研发人员埋头搞技术,很少思考这些技术是如何产生效益的。在很多情况下,与其艰难地改进技术本身,还不如“优化盈利模式”,使得现有的技术和资源产生更高的效益。
盈利模式是指“企业的某个业务是如何赚钱的”。每项能够赚钱的业务,都有一些构成要素(有共性的也有独特的),这些要素的强弱体现了“盈利能力”的强弱。
优化盈利模式有两种途径:
一、优化某业务盈利模式中的构成要素,提升该业务的盈利能力。
常见的盈利模式构成要素有:目标客户群体、产品和服务、营销途径、收费方式、成本和利润、档次与品质、技术能力和管理能力、有效时间、规模复制效益、市场增长率、本公司竞争力等。
若能优化其中一个或多个构成要素,可能使该业务的盈利能力显著提升。
例如,国内有近十家实力相当的教育电子产品企业都推出面向中学生的“学习机”。不同牌子的学习机的功能很相似,价格也相近。一旦某个学习机有个新功能,其它学习机马上模仿,谁都不敢少个功能,哪怕是垃圾功能。产品越做越复杂,垃圾功能越来越多,开发者很累,利润又低。
A公司下决心不再走竞争导向的路线,重新思考“消费者究竟想要什么?我们的产品能够给消费者带来好处?”
通过调研分析发现,家长们最希望能够把孩子送到名校读书,如果不能进名校,能遇到名师也不错。如果两者都没有,那只好买各种各样的学习用品(包括学习机),以弥补缺失。
A公司搞清楚消费者的真正愿望后,大胆地把原先学习机里的所有复杂功能都去掉,只保留一个功能“播放视频”,改名为“视频学习机”。把湖北黄冈中学的所有课程都录制下来,保存在学习机中。这个产品的卖点只有一条“把名校名师的课堂搬到家里”,立刻打动无数消费者。
视频学习机的技术开发复杂度比原先的简单多了,售价却是原先的数倍,利润大增。这是通过“优化产品内容”来提升盈利能力的示例。
再如,国内由于软件盗版原因,开发和销售面向个人的应用软件几乎是死路一条。自从Apple推出iPhone和AppStore后,大量的个人应用软件从Windows转移到iPhone平台,在AppStore销售,开发者与Apple分享利益,走上了致富道路。这是通过优化“营销途径和收费方式”来提升盈利能力的示例。
过去游戏软件开发商靠卖游戏软件(载体是光盘)盈利,现在几乎全部转型为网络游戏运营商。游戏软件使用方式改变了,不再安装在用户的计算机上,用户直接登录到运营商网站上使用。游戏软件本身免费了,但是游戏里面各种各样的装备要收费。这是通过优化“产品使用方式和收费模式”来提升盈利能力的示例。
二、几种盈利模式融合,相互支撑,扬长补短,使企业整体盈利能力更强。
软件行业三类盈利模式“合同项目模式、通用产品模式、运营模式” 各自都有优缺点,软件企业如果能够把几类盈利模式融合起来,则能相互支撑,扬长补短,使企业整体盈利能力更强。
“合同项目模式”和“通用产品模式”的融合示例:
承接合同项目的软件企业,应当提炼自己做过的所有合同项目的共性知识财富,设法打造公司内部的“通用平台”(相当于通用产品)。将来每承接一个新的合同项目,不必从零开始开发项目,大部分东西可以直接复用“通用平台”,只有少部分东西需要重新开发,必然取得更高的效益。
“通用产品模式”和“运营模式”的融合示例:
传统的手机开发商均采用“通用产品模式”,即卖手机给消费者。消费者购买了手机之后,消费者和手机开发商之间就不再有后续消费关系。卖手机的方式使得手机开发商难以从消费者那里获得后续收益,手机做得再好也无奈啊。
这种困境被“后来者”美国苹果公司突破,它不仅创造了新型的手机iPhone,而且创造了新的手机盈利模式。苹果公司不仅卖手机给消费者,赚到高端产品的利润,而且消费者可以源源不断地从苹果公司网站下载付费的音乐和应用软件,产生持续消费。苹果公司不仅是手机开发商,而且还是手机内容的运营商。
同理,当前流行的“电子书设备 + 内容网站”也是“通用产品模式”和“运营模式”的融合示例。
关于盈利模式更多的论述,详见本书第5章“盈利模式和核心竞争力”。
4.4.3需求研究与解决方案设计
很多公司埋头做合同项目或产品,人们不断忙碌地开发功能,忙碌地测试,却不知道为什么要开发这些功能。产品策划人员常常根据自己的想象和竞争对手的产品功能,而决定开发什么功能。
我曾体验了某电子公司的一些产品,发现里面有很多低价值的功能,对用户几乎没有用处。
我问:这些低价值的功能消耗了研发部门的大量精力,而且由于做得不彻底,产生了不少质量隐患。你们为什么要开发这些“垃圾功能”?
答曰:竞争对手产品有这些功能,我们也要有,否则我们的功能就被人家比下去了。反过来,竞争对手也不断模仿我们的功能,否则被我们比下去了。所以我们要比竞争对手更快地开发更多的功能。
恶性循环由此产生。
多少公司口头喊着“消费者导向”,可是干活的时候却是“自己导向”或“竞争对手导向”,开发了很多垃圾功能,消耗精力,迷失方向。
有些人误以为“消费者导向”就是“客户说什么我就做什么”,被客户牵着鼻子走,那么你就是那头被牵了鼻子的苦力牛。
如果企业不研究领域需求,埋头做项目或产品,最糟糕的后果是“如果产品被市场淘汰了,自己怎么死的都不知道”。
20世纪90年代,中国传呼机市场非常庞大,几乎人手一个。如果你公司埋头研究传呼机,即使你成为中国最好的传呼机公司,当手机普及的时代到来,顷刻间传呼机市场覆灭,最好的传呼机公司也无法抗拒地倒闭了。如果你一直研究消费者对通信的需求,你会在某个产品被淘汰之前就已经转型。
有些公司在市场上打拼多年,在客户需求方面积累了很多经验教训。但是没有把大量的客户需求提炼、升华成为“领域需求知识财富”,每个项目都从零开始做需求分析,被动地等待客户提出需求,那么研发过程将产生大量的需求争议和变更。
如果需求捏在客户手里,那么任何需求分析方法都解决不了需求混乱问题。需求研究的目的是发现消费者真正的需求,并且发掘隐含在需求中的价值。设计的目的是以最佳的方式实现需求和价值。两者加起来才能引导客户消费,而不是被客户牵着鼻子走。需求研究能力和设计能力是研发企业最重要的能力,如果没有这种能力,研发企业充其量是个苦力公司,永无出头之日。
我自己的公司白手起家,创业期间没有外界一分钱投资。我花了十年时间研究国内软硬件研发企业管理面临的问题和需求,思考解决方案,公司专注于开发一款产品“集成化研发管理平台”。我们不断完善方法论,不断改进产品。从来没有被客户或竞争对手牵着鼻子走,以致整个公司多年来从未加过一天班,活得好好的。
我公司很小,但却是国内“研发企业管理方法论和管理平台”领域最强的公司。不管竞争对手公司有多大,多么有钱,如果想超越我们,也得花多年的时间去研究、提炼领域需求,没有其它捷径可走。
研发企业要把“需求研究与解决方案设计”提升到战略高度,持之以恒地开展,努力提炼出领域需求知识财富,给出最佳的解决方案,成为业界公认的领导者,从而引导客户消费。
4.4.4成果标准化与复用
经过消费者验证的工作成果是企业宝贵的知识财富,要把它标准化(成为标准件),开发方通过“复用标准件”可以大大提升“开发效率和质量”。
复用是指“利用现成的东西”,即“拿来主义”。被复用的对象可以是有形的物体,也可以是无形的成果。复用不是人类懒惰的表现而是智慧的表现。因为人类的进步是继承了前人的成果,不断加以利用、改进或创新后的结果。所以当我们欢度国庆时,要搞清楚祖国远不止几十岁,我们今天享用到的还有中国五千年的历史财富。进步是应该的,不进步则就可耻了。
复用意味着既提高了效率又提高了质量。由经验可知,在一个新系统中,大部分的内容是成熟的,只有小部分内容是创新的。成熟的东西总是比较可靠的(即具有高质量),而大量成熟的工作可以通过复用来快速实现(即具有高效率)。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上,而把小部分的时间用在大比例的成熟工作中,这样才能把工作做得又快又好。
把复用的思想用于软件开发,称为软件复用。据统计,世上已有1000亿多行程序,无数功能被重写了成千上万次,真是浪费啊。面向对象(Object Oriented)学者的口头禅就是“请不要再发明相同的车轮子了”。
将具有一定功能并且可以重复使用的软件单元称为软构件,即软件的标准件。软件复用可以表述为:构造新的软件系统不必每次从零做起,直接使用已有的软构件,即可组装(或加以合理修改)成新的系统。复用方法合理化并简化了软件开发过程,减少了总的开发工作量与维护代价,既降低了软件的开发成本又提高了生产率。另一方面,由于软构件是经过反复使用验证的,自身具有较高的质量。因此由软构件组成的新系统也具有较高的质量。
软件复用的好处是显而易见的,但是国内大部分企业在软件复用方面做得非常差。
例如,手机领域的“标准化和复用”出现了两种极端现象。一方面,由于手机芯片和底层通信软件是标准化的,导致手机开发的门槛非常低。中国手机开发公司如雨后春笋般地诞生,创造了“山寨文化”,这是标准化带来的繁荣。另一方面,手机公司内部的应用软件开发却没有标准化,导致开发新款手机的效率和质量低下。
有个手机开发商每年推出十余款手机。每款手机之间的相似度其实很高,可是平均每款手机项目的缺陷数量竟然达到3000~5000个,比我公司5年时间软件产品的缺陷累计还要多!该公司花费了极高的测试代价和纠错代价,并年复一年地进行着。
通过分析发现,每个项目的缺陷相似度也是很高的。为什么会产生如此多相似缺陷呢?主要原因是:
(1)过去没有进行缺陷分析总结,相同的错误重复发生。
(2)很多成熟的软件功能没有标准化,每个程序员都搞点新花样,操作界面各式各样,甚至两款手机相同的功能竟然互不兼容,导致太多的缺陷。
(3)每个项目开发都是匆匆忙忙的,在设计和实现过程很少思考怎样使将来的开发工作做得更好更快,几乎不给将来留下可以复用的东西。
解决上述问题的基本手段是:
(1)要开展“缺陷分析总结”活动,反省过错不二过,消除重复的错误。
(2)凡是消费者验证过的成熟功能,要提炼成为标准件,要有专人维护,不能随意篡改,新项目尽可能使用公司积累的标准件。
(3)在每个新项目的开发过程中,既要考虑现在又要顾及将来,要设计出可以在将来复用的东西。
企业要提倡复用知识财富,要有相应的激励措施,让人人养成复用习惯:每个人在干活的时候,先想想是否有可以复用的成果,如果有,自己就不要从零做起。同时尽可能使自己的成果具有复用性,将来可以让别人复用自己的成果。
函数级别的复用,对程序员很有意义,对软件企业而言还不够,企业还需要“业务级别的标准件”,称之为“公共技术平台”。企业要舍得花精力不断建设、完善“公共技术平台”,这是大规模复用的根基。措施如下:
(1)公司应当成立“公共技术平台”项目,把“公共技术平台”当做公司长期的产品来开发。该项目人员少而精,保持人员稳定。
(2)公共技术平台的第一个实用版本极为重要,要让相关人员感受到复用的好处,才有信心。通常第一个版本要具备:公共的技术架构,公共的“用户管理和权限管理”模块,公共的UI控件。做到这一步,至少可以节约30%的编程工作量。之后再逐步开发公共的应用模块。
(3)公共技术平台和应用项目之间的关系如图4-3所示。应用项目应当在公共技术平台上面开发,应用项目只能调用平台功能,而不可修改平台的代码,确保平台升级后,所有应用项目都能无缝升级。应用项目完成之后,要提炼出“公共模块”纳入到公共技术平台,使平台越来越“强壮”,同时应用项目不断“瘦身”。
图4-3 应用项目和公共技术平台的关系
4.4.5反省过错不二过
大多数人谋求进步的主要途径有两种:
(1)不断接触新事物、学习新知识,从而进步(即学而知)。
(2)不断反省过错,不再犯相同的错误,从而进步(即困而知)。
青少年的智商尚在发展中,最容易接受新事物、新知识。而青少年的缺点是社会阅历少,反省不出多少东西来,等他长大了,自然会明白很多道理。相比之下,对于青少年而言,学习新知识的方式进步最快,所以要上学。
而成年人的智商不再发展(越老越倒退),加之家庭和工作事务繁多,通常很难通过读书的方式进步。但成年人的优点是社会阅历丰富,通过反省过错,总结自己和他人的经验教训,从而取得巨大的进步。
中国有位饱经沧桑的老人曾经总结了几句话:发展才是硬道理,稳定压倒一切。这些话哪是学来的,那是他经历了十多年动乱磨难,代表中国人民反省出来的道理,中国因此走上正确的道路,欣欣向荣。
“反省过错不二过”是企业谋求进步的极重要手段。对于企业的研发机构而言,“缺陷分析总结活动”是实践“反省过错不二过”的最佳方式。意义如下:
(1)人们在研发过程中不断地产生大量相似的缺陷,然后花大量时间和精力找出缺陷,再消除这些缺陷,是巨大的生产力浪费。
(2)人们犯下的过错,也是企业的知识财富。通过分析大量的缺陷,可以找出规律,使企业避免再犯相同的过错,乃至预防产生新的错误。
(3)这是“生于忧患,死于安乐”哲理的体现。
(4)这种方法成本最低,进步最快。
我曾无数次规劝我的客户们(数百家IT企业的研发机构)要周期性地搞“缺陷分析总结”活动,他们都明白其道理和价值,但是他们都说“我们现在很忙,等以后有时间了一定会好好分析总结缺陷”。多么遗憾啊!
2008年北京奥运会,全国人民都盼望着刘翔再次夺冠。可是他不能比赛了,因为他的脚有伤,必须要停下来,治好了才能再比赛。如果当时迫于形势逼着他比赛,极有可能跑成残废,把他未来全毁了。
大家都知道“放下包袱、轻装上阵”的道理。企业明明生病了,就是不愿意暂停下来、先把毛病治理了再往前走,非得要拖着病体往前冲,直到把自己累死,产生更多的损失,这违背了公司“健康长久地发展”的终极目标。
缺陷反省总结的方法(7个步骤)如图4-4所示。
图4-4 缺陷反省总结的步骤
第1步,每个人撰写《缺陷分析报告》。实施范围内的每个人都必须按照规定的模板撰写《缺陷分析报告》,见表4-1。每人至少写10个缺陷,鼓励多写。只要是有价值的缺陷,即使没有解决方案,也鼓励撰写。
第2步,专家初筛选。专家分工审阅《缺陷分析报告》,发现“不合格或者描述不清楚”的报告,退给当事人改进;提取有推广价值的缺陷报告,汇总到新的文件,便于下一步专家评审。
第3步,专家评审入库。专家分组讨论“初筛选”出来的缺陷:(1)分析哪些缺陷报告有推广价值,确定采纳,数量不限。(2)对已采纳的缺陷报告,提出改进建议,以便撰写者完善缺陷分析报告。(3)把完善后的缺陷输入到“研发管理平台-缺陷知识库”中。
第4步,专家总结报告。专家通过审阅和分析大量的缺陷,总结缺陷产生的规律和对策。公司组织专家报告会(指定每个类别的演讲者),每个演讲时间约30分钟。
第5步,公司表彰大会。公司举行“缺陷分析总结表彰大会”,对于本次活动的突出个人和专家给予表彰。
第6步,专题培训学习。由人力资源部和专家商议,从缺陷知识库中提炼“专题培训课程”。给予培训讲师一定的奖励,鼓励多讲。
第7步,常态化。(1)每个项目结项的时候,都要进行相似的缺陷分析总结活动。(2)如果质量部在新项目中再次发现《缺陷知识库》中已经分析过的缺陷,报告给研发部门领导,批评开发者。(3)如果产品推向市场之后,再发现《缺陷知识库》中已经分析过的缺陷,那么追究开发者和测试者的责任(视问题的严重性给予一定的处罚)。
表4-1 缺陷分析报告的模板
撰写人:
|
|
所属部门:
|
|
缺陷名称
|
提示:给出简洁准确的缺陷名称(20个文字之内)
|
缺陷定位
|
提示:尽可能说清楚缺陷所在的位置,例如所属机型、平台、模块等。便于其他人迅速找到缺陷。
|
缺陷详细描述
|
提示:说明缺陷的症状,以及如何操作才发现该缺陷。如果文字不容易说明,请附图片。
|
缺陷产生原因
|
提示:尽可能说明此缺陷是如何产生的,最好能够发现规律。
|
缺陷解决方案
|
提示:详细说明是如何解决这个缺陷的,要让公司其他人很容易学会这个方案,可以附相关文件。如果方案有多种,请比较方案的优缺点。
|
消费者心理分析
|
提示:请分析消费者遇到这个缺陷时将有什么反应?有什么期望?
|
应用建议
|
提示:有什么建议可以让公司其他人避免产生同类缺陷?有什么措施可以改进消费者的满意度?
|
4.4.6优化组织结构与人力资源
当公司很小时,无所谓组织结构,公司领导自己直接管理所有人员就可以了。当公司比较大时,领导一个人管不过来了,就要把公司细分为一些部门并明确相关职责:
(1)定义每个部门的职责。
(2)定义部门内每个岗位的职责。
(3)定义各部门之间的合作关系(接口)。
(4)然后把人员放到合适的岗位去工作,这样就确定了公司的组织结构。
良好的组织结构能够让人们各司其职,把企业的问题分而治之。但是不良组织结构将会导致人浮于事、效率低下、管理混乱的情况。
某公司在2006年和2007年大约有40人,公司组织结构采用简单的项目制,干得挺好。由于国家大力投资该行业,公司发展很快,到2008年底人员突然增加到300多人。该公司组织结构调整为“二维矩阵结构”,即人员按“职能部门”划分,干活的时候分配到项目中。很快又加入几条产品线,变成了三维矩阵。员工干活的时候不知道听从项目经理、产品经理还是职能经理。公司研发工作几乎陷入瘫痪,不仅新项目难以开展,就连老项目也做不好了。
公司领导认为这是项目经理水平较低,研发流程不完善导致的,他们请一个国外CMMI咨询师来诊断问题。老外套用CMMI检查表写了一份“治不死人,也治不好人,但是能气死活人”的诊断书。公司领导看了既失望又生气,中途把这位稀里糊涂的CMMI咨询师赶走了。
这个公司又重新找我做咨询。我先访谈3天,结果发现该公司最严重的问题就是组织结构太复杂(三维矩阵),几乎无法开展工作,这个问题不解决,流程改进是无法开展的。我花了5整天时间,终于制定并说服管理层采纳新的扁平化组织结构,后面顺利地制定了集成化研发流程。这个公司花了数十万元咨询费,公司领导对我说,咨询师最大的贡献就是帮助他们制定了合理的组织结构,公司终于能够正常运作了,虽然花费很高,但是值得。我不禁感叹,要是他们自己会优化组织结构,那会节省很多钱,少浪费很多精力啊。
优化组织结构的基本方法:
优化人力资源的目的就是让合适的人去做合适的工作,并且有合适的考核和激励措施,使他们把工作做得更好。这样才能使企业的人力资源产生最大的效用。
一、根据“人员的能力和优缺点而不是资历、关系”去匹配工作岗位。
企业即使有了合理的组织结构,但是岗位上的人不合适也不行。国内IT企业普遍提拔资深的“技术骨干”当高级经理,殊不知大多数的技术骨干们不仅不懂管理,而且误以为自己很懂管理,结果乱管理,典型的“困而不知”。
某软件公司研发总监请我做“研发流程改进”咨询,双方合作了近3个月,我和这位研发总监成为不错的朋友。当我完成了合同规定的咨询服务后,临走前十分钟,我向该公司总经理告别,向他说了我憋了很久的“秘密”:
我已经根据您公司的情况优化了研发流程,也做了深入的培训,还有一件很重要的事情我没有说。我说了对不起朋友,不说对不起客户。我左思右想,现在必须告诉您,您公司研发管理最大的问题是用错了一个人,就是研发总监。他是技术高手兼行业专家,但是对团队管理完全没有悟性。他经常不等别人把话说完、没有搞明白出了什么问题,就武断地给出了不合理的答复,让人不知所措。由于他是公司的元老,没有人敢顶撞他、怀疑他的能力。您要么把他换个职位,如果不换职位的话,您最好把他架空了,不要让他管理人员和具体事务,想办法只让他专心研究行业解决方案,发挥他的价值。
我说完后,总经理惊愕了一会儿,然后站起来长时间握着我的手,说:我非常感谢你临走前说的真心话。过去我一直感觉到公司研发管理存在某个隐患,公司做过多次流程改进和培训,效果一直不好,但是我没有想到是研发总监人选不合适,真是当局者迷啊。你这么一说,我就恍然大悟,我会妥善处理研发总监职位的问题。
二、根据经济学中的比较优势原理,让企业中的任何人(包括强者和弱者)都发挥各自最大价值。
能力强者去做最大优势的工作,而能力弱者去做最小劣势工作。不提倡“能者多劳”,不该让能干的人做太多的杂事(机会成本太高)。不应出现忙的忙死,闲的闲死。
企业要拥有不同级别的人才,去从事不同级别的工种。而不能招聘一大批相同水平的人(例如从大学招聘一批毕业生),去做多个不同级别的工作,否则会发生“能力不足”和“能力浪费”的现场。
三、要为不同岗位制定合适的绩效评估方法,并采取合适的激励措施。
关于组织结构和人力资源进一步论述,详见本书第7章“软硬件研发企业人力资源管理”。
4.4.7 企业流程改进
企业流程改进的目的是:持续优化企业流程制度,使员工掌握与流程匹配的技能,从而“提升产品质量、提升生产率并降低成本”。
一、如果某些业务领域还没有流程制度,那么先要制定流程制度,防止流程制度缺失而产生隐患。
20世纪80年代某大型电视机厂基本没有管理制度,只有墙上刷着标语:不准随地大小便。好歹有了这个制度,电视机才不会有“便味”。
我在上海贝尔有限公司工作时,曾经有一段时间从优秀员工堕落成为差员工。2002年我买了房子,上班的时候心思就不在本职工作上了。有将近2个月时间,我上班有一半时间是在画装修图,更过分的是我就在上班时间出门买家具。后来我反省自己,为什么我堕落了呢。根本原因是没有流程制度来约束我的上班行为,导致我放纵自己。
试想一下,如果银行没有严密的安全制度,那么大部分“良民”就会经不起诱惑,成为不法分子。
流程制度缺失是企业管理的重大漏洞。建立流程制度,首功就是堵住管理漏洞。
二、对于已经存在的流程制度,要定期审查是否合适企业的实际情况。如果发现流程制度存在缺陷,则要及时改进,要随着企业的发展而优化流程制度。
大凡第一次从事流程改进的人员,他们总是希望制定“大而全”的流程制度,企图覆盖企业中的所有事务。从实际效果来看,“合适”比“大而全”更有价值。
我询问过很多IT企业研发管理人员:你公司有没有研发流程?
他们会捧出几百、上千页的流程文件,得意地说“有!我们已经按照CMMI制定了流程”。有一些压根就是取自我8年前写的一堆流程文件,错用了都不知道。
在创作“厚”流程方面,我算得上是“骨灰级”人物了。在2000年至2001年,我带着6人流程小组,为某软件事业部制定了1000多页的软件研发流程。由于流程实在太厚、太啰嗦,我花了很大力气去培训、推广,最终都没有用起来。想想也是,正常人看1000多页的流程,谁记得住啊!
这些流程文件的唯一价值是,事业部领导向公司领导汇报工作的时候,经常带着这本“砖头”来展现业绩,搞得其他事业部领导很羡慕,恨不得造出更厚的“砖头”。
由于舍不得自己失败的心血之作完全被遗弃,而且我也不好意思承认自己写了一堆废物。我把臃肿不堪的流程文件(含近百个文档模板)全部在网上公布,权当“学术”成果,给别人留点参考资料,聊以自慰(我那个时候不明白这是虚荣行为)。
之后我自己不断优化“集成化研发流程”,到现在已经把1000多页的内容精炼到100页之内,才在企业中真正用起来。
有一次我参加软件工程大会,恰好和国内知名CMMI咨询公司的老总同住一个房间。老总就像找到革命同志一样,握着我的手说:小林啊,你写的那些CMMI模板(在网上公布的)很好,我们一直在用,也推荐给很多客户用,你是真有贡献的人啊。
我没有想到国内有些CMMI咨询公司和软件公司照搬我过去写的那堆废流程。就如同《武林外传》里面的那个画家,凭空想象创作了“衡山剑法”,结果被卖包子的莫太冲照搬了用,竟然创办了衡山派。小说中的夸张情节,搬到企业是行不通的。
大多数有效的流程制度,总是简洁明了的,而不是繁复冗杂。流程的价值通常和它的厚度成反比。如果你自己撰写了近千页的流程文件,那么你有苦劳但是没有功劳。如果你抄了近千页的流程文件,你既没有功劳也没有苦劳。
我曾多次看到这样的现象:咨询师给企业员工培训流程制度的时候,各级领导总有各种理由不参加培训。当真正在项目中推行新的流程制度的时候,各级领导自己却不懂,仍然按照他原先不合理的方式去管理,让下属不知所措。
各级领导的主要职责是“带领团队完成目标”,他们要“亲身参与”过程改进,才能深刻体会过程的要点,掌握相应的方法技能。“亲身参与”体现在:参与分析问题,商议对策;参与制定和自己工作相关的过程规范;参与评审;参加培训学习等。
对于特别重要的流程制度,培训之后要对学员进行考试,促使他们牢牢记住。例如交通法规的考试,即便是死记硬背,也是有用的。
四、引导推行,而非简单粗暴的强制推行。
推行流程制度会遇到阻力,主要有几方面原因:
(1)员工们难以很快改变自己的习惯,他们会把合理的流程制度当做额外负担来看待。
(2)流程制度本身就存在缺陷。
(3)即使流程制度是合理的,但是员工们没有掌握与流程匹配的工作技能。
我曾经询问某公司领导:“在推广流程制度的时候遇到阻力怎么办?”
该领导回答很干脆:“强制执行,不按流程执行者要处罚。”
这种答复“说得容易,做起来难”。在中国自古就存在“上有政策,下有对策”之说,在推行流程制度时,不仅要预防员工们应付了事,还要引导员工们正确地做事情。
举个例子说,计划生育是一项基本国策,它在实施之初遇到了强大的阻力。有一些人暴力对抗,很多人东躲西藏(形成了超生游击队)。怎么办?惩罚违抗者是一种不得已的措施。更好的方法是对全国人民进行教育宣传,例如农村的墙上到处都是“只生一个好”,这么多年下来,成绩斐然。如今计划生育已经深得民心了,很少发生对抗。
企业制定流程制度是为了帮助员工们把工作做得更好,而不是存心与人们过不去。企业要设法使员工们乐于执行,从而避免流于形式。
流程制度制定者不要只是埋头写流程制度,写完了上缴了事。最好在企业内部网上开辟一个专栏,专门解释流程制度。流程制度不是数学定理,可谓“智者见智,笨者见笨”。如果不对流程制度作解释,员工们就不理解“为什么”,如果不理解“为什么”,怎么能够很好地执行呢?
不少公司都有名目繁多的规章制度,很多条款用了“必须”的语气。有些内容会损害不少人的利益,但为了顾全大局不得已这样做,如果不解释清楚原因,可能会招致本来可以避免的埋怨或对抗。
解释流程制度还会带来间接的好处:不合理之处会很快被发现(因为解释不通)。
五、质量保证人员监督实施
人都有惰性,如果没有人来监督员工们按照流程制度办事,那么自觉性不强的员工就会回到“无序”的老路上。
CMMI把质量保证称为“过程与产品质量保证”。质量保证人员的主要职责就是周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的过程规范。
几乎所有的老百姓都明白基本的交通法规,可是明知故犯的人仍然不少,所以社会需要很多交通警察。质量保证人员的工作性质有点像交通警察。
企业推行研发流程后,通常会要求研发人员写不少文档。
传说CMMI等级和文档有这样的关系:
你们对所做的事情有文档记载吗?如果有,好,达到了CMMI2级。
你们对所做的事情的文档有文档记载吗?如果有,很好,达到了CMMI 3级。
你们对所做的事情的文档的文档有文档记载吗?如果有,非常好,达到了CMMI4级……
很多管理者有这样的感受,在推广流程制度时,员工们抱怨最多的就是“要写的文档太多了”!甚至很多人把进度延误归罪于写文档。
人们抱怨“文档太多了”,有两种原因:
一是流程的确很臃肿,规定了太多不必要的文档,如果是这种情况,那么应该精简流程,减少文档数量。
二是要求写的文档本身是合适的,但是人们以前写文档太少了,一下子不习惯写文档。现代人早晚各刷一次牙,我们觉得很正常。可是古代人不刷牙,如果你要求古代人早晚各刷一次牙,他们肯定觉得太麻烦了。
企业应该想办法降低写文档的难度,帮助员工们提高写文档的效率。一定要下功夫制定出良好的文档模板,给出充足的提示和示例。这样使用者就可以“依葫芦画瓢”,总比他自己琢磨怎样写要方便得多。
4.4.8建设企业管理平台
企业管理平台可能是一个软件系统,也可能是一系列软件系统的集合。企业管理平台的主要价值在于:
(1)把重要的流程制度“固化”在软件中,人们使用软件的时候就已经按照既定的流程来执行(如果没有配套的软件,流程就形同纸上谈兵)。
(2)提高管理效率。用软件来管理日常工作和事务,显然比手工记录的效率高得多。
(3)企业管理平台不仅可以积累知识财富,而且可以分析人员的绩效。
第一个问题:谁来建设企业管理平台?
通常有两种选择:要么自己开发;要么采购通用的软件,如果有必要,请开发商适当地做定制开发。
国内很多IT企业有编程情结,他们认为开发软件是自己的本行,管理类软件的技术难度不高,买软件还不如自己开发。如果自己开发成功了,说不定还能卖给别的企业,真是一举两得。
可惜这是一厢情愿,他们没有意识到最重要的问题:开发管理软件的成败要害不在于会不会编程,而在于开发团队里有没有管理专家。如果让不太懂管理的一群程序员自己开发一套软件去管理企业,这怎么可能成功呢?即使做出能用的系统,后续又得花多少精力去维护呢?更何况推向市场了。
迄今为止,国内有无数IT企业还在开发自己的项目管理软件,绝大多数半途而废,多么浪费啊。
我的观点是:如果行业内有适合本公司的管理软件或专业开发商,而且性价比合适,那么不要自己开发管理软件。要么买现成的通用软件,要么请专业开发商来做。任何时候都应当把自己的开发资源用在公司的主营业务上,这样才能够创造最大的效益。
第二个问题:如何建设和推行企业管理平台?
任何管理平台都不可能一下子具备很多成熟的功能,有个演进的建设过程。通常有两种思路:“自顶而下”地开发功能和推广应用;“自底而上”地开发功能和推广应用。
“自顶而下”是指先满足“公司高层人员”的管理需求,而后再满足“公司广大员工”的工作需求。
“自底而上”是指先满足“公司广大员工”的工作需求,而后再满足“公司高层人员”的管理需求。
理论上讲,只要坚持做下去,上述两种方式都可以把管理平台建设好。但是现实情况是有区别的。
“自顶而下”这种方式比较“讨巧”,奉行的思路是:先把领导搞定,以后慢慢对付员工。刚开始这容易博得公司高层人员的欢心,但是高层人员喜欢的东西,不见得就是广大员工爱用的东西。高层毕竟是少数人,他们自己不用,会催着员工们去用。刚开始大家积极性高,推行比较容易,但是由于面向员工的功能很弱,越推越难。我把“自顶而下”的方式比喻为“先甜后苦”。
2003年,我参与建设电信企业的研发管理流程和管理平台。有一些国外软件供应商向我们推销管理平台,每次都派销售高手过来给公司领导们做管理平台报告。PPT文件和彩页很漂亮,有很多图表,显示购买这套软件将带来什么好处。领导们看了很喜欢,甚至很崇拜,于是花了100多万美元买了美国的某个管理平台,选型期间根本没有让员工们试用。
买了之后,领导就下命令让相关事业部使用这套软件,他们相信只要下命令就能用起来。但是这套软件和员工们实际工作相距太远,实在太难用,员工们就应付了事,随便在软件中填写些东西。为了让公司领导们每月都看到漂亮的报表,总工室里2名管理员每月都挖空心思去造数据。不到2年,这套花费了100多万美元的管理平台就荒废了。
“自底而上”的方式比较“踏实”,它优先开发让广大员工们使用的功能,一边开发、一边使用、一边改进。由于员工人数很多,如果管理平台做得不好,会被大量使用者挑剔、指责。“自底而上”的方式一开始就吃尽苦头,如果坚持不住,很快夭折了。但是如果坚持做好了,那么这种管理平台的生命力极强。我把“自底而上”的方式比喻为“先苦后甜”。
我自己公司(上海漫索)的产品是“集成化研发管理平台”,我们走的是“自底而上”的路线。该产品的绝大多数功能面向项目经理、开发工程师、测试人员、质量管理人员等第一线员工,少数功能面向公司领导。
我把这个产品推向市场,历时5年才成功,非常艰苦:
产品推向市场第一年,由于功能弱,免费送给客户,人家都不愿意用。
第二年,产品有所改进,免费送给客户,人家愿意使用,但是不愿意买。
第三年,产品又有进步,这时候产品可以捆绑在我的咨询服务中卖出去,但是还不能独立销售。
第四年,产品功能已经比较不错,但只能以比较低的价格独立销售,基本做到收支持平。
尽管前4年生意做得不好,但是该产品已经积累了近万名最终用户,经受了大量第一线用户的考验。终于量变发生质变,在第五年之后,正式采购产品的客户大量增长,软件产品真正盈利。
我们向客户推销产品时,总是先帮助员工们试用。试用效果好了,我们才会和客户领导谈商务。如果试用效果不好,我们也不会想办法去搞定客户领导。所以我们的销售过程比较单纯,从来就没有采用吃喝玩乐和蒙骗的手段。
客户采购研发管理平台后,客服工程师和我自己会跟踪最终用户的使用情况。客户方员工们会不断提出问题和改进建议,我们不断汇总分析问题,不断改进,从而使产品功能越来越强。而且“买卖双方”都成了朋友。
有一个小企业的基层管理员在使用管理平台过程中,非常用心,向我公司提出了数十个问题和改进建议,我们分析后竟然采纳了80%以上。我就向对方发了感谢信,并指示本公司客服工程师:对方是个好客户,以后他提出的需求优先处理。
对方收到我的感谢信很开心,还不好意思地说:我们只花了一点小钱买了你们的管理平台,充其量是个小客户,哪里算得上是好客户啊。
我公司客服负责人答复得好:林老师一直教育我们,不要拿合同额大小来衡量客户好坏。真正好的客户都不乱花钱,他们用得越认真、越挑剔,就越促使我们进步。所以你就是好客户。
我认为:所谓好的企业管理平台,必须让广大员工使用起来,真正对他们的工作有帮助。无需讨巧领导,也讨不了巧。退一步讲,我情愿“产品做得好、卖得差”,也不愿“产品做得差,卖得好”,否则违背公司价值观“为客户创造的收益必须高于客户付出的成本”。
4.4.9量化分析与改进
国内研发管理的历史并不长,按管理特征可粗分为三个阶段:
(1)第一阶段:基于人治的管理。20世纪80年代和90年代,国内微型、小型IT企业居多,那是个崇拜超级程序员的年代,一支软件队伍能够遵循软件工程方法来干活就算得上有先进的管理了。企业管理水平取决于领导者个人的水平。
(2)第二阶段:基于流程改进的管理。进入21世纪后,国内IT行业蓬勃发展,中大型软件企业开始重视流程改进。从2000年至2010年,由于政府部门和民间机构大力推行CMMI,短短十年时间,CMMI就在国内IT行业得以普及。尽管CMMI认证有泛滥趋势并受到广泛指责,但不可否认CMMI方法论对提升IT企业管理水平有极大帮助。我对CMMI的评价是:功远大于过。
(3)第三阶段:引入量化的管理。如今很多IT企业已经制定了流程,并且有专人推行流程,接下来还要做什么?我认为是量化管理:即不断优化流程,使流程标准化和精细化,覆盖尽可能多的工作环节,并且用数字来说明企业在各个环节的实际情况。
从常识来讲,只要企业人数超过百人、研发队伍超过五十人,企业就有必要引入量化管理,否则管理者很难搞得清楚那么多人究竟做出了什么贡献、谁做得好谁做得不好!目前很多软硬件研发企业对量化管理的心态是:可望却不可及、想做却不知怎么做。
企业量化管理的目的是:精确地描述企业各项工作及其目标,运用数学统计分析方法,让人们快速、精确地了解企业各个方面的实际状况,为管理者解决问题和做出决策提供简洁明了的数字依据,从而提高管理效率、提升企业效益。
量化管理的核心是“量化分析与改进”,实施模型见图4-5,详见本书第7章“研发企业量化管理思想方法”。
图4-5 研发企业量化管理实施模型
4.4.10提升全员技能
员工技能的高低直接影响产品质量和生产率的高低。企业在任何时候都不能忘记提升全员的技能,包括技术能力和管理能力。
企业要经常性地诊断员工们的能力,同时也要让员工们自己提出提升能力的需求。
一方面,企业请外界专家来培训,让员工们快速地学习到专家的知识。这种方式的缺点是,外界专家讲的大多是公共课,不是专门针对本企业的,学会之后却难以直接应用。
另一方面,企业应当建立“自我培训”机制。企业里面绝大多数的知识经验分散在广大员工脑子里,当你遇到某个问题、百思不得其解时,其实公司里早有人解决过同类问题,但是你不知道有这样的“专家”,不知道在哪里。
企业不必在乎员工的学历高低,也不在乎他的口才怎么样,只要他有本事,就要设法把他推到讲台,把他的知识经验传授给大家。大家一起进步,这样对企业最好。
我认为比较合适的比例是:外界专家培训约占20%,自我培训约占80%。可以形成良性循环,性价比很高。