在系統開發的過程中，如何從客戶那裡獲取正確、有效的需求，是每個團隊都需要仔細考慮的問題。如果最初的需求沒有明確，就開始著手開發，到最後可能會有很多東西需要修改，浪費大量的時間、精力和金錢。
這件事說起來很容易，但實際做起來的時候，總會遇到各種各樣的阻力，似乎在每個專案中都一樣。所以，有很多人喜歡憑藉之前類似專案的經驗，或者自己對於業務的理解來做需求分析，要牽著客戶的鼻子有，甚至於替客戶決定如何來做系統。但是，這往往會導致客戶抱怨：你們做的系統不是我想要的，根本就不好用！其根本的原因就在於：我們不是客戶！
很多人都清楚的乙個原則是，在做系統的時候要從客戶的角度出發，但什麼是客戶的角度呢？在明確這個問題之前，我想大家應該了解我們程式設計師與客戶之間的一些區別。
首先，我們和客戶使用計算機的水平不一樣。這一點是客觀存在的，我們作為程式設計師，計算機就是我們戰鬥中的槍，那必然是非常熟悉，而且整天24小時至少會有十幾個小時在和計算機打交道，每個人熟悉的軟體至少也會有十幾種。而作為客戶，可能只是在上班的時候使用，而且使用的軟體非常有限，一般就是office，加上有限的幾個軟體。
其次，我們和客戶對業務知識的掌握不一樣。客戶的業務知識就是他所從事的行業的知識，比方說對於乙個保險公司的業務人員來說，他們的業務知識就是與保單、**人、承保、理賠、保全相關的各種內容，而對於**型企業來說，他們的業務知識就是與採購、銷售、產品、訂單等相關的內容。如果我們沒有做過相應的行業軟體的話，那麼我們的業務知識就很差。這也正是為什麼好多軟體公司想要做一種行業軟體時，所存在的壁壘。
既然有了這麼大的不同，那麼我們想要從客戶的角度出發，就要以客戶的計算機水平和業務水平來考慮，這樣做出的東西才是給客戶用的，而不是給我們程式設計師用的。
想要達到這個目的，首先我們就要從自己做起，努力去學習各種業務知識，要有不恥下問的精神，千萬不要覺得自己是做it的，就孤芳自賞，而對於其他行業的人員，就覺得不如自己。古語說得好：三人行，必有我師。每個人的知識都有不同的重點，客戶中有很多人掌握著我們所不知道的知識，不向他們請教、學習是不行的。
然後就是要多多與客戶溝通，不同時間、不同地點、不同的環境中，客戶的想法也會有所不同，這也正是需求的變更，我們不能要求客戶提出的需求是一成不變的，有人說過，唯一不變的就是變化！想要解決這個矛盾，我覺得最有效的方法就是溝通，這樣的話，如果客戶的需求有了變化，我們會在第一時間了解，並為其做相應的工作，這樣可能就會節省出很多的時間和精力。並且，溝通是會增進我們與客戶之間的感情的，如果雙方都認為對方是自己的朋友，很多麻煩的事兒也就迎刃而解了。
接下來，我想和大家聊聊當前做系統時，獲取需求可能的幾種做法，並提出自己的淺薄的意見。
1、閉門造車型——也就是憑藉自己對行業的理解，或者是以往專案的經驗，猜當前專案的客戶會提出什麼需求，而不理會客戶的具體情況。
大家也應該可以立刻給出結論，這樣的專案很難成功，即便是我們之前做過100個類似的專案，那麼在做第101個的時候，也會發現企業會有自己的特點，客戶會有自己的特點，畢竟我們做出的系統不是給機械人用的，而是給人用的，有人存在，就會有差別，我們就應該具體情況具體分析。
2、積極溝通型——作為程式設計師或者是專案經理，在開發的整個過程中積極地與客戶溝通，及時了解客戶的需求是否有變化。
這種型別應該比上述的有很大的改善，但是我覺得需要注意的問題就在於溝通和資訊傳達的效率上。一般來說，可能這種工作會由專案經理來做，而不是由具體開發的程式設計師來做。這樣的話，就需要做溝通的人有充分的計算機知識和業務知識的儲備，既能夠了解客戶所說的話，也能夠把客戶所說的話正確地傳達給程式設計師，並且還可能會加入自己對如何在系統中實現的理解。
3、現場客戶型——這是敏捷開發中乙個很重要的原則，就是在開發的現場要有客戶，不斷地提供對系統的意見和反饋。
首先這一點很難達到，畢竟客戶也有自己的工作，很難整天地坐在我們旁邊為我們提供反饋。另外，如果說是乙個或者有限的幾個客戶，那麼就需要他對所要負責的模組相關的業務知識都非常了解，這對於現場客戶的要求也是非常高的。
上面幾種形式都是我們被動地來接收需求，其實我覺得我們還可以主動出擊，去找需求。
4、觀察客戶型——就是說我們要在客戶工作的時候一直觀察，看客戶是如何在實際工作中作出各種各樣的決定的，也了解客戶的工作方式和工作內容，看看如何能夠通過系統來幫助他們。
5、一起工作型——這種方式意味著我們要把自己下放到客戶的辦公室中，去和他們一起工作，有些邊緣性的工作，我們作為學徒的角色，幫客戶完成。
上面的兩種方式所獲取的需求都是第一手的需求，而且通過和客戶一起摸爬滾打，我們不僅能夠獲取寶貴的需求和業務知識，而且還可以了解到客戶對於每個需求的迫切程度，以及完成每個需求能夠為客戶帶來什麼，這樣就可以做到知己知彼，百戰不殆，不出意外的話，可以達到一種雙贏的結果。
然而，這需要高度的信任關係，畢竟行業之間都是有很多秘密的，不是乙個公司的人，不一定會把很多資訊和資料放心地交給我們程式設計師，所以，一般來說，這兩種方式其實對於做自己公司內部專案的程式設計師來說會比較適用。
總之，在獲取客戶需求的時候，我們要牢記一點，我們不是客戶，要想獲取有效的需求，想要做出客戶滿意的系統，那麼就要向客戶接近，多溝通，從客戶的角度來做系統。
程式設計師應知 我們不是客戶
在系統開發的過程中，如何從客戶那裡獲取正確 有效的需求，是每個團隊都需要仔細考慮的問題。如果最初的需求沒有明確，就開始著手開發，到最後可能會有很多東西需要修改，浪費大量的時間 精力和金錢。這件事說起來很容易，但實際做起來的時候，總會遇到各種各樣的阻力，似乎在每個專案中都一樣。所以，有很多人喜歡憑藉之...
程式設計師應知 我們不是客戶
在系統開發的過程中，如何從客戶那裡獲取正確 有效的需求，是每個團隊都需要仔細考慮的問題。如果最初的需求沒有明確，就開始著手開發，到最後可能會有很多東西需要修改，浪費大量的時間 精力和金錢。這件事說起來很容易，但實際做起來的時候，總會遇到各種各樣的阻力，似乎在每個專案中都一樣。所以，有很多人喜歡憑藉之...
程式設計師應知
作為程式設計師，不可避免地會經歷過下面的情況 你花費了大量心血辛辛苦苦地編寫了一本程式，結果到了測試人員那裡測試的時候，測試人員測了一陣子之後，提交給你乙份測試報告，並說 你裡面怎麼會有這麼低階的bug。或者說 你的程式裡面的bug好多，到底自己編寫完了之後測沒測試啊？或者在國內專案中可能是這樣的，...