管理上的问题不能得到彻底的解决，软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司（以下简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业内人士参考。
 
　　1.软件企业的组织结构

　　(1)A公司结构

　　图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。

图1

　　* A公司中，QA(Quality Assure)部门与研发部门独立，负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组，制定公司流程。
　　* SSG(System Support Group)类似我们的IT部门，负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护，计算机资源属于SSG，由各个项目向SSG提出需求，项目结束后，设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。
　　* 人力资源部门负责公司的人力资源管理，并维护员工的技能数据库。项目开始时，项目组向人力资源申请人力，向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG，释放人力资源到人力资源池，并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。

　　(2)项目组结构

　　1) A公司对项目组进行独立核算，项目具体负责人为PC(Project Coordinator)，负责项目计划和执行，对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束)，PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外，所有其他外部接口都由EM(Engineer Manager)完成，EM负责与客户打交道，向SSG、人力资源要求资源，与其他项目组协调进度。
 
　　2) 汇报关系为:
　　Team Member->Team Leader->PC->EM->研发总负责人。

　　3) 印度工程师分为7级，半年一次考评，即半年有一次升级机会。
　　1级:Software Engineer，刚毕业的本科生和研究生。
　　2级:Senior Software Engineer。
　　3级:Project Leader。
　　4级:Project Manager。
　　5级:Senior Project Manager。
　　3级可以成为PC，4级可以成为EM。刚开始平均2年升一级，越往后升职越慢。

　　A公司规定，一人最多可以同时兼任两个项目的PC，EM管理的项目没有限制。

　　A公司通常的项目组为4到5人，最多不超过10人。

　　以上是A公司（同时也是印度大多数规范化的软件公司）的组织结构和项目组结构。可以看出，A公司的组织结构非常清晰，各个部门分类非常细，任务明确，软件生产的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总经理，层层管理，沟通渠道畅通。而在我国，管理的不规范往往首先体现在公司的组织结构上，集中表现为部门的缺失和管理的交叉上。我国的软件公司，大部分规模较小，开发人员超过100人的公司很少。在印度，软件公司无论大小，都是“麻雀虽小，五脏俱全”，绝不会因为公司的规模大小而改变合理的组织结构。因此笔者认为，国内的软件企业要想有效地保障产品质量，首先就要在构架合理的组织结构上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构不合理，其他方面再下功夫也是徒劳。有人说，因为国内软件企业规模小，所以造成结构设置的欠缺，但笔者认为恰恰是因为没有建立一个规范化的组织结构，才会使软件产品质量不保，进而严重影响了企业的发展扩大。

　　2.项目计划

　　凡事预则立，不预则废。这里的“预”就是指计划。对于软件企业，计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司，项目开始之前必须先估计项目的规模（以代码行数来衡量）;然后制定项目计划。通常时间为2～3周，已知的最长有5周。EM负责制定项目 EWP(Engineer Work Paper)，其中定义了项目需要的人力和计算机资源，由相关部门同意，并报研发总负责人批准后才能开始项目。

　　项目的正式开始时间由项目组的Kickoff Meeting算起，Closeout Meeting结束。

　　大概很多人都听过这样一句话：“计划赶不上变化”。这种“变化”对某些行业而言也许并不会产生太大的影响，但对于软件企业而言，却会给软件产品的质量保证带来严重的负面影响。为什么会造成这种“计划赶不上变化”的现象？究其原因，笔者认为主要是因为对计划的重视程度不够，计划过于笼统、粗糙导致可执行性太差，再加上一些人为因素的影响，必然会产生这样的后果。

　　如果我们的软件企业都能像A公司这样，在作计划时能考虑到每一个细节，不是仓促做出决定，而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改，最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响，那么就不仅能够减少大量资源的浪费，产品的质量也得到了保障。

　　因此，对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。

　　3.项目管理

　　当企业构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。在这个阶段中，项目管理起了重要作用，它所涉及的环节相当具体复杂，下面先介绍一下A公司在项目管理上的具体细节：

　　(1)开发阶段和项目周期
　　开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。
 
　　(2)流程

　　* A公司对流程比对项目更重视。
　　* 软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面，包括从最开始的意向到最后软件的版本发布(release)，都有相应的流程规定，基本上已形成一种工业化的软件开发。
　　* 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。

　　(3)计划

　　1) 计划详细、周到。

　　2) 流程中明确定义开发阶段。
 
　　3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
　　* 进入条件，输入;
　　* 验证方法;
　　* 结束条件，输出。

　　4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。

　　5)计划中每个活动都比较具体，每个活动的时间以天（半天）为单位。计划包括了开展质量控制活动的时间。

　　(4)Review

　　按印度公司流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了，而Review则是一个非常简单有效并能尽早发现软件中错误的方法，可以说，任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。

　　在印度软件企业，现有这么一句口号：凡事有计划，凡事必review。

　　(5)QA

　　QC（质量经理）作为质量保证部门（SQA）的代表，监督和保证项目的进展遵循QMS各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。

　　(6)度量数据

　　CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集，包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说，有了这个项目档案，你就可以完全了解这个项目的开发过程。

　　(7)团队精神

　　印度公司都比较强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。相对而言，印度员工的合作精神和协调精神都比我国员工要好得多。

　　(8)培训

　　印度公司都比较强调培训，一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。

　　(9)配置管理
　　在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
　　(10)记录

　　记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
 
　　1)与客户和其他项目组的所有往来必须邮件记录。

　　2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。

　　3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。

　　4)记录比较准确、比较客观。

　　5)许多记录都是通过定量的数值记录，强调以数据说话（CMM4级的重点就是量化管理）。

　　以上是A公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。除此之外，我国的软件企业在产品开发管理的过程中，还易出现以下几个方面的问题:

　　1)需求说明差─需求不清楚、不完整、太概括、或者不可测试，都会造成问题。

　　2)不切实际的时间表─如果在很短的时间里要求做许多事，出现错误是不可避免的。

　　3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。

　　4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。

　　5)交流问题─如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
 
　　这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合A公司在项目管理方面的经验，笔者提出一些相应的解决方法，以供参考：

　　1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。

　　2）合理的时间表――为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

　　3)适当测试─尽早开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。

　　4)尽可能坚持最初的需求─一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。

　　5)沟通――在适当时机进行预排和检查;充分利用团组通信工具―电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档:进行远距离联合作业及协作;尽早使用模型，使客户的预想表达清楚。

　　4.PC（项目经理）

　　项目经理是项目成败的关键人物，其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出，以A公司为例详细说明PC在整个产品研发过程中所扮演的角色，希望能对国内软件企业的项目经理有所启示。

　　（1)在A公司，按流程在一个项目正式开展之前，项目经理需要完成：

　　* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。

　　* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员，描述项目配置项列表、配置管理库、版本管理计划等等。

　　*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。

　　（2）在项目开发过程中，项目经理需非常了解项目进度，进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。

　　（3)总的说来，PC安排工作有这么几个特点:

　　a.PC对软件开发具有丰富的经验，了解软件开发的普遍流程，了解各个阶段所需完成的工作，这是安排好项目组成员工作的前提，在A公司对PC的整体素质要求非常高。

　　b.在项目正式开展前，PC准备项目计划文档，在项目计划中包含了项目进度时间表，但此时间表比较粗，只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排，一般是在每周项目组例会上进行本周详细工作安排。
 
　　c.PC对工作安排往往精确到天，有时甚至精确到小时，要做到这一点，需要:

　　* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解，这也需项目组成员能如实汇报工作。

　　* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么，并且能把各项工作进行合理细致地划分，因为各个分解的工作比较细致，因此能相对精确地评估出这些工作完成所需的时间。

　　* PC对项目组员的能力比较了解，安排工作时能做到有的放矢。当安排的员工对工作不熟悉时，会指定相应的组员进行协助。

　　* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干，有些员工没事干的情况，当出现这种情况或员工提前完成工作时，PC就会进行相应的协调。

　　d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制。相对而言，短时间的工作安排就比较精确而且容易控制，并且能不断根据完成的工作进行调整。当然，这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。

　　e.项目组例会一般一周一次（时间不能太长），但必要时（如组员工作已完成或其他事情），也可在中途召开项目会议进行工作安排，一般时间都比较短（十几分钟左右，一般不超过半小时，以免浪费时间），总之，当PC觉得需要时，就会召开项目会议。

　　f.当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛。
 
　　g.PC善于鼓励手下，发挥员工的潜能，PC往往会赞扬很好地完成了工作的组员。
 
　　从上面可以看出，对PC的能力（包括技术和管理能力）要求是非常高的，我国的软件企业往往只重视PC的技术能力，但事实上，一个只精通技术的人往往不能成为一个合格的领导者， 笔者认为对PC而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。

　　总结

　　以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿，民族软件工业没有多大希望。但笔者认为，在这个问题上不妨采取“拿来主义”的办法，对于好的，事实证明是成功的经验，首先是“占有”，然后才是“挑选”和“创新”。如果能把印度的管理经验真正领会并付诸实践，相信对我们的民族软件工业一定会起到积极的推动作用。

*************