【案例正文】

背景介绍：我公司主要提供电力方面的软件，软件产品，市场供求关系还不错。一般市场部一个人负责一个片区和客户沟通，在客户需要实施和提供技术支持方面的工作时，由项目部安排人员前往，供电局小型的维护，一般靠电话联系，合同的签订由项目实施人员或者市场人员负责收集信息。一般情况下，需求主要通过市场人员和在项目实施过程中由实施人员反映到开发这边及用户在使用之后觉得要增加新的要求，然后进行开发。目前我们自己必须承认，大部分开发经验不多，在没有进行业务培训的情况下，就直接实施编写代码，并且缺乏必要的设计文档，团队合作精神有待进一步加强提升。
目前所面临的问题：
在实施现场，实施人员在案场解决了这个缺陷后，在另一个案场实施人员又遇到了相同或都相似的故障，实施人员往往会四处求救，但有时解决过此类故障的人员在接到电话时，也会爱莫能助或者将此类故障的解决方法也无从下手。
开发人员及项目部在进行新功能或新的要求及修补缺陷时，实施人员在现场进行变更时，没有完好的记录，进而导致后续的缺陷及更新的要求不断。进而导致项目进度延期现象严重。
目前所要解决的问题：
加强相关文档管理意识，对实施过程进行标准文档化；记录在现场实施过程中发现的缺陷与故障解决方案，收集成册，可提高故障解决处理的时间。
我的分析：
文档重要性意识不全，文档是软件产物必需品。
解决方案：
1）记录：记录活动的过程和结果，最常见的记录就是表格。一个过程可能涉及A、B、C和D四个活动，并由不同的人员执行。每个人完成各自活动后就记录处理过程和结果，并签字确认。因此这个表格留下了所有人相关人员处理的“痕迹”，一旦出了问题就可以回溯，确定是哪一步出了什么问题。
2）规程：光有一个表格还不行，还需要一个文件规定活动的执行顺序和要求，这样的文件就是规程。规程表示按A-B-C-D顺序执行，复杂的规程还可能包括条件分支，每一步骤的具体操作和要求也应该在规程中描述。
3）状态：有了记录和规程还会发生问题。比如，记录丢失了而不知道谁负责（甚至根本不知道丢失了）。这是因为不知道记录的状态当前在谁手里，处理的结果如何。因此还需要状态文档。
开发人员都知道“质量”的重要性，但却不能正确看待质量的“代价”。一旦需要他们填写表格或者严格遵照流程工作时，多数都会说“太麻烦了”“效率太低了”。的确，如果没有文档工作一定程度上可以提高效率、节约成本，但长期看因管理混乱和质量低劣带来的损失可能远远大于短期的利益。还有一种常见的错误看法是“质量就是凑齐文档”，表现为在进度压力下违规操作，待完成项目后匆匆补文档。坦率地说，如果补的是中间文档（例如部分详细设计）还情有可原，如果补“过程记录”则实在不甘恭维。例如，在项目完成后补《测试缺陷记录》的情况，其实这时补这些文档对测试过程的管理已经根本没有意义，花时间精力仅仅是让项目看起来规范一些，可以算是一种“粉饰太平”的行为。我个人认为，如果真的认为一个过程不需要文档也可以控制，则可以进行适当的裁剪。其实项目并非越规范越好，应该根据具体的质量要求平衡质量和进度、成本三者的关系。
质量控制指采取适当的方法监控项目结果，确保结果符合质量标准，还包括跟踪缺陷的排除情况，典型的例子就是测试。对于软件开发来说，重要的质量活动包括：
1）评审：检查项目中间产品，早期发现缺陷以减少后期修改和返工的工作量。
2）测试：直接检查软件产品中的缺陷，确保产品符合要求。一般通过单元测试、功能测试、集成测试、压力测试实现。
3）缺陷追踪：记录和追踪缺陷从发现到解决的整个过程，确保所有的问题都有结论（注意，并非一定都能解决，解决不了的要进行评价）。这是与评审和测试配合使用的一个重要管理过程。
4）审计：对项目的工作过程进行检查，确保所有活动遵循规程进行。
5）变更控制：在前面的章节中谈过，这也是一个重要的质量活动。
6）配置管理：记录这些中间和最终产品（配置项）变化的历史，确保他们的正确性和一致性。
质量管理不是一堆文档就可以解决问题的，要想确实作好有三点很重要：一是培训，要确保员工知道为什么要这样做？能解决什么问题？具体如何做？没有这种培训，员工很容易把质量管理理解为填写各种表格的繁文缛节。二是与客户交流，很多时候因厂商没有与客户进行必要的交流，客户总觉得“什么事都要填表”是在故意刁难；通过解释客户往往非常理解，觉得这正是厂商做事规范的表现，因此会变得很配合。三是慎重选用SQA。
SQA典型职责如下：
1）根据项目特点对过程进行裁剪，并审定最终的质量标准；
2）帮助项目经理制定计划并最终审批，过程中对变更进行审批；
3）进行日常的项目审计，确保项目按规程工作；
4）在阶段点对项目的基线进行审计，配置管理情况；
5）收集和分析各种度量数据，并向高层报告项目情况；
6）对项目组成员进行培训。
总之，质量管理主要通过“文档”控制“过程”。质量管理需要一定代价，要平衡与进度和成本的关系。质量保证是确保最终产品质量的一系列活动；质量控制是确保最终产品满足要求一系列活动。软件项目中的质量管理的重要角色是SQA。

分析1：1.组织的能力:组织能力应建立在组织之上,而非个人.因此对过程中的经验加以文档化非常重要.
2.质量管理必要性:项目越来越大,内容越来越复杂,就个人能力是很难确保完全一至,必须在组织内,组织之间,项目各环节,项目各组成部分进行很好的约定,以免出现不必要的返工或错误,提高交付物性能,这是生成之本,也是减少工作量浪费的重要方面.
3.案例中的作法感觉还有许多可以改进的地方.可以多参考CMM3等相当做法.

分析2：案例中有一个典型的问题是需求的变更管理，由于需求变更的随意，需求跟踪的不到位，没有人能完全清楚地知道开发活动中的重大变更的次数、原因及变更的结果，这将对后期的维护带来很大的麻烦。建议引入需求管理系统进行需求的管理和跟踪，所有需求变更必须记录，所有需求变更必须进行跟踪。

分析3：从案例背景来看，质量管理的基础比较薄弱。个人感觉不宜做太多复杂的事情，那样会增加不少风险。

从问题解决来看，其实只要现场人员做好维护记录就差不多了。另外，虽然说大家的经验普遍欠缺，但我相信总有一些经验不错的，所以可以补充一个维护方案方面的记录，组织者这样一些人做一些维护方案的评审活动，也是一个有益的补充。

其它的事情应该说都是必需的，但是个人感觉应该在具备了一定基础以后再实施比较好。