银行IT建设项目管理：如何在规划过程中对需求进行质量控制？

原题：银行IT建设项目管理应该如何解决规划过程中需求的质量控制

前言

本文主要讨论的是软件项目管理中规划阶段的需求文件的质量管理。

产品/项目管理中最难管理的不是启动、规划、执行、监控和收尾过程组的进度、成本、质量、人员、沟通、风险、采购，而是范围/需求管理。需求包括：业务需求、干系人需求、解决方案需求（功能性需求、非功能性需求）、过度需求、项目需求、质量需求。需求文件做为需求最终的产出物和交付成果，其中最难以控制的是需求文件做为一个可交付成果所具有的质量属性。虽然项目管理中质量管理贯穿了项目始终，目前已经有很多方法和工具来管理和控制质量，但不可否认需求的质量问题一直是困扰着每一位项目经理的难题及每一个项目的最大的潜在风险问题。

按照项目管理方法论和质量管理理论，产品/项目不确定因素、风险、问题能够在项目初期解决对项目造成的影响越小，那么对于项目初期而言就只有从最初的“范围管理—需求”开始进行控制。确保输出需求的范围和质量满足大多数主要干系人的预期和要求。避免因需求范围的各种不稳定因素导致执行、监控和收尾过程组中进行频繁的范围和需求变更。

因此解决规划过程中需求的质量问题成为产品/项目是否成功的基础因素或条件。

现状分析

在产品/项目管理实际活动中，我们会遇到许多因范围边界模糊不明、需求描述不清等需求文件因缺乏质量导致的工期延期或产品/项目失败的问题。目前大多数项目经理在产品/项目执行过程中都会遇到不断的需求变更和新增需求的事情，任何一位项目经理在处理这类事情的时候都会非常棘手。我认为造成这类问题的原因在于规划阶段输出的需求文件没有满足用户/客户要求。以下几点为需求在规划阶段最容易出现的问题（包括但不限于）：

（1）产品/项目在规划阶段未全部考虑到各个相关系统的实现问题，只是简单的完成了需求的描述，未明确边界划分。

（2）产品/项目在规划阶段有明确的业务性需求和边界划分，但是未考虑经济价值、可落地性行分析和新技术应用分析，且对关联系统定位出现偏差，导致项目启动后需要重新界定需求范围。

（3）产品/项目在规划阶段时未充分对功能性/非功能性/新技术/运维等需求进行调研，导致立项时流程出现严重错误和范围严重偏离预期目标。

上述问题的发生将会导致产品/项目进度延期、成本持续增加，也会直接影响到交付成果的质量。

按照PMI（Project Management Institute）或其他的项目管理专业机构对项目管理的描述和理论，我觉得规划范围管理（Plan Scope Management）中产出需求文件的过程或活动也可以做为项目进行管理，最终的验收的可交付成果（Accepted Deliverables）—需求文件（Requirements documentation）就必须具备用户/客户满意的条件，因此需求的规划过程也存在质量管理，需求文件也必须具备质量要求。

项目管理和质量管理知识体系中都提到“三重制约”（范围、时间、成本）。其中需求文件决定了整个产品/项目的输入“范围”，直接指导着“时间、成本”的预估和执行，也指导着核心“质量”的管理。为最终的产品/项目的成功起到基础作用。

解决思路

PDCA（又名戴明环，由美国质量管理专家休哈特博士首先提出，由戴明采纳和推广）是解决质量问题的理论和方法，是一个反复循环的过程。我认为需求的收集和细化也是一个循序渐进和渐进明细的过程，与PDCA的理论相同。因此我的观点为：解决需求文件质量问题可以使用PDCA的方法。

PDCA分为四个活动，P：Plan（计划）；D：Do（执行）；C：Check（检查）；A：Action（改进/行动）。（见下图1）

图1 PDCA戴明环 

PDCA也存在局限性，因此在需求管理活动中完全使用PDCA的方法也并不完全适用，必须结合需求管理活动特点，在需求管理活动的每一个具有交付成果的节点上引入PDCA方法，从而达到对需求的质量管理目的。解决软件项目管理需求规划阶段中因各种问题导致的需求文件质量/失效问题。

PDCA四活动分别对应需求管理活动中的需求规划和收集；需求文件编写；交付成果评审；持续改进（渐进明细的过程）。

PDCA（戴明环）实践应用

1.Plan（计划）—需求规划和收集

在需求规划和准备的实际活动中业务经理/产品经理/系统工程师或其他干系人最容易出现以下问题（包括但不限于）：

（1）未准确的掌握用户/客户真正的需求/诉求/要求。

（2）组织过程资产（The organizational process assets）不全，导致资源信息掌握出现偏差。

（3）未对组织过程资产进行了解分析，凭借经验进行臆断导致规划偏离用户/客户的最终目标。

（4）未对当前事业环境因素（enterprise environmental factors）进行充分了解和分析，导致规划偏离用户/客户的最终目标。

（5）未进行风险（消极的风险）因素分析，或未充分评估风险，导致规划结果难以落地。

（6）未进行充分细致的调研，忽视个性化对产品/项目的影响。

（7）未收集所有相关方意见，凭借初步判断决定方向。

（8）规划较为激进，要求使用不熟悉的技术，要求业务适应激进式发展。

（9）能力不足以胜任规划工作。

因此我觉得在此活动中必须要明确：做什么、为什么做、怎么做、什么时候完成，这就是需求文件质量管理计划。（见图2）

图2

需求文件质量管理计划

我觉得此活动中最重要的就是制定需求文件质量标准。最简单的需求文件质量标准管理工具是PMI（Project Management Institute）在“规划范围管理”（Plan Scope Management）中提出的范围管理计划（Scope Management Plan）和需求管理计划（Requirements Management Plan）。较为复杂的工具是质量管理体系中用于管理产品/项目质量的质量管理工具。如：QA检查表（checksheet）、McCall质量模型（McCall's Quality Model）。主要作用是制定质量管理计划，以检查、核对、核实的方式判断规划出的需求是否能够满足用户/客户要求。

我认为需求规划和准备活动应该制定需求文件质量管理计划，应包括以下内容：

（1）范围管理计划、需求管理计划；

（2）组织过程资产、事业环境因素、干系人登记册（Stakeholder Register）；

（3）需求收集、分析、评审、持续改进、质量控制所需工具；

（4）完成计划时间。

可以根据不同的产品/项目特征选择定义适合的需求文件质量管理工具和计划。

计划制定完成后我们就可以开始进行需求收集工作了。通过组织过程资产和事业环境因素寻找可能存在的利益干系人，通过专家判断或组织过程资产或工作经验尽可能发现可能相关联的关联系统，并将发现的所有干系人、可能相关联的关联系统、有用的组织过程资产和有用的事业环境因素进行登记记录。我们可以使用需求收集记录表来实现。（见表1）

表1 需求收集记录表 

注：为了更好的让需求具有可追溯性、前瞻性，在充分完成干系人调研后需要将所有干系人的要求转化为可视化的需求并记录。

记录是为了更好的分析，是进行分析前的准备工具，因此我认为“分析”是此活动最重要工作，直接影响最终的交付成果—需求文件。对收集后的需求进行分析整理，我们需要使用风险管理工具（通过对组织过程资产和事业环境因素分析得到的风险记录登记册）和质量管理工具（McCall质量模型和QA检查表），排除高风险、不明确、扩展性低、易实现程度低等需求/要求等，此过程也叫可行性分析。

“需求分解”（Requirements analysis）和“活动分解”（活动Activity，分解Breakdown。一般只有工作分解work breakdown成活动，活动再分就是动作。），我们可以将其看做是需求分析的一部分，这样做的好处是实现需求的可视化和预防分析出现遗漏和理解偏差。这是对需求分析结果的质量控制管理。（见表2）

表2 需求分解和活动分解工具 

对于如何进一步提高需求的分析质量要求，我们还可以对涉及到的关联系统进行功能或交易关联性建模。建模不需要建立数据型的模型，只需要通过各种绘图工具勾画出系统间的功能或交易关联性，例如使用Visio。主要作用是在分析过程中避免关联系统间交互性需求遗漏的问题。

虽然我们完成了上诉工作，但并不表示我们在此阶段的工作已经完成。我们还需要完成QA检查表的编写，为需求文件的交付成果评审提供检查依据。QA检查表工具为我们提供了更为直接的可视化的需求确认或范围检查工具。

2.DO（执行）—需求文件编写

完成计划的制定、需求的收集和需求分析后，接下来我们将开始进入需求文件的编写活动。最终交付的需求文件是被所有主要干系人接受和认可的。因此我们需要在需求文件编写过程中引入需求文件编写工具，确保需求文件做为产出的可交付成果具备完整性、可测试性、可检查等质量特性。

功能/交易清单是一种最直接有效的需求文件编写工具。但该工具的使用必须是在完成需求收集和精准的需求分析（需求分解和活动分解）后才可以使用。因为它是比活动分解更为细化的功能/交易分解分析。对于大型项目、重要信息系统建设或重大优化需求时编写的需求文件起到全面质量管理和风险预防的作用，更能保证需求文件的完整性和准确性。但是对于中小型项目或者功能单一化的系统建设或者很简单的优化需求作用和效果并不是太过明显，且太过耗费时间和资源。对于产品/项目管理者而言，可以根据产品/项目需求的不同特性（复杂程度高、风险程度高、关联系统过多等）选择性使用。（见表3）

表3 功能/交易清单

注：主要作用为全面细化需求分析的功能/交易对潜在的关联系统或关联交易影响，以及分析记录需求所涉及到的风险。为最终的决策提供可视化的依据。

我认为需求文件没有固定的、统一的编写结构规定，可以根据所在组织的不同要求来进行文件编写。需求文件应该包含的内容：项目背景、业务目标和意义、投产范围及用户、业务概述、业务处理流程（包含异常的处理）、业务结构（系统关联关系图和交易结构描述）、非功能性需求、新技术/架构使用标准、质量需求、外部监管要求或符合相关法律要求等。

3.Check（检查）—交付成果评审

需求文件编写完成后，需要联系所有的相关方干系人（Stakeholder）参与需求的评审。按照PMI（Project Management Institute）或其他的项目管理专业机构对于可交付成果（deliverables）验收工具：检查（Inspection是检查可交付的成果或产品，check是包括核对行为。）和群体决策技术（Group Decision Making Techniques）来对交付成果进行验收和确认，这个过程也叫确认需求或确认范围（Validate Scope）。该过程是对需求文件的质量进行检查的重要活动。虽然质量管理的工具繁多，但经过整理后我认为最为有效的工具有两个最为直接和有效McCall质量模型和QA检查表工具。

我认为确认需求或确认范围应该是可进行检查的，简而言之就是对需求文件的目标检查，这应该是在Plan（计划）过程中就被明确定义在QA检查表检查项中。QA检查表在编写时除对工作活动过程检查项外，还应该包括具体的需求范围检查项。明确如何检查需求文件中的需求范围是否完整、描述是否清晰易懂、是否具有可追溯性、是否具有非功能性需求、是否具有质量需求、是否符合监管或法律法规要求、是否具有可测试性、是否具有易执行性等。

McCall质量模型或QA检查表的主要作用是在审核或评审需求文件时再次检查和验证需求文件质量管理计划是否应被执行，分析过程输出的需求是否具备了可追溯性、前瞻性、低风险性、易实现性、清晰性、简化性等，是否达到了用户/客户的要求。（见表4）

表4 McCall质量模型和QA检查表 

在此活动中我们可以按照产品/项目实际情况选择所需要的检查评审工具，确保交付结果满足于用户/客户要求。对还存在遗漏或异议的需求进行标注，在Action（改进）活动中进行优化。

通过此活动我们能够识别出后续的提升方向，对新技术/新架构的采用程度。有必要在此活动中让所有的干系人参与，使其对产品/项目更有认同感、向心力和凝聚力（人力资源管理和干系人管理）。

4.Action（改进）—持续改进

对于Check活动交付成果的评审结果，进行重新的改进和优化，在这个过程中又可以再次使用PDCA循环过程的方法重新对待修改优化的部分进行再次确认。直到交付成果—需求文件被最终确认。

总结

综上所述，PMI（Project Management Institute）或其他的项目管理专业机构在描述项目管理时，将“时间、成本、范围”定义为项目管理的三重制约因素，其中最重要的就是范围—需求文件，需求文件的优劣直接对时间和成本施加影响。优质的高质量的需求文件是正向的影响，可以缩短时间进度和降低成本。劣质的低质量的需求文件是负向影响，会造成时间进度延迟和增加成本。优质的高质量的需求文件也会防止需求蔓延和镀金。

因此在规划阶段对需求文件进行严格的质量控制，目的在于将问题集中在规划阶段进行解决，对于项目管理问题越早解决投入的成本越低，执行越高效。将规划阶段输出需求文件的过程当做项目进行管理，那么对于项目成功与否的关键就是是否满足用户/客户的要求。

通过在项目管理规划阶段对需求文件进行质量管理，能够最大程度的避免需求提出质量不高、关系人沟通阶段出现的理解偏差、需求遗漏、未能对新技术/新架构/新市场变化做出快速反应等问题。能够最大程度支持产品/项目的落地实施和高质量交付，从而最大程度的达到用户/客户的要求。

对于不同的产品/项目，或不同的组织过程资产和事业环境因素，可以根据具体情况选择不同的质量管理方法，增加或提高产品/项目成功的概率。也能够直接作用于和影响于执行、监控和收尾过程组，使其工作更为高效。

本文作者：程琢，能够灵活运用PMI各项管理工具。热衷于项目和产品的质量管理。熟悉人行支付监管规定。擅长金融机构支付产品创新分析和应用场景分析。擅长人行系支付系统产品设计。具备较强的风险管理和控制能力。热衷于深度研究项目管理学术、理论，和支付业务创新研究。

更多相关内容，请点击阅读原文

长按二维码关注公众号