最近，负责客户的一个项目设计的审计工作，是一个短信平台的项目，上行和下行通信都有，之所以叫平台，是想将客户的很多的业务系统，涉及到短信的部分都统一挂接到者一个服务平台当中，只要一家服务提供商，量大从优，避免各自为战，浪费资源。业务系统多是遗留系统，当中对短信需求各不一样，客户从自己的vendor List中找了一个短信服务提供商（SP）。一般的要是能进入vendor list中，说明实力还是有的。
由于项目设计多个系统，前期投入就要10K$，还不算后期的按条计费的短信费用，我是参与项目技术方面的审核工作，客户不懂技术，很信任我，我是不敢怠慢。
SP派了客户经理和项目经理及几个技术人员，来开了几次会，双方一起制定了协议格式、接口功能，考虑到遗留系统，提供多种业务接入方式如WS、socket等方式。
同时对于目前的流量和未来的增长，也做了分析，对方做了最终的设计方案，漂亮的powerpoint展示出平台的几个feature：与业务无关的松耦合接入、跨平台、可扩展、Scalability，似乎都很完美。
SP很得意，会议现场充斥者“没问题”的论调。现场中提出的其他的附加功能，如手机身份验证、日志、费用对账等，都一一答应下来。
客户象征性的问了我的意见，我说还是要做一个POC（proof of conecpt)，来验证一下，这个POC相当一个Demo了，就是要验证设计，只实现核心的功能就可以了。
双方讨价还价，POC制作的费用是2万元，结果噩梦就从这个POC开始了。
1）2个星期后，对方来部署POC，忙到天黑，未果，说是短信猫与服务器的端口有冲突，工程师走了，没说什么时间再来。
2）又过了几周，在反复打电话，催促下，工程师来了，终于搞定，通知客户说可以测试了，结果只用一个手机，都没有测试通过。对方有走了，说是短信猫没充值，没钱了，把客户都气死了，没充值，让客户测个屁啊。
3）第三次测试，个别的手机，能测试通过。非常不稳定，一个机票申请、审批流程，要半个小时走完。
4）拖了一个月，对方要修改设计方案，将上行的短信猫方式，修改为WS方式，定时调用，获取信息。
5）最后，对方信心满满的，拍着胸部说，没问题了，可以了。
6) 我设计测试案例，手机分为联通手机、移动、繁体手机、英文手机等，测试流程是模拟真实业务的机票申请、审批的流程。客户开始召集10几部手机，开始人肉测试，还有人在外地测试。
测试目的，初期并不以压力测试为主，而是测试infrastructure，诸如上下行通道畅通、通信制式、编码、协议、业务流程为主。
测试结果非常失望，繁体不支持，联通通过率很低，移动很慢，上行和下行通道都不稳定。
7）这样的测试很累，我们调整了策略，让SP按照我们的测试案例，提供测试报告。SP不愿意，说没有那么多人，我对他们说，你们傻啊，客户是黑盒测试，你们有源码，可以有更灵活的测试策略啊，比如Mock Test之类的白盒测试啊，对方没反应，可能是他们没有正规的测试平台。
8）最后，4个月过去了，客户还是客气的给了2万元钱，双方各自散去，无疾而终。
教训：
1）一定要用POC来验证华丽的设计方案，避免看上去很美(参见 用代码来推动设计）。
所谓的UML、PPT、方案书，其实都是一种Presentation, Not Validation。
2）底层的平台设计的稳定性，很重要，再好的function, 性能不行，白扯。如果想不出办法来验证，就不要上马，不能用时间和Money来验证，时间比钱更重要！
3）对于vendor的服务行为一定要在合同中注明，避免出现不规范的现象：
1.技术工程师是个性情中人，没有服务的意识，说来就来，说走就走，还经常不耐烦，发飙，真拿自己不当外人。没有时间观念，自己说周二来，结果没来，也不解释一下，还要客户主动打电话问为什么不来。
2.没有规范的测试流程，直接在现场边修改代码，边测试。
3.对于客户的不满，没有及时的响应，仍然是老一套的能拖就拖的现象，典型的有中国特色的软件公司，邮件发到老板那里，才有效果。
4.过度承诺，对客户的承诺不负责，说话不算数。
4）客户是无辜的，做人要讲诚信，特别是搞技术的人，设计绝对是要负责任的，现在越来越觉得一些所谓的设计师，跟江湖郎中没有区别。