需求的管理一般分三部分:
一、交付需求
產品經理本身不能對產品方案進行實施,需要協調研發、測試、設計等工作人員來共同完成產品需求,這個時候我們就需要將自己梳理的產品需求,傳達給我們需要協調的這些人,這個過程就是交付需求的過程,一般分下面兩個步驟:
1、提交需求
提交需求一般包含以下內容:
結構圖(信息結構圖,功能結構圖)
流程圖(業務流程圖、功能流程圖)
產品原型(低保真、高保真)
產品需求文檔(PRD)
2、評審需求
在提交了產品需求后,需要組織開發、運營、設計、測試等相關人員對產品需求進行評審,在評審過程中,對產品的目標、背景、問題、思路、解決方案等進行介紹、評審的目的一個是為了讓產品更完善,具有可行性;另一個目的,也是讓所有參與人員認可并評審通過的產品需求才能被開發,評審是產品工作中非常重要的環節,如果這部分工作做不好,開發過程中的摩擦和改需求的可能性非常大。
二、制定需求實施計劃
需求評審通過后,就可以開始實施了,在實施前需要和具體的執行人一起來確定開發計劃,一般包含以下幾種情況:
1、和開發確定開發計劃,主要包含:
誰來做?
什么時候開始做?
什么時候開發完成?
什么時候提交提測試?
什么時候測試版上線?
什么時候正式版上線?
2、和設計人員確定UI設計計劃,主要包含:
誰來設計?
什么時候開始設計?
什么時候出主風格?
什么時候完成設計?
3、和運營人員確定運營計劃,主要包含:
誰來運營?
什么時候開始運營?
運營計劃和資源準備?
這里面要特別注意下面幾點:
1、明確干系人,每一項需求的實現工作都需要具體到某個人。不能似是而非,否則最后出了問題都找不到人;
2、明確工作中的關鍵時間節點。比如開發什么時候開始,什么時候測試,什么時候上線等問題;
3、在計劃中要考慮風險因素,和執行成員事先商量好規避風險的辦法。比如在計劃安排上考慮后面需求變更、人員變更、技術實現困難等因素,在排期上時間安排的寬松一點,這樣有意外情況發生時也有時間來調整。另外在執行過程中,可以和團隊小伙伴商量使用每天10分鐘站立會的方式對執行過程的工作內容進行把控,讓每個人講下前一天的工作進展和今天的工作安排,有沒有延期或者有沒有什么自己解決不了的問題,然后再講一下今天的工作計劃,有沒有什么困難需要幫助,通過對每一天工作內容和進度的把控來保證產品需求能被按照計劃來實現,這個方法在很多互聯網公司使用。
三、管理變更需求
在需求評審完成后,產品會進行封板,需求池也會凍結。不論什么需求,都不會加到這個版本里面了,原則上是不能再改變需求了,但是有時候因為一些客觀因素,需求變更又是不可避免的。比如市場環境的變化,之前考慮不周,功能被遺忘,技術實現比預估的困難等因素,所以管理產品需求變更也是產品需求管理的一項重要工作。
1、分析需求
需求變更常見的類型有三種:新增,刪除和更改,當產生了新的需求的時候,首先我們使用之前講的需求分析的方法,從痛點→用戶→需求→產品需求→評審,這樣一個流程來對需求進行分析,確認需求的價值,看看這個需求是真實需求還是偽需求,只有靠譜的需求才有變更的必要和討論的意義,這里要防止拍腦袋變更需求,拍腦袋一兩次是可以的,經常隨意改變需求,自己的信譽會下降,而且能力也會被同事質疑。
2、分析變更的可行性
要不要變更需求,可以從以下三個方面來評估
考慮變更需求對用戶使用的影響
考慮需求變更帶來的成本因素
考慮市場的機會成本
3、變更需求
變更的需求被評估,確定要進行需求變更后,就可以執行需求變更了,這時候需要做兩方面的工作:
第一部分是自己獨立完成的工作,需要對變更后需求的產品流程、功能、原型、文檔等進行相應調整;
第二部分是協調其他參與人,及時把需求變動告知相關人員,讓其對工作作出相應的調整。
做完以上兩個工作,需求變更才算真正完成。
內容摘自《人人都是產品經理》