今天看一篇園子里面的
文章，剛好手上碰到這樣的事不少，最近也有個項目遇到了這樣的情況，感觸之余，就寫了篇文章算是交流一下吧。
客戶常常有很多很急的需求，很多客戶不是軟件開發專業的，常常拿他們平常所見的軟件與我們的產品或項目作比較，認為這樣或那樣的功能在臆想中應該一天或短時間就能完成的，殊不知在寫代碼的時間很短，但了解需求，版本管理和溝通確認的時間是要得到充分保證的，否則只有一個后果，返工的機率大大增加，辛苦寫的代碼成了廢品。這時，誰能體會我們心在流血的感覺呢，那么多的一個個加班和心血都沒有了。
所以，溝通確認是為了讓客戶明白，需求一定要明確要細致，明白了客戶的真實要求，雙方達成一致意見后，再以書面的形式確認下來，客戶可能會認為麻煩，但這種麻煩是必須的，一方面保證需求有據可查，另一方面客戶會通過這種認真，知道我們的專業精神。
我舉一個最近的例子
某客戶是有名的快速執行的主，最近很多需求，從集團人力資源部，從分子公司，從各個層面象雨點一樣撲面而來，怎么辦，我們采取的辦法是，一一記錄下來，用標准的文檔，里面以圖片加文字加原型設計的格式來說明各個需求，統一由集團人力資源部的管理者確認。確認后我們再動手，再急的需求也必須有記錄，哪怕是為了客戶不扣錢而加急趕的工，事后也要和客戶確認一下。客戶的態度也慢慢從當初的馬上就提需求到現在的思考后再提需求。從中間得到的經驗和教訓是：
1、需求必須要詳細說明，必須要站在客戶的角度描述，避免純文字描述，能有圖片盡量有圖片，遇到有新功能還要輔以原型界面，這點時間的花費是絕對值得的
2、有些小改動不是大改動沒有新增功能、不影響產品普遍適用性的，而且關系到客戶工作評價的，譬如改個查詢視圖的排序之類的，在需求說明范圍之內的，能速度解決的就速度解決，不需要再來回確認客戶會明白的。不是任何工作都要客戶確認一下，那樣就失去了需求確認的意義了，我們做需求確認是為了雙方的意思表達一致，並對結果預期（圖片、原型）一致，不是人為搞那么多文檔麻煩彼此的
3、文檔寫作是個細致的活，一定要站在客戶的角度去想去寫，不要怕麻煩，需求確認越清楚，后面的兄弟們寫代碼越輕松，越不會出現返工的現象。
4、需求說明文檔必需對產品有深刻的理解人去寫，一個人如果只負責自己這幾個模塊功能的，很可能考慮不全面
5、再橫的客戶也明白規范工作的意義，要掌握好平衡，對需求一定要據理力爭先確認，哪怕是口頭的溝通就開始做的很急的功能，也要在寫代碼時馬上補好需求文檔讓客戶確認，因為這時代碼剛剛開始寫，如果理解錯了，還來得及糾正
下面是一段對話
george.hu 17:13:14
好
某客戶人力 17:13:21
哈哈 這件事情溝通蠻久了 會不會感覺蠻崩潰？
某客戶人力 17:13:32
寫這個需求變更單 你寫了有好幾次了吧
某客戶人力 17:13:42
要是我 就抓狂發瘋了
george.hu 17:14:26
不會啊，說清楚了再做，這是個好習慣
某客戶人力 17:14:41
厲害
某客戶人力 17:14:46
恩 心態蠻好
某客戶人力 17:14:57
是做大事的料子
george.hu 17:15:33
習慣了，呵呵
你越專業，越冷靜，越細致，還要掌握一點平衡，客戶就會越認可你
這個需求文檔來回改了不下5次，但我認為是絕對值得的
文檔附件在此處，大家可以參考/Files/georgehu/復件需求變更確認單20120509.doc