?? 最近，負(fù)責(zé)客戶的一個(gè)項(xiàng)目設(shè)計(jì)的審計(jì)工作，是一個(gè)短信平臺(tái)的項(xiàng)目，上行和下行通信都有，之所以叫平臺(tái)，是想將客戶的很多的業(yè)務(wù)系統(tǒng)，涉及到短信的部分都統(tǒng)一掛接到者一個(gè)服務(wù)平臺(tái)當(dāng)中，只要一家服務(wù)提供商，量大從優(yōu)，避免各自為戰(zhàn)，浪費(fèi)資源。業(yè)務(wù)系統(tǒng)多是遺留系統(tǒng)，當(dāng)中對短信需求各不一樣，客戶從自己的vendor List中找了一個(gè)短信服務(wù)提供商（SP）。一般的要是能進(jìn)入vendor list中，說明實(shí)力還是有的。
?? 由于項(xiàng)目設(shè)計(jì)多個(gè)系統(tǒng)，前期投入就要10K$，還不算后期的按條計(jì)費(fèi)的短信費(fèi)用，我是參與項(xiàng)目技術(shù)方面的審核工作，客戶不懂技術(shù)，很信任我，我是不敢怠慢。
?? SP派了客戶經(jīng)理和項(xiàng)目經(jīng)理及幾個(gè)技術(shù)人員，來開了幾次會(huì)，雙方一起制定了協(xié)議格式、接口功能，考慮到遺留系統(tǒng)，提供多種業(yè)務(wù)接入方式如WS、socket等方式。
?? 同時(shí)對于目前的流量和未來的增長，也做了分析，對方做了最終的設(shè)計(jì)方案，漂亮的powerpoint展示出平臺(tái)的幾個(gè)feature：與業(yè)務(wù)無關(guān)的松耦合接入、跨平臺(tái)、可擴(kuò)展、Scalability，似乎都很完美。
?? SP很得意，會(huì)議現(xiàn)場充斥者“沒問題”的論調(diào)。現(xiàn)場中提出的其他的附加功能，如手機(jī)身份驗(yàn)證、日志、費(fèi)用對賬等，都一一答應(yīng)下來。
?? 客戶象征性的問了我的意見，我說還是要做一個(gè)POC（proof of conecpt)，來驗(yàn)證一下，這個(gè)POC相當(dāng)一個(gè)Demo了，就是要驗(yàn)證設(shè)計(jì)，只實(shí)現(xiàn)核心的功能就可以了。
?? 雙方討價(jià)還價(jià)，POC制作的費(fèi)用是2萬元，結(jié)果噩夢就從這個(gè)POC開始了。
?? 1）2個(gè)星期后，對方來部署POC，忙到天黑，未果，說是短信貓與服務(wù)器的端口有沖突，工程師走了，沒說什么時(shí)間再來。
?? 2）又過了幾周，在反復(fù)打電話，催促下，工程師來了，終于搞定，通知客戶說可以測試了，結(jié)果只用一個(gè)手機(jī)，都沒有測試通過。對方有走了，說是短信貓沒充值，沒錢了，把客戶都?xì)馑懒耍瑳]充值，讓客戶測個(gè)屁啊。
?? 3）第三次測試，個(gè)別的手機(jī)，能測試通過。非常不穩(wěn)定，一個(gè)機(jī)票申請、審批流程，要半個(gè)小時(shí)走完。
?? 4）拖了一個(gè)月，對方要修改設(shè)計(jì)方案，將上行的短信貓方式，修改為WS方式，定時(shí)調(diào)用，獲取信息。
?? 5）最后，對方信心滿滿的，拍著胸部說，沒問題了，可以了。
?? 6) 我設(shè)計(jì)測試案例，手機(jī)分為聯(lián)通手機(jī)、移動(dòng)、繁體手機(jī)、英文手機(jī)等，測試流程是模擬真實(shí)業(yè)務(wù)的機(jī)票申請、審批的流程。客戶開始召集10幾部手機(jī)，開始人肉測試，還有人在外地測試。
??
????? 測試目的，初期并不以壓力測試為主，而是測試infrastructure，諸如上下行通道暢通、通信制式、編碼、協(xié)議、業(yè)務(wù)流程為主。
????? 測試結(jié)果非常失望，繁體不支持，聯(lián)通通過率很低，移動(dòng)很慢，上行和下行通道都不穩(wěn)定。
?? 7）這樣的測試很累，我們調(diào)整了策略，讓SP按照我們的測試案例，提供測試報(bào)告。SP不愿意，說沒有那么多人，我對他們說，你們傻啊，客戶是黑盒測試，你們有源碼，可以有更靈活的測試策略啊，比如Mock Test之類的白盒測試啊，對方?jīng)]反應(yīng)，可能是他們沒有正規(guī)的測試平臺(tái)。
?? 8）最后，4個(gè)月過去了，客戶還是客氣的給了2萬元錢，雙方各自散去，無疾而終。
?? 教訓(xùn)：
?? 1）一定要用POC來驗(yàn)證華麗的設(shè)計(jì)方案，避免看上去很美(參見 用代碼來推動(dòng)設(shè)計(jì)）。
????? 所謂的UML、PPT、方案書，其實(shí)都是一種Presentation, Not Validation。
?? 2）底層的平臺(tái)設(shè)計(jì)的穩(wěn)定性，很重要，再好的function, 性能不行，白扯。如果想不出辦法來驗(yàn)證，就不要上馬，不能用時(shí)間和Money來驗(yàn)證，時(shí)間比錢更重要！
?? 3）對于vendor的服務(wù)行為一定要在合同中注明，避免出現(xiàn)不規(guī)范的現(xiàn)象：
??????? 1.技術(shù)工程師是個(gè)性情中人，沒有服務(wù)的意識(shí)，說來就來，說走就走，還經(jīng)常不耐煩，發(fā)飆，真拿自己不當(dāng)外人。沒有時(shí)間觀念，自己說周二來，結(jié)果沒來，也不解釋一下，還要客戶主動(dòng)打電話問為什么不來。
????????2.沒有規(guī)范的測試流程，直接在現(xiàn)場邊修改代碼，邊測試。
??????? 3.對于客戶的不滿，沒有及時(shí)的響應(yīng)，仍然是老一套的能拖就拖的現(xiàn)象，典型的有中國特色的軟件公司，郵件發(fā)到老板那里，才有效果。
??????? 4.過度承諾，對客戶的承諾不負(fù)責(zé)，說話不算數(shù)。
?? 4）客戶是無辜的，做人要講誠信，特別是搞技術(shù)的人，設(shè)計(jì)絕對是要負(fù)責(zé)任的，現(xiàn)在越來越覺得一些所謂的設(shè)計(jì)師，跟江湖郎中沒有區(qū)別。
??
????