來自同事的經驗共用：分享一個需求調研的案例，談談他的感受和啟發

在該項目中，需求調研人員花費一個半月時間開了8次需求交流會發出十幾封需求討論郵件向業主方調研需求，期間產出了3個版本的需求規格說明書（均在60頁以上）。

系統部分功能開發完成後給業主方展示。看了之後業主方驚呼不是自己想要的，指責我方不按照需求開發， 我方拿出需求規格說明書後，業主方更加激動當即認為我方“篡改需求”。

後經專案經理通過從業務的角度向業主方說明為什麼這樣實現，以及按照業主方的想法實現系統會有什麼問題的方式將當時與業主方溝通的情境還原，才使業主方接受了我方的說法沒有追究下去。

有人會說這個案例中主要還是業主的問題，需求調研一個半月發了3個版本要他們確認，自己不看需求後面出了事還反咬一口。但是，各位覺得我方有什麼做的不足的地方嗎？下面說說我的看法：

1、調研時直接把需求規格說明書給業主方是“霸王硬上弓”的做法。有人會說一次調研談了很多內容，與其寫成會議紀要還不如寫成需求規格說明書，一氣呵成又提高了效率，何樂而不為？親愛的朋友們，大家有沒有從業主方的角度考慮問題？一個60頁的文檔大家能專心看多久？分幾次能看完呢？按照我的實踐看20頁左右注意力就無法集中了，我們自己做起來都有問題怎麼能要求業主方呢？反倒給業主方留下不負責任的印象，他也就無法信任你。

2、把需求規格說明書作為需求調研的唯一產出物是“把雞蛋都放在一個籃子裡”的做法。 事後專案經理仔細尋找了需求調研會議紀要，需求確認郵件可就是沒有那部分需求細節的確認內容，凡是。需求調研的成果不讓業主方對每一點進行確認就是在給項目的關鍵路徑上“埋地雷”給業主方challenge你的機會，這次踩上了是地雷沒爆，下次還會這麼幸運嗎？

3、談完問題談談改進的方法。

與業主方對需求調研的過程式控制制達成一致。不但我們要明白還得讓業主方明白，需求規格說明書是需求調研的最終成果並不是唯一成果，加入規格說明書的內容必須要業主方認可（最好是簽字認可）；然後還要對確認的周期達成共識，比如業主方必須對一天前的調研需求做一個check確認，我方的責任就是將當天的需求調研內容以會議紀要的形式在當天內發出。階段性調研結束形成的規格說明書要有一個詳細的更新列表和需求SRS一起發給業主方，方便人家閱讀。

要取得業主方的信任，不光對業務要瞭然於胸，還看我們做事的方式方法夠不夠專業。咩是專業？專業是比較出來的，就體現在我們對過程的控制細節上，只要我們想在業主之前，過程式控制制的比競爭者更細微，在業主的眼裡我們就比對手更專業。

說了這麼多，如果是各位來做需求調研，大家有什麼控制調研過程的方法嗎？