过程改进自我诊断（1）

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

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

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

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

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

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

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