项目管理 | 需求变更、可塑性、空间

需求变更管理：

需求变更：

需求变更之所以会产生，可能是用户不能清晰描述需求或对需求也不是特别明确，也可能是开发人员对需求理解与用户不一致，或者是用户需求确实有更改，或者是遇到其他外部环境的影响（如国家政策）。

需求的变更总会对项目产生一定的影响，比如项目范围、项目进度、项目质量、项目成本、开发人员的心里、用户满意度、代码与文档的吻合度等等。所以对需求的变更一定要有一定的管理策略。

变更管理：

变更管理应该有一定的规范，主要应该包含以下几个步骤：

第一步，应该识别变更，只有识别那些是变更才能对其做出合适的处理。

第二步，应该对变更进行详细的分析，分析变更的合理性和紧迫程度，以及对项目产生的影响，比如是否会影响项目进度，是否会加大项目投入等等。

第三步，提出正式的书面变更申请。

第四步，审批，来确定变更是否通过。

第五步，如果审批通过，那么应当详细记录变更。

需求可追溯性：

项目变更的可追溯性也非常重要，可以监控变更执行情况、防止与用户之间的纠纷、问题的处理分析等等。要做到可追溯性，那么项目变更的记录就需要非常详细，应当记录变更缘由，变更日期，变更前后的需求内容等，这样才能追溯到每一次的需求变更，让项目更可控。但是并不是需求追溯的粒度越细越好，否则的话，一方面会使需求追溯耗费的时间成本巨大，另一方面也会让需求追溯数据量变大而难以维护。

除此之外，项目需求文档的格式以及力度也对项目变更的管理和记录有一定影响，虽然可追溯性不是决定需求文档编制的主要因素，但是结构好的需求文档更容易只是需求变更的可追溯性。

需求空间：

敏捷过程中，仅用Product Backlog，不足以满足需求的管理。通常，一个项目的研发过程，通过3个空间来进行表达：需求空间、研发空间和QA测试空间。3个空间相互间应当是完全整合的，使得整个团队的不同职能工作能够相互协作。

需求空间用来做什么？

用户需求，在需求空间中被录入登记。

敏捷提倡客户价值导向，应当从客户价值角度描述，就是描述客户如何使用，而不是描述技术层面如何实现。

我们喜欢Story的用户需求表达方式，但这不代表用户需求的管理就是杂乱、随意和无序的。产品负责人需要借助需求工作流、需求分析、和需求可追溯性的管理，进行产品需求的提炼、条目化、优先级排序等。通过需求空间，对用户需求形成细化和量化.

借助于需求空间的系统化管理，项目负责人能更好的对需求相关联的产品功能、用户需求、开发任务、测试用例、产品缺陷等进行全程跟踪，实现需求可追溯性管理。

有了需求空间后，我们仍然需要Product Backlog，并且Product Backlog仍将继续扮演重要的角色。首先我们明确Product Backlog存放的是给开发团队用的需求，更多服务于开发团队。

如何管理Product Backlog？

只有当需求决定要开发的时候，才需要有分配；有了分配后，才需要放到Backlog中。有了这样的改进，能更好的控制、管理Product Backlog列表。需求一旦分配到开发团队后，也就从Backlog中移除了。设计完毕的，可供分派到开发团队的待处理需求，又从需求空间进入到 Product Backlog中。这样的改进，更能让Product Backlog实现了Scrum最早的思想；帮助项目经理从茫茫海洋中快速定位急待开发的任务。

一个需求包含的开发工作较大，Sprint 1 开始的时候，需求从Product Backlog分配出去。但是在Sprint 2中，同一个需求需要继续迭代开发，但该需求已经不存在于Product Backlog中了，该怎么办？

Product backlog和需求空间是相互整合的。只不过需求（Epic/Spec）并不直接从需求空间被分配到 Product Backlog或Sprint中。当产品负责人决定要实现的时候，需求以Story的形式分配到Product Backlog中。Story是需求的一次实现分配。

Product Backlog中不要直接存放用户需求，否则会使得Backlog中的任务队列越来越多，反倒影响了对于任务优先级的排列。 Backlog中的内容应该尽可能的少，因此避免直接把需求放到Backlog中。而是采用把Story和Task放到Backlog中更好。Story一旦被分配，也就从Product Backlog中移除了。一个需求，如果工作量较大，需要通过多次迭代开发，或多个团队共同协作来完成的话，那么就可以根据开发情况，生成多个Story来进行分配。您也可以把Story理解为一个指向需求的指针；通过Story，开发团队能直接查看到具体Epic/SPEC的描述信息，获得上下游需求。分配到开发团队的Story，可包含一组已分类的开发任务。所有这些关联派生的Story以及拆分的任务，在需求空间上，又全都能够在Epic/SPEC条目上进行全程跟踪和追溯管理；从而让项目负责人和管理组从需求层面上，牢牢掌控、规划项目的进度和质量。

通过上面一系列的讨论，我们就会发现单纯的Product Backlog 不足以实现需求管理。通过引入需求空间，重新定位Product Backlog的作用，以及Story概念的定义等系统化地需求管理，将有助于团队决定产品功能取舍的“智慧”有效地发挥作用，且能直接从软件产品结果中进行追踪，也提高了可执行产品的交付正确性。高效、灵活地保证了可执行产品的交付，也就能让用户更早提出修改意见，从而使得项目整体保持良好的进展健康度。管理层也无需担忧由于团队人员变动和流失，而让企业找不回当初创造产品功能时所经历过的团队讨论与决定过程。