IT项目如何进行质量控制?

IT工程技术网(www.systhinker.com)专家观点：

对于复杂的IT项目而言，其投资规模较大，实施周期较长，在实施过程中存在诸多风险，所以对其质量进行合理的跟踪与管理，以保证最终结果能够满足企业的要求，是一件非常重要的事。

IT项目管理同其他项目一样，都包括计划管理、质量管理、时间管理、预算管理、人员管理、风险管理等。项目质量管理是IT项目管理的一个重组成部分。

从管理流程来看，IT项目质量管理是为了保证IT项目最终能够达到预期的质量目标而进行的一系列的管理过程。IT项目的质量管理可以分解为质量规划、质量控制与质量保证等三个过程。整个IT项目质量管理过程可以分解为以下四个环节。

首先，要确立有效的质量标准体系。建立适当的质量衡量标准是进行IT项目质量管理的前提性的关键性工作。根据企业在实施IT项目方面的整体战略规划与IT项目实施计划，实施IT项目的主体企业首先要确立衡量项目质量的标准体系。衡量项目质量的标准一般包括项目涉及的范围、项目具体的实施步骤、项目周期估计、项目成本预算、项目财务预测与资金计划、项目工作详细内容安排、质量指标要求以及客户满意度等。这里需要注意的是，项目质量指标体系一定要具备完整性、科学性与合理性，项目实施各相关主体应该事先进行讨论与沟通，以保证其完整、无漏洞，又具备较强的可实施性。

其次，要在项目执行过程中采取有效措施来监控项目的实际运行。在IT项目实施过程中，根据要求收集项目实施过程中的相关信息，观察、分析项目实施进程中的实际情况以便监控。为了达到有效监控项目的目的，可以利用的监控措施与沟通渠道包括正式的监控与沟通渠道，比如，项目进度报告、项目例会、里程碑会议、各种会议纪要等非正式的监控与沟通渠道，比如，与项目小组成员或最终用户进行交谈与讨论，与企业管理层进行非正式的交流等。在这个环节上，要根据项目质量标准体系的要求，通过有效的监控措施与渠道，全面、客观地跟踪与反映项目实施的实际情况。

再次，把项目实施过程中的实际表现与项目质量衡量标准进行比较，分析出差异。在监橡枝胡控与跟踪项目实际运行状况时，往往需要解决这样一些问题，比如，“项目进展如何”，“如果发生了与项目计划偏离的情况，是如何造成的”等。通过对项目实施相关衡量指标的综合分析，为客观评价项目质量状况提供依据，帮助项目决策人员迅速、有效地对项目的实际进展情况进行监控与管理，从而可以根据需要采取有效措施来保证项目实施按着既定的轨道运行。

最后，根据具体情况采取合理的纠正措施。经过比较与分析，如果发现偏差，就要采取适当的措施进行纠正，让项目实施回到正轨。可供选用的纠正措施包括重新制定项目计划、重新安排项目步骤、重新分配项目资源、调整项目组织形式、调整项目管理方式等。一般而言，为了保证IT项目不偏离正常轨道，按着既定计梁拦划走向成功，保证纠正措施的合理性与有效性，需要IT项目的实施主体事先了解一些IT项目质量管理基础知识与相关案例，确保纠偏措施的有效性。

从IT项目质量管理的承担主体来看，既可以由IT项目实施主体来承担，也可以选择外包。IT项目实施双方可以成为项目质量管理的主体，分别或者共同对项目实施质量进行管理。此外，还可以根据需要与企业资金实力情况，决定是否选用专业的第三方项目监理商协助对项目实施质量进行管理。

无论是否采取外包协助的方式进行IT项目的质量管理，实施IT项目的企业都应该作为主体首先提出IT项目的整体规搭闷划，为IT项目质量规划确立明确的方向，清楚自己究竟想要通过IT项目的实施得到什么。作为IT项目实施的服务提供商，对项目质量承担根本责任。因而，需要为IT项目的质量管理制定更为明确的计划，协助客户实现IT项目规划，达到预期目标。

另外，还要注意做好项目质量管理的组织工作。由于整个IT项目实施过程往往可能涉及到两方、三方甚至更多相关方的参与者，为了做好项目质量管理，达到预期的质量目标，在整个项目的组织架构中，还要明确建立对项目质量管理负责的团队及其相关的工作流程，从组织方面为项目质量管理做好准备。

IT项目开发人员普遍认为，要高质量并按时完成项目是难以实现的，项目经理们并非不想要高质量的项目成果，他们只是想在质量的基础之上，能够按时完工和低于或等于预算的情况下，实现这个项目。有些项目管理技巧虽然确实可以成功地在降低成本和开发时间的同时不会对质量造成影响，然而，必需注意的是，过度地利用这些技巧就有造成灾难性后果的潜在可能。

1、时间盒(Time boxing)

在破坏项目质量的事件列表上，时间盒的应用排在第一位，当您告诉某人在任务必须移交之前，他拥有多长时间来完成这项工作，我说“移交”而不是“完成”，因为在极端情况下，这经常意味着代码并不完善，仅仅是抓紧时间去完成这项工作。

在大多数情况下，时间盒是有效的，因为它可以做到四件事：

1. 它迫使开发者能够富有创造性地在他们的预算之内发现解决方案。

2. 它排除了经常添加在软件中不必要的虚饰，而这些虚饰往往并不能增加软件的价值。

3. 它防止开发者过度测试。

4. 目的只是要得到这件产品，在完整的质量评价(QA)阶段将会有详细的测试，希望在此阶段中能够发现代码中存在的问题。

当存在未知问题，或技术没有经受检验，或没有正确的方法来检验结果的时候，时间盒就无能为力了当时间盒很小，而且在分配的时间之内并没有可能的.办法来实现目标时，这种方法也是无效的。换句话说，时间盒可以很好地解决一些问题，比如充分理解、谨慎评估和执行类的任务然而，也确实存在时间盒方法不能很好解决的问题，比如研究和发展，还有解决问题等等。

如果时间盒是正确使用的，那么不应当导致测试到很糟糕的代码，这些糟糕的代码可能会导致数百个小时的诊断和返工。时间盒应当适度使用来确保最低的成本、最快和最高质量的软件。

2、误期

所有人都要有奋斗的目标，里程碑是一种受到尊敬的方法，它用来激发人们向同一个目标前进，这种动力可以在很短的团虚时间内得到重大成果。然而，每个人都必须承认里程碑所界定的时间并不是每次都能实现，这时就必须要做出新的决定。

项目经理们必须要在团队中树立里程碑的目标，以此来激励他们前进，但是，当里程碑确立的日期并不现实，而且队员们一再出错，那就应该重新评估这个计划了液拿。如果因为某种特殊情况可以使这个日期不再重要，那么当这个重要日期真正来临的时候，整个团队就只有很小的动力来实现这个里程碑日期。当整个团队连续错过了10个日期，那么第11个日期还重要么?这就像喊着“狼来了”的孩子一样。

如果在设定的时间线之后并没有任何处罚，那么当错过这个时间的时候闹或搭就应该强制执行或者移动整个时间线。

长远来看，不断创造持续的压力和令人迷惑的环境并不能创造出好的软件，开发人员需要能够专心工作的环境。完成项目的日期和关于里程碑日期是否真实的混乱，经常会导致开发人员在开发过程中跳过关键步骤或者造成难以发现的问题。

3、忽视相关性

在软件开发中，我们有很多技巧可以用来延迟相关性，我们可以停用一些函数、移动相连的基本架构，或者绕开众多的错误处理，在正确使用的情况下，所有这些技巧都可以帮助推进一个项目，然而，当为了完成项目，而这些技巧的成本因素又没有被考虑到整个计划当中时，就埋下了烦恼的种子。

很多时候，在项目中排列软件开发的顺序是非常具有挑战的事情，相关性并不容易被发现，因此也就不可避免地有很多相关性因素没有被安排到计划当中。为这些不可预见的相关性安排日程表可以让人变得疯狂，因此，压制相关性的方法是经常使用的，但是，如果过度使用了这些技巧，这些费用可能经常会占据项目总成本中很重要的一部分，而且直到项目的最后才会被发现。

所以要确信您现在所做的对于管理相关性是必需的，不会添加过多的成本，而且是整个软件开发项目中必不可少的一部分。当项目经理不能在成本与降低相关性的便利中取得平衡，那么他们草率地组装的代码将会展示出质量问题。

4、假装没有错误

在项目管理中，忽视并不是一种幸福。为了成功地完成项目，除了不可阻挡的政治压力，向公司其他的员工介绍项目的风险也是必需的。几乎每个软件开发项目都有延期或超出预算或同时出现这两种情况的风险。

问题在于，当最终某一时间，这些风险真正变为现实的时候将会引起恐慌，每个人都在混乱中将项目其余的部分组装在一起，整个项目的质量将因为最终轻率的装配而遭受损失。

当然，当整个项目还没有落后于计划之前，这一问题还不会充分暴露出来，然而，大多数项目都有办法只让项目的某些部分落后一点点，而几乎每个项目都有过于仓促的风险，这是因为管理层在很长一段时间之内都在项目没有任何问题之后得知项目的真实状态。

即使在最完美的条件下，管理一个软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。不过，只依靠某一两条“妙计”，是无法顺利完成项目的。

1.定义项目成功的标准

在项目的开始，要保证各方对于判断项目是否成功有统一的认识。通常，跟紧预定的进度是明显的成功要素，但是肯定还有其他的因素存在，比如，增加市场占有率、获得指定的销售量或销售额、取得特定用户满意程度、淘汰一个高维护需求的遗留系统等。

2.把握各种要求之间的平衡

每个项目都需要平衡它的功能、人员、预算、进度和质量目标。我们把以上五个项目方面中的每一个方面，综合成一个约束条件，你必须在这个约束中进行 *** 作你也可以定义成与项目成功对应的驱动力，或者定义成通向成功的自由程度。可以在一个规定的范围内调整。

3.定义产品发布标准

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以将发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可 *** 作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与客户所指的“质量”一致。

4.沟通

尽告空管可能无意中了不可能的事件，但不要做一个明知不能保证的。坦诚地和客户和管理人员沟通那些实际成果。任何以前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有真正的作用。

5.写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划，困难的部分是做这个计划——思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。

6.把任务分解成“英寸大小的小圆石”

“英寸大小的小圆石”是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确地估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。

7.为大任务制定计划工作表

如果你的组经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定信友液和评估与他必须处理的大任务相关的工作量。

8.计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用做任何的修改，很好，你已经走在了计划的前面。

9.为“过程改进”安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投一些时间在“过程改进”上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

10.管理项目的风险

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。

11.根据工作计划而不是日历来估计

人们通常以日历时间做估计，但是我倾向于估计与任务相关联的工作计划(以“人时”为单位)的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求、会议，和所有其他会让耗费时间的地方。

12.不要为人员安排超过工作时间80%的任务量

跟踪你的组员每周实际花费在项目指定工作上的平均小滑物时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。一个员工一周理论上工作40小时，但不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。

13.将培训时间放到计划中

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。

14.记录你的估算和你是如何达到估算的

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

15.记录估算并且使用估算工具

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即将任务量、小组劳动力和进度安排组合起来一看，根本不可能成功。

16.遵守学习曲线

如果你在项目中第一次尝试新的过程、工具或技术，你必须承受短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。

17.考虑意外缓冲

事情不会像你项目计划的一样准确地进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。向他们指明一些以前项目不愉快的意外，来说明你的深谋远虑。

18.记录实际情况与估算情况

如果你不记录花费在每项任务上的实际工作时间，并和你的估算做比较，你将永远不能提高你的估算能力，你的估算将永远是猜测。

19.只有当任务100%完成时，才认为该任务完成

使用英寸大小的小圆石的一个好处是：你可以区分每个小任务要么完成了，要么没有完成。这比估计一个大任务在某个时候完成了多少百分比要实在得多。使用明确的标准来判断一个步骤是否真正的完成了。

20.公开、公正地跟踪项目状态

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正 *** 作，并且在条件允许时进行表扬。

---