您的位置: 首頁 > 新聞中心

    實戰之從需求池到確認需求的全過程

    作者:威海網絡公司 日期:2018-05-24 點擊:419

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

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

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

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

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

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

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

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

    第一步:整理需求池

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

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

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

    示例如下:

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

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

    文檔說明:

    (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的產品需要輸出哪些產物。

    本文由威海網絡公司半島科技轉載整理2018.05.24

    分享到:

    上一條:如何將產品推向市場?通過9個問題幫你尋找獲客渠道

    下一條:需求分析師如何分析功能性需求

    360彩票网官网下载 广东十一选五追号软件 2018跑路的理财平台名单 极速赛车公式大全图解 福彩36选七的走势图 每日免费推荐股票 七乐彩选号的独门技巧 广东36选7如何选好 赛车预测 广东十一选五购买软件 北京快乐八工在线计划 一个人能开几个股票 股票买卖成交规则 即时开奖网极速时时彩 陕西快乐10分下载 二四六免费资料大全正版 贵州今天快3走势图