實戰第三步:從需求池到確認需求的全過程

22 評論 44041 瀏覽 339 收藏 10 分鐘

說在前面的話:上兩篇文章講了市場調研、競品分析,肯定收集了一堆的需求,那么我們怎么去分析這些需求了?從哪些維度去分析?接下來這篇文章主要是說一下我個人對做需求分析的一些方法和步驟。

需求分析是整個項目計劃階段的重要活動,也是軟件生存周期中的一個重要環節,該階段是分析系統在功能上需要“實現什么”,而不是考慮如何去“實現”。

需求分析的目標是把用戶對待產品提出的“要求”或“需要”進行分析與整理,確認后形成描述完整、清晰與規范的文檔,確定軟件需要實現哪些功能,完成哪些工作。

此外,軟件的一些非功能性需求(如:軟件性能、可靠性、響應時間、可擴展性等),軟件設計的約束條件,運行時與其他軟件的關系等也是軟件需求分析的目標。

上面這張基本就是講大道理的,接下來這張圖是我整篇文章的分析步驟:

第一步:整理需求池

首先我們來看下面一張圖,看看需求的來源有哪些:

在通過上面的各種需求的收集,會收集一堆的需求,俗稱需求池。在收集的過程中,記錄需求大部分都是先拿筆記本記錄,最后在匯總到電腦里面,所以會很分散,這個時候需要一張表格來規范所有的需求,做成一個列表。

示例如下:

列表字段:編號、需求分類、需求描述、場景描述、需求來源、提出時間、是否解決、優先級、備注。

文檔說明:

(1)需求分類:一般需求可以劃分為五類。

(2)場景描述:主要描述需求發生的場景。

(3)需求來源:主要是記錄需求產生的方式。

(4)優先級:這個地方我用的是我司的優先級排列方式,P0最高、P4最低。這個地方可以靈活處理,換成自己公司的就可以了。

(5)備注:一般用于抒寫,不解決的原因。和如果解決需要注意什么。

分析方法:需求分析自己分析需求的方法我沒有寫,因為網上有一堆講這種自我分析需求的方法。

這兩篇文字是人人都是產品經理專欄作家@吳邢一夫的文章,感興趣的可以點擊看看,我文章只是講述怎么讓需求落地。

深度丨從上帝視角審視產品需求(上)

深度丨從上帝視角審視產品需求(下)

其他說明:

一般產品都會分為用戶端與后臺,所以在做Excel表格的時候,需要分為兩個模塊,分別列對應平臺的需求。這樣會讓各個平臺的需求清晰明了。開需求大會的時候,分平臺的評審需求。

第二步:需求大會

匯總完所有的需求到需求池,這個時候產品經理就需要組織需求大會了,邀請相關同事參會,討論V1.0版本需要做哪些需求。

參會的人員:相關領導、項目經理、產品相關人士(產品汪、產品助理、產品專員)、研發leader、運營。

會議時長:2-4個小時。

會議記錄:產品經理。

會議說明:

(1)這種需求大會,會針對每一個需求進行探討,V1.0版本做與不做,所以會議時長一般會很長。產品經理需要對每一個討論過的需求標記優先級,是否需要第一個版本實現做備注,延后處理的需求,需要標明延后原因等等。一般都是在我之前列表的需求池列表的后面做處理。

(2)針對需求一般會圍繞以下幾個維度進行討論:

第三步:初稿需求整理

會議結束,產品經理需要做的事情,就是把需求池列表的需求進行過濾,把V1.0版本初步需要做的需求進行進行一個需求的整理,單獨做成V1.0需求列表。

我簡單做了一個需求列表的Excel的表格,僅供參考:

列表字段:編號、所屬模塊、子模塊、需求描述、場景描述、優先級、備注。

備注說明:分別把前端和后臺的需求分開列。這樣展示會更清晰明了。

第四步:V1.0需求確認會

匯總完所有的V1.0需求,又是產品經理主持會議的時候到了,這次的會議室確定上一次會議的確定下來的版本需求。

參會的人員:相關領導、項目經理、產品相關人士(產品汪、產品助理、產品專員)。

會議時長:1個小時左右。

會議記錄:產品經理。

會議說明:

(1)確認需求的過程中一般又會爆發新的一輪需求的討論,別問為什么。(上次討論需求的腦細胞已經死亡了,新的腦細胞又會有新的意見。)

(2)產品需要記錄這次會議上針對需求提出來的一些討論結果的記錄。

第五步:最終需求表

有些公司需求的確認會,需要經過很多次的需求會議,才會確認下來。本文只是理想化的做了2次,但是不管經歷了幾次需求確認會,都會走到最終定下來的這一稿。

我簡單做了一個最終需求列表的一個Excel表格,表格如下:

列表字段:編號、所屬模塊、子模塊、需求描述、場景描述、優先級、產品負責人、完成時間、預計用時、對應開發人員、完成情況。

備注說明:

  1. 產品負責人字段:有些公司一個產品是多個產品經理負責,所以需要寫上對面模塊的產品負責人,這樣在后期開發的過程中,開發有問題可以直接找到對應模塊的負責人。
  2. 完成時間一般都是在需求定下來的時候就可以大概定下來的。
  3. 預計用時、對應開發人員、完成情況。這些是在幫研發leader做的了,leader拿到表就可以開研發內部任務分配會議了。

題外話:研發leader拿到這個需求列表后,召開研發的會議,然后分配任務給對應的開發人員,就可以直接在頁面天對應的天數、開發人員了。

結尾

本篇文章講解了產品從匯總需求池到需求確認的整個過程,接下來的一篇文章,會全面講解我們在做0到1的產品需要輸出哪些產物。

相關閱讀

實戰第一步:市場調研

實戰第二步:如何做一份有針對性的競品分析

下一篇:【第四步】產品輸出,敬請期待

 

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

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 好期待第四部大作!

    來自廣東 回復
    1. 失聯一段時間,已經發布啦

      來自廣東 回復
  2. 我們是把需求池建在worktile上,方便直接討論或貼附件溝通清楚需求是什么, 需求狀態一發生變化也會即時通知到相關的人

    來自北京 回復
    1. 形式很多種,多人協作時,這個worktile是可以的,類似工具很多。我最近愛上用石墨了

      來自廣東 回復
  3. 好文

    來自河南 回復
    1. 謝謝

      來自廣東 回復
  4. 期待大神的第四步,能系統地學習整個過程

    來自貴州 回復
    1. 哈哈哈,期待你的成長

      來自廣東 回復
  5. 有質量的文章

    來自四川 回復
    1. 感謝 ??

      來自廣東 回復
  6. 我也是在等您的第四步,哈哈

    來自廣東 回復
    1. 實在抱歉,文章更新慢,現在才更新到第五篇

      來自廣東 回復
  7. 啥時候出第四步~

    來自山西 回復
    1. 項目太忙,可能會晚點

      回復
    2. 謝謝作者啦,很適合野生小白

      來自廣東 回復
  8. 感謝作者,解決了不少我個人思路上的問題

    回復
    1. ??寫出來就是幫你們解決問題的

      回復
  9. 很贊..這段時間我也開始整理這方面的知識

    來自廣東 回復
    1. ?? 加油

      來自廣東 回復
  10. 個人微信號:weixin-lianggao1993

    來自廣東 回復
    1. 只需要填寫功能點嗎?好像沒看到出原型需求的階段呢?求教

      來自福建 回復
    2. 同問,哪個階段出原型需求

      來自北京 回復