盤點(diǎn)PRD中易遺漏的三類非正面需求

8 評(píng)論 7889 瀏覽 23 收藏 12 分鐘

PRD除了描述產(chǎn)品的正面需求,即要什么之外,還要描述產(chǎn)品的非正面需求,即我不要什么,或預(yù)防什么。

筆者將非正面需求歸為三類:排除項(xiàng)、異常項(xiàng)、默認(rèn)項(xiàng)。

一、需求的排除項(xiàng)

在PMBOX中,項(xiàng)目排除項(xiàng)是項(xiàng)目范圍說明書中的一部分。同樣,需求排除項(xiàng), 也是需求范圍說明的一部分。

交代需求排除項(xiàng),不僅要告訴開發(fā)人員,哪些是不需要的功能、哪些不是目標(biāo)場(chǎng)景或目標(biāo)用戶,而且要交代哪些觸發(fā)操作不被允許。

1. 哪些是不需要的功能

比如,GIF圖是很常見的圖片形式,但是「微信」規(guī)定,發(fā)布的圖片不支持GIF格式。

又比如,更換游戲用戶頭像是個(gè)很常見的功能,但是「王者榮耀」就不支持(直接)更換頭像。

這些是產(chǎn)品克制的體現(xiàn)、邊緣性需求,或者說是功能邊界,當(dāng)然也可以簡(jiǎn)單歸屬為產(chǎn)品的個(gè)性化玩法。

作為產(chǎn)品經(jīng)理,一方面需要基于產(chǎn)品定位,主動(dòng)設(shè)置這樣的功能空缺,好像書法“飛白”,讓產(chǎn)品更加立體和獨(dú)特;

另一方面,某些時(shí)候受限于資源(比如開發(fā)人員不足),只能實(shí)現(xiàn)部分優(yōu)先級(jí)高的需求,這時(shí)候也要被動(dòng)地劃分出階段性的需求邊界,待日后做增量迭代。

不管上述那種動(dòng)機(jī)導(dǎo)致的“非需求”,產(chǎn)品經(jīng)理都要明確地將這些不需要的功能點(diǎn),作為需求的一部分呈現(xiàn)在PRD中,以便團(tuán)隊(duì)步調(diào)一致,避免思維定勢(shì)導(dǎo)致實(shí)現(xiàn)錯(cuò)誤。

2. 哪些觸發(fā)事件不被允許

舉個(gè)例子,我們通常說點(diǎn)擊按鈕打開新頁(yè)面,指的是「單擊事件」。但是有時(shí)候代碼不做排除的話,就會(huì)將雙擊事件當(dāng)做兩次單擊事件進(jìn)行執(zhí)行。

于是出現(xiàn)雙擊之后打開兩次頁(yè)面。那么用戶在新頁(yè)面操作完,返回的時(shí)候就需要返回兩次。如下圖演示了雙擊「搜索」和雙擊作者「頭像」時(shí)分別按兩次單機(jī)處理的畫面。

當(dāng)然這與開發(fā)的細(xì)致程度和經(jīng)驗(yàn)也有關(guān)系。但作為產(chǎn)品經(jīng)理,可以事先跟團(tuán)隊(duì)約定:

  • PRD中不提雙擊的,則一律將該控件的雙擊事件都定義為無效。
  • 只在需要雙擊的時(shí)候才定義雙擊事件。比如抖音,雙擊視頻畫面則為點(diǎn)贊,單擊則切換【播放/暫?!?。

3. 哪些不是目標(biāo)場(chǎng)景或目標(biāo)用戶

比如業(yè)務(wù)規(guī)定,主播在直播間獲得打賞的虛擬物品,可以對(duì)應(yīng)領(lǐng)取指定的實(shí)物商品。那么假設(shè),某主播積攢了上百個(gè)同一虛擬禮物,并且要同時(shí)全部領(lǐng)取。

但是實(shí)物庫(kù)存不夠,主播以“平臺(tái)不守信用”為理由投訴平臺(tái),該怎么辦?

辦法很多。要么就規(guī)定每次只能領(lǐng)取n個(gè)(n在試運(yùn)營(yíng)階段確定);要么發(fā)現(xiàn)庫(kù)存不足的時(shí)候,提前發(fā)出延遲供應(yīng)的免責(zé)聲明;要么就通過客服下線解決(比如兌換同價(jià)值商品或現(xiàn)金)。

總之,在這件事上,不把這種場(chǎng)景作為產(chǎn)品設(shè)計(jì)的考慮對(duì)象。即不為其開發(fā)對(duì)應(yīng)的產(chǎn)品功能,也不考慮其他辦法解決該問題帶來的不良的用戶體驗(yàn)。

因?yàn)楦鶕?jù)邊際效益,或者說產(chǎn)品定位來說,這種場(chǎng)景下的這號(hào)人就是排除項(xiàng)。既不是我們鼓勵(lì)的現(xiàn)象,也不是能為產(chǎn)品帶來價(jià)值收益的場(chǎng)景,同時(shí)花費(fèi)精力只能讓產(chǎn)品失去重心。

產(chǎn)品經(jīng)理在對(duì)待類似這種情況時(shí),要判斷出這是不是我們的目標(biāo)用戶和場(chǎng)景。如果不是,需在方案評(píng)審時(shí)或者在需求背景描述時(shí)候加以解釋,并果斷轉(zhuǎn)換解決方案。

二、需求的異常項(xiàng)

異常,主要包括目標(biāo)App本身的異常、手機(jī)系統(tǒng)環(huán)境引發(fā)目標(biāo)App的異常,和周邊平行應(yīng)用引發(fā)目標(biāo)App的異常。

1. App本身設(shè)計(jì)的異常

舉個(gè)例子,電梯中打開App,到達(dá)初始頁(yè)面【首頁(yè)】,界面顯示在加載。我們知道,這是網(wǎng)速問題。

這時(shí)候點(diǎn)擊【我的】菜單,想看草稿箱。但是發(fā)現(xiàn)無法打開【我的】。退出重啟,依然如此。

【我的】是本地文件,不依賴網(wǎng)速,卻為啥也打不開呢?

其實(shí)是因?yàn)榇a這樣定義的:打開App,要做一次初始頁(yè)面的加載,沒加載好,就不會(huì)允許其他操作。

這就導(dǎo)致了無需加載的【我的】頁(yè)面,雖然不依賴網(wǎng)速,但是因?yàn)橐蕾嚲W(wǎng)速的【首頁(yè)】沒完加載,所以“殃及池魚”,【我的】也打不開了。

因此,作為產(chǎn)品經(jīng)理,對(duì)于這種初次加載App的規(guī)制,就要做一個(gè)最長(zhǎng)加載時(shí)間的設(shè)置。比如,若2s仍舊加載不出來,則切換到無網(wǎng)情況下的機(jī)制展示(無網(wǎng)絡(luò)情況下可以查看頁(yè)面)。

2. 外部環(huán)境導(dǎo)致的異常

以系統(tǒng)的定位功能為例,正常情況下,若定位系統(tǒng)開啟,那么打開App,定位功能就會(huì)為App提供當(dāng)前位置,并展示在頁(yè)面。

但是若手機(jī)定位不開啟,那么APP的位置就無法獲取。

這時(shí)候就需要產(chǎn)品經(jīng)理考慮,在這種手機(jī)GPS異常(系統(tǒng)設(shè)置帶來的異常)情況下,位置顯示什么?比如是顯示空、還是圖標(biāo)。

同樣,如果手機(jī)未聯(lián)網(wǎng),或者網(wǎng)絡(luò)不通暢導(dǎo)致的加載失敗 ,就該提示“加載失敗,稍后再試”。

如果App檢測(cè)到斷網(wǎng)了,或者網(wǎng)速不好,就該更準(zhǔn)確地提示“網(wǎng)絡(luò)不佳”。

3. 平行應(yīng)用影響導(dǎo)致的App異常

比如,當(dāng)手機(jī)開啟藍(lán)牙,并且被另一個(gè)手機(jī)連上的時(shí)候,就會(huì)在手機(jī)頂部展示一行狀態(tài):1個(gè)連接。

這時(shí)候?qū)嶋H手機(jī)界面被這一行擠壓了。

遇到全屏播放的界面,就會(huì)出現(xiàn)下圖這樣:頂部Tab頁(yè)簽下移,視頻畫面不居中,底部菜單下移。

App是否有考慮過這種情況下的界面兼容呢?如果沒考慮,那么就會(huì)出現(xiàn)這一合理場(chǎng)景下的異常bug。

又比如,一個(gè)語(yǔ)音聊天應(yīng)用,當(dāng)按住home鍵切出去的時(shí)候、來電話的時(shí)候、當(dāng)用戶執(zhí)行其他應(yīng)用的時(shí)候等,該怎么規(guī)定呢?

作為產(chǎn)品經(jīng)理,拋磚引玉一個(gè)方案例子:

a.【語(yǔ)音聊天】時(shí) home鍵切出來,不影響聊的功能。

b.【語(yǔ)音聊天】時(shí) 不管是否切出去,若來電話(電話未掛斷的情況下) 則雙方屏蔽語(yǔ)音,但不掛斷。同時(shí)給對(duì)方toast提示:對(duì)方忙碌,馬上就好!

c.語(yǔ)音聊天時(shí) 切出去,看視頻、聽歌曲、打開其他應(yīng)用(如微信)進(jìn)行視頻等,都不影響語(yǔ)音聊天。(是否影響到效果,玩家自行處理)。

三、默認(rèn)值設(shè)置

1. 默認(rèn)頭像

這就像是統(tǒng)一制服一樣,不能因?yàn)檫@個(gè)孩子沒準(zhǔn)備衣服你就讓他裸著出場(chǎng)。所以要確定一個(gè)這樣的圖。

這個(gè)頭像可以是灰色底圖,比如花椒的就是。也可以定制帶產(chǎn)品元素的,比如映客的。

2. 默認(rèn)昵稱

好處就是萬一用戶懶得寫,也不至于空蕩蕩的。

產(chǎn)品經(jīng)理設(shè)計(jì)一個(gè)昵稱庫(kù),隨機(jī)給用戶分配昵稱,有時(shí)候還有意想不到的驚喜感。

個(gè)性簽名也是同樣的道理。

3.?默認(rèn)提示

在無數(shù)據(jù)的頁(yè)面,比如【好友列表】,如果不告訴用戶這里確實(shí)沒數(shù)據(jù)的話,用戶可能會(huì)懷疑是不是App故障導(dǎo)致的呢。

所以產(chǎn)品經(jīng)理一般都會(huì)給予一個(gè)默認(rèn)的全局通用的提示,比如“暫時(shí)無數(shù)據(jù)哦”。

4. 默認(rèn)封面

比如相冊(cè), 在網(wǎng)速不好的時(shí)候,加載不出來,那么怎么辦呢?黑洞洞的不好看,所以也需要產(chǎn)品經(jīng)理確認(rèn)一個(gè)默認(rèn)的封面或者數(shù)據(jù)背景圖。

這樣大家一看就明白了,哦,是沒加載出來啊。

5. 其他默認(rèn)項(xiàng)

默認(rèn)項(xiàng)總體上就是通用規(guī)范范疇的。遠(yuǎn)不止列舉的這幾項(xiàng)。產(chǎn)品經(jīng)理應(yīng)事先就做全局設(shè)計(jì),確保默認(rèn)項(xiàng)一致、通用,且不遺漏。

總結(jié)

一個(gè)產(chǎn)品可以拆解梳理出一份PRD;但是反過來,提供這份PRD給開發(fā),卻往往不能逆向地輸出同一個(gè)產(chǎn)品(假設(shè)UI一樣)。

這就是bug的誕生,和測(cè)試的必要性。

因此在確認(rèn)PRD的時(shí)候,就像素描,不僅要高光區(qū),還需要陰影區(qū)。

產(chǎn)品經(jīng)理在說完正向的要什么之后,還要說清楚不要什么、異常情況下怎么辦,以及默認(rèn)怎么辦。只有將細(xì)節(jié)說完備,才有可能讓需求完整落地。

 

作者:唧唧歪歪PM;公眾號(hào):唧唧歪歪PM(ID:jjyypm)

本文由 @唧唧歪歪PM 原創(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. 反面需求 用陰影區(qū) 劃分出 需求邊界

    來自湖南 回復(fù)
  2. 我一口氣看完了你所有文章

    回復(fù)
    1. 肺活量鯨人

      回復(fù)
  3. 請(qǐng)問這三項(xiàng)是不是屬于非功能需求里面的?

    來自湖北 回復(fù)
  4. 但是項(xiàng)目的需求分析是漸進(jìn)明細(xì)的。不可能一次性的做到事無巨細(xì)后再進(jìn)行開發(fā)。

    來自廣東 回復(fù)
    1. 來自湖南 回復(fù)
  5. 學(xué)習(xí)了

    來自廣東 回復(fù)
    1. 來自湖南 回復(fù)