过程改进自我诊断漫谈

过程改进自我诊断（1）----少得可怜的一线人员配比

 

老板一直很得意于公司的管理规范，去年 ISO9000外审时，一位年近50的外审专家给出了“他见过的做ISO9000最好的企业”的评价，更是让老板心花怒放。公司上下，基本做到了“言必称流程，凡事要review”。 这可是很多实施CMMI的企业的目标哦，我们公司并没做CMMI，却做到了这一点，但是，利弊究竟如何呢？公司成立多年，作为一个只做软件的公司来说，规模也不算很小。市场能力挺强，能拿到合同额不低的单子，可是，公司的经营状况却不那么令人满意。可以肯定是公司的管理出了问题，作为曾经的管理咨询顾问，本能得想到应该“诊断”一下问题所在，找到解决方法，于是，开始了这方面的实践，由于职务的便利，我能够接触到公司的方方面面，可以从比较全面来思考。这也是一个管理者的职责所在。

企业管理可以从很多角度来分类，任何一家企业，首先要确定的是自己的产品和市场定位，“做什么”，“卖什么”，卖的无论是有形的产品还是无形的服务，都有一个“生产制造过程”，因此，梳理流程也好，诊断问题也好，我喜欢先从产品或者服务的生产过程开始。

产品本身生产过程的专业方法，一般称之为“规范”，在制造业中就是指生产工艺，在建筑工程中就是指建筑工程施工规范，在软件开发中就是指软件工程方法，在CMMI中则是属于工程过程的那些过程域：需求开发、需求管理、技术解决、产品集成等。

公司在技术规范上投入的力量很大，有专人做这个事情，需求、概设、详设文档模板一样不缺，业务需求、需求规格、概要设计的模板都说明详尽，示例图也有。设计部高薪养着若干架构师，他们不用写代码，专门做需求分析和概要设计，文档写得似乎很漂亮，用例图、应用场景一个不少，UML也都个个用得不错，按说这样一来这些文档就应该发挥较大的作用了。但是很奇怪，开发人员都说看不懂，花费了无数的时间在沟通上，开发人员总是要求写的细些再细些，架构师则认为自己写的已经够细了，再细就该写代码了。于是，往往在进度的压力下，文档的签字、确认和评审基本成了走过场。实际情况则是，需求和设计文档，特别是设计文档，只是用于存档。开发人员一般直接照着UI编码。因为需求文档也因为同样的原因，基本无人参照，最管用的主要是UI，跟客户确认需求的时候，用UI，项目经理跟组员交流业务时，也是用UI，客户对需求文档一般也不爱看，大致有个范围就行了，真正对着挑毛病的就是这个UI。虽说UI既能描述业务需求，也含有部分设计了，但是能不能就此废除文档呢？架构师不写代码，只怕软件公司很少见，支撑公司主营业务的“产品”生产线跨了3个部门，而能直接有产出的人不到公司总人数的20% ，这难道不是一个很大的问题吗？

 与产品相关的质量检验部门，即是测试部，测试部的人员配备不少，与开发人员基本是2：1的比例，即2个开发可配1个测试，测试应该比较充分了，可是仍然有很多缺陷都是到了客户现场才发现，甚至被客户随便点击几下就发现一堆Bug，因为测试人员不愿下功夫去熟悉业务，只是测测功能。虽然现有的测试规范很齐全，测试计划、测试用例测试报告等一样不缺，但是现在看来，值得进一步改进，不能只看形式，要重内容，尤其是测试用例的设计上。

配置管理本来也是一个执行层面（生产、检验、产出物）的事情，公司却莫名其妙得搞了个“公司级配置管理员”，打标签、版本发布、基线生成等基础工作均由“项目级配置管理员”来做，公司级配置管理员只是在那里做做配置审计，不了解项目进展，不参与项目活动，连当前版本号都不知道，真是不查不知道，一查吓一跳。

CMMI的本质是“能力成熟度”，当企业中某类具体问题的处理方法比较固定之后就可提炼为“过程”，因此，通过过程改进，就可以提升组织的能力成熟度。作为公司主营业务的软件设计、开发、测试过程存在着问题，生产和交付能力当然就高不了。

 

 

过程改进自我诊断（2）----缺乏执行力度的咨询服务

企业管理是个挺复杂的事情，流程管理、CMMI、 PMBOK、ISO9000等等都只是管理丛中的一棵树或者一束花。无论哪家企业请咨询顾问或者自己搞管理改善，目标都不会只是为规范管理而规范，为改进而改进。都是为了能给企业带来更大的经济效益。无论是直接的，还是简接的。

 

尽管CMMI并未将市场活动和销售过程纳入到它的模型，但是几年在企业的管理实践告诉我，市场或者说客户服务作为围绕业务的重要增值活动更应该放入改进的范围。因为市场、销售、售前过程的改进更容易会给企业带来“立竿见影”的效果。

 

当前主要的问题是：销售人员传递回来的客户信息，准确率极低。经常是咨询顾问一接触客户，发现满不是那么回事。连我本人都碰到过，去年有一天，销售给我打电话：“刘老师，客户明天要来看我们的PDM，请您给安排产品经理给介绍一下。”等到客户坐下一谈，发现人家主要是要看我们的项目管理系统，兴趣并不在PDM上，之所以提到PDM，人家的意思是在考虑项目管理系统怎么和PDM集成。。。。。。这个例子看起来简单，实际是由于客户提供了很多信息，销售人员没有抓住关键信息所致；

 

咨询顾问进行售前支持，一次次去客户那里，说着重复的话，写出的方案经常被客户打回来说，“不是我们想要的”，“只是你们的产品功能介绍，没看出是给我们的解决方案”，“没有亮点，看不出与同类产品有什么区别”；销售总监曾跟我谈到：“如果销售给咨询顾问搭好了一个舞台，那么咨询顾问就是演员，每和客户交流一次，就是演一幕戏，应该将我们产品的管理理念演出来，每一幕戏应该有一个不同场景”我很赞同他的看法，我们的咨询顾问这方面能力真的有点弱，经常需要重复多次才能将客户的需求搞明白，才能将产品讲清楚。就好比一幕戏不能推进剧情，总在原地踏步。

 

虽然公司去年专门请了咨询顾问改进销售和咨询过程，在其指导下，定义了一系列的程序文件和记录单，如《销售控制程序》、《企业信息化咨询控制程序》、《客户跟踪记录表》、《企业信息化规划咨询调查表》、《售前阶段工作报告》等等，这些规范性的文档旨在收集客户的信息、记录历次售前成果，但是好像收效甚微，售前成功率依然不高。或者说，虽然能签单，但是似乎与售前支持并无多大关系。

 

经过调查，发现一是无人去监督严格执行这些规范，有人做，有人不做，因此，留下的信息有限，依靠文档了解客户的信息和需求的人就越来越少；二是这些表单的设计还是有些复杂，面面俱到，大家就懒得去填。

 

问题虽然找到了，解决起来可就麻烦了。

 

 

过程改进自我诊断（3）------ 混乱的项目管理

项目管理可谓是企业管理的一个重要内容，尤其是现代企业，项目管理方法得到普遍认同和广泛应用。甚至出现了“凡事皆项目”的观点，当然，我是不赞同的，项目就是项目，PMBOK里定义得很清楚，“项目，是为了创造一个独特的产品或服务而采取的一次临时的行动。”它提供的是一次性的工作方法。 在CMMI里，项目管理是实践内容最多的一组过程域，项目策划、项目跟踪和监控、风险管理、集成项目管理等等无不和PMBOK中的过程闪耀着同样的思想。我曾经将二者详细比较了一下，感觉能把这些都掌握了，吃透了，活学活用，做起项目来应该是得心应手的。 可惜，本公司虽然表面很重视项目管理，不然也不会搞了一个强矩阵的项目管理体制，但问题仍然很多，既然是自我诊断，就直奔“问题”了。 1、始终未能定义好项目经理和部门经理的责、权、利：作为矩阵式结构，项目成员同时受到其部门经理和项目经理的领导，但是员工的考勤、年终考核却在部门经理那里，虽然项目经理也能管组员，但手中并没有实权。因为公司把项目过程中的每一个环节都分割给不同部门承担，部门经理手下的员工只负责一段，所以为了避免惹麻烦，部门经理及其员工容易出现“尽量将自己摘干净”的毛病，一有事就往项目经理或其他部门那里推。   2、公司实际的项目管理和产品使用上的矛盾：由于公司自己的主打产品是项目管理软件，按说应用自己的产品来管理项目也是天经地义的，公司也有内部项目管理信息系统，可是我觉得凡事都不能过度，老板热爱自己的产品，但是也不能就只认自家的好，老板不允许任何人在他面前用任何项目管理工具，开始只是project，后来连Excel也都禁用了。而且明明几句话就能说清楚的事情，他非要求在系统中看到，似乎我们的工具可以解决所有的问题。结果搞的项目经理很烦，除了正常的工作之外，还有一部分精力要应对公司的信息化应用要求。 我们的产品属于企业级项目管理信息系统，是面向军工行业的，属于“重量级”的项目管理工具，项目组织、角色、权限的设置跟软件公司不太一样，可能客户用不别扭，但是自己用还真是有些别扭，当然，老板也是用这种方式强制使用自己的产品，以便不断改进产品性能。事实上，也确实起到了一些作用。但是产品的应用改进和自己的实际管理还是应该分开的。 只是任何时候，任何工具的应用都不能代替人的管理，否则，岂不是用机器人就可以做管理了？ 项目管理上的问题当然不只这一点点，建立企业级项目管理体系，还有很多很多的工作要做，但是最重要的是必须搞清楚项目管理和企业运营管理之间的区别，各自起什么样的作用，"战略"不清晰，“战术”搞得再好也没用。     过程改进自我诊断（4）----- 走形式的质量保证 本公司整个的管理思想和理念可以用一句话来概括，那就是“以流程管理为核心、以项目管理为主线、以质量管理为导向”，也就是说，本公司所有的活动都是以流程来驱动的，所有的活动都以项目来串联，所有的活动都以满足公司的质量体系为目标。由此可见，本公司对质量体系建设重视到了一个什么样的高度？ 可惜，重视依然在表面上。无论企业实施何种管理体系，QA这个角色都是必不可少的，体系的推动，改善都有赖于QA 的工作，在我的职业经历里，曾经有一段非常充实忙碌的日子，2003，在一家公司做QA经理时，按照领导的要求实行“日审计”制度，深入到项目组中，天天帮助项目经理发现问题，也包括检查项目经理自己的问题，也经常给项目组培训，让他们了解规范的管理有什么样的好处，我记得最多时一个QA管5个项目，很累，但是很管用，很快，我们Team里的QA基本都得到了项目经理的认可，甚至出现项目经理主动要求派QA的现象。但是在本公司，专职的QA居然不参与项目！天天只是坐在那里时不时的发布一下质量体系文件，项目QA都是本项目组测试人员兼职的，可想而知会是什么效果，测试人员一定是将自己的本职工作放在最前头，其次，测试人员受项目经理领导，他又如何保证能客观反映项目的状态？结果，QA主要的工作就是审核一下文档是否符合格式，称为“标准化”检查，要说这也不是没有一点价值，但是对于设置了专门的质量部门来说，实在是个浪费。这个问题与前面提到的“公司级配置管理员”如出一辙，专职QA，CM们要了解项目情况，了解项目产出物，不是靠自己主动参与项目活动，不是以专业的角度去诊断项目过程中的问题，而是靠项目经理给他们“报告”，当然，由于项目经理的上级不是他们，所以项目经理也就不可能很好配合了。   虽然大家都针对这种现象提了不少意见，也许，对本公司来说，这不是什么主要问题，也就一直没有下决心纠正。 质量保证活动没有给项目带来太多实质上的帮助，直接导致了流程执行的表面化，形式化，公司流程将近100个，对于规模还不是很大，业务也比较单一（以项目管理软件为主）的公司来说，真是够多了，而且，这些流程里面，主流程反而严重缺失，按照也应该是质量部牵头组织人编写，但公司的质量体系文件一般都是各部门自己写自己的，质量部做一下“标准化检查”也就发布了。以前做CMMI 咨询时，遇到不少客户问：过程体系文件到底应该谁来写合适？做咨询的时候，我是强烈主张当事人自己写的，比如项目管理流程最好就由项目经理来写，但是进了企业从事管理之后，我就不这么看了，项目经理等一定要参与，但是不一定亲自操刀执笔，流程制定也有其专业性，应当由专业人士来制定，本公司专职搞ISO9000 的人以不熟悉业务为借口是说不过去的，这就好比写小说，描写医生的生活，并非一定要医生来写才能写得好。要写的生动、好看，还得是作家，但作家绝不可能自己呆在家里就写出他不熟悉的生活场景，他们不是还得“体验生活”吗？道理是一样，体系建设者们应当去了解各项活动的特点、要点，然后将其提炼总结出来，流程化，这样他们自己去检查执行情况时，才能准确判断出哪些是执行上的问题，哪些是流程本身的问题，就不至于让项目经理们讽刺说“只会挑错别字了”。虽然从”三员分立”的角度来说，立法和司法最好是两拨人，不过一般对软件企业，现实一些，我认为还是合在一起做比较好，毕竟软件行业的各种管理思想、模型、体系等跟其他传统行业相比，还是没有那么成熟，需要多实践，多总结。 写了几篇对过程改进诊断的文章，一个公司，不管现在处于什么样的阶段，自我反省都是有必要的，如果真到了已经无法挽回的那一天，就是神仙来，也救活不了。