在软件项目过程中，我们最常遇到的一个问题就是用户/客户和开发人员对于需求理解不一致。这种问题为什么会发生？又应该如何解决呢？资深全栈工程师为您剖析。
需求沟通为什么那么难？
例如：客户在谈需求时，他认为需要改变一些内容，但是他不会去说业务上的背景和他所在环境。当然，如果业务背景程序员不了解，我们可以主动去问、去了解。比较容易出问题的就是，客户说的一些需求程序员是能够理解的，但是程序员理解的东西跟客户理解的东西是完全不一致的，更糟糕的是，大家并不能够发现这中间的差异。
一些不懂软件开发的客户，他往往对于系统的认知是停留在他能看得到的东西。比如同样是在页面上加3个按钮，客户会觉得加一个按钮花一天，那加另外一个按钮也是花一天。但是他不能理解的是，可能一个按钮我们只要10分钟就能加好，因为是很简单的功能，或者说是已经做过的东西，我们再做一遍当然很快。但另外一个按钮，是全新的内容，会涉及到很多东西，那么可能加这个按钮却需要一周，甚至更长时间。
再比如，很多客户说他想做一个页面或者功能，这是经过他加工过的。而他在这个加工之前，原本有一个痛点或者问题的，那么如果我们按照他加工的内容来开发，即使是百分百还原他的构想，也不是他需要的。
最佳解决方案怎么来的？
那么，软件开发正确的沟通方式是什么？客户直接告诉程序员你的痛点或者问题，而不是解决方案！这一点很重要！因为大部分时候，客户的解决方案其实并不能、也基本不可能站在一个开发者角度去思考。
程序员要做的，就是首先让客户把问题/痛点表达出来，也可以说一些解决方案，然后程序员去思考，告诉他这个方案是不是可行，是不是有一些你没有想到的地方。我们从程序的视角，客户从业务视角，一起去讨论出一个最好的解决方案。
客户一般是当前处于一个困境下，给出来的需求是非常短期、紧迫的，或者说不是站在一个全局的角度给出了一个需求。而作为程序员，是需要看到全局的。这部分需求实现的代码是不是能符合整体系统的框架，会不会跟其他内容有冲突？再去评估客户的需求对于未来来讲是不是一个可持续的状态，避免出现拆东墙补西墙，或者说把后期修改更新的途径封死，不停地打补丁。
总而言之，每当程序员拿到一个需求，一定要去考虑这个需求在未来会不会发生变动，他的考虑是不是整体的、全面的？需求沟通不一致，客户发现做出来的东西跟他想的是完全不一致的，这个成本其实是很高的。
怎样才能做出好的软件？
固定价格的项目由于有成本和预算的限制，程序员认为他可能对于需求没有那么多的精力和时间去细细了解。而软件开发ODC的付费模式，就是按时间去计费，这种服务与总包形式的服务核心不一样，总包形式只