近期经历的项目中面临了较大的需求变动，特此总结经验教训防止类似情形再次发生。以下为“如何减少因为需求考虑欠周导致的额外成本”的一些思考：
- 充分的分析需求首次确认需求可行性
这个阶段主要理解产品在业务需求上和用户需求上分别要达到怎样的目标、产品的宗旨甚至产品设计的准则，若有疑问可向相关人员咨询以帮助后续的工作开展。 - 完善产品逻辑
通过编写用例的方式，可以让自己对产品逻辑有一个系统性、地毯式的梳理，减少遗漏，确定需求的实际实施方案以及进一步确认需求可行性。 - 需求评审
编写完毕用例，根据用例进行产品原型设计，设计过程中进一步检验用例的逻辑完整性；最后将较完善的产品需求文档、原型同各部门同事沟通（运营人员、开发工程师、测试工程师等干系方），引导各个职位的同事从不同的角度再次确认方案可行性，尽量在开发前找出产品逻辑漏洞并完善。
这样重重的把关之后，相信会减少后期需求因考虑欠周所造成的变动。
需求发生变化后怎么处理？
需求可能在以下 2 个阶段发生变化。
需求评审后
将初步的产品需求文档提供给相关同事浏览后，必定会收到有关产品逻辑漏洞的反馈。此时独自或与同事共同完善产品逻辑，这也是需求评审的意义，减少在开发过程中推倒需求重做。
后续完善产品逻辑漏洞后需要再次确认产品逻辑的完善程度，以保证产品可开发性。开发过程中
根据需求的重要程度，若变更的需求在本阶段开发目标中必不可少，则只能顶着压力确定变更后的方案同工程师沟通开发。
若变更的需求优先级较低，则可与开发工程师、需求方商量安排下一阶段进行完善。
以上。
