了解項目，熟悉業務流程及背景

當你接手了一個項目時，先不要去著急了解這個產品的功能，它的用戶體驗好不好。

首先最重要的是了解這個產品屬于 B 端產品還是 C 端產品，它的受眾人群是廣大 C 端用戶還是合作公司？因為二者的本質還是有比較大的差別。

使用 B 端產品的用戶，希望通過這款產品可以將自己內部管理混亂的流程標準化，最最重要的就是可以提高人效。為了提高人效也許不會那么注重用戶體驗，更不會有一些很炫酷的交互，正如張小龍大神所說的：用完即走。因為作為 B 端產品不需要對用戶增加什么粘性。

其次需要熟悉為什么要有這個產品，打造這個產品的初衷是什么？為了解決當時的什么問題？有和沒有這個產品對實際業務有什么影響？提高人效是否可以量化（如：沒這個產品辦一件事需要1小時，有了這個產品后，辦相同的事只需要 1 分鐘）？整個產品的未來規劃是什么？

尤其是 B 端產品，要緊跟公司的戰略發展，必須熟悉了解公司當前的戰略發展是什么，最重要的戰略合作伙伴有哪些，這個產品在公司戰略發展中起到什么樣的地位。

相信對這個產品有了以上的了解后，在日后的產品需求優先級的判斷，及產品設計中會更游刃有余。

需求收集

通過對以上內容對產品的歷史及未來有了一定的了解后，接下來就要進入整個產品的初始階段：收集需求。既然是一款緊隨公司戰略發展的 B 端產品，那么高優需求一定是來自業務部門以及相關戰略合作公司。

首先收集最高優緊急的需求，也就是與當前公司戰略發展最密切相關的，根據關鍵需求梳理 MVP 主流程，同時產出流程圖。然后確認該流程圖中所涉及的角色有哪些，每個角色應該有哪些最基本的功能，才能使整個流程不阻塞，走的通。

有些 B 端產品不僅涉及到公司內部的多個部門，還涉及到公司戰略發展的合作伙伴，這時你就會發現每個部門或合作公司，都會對這個產品都會提一些自己的需求。

這時最重要的兩個問題出現了:

1. 需求提交流程規范化

當有很多部門或合作公司同時對你所負責的產品提需求時，作為 PM ，我們是需求的收集方，同時也是需求的過濾方，更是善于梳理流程的專業戶。

可以讓每個部門選出一個負責收集該產品需求的負責人，每個部門人員的需求統一提交至需求負責人處；同時，每個部門的需求負責人，再選出一個總的需求負責人，由總的需求負責人收集所有部門負責人的需求，同時過濾掉一些提交重復的需求，最后以正式的形式（郵件）交至 PM 手中。

接到需求后，PM 線下和各部門需求提交人積極溝通，了解需求背后的邏輯，需求產生的原因，自己再過濾一些偽需求。

2. 需求優先級判斷要明確

當非常多的需求到 PM 手中后，不可能所有需求都在一個版本做完，就算 PM 產品設計能做得完，但是也得問問天天加班加點的程序員哥哥愿不愿意啊～

所以，要制定重要的需求優先級排序，明確下一個版本要達成什么目標，需要什么功能，在不影響大版本發版的情況下，可以對哪些小的功能進行優化。

明確了需求優先級后，便可以進入到下一個環節— 產品設計。

通過以上行為收集了需求，并且明確了需求的優先級，對下一個版本的迭代目標有了更深的理解之外后，再補充一下需求收集中。尤其是迭代目標需要注意的幾個重點，避免踩坑：

無論任何需求傳遞到 PM 手中，都要與提這個需求的人直接溝通，而不是層層傳遞，拒絕接收二手需求（如：運營中心市場部門員工A提交需求至本部門需求負責人 B 手中，B 再將需求匯總傳遞至運營中心總需求負責人 C 手中，C 將需求傳遞至 PM，PM 需要對需求進行核實了解，應直接找到 A，而不是 B 或 C）

當 PM 收集了很多需求后，自然要結合公司發展戰略，總結出下一個版本需迭代的高優需求。既然是公司戰略層面的問題，自然少不了開會。每次開會，會議的決策人最好在場，避免以后將本次會上的所達成的結論推翻。需求高優不高優，有時就是老板一句話的事兒。并且在會議結束后，要將會議紀要同步所有相關人員，做到信息一致。

產品設計

Axure 是 PM 吃飯的家伙，你可以不會 PS，不會編程，但是 Axure 你必須得會。

我非常享受畫產品原型的時候，因為這個時候，才是 PM 真正發揮創造力的時候。此階段最重要的兩個產物，是產品原型和 PRD 文檔，產品原型決定了你的產品長什么樣，而 PRD 文檔決定了你的產品規則邏輯。

作為產品小白，剛開始畫產品原型的時候，面對一大片空白區域，真的不知如何下手，這一點我深有體會。此時不妨去看看別的產品是怎么做的，競品也好，還是當今最流行的產品也罷，真的會幫助你少踩不少坑，最好多看幾款產品，取其精華去其糟粕。

作為一款 B 端產品，要本著提高人效的心態去完成這款產品，似乎不需要多么炫酷的交互。因為這個產品的用戶是上來工作的，不會因為你一個超炫的視覺效果而愛上這個產品，從而多加加班。

但是最基本的交互是必須要的，如什么時候用浮層，什么時候用彈窗，什么時候打開一個新頁面，篩選是用下拉還是點擊，完成一件事的操作流程是否足夠簡潔等等。

界面樣式，只是這個產品的表現形式，應該對任何一個細小的功能有更多的聯想。例如一個工單列表頁，涉及到很多信息：工單提交人、工單實施人、提交工單時間、工單狀態、工單完成時間、工單所在地、工單名稱等等等等。

這里就涉及到信息展示的問題，要聯想到誰會用到這個頁面？可能是管理者要登錄后臺看自己公司的工單信息，那么他希望看到什么？可能要看看自己哪個員工又簽單了，什么時候簽的單，工單的進展如何了，并且看到這些信息之后有什么樣的操作？可能要對已完成的工單操作一下服務成功，或者把某一個進展不順利的單重新分配給自己其他員工，他希望的達到怎樣的效果？

所以要對如此多的信息進行篩選，列出操作此功能的人最關心的信息，將其不關心的信息弱化，或者在工單詳情頁去展示，并且配上可能出現的場景操作。

在產品設計中，一定要注意產品設計的細節，任何細節都不可想當然。因為研發會根據你所有的需求描述去實現產品，可能會因為一個小細節的變動，牽一發而多全身，有時只是 PM 的一句話，但是卻是研發工作的一整天。

PRD 文檔的書寫要細心，盡量要多考慮產品的邊界值，如：設置密碼，密碼的長度控制在多少位，是否需要特殊符號，大小寫是否有區分，對輸入不規范的報錯形式是怎樣，文案怎么寫能讓用戶知道自己輸錯了等等。

一些技術難題，可以拋給研發去處理，但是對于產品需求，一定要自己去構思完成。

產品開發

終于到了將自己的構思實現出來的重要一步，交付研發。其中自然少不了評（si）審（bi），我們現階段的產品評審流程為：組內評審—設計評審—和業務部門評審—研發評審—項目啟動。

如果想著研發哥哥會按照自己的產品原型和需求文檔，任勞任怨的實現出來，那你就大錯特錯了。

正式啟動研發后，還會發現之前評審沒有發現的種種問題。項目正式啟動研發后，有以下幾點總結：

每天最好以站會的形式和大家同步彼此的工作進展，因為有些研發會有多項目并行的情況，如果有影響上線時間的情況出現，那么也好做出調整，而不是后知后覺。

需求和研發成本如何取舍，根據當前項目緊迫程度做好評估。如某一個需求，研發成本比較高，那此時需判斷此需求是否影響主流程，是否屬于 MVP 功能，如果會影響主流程，非做不可，但是做了會影響上線時間，那么就要及時協調研發資源，如果又沒有多余的研發資源可供協調，那么就要考慮變更需求或聽取研發的其他建議了。如果不是影響主流程的需求，那么就要根據當前項目緊迫程度做好評估，是否可以將此需求延遲至下一個版本。

如有延期上線風險，合理調動研發資源。

盡量考慮周全所能遇到的場景，以便研發設計技術框架。

我所用到的項目管理工具是 jira，會在每一次的項目啟動后建立相關的用戶故事和任務，任務分配給各自負責的研發就好，用戶故事可以存放原型和 PRD 文檔。

測試環節

辛苦的程序猿哥哥通過加班加點的寫代碼，終于通過了聯調，將自己的代碼部署到了測試環境，那么就該測試和 PM 上場了。

測試評審盡量叫上相關研發人員，可以作為產品實現是否正確的二次確認。并且評審要細致，將各個功能的不同操作所導致的結果考慮情況全面，歸根結底還是 PRD 文檔要書寫全面，因為測試同學會根據 PRD 文檔來寫測試 case。沒錯，一切都是產品的鍋。

每一次新版本的迭代，不僅要測試新增加的功能是否有 bug，還是測試產品的主流程是否受到本次迭代的影響。

關于 bug，我認為兩種非常緊急且重要：

阻塞性 bug

影響業務的 bug

阻塞性的 bug 自然不用多說，例如你用微信聊天，信息發不出去；用攜程買機票，沒法兒出票。

而影響業務的 bug 是指：用攜程買機票，本來機票 1000 塊，但是用戶 1 塊就買到了，這個 bug 不屬于阻塞性，但是卻影響重大。

產品上線

我們產品上線的流程為：研發提交上線申請 — 測試回復測試通過并且展示 bug 處理情況—產品驗證是否通過—產品上線—產品發 release 郵件周知老板們及項目成員。

產品上線意味著兩件事：

可以進入到下一個版本迭代的工作當中了。

對本次上線的產品功能負責。

在此主要整理一下產品上線后的注意事項：

尤其是一款 B 端產品，一定要在產品上線前幾天，對公司內部用到該產品的所有部門進行相關培訓，并且編寫產品功能使用手冊及時同步大家。

線上回歸測試，收集 bug，嚴重 bug 緊急修復；影響不大的 bug 可以考慮到下一個版本迭代修復。

收集用戶的使用反饋，對體驗不好的功能進行優化。

數據監測，最好通過線上數據，可以給業務部門一些指導性的建議。