編輯導語：需求分析師，是一個連接各處的橋梁，需要和產品經理、開發、測試、用戶等進行溝通。本文作者從自身經驗出發，對需求分析師的主要工作及需要具備的技能和素質進行了梳理，希望通過此文能夠加深你對需求分析師的了解。

前言

客戶是一家上海的中外合資的汽車技術研發公司，所服務的類型是項目管理的IT信息系統的建設。具體細化是整車和零配件的實驗驗證管理IT信息系統開發。

首先提到是顯性知識和隱形知識的概念。一言以蔽之，即是知識是否有過編碼的過程。對于，客戶公司以及筆者所服務的KM公司而言，這已經是“常識”一類的認知了。但是在實踐中發現這里面依然存在著很大的問題。

具體而言之存在著：

1. 項目文檔的缺失；
2. 項目溝通障礙；
3. 崗位邊界模糊；
4. 項目合作方法存在認知差異（需求和開發同步推進）等重大問題

這些問題都需要在項目實施中去彌補實現。

一、場景化下的需求識別

客戶需求：需求分析師需要在歷史文檔和訪談的基礎上，將業務流程和系統頁面畫出來，具體的輸出里程碑是經過客戶書面確認的產品Demo和產品需求說明書。

項目需求：需求分析師需要在單位的工作日里面，輸出產品的Demo和PRD，并對程序開發團隊進行培訓講解，以保障項目的正常推進。

所謂知易行難無非如此，需求分析師需要面對的是客戶的壓力和本身項目組的壓力，成功則保障項目按計劃推進，反之則項目延后，甚至有項目解散的可能。

故而，產生需求識別的知識萃取話題。

1. 為什么需要對這類知識進行萃?。ㄝ腿〉男枨蟊尘埃?？

• 如果不能在工作計劃內形成客戶確認的產品Demo和PRD，會產生項目滯后或者項目解散的可能。
• 產品Demo和產品的PRD屬于需求分析師的核心KPI指標。

2. 目前表現出哪些問題（萃取的現狀）？

a、單位工作日內獲得了客戶確認的產品Demo和PRD,但是客戶提出了新的需求；（走需求變更流程）

b、獲得了客戶確認的產品Demo和PRD，但是項目超時；

c、沒有獲得客戶確認的產品Demo和PRD，需求和開發同步推進；

d、Demo和PRD沒有獲得客戶認可，項目解散。

3. 涉及崗位或人群，人員數量？

筆者公司內的咨詢團隊，衍生至行業內的同行。

綜合以上表述，利用任務描述的模板，總結提煉如下：

需求分析師需要在工作計劃內，掌握具體的業務定位，熟悉客戶的具體操作業務流程，用精準的語言和專業的軟件工具輸出產品的原型圖和產品功能需求文檔，并對程序開發團隊進行有效的業務開發培訓。

二、問題的提出、存在的痛點和希望實現的目標

1. 目標

a、產品的Demo和PRD；

b、開發團隊的業務培訓。最終實現項目的及時、成功上線。

2. 痛點

a、歷史文檔的欠缺。由于項目交接和對需求分析工作重要性的認知不足導致項目文檔缺失。如、關鍵的業務流程分析缺失。

b、行業專業知識的沉淀。需求分析師過往的項目經驗積累和學歷背景不可能完全符合客戶的專業需求。

c、溝通的障礙。語言的溝通障礙，客戶習慣于中、英文混合表述；客戶不愿意或者限于權限不方便討論更深層次的原因。

d、項目實施方法的認知誤區。由于開發進度（或者來自更高層的壓力）客戶更傾向于越過需求階段的工作，直接開發一步到位。需求分析師沒有職權獲得有效的溝通時間或者機會向開發團隊進行有效的溝通培訓。

e、信息傳遞的有效性和完整性。對于信息傳遞的有效性，相信筆者的同行大多能夠勝任，但是信息傳遞的完整性則不能保障。舉個案例：軍隊夜間行軍時口令傳遞的失真。在這個案例的基礎上，大家對于完整性將有更深入的理解和體會。進一步講，客戶方的“朝令夕改”則是大家都能體會的難點。對于此，只能說是“我更接近命題的真相”了。

3. 希望實現的目標

a、如何幫助客戶建立正確的項目實施方法

b、如何建立信任通過訪談獲得高價值的信息和獲得有用的資料

c、如何對程序開發團隊進行有效的溝通培訓

三、解決方法

1. 正反案例的解剖

典型反面案例：

案例一、“流程引擎的問題：UI盡量滿足客戶的需求，涉及到流程引擎功能及重構在現有工作計劃里面我們做不到（建議40萬重新立項一個流程引擎改造的項目，工期重新協定）。如果客戶不同意，建議投資項目終止，做好現有工作量的統計”。

案例二、“你們根本就不懂我們的業務流程，你們的演示和我和需求顧問溝通的東西不一樣。這樣的演示和我們的業務部門的需求還有一定的距離?！?/p>

上面的案例來自于某軟件公司的內部工作郵件和某軟件公司客戶演示的現場。涉及到的問題點有：

• 項目SOW工作范疇的確定；
• 客戶公司多項目、多供應商的系統集成；
• 客戶業務流程的梳理；
• 需求分析的準確和Demo演示現場氣氛的控制；

上面的大多數的痛點屬于需求分析師的主要工作范疇，也有一些如:SOW的撰寫不完全屬于需求分析師的工作領域。

典型正面案例：

案例一、“你畫的Demo比前面那位好多了，還能實現客戶的需求，我們開發做起來非常輕松，以后客戶這邊的需求就靠你了”。

案例二、“你真棒！把我的需求用你們的專業語言表述出來了，而且你的Demo超出了我的預期，在我給我的老板演示的時候，我的上司非常滿意”。

上面的案例來自于某軟件公司內部的溝通培訓會和客戶的現場反饋。

總結：通過上面正、反兩方面四個案例說明了需求分析的工作重要性，所謂是“成也蕭何、敗也蕭何”也不過如此。

2. 知識點的提煉

仔細解剖問題背后的原因：

（1）認知方面：需求分析的工作重心的問題，項目經理或者項目總監是否能夠準確理解需求分析的工作的職能需求？是否能準確理解需求分析工作在項目開發中的重要作用？當遇到強勢的客戶的時候，是否能夠把控項目推進的重心，并且及時有效的投放資源？

（2）思維方式方面：作為乙方，從行業特性來講是典型的第三產業、服務工作。而軟件公司是典型的“程序員文化”。這二者之間的沖突如何有效的“化解”、“克制”？如何有效的達到平衡？

（3）業務能力方面

1. 知識積累：學歷背景的積累和項目實施經驗的沉淀。這方面的知識應用更多的體現在對客戶的行業知識和專業知識的應用方面。畢竟咨詢顧問的職業特征之一就是無法預知下一個客戶所在的行業和形成商業合同項目的咨詢服務模塊。這同時也對咨詢顧問的學習能力和適應能力提出了更高的要求；
2. 溝通能力：體現在對行業專業知識理解基礎上的專業溝通能力。在筆者服務的項目上還多了一項語言的掌握能力上。畢竟案例中的客戶所在的領域是國內最早的合資公司；
3. 業務技能能力：這是需求分析顧問的基本功。體現Axure的掌握能力和書面的表達能力；畢竟對于需求分析師的考核KPI而言，最為直觀的反映就是產品Ddmo和PRD。
4. 演講控場能力：這是咨詢顧問的進階篇。畢竟是“十年陸軍、百年海軍”。其中，蘊含的知識沉淀、客服意識和現場控制能力并非“一朝一夕”之功所能實現。這也就是大家通常所講到的“內功”和“氣場”。

3. 解決的實施辦法結語

對于本文的標題“需求分析師勝任力之知識萃取”而言，行文之此，相信對于IT行業內的需求分析崗的主要工作已有所了解。但不免仍有遺憾。知識萃取的目的在于成果的轉化，成果的轉為的特征對于商業公司而言，無非是商業合同的誕生。

對于本文而言，成果轉化有兩個方向：其一、需求分析師培訓教案的實現；其二、需求分析師能力勝任模型的構建。

這是下一個命題了。

作者：吳虹辰；微信訂閱號：三穩人。這個訂閱號是過去十幾年來的經驗積累，也是近百個項目經驗的結晶，希望能對您有所幫助。

本文由 @吳虹辰?原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。