科技进步与发展是日新月异的，这也必然会催生新的业务、新的需求，因此大部分项目发生需求变更是无法完全避免的。当市场、环境都在发生着剧烈而深刻的变化，必然会带来政策的调整、流程的再造、业务规则的修改。
一味地否认抵制改变带来的需求变更当然不行，但全盘照收只会让项目越变越大，项目组的人每日每夜地加班。怎么办呢?可以试试将需求和变更记录成文字性的文档，然后根据实际情况提出哪些现在做，哪些暂时不做，哪些到二期或三期工作时再考虑，并请他们确认。
当业务在确认需求说明书的过程中有反馈意见提出时，需尽快讨论并确认意见的合理性，对合理的需求需尽快更新到需求说明书中，再次提交确认，必要时可能需要再次访谈。
举个例子，首先自己从业务入手，整理业务的流程，画出业务流程执行的yes线和no线，no线其实就是可规划的几个产品方向。然后针对不同的产品方向做进一步评估，看哪一个方向是眼下可行性最高，价值最大的。
拿着选定的产品方向思路，和业务相关的同事去验证，看这个产品是否对她们业务有帮助，在这个过程中，逐渐就明确需求了。
在这个过程中，很多人会出现疑问，到底是先有需求，还是先有项目/产品。按照大多数的逻辑，先有需求，才会有产品。但是在实际公司推出一个新产品的时候 ，往往是先有项目/产品，然后才去明确需求， 就是大家提出的问题：接触了一个项目，但是项目需求还不明确的情况。这个时候我们应该用假设—验证—最终确认的方法，具体如下。
1)先假设一个产品方向。
2)市场分析，通过市场分析，总结出目前关联市场的现状，尤其是问题点，或者将来的发展趋势点
3)需求分析，结合市场分析的结果，看能否提炼出来一部分需求。
4)用户分析，挖掘下，在这个市场环境下，到底是谁有这些需求。
通过以上4个步骤，顺利的话，可以得到这个结论——项目是为了解决谁的什么问题，同时也会验证这个项目的必要性。
5)竞品分析，以上知道了要解决谁的什么问题，接下来通过竞品分析，可以吸收一些功能特点和想法，解决了这个项目通过什么样的方式解决以上用户的需求。
6)接下来救顺理成章了，如果是产品就做产品形态。