故事1:開發(fā)團隊提交了一個測試版,需要測試團隊來進行測試。但是,測試團隊對這個版本的需求并不了解,不知道它的需求是什么?
測試團隊是如何解決這個問題的呢?第一是自學。通過探索新版本的功能來了解它。第二是提問,開發(fā)團隊很厭惡的回答這些問題。
最后產品投產上線,產品經理上來一看,火冒三丈:一堆功能錯亂,需求理解錯誤的內容。
故事2:產品經理為了產品有競爭力,做了市場分析、競品調研。指定了一系列的需求。
過了幾個月,發(fā)布了新版本,但是,新功能參差不齊,好幾個“killer feature”沒有實現。
以上的故事的原因就是,沒有需求管理。產品無法聚焦在客戶關注的需求上面,最后導致產品么有競爭力。
需求管理要解決的問題是:
1,盡可能多的需求搜集。不只是產品經理,運維和技術支持人員,經常能夠發(fā)現有價值的需求。
2,確定哪些需求有價值。通過需求管理的流程化,對需求進行分析評估、可行性分析,確定哪些需求具備比較高的價值。
3,保證有價值的需求盡可能先推出。需求管理是一個流程,通過這個流程的運轉,我們能夠把高優(yōu)先級的需求優(yōu)先排期,優(yōu)先實現。
4,需求與開發(fā)同步。
5,各個團隊共享一個需求,么有理解偏差。使用一個需求,防止雞同鴨講。
當我們具備了需求管理,我們能:
1,統計當前需求的狀態(tài),比如總共的需求個數、已經開發(fā)完成的需求個數、正在開發(fā)的需求、排期中的需求。
2,共享需求,排除理解異議。測試團隊很早就可以自己去查看需要測試的需求,而不依賴于開發(fā)團隊最終的代碼和解釋,提前編寫測試用例。
3,通過排期,能夠讓產品經理聚焦在需求上,盡可能發(fā)布包含更多killer feature的版本。順便說一下,killer feature這個詞,我是抄微軟的,覺得是一個非常棒的詞,就是通過這些feature可以kill競爭對手的產品。
當然,澤眾ALM的需求管理模塊已經包含了這個功能。并且自己也在使用。還有什么比自己都認同更有說服力?
推薦閱讀: