在本章中，我们将介绍需求管理面临的最大挑战以及如何克服这些挑战。
随着产品和软件变得越来越先进，项目的复杂性也随之增加，需要在开发、维护和遵守标准的同时保持其初始目标。对于许多项目来说，需求文档可能长达数百页，并且在开发过程中会更改数十次。这意味着团队有时会花费数小时来传阅、编辑和跟踪对大量需求文档的更改，希望每个人都能阅读并参与其中。有时，审查和批准所有需求所花的时间比实际需求工程活动本身所花的时间还要多。这可能会对项目 FTE 产生重大影响，并且通常无法得到适当的预算。
现代产品是多方面的、多学科的，包括硬件、软件（以及医疗器械行业的 Bioware、化学和生命科学）以及各种科学和工程方法，它们都以卓越的客户体验为名汇聚在一起。许多行业（例如医疗器械、汽车、航空航天和国防）还要求复杂产品开发商遵守严格的安全标准和法规。如果公司想要增强竞争优势，就必须有效、高效地开展工作。而这一切都始于需求管理。
而现实情况是，Word 和 Excel 不足以管理复杂的需求。
问题不在于需求文档本身。事实上，文档本身是记录需求所必需的。问题在于使用文档来管理需求。当前的静态工具（如 Word 和 Excel）不支持加速的开发过程、变化速度以及复杂的组织文档机制。在当今复杂产品的整个开发过程中，使用文档来设定期望、传达项目细节和跟踪变化已不再现实。
作为负责确保每个人都了解我们正在构建什么以及为什么构建（即需求）的人，您必须改进工作方式。您必须采用新技术和工具来找到更好的方式来传达需求并提供正确的解决方案，同时使流程尽可能愉快。
根据我们自己的经验和客户的经验，我们总结了需求管理的五大挑战，以及如何克服每个挑战的专家见解。
挑战#1：第 11 个小时突然袭击
一位高管在最后一刻找到你，向你提供三周前你需要的反馈。
我们都经历过这种沮丧，这对双方来说都不是一件愉快的事情。现实情况是，管理人员忙于处理各种问题，往往被迫专注于最紧急的问题。此外，领导者或利益相关者看到原型并意识到初始需求文档中指定的内容不再是最佳解决方案后，可能会产生想法。
专家提示：保持开放
为了防止最后一刻的突然出现，你必须在项目的所有阶段都保持透明并接受反馈。在整个开发过程中为管理层提供更好的可视性和持续的反馈循环，以便在为时已晚之前解决问题。频繁的签到可以帮助尽早得到反应。如果你的团队和高管在同一间办公室，这更容易实现。在显眼的位置（例如项目室或指挥中心）放置一块白板或专用墙来分享最新的设计。每天，人们都会路过并有机会对他们所看到的东西做出反应。大多数人对视觉效果的反应比书面文字更好，因为他们更能理解用户体验。
如果您的团队分布在多个地点，这在当今很常见，那么为每个人提供项目需求、相关设计和 Live Traceability™ 中心的专业解决方案将有所帮助。无论身在何处，任何人都可以看到项目进展情况，并且您将能够在任何分歧或潜在问题导致代价高昂的返工之前发现它们。
挑战 2：重新制定决策
会议用于重新审视旧决策或让其他人了解最新情况。
随着开发过程中出现新信息，决策可能会被推翻。但是，有比在团队会议上讨论这些变化更好且更具成本效益的方法来解决这些变化。
专家提示：要清晰
为了妥善管理变更，整个团队需要了解所做决策的完整背景，以了解事情发生变化的原因以及这些变化如何影响项目范围。人们需要清晰和理解才能发挥最佳水平。
这适用于上游的利益相关者和客户，以便他们了解他们得到了什么。它也适用于下游的设计、开发和 QA 团队，以便他们确切地知道要构建和测试什么。
现代协作解决方案可以帮助您捕捉围绕需求自然发生的健康辩论和持续讨论，而无需召开更多会议。人们可以看到其他人在说什么，并随时添加反馈以同意或不同意、批准或拒绝，或提出修改以完善解决方案。
此外，会议上做出的决策不易在文档中记录，而且人的记忆会随着时间的推移而逐渐消失。在某些市场，例如医疗器械行业，决策记录可能也是一项要求。如果决策缺失是贵组织面临的一个问题，请采用一种新技术来根据要求记录决策，并让团队随时轻松查看。这将消除歧义并确保有关项目的决策清晰明了。
挑战 3：变更税
当发生变更时，手动向所有人发送更新。
在执行复杂项目时，变更将会发生，通常是出于好的理由。随着您对项目的设计和开发越深入，您就会比一开始了解得更多。因此，您和您的团队将想出更好的方法来构建所需的产品并在此过程中修改需求。如果您尝试通过跟踪 Word 文档中的更改来管理版本并保持可见性，那么您将面临巨大的时间负担。
专家提示：迭代
通过连接点、快速评估影响并自动将变更传达给相关人员，明智地接受变更。您希望您的整个组织在找到更好的解决方案时都有权提出变更。
在您的组织内采用敏捷的首要原因是创建一种灵活的文化，以便您的团队能够快速有效地响应不断变化的需求。事实上，敏捷开发的第一原则是“我们的最高优先级是通过尽早和持续交付有价值的软件来满足客户。”
因此，在开发过程中不断迭代。
不要纠结于标签或争论 Scrum 和 Kanban 哪个更好。没有明确的、一刀切的流程。敏捷首先是一种文化思维，而不是规定性的开发流程。
有效的敏捷团队会保留需求最佳实践，例如可追溯性、影响分析和变更管理，这些最佳实践借鉴了传统方法，因此他们可以了解变更对项目其余部分的连锁反应。
这是敏捷和正式控制之间的平衡行为。有人称之为混合方法。同样，标签并不重要。关键是找到最适合您团队的技术组合，以便您可以在鼓励/欢迎/响应变更的同时执行项目。
挑战 4：注意力缺失
创建一份长达 200 页的详细计划，但没有人有时间阅读、维护或审查。
您需要向参与产品开发流程的人员阐明您的计划，并让利益相关者明确了解与他们相关的内容。问题是，大多数人在任何时候都只关心计划的特定部分。一些文件是法规要求的。但是，如果您在处理文档，您可能会花费大量时间创建很少有人阅读的内容。而且，每当项目发生变化时，人们都必须查看整个项目以找出变化的内容，并每次确定是否与他们相关。最终，人们不再关注。
专家提示：保持相关性
采纳这样的理念：每个人都太忙了，无法吸收整个需求文档。为了避免因组织的集体注意力缺失而感到沮丧，相关性是关键。
在这个领域，产品开发解决方案可以帮助您将大型复杂项目分解为更小、更易于管理的部分，并让人们专注于与他们相关的内容。我们建议您逐项管理项目范围以完成工作。如果您好奇我们所说的“项目”是什么意思，那么需求就是一个项目。用例是一个项目。测试用例是一个项目。缺陷是一个项目。
人们自然会一次处理几个项目的列表。这就是我们的大脑的工作方式，这样我们的工作效率更高。通过使用具有关系数据库的解决方案逐项列出项目范围，它将使人们能够专注于他们正在处理的特定项目并维护整个项目的上下文。然后，根据基线、发布或里程碑的需要，您可以将项目分组在一起并通过报告或规范文档总结项目以获得整体视图。
挑战 #5：期望不匹配
利益相关者认为他们得到的是一回事，但实际得到的却是另一回事。
期望差距可能会给公司士气带来真正的问题，更不用说您的底线了。您的开发团队对自己创造的东西感到自豪，因此当它没有达到预期时，他们会觉得自己的辛勤工作白费了。另一方面，利益相关者可能会觉得自己的声音没有被听到，或者开发团队没有理解请求。
专家提示：积极主动地进行可追溯性
每个项目在开发过程中都会发生变化，无论是添加其他内容还是随着范围的发展重新确定功能的优先级。您必须能够记录相应利益相关者提出的请求、理由、决定、协议和批准。并且在整个开发过程中，这些信息必须可供所有人使用，以确保一致的期望。
在根据要求开发产品或系统时，团队必须与利益相关者所述和同意的需求或问题保持一致。对于系统工程师、业务分析师和产品所有者来说，需求可追溯性（将需求追溯到下游开发、测试、验证、确认和风险活动的能力）无疑是好事，也是必需的。
无需增加大量不必要的开销，现代需求管理解决方案就可以捕获决策、审查、批准和电子签名以确定范围变更，并提供上下文，所有这些都是自然工作流程的一部分。
有了这种可见性，每个人都可以确信他们知道计划，您的开发团队也可以对兑现承诺感到满意。您的发布会可以成为对您出色工作的庆祝，而不是对哪里出了问题的质问。
