2 从客户角度审视需求（2）

2.7识别决策者

让一个代表各个关键领域（如管理、客户、商业分析、开发和市场部门）的小组来决定通常更有效。
决策小组需要指明决策领导并选择一个决策规则，该规则描述了他们如何做决定。有很多决策规则可以识别：

• 决策领导做决定，不管是否已经和其他人讨论过
• 小组投票，少数服从多数
• 小组投票，但是结果必须获得一致通过
• 小组讨论和协商达成共识。每个人都拥护这个决定并承诺支持它
• 决策领导授权一个决策人
• 小组达成一个决策，但是一些人有权否决小组决定

没有普适的决策规则。单一的决策规则通常也不普遍适合于每个场景，所以小组必须建立一套指导原则，让他们知道什么时候该投票，什么时候该达成一致，什么时候该授权代理人等。在每个项目的第一个重大决策点出现之前，需要做需求决策的人都必须事先确定好一个决策原则。

2.8对需求达成一致

涉及多角色应形成如下共识：

• 客户承认需求描述了他们的需要
• 开发人员承认理解需求并且认为它们是可实现的
• 测试人员承认需求是可验证的
• 管理层承认需求可以达成他们的业务目标

许多组织以签字的方式来代表干系人认可需求。所有的需求确认流程的参与者都清楚签字的含义及其结果。

2.9需求基线

比签字仪式更重要的是确立一条需求基线，一个特定时间点的需求快照。
需求基线是一组需求，在评审和确认后作为后续开发的基础。不论团队使用正式的签字或者其他方式对需求达成一致，潜在含义都应该如下所述：

我同意当前这组需求代表我们对项目下一阶段需求最深入的理解，并且基于目前我们对问题的理解，这个解决方案能够满足我们的需求。我同意在未来使用项目定义好的变更流程基于这个基线对需求进行修改。我清楚变更可能导致我们重新讨论项目的成本、涉及的资源以及随时间表的承诺。

一些组织与这段话类似的内容放到了签名页上，让需求审批人在签字的时候清楚签字的真正含义。
一个有意义的基线确定流程可以在以下几个方面为主要干系人带来信心：

• 客户管理层或者市场营销人员相信项目不会超出可控范围，因为客户会为范围变化的决定负责。
• 用户代表相信开发团队会和他们一起工作，交付正确的解决方案，即使他们在开发开始之前没有考虑清楚所有的需求。
• 开发部门的信心建立在开发团队有业务伙伴保证项目始终聚焦于目标上，同时业务伙伴也和开发团队一起平衡项目计划、成本、功能和质量。
• 业务分析师和项目经理有信心有效控制项目变更带来的风险，并使风险最小化。
• 质量保证和测试团队有信心开发测试脚本并且为自己在项目中的各种活动做好准备。

在决策者定义基线以后，业务分析师需要在需求变更上施加控制。团队可以在分析每个变化对项目计划和其他的关键因素的影响之后重新调整项目的范围。在达成一致后结束初始的需求开发活动，可以有效推进协作式客户-开发人员关系，使产品走上成功之路。

2.10达不成共识怎么办

让所有干系人达成一致并签字是很困难的。障碍包括后勤、忙碌的日程以及某人不愿意承诺（害怕在日后承担责任）等。如果干系人担心批准需求以后不可以再更改，就会拖延审批时间。这无疑会导致需求分析工作陷入瘫痪。尝试了解不愿签字的原因并当面提出来。
在这种场景下，最好先小心推进项目，不过要假定那些有抵触情绪的干系人没有同意。在风险列表中做记录，说明有些干系人没有在需求文档上签字（把它和遗漏或错误的需求可能带来的影响同等对待）。作为风险管理的一部分，持续跟进这些人。用一种积极的态度让他们了解，虽然他们没有批准需求，但为了保证进度，项目仍然使用这些需求作为基线。让他们知道，如果他们想改变需求，可以通过一个现有的流程。基本是在假定干系人同意需求的状态下工作，但是需要与他们保持密切的沟通。

2.11对敏捷项目的需求达成共识

敏捷项目通常没有正式的签字环节。敏捷项目使用Backlog（待办事项）中放入用户故事的形式来管理需求。产品负责人和团队一起在计划会议上对下一个迭代团队要做的用户故事达成一致。选择实现哪些用户故事只要取决于故事的优先级和团队效率（生产力）。在需求集合达成一致后，迭代中包含的用户故事将被冻结。新出现的需求变更留在未来的迭代中再考虑。
敏捷项目不会一开始就试图让干系人就项目所有需求达成一致。虽然产品愿景和其他业务需求仍然需要一开始就明确，但在敏捷项目中，功能全集是逐渐得以明确的。
通常在敏捷项目中，产品负责人为迭代选择或拒绝需求，需求包括一系列用户故事以及相应的验收条件和验收测试。最终的签字就是接收迭代所产出的经过测试的可工作的软件。
敏捷告诉我们要“拥抱变化”，但变化总是基于某个参照点而存在的，可以将签字确认作为一个参照点。