银行IT建设项目中对需求进行质量控制.docx

? ? ? ? ? ? ? ? 银行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）未对组织过程资产进行了解分析，凭借经验进行臆断导致规划偏离用户/客户的最终目标。