產品經理要如何開始一個新專案？

當接到一個專案時，自然而然來的一個問題是預估研發時長。

通常產品或專案人員基於自己的經驗給出預估時長，但這顯然是不合理的。專案剛提出時，由於沒有研發團隊參與專案立項，這個時候專案一般是一句話需求，不完整的，甚至是不合理的。

而這種“拍腦袋”得出的研發時長會導致後續專案開發中資源和時間不夠，最後的結果往往不盡人意。這類問題的核心是專案調研，也就是在專案開始前如何儘可能收集多且有效的資訊，輔助需求分析，預估研發時間。

本篇文章以工單系統為例，說明需求調研要收集的資訊，如何處理資訊以及最後得到的結果，輔助給出預估的研發時長。

一、收集資訊1. 定義問題

正確定義問題就是解決問題一半，這句話可以看出定義問題的重要性，同時也說明定義問題具有一定的難度。善用方法可以事半功倍，接下來介紹兩種常見的方法。

1）轉化

轉化是指將未知的問題與已知的問題建立聯絡，在這裡特指將未實現的需求引導到已有的功能上。

業務人員提需求的時候都會提出一種解決方式，這自然是一個新功能，但是如果仔細分析會發現往往已有功能就可以實現業務人員的需求。這就是轉化，產品人員做好需求分析工作，將業務人員的需求轉化為已有功能，避免增加無謂的工作量。

2）本源

問題的本質往往掩蓋在眾多表象之下，只有撥開表象才能定義出真正的問題。

2. 尋找原因

在定義問題之後要尋找對應的原因，不但要關注原因還要關注各個原因所佔比重，使用魚骨圖和帕累託分析法可以得出以上內容，下面具體介紹魚骨圖和帕累託分析法：

1）魚骨圖

魚骨圖又叫因果圖，是一種探尋問題的“根本原因”的分析方法。

魚骨圖例項

繪製魚骨圖的步驟如下：

1. 在魚頭位置標註待解決的問題；
2. 在魚骨位置標註可能的原因分類；
3. 在魚刺位置標註可能的具體原因；

需要注意的是，在尋找原因類和具體原因時，要頭腦風暴儘可能多地尋找原因類和具體原因。

魚骨圖本質上是定性分析方法，好處是可以儘可能多找到可能的原因，缺點是不知道原因的重要程度，帕累託分析法正好可以解決這個問題。

2）帕累託分析

帕累託圖又叫排列圖、主次圖，是按照發生頻率大小順序繪製的直方圖，表示有多少結果是由已確認型別或範疇的原因所造成，是一種定量分析方法。

帕累託分析

如上所示，帕累託分析法的步驟如下：

1. 列出解決問題的原因；
2. 計算每個原因的頻率；
3. 以原因為橫座標，以頻數，頻率作為左右縱座標分別繪製直方圖和折線圖；

帕累託分析直觀地給出了因素對結果的影響程度大小，針對性採取措施，提高效率降低成本。

3. 人員訪談

需求是有層次的，單獨對個人或某類人進行訪談無法得到完整需求，必須要梳理完整的使用者群並做針對性訪談。

一種常見的做法是對系統的利益相關者做使用者分層，然後針對性做訪談。比如可以把系統的利益相關者分為公司高管，業務管理，一線作業人員，支援人員，合作伙伴，針對分層使用者建模分析，為下一步的功能設計做好準備。

4. 確定邊界

用於實現系統的資源總是有限的，系統的功能也是有限的，系統能覆蓋的範圍自然而然也是有限的。如何定義合適的系統範圍是調研階段重要的內容之一。

比如在工單系統中，是自研客戶管理系統還是接入外部CRM系統。像這種問題要結合目的和實際情況去思考。我們服務的都是本地客戶，沒有強競品公司，而且也沒有專業的銷售團隊；同時預算不充足。

基於以上原因決定暫時不外接專業的CRM系統，只是在系統內部做一個簡單的客戶管理系統。

5. 常見約束

常見約束是指技術，使用環境，預算，政策等要求。

很多非功能性約束往往會對產品有更大的影響，收集更廣泛需求，避免遺漏需求。比如打車軟體司機端主要是在行進中的汽車使用，金融類軟體需要遵守相關法規。

二、梳理資訊1. 定下目標

好的目標要符合SMART原則，具體來說是目標必須是具體的，可衡量的，可達到的，和其他目標具有相關性，截止時間是確定的。要想清晰地定義目標，原因分析工作必須做好，也就是魚骨圖分析和帕累託要認真對待。

2. 功能拆分

在功能調研期間，功能拆分是為了後續的需求實現分析準備調研主題。

傳統的拆分方式按實體拆分，比如將交易系統拆分為商品模組，訂單模組，客戶模組等。按實體拆分最大的問題是拆解出來的單個功能模組或系統會有多個業務人員參與，由多條業務流程組成。

調研單個功能模組或系統還要調研多種崗位人員，這不但會加大調研工作難度，也為後續的功能實現埋下隱患。

傳統劃分方式

上述是常見交易系統的傳統功能模組劃分方法，雖然很好理解，但是產品人員在調研訂單模組如何實現時，要同時調研商品管理或客戶管理模組的相關內容，這導致重複的工作量，更推薦的方法是按“流程”進行功能劃分。

流程劃分

如果產品人員按此功能拆解圖去調研，那麼重複訪談的現象將大大減少。由於單個功能模組不在有多個業務角色參與，也沒有交叉業務流程，避免發生了調研時要重複調研多位業務人員的情況，大大降低調研複雜度和工作量。

3. 使用者列表

系統的使用者往往不是單一的，複雜系統甚至會有十幾種使用者角色。這一步中需要梳理系統的使用者列表，使用者列表結合功能模組列表就可以梳理出業務事件列表。

梳理使用者列表最重要的是不重複不遺漏，可以先將使用者劃分為外部使用者、內部使用者、管理層使用者、時間和效果：

• 外部使用者是指使用者使用系統解決自己問題的角色；
• 內部使用者是協調系統或承擔一部分系統資訊處理的角色；
• 管理層使用者關注系統使用效果；
• 時間是指到達特定時間會觸發的事件，比如定時器；
• 效果是指到達特定效果會觸發的事件，比如實體的狀態。

需要注意的是，以上事件是業務事件，系統還有一部分重要事件是系統事件，比如資料安全、修改密碼等，要區分看待。

4. 業務事件列表

業務事件列表是系統的目標功能，梳理正確的業務事件列表有助於正確預估產品的研發量以及研發時間。結合功能拆分和使用者列表可以梳理業務事件列表，具體做法如下：

1. 用“黑河”視角看待拆分出來的功能模組；
2. 將使用者列表中的使用者與“黑盒”進行連線；
3. 梳理使用者與“黑盒”的完整互動，進而梳理出業務事件；

5. 業務報表列表

根據業務事件可以梳理出業務報表，如果你對業務比較熟悉的話，這個過程可以迅速完成。報表是系統的重要組成部分。梳理完業務報表後相當於完成了大部分的系統功能設計，報表如何快速實現就不在這篇文章中說明了。

三、總結

文章簡單梳理了專案調研要收集的資訊和產出的內容。專案調研的內容一定程度上決定了專案的實施成本，所以要儘可能在立項時完成，這樣才能給出合適的專案資源。

但是由於專案立項大多是管理層決定，缺少執行層參與，執行層在接到專案時必須儘可能詳細調研，收集資訊，評估成本，如果資源不夠，需要申請資源或調整預期功能，這樣才能保證專案能夠準時完成。

相反的，如果接到專案就開始需求分析，研發等工作，等到臨近驗收才發現專案實現遙遙無期，那麼只能自己背上這個鍋了。

作者：寶寶心裡苦啊；公眾號：寶寶心裡苦啊

本文由 @寶寶心裡苦啊 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

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