项管行知06--需求与跟踪

上次我们总结了项目执行的核心：可交付成果；本次我们总结下项目的源头：需求。

1 定义

需求是组织和客户沟通的依据，是项目启动的主要源头。在项目启动之前的准备阶段，需求管理就已经开始，这是聚焦于业务和用户的需求和问题；项目实施阶段的需求管理，主要聚焦需求的规格化、完整性、跟踪、变更等。本次主要总结项目实施阶段的需求，两者关系如下图所示：

 一些关键定义：

需求（Requirement）：为满足业务需求，某个产品、服务或成果必须达到的条件或具备的能力。
需求管理计划（Requirements Management Plan）：项目或项目集管理计划的组成部分，描述将如何分析、记录和管理需求。
需求文件（Requirements Documentation）：关于各种单一需求将如何满足项目商业需求的描述。
需求跟踪矩阵（Requirements Traceability Matrix）：把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

2 说明

在项目实施中的需求管理，要特别注意几个点：

需求类型

常规我们理解的需求，是要满足客户的产品规格需求；一个有用的产品都是不简单的，为了设计生产满足客户的产品需求，还需要做若干过程任务，对过程任务也需要管理，所以有了另一类非产品的项目需求；现代项目管理为了多维度监控和评价项目过程和产品，还会细分出质量、资源、沟通等等类型的需求。

实际项目中，需要在需求文件中书面记录各类需求，并就内容和管理方式和项目成员达成一致，保证源头清晰，师出有名。

需求跟踪

犹如幼儿园老师管理小朋友，如果没有一套点名、吃饭、午睡、运动、学习等活动的约束方式，老师很快就会筋疲力尽一锅粥，小朋友则是翻天覆地搞破坏。

从需求到客户验收的可交付成果，中间会经历若干任务：确定到本次实施范围，概要设计，详细设计，开发实现，内部测试，正式发布，用户验收等；会经历若干角色：项目经理、专业负责人、开发工程师、测试工程师、用户代表等；会与过程或结果交付件相关：需求文档、设计文档、实现任务、用户可操作功能、测试用例、测试结果、相关问题、相关变更等。如果没有约束方式，也会陷入“焦油坑”。

需求跟踪，就是把这些东西关联起来，达到监督的目的。

过程交付件

从某种程度上，需求文件和需求跟踪矩阵，就是项目的过程可交付成果。

这基于一个常识：过程执行得好、结果好的概率也会高。

3 修行

在工作、学习、生活中，“分解”、“持续跟踪和改进”、“集成抽象”都是三个非常重要的执行能力。分解让我们能从上到下思考，拆解复杂问题，分派给其他人，聚焦到关键局部；集成抽象能让我们从下到上集成，脱离局中人，鸟瞰全局，整合1+1>2；把这两个部分关联起来，形成逻辑关系，清楚前因后果，以终为始，这就是持续跟踪和改进。PMBOK中专门有监控过程组，十二个过程来说明这个内容。

日常使用时，需求规格清单及其跟踪，通常会用二维表格或其改进形式来体现。

最容易上手的就是办公工具excel，纵向各行为事项，横向各列为关联项，事项和关联项对应的方框，则可填写各种约定关系。用电子表格的一个好处是容易统计，事项超过一定数量时，分析时就要先运用集成抽象能力来分类，关注大图景；面对细节时，又要运用分解能力具体化。在实际项目中，你会看到成熟的项目经理用表格做需求规格清单、任务计划、测试准入准出check表、bug跟进表、风险跟踪表等等。

单个电子表格的一个重大缺陷，是靠人来把控数据分发和收集的及时性、完整性、正确性。这在参与人多、持续时间长、需要以数据作为分析决策的条件下，会迅速成为瓶颈。于是会引入平台工具，做到多人并行、统一发布和收集，高级的还会做流程、角色、权限自定义，突破单个表格的时空局限。在实际项目中，你有时会用到如Bugzilla、Mantis、Testlink、Redmine、RDM、禅道等等实时跟踪工具。

使用好Excel来跟踪，你会是一个成熟的工作人员，利用好实时跟踪工具，你会成为一个高效的工作者。欢迎拍砖讨论。