? ? 記得多年前我參與的一個行業2B的大型系統建設項目中，從啟動到系統割接上線花了2年時間，需求分析就花了1年時間，在后一年中，需求爭論和變更就從來沒有停止過，一直困擾研發人員的問題是，在系統上線的前一天需求還在變動，最后大家達成共識，為了保證系統正常穩定上線，我們建立的需求基線提前3個月就關閉了新需求在上線版本的體現，而是放到后續版本中實現，所以可以說我們的需求就從沒有停止過變更，上線后系統穩定，但甲方業務部門卻抱怨這不是我想要的系統，我的需求不是這樣的。可能你也經歷過相似過程，甲方和乙方都很辛苦，2年的建設周期，加班加點是常事，不斷的開會討論和需求確認，雙方也都為系統上線投入了大量的成本和時間，但卻很難得到使用方的業務認可（但非常認可我們的工作態度）。
? ? 在這個過程中到底發生了什么呢？我們的需求訪談、收集和分析難道還不夠細致嗎？還是客戶的需求本來就是不可能滿足的（因為他們經常善變）？。當然有經驗的項目經理會告訴你，要用需求確認的方式逐條同客戶進行需求簽字確認，以確保后期客戶需求變更的責任劃分，但這絲毫不能阻止我們研發出來的系統并不是一個讓客戶歡喜雀躍的系統，而是一個平庸的系統。
????這個問題其實本身也是軟件工程一個一直存在的普世問題，無論我們如何改進軟件開發過程（傳統瀑布式、螺旋，敏捷開發模式等），實際上真正在項目實踐中總有這樣或那樣問題涌現出來，這些研發模式總會感覺實踐起來困難重重。我們開過手動擋車的人都有這樣一個體會，學開車或者是開好車最關鍵的其實并不是在駕校中學到的流程，規則或操作步驟，而是我總結的兩種感覺，一個是：“機械感”，一個是：“路感”，“機械感”負責你對車這部機器進行操作的機械反饋的預判和掌握，負責你對車的控制力；“路感”負責你對道路反饋的預判和控制，是你對道路行駛的掌握。這些是你開車的細節，只要掌握這兩個細節，你開車就會變得很容易。為了說明需求分析中的細節決定成敗，我再舉一個中國足球的例子，大家都知道中國男足弱，但歸結原因無非是足協體制，青訓，教練，戰術，球員不職業等，但我覺得中國足球最大問題是無“球感”，也就是對足球在身體各個部位接觸反饋和預判和控制，而提高中國足球的方法是要拆解足球訓練流程和步驟，專注在足球最核心的身體反饋訓練上，過早開展技戰術訓練反而會影響運動員在球感上投入的專注，這也是日，韓雖然在足球體制和青訓體制上世界一流，但為什么水平是三流的原因。
????上面我講的兩個問題都是想說明決定我們項目成敗的往往并不是宏觀流程和步驟，而是實施細節和操作的潛意識。今天的主題就是想講講需求分析中的潛意識：需要2需求的動賓結構。
什么是需求？ 市場營銷學的解釋是：需求是指人們有能力購買并且愿意購買某個具體商品的欲望。我們往往忽略需求的真實理解核心是：意愿，能力和商品。這三樣組合在一起才是需求，用個公式表達什么是需求：意愿+能力=商品。這里的能力指甲方客戶購買力，如：財務能力，同時也指乙方提供客戶購買意愿的能力，如：技術能力，資源整合能力等。在這點不容易產生誤解所以我也不做過多描述，我將重點是闡述這個過程中最容易誤解的意愿和需求這個話題。
客戶意愿就是客戶需要(need)，是客戶對于實現業務目的而產生內在意愿，比如：一個銷售人員為了更有針對性的對客戶開展銷售，他必須要了解客戶消費力。所以他的需要就是了解客戶消費力。?
需求(requirement)分析的過程是：匹配客戶意愿+能力=商品的過程，它是提供組合和匹配商品的過程，它不能從客戶那里直接獲取的，在過往項目中我們常常直接收集客戶，然后將需求重組，歸并同類項，從而形成系統功能。我們誤解客戶需要就是需求。
需要和需求是我們最容易搞混淆的概念，雖然在中文中他們很難區分，但在英文中區別還是比較明顯的，需要(need)是動詞，而需求(requirement)是名詞，需要是指心理活動，以“我想。。。”，“我要。。。”開頭的典型動賓結構，而需求則應該是具體包括了能解決客戶需要，驗證雙方能力，最后提供具體功能的解決方案。需求是我們分析得到產物，所以我們常說的需求分析并不是分析的需求，而是分析的是需要。為什么要咬文嚼字的去區分這個概念，這點為什么又那么重要呢？因為單純開發一個系統確實沒有必要搞清楚兩者的區別也能上線運行，但如果不搞清楚客戶的真實需求，就不能給他帶來業務的最佳實踐幫助，就不是一個優秀的系統。
? ? 在行業2B客戶的大型系統中，實際操作使用的用戶是主要參與者和需要的提出者，但這些用戶又常常給我們帶來很多困擾，他們有多樣化的角色，分工和不同的文化，社會背景，所以他們提出需要的規范并不一致，有些業務部門的用戶提出的是含糊的需要，有些有IT背景的用戶提出的又是比較細致的，符合他自己理解的需求（具體系統功能）；對于構建新系統，新業務的用戶常常提出的是需要，而對于舊系統改造，舊業務升級客戶往往提出的是細致的需求，所以這就對我們的需求分析師或者產品經理帶來了極大的挑戰，對于需要和需求我們要怎么收集，整理和分析呢？下面我將用需要2需求模型來甄別和分析不同的需求或者需要。
????上圖給出了一個基本分析方法，通過需要如何分析成為需求，這是一個多年前我親身經歷的一個案例，一次我在做需求收集的過程中，我詢問一位客戶的銷售經理關于與銷售管理功能相關的需求，我在同他的訪談中，他很快就給我了一個名詞性需求：“一個實時銷售額匯總報表”，如果按照往常，我將很快收集該需求具體的維度，元素，統計條件，規則和實時性要求等，然后歸檔為報表需求，可是那天由于他是不假思索的脫口而出，直覺告訴我，這里邊一定有故事（需求分析師有時非常像偵探，需要敏銳的嗅覺來探尋客戶內在需求）。我和他套了套近乎，然后點上一根煙和他聊了起來，具體就是上面圖表中的步驟，他看似給了我一個需求（一張報表），不過我還是按照需要來處理，這樣可以分析他真實的動機和系統需求。不出意料，他之所以會提出一個實時報表需求，是因為他老板有抽查下屬對實時銷售額準確性的愛好。這兒插個不相干的話題，有些老板還喜歡隨時問他部門經理，自己部門具體的人數是多少？特別是那種2，3百人的部門，你還真不一定答的上來(因為有人員進出，有些還在入職，離職流程中等)，傳授一個這類情況的回答經驗，無論你是否知道準確值，回答一定要肯定，不要含糊其辭，原因自己琢磨。回到正題，通過三三法則，暨：三個洞察why，給客戶三個解決方案評估，最后真正需求逐漸浮出水面，因為下屬的工作過程對老板缺乏透明性，所以老板只能靠最簡單的報數字游戲來檢驗下屬是否認真。所以核心功能是提供一個銷售經理巡店軌跡上傳的功能，來解決老板對于日常管理的關注，最后至于銷售額統計報表還要不要就仁者見仁智者見智了。誰知道從一張報表到一個巡店軌跡上傳這兩個完全不搭界的功能還有如此聯系呢？ 一個小知識點，客戶的報表需要往往是最容易隱藏內在需求的地方，當你接收到大量報表類需求的時候，你就要認真考慮一下這里邊是否有故事了。
總結一下，客戶提出他們所謂需求的時候，往往有兩類情況：第一類是對于系統功能沒有具體想法，只能用我想。。。，我要。。。這樣的動賓結構來描述自己的心理需要。第二類是對于系統有自己明確的看法直接提出系統需求，比如：一張報表，一個菜單功能，一個字段等名詞結構。無論是哪種情況，我們都需要按照“需要2需求模型”重新評估和分析，不能直接記錄為系統需求，這種分析模式必須訓練成潛意識，針對客戶的需要多提幾個為什么？只有通過為什么的挖掘，我們才能像偵探一下洞察真正的需求動機和訴求。培養需求分析模式的潛意識是關系項目成敗的關鍵，當你接收到1，2百張的報表需求的時候你就該好好想想你有沒有問過客戶為什么？
