需求沟通为什么那么难?

例如:客户在谈需求时,他认为需要改变一些内容,但是他不会去说业务上的背景和他所在环境。当然,如果业务背景程序员不了解,我们可以主动去问、去了解。比较容易出问题的就是,客户说的一些需求程序员是能够理解的,但是程序员理解的东西跟客户理解的东西是完全不一致的,更糟糕的是,大家并不能够发现这中间的差异


一些不懂软件开发的客户,他往往对于系统的认知是停留在他能看得到的东西。比如同样是在页面上加3个按钮,客户会觉得加一个按钮花一天,那加另外一个按钮也是花一天。但是他不能理解的是,可能一个按钮我们只要10分钟就能加好,因为是很简单的功能,或者说是已经做过的东西,我们再做一遍当然很快。但另外一个按钮,是全新的内容,会涉及到很多东西,那么可能加这个按钮却需要一周,甚至更长时间。


再比如,很多客户说他想做一个页面或者功能,这是经过他加工过的。而他在这个加工之前,原本有一个痛点或者问题的,那么如果我们按照他加工的内容来开发,即使是百分百还原他的构想,也不是他需要的。


最佳解决方案怎么来的?

那么,软件开发正确的沟通方式是什么?客户直接告诉程序员你的痛点或者问题,而不是解决方案!这一点很重要!因为大部分时候,客户的解决方案其实并不能、也基本不可能站在一个开发者角度去思考。


程序员要做的,就是首先让客户把问题/痛点表达出来,也可以说一些解决方案,然后程序员去思考,告诉他这个方案是不是可行,是不是有一些你没有想到的地方。我们从程序的视角,客户从业务视角,一起去讨论出一个最好的解决方案。


客户一般是当前处于一个困境下,给出来的需求是非常短期、紧迫的,或者说不是站在一个全局的角度给出了一个需求。而作为程序员,是需要看到全局的。这部分需求实现的代码是不是能符合整体系统的框架,会不会跟其他内容有冲突?再去评估客户的需求对于未来来讲是不是一个可持续的状态,避免出现拆东墙补西墙,或者说把后期修改更新的途径封死,不停地打补丁。


总而言之,每当程序员拿到一个需求,一定要去考虑这个需求在未来会不会发生变动,他的考虑是不是整体的、全面的?需求沟通不一致,客户发现做出来的东西跟他想的是完全不一致的,这个成本其实是很高的。


怎样才能做出好的软件?

固定价格的项目由于有成本和预算的限制,程序员认为他可能对于需求没有那么多的精力和时间去细细了解。而软件开发ODC的付费模式,就是按时间去计费,这种服务与总包形式的服务核心不一样,总包形式只关注于结果。但是软件本身,并不像汽车、手表这种消费品,软件本身是不确定的,它本身就是一个思维的产物,所以怎么想——这个过程很重要。统一了需求以后,才能做出一个比较好的产品。


所以软件开发ODC服务相对来讲,会比传统的外包(固定价格、总包)形式的合同更有利于把产品做好不管是程序员,还是客户,都愿意花时间去面对问题,把需求了解清楚了以后再开工。虽然从时间上来看,似乎会比传统的合作方式成本更高一点。但是,这种形式的服务规避了更大的风险,从长远来看,从达成的结果和效率来看,未必比固定价格要贵


还有一点很重要,因为对时间付费,所以这对客户也是有约束的。这部分约束反映到整个项目中,就是从需求端先行把控,客户会督促自己尽快明确需求,想清楚问题/痛点。如果需求不清楚造成的返工,客户也是有责任的。


软件开发ODC服务的合作形式需要两方的信任,最终造成的效应就是不管是甲方还是乙方,都希望尽可能地把这个项目需求整理清楚,然后考虑清楚,进而把项目做好,解决眼前的痛点乃至长远的考量,最终确保做出来的软件是可用的,且对业务/企业发展起到积极促进作用的。