作為一個新項目的產品經理,該如何入手新工作?

7 評論 36999 瀏覽 300 收藏 7 分鐘

萬變不離其宗,一個產品的誕生,需要搞清楚的問題和需要做的工作總是那么些,否則,項目必然會走很多彎路甚至夭折

假如,你是一個新項目的產品經理,你應該從哪些方面入手開始你的工作?或者說,在一個項目中,產品經理需要做的工作有哪些?

1.這個產品是干什么的?

即給產品定好位,界定好邊界。為此,需要回答如下問題:

A.做這個產品,想要達到什么目的?

通常是比較宏觀的,如降低XXX成本、提高XXX效率、通過XX方式賺取利潤等。千萬不要認為,宏觀的都是虛的,這些虛的東西,是評判產品功能設計好壞的標準。如公司建設一個ERP系統,目的是想要通過電子化辦公,提高工作效率。結果設計出來的系統,線下一步可以完成的工作,系統上要流轉七八次。沒錯,是實現了電子化,但目的達到了嗎?回答完這個問題,可輸出對產品定位的描述(給誰用來做什么?),輸出對產品商業模式的描述(怎樣賺錢?)。

B.誰會在這個系統上做什么事?

回答這個問題,就需要搞清楚,這個系統上需要進行操作的業務是什么?業務從開始到結束經歷的流程是什么?什么人在什么場景下會做什么事?確定業務邊界,明確業務細節。產出業務流程、角色分析、用例模型等文檔。搞清楚這些,你就知道:哦,我的產品是給這些人(分析獲得的用戶)用的,是讓他做XXX事情的(功能)。

2.如何實現這個產品?

知道了產品要滿足的功能、需求點(story級),就可進行分版本迭代的工作了。
每個版本迭代中,應該完成如下工作:

A.規劃第一版本

確定版本的邊界,輸出版本功能列表,并與業務部門、項目組成員就此列表進行評審,達成共識。

B.排定版本周期

根據功能列表,排定版本開發的周期,包括什么節點出需求、什么節點由誰完成什么功能(明確任務分配和里程碑)、什么時候測試、什么時候上線。

C.需求梳理和底層設計

需求是每個迭代的第一步,產品在梳理需求時,技術人員同步進行技術架構(整體架構大多在產品規劃時就完成了),數據庫等底層設計。在梳理需求的過程中,應該時刻考慮:如何設計功能才能讓用戶用更方便快速的方式完成他們想要做的事,并且達到了產品的目的(賺錢)。

D.評審需求,提交下一流程

需求梳理完了,與業務、項目組、產品部評審,評審完,修修補補,確認后,就可以交付給下一步,如交互、UI等。

E.跟蹤研發,規劃下一版本

通過站會、里程碑追蹤等方式,跟蹤項目進度,早日識別風險,如某一節點的里程碑延遲,那是不是考慮安排加班?除了進程跟蹤外,應著手準備下一版本的工作,確定版本需求、梳理版本規劃等。需求管理是迭代過程中很重要的工作,應做好真需求的識別,需求優先級的排定。

3.完成交付

經過多次版本迭代,完成項目邊界內的功能,系統即可交付或進入成熟期。這個項目的研發工作基本完結。

如上,每個項目中,至少應維護的文檔有:

  • 產品規劃書:交代清楚產品的定位;為誰提供什么功能?如何賺錢?
  • 需求說明書:交代產品的全部功能點,及每個功能點是干什么的;簡單幾句話描述清楚這個功能點是干什么的?
  • 需求列表:正在做和將來要做的需求集合,每周維護一次;
  • 原型版PRD:提交開發和測試的指導性文檔,按版本維護;應注意交代:操作、狀態、條件、功能。某個功能包含哪些操作,什么條件下才可觸發某個操作。
  • 版本計劃:每個迭代的周期排定、及現有進度,按版本出具,每周維護;
  • 其他:測試用例、操作手冊、培訓資料、系統使用情況等;即時維護。

誠然,每個公司、每個項目都有特殊和不同,以上所說流程和步驟并非所有項目皆如此。但萬變不離其宗,一個產品的誕生,需要搞清楚的問題和需要做的工作總是那么些,否則,項目必然會走很多彎路甚至夭折。

此外,以上只簡單介紹了項目中應該關注的問題,至于如何搞清楚這些問題,每個人、每個項目的方法有很大差異,如業務導向性的需求獲取方法更多是向業務部門進行調研;toC產品更多是競品分析,情景假設等。

 

本文由 @李曉霞 原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 提個問題:產品需求還沒出的階段,技術怎么做系統框架和數據庫底層設計?

    來自北京 回復
  2. 非常感謝您的分享 很贊 沒有水話 都是干貨 提綱挈領 簡單明了 贊贊贊!??!

    來自上海 回復
    1. ?? 謝謝肯定

      來自廣東 回復
  3. 厲害,

    來自重慶 回復
    1. ?? 謝謝~

      來自廣東 回復
  4. 靠譜

    來自北京 回復
  5. ??

    來自北京 回復