經歷了一年的折騰，一直跟隨的項目終于走到了尾聲，盡管最后的結局是向好的，但我依然將其劃歸為失敗！心中的苦楚雖然在時間這個最具魔力的工具下漸漸平復，但是寫下這個題目依然是鼓起十足的勇氣。
前提
其他類型的項目不好說，我這里只說說軟件定制的項目。
1.客戶，客戶
現實世界很難將過錯推給客戶，畢竟客戶是上帝吧。但是經過這次，真心覺得如何利用好客戶是項目成敗的關鍵。
為毛這么講？
第一，需求
舉例來說，我們這次項目本來大家是摩拳擦掌，躍躍欲試，在時間緊任務重的情況下，希望把事情做到可以做到的最好！客戶給的需求說明，非常詳盡，A4雙面打印紙，打出來有兩個大拇指的厚度。但是非常不幸的是：
全文字！全文字！全文字！唯一的圖表是各種邏輯圖！
真的！真的！真的！我沒有讀完（當然程序員未必真的要讀完客戶需求，因為還有顧問呢啊，但是，但是。。。程序員看consultant的分析就等于吃了人家嚼過的饃，已經少了一層意思）
第二，抽象和具象
接下來，壞結果水到渠成，為啥？
客戶的需求是抽象的，而非具象的。需求只體現在了功能上面，而不是具體的畫面。
客戶第一次見到成品的時候，非常不滿意，為何？因為我們所呈現的東西不是他們腦子里想像的哈姆雷特！我們呢覺得就是按照他們的意思編的，他們認為他們的需求被扭曲了。。。當然，這里是否有語言的問題，也不好說。也就是說當客戶的母語不是文檔中的語言，不可否認，某種程度上出現歧義是非常有可能的。
另外，為什么文藝作品搬上熒屏，不管演員如何努力，總會有人跳出來說演的不好，不是心中的（或者說是小說中的）XXX？但是現實中的客戶不滿意就是大事兒了，不是斗斗嘴皮子的閑聊天兒
但是無論怎么樣，客戶是衣食父母，咋辦？
具象化對客戶需求的理解
畫圖或者模型是目前我看到的唯一解決辦法，同時這也是我們梳理思緒和邏輯的過程。另一方面，在客戶需求中很難表現的是他們現實的工作環境以及流程（這部分有所表現，但是還不充分）。這樣就容易造成程序員按照自己的開發習慣做出來的東西，客戶覺得并不方便他們的使用！
第三，測試
千萬別和我說，客戶不是測試中的一部分，恰恰相反，客戶應該包括在測試中，而且不是最終測試中。客戶的測試需要從第一個試運行版本開始，這樣客戶的意見可以及時加入到下一部分的修改中。避免成品后再改動，因為這樣容易造成對代碼的毀滅性打擊，或者說是對花了心血的程序員朋友們的自信心造成重大打擊！把客戶嵌入在測試+反饋中也是現下流行的敏捷開發中所提倡的。
未完待續
