下文提到的客户是瑞典最大的旅行社之一——Langley，成立于1984年。其在世界各地以Langley Hotels的名字运营着16家酒店和度假村，为游客提供个性化的服务。
盛安德服务历程摘要：
· HR系统：做了5年，经历了12个HR，4个Accounting
· Reservation系统：做了9年，经历了5任Sales Manager，5个Marketing，4个COO
第一阶：与用户一起工作，零距离沟通解决实际问题
前3年客户说什么我们做什么，改变从第一次on-site工作开始，当我们亲眼看着用户使用我们2年前做的系统时，我们才理解一些功能是干嘛用的？当系统速度很慢，某些细节令我们十分“尴尬”时，我们迫不得已开始改系统。2个月之后，我们修改的系统让客户满意了。
因此我们得到了一条宝贵的经验——跟用户在一起工作，才能解决他们的实际问题。
我们至今觉得幸运，项目开始不久就能on-site工作，跟用户近距离接触。我们从ERP系统开始做，得以比较快地从内部接触到用户的实际需求，如果从booking等外部系统开始的话，要走很长的路才能抓住用户反馈，而且还需要很多工具去收集用户信息。
很庆幸我们做的是ERP系统，用户都是内部员工，销售、销售主管、产品经理等人。我们一去，坐在他们旁边看他们工作，看着看着我们自己就不好意思了，就知道系统该怎么改，活儿该怎么干了。我们就是这样学会如何从用户角度思考问题，如何与用户沟通的。
但是，即便你做到了从用户角度思考问题，与用户沟通，你也只能算是刚刚走上“敏捷”程序员的取经之路，前面还有九九八十一难在等着你。
第二阶：沟通尽量免“中介”
很多程序员会说，我天天都在跟客户沟通，客户会给我讲业务，告诉我需求，甚至告诉我怎么实现，帮我测试，告诉我bug……
这些其实都不算与客户沟通，或者只能说是与客户沟通的初级阶段。
要么是客户特别相信你，对你提交的东西不必测试，直接上线；或者客户找其他人测试你提交的东西，但没测出bug……一般情况下，凡是最终实际用户的测试，不存在“零bug”的产品。用户的思路千奇百怪，有时候甚至会另辟一条你都没发现的“蹊径”，找出一些让你始料未及的bug，这非常正常。
我认为什么时候不是客户给你报bug，而是用户，即系统的真正使用者给你报bug，那你才算“敏捷”程序员达标了。这一层次的沟通其实也有一些技巧，容未来有机会我们再展开细说。
第三阶：保持产品价值，而不是某一个客户个人的利益
我主要想讲的是另外一种沟通，比较有意思，还是举例说明吧。
客户方新来的COO肯定要刷存在感，于是新官上任三把火，他给我发了个邮件，问我能不能加“meal board”，实际上我们已经有了这个功能，只不过设计在递进的页面，他不知道罢了。于是我回邮件告诉了他。
接着来了第二把火——他又发了第二封邮件，提出一个关于预订的问题，而且语气比较强硬。于是我的同事花了几个小时检查原因，然后给他回了邮件，说预订功能没找到什么问题。
然后我了解到这个情况，用了一个Log分析工具，查找了一下用户使用的轨迹。这个用户访问了90多个页面，预订后就是不提交，这显然不正常。我们分析他很有可能是个竞争对手，来窥视和“学习”的。然后我们把记录用户访问轨迹的工具发给了COO，他就明白了。
当然，第三把火是不能少的——他发了第三封邮件，提出不要显示“打包价格”，而要显示“单位价格”，因为后者显得“便宜”，更能吸引用户。他这个需求可以理解，因为他同时负责销售，用低价刺激销售是“常用”手段。
但实际上，显示打包价格是我们9年研究用户使用习惯的结论，虽然看起来贵一点，但它更真实。如果只显示单价，尽管当前页面流量会增加，但只要进入下一级页面价格就会“暴涨”，客户难免会有“被欺骗”的感觉。所以我们不能按他的意愿改。但他是客户，是COO，我们到底该不该听他的呢？
