本文明確項目調研階段的工作劃分及流程，作為產品經理或者項目經理及參與項目調研的項目組成員，在調研階段的工作指導以及相關約束條件，如何高效的進行調研。通過本文所明確的管理規則，促進醫療事業部需求調研的管理更加透明、有效，為項目開發階段的設計、分析提供準確依據。

需求調研作為一種產品需求驗證的手段，在需求搜集中有著比較重要的作用，尤其是在新功能、新業務設計前以及類似方案取舍對比上。需求調研是作為產品經理/項目經理工作最關鍵的環節之一，也是項目啟動先決條件之一。

相信已經這個大家一定不會陌生。但是，在實際工作中參與者或者是企業又不太重視的一個工作環節。

因為大量的需求調研會消耗公司巨大的人力、物力，且有可能得到的需求調研結果和實際結果大相徑庭，得不到正確方向的引導，反而變成一種反向型的引導。所以一般企業會跳過這個環節去直接開展工作。

其實，最重要的是我們能不能去解決調研效率問題？

需求調研的效率和質量對于一個應用產品來說，是一個極其重要的階段，它的質量在一定程度上決定了一個軟件產品的最終交付結果。

那么如何提高產品調研的質量和效率，所以今天我們來聊一聊需求調研到底該如何高效、高質量地進行？

首先，我們要來把相關調研的規則梳理清楚，按照相關規范去執行解決相關效率。

由于文章篇幅以及產品經理如何進行需求調研的相關知識就不在這里贅述了，大家可以通過人人都是產品經理平臺去進行學習調研的交談技巧、調研表設計以及相關基礎性的硬技能。

本文明確項目調研階段的工作劃分及流程，作為產品經理或者項目經理及參與項目調研的項目組成員在調研階段的工作指導以及相關約束條件，如何高效的進行調研。通過本文所明確的管理規則，促進醫療事業部需求調研的管理更加透明、有效，為項目開發階段的設計、分析提供準確依據。

但，此規范要求主要面向軟件開發類大項目的需求調研階段，以為核心開發組提供準確、全面而有條理的現場需求為目標。為保證開發類項目調研過程完整，產品經理項目經理應該按照此過程執行。

希望產品經理或者項目經理在調研過程中再結合自己的一些特殊因素，行業經驗去豐富、去調整。

1. 應用范圍與版本說明

首先我們按照正常文檔規范去書寫這一份調研規范，讓參與者都清楚應用范圍定義，以及明確調研任務和項目名稱。

另外，還有適用對象，適用于開發部內參與需求調研工作的PMPSM運營人員實施人員開發支持人員。

同樣，對于產品經理的每一份輸出文檔來說，都必須要有版本變更的記錄，方便復盤以及觀察功能共性。

2. 參與者職責范圍

本規程用于明確醫療產品項目需求調研階段的工作職責，規范調研過程中所需遵守的規章制度、工作流程。

并且，清晰的定義參與此次調研相關人員崗位職責以及清晰分工，這個的作用是避免參與者的重復工作，分工合理的狀態去完成調研工作，提高效率。

項目經理和產品經理在項目調研過程中負責整個項目的設計以及管理，是項目調研過程的策劃和組織者，其職責包括：

• 對于組織項目啟動會，負責制定和宣導項目調研的具體工作安排，并且確定需求調研的范圍、參與者、進度。
• 調研前準備對客戶原有系統做詳細了解，特別涉及與新系統差異較大的流程和特有業務的掌握。調研前對客戶原有系統做詳細了解，特別涉及與新系統差異較大的流程和特有業務。并對系統業務的講解和客戶指導，保證客戶充分理解和掌握系統的業務流程和關鍵點。
• 設計可行的調研計劃并推進調研工作的執行。
• 在調研過程中根據軟件項目的生命周期進行控制調研進度，負責與開發人員、相關調研對象的溝通，圍繞績效和績效來確保溝通質量以及成本。
• 風險控制。
• 定期舉行項目例會，總結調研工作執行階段成果，向核管理層和參與者匯報調研工作執行情況。
• 處理好項目組、客戶、商務及核心開發組之間的關系，有效利用內外資源。
• 整理并討論需求調查表收集上來的需求，提請項目組討論確認以及評審。

核心開發支持人員的職責包括：

• 完成調研過程中的提前評審，給項目經理以業務支持，完成提前評審。
• 需求調研完成后完成整體需求的評審。
• 確定后續開發計劃并完成需求開發工作。
• 及時整理和完成《需求跟蹤矩陣》相關內容。

3. 相關附件規范

在調研規范說明之后，必須事先準備的輸出文檔就是，需求調研計劃、需求調研大綱、需求調研問卷表、軟件需求說明書、需求變更控制報告、軟件需求說明確認書，風險控制書。

接下來，就是進入到產品設計階段，這樣一來我們就可以有依據的去做需求。

關于附件文檔的一些釋義如下：

（1）《需求調研計劃》

該文檔用于調研人員到客戶現場后根據現場情況確定調研計劃使用，可以在現場啟動會后根據客戶實際安排來完成此項工作。此計劃需要通過組織者、管理層評審后方可執行。如果產品經理或者項目經理情況在調研前已經了解足夠充分，需要在公司啟動會前完成并提交部門評審，到現場后提交現場啟動會討論通過，如果現場啟動會對計劃有所更改，需再次發回公司評審。

那么對于需求調研計劃的重點我們要側重于計劃的可行性以及真實性。

（2）《需求調查表》

該文檔應用于正式調研的場景中，下發給被調研對象，在系統演示或者培訓后由調研對象以業務單元為單位集中收集并逐個需求確認。如果有條件建議該調查表以電子表格方式下發給被調研對象，并以電子文檔方式反饋調研結果，便于后續需求規格說明書的整理。

同時，產品經理/項目經理記錄“需求描述”，問題描述內容要把問題描述清楚，同時需要說明問題的性質（問題、新增需求、需求變更、需求舍棄）。

另外，還要說明問題的優先級別（高、中、低）。明確涉及工作產品”（功能名稱）及“涉及項目相關方”（哪些最終用戶）；需求調查表經過討論后需要確認該需求是放棄還是保留，放棄的需求也需要客戶確認簽字，避免客戶事后再次提起，以作為需求變更的依據。

需求調查表的內容除調研對象提出的需求描述外，還包括調研負責人拓展的相關需求進行確認。通過的報表格式、文檔等形式形成有效力的附件，產品經理復盤以及定責使用。

（3）《需求調研大綱》

該文檔用于項目組對調研工作中功能點及關鍵流程的指導，防止調研中某些關鍵流程及功能點的遺漏。項目經理及項目組成員要仔細閱讀并熟練掌握其中流程及功能點的應用，以方便項目組在調研過程中對客戶的引導和建議。

調研大綱的內容為軟件系統業務功能點的匯總，在實際工作中需要各項目組加以補充和積累，以便于對其他項目調研工作有更積極的指導意義。此大綱的豐富和積累工作要求在后續章節中重點闡述。

（4）《項目風險管理報告》

項目風險控制報告是貫穿于項目整個生命周期的風險跟蹤和評估的依據，其中的每一個風險項具備兩個狀態，發生和關閉。風險項的初始狀態為發生，產品經理及項目組成員要實時跟蹤和關注各風險項的狀態和措施的驗證，一旦根據風險得以解決或規避，項目經理需要將其狀態由發生變更為關閉，表示該風險已規避。

其中.“主要生存期”一列中填寫該風險存在的主要的階段，可分過程、活動或子活動進行明確。例如：過程——項目全過程、軟件開發過程、系統集成過程；軟件策劃過程、設計與實現過程、硬件實施過程、軟件實施過程；活動——需求分析、項目策劃、系統設計、編碼實現、軟件測試、軟件釋放、集成策劃、實施、試運行、系統驗收等；子活動：概要設計、詳細設計、代碼檢查、單元測試、功能測試、系統測試等。

如果某風險在不同的“生存期”屬于不同的“風險類型”和/或采取不同的“控制措施”，則需作為多條風險分別列出。

列在本表中的風險，只能增加不能刪減，對于已經不存在的風險，須填寫關閉標識與狀態。

（5）《變更控制報告》

變更控制報告是貫穿于項目整個生命周期的所有變更行為的評審依據，亦適用于項目需求的變更。對于已經評審通過的需求，需要項目組提交項目領導小組進行評審，并同時提交開發部評審后方可生效。對于評審通過的需求根據需求的分類，由核心開發組或現場項目組完善設計文檔后進行開發。

需求變更控制報告需要明確變更的主體及變更提出原因，如果有客戶的書面說明，則可以直接引用。此報告可附帶附頁并同時提交評審。

（6）《軟件需求規格說明書》

軟件需求規格說明書用于需求調研結束后對各業務單元所涉及需求的匯總和整理，凡是在需求規格說明書中體現的需求，均為與客戶方逐個討論確認并通過開發部提前評審的需求。軟件需求規格說明書是最后與客戶確認需求的依據，在整理完成后經過客戶和開發部最終確認后生效。

該說明書與《軟件需求規格說明書確認單》共同構成本次需求調研的最終確認成果。軟件需求規格說明書是最終項目驗收的重要依據，必須引起足夠重視。

（7）《軟件需求規格說明書確認單》

需求規格說明書確認單是與需求規格說明書同時使用，為最終確認客戶需求的匯總文檔。其中內容詳細描述部分需明確本次確認的所包含的需求規格說明書的全部清單，并簽署客戶確認意見，同時明確對于本次確認的需求變更控制辦法，不得有遺漏。

4. 調研過程規范

（1）調研啟動會

旨在確定調研階段詳細計劃、項目組織結構、人員分配等工作，明確調研流程及調研相關資料的使用及提交和確認方式。

（2）制定詳細調研計劃

結合產品實際情況，制定出詳細的調研計劃。計劃要明確調研范圍、時間進度安排、階段提交工作產品，明確調研相關業務單元及子單元負責人。計劃要做到周密嚴謹、可行性強。

調研計劃確定后提交項目領導小組和公司相關負責人評審通過后生效。

調研計劃要充分體現客戶資源的利用，安排客戶信息中心人員從需求調研開始全程參與項目。在客戶人員充足情況下要確保每一個業務單元都有信息中心人員全程跟蹤和監督，明確責任。此項工作可以使項目組人員能夠從繁瑣的客戶指導和需求整理中抽出身來，全身心的投入到需求的分析和引導工作中。

此階段用到項目調研階段規范中的《項目調研計劃》模板，從此階段開始整理《項目風險管理表》。

調研參與者要對調研對象認知差異作出準確判斷，了解和記錄特殊業務和流程，充分了解需求調研規范中的《項目調研大綱》內容及關鍵業務點。通過新舊系統的比較，拿出合理的解決方案和需求業務引導措施，保證在調研對象調研及需求討論過程中，對調研對象提出的特殊業務和需求及時準確的反饋和引導。

（3）真實場景調研規范

對于調研對象特有的需求，要充分的理解和挖掘。對于其中我們系統能夠變通實現的業務，要給予調研對象理性的分析和宣導。激勵引導調研對象詳細的描述清楚并注明提出的原因，供后續需求討論時篩選和確認。

對于我們系統欠缺的或沒有實現的業務，要充分挖掘用戶需求，不排除對用戶原系統加以仔細的研究和摸索，力求熟悉相關業務，然后仔細的整理并收集相關報表和業務資料。此項工作有利于項目的后續開發和實現，也是對我們系統版本的必要補充。

（4）需求的整理和確認

《需求調查表》收集工作完成后，由調研負責人將需求內容第一時間發回公司進行需求提前評審，避免開發確認和客戶確認出現較大分歧。

同時，調研負責人和項目相關負責人對所收集的需求進行篩選和確認。對于由公司提前評審提出的需求意見，項目組要第一時間給客戶以反饋，提交項目領導小組進行再次討論，直到得到客戶和公司開發組的最終確認。

需求調研產生的需求經過雙方討論確認后，由項目組和信息中心組織整理《軟件需求說明書》和《需求說明書確認單》。需求規格說明書的整理要尊重需求原型，做到客觀而詳盡，力求清晰明了。

《軟件需求說明書》和《需求說明書確認單》整理完成后提交項目領導小組和公司開發組審閱，經項目經理和院方領導小組相關干系人確認簽字后正式生效，作為本次調研的最終成果物。

對于調研及確認過程中放棄的需求，也要求客戶詳細的進行整理并加以確認，并注明‘放棄’字樣，防止需求的再次提起引發爭議。

5. 調研質量管理

為了保證項目調研的質量和效率，提高核心版本的有效復用率，控制項目調研的周期、質量與成本，參考公司質量管理體系，形成項目調研階段質量與安全管理規范。

為保證系統穩定和貼近客戶，提高軟件復用率，要求項目組成員對合同約定的版本有足夠的了解和掌握，避免錯誤的理解和引導客戶。

保證對客戶需求最大限度的引導和理解。對于客戶特有的需求加以合理的引導，對于本系統的規范流程最大限度的宣導和講解，尤其對本系統的亮點和優勢，加大宣導力度。

對于本系統不足的業務模塊加以詳細的整理和收集，以期通過每個項目的調研來豐富和補充我們的核心版本，達到調研的最佳效果，提高調研質量。

#專欄作家#

Rolia，微信公眾號：pmsummit，人人都是產品經理專欄作家。前?？挡┦柯摵蟿撌既思娈a品總監，涉及智慧醫療領域需求產品化5年，致力于智慧醫療領域產品體驗設計以及新商業模式研究。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

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