一个企业应用软件即将交付，开发方和需求方一起商讨用户测试的时间安排等事宜。此时，需求方才发现一个重要的应用功能被做了“瘦身”处理，即：虽有此功能，但如此的简化处理和操作复杂性使该功能点基本无实际意义。

这就犹如到了考场才发现委托别人带来的是铅笔一样。交付期在即，如果按需求方所述的功能复杂度和深度补充开发，工期将在N个月以上，双方为此争执不下。需求方称此功能在当初的需求书中已提出，而开发方称其就是按照此前需求方提出需求书开发的，并可用需求方签字和往来的邮件作证。

碰到这样的棘手问题，在双方辩论式的会议上是很难达成共识的。因为，此时的讨论已经远离了开发该软件的初衷和最终使用者的实际需求及操作习惯，变成了双方寻找证据证明自己的说法是有理有据，以有利于推卸责任。

很显然，双方对“需求”的理解是不相同的，甚至差异很大。就比如甲方要求乙方购买一台“60英寸液晶平板电视机”，但甲方未书面详尽提出关键的字段“60”“液晶”“平板”，而乙方有意无意地理解成了需要一台电视机，甚至12英寸黑白电视机就可以。在乙方归纳整理了需求后，甲方深入思考就在一叠厚厚的业务需求书上签了字。而随着甲方对电视机的新功能了解的深入，其意向中的需求又增加了带“高清、可上网”这两项重要功能，并口头和乙方进行了沟通。如此一来，当乙方买回电视机时，双方的落差、争执就非常之大，就像“跑车”和“普通轿车”甚至摩托车的差距。

姑且不去讨论这样的事情责任在哪一方，如果双方都能真正从“以客户为中心”的角度来思考和合作，软件开发前、开发中、开发后的误解就会少很多，软件最终的实用性也会大大提高。对开发方来说，“客户”不仅仅是提需求的人，更是该软件的在需求方公司的最终使用者，而对需求方来说，其也有客户，也即该软件的最终使用者。从这个意义上理解，双方的“客户”是基本相同的。在这个理解的共识下，很多事情的沟通就变得相对容易一些。

“以客户为中心”要求开发人员不仅仅是将需求用技术来实现，即只进行“翻译”，而要深入思考，用技术引导客户定出更贴近实际需要、并具有一定领先性的功能点；而对需求方的要求则是：不能简单地用粗线条勾画需求就算完成，要深入功能细节和实现途径，并了解新技术、新功能的应用，从软件最终使用者的角度考虑适用性、必要性，并经济性上综合平衡软件功能实现的深度和复杂度。

“以客户为中心”的这简单的六个字，使双方的“客户”有了重叠，思考有了共同的区，都能深入从对方和最终给用户的角度去分析，一个个细化后功能开发共识和平衡在软件编码工作启动就详细完成了，不至在即将出窑前还为砖头的形状在争执。这种思考方式也为好的开发成果和双方的长久合作奠定良好的基础。

当然，需求方、开发方在需求的分析讨论会上不能蜻蜓点水，然后各自自由发挥，要尽可能地深入探讨，并及时和对方交换意见，使理解的偏差及时能被发现和纠正。

在软件需求的分析和实现中，功能点“勉强够用”和“非常实用”的距离其实很远，就犹如房间的内装修时间可能超过建房屋框架的时间一样。很多企业每年都有大量的应用软件在开发，不是每个需求拟定者和开发人员都是高超的项目管理师，“以客户为中心”的思考方式有助于双方够紧密协作、共同成功。