某工程项目需求管理实践应用分析

曾令东 董鹏 王飞辉

(1.海军工程大学管理工程与装备经济系，湖北 武汉 430033；2.91515部队，海南 三亚 572016)

0 引言

项目需求包括功能、非功能、质量等方面的指标和要求。正确的项目需求是为了满足利益相关方期望而收集的，是检验项目成果的基本依据。工程项目需求管理是一项系统的、复杂的工作，必须采用科学的管理方法。

1 需求管理中存在的问题

据不完全统计，项目缺陷与返工事件中有近50%来源于需求问题。可见，实施有效的需求管理活动是工程项目获得成功的关键。

1.1 需求信息收集不全面

如果项目团队没有花费足够的时间和精力收集项目需求，而是直接进入项目需求起草阶段，很容易导致需求缺失、需求信息不完整和范围变更。项目管理人员往往容易错误地认为只有部分利益相关方有需求信息，仅邀请部分利益相关方参与需求管理活动。技术人员也经常犯需求“镀金”和“过滤”两类错误：“镀金”是指抛开实际需求，片面追求先进性；“过滤”是指根据主观偏好开展需求筛选。

某工程项目需求管理面临的问题主要包括：需求和理解不一致；用户不能直接写出所有需求；用户在项目验收前仍然存在许多需求；谦让和迁就用户太多；沟通交流渠道不顺畅。

1.2 期望与需求混淆

在某工程项目需求管理实践中，很多用户可能表述的是“期望”，而不是“需求”。用户基于阅历与认知，会习惯性地把自己的需求套到可实现的方法或技术中，或者用自己见过的东西描述从未见过的东西。用户提出建议时，可能会带有自己对问题的理解、定义与处理意见。项目需求管理人员需要对用户期望进行筛选，过滤掉无效期望，总结提炼出项目真实、准确的需求。

1.3 “投射效应”的不利影响

用户往往只提供期待解决的需求，而忽视其他重要和隐含的需求，并认为项目管理者应该知道其基本需求。在某工程项目中，大多管理人员具有较好的技术背景，而技术视角可能会影响需求管理实践的开展。即管理人员的技术信心越大，越容易把自己的理念灌输给别人而造成“投射效应”。“投射效应”加大了某工程项目需求获取的难度，增添了项目需求实践障碍。因此，项目管理者应详细调查项目的使用环境，深入了解业务过程，收集用户的真实需求。

2 需求收集

全面、有效地收集需求是完成工程项目的第一步，应连续不断地接受新需求直到真正开始项目活动。

2.1 正确使用需求收集方法

某工程项目团队在项目全生命周期都面临需求收集和更改问题，必须认识到收集所有利益相关方的需求是不现实的，应重点关注与确认主要利益相关方需求。需求收集人员必须“读懂”利益相关方，并使用合适的方法完成需求收集工作。为了提高需求的被理解力和减少歧义，需求管理人员可使用示意图、函数模型、表格、用例、用户故事、原型示例等方法，如可使用图表和算法描述过程和数据流需求。某工程需求管理实践中可使用的收集方法很多，具体分析见表1。需求管理人员应根据需求管理实践特点和不同阶段要求，正确地选用一种或多种需求收集方法。

表1 需求收集方法示例分析

2.2 合理使用启发式计划

启发式计划也是需求收集工具之一。在某工程项目实践中，需求管理人员可根据需要对启发式计划进行简化或概括，根据项目规模对启发式计划的主题进行适当的增加或减少。启发式计划不需太庞杂，可以采用简单的文字处理或电子表格软件，以文档的名称、版本号和日期开头，列出主要需求发起人和关键贡献者，详细描述项目将会遇到的问题和机会，确定收集需求的高层级目标和关键策略。启发式计划模板示例见表2。

表2 启发式计划简化模板示例

2.3 准确辨别期望和需求

期望和需求概念和意义并不同：期望是用户确实想得到的东西，比需求的范围大；需求是用户期望和项目目标结合的实际表现形式，可以明确表述，体现在合同里。期望与需求的差距一般是交流沟通不顺畅、不全面所致。利益相关方通常是通过描述性的自然语言描述需求，由于汉语词汇的多义性，需求理解往往存在一定困难。某工程项目需求分析模板示例见表3。

表3 某工程项目需求分析模板示例

2.4 防止需求信息的虚假共识

利益相关方即便有不同的想法或需求，通常也不会直接否定别人的建议，容易导致真实需求的收集不全面。作为项目经理，面对需求必须谨防表面上的一致，必要时可以到用户项目成果使用现场进行观察和对工作、业务进行实地跟踪调查。某工程项目需求调查模板示例见表4。

表4 某工程项目需求调查模板示例

3 有效设置需求文档

3.1 拟制需求说明书

拟制某工程项目需求说明书的目的是对如何记录项目需求在团队内部达成一致意见。如果使用一定结构的框架和规则，具体说明和表述需求更简单。需求说明书可包含不实施某个需求将产生的影响。编写某工程项目需求说明书需要的主要关键词见表5。

表5 某工程项目功能需求主要关键词

某工程项目需求描述中最难的是非功能或质量需求，这些需求能够确保解决方案如期进行。非功能需求中有部分需求关系到解决方案的可靠性，以及随着解决方案的演化、成长和实施，需求的可扩展性。某工程项目的非功能需求主要关键词及示例见表6。

(续)

表6 某工程项目非功能需求关键词及示例

3.2 建立需求文档

需求文档是项目团队的指南针，可清晰描述一个解决方案的目的、特点、功能、使用以及可能会遇到的风险。需求文档通常包括商业需求文档、功能说明书、系统说明书等形式。某工程项目需求产生的时候，应将需求文档化，需求文档模板见表7。利益相关方通过需求文档可了解项目发展程度以及掌握进入项目的最佳时机。需求文档有助于减少歧义，为团队项目实践和成果测试提供参考和标准，这是需求文档最重要的用处。某工程项目需求文档制定注意事项见表8。

表7 某工程项目需求文档模板示例

表8 某工程需求文档拟制要求和注意事项

3.3 设置需求基线

据统计，只有很少的原始需求文档体现了过半数的期望和要求，因此需要变更。如果不对某工程需求变更进行科学的管理，将导致失误或产生不必要的结果以及返工等现象。因此，应建立需求基线反映项目需求的一致意见。需求基线一旦获得所有利益相关方批准，将成为需求管理过程中的核心内容。

4 及时审查和验证需求

某工程项目团队需要重点从三个方面对需求进行审查，确保每项需求只有一种解释，具体见表9。可使用需求审查清单清除需求提出者常犯的错误，具体模板示例见表10。

表9 某工程需求审查重点分析

表10 需求审查清单模板示例

在需求确认上，某工程项目经理应用各种可能的办法促使利益相关方把需求考虑清楚。可采用RUMBA方法验证用户的需求和期望；简单地记下每个需要和期望，按照表11中的要素进行验证；如果所有RUMBA问题的答案都是“是”，那么需求基本可认定是有效的；任何“否”的回答都需要进一步讨论和协商，直到得到“是”的答案；如果验证答案不是“是”，那么用户的需要或合理期望就不是有效需求。

表11 某个工程用户需求和期望验证要素分析

5 结语

本文针对某工程项目需求管理的特点，分析了需求管理实践问题、困难和注意事项，有助于提高需求管理活动的有效性、针对性和全面性。使用正确有效的需求收集方法和工具，可确定某工程需求重点。将某工程项目需求文档化，便于需求使用对象查找他们想要的信息，并明确需要做什么。建立某工程项目需求基线，可使有关人员知道哪些需求通过审核。分析某工程需求重点、需求审查清单和RUMBA方法的使用过程及要求，可确保需求清晰、简洁、可度量。

(续)