软件开发中如何应对需求的不确定性？

你需要学习设计模式、MVVM和Combinator。

软件开发中如何应对需求的不确定性？你需要学习设计模式、MVVM和Combinator。客户并非不在乎具体实现方式，只不过客户说不出来他为什么喜欢这种不喜欢那种。

产品人员的工作就是确定这些事情，弄明白到底哪种实现方式最优，然后设计出产品来给交付团队。

不确定性往往是由于产品人员没有时间或没有能力确认这些东西。

那么原型法就是干这个的，持续集成也是干这个的，迭代式发布也是干这个的，给你个东西，这样你就可以体验，然后告诉我你喜欢哪种。

当然，有些时候即使这样仍然无法确定，那就干脆不确定，先弄个东西上市场上去做beta，然后再收集反馈进行修改。

iPhone不也这么干的。概念验证原型，把用户界面先做出原型，给用户确认
开发采用快速迭代，从客户那里获得反馈进行改进
想得清楚的先做，想不清楚的什么时候想清楚了再做需求要签字，再改要加钱。需要及时和多的沟通，保持业务理解上的一致

实现的功能事前事后需要演示

维护变更需求，变更同样属于新需求需要计费绝大多数的客户不知道他们想要什么，但是他们明确知道自己不喜欢什么，所以那就早点做出来，让他们看喽，获取他们的反馈。

以最小的代价将该功能上线，然后加一些event来跟踪用户对该功能的使用习惯再做调整。或者做一个伪功能，当用户点击时，弹出框“coming soon”之类的，来减少前期的成本以及探求用户的需求。这样得到一些用户数据的支持之后，也能更好的说服客户做决定。拥抱变化，自动化测试，持续集成，快速迭代，简单设计，重构，用户合作。你可以看看敏捷方面的书。不确定性解决得越早，代价越低。
所以，建议在需求分析阶段使用某种原型系统先将软件的样子大致让用户看到。你所描述的并不是需求的不确定，而是设计模式的体现。假设建立在需求合理的情况下，利用同理心，模拟用户场景来设计。最终是要让用户完成任务，这个过程中，使用哪种表现形式，怎么让用户用的爽，遵循一些交互原则就好了，比如尽量少的点击，操作负荷大于认知负荷，界面元素的隐喻，及时有效的反馈等等。

这些都不是需求，而是设计，在交底时，最好能说出来为什么要用这种方式，比其他方式好在哪里，为用户带来了哪些便利，如果你能说出来，并得到认可，一般不会差。但是验证还是要有的，因为我们不可能把所有场景都考虑全。好的设计是改出来的，这句话没错。画出原型，反复找客户论证从代码设计的角度也必须考虑到需求形式的变化，需要更高层次的抽象或者更灵活的架构设计，需要设计人员能够在有限的具体需求里归纳总结出统一的流程或者设计，能够把未来的变化考虑在内。之前做大型游戏的AI需求也是很具体的需求，但实际上是策划人员常常有不一样的新需求，总不能没完没了写代码，完全可以设计一个包含状态机、功能插件、事件触发、文本解释的引擎让设计人员简单的直观的去配置自己所需的AI

作为一个从业者，我建议你接受这个现实：客户的需求总是会变；其实也不难理解，需求变才说明软件有生命力，因为人总是要求越来越好的嘛；

然后我建议在接受这个现实的基础上，用我们的专业技术来做到客户需求变动后我们的调整最小，这个包含技术和服务两方面，技术上我们竟可能的把架构，代码做得耦合点，梳理出容易变动的部分和不容易变动的部分，用好架构，模式和各种效率工具；服务上，竟可能的先让客户在没开发前看到实际的软件效果，包含如何交互体验的，怎么展示的等，减少因为双方理解不一样而导致的调整