不想被開發(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è)人中心頁

▲頭像大圖

基本需求說明

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

看起來三個(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)按頁面彈出保存圖片按鈕,保存成功后提示,文案為“保存成功”;
  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ù)覽頁面是否支持對(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ì)涉及到頁面層面的需求拆解方法。

1. 頁面拆解

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

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

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

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

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

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

2. 整體需求自查

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

3. MECE原則檢查

通過上述方法,也許已經(jīng)將每個(gè)頁面的需求考慮得非常仔細(xì)了,但不能保證多個(gè)頁面之間描述的問題沒有重復(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è)人中心頁。

可以發(fā)現(xiàn),這兩個(gè)大的需求點(diǎn),對(duì)點(diǎn)擊切換頁面顯示的內(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. 好詳細(xì)的需求點(diǎn)~ 努力完善,再接再厲

    來自江西 回復(fù)
  2. 不贊同說prd沒人看,所以不用細(xì),我的經(jīng)驗(yàn)來看,prd主要是給測(cè)試人員一個(gè)目標(biāo),另外留著后面查閱。開發(fā)倒是真不會(huì),當(dāng)然**厲害了,文檔寫了你沒看也是一個(gè)說法。

    回復(fù)