需求分析06:如何管理產(chǎn)品需求?

17 評論 41221 瀏覽 376 收藏 15 分鐘
🔗 B端产品经理需要更多地进行深入的用户访谈、调研、分析,而C端产品经理需要更多地快速的用户测试、反馈、迭代

文章分三部分展開描述如何進行產(chǎn)品的需求管理,希望對大家有所啟發(fā)。

這是產(chǎn)品硬技能知識中需求分析系列的最后一篇文章,之前已經(jīng)發(fā)布了5篇,分為兩部分,一部分是與用戶需求相關(guān)的內(nèi)容,見下圖所示:

需求往往來源于痛點,當我們發(fā)現(xiàn)了一個痛點后,通過用戶研究的方法,發(fā)現(xiàn)了痛點背后龐大的市場;市場很大,而我們能力有限,這時候我們就要找到自己能解決的哪一部分,并了解這部分用戶的需求,這個過程就是定義用戶需求的過程,在這個過程中我們要弄清楚這里的用戶角色、使用場景、用戶的問題,這三個方面綜合起來也就是我們常說的用戶需求,在這里要注意、痛點、市場需求和用戶需求并不是同一個東西。

另一部分是與產(chǎn)品需求相關(guān)的內(nèi)容,見下圖:

當我們弄清楚了用戶需求后,就需要提供一個產(chǎn)品解決方案來解決用戶的需求,在提供解決方案的時候,我們不能只考慮用戶需求,還需要考慮戰(zhàn)略的需求,老板的需求,產(chǎn)品運營的需求,業(yè)務人員的需求,競爭的需求,作為產(chǎn)品經(jīng)理自己本身的價值觀需求等,基于這些需求,我們來構(gòu)建產(chǎn)品,在這個產(chǎn)品方案里面會有很多產(chǎn)品的功能,這個功能就是我們常說的產(chǎn)品需求。

當我們確認了產(chǎn)品需求后,產(chǎn)品就從需求階段進入到了實施階段,接下來就是怎么管理產(chǎn)品的需求,我們分三部分來講:

  1. 交付需求
  2. 制定需求實施計劃
  3. 控制需求變更

一. 交付需求

產(chǎn)品經(jīng)理本身不能對產(chǎn)品方案進行實施,需要協(xié)調(diào)研發(fā),測試,設(shè)計等工作人員來共同完成產(chǎn)品需求,這個時候我們就需要將自己梳理的產(chǎn)品需求,傳達給我們需要協(xié)調(diào)的這些人,這個過程就是交付需求的過程,一般分下面兩個步驟:

第一步:提交需求

提交需求就是把產(chǎn)品需求完整清晰的告知給需要協(xié)作的小伙伴,讓他們清楚的了解產(chǎn)品的需求, 一般通過以下三個交付物來告知:

1.產(chǎn)品流程圖

產(chǎn)品流程圖是說明產(chǎn)品操作和相應過程的文檔,一般有兩類:

一類是業(yè)務流程圖,基于業(yè)務邏輯來設(shè)計,一般包含主要流程和功能模塊,用來說明產(chǎn)品的架構(gòu);

另一類是功能流程圖,一般基于用戶任務來設(shè)計,包含人物角色,操作過程的關(guān)鍵節(jié)點,狀態(tài),判斷,結(jié)果等,可以參考下面兩個簡單的小例子(只是為了說明問題,不代表真實流程):

2.產(chǎn)品原型

上面的流程圖主要偏重于對產(chǎn)品后端和邏輯的描述,而產(chǎn)品原型的作用正好與流程圖互補,偏重于對產(chǎn)品界面信息架構(gòu),跳轉(zhuǎn)邏輯和交互功能的展示說明,通過產(chǎn)品原型,可以將抽象的產(chǎn)品具體化,讓產(chǎn)品更容易被理解,產(chǎn)品原型一般由線框圖構(gòu)成,在業(yè)界大部分人使用axure來制作,有的公司有交互設(shè)計師,原型制作工作由交互設(shè)計師來承擔,大部分互聯(lián)網(wǎng)公司是沒有交互設(shè)計師的,所以產(chǎn)品原型一般由產(chǎn)品經(jīng)理來完成,一般長下面這樣:

3. 產(chǎn)品需求文檔

產(chǎn)品需求文檔,英文Product Requirement Document,簡稱prd, 主要以文字形式來闡述產(chǎn)品的詳細需求,與流程圖,產(chǎn)品原型配合使用來說明產(chǎn)品需求,核心內(nèi)容是對要實現(xiàn)的每個產(chǎn)品功能及里面用戶角色、前置條件、后置條件、界面、流程,數(shù)據(jù)統(tǒng)計等內(nèi)容的描述,主要面向研發(fā)人員,使用word來撰寫和閱讀。
以上這三種交付物是產(chǎn)品經(jīng)理協(xié)作過程中比較常見的交付物,尤其是在大公司中這些是必備的。但這不是強制的標準,很多中小公司都沒有產(chǎn)品文檔這個部分,有的直接用產(chǎn)品原型標注文字說明來做文檔,有的是用excell來寫文檔,所以具體的交付物根據(jù)自己所處公司的實際要求來看,這些交付物的目的是為了輔助溝通,不管什么樣的交付物,只要能達到簡單,快速,高效溝通的目的就可以。

第二步. 評審需求

在提交了產(chǎn)品需求后,需要組織研、運營、設(shè)計、測試等人員對產(chǎn)品需求評審,在評審過程中,對產(chǎn)品的目標、背景、問題、思路、解決方案等進行介紹,評審的目的一個是為了讓產(chǎn)品更完善,更具有可行性,另一個目的,也是讓所有參與實施的人員對產(chǎn)品需求認可,目標達成一致,只有被所有參與人員認可并評審通過的產(chǎn)品需求才能被開發(fā),評審是產(chǎn)品工作中非常重要的環(huán)節(jié),如果這部分工作做不好,開發(fā)過程中的摩擦和修改需求的概率非常大。

二. 制定需求實施計劃

需求評審通過后,就可以開始實施了,在實施前需要和具體的執(zhí)行人一起來確定執(zhí)行計劃,一般包含下面幾種情況

1.和研發(fā)確定開發(fā)計劃,主要包含:

  • 誰來做?
  • 什么時候開始做?
  • 什么時候完成?
  • 什么時候測試?
  • 什么時候測試版上線?
  • 什么時候正式版上線?

2.和設(shè)計人員確定UI設(shè)計計劃,主要包含:

  • 誰來設(shè)計?
  • 什么時候開始設(shè)計?
  • 什么時候出主風格?
  • 什么時候完成設(shè)計?

3.和運營人員確定運營計劃,主要包含:

  • 誰來運營?
  • 什么時候開始試運營?
  • 運營計劃和資源準備?

在這里面特別要注意下面三點:

第一:明確干系人,每一項需求的實現(xiàn)工作都要具體到某個人,不能似是而非,否則最后出了問題都找不到人;

第二:明確工作中的關(guān)鍵時間節(jié)點,比如研發(fā)什么時候開始,什么時候測試,什么時候結(jié)束等問題;

第三:在計劃中要考慮風險因素,和執(zhí)行成員事先商量好規(guī)避的辦法,比如在計劃安排上考慮到后面需求變更,人員變更,技術(shù)實現(xiàn)困難等因素,在排期上時間安排的寬松一點,這樣有意外情況發(fā)生也有時間來調(diào)整,另外在執(zhí)行過程中,可以和團隊小伙伴商量使用每天10分鐘站立晨會的方式對執(zhí)行過程的工作內(nèi)容進行把控,讓每個人講一下前一天工作的進展,有沒有延期或者有沒有什么自己解決不了的,然后再講一下今天的工作計劃,有沒有什么困難需要幫助,通過對每一天工作內(nèi)容和進度的把控來保證產(chǎn)品需求能被按照計劃來實現(xiàn),這個方法在很多互聯(lián)網(wǎng)公司使用。

三. 管理需求變更

在需求評審完成后,產(chǎn)品會進行封版,需求池也會凍結(jié),不論什么需求,都不會加在這個版本里面了,原則上是不能再改變需求了,但是有時候因為一些客觀因素,需求變更又是不可避免的,比如市場環(huán)境的變化,之前考慮不周,功能被遺忘,技術(shù)實現(xiàn)比預估的困難等因素,所以管理產(chǎn)品需求變更也是產(chǎn)品需求管理一項重要的工作,下面來說說怎么管理需求變更。

1. 分析需求

需求變更常見的類型有三種,新增,刪除和更改,當產(chǎn)生了新的需求的時候,首先我們使用之前講的需求分析的方法,從痛點-用戶需求-產(chǎn)品需求-到評審這樣一個流程來對需求進行分析,確認需求的價值,看看這個需求是真需求還是偽需求,只有靠譜的需求才有變更的必要和討論的意義,在這里要防止拍腦袋變更需求,拍腦袋一兩次是可以的,經(jīng)常隨意改變需求,自己的信譽會下降,而且能力也會被同事質(zhì)疑。

2. 分析變更的可行性

變更需求通常意味著要調(diào)整資源、重新分配任務,并修改前期的工作成果,有時要付出較大的代價,如果動不動就變更需求,項目也許永遠不能按時完成,要不要變更需求,我們可以從以下三個方面來評估:

第一.考慮變更需求對用戶使用的影響:

產(chǎn)品最終是要推向市場面向用戶的,要不要改,首先得考慮對用戶使用的影響,如果一個需求屬于無差異型需求,有沒有對用戶使用都沒有影響,那這樣的需求就沒必要存在,更沒必要變更,如果一個需求屬于基礎(chǔ)型需求,比如社交網(wǎng)站沒有用戶上傳頭像功能,這對社交網(wǎng)站來說是功能的缺陷,沒有頭像,用戶體驗不到社交的氛圍,這樣的需求就得考慮變更。

第二.考慮需求變更帶來的成本因素:

需求變更意味著在計劃外要做很多工作,額外的工作就需要額外的投入,如果本來2個月可以完成的開發(fā)的產(chǎn)品,需求變更后,變成了3個月,就多了一個月的人力,物力,財力的投入,不論是大公司還是小公司,每個項目都有預算,如果因為需求變更導致預算超支,即使產(chǎn)品開發(fā)完成也得不償失,所以在評估需求是否要變更的時候,要考慮變更帶來的成本大小。

第三.考慮市場的機會成本:

大多數(shù)需求變更都會影響產(chǎn)品的上線時間,產(chǎn)品上線時間直接決定了后面投入市場運營,推廣的時間,如果錯過了某個有利的時間窗口期,產(chǎn)品是完善了,但是同樣喪失了市場推廣的有利機會,這樣也是不可取的,所以在考慮變更需求的時候,也要考慮市場因素,不能單純的看功能。

3. 變更需求

變更的需求被評估,確定要進行需求變更后,就可以執(zhí)行需求變更了,這時候需要做兩方面的工作

  • 第一部分是自己獨立完成的工作,需要進行需求變更后的產(chǎn)品流程,功能,原型,文檔制作和變更工作。
  • 第二部分是協(xié)調(diào)其它參與人,及時把需求變動告知相關(guān)人員,讓其對工作做出對應的調(diào)整。

做完以上兩個工作,需求變更才算真正完成。

四.小結(jié)

需求分析系列文章到這里就結(jié)束啦,大家可以翻閱以前的文章進行學習和練習,師父領(lǐng)進門,修行在個人,后面怎么使用就看大家的了。

相關(guān)閱讀:

需求分析01:如何發(fā)現(xiàn)用戶需求?

需求分析02: ?如何判斷用戶需求?

需求分析03:如何定義用戶需求?

需求分析04:如何定義產(chǎn)品需求?

需求分析05:如何評估產(chǎn)品需求?

專欄作家

作者:木木,高級產(chǎn)品經(jīng)理,人人都是產(chǎn)品經(jīng)理專欄作家,曾經(jīng)在人人網(wǎng),新浪微博等從事產(chǎn)品運營工作。微信公眾號:大白學堂(ID:dabaixuetang)。

本文由 @木木 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 為啥用戶需求和用戶痛點沒有交集呢?

    來自浙江 回復
  2. 您好,可以轉(zhuǎn)載該篇文章么?會標明作者和出處~ ??

    來自四川 回復
  3. 算了,我文化不高,只想說寫的真特么好

    回復
  4. 一口氣看完了6篇,很棒,思路很清晰,受益匪淺

    來自廣東 回復
  5. 很棒的文章,滿滿的干貨啊,6篇文章看下來通俗易懂,并且有一個相對完整的架構(gòu),能幫助像我這樣的小白梳理凌亂的觀點,謝謝作者!

    來自廣西 回復
    1. 是啊,我也這么認為!作者好厲害啊~文章全是干貨,看完都有點想報作者的實戰(zhàn)班了。。

      來自湖北 回復
  6. 回復
  7. 6篇文章均已認真拜讀并一一做了相應的筆記,用一句話來概括我的心情:感恩作者的無私分享,感恩人人都是產(chǎn)品經(jīng)理平臺!

    來自北京 回復
    1. 回復
    2. 回復
  8. 很棒很干,感謝作者

    回復
  9. 完整讀完5篇文章,很多東西有些框架和體系了,以后多多努力,謝謝指導

    來自廣東 回復
  10. 對于我剛?cè)胄械娜藖碚f,很受用

    來自安徽 回復
  11. get

    回復
  12. 受益

    回復
  13. 不錯啊~

    來自上海 回復
  14. ??

    來自上海 回復
专题
66265人已学习25篇文章
做好微信运营比做好APP运营还重要,因为用户把时间都给了微信。
专题
36286人已学习14篇文章
订单系统是看似简单,实际上是一个逻辑复杂的系统。
专题
37655人已学习20篇文章
“搜索功能”拆解:小功能,大细节。
专题
14083人已学习13篇文章
本专题的文章分享了WMS系统设计指南。
专题
13308人已学习12篇文章
随着互联网的不断发展,如今获客渠道及方式也有很多。本专题的文章分享了获客渠道及方法。