突破质量困境
--------------------------------------------------------------------------------

一、客户是最重要的
在这里，我们先来问几个问题：
问题1，如果客户对你公司的产品没有一点不满，没有一点抱怨的话，现在需要改进质量吗？
问题2，如果一个产品所有出现过的问题都集中在一天重现，客户会接受这样的产品吗？（客户接受了这个产品，原因是问题在一段相当长的时间里一个一个出现的，而且似乎每个都不是大问题，所以也就凑活着接受了）
问题3，如果公司一直为一个客户连续不断的开发产品，而且问题也连续不断的重复出现，你觉得公司还会拿到订单吗？就像一家饭馆的饭总是有沙子，你会一直订他们的饭吗？但如果只吃一顿的话……
从上面的问题可以看到，质量是客户的基本要求，质量改进是为了适应客户的要求！在全面质量管理理论中着重强调的就是“以客户为中心”，这不仅仅是一个口号。那么以客户为中心应该怎么做呢？以客户为中心首先需要注重客户提出的质量问题（以下称客户问题），注重的意思就是切实的为客户去解决问题，而不是重复的解决同一种问题！
二、问题
客户能够发现什么样的问题？
认识客户问题，首先要从客户的调查开始。曾经针对以前的一个软件项目组进行过调查。客户参与了项目的系统测试工作。每天项目组将客户发现的问题记录下来。记录中总共有168个问题。在问题的分析中，仅仅简单分了三类，分别是：业务问题、一般性问题和重大问题。其中：
业务问题是因为对业务不熟而产生的问题。
一般性的问题是常见的、重复性出现的问题，例如界面问题、计算错误等。
重大问题是比较难以解决的技术问题。
经过分类后，发现业务问题有38个，占整个问题比重的23%，一般性问题127个，占75%左右，重大问题共有3个，不到2%，比例图如下：

一般性问题主要集中在：页面的显示，按钮的大小，文字的大小和格式，界面风格等问题。
在一般性问题上还需要说明的是，其中部分问题是被客户重复的提及。
业务性问题主要集中在：用户权限的分配、业务规则等。
在业务性问题上还需要表明的是，大多数业务问题在实现的时候都感觉不能确定，没有明确的表述，在实现的时候，开发人员以自己的理解方式，就“想当然”的处理了这种疑惑。于是导致测试的时候出现问题。
以上这些问题在公司刚刚成立的时候就存在，现在依然存在，以前没有做过这样的统计，所以也不知道现在是否有所改进，或者这种改进有多大。质量工作做到那里去了？连小问题都不能解决，又怎么能解决大问题呢？
以前问题那里去了？
在这里我们必须先弄明白“什么是问题？”所有造成客户不满意的事情都是问题。小问题似乎可以忽略，但是小问题多了，就变成了大问题！从项目组的记录中可以看到客户的不满情绪在加大，在后面的问题记录中都加上了硬性的修改时间。可以看到客户的要求越来越强烈了。软件的意思应该是一种服务。服务的优劣就应该以客户的满意程度来衡量（这可能也是质量定义的一个主要来源）。
在“什么是问题”的认识上，公司经常会受到项目组的误导。但这种误导不是项目组的错，而是因为项目自身原因造成的。原因如下：
（1）、质量问题可以缓解。我们都知道项目是有资源限制的，。因为有限制，所以他们会做最主要的工作。对一般的商业软件项目而言，追求进度就符合了公司对成本的要求和客户对进度的要求。公司商务人员和项目组通过自己的勤奋努力和良好的态度，总会让客户容忍系统的一些问题。所以质量问题绝对不会是最主要的问题，而成本和进度就成了最主要的问题。
（2）、项目更注重技术。就像一个问题的解决，他们更注重的是解决这个问题的技术方法，至于重复出现的次数就不那么让开发人员感兴趣了，即使问题再出现几次，只要这种技术解决方法掌握了，也就不是问题了。PM顶多让某个或者某几个人注意一下就可以了。项目完成后，新的项目很快就会上马，虽然开发人员意识到存在问题，但也很少有时间去深入思考这种问题。开发新的项目，有新的技术问题等待解决。而且下一个项目肯定会有不同的人员加入，所以眼前的问题就已经够忙的了，已经没有心思考虑问题本身的情况了。
（3）、缺少连续性就缺少改进的基础。项目是一次性的开发任务，太多模块的编写都是一次性的，不能公用的。这个地方出现的问题与那个地方出现的问题不太相同，所以每个问题似乎也是一次性的。既然下一次出现的问题会有不同，而且眼前仅仅有少量问题需要修改，所以就没有兴趣去总结。因为缺少连续性所以也就缺少收集的必要，所以就缺少研究的必要。
（4）、项目组与公司的关注点重合。这有两个方面。首先，项目组是公司解决客户需求的根本，任何妨碍项目组的问题都是公司的绊脚石。公司的目的与项目的目标是一致的，所以公司和项目组的关注点就很容易重合。其次，很多软件公司的管理者都做过开发（尤其是CTO），所以他们理解项目的难处，也知道项目当前最需要解决的是什么，为了让项目组顺利实施，他们甚至会赋予项目组一些特权，减少别人的干扰。他们的关注点就很容易和项目组重合。当项目组遇到了技术问题、人员问题时，公司都会尽力解决。项目认为是问题的，公司就会把它当成问题。而项目组认为不是问题，或者是小问题的时候，公司也很容易忽略。
公司对问题的判断不能仅仅与项目组相同，更需要倾听客户的意见。如果公司和项目组的认识是一样的，那么就失去了对这些问题的察觉能力。
如何捕获问题？
认识到了问题才会去寻找解决问题的方法。那么下一个问题就是“谁会发现问题？”问题来自于客户公司参与项目的人员。这些人员发现问题后，不但会传递给我们，更会上报他的领导。所以客户公司的领导总会有一些要求。客户问题的调查和收集应该集中于客户参与项目的人员。了解他们的要求和想法，他们的要求就是客户的最终要求。当然前提是客户必须参与项目工作。
注重客户的问题就应该及时记录，不管是那个部门的人员，只要得到客户问题就应该记录。客户问题记录应该作为一个项硬性指标，要求每个项目都必须实施，而且每天一个记录（因为这样的记录更有利于问题的分析），要求记录详实、准确。做好记录后，应该及时的将记录结果传递给公司的质量管理部门，质量管理部门应该设立专门人员对问题及时汇总和整理。在一定的时间段内（比如两个星期、一个测试阶段等），做好客户问题报告。客户问题报告属于重量级文件，所以报告应该直接提交公司领导。
三、 分析
如何认识问题？
在这里要介绍一下传统工业改进的一个方法，叫做“主导因素”。我们都听说过5M1E，说得就是影响生产质量的六个方面，分别是人（Men）、法（Method）、料（ Material）、机（Machine）、 量（Measurement）和环境（Environment）。这六个方面都会对产品造成影响，但是其中会有一个主要因素。这个因素就是急需改进的方向（Pareto原理的应用）。
软件行业也是一样，我们的改进也存在主导因素。如何发现我们自己的主导因素呢？由于传统行业的特性，所以很多指标都是可以度量的，因而很多数据都很明显，稍加统计、分析就可以发现。软件行业不同，不少问题我们自己难以发现，但客户能够发现，所以在一定程度上我们的数据收集依赖客户。对客户的调查主要是了解客户的要求和不满。就像上面所列的问题，我们可以明显的看到，最主要的问题（主导因素）就是一般性的问题，也就是那些界面问题。
在上面的例子中还有一个重要的问题是业务问题。在发现业务问题的时候，客户一般会认真、细心的对此进行讲解，他们并不会对这种问题有太多的抱怨，他们在讲解的时候，也会有一种成就感。当然如果这种问题多了，那也会成为主要问题！
这种调查是必要的，即使公司已经建立了测试队伍，即使测试已经初见成效，但是公司依然存在质量问题。改进的目标和方向也应该从这种调查和分析中取得。因为你的问题总会流到客户那里，而他们发现的主要问题也就是项目最容易出现的问题，也就是公司要改进的方向。在这种情况下，公司应该对测试问题和客户问题都进行统计和分析。
如何发现与解决？
了解了主要问题后，如何去解决呢？当客户发现问题后，项目组的解决只能是弥补性的，这种解决方式不可能从根本上解决这类问题。在问题传递到客户前，可以增加测试人员，提高测试效率，但这也不是根本解决办法，而是一种缓解方法。最有效的解决办法应该是寻找这种问题的根源，通过预防措施将其解决。
如何预防这些问题呢？要预防这些问题，就必须弄明白问题的产生原因和产生阶段。主要分析步骤如下：
（1）、对问题进行分类，这个分类方法可以问题解决的难易程度、表现形式等来划分，如果公司的工程化标准更高的话，可以以问题修改的成本、时间等来划分。选中一个特性之后，需要对问题的表现进行等级划分（比如：高、中、低）。在刚开始的时候，建议等级不要过多，而且初期的问题最多，问题主要集中在一般性的问题上，很容易就认识到了，所以过多的问题档次会增加分析的工作量。这种分类主要为确定主导因素，减少其他因素的干扰。
（2）、确定问题的轻重程度。问题分类后，针对问题的数量分布来确定问题的轻重程度。这个分类方法可以以客户要求的“强烈程度”为依据。那么要求的强烈程度怎么衡量呢？比如客户问题总共被划分了3个等级“大、中、小”，每个等级有多少问题马上就可以明了，可以简单的根据数据的大小进行判断，数额最大的就是客户要求最强烈的。对于软件行业来说，客户的强烈要求程度并不是因你的修改难易程度和成本的大小来决定的，所以可以不考虑这两个因素。当然这种判断是有误差的，这种判断仅仅适合于初期。
更进一步的分析可以对问题进行赋值，比如大问题赋值为4，中问题赋值为2，小问题赋值为1。问题的赋值×问题的数量就作为客户要求的程度数值。如果问题的数值都比较接近，那么可以增加或者改变度量的特性，比如修改成本、时间等。问题赋值的大小关键在于对问题的认识方向上，例如用修改成本来赋值的话，可能一个大问题就会是几十个甚至几百个小问题的总和，但如果用客户要求的强烈程度的话，可能一个大问题跟一个小问题的值相差无几。有了这些数值，要运用方差分析、风险分析还是其他各种图表分析法那就由你选了。
（3）、每一次分析都应该对问题进行排序。一个连续的、长期的分析应该注重问题分类的准确程度，同时应该注意问题的顺序变化。及时的了解变化趋势，并积极的调整自己的工作方法和工作重点。连续的、长期的收集分析过程中，可以得到自己的质量标准。
在确定了主导因素之后，应该对问题进行深入的研究，这个研究主要是解决“问题产生在那里？如何产生的？”通过对产生原因的分析和产生阶段的定位，才能够确定问题的解决方法。这种分析应该以会议形式举行，问题的分析应该由公司组织，不同项目的开发人员和质量管理人员共同参与完成。这个会议应该有两个主要任务，一是问题分析，二是找到解决方法。也许你已经看出，这个会议就是SEPG会议。
修改所花费的时间和金钱直接关系到公司的成本和效率，这方面也应该下功夫去研究。目前，建议中小型企业，尤其是质量管理刚刚起步的公司从简单的统计方式入手。原因是：（1）、各公司的管理、工程水平不同，所以对各种不同数据的认识程度也不相同。比如说对问题修改的时间和成本的度量，这种度量可能会让管理水平相对差的企业付出过多的劳动，而且可能导致数据失真。（2）、由于现在公司的问题比较多，而且大多集中在一般性问题上，所以即使采用了时间、金额等数据进行度量，但发现的问题也会集中在一般性问题上。（3）、既是发现“重大问题”是主导因素，从市场角度、从改进的可行性方面来分析，首先改进的也应该是一般性问题。数据采集方面建议以客户要求为主，这不仅因为客户问题容易收集，也因为客户问题是至关重要的问题。对于中小型公司来说，市场问题可能是最重要的问题。

四、转变意识
以前工作出现的问题？
实施是解决问题的最关键的阶段。实施一直是大多数软件公司头痛的问题。实施问题虽然有人的因素，但也存在一个方法的影响。在这里仅仅讨论实施的方法。总结前一个时期的质量工作，感觉最不得当的是工作方法。以前的质量管理工作脱离了市场，并没有和客户的要求达成一致，而形成了另外一个要求，并且与项目组形成了对立关系。

在脱离市场的情况下来要求项目组完成质量目标，难免产生不当的要求。而项目组和管理者都是紧密的按照客户的要求来做，所以质量要求和市场要求在发生冲突的情况下，必然是前者被抛弃！曾经遇到过客户认可，而质量管理人员不认可的情况。在这种情况下，质量管理工作似乎就是给项目组“画地为牢”了。
我们要改进的工作是将客户问题提炼成质量要求，一切以为了满足客户要求为基准。以前的质量工作与项目组形成了一种对立关系，现在要使质量管理和项目组工作结合起来，劲往一处使。客户已经给项目施加了很大的压力，质量管理人员应该为项目缓解这种压力，缓解的方式是为项目组提供正确的、有效的改进方式。为项目组提供正确的工作方向和建议。公司应该对项目的改进做长远的规划。

在前一阶段，质量工作遵循了西方SQA的太多原则，比如仅仅对过程负责，不对项目质量负任何责任等。在很多时候，这些原则的提倡被项目组认为是在“开脱责任”，并且产生了逆反心理。他们认为质量管理人员既然不负任何责任，那也就不需要他们参与项目，所以质量管理人员的介入是没有必要的，也是不合道理的。而且在旁边比比划划让人反感。
这种不适合的情况早就出现了。改进的方式是：首先改变以前SQA的认识。我们不是非要让某个人来对质量负责，我们的目的是如何做好质量工作。再加上国内的软件质量管理工作起步时间较短，还没有完全摸清情况的时候，SQA的工作原则可以改变，而且需要改变！如果以前的工作原则让项目组反感，那么现在就应该改变，并且适应自己公司的情况。
改变的内容首先要树立一种“服务”意识。公司是为客户服务，质量管理就是为项目组服务。质量管理部门在整个公司范围内提供一种“质量服务”。客户就是“项目组”。其次注重适应性的改变。就像SQA工作原则的问题，这种情况不应该被继续保留，应该马上进行改善。
通过统计分析，SQA应该将发现的问题及时通报项目组，并提出注重的内容。例如上面的例子中所提到的第二类问题（业务问题），经过调查发现很多业务问题在设计和实现的时候就不能明确，但是由于缺少交流，所以发现问题的人没有将问题暴露出来，并且按照自己的想法将其实现。结果遗留到客户那里。对于这种问题，质量管理人员应该在设计阶段及时给PM提出，并建议PM及时采取某种形式进行纠正。这种预防性的措施是最好的质量管理方式。
在这里顺便提一下项目管理。现在的项目管理基本上集中在进度管理和人员管理上，对于问题管理相当薄弱，原因就在于不知道会产生“什么样的问题”。在缺少问题管理的情况下，项目成果的质量自然会受到怀疑！这种统计可以让我们认识问题，是加强问题管理的必要内容。
试点
很多好想法好制度，在刚刚实施的时候就涌现出一片反对声音，过不了多久就发现实施效果欠佳，实施中阳奉阴违等情况，最终导致新制度的夭折。这种情况的发生有几个方面的原因。首先一点是制度本身存在的问题导致实施困难。其次是员工对新制度的抵触心理。在实施的时候，建议企业先进行试点试验。试点就像中国搞经济特区一样。不要一下子就全面推开，这样夭折的可能性最大。
试点的目的是为了取得改进的方向，制度实施效果和可行性的大小。试点前应该有试点计划，规划好试点的内容和参与的人群。试点前应该针对相应的人群对试点内容进行培训，并且讨论试点的方式。应该及时的了解试点情况，了解试点人员的反应和要求，应该对试点人员的各种角色进行面对面的交流。为取得试点数据，应该及时针对问题进行收集和分析。对于不适合的地方应该进行改进。改进后内容的实施也应该及时通知试点人员。试点结果是宝贵的，所以应该要求试点人员记录其中的问题，最好能够提出改进的意见。
宣传
宣传主要是说明制度建立的原因和目的，解除员工的抵触心理。
为什么CMM的实施没有效果？
在软件质量管理的实施中，CMM是不可缺少的指导。它循序渐进的方式和详细的工作分解，可以减少实施的难度和失误。但是CMM也存在一定的缺陷，首先是CMM的范围比较小，它不包含市场方面的内容，所以在质量管理的实施上就缺少了客户这一环节。我们都知道CMM的核心就是全面质量管理，全面质量管理注重的是“以客户为中心”。所以在我们实施CMM的时候，经常失去动力和方向。
CMM在国外得到了很好的发展。在国内的企业中，尤其是含有外包业务的企业中CMM也得到了很好的发展（问题3）。但是对于中国的大多数的直接面向用户的企业，CMM的实施似乎并不那么顺利。CMM取得世界公认是因为在美国的成功，在这些发达公司实施CMM前，他们已经建立了一套完整的、有效的市场机制，能够及时有效的反应客户的要求和市场的变化。在全面质量管理成功实施多年后，对市场的调查已经成了他们的习惯，也认识到了质量在竞争中的作用。再加上CMM本身的指导意义，所以在实行的时候很容易见效。
印度的软件大部分是向美国出口的，而CMM就是评估供应商能力的最好的模型，所以印度人就顺应了美国人的要求，成功的实施了CMM。在国内的应用中也呈现出这种趋势，就是外包型的企业，或者前期以外包为主的企业，或者想做外包的企业很容易就向CMM靠拢了。他们在实施过程中得到了很多帮助，同时他们的问题也很容易被客户反应出来（客户水平高），所以他们的改进也是比较及时和有效的。
但是国内的没有外包业务的企业就不那么幸运了，因为管理经验和市场反应能力不是很高，不能够及时发现自己的问题，而且也没有完全意识到质量的作用，客户也不是固定的，大多都是一次性买卖。所以实施的时候就缺少方向，缺少动力，缺少效果。
CMM框架比较完善，所以在实施的时候总是会自然不自然的就在这个框架内寻找解决问题的方法。我们考虑解决问题的方法几乎都是管理和技术上的，也因此我们仅仅在考虑实施“方法”的问题，而且这种方法也仅仅是在开发过程中，在这个范围内这种方法也就不可避免的延伸到其他的领域。没有系统的去考虑质量管理实施的目的，就非常可能失去方向和动力，在这种情况下，即使方法再好也难以见效！
五、总结
以客户为中心就需要注重客户问题，注重的意思就是切实的为客户去解决这种问题。可能客户对公司的服务满意，因为公司及时的处理了客户的某一个问题，对于某个客户来说，这是最重要的。但我们是不是在重复的解决同一种问题？认识到客户问题有什么用处呢（这个问题似乎在软件企业比较有用）？回答是“认清自己，调整自己，完善自己”。
质量管理人员就是客户代表。在软件企业中，应该首先树立为客户服务的思想，建立质量服务意识，转变以前的思维定式。我见过不少软件质量管理人员都不愿意考虑客户问题。其次在实施质量管理的过程中，不一定要完全按照CMM的架构来工作。CMM本身也提出了灵活处理的意见。那个部分有用就用那个部分，就像做二级的时候可以实施三级中的培训和同行评审一样。质量管理不是要一下子就解决所有当前的问题，这是不经济也是不明智的。即使在实施某些KPA时候，如果还不具备某些能力和知识也不要完全照搬。比如在实施软件项目策划（SPP）这个KPA的时候，它共有15个活动，也许活动9、10、11、13、15都是难点，难在不知道该如何去做，更不用说是评估和数据收集了。在这种情况下，建议实施的时候暂时将这些“活动”搁置，研究之后再去应用。如果完全照搬很有可能就让“计划”变成“废话”，而且这种情况非常影响信心。这些活动将是下一步改进的方向！再次就是建立试点机制来检验制度的可行性，并及时完善，并通过宣传来缓解和引导大家的情绪。“以客户要求为导向，以CMM为指导”进行质量工作！也许这就是真正的质量突破口！
质量建设不是一蹴而就的，所以我们需要耐心，更需要毅力。在这里特别要提醒那些管理者，尤其是那些刚刚脱离了开发的管理者，不要像做项目一样做质量管理，不要期待一次就可以解决所有问题，项目管理和企业管理还是有差别的，要耐心，慢慢来，好方法也需要时间来验证。