本文主要讨论的是软件项目管理中规划阶段的需求文件的质量管理。
产品/项目管理中最难管理的不是启动、规划、执行、监控和收尾过程组的进度、成本、质量、人员、沟通、风险、采购,而是范围/需求管理。需求包括:业务需求、干系人需求、解决方案需求(功能性需求、非功能性需求)、过度需求、项目需求、质量需求。需求文件做为需求最终的产出物和交付成果,其中最难以控制的是需求文件做为一个可交付成果所具有的质量属性。虽然项目管理中质量管理贯穿了项目始终,目前已经有很多方法和工具来管理和控制质量,但不可否认需求的质量问题一直是困扰着每一位项目经理的难题及每一个项目的最大的潜在风险问题。
按照项目管理方法论和质量管理理论,产品/项目不确定因素、风险、问题能够在项目初期解决对项目造成的影响越小,那么对于项目初期而言就只有从最初的“范围管理—需求”开始进行控制。确保输出需求的范围和质量满足大多数主要干系人的预期和要求。避免因需求范围的各种不稳定因素导致执行、监控和收尾过程组中进行频繁的范围和需求变更。
因此解决规划过程中需求的质量问题成为产品/项目是否成功的基础因素或条件。
在产品/项目管理实际活动中,我们会遇到许多因范围边界模糊不明、需求描述不清等需求文件因缺乏质量导致的工期延期或产品/项目失败的问题。目前大多数项目经理在产品/项目执行过程中都会遇到不断的需求变更和新增需求的事情,任何一位项目经理在处理这类事情的时候都会非常棘手。我认为造成这类问题的原因在于规划阶段输出的需求文件没有满足用户/客户要求。以下几点为需求在规划阶段最容易出现的问题(包括但不限于):
(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)
PDCA戴明环 图1
在需求规划和准备的实际活动中业务经理/产品经理/系统工程师或其他干系人最容易出现以下问题(包括但不限于):
(1)未准确的掌握用户/客户真正的需求/诉求/要求。
(2)组织过程资产(The organizational process assets)不全,导致资源信息掌握出现偏差。
(3)未对组织过程资产进行了解分析,凭借经验进行臆断导致规划偏离用户/客户的最终目标。
(4)未对当前事业环境因素(enterprise environmental factors)进行充分了解和分析,导致规划偏离用户/客户的最终目标。
(5)未进行风险(消极的风险)因素分析,或未充分评估风险,导致规划结果难以落地。
(6)未进行充分细致的调研,忽视个性化对产品/项目的影响。
(7)未收集所有相关方意见,凭借初步判断决定方向。
(8)规划较为激进,要求使用不熟悉的技术,要求业务适应激进式发展。
(9)能力不足以胜任规划工作。
因此我觉得在此活动中必须要明确:做什么、为什么做、怎么做、什么时候完成,这就是需求文件质量管理计划。(见图2)
需求文件质量管理计划 图2
需求收集记录表 表1
需求分解和活动分解工具 表2
完成计划的制定、需求的收集和需求分析后,接下来我们将开始进入需求文件的编写活动。最终交付的需求文件是被所有主要干系人接受和认可的。因此我们需要在需求文件编写过程中引入需求文件编写工具,确保需求文件做为产出的可交付成果具备完整性、可测试性、可检查等质量特性。
功能/交易清单是一种最直接有效的需求文件编写工具。但该工具的使用必须是在完成需求收集和精准的需求分析(需求分解和活动分解)后才可以使用。因为它是比活动分解更为细化的功能/交易分解分析。对于大型项目、重要信息系统建设或重大优化需求时编写的需求文件起到全面质量管理和风险预防的作用,更能保证需求文件的完整性和准确性。但是对于中小型项目或者功能单一化的系统建设或者很简单的优化需求作用和效果并不是太过明显,且太过耗费时间和资源。对于产品/项目管理者而言,可以根据产品/项目需求的不同特性(复杂程度高、风险程度高、关联系统过多等)选择性使用。(见表3)
功能/交易清单 表3
需求文件编写完成后,需要联系所有的相关方干系人(Stakeholder)参与需求的评审。按照PMI(Project Management Institute)或其他的项目管理专业机构对于可交付成果(deliverables)验收工具:检查(Inspection是检查可交付的成果或产品,check是包括核对行为。)和群体决策技术(Group Decision Making Techniques)来对交付成果进行验收和确认,这个过程也叫确认需求或确认范围(Validate Scope)。该过程是对需求文件的质量进行检查的重要活动。虽然质量管理的工具繁多,但经过整理后我认为最为有效的工具有两个最为直接和有效McCall质量模型和QA检查表工具。
我认为确认需求或确认范围应该是可进行检查的,简而言之就是对需求文件的目标检查,这应该是在Plan(计划)过程中就被明确定义在QA检查表检查项中。QA检查表在编写时除对工作活动过程检查项外,还应该包括具体的需求范围检查项。明确如何检查需求文件中的需求范围是否完整、描述是否清晰易懂、是否具有可追溯性、是否具有非功能性需求、是否具有质量需求、是否符合监管或法律法规要求、是否具有可测试性、是否具有易执行性等。
McCall质量模型或QA检查表的主要作用是在审核或评审需求文件时再次检查和验证需求文件质量管理计划是否应被执行,分析过程输出的需求是否具备了可追溯性、前瞻性、低风险性、易实现性、清晰性、简化性等,是否达到了用户/客户的要求。(见表4)
McCall质量模型和QA检查表 表4
对于Check活动交付成果的评审结果,进行重新的改进和优化,在这个过程中又可以再次使用PDCA循环过程的方法重新对待修改优化的部分进行再次确认。直到交付成果—需求文件被最终确认。
综上所述,PMI(Project Management Institute)或其他的项目管理专业机构在描述项目管理时,将“时间、成本、范围”定义为项目管理的三重制约因素,其中最重要的就是范围—需求文件,需求文件的优劣直接对时间和成本施加影响。优质的高质量的需求文件是正向的影响,可以缩短时间进度和降低成本。劣质的低质量的需求文件是负向影响,会造成时间进度延迟和增加成本。优质的高质量的需求文件也会防止需求蔓延和镀金。
因此在规划阶段对需求文件进行严格的质量控制,目的在于将问题集中在规划阶段进行解决,对于项目管理问题越早解决投入的成本越低,执行越高效。将规划阶段输出需求文件的过程当做项目进行管理,那么对于项目成功与否的关键就是是否满足用户/客户的要求。
通过在项目管理规划阶段对需求文件进行质量管理,能够最大程度的避免需求提出质量不高、关系人沟通阶段出现的理解偏差、需求遗漏、未能对新技术/新架构/新市场变化做出快速反应等问题。能够最大程度支持产品/项目的落地实施和高质量交付,从而最大程度的达到用户/客户的要求。
对于不同的产品/项目,或不同的组织过程资产和事业环境因素,可以根据具体情况选择不同的质量管理方法,增加或提高产品/项目成功的概率。也能够直接作用于和影响于执行、监控和收尾过程组,使其工作更为高效。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论0 条评论