在软件开发中，如果你问任何经理“在管理项目中，你的痛点是什么？”，超过85%的人会说-需求。
在这个领域，我们的经验教训是什么？未来在项目中我们如何做的更好？
接下来，我们将强调我们在需求培训课程中所教的原则如何帮助需求分析师来提高他们的工作：
问题1：“在需求阶段我们没有识别和包括‘正确的’干系人。这经常会在项目后期引起不必要的需求变更。”
例子
在最终的用户验收测试中，客户告诉我们系统的授权功能没有满足他们的需求。我们发现在需求诱导阶段我们与之交谈的客户代表们没有告诉我们这个授权需求。这些代表们是资历较浅的员工。他们没有意识到这个需求。
所以我们立刻召集最好的技术员工来做变更。我们估算我们要多花费至少25个人天来做这个事情。幸运的是，整个项目延迟了7个工作日。
:经验教训：
干系人的重要性。。。 详细的干系人模板。
问题2：“在项目结束时，我们评审。我们得出的结论是我们所建立的解决方案不是解决问题的最佳方案。”
例子
“我们正为一家重要的保险公司开发一个现金管理系统。因为现金管理非常重要，所以该公司在总部的整个组有一个非常有经验的团队来管理所有现金。该公司的银行合作伙伴来销售保险服务。作为交换，这些银行想要保险组存钱到银行。
当我们和这个保险组的财政部门讨论时，他们提出了这项需求：如何管理现金流的需求-每个地方分支机构必须从总部拿到现金来满足他们的地方银行合作伙伴
我们听到了这个需求，并且在系统中增加功能来满足。我们把这个作为系统的一个功能包括进来。在5个月内我们开发并交付了系统。
在项目完成之后，我们有一个项目结项会议。当我们回头看时，发现一个更好的解决方案：为每个分支设定一个准则即保持满足当地银行营业额的一个百分比更简单，而不是管理总部和分支之间的复杂的现金流。但是我们仅仅与该保险公司的现金管理部门谈论过，他们没有全局的视角。他们只能告诉我们他们的问题，并且希望有一个IT系统来解决他们的问题。”
经验教训
需求分析师必须把自己放在行业专家/咨询师的位置上。他们不应该把自己局限于只是为客户问题提供IT解决方案。而要针对商业问题对能为客户提供价值的商业解决方案进行更多的思考。
如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。
需求发现者的职责，就是确定拥有者看重的价值是什么。
客户不一定总能给你正确答案。有时候客户也不可能知道什么是对的。有时候他
就不知道需要什么。
传统来讲，需求活动被看成是某种类似速记员的任务。也就是说，业务分析师仔细聆听利益相关者，准确记录他们说的所有东西，并将他们的要求翻译成产品的需求。这种方法的缺点是；它没有考虑到利益相关者在试图描述需求时的困难，展望一个产品来解决一个问题，这不是一项简单的任务，尤其是问题并非总是理解得很切底。考虑到今天业务
的复杂性和规模，个人确实很难理解业务所有适当的部分。也有‘增量改进’的问题。有询问有关新系统时，利益相关者常常会描述原有的系统，并加上一些改进。这种增量的方式通常排除了所有重大的创新，常常会导致平庸的产品，不能满足期望。