身為產(chǎn)品經(jīng)理，經(jīng)常會(huì)面對(duì)各種各樣的需求，并且這樣的需求還在源源不斷地增加，面對(duì)這種困境，需要給需求做好排序，按照優(yōu)先級(jí)去實(shí)現(xiàn)。

開(kāi)發(fā)產(chǎn)品的時(shí)候，我們每天都會(huì)面對(duì)各種各樣、沒(méi)完沒(méi)了的需求，有的來(lái)自外部用戶的反饋，有的來(lái)自內(nèi)部團(tuán)隊(duì)的 idea，有的是產(chǎn)品的 BUG，有的是新的功能……

看起來(lái)只要實(shí)現(xiàn)所有需求，產(chǎn)品就可以變得更好，然后吸引更多的用戶，接著賺更多的錢，之后招更多的人，再完成更多的需求……

問(wèn)題是，需求會(huì)源源不斷地進(jìn)來(lái)，我們永遠(yuǎn)也不可能清空所有需求，996 也做不完，這輩子都不可能。

我們能做的，是不斷將需求排序，實(shí)現(xiàn)優(yōu)先級(jí)最高的需求。那么問(wèn)題來(lái)了，我們應(yīng)該如何給需求排序？

以用戶為核心確定優(yōu)先級(jí)

喬布斯曾經(jīng)說(shuō)過(guò)：

People don’t know what they want until you show it to them.

用戶真的不知道他們想要什么嗎？很多時(shí)候并非如此。

我負(fù)責(zé)產(chǎn)品，每天都會(huì)和用戶交流，他們知道自己想要什么功能，有時(shí)會(huì)做好簡(jiǎn)單的交互設(shè)計(jì)、幫忙想想算法、甚至給我開(kāi)源代碼。

問(wèn)題在于，用戶只是產(chǎn)品的使用者，他們對(duì)于產(chǎn)品的理解沒(méi)有我們那么深刻，所以他們提出的需求有時(shí)會(huì)偏離問(wèn)題的本質(zhì)，需要我們進(jìn)一步分析與挖掘。

我們不是喬布斯，沒(méi)有能力創(chuàng)造需求；我們也不是張小龍，沒(méi)有 1 億人教我們做產(chǎn)品。因此，我們應(yīng)該多與用戶交流，以用戶需求為核心確定優(yōu)先級(jí)：

• 用戶反饋或者吐槽的時(shí)候，耐心一些，聊得更深入一些，同時(shí)做好記錄
• 修復(fù) BUG，優(yōu)化功能或者新增功能時(shí)，與感興趣的用戶主動(dòng)聯(lián)系，他們會(huì)給你更多的反饋
• 定期做用戶調(diào)研，聽(tīng)聽(tīng)沉默的大多數(shù)是怎么說(shuō)的
• 對(duì)于用戶所提的需求，根據(jù)反饋用戶多少、影響范圍、難易程度進(jìn)行排序

當(dāng)我們做產(chǎn)品的時(shí)候，創(chuàng)造的欲望是非常驚人的，總會(huì)有一些新的 idea 讓我們激動(dòng)不已，恨不得明天就能上線。但是，我們應(yīng)該克制自己的創(chuàng)造欲，尊重用戶的意見(jiàn)。我們的產(chǎn)品是給客戶用的，不是給自己玩的。

流量紅利已經(jīng)枯竭的時(shí)代，獲取一個(gè)新用戶比留住一個(gè)老用戶難太多了，因此提高留存率顯得非常重要。重視每一個(gè)用戶反饋，及時(shí)修復(fù)他們發(fā)現(xiàn)的 BUG，優(yōu)先實(shí)現(xiàn)他們想要的功能，是提高留存率最有效的方式，沒(méi)有之一。

BUG 的優(yōu)先級(jí)高于新功能

墨菲定律是這樣的：

Anything that can go wrong will go wrong.

程序員應(yīng)該都知道，代碼怎么可能沒(méi)有 BUG 呢？很多時(shí)候只是我們沒(méi)有發(fā)現(xiàn)，或者是知道了卻沒(méi)有及時(shí)修復(fù)。

然而，對(duì)于當(dāng)前產(chǎn)品的 BUG，我們往往容易忽視?？赡苁?BUG 隱藏的太深，我們和用戶都沒(méi)有發(fā)現(xiàn)；可能是用戶發(fā)現(xiàn) BUG，但是沒(méi)有反饋；也可能是我們選擇性失明，覺(jué)得問(wèn)題不大。

事實(shí)上，用戶對(duì)產(chǎn)品質(zhì)量的要求非常嚴(yán)格，再小的問(wèn)題他們也會(huì)發(fā)現(xiàn)，也會(huì)吐槽。用戶反饋的話我們還能知道，否則我們可能很晚才發(fā)現(xiàn) BUG，如果沒(méi)有監(jiān)控的話。

還有一種微妙的情況，當(dāng)用戶反饋貌似不可能出現(xiàn)的 BUG 時(shí)，我們會(huì)本能的覺(jué)得產(chǎn)品應(yīng)該沒(méi)有問(wèn)題，問(wèn)題應(yīng)該出在用戶那里，大概是他的瀏覽器或者網(wǎng)絡(luò)，或者某種無(wú)法解釋的原因?qū)е碌?。其?shí)，這只是我們?cè)谔颖軉?wèn)題，代碼的運(yùn)行方式是確定的，沒(méi)有什么不能解釋的地方，如果什么地方不太對(duì)勁了，那基本上是 BUG。這里分享一個(gè)我們的經(jīng)歷：

• 某個(gè)用戶反饋，他在邀請(qǐng)成員加入團(tuán)隊(duì)的時(shí)候發(fā)現(xiàn)，偶爾會(huì)有那么一次邀請(qǐng)失敗。
• 我們檢查了一下監(jiān)控?cái)?shù)據(jù)，發(fā)現(xiàn)確實(shí)有失敗過(guò)，影響的用戶不止一個(gè)，但是很少。
• 然后，我們檢查了一下前后端代碼，發(fā)現(xiàn)沒(méi)有問(wèn)題。
• 既然業(yè)務(wù)代碼沒(méi)有問(wèn)題，那應(yīng)該沒(méi)有BUG，這事大概是什么奇怪的原因?qū)е碌?，我們什么也不用做?#8230;
• 后來(lái)，又有幾個(gè)用戶反饋同一個(gè)問(wèn)題，報(bào)錯(cuò)也越來(lái)來(lái)越多，我們不可能再騙自己了！
• 再次檢查，業(yè)務(wù)代碼確實(shí)沒(méi)有問(wèn)題，但是報(bào)錯(cuò)的代碼位置的行號(hào)和列號(hào)都偏移了，這么詭異？
• 不難猜測(cè)，生產(chǎn)環(huán)境運(yùn)行的是舊代碼！檢查一下果然是這樣。
• 接著，不難發(fā)現(xiàn)部署的Docker配置文件有問(wèn)題，導(dǎo)致某個(gè)節(jié)點(diǎn)部署的后端代碼是舊的…

我們總是這樣，不停地向前走，不斷地追求新的成就，逃避當(dāng)下的問(wèn)題。聽(tīng)著是不是很像我們的生活？

對(duì)于產(chǎn)品 BUG，我們應(yīng)該第一時(shí)間修復(fù)，或者設(shè)置一個(gè) Deadline，新的功能可以稍微延后。

如果我們不停地開(kāi)發(fā)新功能，那當(dāng)初開(kāi)發(fā)這個(gè)有 BUG 的舊功能究竟是為了什么？如果我們忽略當(dāng)前用戶反饋的問(wèn)題，那我們費(fèi)這么大勁拉新是為了什么？

結(jié)論

需求管理是一門藝術(shù)，需要考慮和權(quán)衡的東西很多，暫時(shí)給大家一個(gè)簡(jiǎn)單的優(yōu)先級(jí)排序，僅供參考：

• 用戶反饋的 BUG；
• 自己發(fā)現(xiàn)的 BUG；
• 用戶反饋的需求；
• 自己想出的需求。

嚴(yán)格按照這個(gè)順序操作是不可能的，這是給大家提供 2 個(gè)思考維度。實(shí)際工作中，每個(gè)需求的影響范圍、緊急程度、難易程度也需要考慮。

你有什么更好的想法嗎？歡迎留言討論！

參考資料

產(chǎn)品需求優(yōu)先級(jí)的藝術(shù) – Kano 模型

如何成為優(yōu)秀的技術(shù)主管？你要做到這三點(diǎn)

為什么美國(guó)程序員工作比中國(guó)程序員工作輕松、加班少？

作者：Fundebug的技術(shù)總監(jiān)，歡迎添加微信交流：KiwenLau

原文地址：https://blog.fundebug.com/2019/03/05/how-to-sort-requirements/

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

題圖來(lái)自Unsplash，基于CC0協(xié)議