不想被開發(fā)錘?教你梳理一份細(xì)節(jié)完整的需求

42 評(píng)論 24627 瀏覽 417 收藏 12 分鐘

寫需求文檔對(duì)于產(chǎn)品經(jīng)理而言是一個(gè)逃不掉的工作內(nèi)容,只有多總結(jié)多反思,積累經(jīng)驗(yàn)教訓(xùn),才能更好的與開發(fā)探(si)討(bi)。

在互聯(lián)網(wǎng)行業(yè),一個(gè)需求要得到實(shí)現(xiàn),首先需要產(chǎn)品經(jīng)理對(duì)需求進(jìn)行評(píng)估和提煉,轉(zhuǎn)化為一個(gè)可實(shí)施的具體方案,然后拆解、細(xì)化方案,通過需求文檔描述清楚這個(gè)方案,再給到研發(fā)人員進(jìn)行實(shí)施。

方案越細(xì)致,研發(fā)過程溝通成本就越低,實(shí)現(xiàn)的效率就越高。

然而寫需求文檔就像寫文章,沒有嚴(yán)格的標(biāo)準(zhǔn),每個(gè)人寫的習(xí)慣不一樣,每個(gè)公司的要求也不一樣。所以需求方案到底需要拆解到什么程度?如何來衡量方案拆解的程度是否足夠細(xì)致?

一、提出這個(gè)問題的目的

一方面,從我個(gè)人工作經(jīng)歷來看,在推進(jìn)一個(gè)需求至上線的過程中,消耗時(shí)間最多環(huán)節(jié)的除了規(guī)劃階段,就是在開發(fā)測(cè)試階段,往往會(huì)由于對(duì)細(xì)節(jié)點(diǎn)描述不夠全面,在開發(fā)測(cè)試階段需要頻繁溝通。

對(duì)需求方案拆解這個(gè)問題的思考總結(jié),希望可以鞭策自己在面對(duì)每一個(gè)需求的時(shí)候完善更多細(xì)節(jié),提高需求質(zhì)量,并思考每個(gè)細(xì)節(jié)實(shí)現(xiàn)背后的原因,從而提升對(duì)每個(gè)需求本質(zhì)的理解深度。

另一方面,業(yè)務(wù)方如果能更加清晰的了解到產(chǎn)品經(jīng)理在完成一個(gè)需求方案的時(shí)候具體的工作內(nèi)容及流程,就可以在需求溝通時(shí)提供更完善的信息,以減少產(chǎn)品經(jīng)理完善需求方案時(shí)與業(yè)務(wù)方的反復(fù)溝通確認(rèn),甚至避免由于理解業(yè)務(wù)偏差導(dǎo)致最后上線的產(chǎn)品不符合業(yè)務(wù)需求。

一個(gè)需求方案到底可以被拆解到什么程度,下面舉個(gè)例子來感受一下。

二、舉個(gè)例子

對(duì)于一個(gè)APP的個(gè)人中心,點(diǎn)擊頭像縮略圖查看大頭像的這個(gè)小功能,會(huì)涉及到哪些需求點(diǎn)?

我們可以飛速的思考幾秒鐘。

根據(jù)我們使用APP的多年經(jīng)驗(yàn),這似乎是個(gè)很常見很小的功能點(diǎn),點(diǎn)擊小圖看大圖,點(diǎn)擊大圖回到小圖就完事了,事實(shí)真的是這樣嗎?那么下面我來一一列舉一下。

▲個(gè)人中心頁(yè)

▲頭像大圖

基本需求說明

  1. 默認(rèn)展示頭像原圖的縮略圖;
  2. 點(diǎn)擊縮略圖,全屏展示原圖;
  3. 點(diǎn)擊原圖時(shí),關(guān)閉全屏,返回個(gè)人中心頁(yè)。

看起來三個(gè)大點(diǎn)已經(jīng)描述清楚了這個(gè)功能,但這只是用戶的操作主路徑,還不是一個(gè)需求說明該有的樣子,每一個(gè)點(diǎn)還有很多需要補(bǔ)充的內(nèi)容。

對(duì)每個(gè)點(diǎn)的二級(jí)細(xì)化補(bǔ)充

  1. 縮略圖的尺寸為原圖等比例縮放,縮略圖是以原圖的對(duì)角線中心為圓點(diǎn)切成的一個(gè)圓形,直徑大小為圖片的寬度;
  2. 全屏展示原圖時(shí),支持保存圖片,長(zhǎng)按頁(yè)面彈出保存圖片按鈕,保存成功后提示,文案為“保存成功”;
  3. 如保存圖片時(shí),APP沒有相機(jī)權(quán)限,此時(shí)應(yīng)先彈出獲取系統(tǒng)相機(jī)權(quán)限;
  4. 支持更換頭像,并顯示修改頭像按鈕,點(diǎn)擊按鈕支持從相冊(cè)選擇及拍照上傳;
  5. 點(diǎn)擊縮略圖進(jìn)入展示原圖過程中,是否需要loading動(dòng)畫,如果加載原圖失敗,如何展示?

似乎已經(jīng)很完善了,還可以更細(xì)化嗎?

繼續(xù)增加三級(jí)細(xì)化補(bǔ)充

  1. 全屏展示原圖時(shí),手指捏合可以放大縮小圖片,放大到多大時(shí)無法再放大,手指捏合縮小時(shí),圖片最小顯示寬度為圖片寬度;
  2. APP是否支持橫屏顯示,橫屏?xí)r原圖是否根據(jù)橫屏的高度撐滿屏幕高度;
  3. 上傳的新頭像時(shí)是否支持預(yù)覽,預(yù)覽頁(yè)面是否支持對(duì)圖片進(jìn)行編輯,圖片是否需要壓縮上傳,壓縮比例如何?
  4. 用戶是否需要查看歷史的頭像,是否需要還原上次頭像的功能?
  5. 更換頭像、保持圖片的功能是做成集合按鈕,還是在長(zhǎng)按彈出的組件中?

……

通過這個(gè)例子我們可以很直觀的感受到,一個(gè)看起來很簡(jiǎn)單的需求,背后需要處理的邏輯是很多的。

如果產(chǎn)品經(jīng)理在規(guī)劃階段沒有考慮到,就可能在開發(fā)測(cè)試階段暴露出來,產(chǎn)品經(jīng)理需要在開發(fā)周期中補(bǔ)充方案,甚至有的問題是上線后才收到用戶的反饋,這種情況需要開發(fā)測(cè)試同學(xué)的返工或緊急發(fā)版修復(fù),既影響用戶體驗(yàn),又浪費(fèi)開發(fā)資源。

既然需求方案的細(xì)化程度如此重要,如何系統(tǒng)化的思考并拆解呢?

三、系統(tǒng)化拆解需求細(xì)節(jié)

一個(gè)大型項(xiàng)目的方案拆解是個(gè)很復(fù)雜的工作,需要豐富的項(xiàng)目經(jīng)驗(yàn)及結(jié)構(gòu)化的思維。

以下僅針對(duì)在確定了整體方案的前提下,對(duì)涉及到頁(yè)面層面的需求拆解方法。

1. 頁(yè)面拆解

首先,每個(gè)頁(yè)面都有進(jìn)入和跳出的條件,如登錄狀態(tài)、用戶身份、權(quán)限、網(wǎng)絡(luò)限制等,梳理與上一個(gè)、下一個(gè)頁(yè)面的邏輯關(guān)系,把每個(gè)頁(yè)面這樣的邏輯串起來其實(shí)就是整個(gè)系統(tǒng)的頁(yè)面流程圖。

其次,有哪些原始數(shù)據(jù)通過怎么的方式進(jìn)入該頁(yè)面,數(shù)據(jù)在頁(yè)面是如何產(chǎn)生的,最后在該頁(yè)面如何提交與儲(chǔ)存。

數(shù)據(jù)就像頁(yè)面的血液,是時(shí)刻變化的動(dòng)態(tài)量,但只要關(guān)心每個(gè)頁(yè)面進(jìn)入時(shí)和跳出時(shí)的數(shù)據(jù),就能掌握產(chǎn)品的整體動(dòng)態(tài)數(shù)據(jù)。

最后是頁(yè)面本身的邏輯,靜態(tài)邏輯包含了用戶未進(jìn)行交互操作時(shí),展示給用戶的全部邏輯,如間距、字體、顏色、聲音、動(dòng)畫等;

動(dòng)態(tài)邏輯即用戶進(jìn)行了某個(gè)操作后可能引發(fā)的頁(yè)面所有變化,如點(diǎn)擊、滑動(dòng)、輸入等動(dòng)作引起的頁(yè)面和控件變化;

邊界限制指的是作為頁(yè)面的載體本身的一些限制,比如同一個(gè)功能在安卓系統(tǒng)和iOS的區(qū)別,原生APP與微信小程序及H5的區(qū)別等。

2. 整體需求自查

通過上述三個(gè)層面的考慮,基本可以保證一個(gè)頁(yè)面的需求不遺漏,但是可能對(duì)很多異常流考慮程度不夠,還可以用一份詳細(xì)的需求自查表來check,驗(yàn)證一下是否覆蓋了大部分異常情況。

3. MECE原則檢查

通過上述方法,也許已經(jīng)將每個(gè)頁(yè)面的需求考慮得非常仔細(xì)了,但不能保證多個(gè)頁(yè)面之間描述的問題沒有重復(fù)或矛盾,這時(shí)可以通過MECE原則進(jìn)行全盤檢查。

MECE原則是《金字塔原理》中提出的概念,全稱Mutually Exclusive Collectively Exhaustive,指的是“相互獨(dú)立,完全窮盡”。

對(duì)于同一層級(jí)的需求點(diǎn)進(jìn)行描述時(shí),必須保證這些需求點(diǎn)之間邏輯相互獨(dú)立,否則會(huì)讓整個(gè)方案邏輯混亂,難以理解。

比如把下圖的大矩形比作一個(gè)需求方案,小正方形比作拆解的需求點(diǎn),那么這樣的形式來描述這個(gè)需求就不符合MECE原則,因?yàn)槿齻€(gè)小正方形之間有交叉重疊部分,且組合起來沒有完全填滿整個(gè)矩形。

例如本文提到的查看頭像大圖的例子,從大的需求點(diǎn)來拆解,如果拆解成:

  1. 默認(rèn)顯示頭像的縮略圖,點(diǎn)擊可以在大圖和縮略圖之間切換;
  2. 全屏顯示大圖時(shí),顯示保存按鈕,點(diǎn)擊大圖回到個(gè)人中心頁(yè)。

可以發(fā)現(xiàn),這兩個(gè)大的需求點(diǎn),對(duì)點(diǎn)擊切換頁(yè)面顯示的內(nèi)容進(jìn)行了重復(fù)描述,即邏輯不互相獨(dú)立。

以下的拆解方法就是典型的符合MECE原則,同一層級(jí)的需求點(diǎn)之間沒有交叉,互相獨(dú)立,組合起來剛好覆蓋整個(gè)需求,沒有遺漏,每個(gè)大的需求點(diǎn)的下一級(jí)再按照同樣的方式進(jìn)行列舉,最終是一個(gè)不斷逼近整體方案的過程。

四、總結(jié)與思考

本文簡(jiǎn)單總結(jié)了我個(gè)人工作過程中對(duì)需求方案拆解的思考,僅適用于確定了產(chǎn)品整體結(jié)構(gòu)的情況下,對(duì)詳細(xì)需求的細(xì)節(jié)層面拆解。

這些只是日常工作的基本功,我認(rèn)為做產(chǎn)品除了要對(duì)需求各個(gè)細(xì)節(jié)充分思考,還是一個(gè)逐漸剝離事物表象,發(fā)現(xiàn)本質(zhì)的過程,只有產(chǎn)品的大方向是滿足事物本質(zhì)的,需求細(xì)節(jié)的完善才會(huì)讓產(chǎn)品變得更精致。

 

作者:haven,非典型工科中年男孩,云擼貓,愛做飯;歡迎關(guān)注公眾號(hào)交流:PM何小澤

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

題圖來自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 寫的很好,雖說是寫文檔的思路,其實(shí)也是業(yè)務(wù)思考的過程。學(xué)習(xí)了

    回復(fù)
  2. 看不見

    回復(fù)
  3. 緩存規(guī)則是主要指的哪些方面呢?什么時(shí)候會(huì)涉及到這個(gè)?到底是解決了什么問題呢?

    來自北京 回復(fù)
  4. 小哥哥可以加個(gè)微信嘛,感覺你分析的好好

    回復(fù)
  5. 寫一份,形成公共規(guī)范就系了,開發(fā)也會(huì)將他們抽象成公共類

    來自廣東 回復(fù)
  6. 寫得很好,自查的看了下需求 都有 挺好的

    來自上海 回復(fù)
  7. 贊一個(gè),起初做產(chǎn)品也是很多細(xì)節(jié)沒有考慮到位,研發(fā)和測(cè)試小姐姐會(huì)一直來問,之后考慮的多了,需求也會(huì)寫的很細(xì),我也是個(gè)很注重細(xì)節(jié)的人,就像評(píng)論中說的,研發(fā)大佬很少人看,但我們考慮細(xì)節(jié)到位了,可提升工作效率、用戶體驗(yàn)

    來自重慶 回復(fù)
  8. 這個(gè)需求拆的真的是很細(xì)了,學(xué)習(xí)了學(xué)習(xí)了~

    來自北京 回復(fù)
  9. 好頂贊!

    來自四川 回復(fù)
  10. 贊,每次寫文檔很多細(xì)節(jié)沒有考慮到,,雖然開發(fā)可能不會(huì)去看文檔,但是如果有時(shí)間還是寫細(xì)點(diǎn)會(huì)好點(diǎn)吧,畢竟有些細(xì)節(jié)過了很久會(huì)遺忘的。

    來自江蘇 回復(fù)
  11. 我和開發(fā)同事已經(jīng)配合好多年了,很多時(shí)候,都不需要寫這么細(xì),大致列出需求要點(diǎn),開發(fā)自己去完成。比如調(diào)用系統(tǒng)權(quán)限這些,都是開發(fā)自己搞定。

    來自湖北 回復(fù)
    1. 那可能你這個(gè)開發(fā)比較牛逼,一般的開發(fā)都不會(huì)去考慮背后的邏輯,你給什么他實(shí)現(xiàn)什么。有很多細(xì)節(jié)沒有梳理到位,到開發(fā)階段,還是屁顛屁顛跑回來問你,很影響效率的

      來自浙江 回復(fù)
    2. 其實(shí)還有一點(diǎn),對(duì)于已經(jīng)成熟的產(chǎn)品,服務(wù)多年的開發(fā)、測(cè)試。有時(shí)候覺得如果產(chǎn)品文檔寫的太過于詳細(xì),真是浪費(fèi)雙方的時(shí)間。

      來自湖北 回復(fù)
  12. 我很支持這樣的方法論的思考和探討,這樣細(xì)節(jié)很清楚很明白。不過有一些問題值得思考:

    項(xiàng)目開始和結(jié)束時(shí),需求前后已經(jīng)發(fā)生了很大的改變;而且從畫高保真的原型經(jīng)歷來看,最后成型的原型,和最初的需求也有不同。簡(jiǎn)單來說,需求是在做產(chǎn)品的過程中得以了優(yōu)化和完善,一開始將所有的問題考慮得很清楚、很細(xì)致,有著一定的難度,尤其是不熟悉,不常見的軟件,構(gòu)想到那么細(xì)致的程度幾乎是不可能的;需求的實(shí)現(xiàn)方案不會(huì)是一成不變,在項(xiàng)目過程中會(huì)進(jìn)行演變,所以,需求梳理到絲毫畢露的地步顯得沒有多大的必要。

    但是,并不是說,這樣的思考和梳理沒有必要,相反,我認(rèn)為這相當(dāng)?shù)挠斜匾?。而且這個(gè)可以作為常規(guī)訓(xùn)練進(jìn)行下去

    來自重慶 回復(fù)
    1. 同感,這需要產(chǎn)品經(jīng)理了解自己開發(fā)人員的開發(fā)習(xí)慣,事無巨細(xì)當(dāng)然好,但是也影響了需求成型的進(jìn)度,可能反過來影響了產(chǎn)品的整體開發(fā)

      來自天津 回復(fù)
  13. 目前只做過軟件需求,也設(shè)計(jì)硬件,但是小程序或者APP的需求沒做過;文中需求自查checklist寫得挺好的,確實(shí)有一些分支在實(shí)際工作中沒有注意到 ??

    來自廣東 回復(fù)
  14. 你寫這篇文章花了多久?做一個(gè)上文的需求需要多久?做產(chǎn)品需要有的放矢,該細(xì)的地方細(xì),該粗的地方粗,最終還是要以落地說話,還有不是需求說清楚了,就不會(huì)si bi,很多時(shí)候就是價(jià)值觀不同,該撕還得撕!

    來自北京 回復(fù)
    1. 同意你的觀點(diǎn),大部分是價(jià)值觀念不一致,同樣的需求不同開發(fā)人員觀點(diǎn)就不一樣,需要產(chǎn)品經(jīng)理保持原則,就像一群人畫畫,每個(gè)人都來畫一筆,結(jié)果誰也不滿意。

      回復(fù)
  15. 感謝分享

    回復(fù)
  16. 領(lǐng)導(dǎo)說,可以寫這么細(xì)。但是別占用工作時(shí)間,拿回家寫吧。

    回復(fù)
    1. 哈哈哈,開發(fā)時(shí)常就是會(huì)問的這么細(xì),如果不說清楚,后期就甩鍋說是產(chǎn)品沒說清楚 ??

      來自廣東 回復(fù)
  17. 有功夫?qū)戇@些東西,請(qǐng)邁開腿走到開發(fā)旁細(xì)細(xì)敘說

    回復(fù)
  18. 第一、這是交互設(shè)計(jì)師的事
    第二、不會(huì)有哪個(gè)開發(fā)看的

    來自浙江 回復(fù)
    1. 開發(fā)不看,但是肯定會(huì)問,如果一人對(duì)接10多個(gè)開發(fā),每天都會(huì)被這些細(xì)節(jié)占用大部分時(shí)間,甚至后期撕逼說產(chǎn)品需求不清楚

      來自廣東 回復(fù)
    2. 我們前端開發(fā)基本不看原型,只看UI。。。

      來自福建 回復(fù)
  19. 難得的好文!

    回復(fù)
  20. 因開發(fā)而異,因公司而已,因需求緊急程度而異

    來自江蘇 回復(fù)
  21. 哇即刻!

    回復(fù)
  22. 感謝分享

    回復(fù)
  23. 真的是細(xì)節(jié)很到位了,找到了和研發(fā)不停溝通的原因了,太細(xì)節(jié)的我覺得沒必要都寫出來,結(jié)果研發(fā)確實(shí)不知道具體要什么樣的展示方式。學(xué)到了,謝謝!

    回復(fù)
  24. 真的不會(huì)被打么這樣寫?開發(fā)一天就在琢磨你的文檔了,愣是沒看明白

    來自浙江 回復(fù)
    1. 第一、這是交互設(shè)計(jì)師的事
      第二、不會(huì)有開發(fā)看的

      來自浙江 回復(fù)
  25. 八分鐘不夠啊 讀了雙倍時(shí)間??
    我覺得關(guān)鍵還是要了解用戶操作主路徑 然后倒推每一步的細(xì)節(jié)處理 串起來 這樣思路會(huì)清晰些
    要想清楚用戶每一步的操作目的和目的達(dá)成失敗產(chǎn)品處理方式

    回復(fù)
  26. 回復(fù)
  27. 感謝分享!這個(gè)需求自查表也就是prd的寫法吧?(來自一個(gè)產(chǎn)品小白的提問)

    來自北京 回復(fù)
    1. 應(yīng)該說是為寫PRD,提供了一些緯度。

      回復(fù)
  28. 方法是沒問題,你是這樣寫出來的需求,得寫到過年,這個(gè)成本公司受得了嗎,老板受得了嗎?具體情況還是得具體分析

    來自浙江 回復(fù)
  29. 一個(gè)不懂技術(shù)的產(chǎn)品想不到這么多細(xì)節(jié)吧 ??

    來自廣東 回復(fù)
    1. 通過實(shí)戰(zhàn)碰壁后,復(fù)盤后都會(huì)有所領(lǐng)悟和改變的,不過確實(shí)在平時(shí)產(chǎn)品開發(fā)中會(huì)功能點(diǎn)考慮不夠深和細(xì),但方法很多,可分期,排優(yōu)先級(jí)

      來自浙江 回復(fù)
  30. 來自廣東 回復(fù)