起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理要如何開始一個新項目？
編輯導語：如果你是一個新項目的產品經理，你應該從哪些方面著手準備你的工作？在一個項目中，產品經理需要做的工作又有哪些呢？相信這是困擾不少產品經理的問題，尤其是對于新人產品經理而言。本文作者以工單系統為例，為我們對以上問題進行了解答。
當接到一個項目時，自然而然來的一個問題是預估研發時長。
通常產品或項目人員基于自己的經驗給出預估時長，但這顯然是不合理的。項目剛提出時，由于沒有研發團隊參與項目立項，這個時候項目一般是一句話需求，不完整的，甚至是不合理的。
而這種“拍腦袋”得出的研發時長會導致后續項目開發中資源和時間不夠，最后的結果往往不盡人意。這類問題的核心是項目調研，也就是在項目開始前如何盡可能收集多且有效的信息，輔助需求分析，預估研發時間。
本篇文章以工單系統為例，說明需求調研要收集的信息，如何處理信息以及最后得到的結果，輔助給出預估的研發時長。
一、收集信息
1. 定義問題
正確定義問題就是解決問題一半，這句話可以看出定義問題的重要性，同時也說明定義問題具有一定的難度。善用方法可以事半功倍，接下來介紹兩種常見的方法。
1）轉化
轉化是指將未知的問題與已知的問題建立聯系，在這里特指將未實現的需求引導到已有的功能上。
業務人員提需求的時候都會提出一種解決方式，這自然是一個新功能，但是如果仔細分析會發現往往已有功能就可以實現業務人員的需求。這就是轉化，產品人員做好需求分析工作，將業務人員的需求轉化為已有功能，避免增加無謂的工作量。
2）本源
問題的本質往往掩蓋在眾多表象之下，只有撥開表象才能定義出真正的問題。
2. 尋找原因
在定義問題之后要尋找對應的原因，不但要關注原因還要關注各個原因所占比重，使用魚骨圖和帕累托分析法可以得出以上內容，下面具體介紹魚骨圖和帕累托分析法：
1）魚骨圖
魚骨圖又叫因果圖，是一種探尋問題的“根本原因”的分析方法。
魚骨圖實例
繪制魚骨圖的步驟如下：
- 在魚頭位置標注待解決的問題；
- 在魚骨位置標注可能的原因分類；
- 在魚刺位置標注可能的具體原因；
需要注意的是，在尋找原因類和具體原因時，要頭腦風暴盡可能多地尋找原因類和具體原因。
魚骨圖本質上是定性分析方法，好處是可以盡可能多找到可能的原因，缺點是不知道原因的重要程度，帕累托分析法正好可以解決這個問題。
2）帕累托分析
帕累托圖又叫排列圖、主次圖，是按照發生頻率大小順序繪制的直方圖，表示有多少結果是由已確認類型或范疇的原因所造成，是一種定量分析方法。
帕累托分析
如上所示，帕累托分析法的步驟如下：
- 列出解決問題的原因；
- 計算每個原因的頻率；
- 以原因為橫坐標，以頻數，頻率作為左右縱坐標分別繪制直方圖和折線圖；
帕累托分析直觀地給出了因素對結果的影響程度大小，針對性采取措施，提高效率降低成本。
3. 人員訪談
需求是有層次的，單獨對個人或某類人進行訪談無法得到完整需求，必須要梳理完整的用戶群并做針對性訪談。
一種常見的做法是對系統的利益相關者做用戶分層，然后針對性做訪談。比如可以把系統的利益相關者分為公司高管，業務管理，一線作業人員，支持人員，合作伙伴，針對分層用戶建模分析，為下一步的功能設計做好準備。
4. 確定邊界
用于實現系統的資源總是有限的，系統的功能也是有限的，系統能覆蓋的范圍自然而然也是有限的。如何定義合適的系統范圍是調研階段重要的內容之一。
比如在工單系統中，是自研客戶管理系統還是接入外部CRM系統。像這種問題要結合目的和實際情況去思考。我們服務的都是本地客戶，沒有強競品公司，而且也沒有專業的銷售團隊；同時預算不充足。
基于以上原因決定暫時不外接專業的CRM系統，只是在系統內部做一個簡單的客戶管理系統。
5. 常見約束
常見約束是指技術，使用環境，預算，政策等要求。
很多非功能性約束往往會對產品有更大的影響，收集更廣泛需求，避免遺漏需求。比如打車軟件司機端主要是在行進中的汽車使用，金融類軟件需要遵守相關法規。
二、梳理信息
1. 定下目標
好的目標要符合SMART原則，具體來說是目標必須是具體的，可衡量的，可達到的，和其他目標具有相關性，截止時間是確定的。要想清晰地定義目標，原因分析工作必須做好，也就是魚骨圖分析和帕累托要認真對待。
2. 功能拆分
在功能調研期間，功能拆分是為了后續的需求實現分析準備調研主題。
傳統的拆分方式按實體拆分，比如將交易系統拆分為商品模塊，訂單模塊，客戶模塊等。按實體拆分最大的問題是拆解出來的單個功能模塊或系統會有多個業務人員參與，由多條業務流程組成。
調研單個功能模塊或系統還要調研多種崗位人員，這不但會加大調研工作難度，也為后續的功能實現埋下隱患。
傳統劃分方式
上述是常見交易系統的傳統功能模塊劃分方法，雖然很好理解，但是產品人員在調研訂單模塊如何實現時，要同時調研商品管理或客戶管理模塊的相關內容，這導致重復的工作量，更推薦的方法是按“流程”進行功能劃分。
流程劃分
如果產品人員按此功能拆解圖去調研，那么重復訪談的現象將大大減少。由于單個功能模塊不在有多個業務角色參與，也沒有交叉業務流程，避免發生了調研時要重復調研多位業務人員的情況，大大降低調研復雜度和工作量。
3. 用戶列表
系統的用戶往往不是單一的，復雜系統甚至會有十幾種用戶角色。這一步中需要梳理系統的用戶列表，用戶列表結合功能模塊列表就可以梳理出業務事件列表。
梳理用戶列表最重要的是不重復不遺漏，可以先將用戶劃分為外部用戶、內部用戶、管理層用戶、時間和效果：
- 外部用戶是指用戶使用系統解決自己問題的角色；
- 內部用戶是協調系統或承擔一部分系統信息處理的角色；
- 管理層用戶關注系統使用效果；
- 時間是指到達特定時間會觸發的事件，比如定時器；
- 效果是指到達特定效果會觸發的事件，比如實體的狀態。
需要注意的是，以上事件是業務事件，系統還有一部分重要事件是系統事件，比如數據安全、修改密碼等，要區分看待。
4. 業務事件列表
業務事件列表是系統的目標功能，梳理正確的業務事件列表有助于正確預估產品的研發量以及研發時間。結合功能拆分和用戶列表可以梳理業務事件列表，具體做法如下：
- 用“黑河”視角看待拆分出來的功能模塊；
- 將用戶列表中的用戶與“黑盒”進行連接；
- 梳理用戶與“黑盒”的完整交互，進而梳理出業務事件；
5. 業務報表列表
根據業務事件可以梳理出業務報表，如果你對業務比較熟悉的話，這個過程可以迅速完成。報表是系統的重要組成部分。梳理完業務報表后相當于完成了大部分的系統功能設計，報表如何快速實現就不在這篇文章中說明了。
三、總結
文章簡單梳理了項目調研要收集的信息和產出的內容。項目調研的內容一定程度上決定了項目的實施成本，所以要盡可能在立項時完成，這樣才能給出合適的項目資源。
但是由于項目立項大多是管理層決定，缺少執行層參與，執行層在接到項目時必須盡可能詳細調研，收集信息，評估成本，如果資源不夠，需要申請資源或調整預期功能，這樣才能保證項目能夠準時完成。
相反的，如果接到項目就開始需求分析，研發等工作，等到臨近驗收才發現項目實現遙遙無期，那么只能自己背上這個鍋了。
作者：寶寶心里苦啊；公眾號：寶寶心里苦啊
本文由 @寶寶心里苦啊 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
- 目前還沒評論，等你發揮！
