需求沟通为什么那么难？
例如：客户在谈需求时，他认为需要改变一些内容，但是他不会去说业务上的背景和他所在环境。当然，如果业务背景程序员不了解，我们可以主动去问、去了解。比较容易出问题的就是，客户说的一些需求程序员是能够理解的，但是程序员理解的东西跟客户理解的东西是完全不一致的，更糟糕的是，大家并不能够发现这中间的差异。
一些不懂软件开发的客户，他往往对于系统的认知是停留在他能看得到的东西。比如同样是在页面上加3个按钮，客户会觉得加一个按钮花一天，那加另外一个按钮也是花一天。但是他不能理解的是，可能一个按钮我们只要10分钟就能加好，因为是很简单的功能，或者说是已经做过的东西，我们再做一遍当然很快。但另外一个按钮，是全新的内容，会涉及到很多东西，那么可能加这个按钮却需要一周，甚至更长时间。
再比如，很多客户说他想做一个页面或者功能，这是经过他加工过的。而他在这个加工之前，原本有一个痛点或者问题的，那么如果我们按照他加工的内容来开发，即使是百分百还原他的构想，也不是他需要的。
最佳解决方案怎么来的？
那么，软件开发正确的沟通方式是什么？客户直接告诉程序员你的痛点或者问题，而不是解决方案！这一点很重要！因为大部分时候，客户的解决方案其实并不能、也基本不可能站在一个开发者角度去思考。
程序员要做的，就是首先让客户把问题/痛点表达出来，也可以说一些解决方案，然后程序员去思考，告诉他这个方案是不是可行，是不是有一些你没有想到的地方。我们从程序的视角，客户从业务视角，一起去讨论出一个最好的解决方案。
客户一般是当前处于一个困境下，给出来的需求是非常短期、紧迫的，或者说不是站在一个全局的角度给出了一个需求。而作为程序员，是需要看到全局的。这部分需求实现的代码是不是能符合整体系统的框架，会不会跟其他内容有冲突？再去评估客户的需求对于未来来讲是不是一个可持续的状态，避免出现拆东墙补西墙，或者说把后期修改更新的途径封死，不停地打补丁。
总而言之，每当程序员拿到一个需求，一定要去考虑这个需求在未来会不会发生变动，他的考虑是不是整体的、全面的？需求沟通不一致，客户发现做出来的东西跟他想的是完全不一致的，这个成本其实是很高的。
怎样才能做出好的软件？
固定价格的项目由于有成本和预算的限制，程序员认为他可能对于需求没有那么多的精力和时间去细细了解。而软件开发ODC的付费模式，就是按时间去计费，这种服务与总包形式的服务核心不一样，总包形式只关注于结果。但是软件本身，并不像汽车、手表这种消费品，软件本身是不确定的，它本身就是一个思维的产物，所以怎么想——这个过程很重要。统一了需求以后，才能做出一个比较好的产品。
所以软件开发ODC服务相对来讲，会比传统的外包（固定价格、总包）形式的合同更有利于把产品做好。不管是程序员，还是客户，都愿意花时间去面对问题，把需求了解清楚了以后再开工。虽然从时间上来看，似乎会比传统的合作方式成本更高一点。但是，这种形式的服务规避了更大的风险，从长远来看，从达成的结果和效率来看，未必比固定价格要贵。
还有一点很重要，因为对时间付费，所以这对客户也是有约束的。这部分约束反映到整个项目中，就是从需求端先行把控，客户会督促自己尽快明确需求，想清楚问题/痛点。如果需求不清楚造成的返工，客户也是有责任的。
软件开发ODC服务的合作形式需要两方的信任，最终造成的效应就是不管是甲方还是乙方，都希望尽可能地把这个项目需求整理清楚，然后考虑清楚，进而把项目做好，解决眼前的痛点乃至长远的考量，最终确保做出来的软件是可用的，且对业务/企业发展起到积极促进作用的。
