《項目經理指導手冊》 調研篇
需求調研是項目經理的必備技能，也是掌握項目成功失敗的關鍵。
需求分為四類：業務需求，用戶需求，功能需求，非功能需求。比如造一輛車，那么就可以按以下方式分解。
1，業務需求：
（1）要是個小轎車，四輪小轎車。
（2）這輛車一箱油要能跑800公里以上.
2，用戶需求：
（1）要有收音機，能聽電台。
（2）要有沙發，沙發要軟。
3，功能需求：
（1）要跑的快，百公里加速7秒以內。
（2）要能越野能力，有四輪驅動。
4，非功能需求：
（1）保養費用要低一點，最好每五千公里保養不超過500塊錢。
（2）質量要好，能開10年以上。
而在做軟件項目的時候，我們如何挖掘出這四類需求呢？ 這就要具備一定的調研技巧。我總結了7種軟件系統調研手段。
一，訪談法：
訪談，是調研活動中最常用也是最簡單的方法，但是很多訪談卻是無效的。我見過很多人調研的時候，事前沒有做任何准備，就跑過去問客戶：“你有什么需求？” 。
我自己也經常犯這樣的錯誤，我常說的一個例子： “你問一個沒有駕照的人，想買一輛什么樣的車。他會思考片刻后告訴你，來個紅色的吧！” 尤其在上新系統的時候，
客戶對軟件系統的認知水平是很低的，所以這種方法，就是無效訪談。
訪談，作為最常用的調研方法，卻是要做最多准備工作的，一般我們需要緊扣業務部門 或 客戶的痛點。而工作之中的“痛點” 基本來源於 績效 和 成本 兩個方面。
也就是我們說的 ”提升效率“ 和 ”降低成本“。 故此，在調研之前應該先列一份 訪談題目列表。好比電視里的訪談節目，一定是先把訪談腳本列出來，然后按流程訪談的。
另外關於 在提效 和 降本 兩個方面。 我們應該本着一顆幫助業務部門的心態去思考問題。
拿降低成本舉例，我曾無數次的見過，項目經理或產品經理在做調研的時候，把降低成本理解為減少多少個人工。這個對上可以，對下項目經理應該刻意避開這個成本。
項目一開始就跟業務部門講，這個項目如何如何好，你們部門現在8個人，上了我們系統之后就只需要3個人就行了。 業務部門的人不會認為這個系統好，他只會想這要裁掉
的5個人是不是我？
所以，在訪談的時候，應該本着一顆實際幫助別人的同理心去做訪談。告訴他們拿着掃把掃地 和 開着清潔車掃地 的差異。 同時，訪談需要及時的做好記錄，這里如果條件
允許，我推薦試用錄音筆或手機錄音。現場不要因為記錄耽誤太多訪談時間，回來再進行整理分析。
二，問卷法：
問卷，通常用於調研對象較多時的一種大面積調研手段。共分為5個步驟：設計，分發，收集，分析，結論。
設計問卷，要盡量避免使用生僻的用語，比如縮寫、俗語等，要具體的提出問題，不要模糊。在做問卷時，盡可能以選擇題的
方式呈現，在題型的設計上，通常建議選擇題與問答題的比例為9比1。 簡單、容易的問題放在前面，問題排序要有關聯，符合邏輯，方便填卷人合作並產生興趣。
問卷設計一般由三部分組成：
1，前言，一般包含:目的，意義，調研對象。
2，主體內容，單選題，多選題，問答題。
3，結束語，表達對調研對象的感謝。
如果是對產品，系統，服務調研，最后在問卷最后加打分項，讓調研對象進行評分，以方便做問卷統計分析。
分發問卷，我們可以選擇線上 和 線下兩種方式，線下即將問卷打印出來，挨個分發到調研對象手中，這種方式的優點是確保調研對象確保收到 調研訊息，並可當面獲得參與調研
的承諾，但是缺點是分發效率較慢。
線上則是利用互聯網平台如：問卷星，騰訊問卷等方式，在線分發問卷。優點是分發快，統計效率高，一般問卷平台會幫我們做完基礎統計。 缺點就是不能確保調研對象都能參與，
需要二次確認。
收集問卷，是問卷調查中非常耗時的一項工作，需要將每道題目都進行選項 或 內容進行 分類占比統計，其目的在於統計收集來的信息分門別類后，給后續做問卷分析做基礎數據。
統計的方式，我們可以采用各類圖表的方式如： 餅圖、曲線圖、條形圖、雷達圖。 盡可能的將數據以直觀的形式呈現。
分析問卷，根據統計而來的數據分析， 分析方式通常可以用：四象限法、SWOT分析等方式進行。分析出來的結果可以以PPT的方式進行呈現。分析時應當注意將不同層次的人群分開
分析，比如，高層領導、中層管理關、底層執行 分別關注的是什么？基於數據做出分析，基於分析做出結論。
問卷結論，是對本次調研做出客觀判斷，以及歸納總結。 總結后，轉換成可執行事項， 針對事項，制定任務計划。並對問卷進行最總匯報。
三，單據法：
單據法是在調研過程中的一種信息收集手段。單據法與流程法相輔相成，單據法是去各部門收集部門的各類單據，包括不限於：工單，報表，發票。單據法的目的在於根據單據的內容
來分析系統應該具備哪些模塊、功能、字段。單據法不是單一的調研手段，往往配合與訪談法，流程法一起使用。
單據法，流程分為三步：
1，收集單據。收集單據之前需要先找到項目關鍵干系人，以及業務流程入口。單據是結合流程的，如同對流程的處理。在搜集單據的時候，我們除了要關注單據本身以外，也需要記錄下來，單據所涉及的部門以及人員。
這些部門和人員會是我們反復調研的對象。此外，單據所涉及的工作大多是有關聯性的，比如：發票與對賬單，對賬單與財務報表 等，這里可以單據干系人溝通 單據是否可以並，是否需要拆分，哪些可以利用系統來自動計算。
故此收集單據，不僅僅是單據本身，同時也要關注，單據對應的業務，以及執行業務工作者的訴求。
2，單據分類。單據收集后，我們要對單據進行有效的分類，通常分類方式有兩種。一種是職能屬性分類，比如行財務部門的單據，就按該部門所有經受要處理的單據，都分一類，我稱這種為垂直分類。
第二種方式是，按流程分類，比如報銷流程，這個流程種所有需要流轉的單據，分為一類，我稱這種為水平分類。 並是，按垂直分之后就不用按水平分類了，如果時間充裕，可以把兩種分類都做一下，會看到不同的結果。
垂直分類，促進的是部門改善，水平分類促進的是流程改善。
3，分析數據。每張單據都會涉及到數據，哪些數據是必須填寫的，哪些是可以固定做為選項，哪些是需要在一級表單就要列出的字段，哪些是需要詳情中去顯示的。對於單據內容的分析和整理是為了優化報表結構。
大部分的報表可以集中到少數報表中來，可以省去許多重復查詢的麻煩。從一定種程度上來說，表單數據分析做完之后，整個系統的表數據結構、核心字段，就基本出來了。
單據法是系統類軟件調研必須要經過的調研手段，我們在試用單據法的時候，最容易范的錯誤是單據不全。 要收集完一個部門或者是一個核心流程的單據，其實是一個非常繁重的工作量，往往在調研中容易出現，收集
一兩張表單后，其他表單就靠推斷，片面的認為其他小單據不重要，這個觀點是單據法最大的忌諱。往往決定項目成敗的是那些容易忽略的細節。
四，流程法：
流程法，顧名思義就是將業務流程進行梳理。首先，要做的事情就是輸出流程圖。常用的流程工具有Visio，Processon，這里我們統一使用Visio作為畫圖工具。流程圖有四種類型
1，過程流程圖，用以說明流程的工作方式，或計划方式。（如：起床去上班）
2，工作流程圖，用以顯示業務或流程的運作方式。（如：OA中請假審批流程）
3，涌道流程圖，也叫職能流程圖，用以顯示多個組織單位信息流轉。（如：物料采購流程）
4，數據流程圖，用以顯示數據處理方式。（如：系統支付流程）
這四種方式種，在不同類型的軟件領域，梳理流程的類型優先順序略有不同，我們做內部系統率先梳理的是，應該職能流程圖。
繪制流程圖時，需要避免將所有流程繪制在一張圖中，拿MES系統來舉例，“工單派工”是一個流程，“工單報工”也是一個流程。我們可以把軟件流程理解為各個流程單元的集合。
先將流程分解到最小流程單元，將每個業務流程做精細化的梳理。合格的流程圖是應該各個 流程單元，最終能連接到一起，組成全局流程。但是 單獨分析的是時候流程是正常合理的。
一定要避免“一葉障目” 這是使用流程法的一個大忌。
其次，繪制最小流程單元之后，我們應該對流程進行小心求證。多數時候，業務部門是有對應的工作流程，但是真實的工作情況，卻不按流程辦事。這里就引申出另一個問題，系統的實施
是否需要對流程進行再造，不按流程辦事涉及到流程是否合理。這也決定了我們上系統究竟是目的是“固化流程”還是“改造流程”。 因此當流程圖繪制到一定程度，我們應該反復的去跟業務部門
進行溝通，一來二往才能挖掘出客戶需求。
通常來說，沒有流程的部門，應該先與業務部門一起建立流程，是否有軟件系統，並不影響流程的執行。先流程，后系統。這個順序不能改變。沒有流程，即便上了系統也不會有流程。有流程
即便拿紙質單據也能讓流程鄭超運作下去。軟件系統只能幫助規范流程。
最后，就是流程對接。一個企業的信息化建設，不會只依賴一個系統，流程知否能順序執行下去，除了該系統本身是否運作正常，還要看與其他系統的協同作業。 系統本質來說就是各種流程的載體。
當我們的流程梳理清晰的時候， 其實就可以去，與不同的系統進行連接。 這里即可檢測出來，各個流程的缺陷。同理，當流程梳理完成時，系統的框架設計已經完成了十之七八。
五，原型法：
原型法，是在流程法的基礎之上，將系統軟件具象化。如果流程都已經清晰，那原型自然就可以呈現出來，一般原型設計是由“產品經理”完成，但是在制造業往往產品經理和項目經理身份是有重疊。
所以項目經理，必須具備原型設計的能力。（原圖工具推薦使用：Axure 和 墨刀）
前面在訪談法中舉例說過，我們在跟用戶溝通的時候，往往要不就是天馬行空，要不就是沒有想法。原型法的則是引導用戶交流需求的重要手段，這就如同幼兒園的小朋友， 你一張白紙說畫一匹馬他可能
畫的亂七八糟，或者壓根不知道畫成了什么樣子。但是 給一個輪廓，他會自己填上鮮艷的色彩。故此，原型法能幫助客戶具象化系統，統一軟件認知，也是溝通需求時項目目標一致化的高效手段。
原型法，相比其他調研手段，是必要的，也是強制要求必須要做的。若軟件開發選用瀑布型，則快速原型模型能克服瀑布的缺點，減少由軟件需求不明確帶來的開發風險，互動性更高，更了解客戶需求，反復循環。
若是采用敏捷型，原型則是每次迭代評審會的核心評審內容。
特別注意，在使用原型法的時候，通常容易犯的兩個錯誤：
1，追求細節，追求大而全。比如：
（1）做表單原型時，將所有字段都羅列在表單中。
（2）寫非常多的文字說明，把原型圖當初需求分析文檔。
2，干擾設計，追求美觀。比如：
（1）原型設計時，給原型上各種顏色為了美觀。
（2）反復調整頁面布局，覺得用戶體驗不夠。
我曾見過很多人的原型設計做比美工的UI更精致的，不管組織內有沒有美工，都不應該去做這些事情。有的甚至把一些條款都一字不落的做到原型里面。其實這樣既耽誤時間，又影響設計。
原型法應該回歸本質，而本質就是“具象化”需求。
六，體驗法：
體驗法，最快捷的實踐方式就是輪崗。只有身處其中才能感受到其崗位所對應的流程，以及該崗位的切身痛點。
輪崗要需要注意以下幾點：
1，輪崗目的要確定。目的是通過內部崗位輪換，增強員工對公司各部門的工作流程認知。
2，輪崗部門與崗位要確定。我們需要將輪崗的部門和崗位進行必要的匯總和分析，做出一個表格，以方便輪崗計划的實施。
3，輪崗周期要確定。參與輪崗需要多長時間？時間到了，到下個崗位或者部門輪崗時如何銜接？如果條件允許輪崗建議2周以上，若條件不允許輪崗應當不低於一周。
七，對比法：
對比法，是相對調研信息已經相對充足的情況下使用的一種調研手段。有兩種方法去執行：
1，企業對比，即尋找業態相似的企業，或直接競爭對手做對比。注意此處的前置條件是對自身企業調研信息相對充足的情況下去對比，而不是照抄同行業務。我們都知道抄作業的方式優點是快速復制同行的優勢點。
但是，同時也會把劣勢點照搬過來。所以，這里強調的是“對比”，而不是“copy”。
直接競爭對手的調研，需要做一些商業情報，相對難度會大一點。 而尋找同類型的企業則相對容易很多，我們可以將企業特征做分類，比如：大類划分： 離散型 與 流程型 ，小類划分 ：食品制造、家具制造等。 划分分類后即可作為
篩選目標對象，以做到觸類旁通。 我們所在的離散型鋰電設備裝配制造企業，就可以去尋找汽車組裝企業，發動機生產企業等等，作為對比對象。
2，系統對比，即尋找市面上符合需求軟件系統做對比。普遍的做法是尋找軟件供應商，這里可以將供應商分為三類： 行業頂尖，國內頂尖，國際頂尖。需要注意的是：每個“頂尖”最多挑選3家， 三輪下來也就是最多9家供應商。這樣避免
看的太多，反而增加了系統的復雜度，也就是“挑花了眼”。
故此，需要再次強調，對比法是調研方法中最后一個方案， 不是必須要用的手段。但是確定要用的話，先一定已經做過一輪充足的內部調研，初步方案已經形成了，對比法只能用來補充調研中哪些沒有考慮到的細節，萬不可生搬硬套。