随着软件和产品不断升级，软件开发项目难度也在增大，团队需要在开发、维护和遵守相关产品标准的同时，还要保持其初始目标能够实现。在许多项目中，需求文档可能长达数百页，并且在开发过程中会经历无数次更改。这就意味着团队有时需要花费几个小时来循环、编辑和跟踪大量需求文档地更改，并期望每个成员都能阅读这些文档并持续参与其中。有时，审查和批准所有需求所花费的时间甚至比实际的需求工程活动还要多，这不仅会影响全职员工（FTE），也会影响项目预算，有可能会导致预算短缺。
为了提高用户体验，现代产品开发通常涉及多个领域和学科，可能包括硬件、软件，以及涉及医疗设备行业的生物技术、化学和生命科学等各类科学领域和工程方法。
例如在医疗设备、汽车、航空航天和国防等行业，产品开发必须遵守严格的安全标准和法规。企业要想增强竞争优势，就要提高工作效率。而需求管理是取得一切成果的根本。
实际上，Word 和 Excel 等类静态工具，已经不足以有效管理复杂的需求。
问题不在于需求文档本身。事实上，文档本身是记录需求所必需的。问题在于使用文档来管理需求。如Word和Excel等，无法支持加速的开发过程、变化的速度以及应对复杂的组织文档管理流程。在当今复杂的产品开发环境中，用这些工具来设定期望、传达项目细节以及跟踪变更已经不再现实。
产品经理作为确保每个人理解我们正在构建什么以及为什么（也就是需求）的人，必须改变你的工作方式。你需要采用新的技术和工具，找到一种更好地方式来传达需求，以保证顺利交付正确的解决方案。
我们从自身经验和客户经验中总结出了需求管理的五个最大挑战，并就如何应对这些挑战给出了专业建议。
挑战1: 最后关头的突然介入
在项目快要结束时，一位高管才给你三周前所要的反馈。
这种情况通常让双方都很不愉快。之所以出现这种情况是因为管理者每天忙于应对各种被迫关注的、紧急的问题。而且有时候，当管理层或利益相关者拿到产品原型后，可能会产生新的想法，并意识到最初的需求文档中所指定的内容已经不再是最好的解决方案。
专家建议：保持开放
为了避免在项目最后阶段被突然介入，你必须在项目的所有阶段都保持透明并对反馈保持开放。在开发过程中提供给管理层更好的可见度和持续反馈循环，以便在最后阶段之前解决问题。频繁得检查可以帮助早期获得反馈。
如果你的团队和执行员工在同一办公室，你可以在项目办公室或指挥中心等地方的显眼位置放置一块白板或设置专用墙，用以分享最新设计。团队成员每天路过都能看到，并可及时讨论。视觉展示一般来说比书面文字更容易引起其他人的兴趣。
但是如今团队往往分布在多个地点办公，就需要一个专业解决方案。它可为每位团队成员提供一个“中央枢纽”，可提供项目需求、相关设计等信息以及具备实时的追踪。这样，在任何地方办公的成员都可以查看项目进展情况，及时处理存在的分歧，或解决可导致返工的潜在问题。
挑战2: 决策反复变更
浪费时间开会反复审视以前的决策，或者花时间向其他成员解释项目进度。
随着开发过程中新信息的出现，决策可能会被推翻。但是不一定非得通过开会地形式，还有其他更好、更具成本效益的解决方法。
专家建议：提升透明度
要有效管理变化，整个团队需要了解决策的全局背景，以理解事情为何会改变，以及这些变化如何影响项目范围。人们需要清晰和理解才能尽其所能地执行。
这适用于你的利益相关者和客户，让他们了解他们将得到什么。同样也适用于你的设计、开发和QA团队，让他们确切知道需要构建和正确测试什么。
现代协作解决方案不需要通过召开会议的形式，就可以捕捉到团队围绕需求所展开的讨论和辩论。团队成员可以看到其他人的言论并随时添加他们的反馈以表示同意或不同意，批准或拒绝，或提出编辑以精细化解决方案。
但如果使用文档得方式记录会议决策，就很难随时进行追踪。在医疗器械行业，决策文档也是需求的一部分，决策记录缺失会带来一系列问题，所以应该考虑使用新的技术手段来记录决策和变更。这样团队可以随时查看这些信息，有助于消除歧义，提高决策透明度。
挑战3:需求频繁变更
当有些事情发生变化时，有必要手动向所有人发送更新。
在复杂项目的开展过程中，变更通常不可避免。随着对项目进一步的设计和开发，团队可能会想出更好的方案来构建产品，并相应地修改需求。如果用word文档的方式控制版本、保持项目透明度，后续将会花费大量的时间成本。
专家建议：采用迭代的方式
应对变更较为明智的做法是将各个点联系起来，快速评估其影响，并自动将变更传达给相关人员。如果存在更好的解决方案，应该鼓励团队提出变更。
采用敏捷需求管理方式的主要目的是让工作方式变得更灵活，确保团队能够快速、有效地响应不断变化得需求。
实际上，敏捷开发的第一原则就是，“我们的首要任务是通过早期和持续的交付有价值的软件，来满足客户的需求。”因此，你要在开发过程中进行增量开发的迭代。
不必纠结 Scrum 或看板哪个更好，也不要把它们标签化。敏捷开发没有一套普适的标准流程。敏捷的本质是一种思维方式，而不是一套严格的开发流程规范。
高效的敏捷团队通常践行需求管理最佳实践，如保持需求可追溯性、影响分析和变更管理，这些实践都是从传统方法中借鉴而来，可更好地了解变更对项目其余部分的连锁反应。最佳实践是在敏捷性和形式控制之间保持平衡的一种混合方法，主要为了找到最适合团队的技术组合，以便在开展项目的同时，鼓励提出变更和应对变更。
挑战4: 注意力缺失
创建一份详细的200页计划，但没有人有时间去阅读、维护或审查。
参与产品开发的每个人都要了解计划，特定利益相关者也需要知道项目中的哪些部分与他们直接有关。但问题是，大多数人只关心项目进展中特定时间段的特定部分。但有一些文档是法规要求必须要具备的，如果手动记录需求，可能要花很多时间整理出一些没人会阅读的文档。一旦变更产生，成员就要审阅所有文档，才能知道变更是什么以及是否是自己负责的部分。久而久之，大家的就不会再关注需求文档。
专家建议：保持相关性
每个人都有很多工作要处理，没有精力了解所有需求文档。为了避免需求文档被抛之脑后，必须要让每个人清楚文档中与自己相关的部分。
而产品开发解决方案可以将大型、复杂的项目分解为更易于管理的小部分，并让每个人专注于与自己相关的部分。建议逐项管理项目范围，什么是一项：一个需求是一项；一个用例是一项；测试用例是一项；缺陷是一项。
大脑通常可以同时处理几个项目，同时能处理的事情越多就意味着我们越高效。通过使用带有关系数据库的解决方案逐条列出项目范围，项目成员会更专注于自己正在处理的特定项目，并利于了解整个项目背景。根据基线、发布或里程碑的需要，可将项目整合在一起，通过报告或规范文档的形式加以总结，以便于了解项目的整体情况。
挑战5: 期望不匹配
利益相关者认为他们会得到一种东西，但实际上却得到了另一种东西。
期望落差可能会影响整个公司的士气，更不用说你的利润了。你的开发团队为他们创造的东西感到自豪，所以当它不符合期望时，他们可能会觉得自己辛勤工作被浪费了。另一方面，利益相关者可能会觉得他们没有被听到或者开发团队没有理解请求。
专家建议：建立可追溯性
每个项目在开发过程中都会产生变更，无论是要添加额外的内容还是随着范围的变化需要重新确定功能的优先级。我们需要记录利益相关者发出的请求、理由、决策、协议和批准，并确保每个人都能在整个开发过程中都能获取到这些信息，保证利益相关者和开发团队的期望始终一致。
在根据需求开发产品或系统时，团队必须与利益相关者所陈述并同意的需求或问题保持一致。对于系统工程师、业务分析师和产品所有者来说，需求可追溯性（能够追溯需求到下游开发、测试、验证、确认和风险活动的能力）的价值是无可争议的。
现代需求管理解决方案可以在不增加大量开销的情况下随时获取决策、审查、批准等信息，并就范围变更进行电子签名。这种高度的可见性确保了每个人都了解项目进展情况和工作流程，确保开发团队顺利履行交付承诺。只有这样，团队才能在最终发布会上开心庆功，而不是相互质问哪里出了问题。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
