客戶(hù)常常有很多很急的需求，很多客戶(hù)不是軟件開(kāi)發(fā)專(zhuān)業(yè)的，常常拿他們平常所見(jiàn)的軟件與我們的產(chǎn)品或項(xiàng)目作比較，認(rèn)為這樣或那樣的功能在臆想中應(yīng)該一天或短時(shí)間就能完成的，殊不知在寫(xiě)代碼的時(shí)間很短，但了解需求，版本管理和溝通確認(rèn)的時(shí)間是要得到充分保證的，否則只有一個(gè)后果，返工的機(jī)率大大增加，辛苦寫(xiě)的代碼成了廢品。這時(shí)，誰(shuí)能體會(huì)我們心在流血的感覺(jué)呢，那么多的一個(gè)個(gè)加班和心血都沒(méi)有了。

所以，溝通確認(rèn)是為了讓客戶(hù)明白，需求一定要明確要細(xì)致，明白了客戶(hù)的真實(shí)要求，雙方達(dá)成一致意見(jiàn)后，再以書(shū)面的形式確認(rèn)下來(lái)，客戶(hù)可能會(huì)認(rèn)為麻煩，但這種麻煩是必須的，一方面保證需求有據(jù)可查，另一方面客戶(hù)會(huì)通過(guò)這種認(rèn)真，知道我們的專(zhuān)業(yè)精神。

我舉一個(gè)最近的例子

某客戶(hù)是有名的快速執(zhí)行的主，最近很多需求，從集團(tuán)人力資源部，從分子公司，從各個(gè)層面象雨點(diǎn)一樣撲面而來(lái)，怎么辦，我們采取的辦法是，一一記錄下來(lái)，用標(biāo)準(zhǔn)的文檔，里面以圖片加文字加原型設(shè)計(jì)的格式來(lái)說(shuō)明各個(gè)需求，統(tǒng)一由集團(tuán)人力資源部的管理者確認(rèn)。確認(rèn)后我們?cè)賱?dòng)手，再急的需求也必須有記錄，哪怕是為了客戶(hù)不扣錢(qián)而加急趕的工，事后也要和客戶(hù)確認(rèn)一下?？蛻?hù)的態(tài)度也慢慢從當(dāng)初的馬上就提需求到現(xiàn)在的思考后再提需求。從中間得到的經(jīng)驗(yàn)和教訓(xùn)是：

1、需求必須要詳細(xì)說(shuō)明，必須要站在客戶(hù)的角度描述，避免純文字描述，能有圖片盡量有圖片，遇到有新功能還要輔以原型界面，這點(diǎn)時(shí)間的花費(fèi)是絕對(duì)值得的

2、有些小改動(dòng)不是大改動(dòng)沒(méi)有新增功能、不影響產(chǎn)品普遍適用性的，而且關(guān)系到客戶(hù)工作評(píng)價(jià)的，譬如改個(gè)查詢(xún)視圖的排序之類(lèi)的，在需求說(shuō)明范圍之內(nèi)的，能速度解決的就速度解決，不需要再來(lái)回確認(rèn)客戶(hù)會(huì)明白的。不是任何工作都要客戶(hù)確認(rèn)一下，那樣就失去了需求確認(rèn)的意義了，我們做需求確認(rèn)是為了雙方的意思表達(dá)一致，并對(duì)結(jié)果預(yù)期（圖片、原型）一致，不是人為搞那么多文檔麻煩彼此的

3、文檔寫(xiě)作是個(gè)細(xì)致的活，一定要站在客戶(hù)的角度去想去寫(xiě)，不要怕麻煩，需求確認(rèn)越清楚，后面的兄弟們寫(xiě)代碼越輕松，越不會(huì)出現(xiàn)返工的現(xiàn)象。

4、需求說(shuō)明文檔必需對(duì)產(chǎn)品有深刻的理解人去寫(xiě)，一個(gè)人如果只負(fù)責(zé)自己這幾個(gè)模塊功能的，很可能考慮不全面

5、再橫的客戶(hù)也明白規(guī)范工作的意義，要掌握好平衡，對(duì)需求一定要據(jù)理力爭(zhēng)先確認(rèn)，哪怕是口頭的溝通就開(kāi)始做的很急的功能，也要在寫(xiě)代碼時(shí)馬上補(bǔ)好需求文檔讓客戶(hù)確認(rèn)，因?yàn)檫@時(shí)代碼剛剛開(kāi)始寫(xiě)，如果理解錯(cuò)了，還來(lái)得及糾正。

原文鏈接：http://www.cnblogs.com/georgehu/archive/2012/05/10/2494856.html

【編輯推薦】

1. 2012年Web設(shè)計(jì)和開(kāi)發(fā)的15個(gè)趨勢(shì)
2. The Joel Test：軟件開(kāi)發(fā)成功12法則
3. 軟件開(kāi)發(fā)中最流行的錯(cuò)誤觀點(diǎn)有哪些？
4. 開(kāi)發(fā)者拒絕寫(xiě)技術(shù)博客的常見(jiàn)理由
5. WEB開(kāi)發(fā)的需求溝通并不難