作為一個新項目的產品經理,該如何入手新工作?
萬變不離其宗,一個產品的誕生,需要搞清楚的問題和需要做的工作總是那么些,否則,項目必然會走很多彎路甚至夭折
假如,你是一個新項目的產品經理,你應該從哪些方面入手開始你的工作?或者說,在一個項目中,產品經理需要做的工作有哪些?
1.這個產品是干什么的?
即給產品定好位,界定好邊界。為此,需要回答如下問題:
A.做這個產品,想要達到什么目的?
通常是比較宏觀的,如降低XXX成本、提高XXX效率、通過XX方式賺取利潤等。千萬不要認為,宏觀的都是虛的,這些虛的東西,是評判產品功能設計好壞的標準。如公司建設一個ERP系統,目的是想要通過電子化辦公,提高工作效率。結果設計出來的系統,線下一步可以完成的工作,系統上要流轉七八次。沒錯,是實現了電子化,但目的達到了嗎?回答完這個問題,可輸出對產品定位的描述(給誰用來做什么?),輸出對產品商業模式的描述(怎樣賺錢?)。
B.誰會在這個系統上做什么事?
回答這個問題,就需要搞清楚,這個系統上需要進行操作的業務是什么?業務從開始到結束經歷的流程是什么?什么人在什么場景下會做什么事?確定業務邊界,明確業務細節。產出業務流程、角色分析、用例模型等文檔。搞清楚這些,你就知道:哦,我的產品是給這些人(分析獲得的用戶)用的,是讓他做XXX事情的(功能)。
2.如何實現這個產品?
知道了產品要滿足的功能、需求點(story級),就可進行分版本迭代的工作了。
每個版本迭代中,應該完成如下工作:
A.規劃第一版本
確定版本的邊界,輸出版本功能列表,并與業務部門、項目組成員就此列表進行評審,達成共識。
B.排定版本周期
根據功能列表,排定版本開發的周期,包括什么節點出需求、什么節點由誰完成什么功能(明確任務分配和里程碑)、什么時候測試、什么時候上線。
C.需求梳理和底層設計
需求是每個迭代的第一步,產品在梳理需求時,技術人員同步進行技術架構(整體架構大多在產品規劃時就完成了),數據庫等底層設計。在梳理需求的過程中,應該時刻考慮:如何設計功能才能讓用戶用更方便快速的方式完成他們想要做的事,并且達到了產品的目的(賺錢)。
D.評審需求,提交下一流程
需求梳理完了,與業務、項目組、產品部評審,評審完,修修補補,確認后,就可以交付給下一步,如交互、UI等。
E.跟蹤研發,規劃下一版本
通過站會、里程碑追蹤等方式,跟蹤項目進度,早日識別風險,如某一節點的里程碑延遲,那是不是考慮安排加班?除了進程跟蹤外,應著手準備下一版本的工作,確定版本需求、梳理版本規劃等。需求管理是迭代過程中很重要的工作,應做好真需求的識別,需求優先級的排定。
3.完成交付
經過多次版本迭代,完成項目邊界內的功能,系統即可交付或進入成熟期。這個項目的研發工作基本完結。
如上,每個項目中,至少應維護的文檔有:
- 產品規劃書:交代清楚產品的定位;為誰提供什么功能?如何賺錢?
- 需求說明書:交代產品的全部功能點,及每個功能點是干什么的;簡單幾句話描述清楚這個功能點是干什么的?
- 需求列表:正在做和將來要做的需求集合,每周維護一次;
- 原型版PRD:提交開發和測試的指導性文檔,按版本維護;應注意交代:操作、狀態、條件、功能。某個功能包含哪些操作,什么條件下才可觸發某個操作。
- 版本計劃:每個迭代的周期排定、及現有進度,按版本出具,每周維護;
- 其他:測試用例、操作手冊、培訓資料、系統使用情況等;即時維護。
誠然,每個公司、每個項目都有特殊和不同,以上所說流程和步驟并非所有項目皆如此。但萬變不離其宗,一個產品的誕生,需要搞清楚的問題和需要做的工作總是那么些,否則,項目必然會走很多彎路甚至夭折。
此外,以上只簡單介紹了項目中應該關注的問題,至于如何搞清楚這些問題,每個人、每個項目的方法有很大差異,如業務導向性的需求獲取方法更多是向業務部門進行調研;toC產品更多是競品分析,情景假設等。
本文由 @李曉霞 原創發布于人人都是產品經理。未經許可,禁止轉載。
提個問題:產品需求還沒出的階段,技術怎么做系統框架和數據庫底層設計?
非常感謝您的分享 很贊 沒有水話 都是干貨 提綱挈領 簡單明了 贊贊贊!??!
?? 謝謝肯定
厲害,
?? 謝謝~
靠譜
??