給沒完沒了的需求排個序

10 評論 8287 瀏覽 35 收藏 8 分鐘

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

開發(fā)產(chǎn)品的時候,我們每天都會面對各種各樣、沒完沒了的需求,有的來自外部用戶的反饋,有的來自內部團隊的 idea,有的是產(chǎn)品的 BUG,有的是新的功能……

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

問題是,需求會源源不斷地進來,我們永遠也不可能清空所有需求,996 也做不完,這輩子都不可能。

我們能做的,是不斷將需求排序,實現(xiàn)優(yōu)先級最高的需求。那么問題來了,我們應該如何給需求排序?

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

喬布斯曾經(jīng)說過:

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

用戶真的不知道他們想要什么嗎?很多時候并非如此。

我負責產(chǎn)品,每天都會和用戶交流,他們知道自己想要什么功能,有時會做好簡單的交互設計、幫忙想想算法、甚至給我開源代碼。

問題在于,用戶只是產(chǎn)品的使用者,他們對于產(chǎn)品的理解沒有我們那么深刻,所以他們提出的需求有時會偏離問題的本質,需要我們進一步分析與挖掘。

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

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

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

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

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

墨菲定律是這樣的:

Anything that can go wrong will go wrong.

程序員應該都知道,代碼怎么可能沒有 BUG 呢?很多時候只是我們沒有發(fā)現(xiàn),或者是知道了卻沒有及時修復。

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

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

還有一種微妙的情況,當用戶反饋貌似不可能出現(xiàn)的 BUG 時,我們會本能的覺得產(chǎn)品應該沒有問題,問題應該出在用戶那里,大概是他的瀏覽器或者網(wǎng)絡,或者某種無法解釋的原因導致的。其實,這只是我們在逃避問題,代碼的運行方式是確定的,沒有什么不能解釋的地方,如果什么地方不太對勁了,那基本上是 BUG。這里分享一個我們的經(jīng)歷:

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

我們總是這樣,不停地向前走,不斷地追求新的成就,逃避當下的問題。聽著是不是很像我們的生活?

對于產(chǎn)品 BUG,我們應該第一時間修復,或者設置一個 Deadline,新的功能可以稍微延后。

如果我們不停地開發(fā)新功能,那當初開發(fā)這個有 BUG 的舊功能究竟是為了什么?如果我們忽略當前用戶反饋的問題,那我們費這么大勁拉新是為了什么?

結論

需求管理是一門藝術,需要考慮和權衡的東西很多,暫時給大家一個簡單的優(yōu)先級排序,僅供參考:

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

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

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

參考資料

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

如何成為優(yōu)秀的技術主管?你要做到這三點

為什么美國程序員工作比中國程序員工作輕松、加班少?

 

作者:Fundebug的技術總監(jiān),歡迎添加微信交流:KiwenLau

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

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

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

更多精彩內容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 不太同意這樣的排序,比如自己發(fā)現(xiàn)的bug可能會造成嚴重后果,或不可挽回的損失,這樣顯然是最優(yōu)先要改的。而且我贊同喬布斯說的,用戶不知道自己想要什么,用戶大多數(shù)時候都是基于自己的認知和所處的環(huán)境,給出他認為正確的解決方案,一個用戶要很理性的告訴你他的需求都是很少的。一般來都會經(jīng)過他自己的預處理,再傳達給你。洞察不了需求背后的本質的產(chǎn)品,就是一個傳話筒。

    來自四川 回復
    1. 基于用戶反饋再去思考,文中也寫了:問題在于,用戶只是產(chǎn)品的使用者,他們對于產(chǎn)品的理解沒有我們那么深刻,所以他們提出的需求有時會偏離問題的本質,需要我們進一步分析與挖掘。

      來自福建 回復
  2. 身為一個乙方小產(chǎn)品,通常都是甲方爸爸說先做啥就做啥,絲毫沒有自主性

    來自山東 回復
    1. 哈哈哈哈哈哈 我也是

      回復
    2. 等同

      來自浙江 回復
  3. 確實需求源源不斷,Bug層出不窮,有時候覺得產(chǎn)品真的是超人,需要處理的事情多且復雜,邏輯思維差的做不了這行?。?/p>

    回復
    1. 首先思考優(yōu)先級,然后思考怎么做……

      回復
  4. 話說這個語言是api還是真人啊, 可以啊講的

    來自上海 回復
  5. 凱文, 我來給你點贊啦 ~

    來自上海 回復
    1. 一贊之恩 ?

      來自福建 回復