全栈工程师?
嗯.....目前并不是!

產品不給力?可能是沒做好需求管理

有效的需求管理對於產品來說十分有必要,需求管理分為四個階段:採集、處理、實現、反饋。

巧婦難為無米之炊。

對於產品經理來說,需求就是用來煮飯的米。

但產品經理的工作可比熬一鍋粥要複雜多了,不光要基於需求設計產品,需求的管理能力也極其重要。

很多時候,糟糕的需求管理,會使產品工作亂成一團,甚至導致項目的失敗。

作為產品狗,需要經常體驗各種產品,也常遇到需求管理失敗的案例。

最近就有這麼一次糟糕的體驗:

一款定位小眾社交的App,名字就不說了。

產品邏輯是,通過心理測試,確定性格分型,匹配陌生人。

心理測試分為:初級、中級及高級等三個階段,每深入一級就更準確。然而,問題就出在心理測試上。

我在完成了高級測試后,測試結果依舊是中級的結果,高級測試的狀態則是未完成。

我嘗試了重新答題、重新登陸、註冊新號、甚至卸載重裝,老樣子。

換台iphone手機,問題依舊(android正常)。

於是,我在App內的用戶反饋功能中,詳細描述了該問題。

一周后,App更新,Bug依舊。

接着,我在Appstore上面通過評價的方式,再次詳細描述了該問題。

半個月後,App更新,Bug依舊。

最後,我按照官方網站的郵箱,講問題描述再次反饋。

一周后,App更新,Bug迎風招展。

在堅持了一個多月之後,我默默的放棄了它。

如此糟糕的Bug管理,絕不是偶然。今天順眼看了下在Appstore,簡直就是車禍現場。

(如下信息,是我按照一星進行的篩選,實際並非全部都是差評)

我如此執着地反饋問題,卻毫無結果,我只能推測:要麼他們看到了,卻沒有有效處理;要麼就是他們連看都沒有看到。不管是哪種,都說明需求管理能力缺失。

需求管理的重要性

產品經理工作的核心就是採集、加工和傳遞信息,而最重要的信息就是需求。就算idea再棒,就算開發效率再高,就算運營團隊推廣效果再好,需求管理不好,負面都會被不斷放大。

卸載前,我發了最後感悟:眼看他起朱樓,眼看他宴賓客,眼看他樓塌了。

你可能會有疑問,前面說的不是Bug么?

不論是反饋者,反饋渠道,或是反饋方式,Bug和需求都是共享的。

用戶訪談時,他會反饋需求,也會反饋Bug。

老闆找你溝通時,會提想法,也會告訴你他看到的問題。

所以我更傾向於,將Bug作為(廣義上的)需求的一種。狹義需求當作一種正向需求,而Bug則作為一種反向(優先級更高)需求。

同時,把Bug作為需求,還有一個優點。

像對待需求一樣,對Bug進行分析,而不是原封不動的直接拋給開發。

經過分析,你有可能發現它不是Bug,而是需要培訓用戶,或是轉化為新需求。而確定是Bug的,經過你的分析后再交給開發,本身已經完成搜集、復現和定位等環節,修復速度也必然會快很多。

下文所說的需求和需求管理,都是廣義上(除非特指)的。即將狹義需求和Bug都作為廣義需求來統一說明。

需求的種類

講需求管理之前,先對需求的種類做個全面認識。全面認識需求的種類(區分維度),有助於在管理需求時,做到兼顧所有情況。

需求的種類(區分維度)有:

  • 來源(提出方):用戶(客戶)、協作方(開發、運營、銷售、項目等)、管理層(投資人、老闆、上司)等;
  • 渠道:訪談、問卷、內部會議、內部系統、IM、產品內反饋、服務郵箱等;
  • 形式:錄音、錄像、文檔、郵件、會議記錄、留言、聊天記錄等;
  • 類型:就是前面說的,正向需求和反向需求(Bug)兩種;
  • 場景:正式使用、體驗產品、開發測試、產品演示等;
  • 緊急重要度:有很多方法,建議使用四象限法(重要緊急、重要不緊急、緊急不重要及不緊急不重要),或直接用1、2、3、4級代替。

需求管理的四個階段

需求管理全過程可以分為四個階段:

  • 需求的採集,維護高效穩定的採集渠道和合理的記錄規範;
  • 需求的處理,對採集到的需求進行篩選和加工明確;
  • 需求的實現,對加工明確后的需求進行規劃和開發;
  • 需求的反饋,反饋需求信息的處理給需求來源。

通過這四個步驟,做到對需求信息有效管理。

採集階段

採集階段,就是我們搜集並記錄需求信息的階段,是需求管理的起點。
首先,回憶一下:

  • 你是如何採集需求的?
  • 你日常獲得的需求中,有多少比例是提出者告知你的?
  • 你是否經常主動去獲取各類需求?
  • 你有主動維護需求獲取渠道的習慣么?

如果,你可以做到主動獲取各類需求,甚至主動維護需求獲取渠道,那麼你已經超過90%的產品經理。

而更常見的情況是,很多產品經理只被動接受需求,也從不維護需求來源。

前面已經講過,需求有多種來源、渠道和場景。

而每款產品,來源、渠道和場景之間的相關度也會不同。

比如,A產品的用戶更喜歡通過產品內的用戶反饋和郵件來反饋需求,但是B產品的用戶,則可能更喜歡面對面反饋信息。

多關注日常獲取到的需求信息,努力尋找和明確你的產品中,各類人群(來源)喜歡通過什麼途徑(渠道)反饋哪種類型(場景)的問題。

針對各類人群建立合適的反饋路徑,逐漸明白哪邊的需求多久採集一次,哪類人群需要採用什麼方法促進反饋。

慢慢你會發現,你能獲取到的信息會越來越全面,你離產品的真相也更進一步。

採集階段,光做好採集還遠遠不夠。

正如我那次糟糕的經歷,我相信,他們獲取到了我的反饋。

但也許很快,更多更雜的反饋出現,他們迷失其中……

沒有對信息的有效管理,信息就沒有任何價值。

做好了需求信息的開源,下一步就是做好需求信息的記錄。有效的記錄方法,不光可以讓需求變得有序,接下來的需求處理、需求實現、需求反饋,也依賴良好的記錄。

需求記錄,就是把一條條的需求記錄下來,同時補齊需求的種類等信息。

我習慣的做法是通過兩張表來管理所有的需求:

採集記錄表

所有採集的需求信息,均按照採集的順序編號記錄。

它是一張完整的需求表,事無巨細的記錄採集到的每一條需求(包括你覺得可笑的需求)。

僅供參考,可根據具體情況增減字段

僅供參考,可根據具體情況增減字段

處理跟蹤表
只記錄完成處理階段后,進入實現階段的需求。
它是一張指導產品規劃和實現的跟蹤表,只包含最後進入實際產品工作的需求。

僅供參考,可根據具體情況增減字段

僅供參考,可根據具體情況增減字段

為什麼要分成兩張表?

我先說只有其中一張,會怎麼樣。

如果只有「採集記錄表」:

每次使用這張表指導需求實現時,都會受到冗餘無效需求(那些在處理環節被篩選掉的)的干擾。

同時,如果你想在這張表上體現,歸屬什麼產品線、哪個版本實現、當前實現進度等,就必要增加字段。而這些多出來的字段,被篩選掉的需求卻並不需要。

最後,難道每次初步溝通需求時,都要讓老闆、同事都面對這麼一張龐大的信息表么?

如果只有「處理跟蹤表」:

也許你每次處理完需求,都把那些不做的需求給刪掉了……

但是,如果你發現一條需求有些熟悉,之前被你幹掉過,那你還能記起你當時處決它的理由么?

當你要反饋結果給提出者時(包括不做的理由),信息都沒了,你還怎麼反饋?

所以,我會把所有採集的需求記錄在「採集記錄表」,在處理階段繼續使用它。

處理過後的需求,保留的轉移到「處理跟蹤表」,在實現階段使用,同時定期更新回「採集記錄表」。否決的,直接在「採集記錄表」中記錄否決原因等信息。

反饋結果給需求提出者時,只看「採集記錄表」就好了。

處理階段

處理階段的工作有兩項:篩選需求和明確需求。

篩選需求

首先,對採集到的需求進行初步判斷,要不要讓它進入後續的實現階段。

要判斷正向需求(狹義需求)和反向需求(Bug)。

如果是Bug,判斷其是否真的是Bug。

如下情況,都不需要當作Bug來修復。

  • 用戶誤操作,導致出現問題。
    比如,企業管理員在中台誤操作刪除了用戶權限,導致他們的員工打不開報表。
  • 用戶不會使用功能。
    比如,管理員沒有將業務環節中必備的組織架構配置好,導致員工無法正常使用。
  • 功能不夠完善。
    比如,員工的填寫表單后,因為沒有自動保存功能,經常未保存退出,導致內容丟失。
  • 無法復現。
    比如,只有極少數情況下出現,反饋后在任何環境下,都無法再次出現的問題。

如上這些不需要修復的Bug,不代表就可以直接刪除了事。

需要針對具體情況,進行處理。

誤操作和不會使用的情況,我們需要反思,對客戶的培訓是否到位。

功能不夠完善的情況,我們可以轉化為新的狹義需求。

無法復現的情況,也要特別關注,如果再次出現,可以對比兩次情況,尋找可能性。

如果是(狹義的)需求,則判斷是否要去實現它。

狹義需求的取捨,主要依靠已經確立的產品戰略。

可以參照我的原創文章《如何系統性思考產品需求-產品問答第一篇》
這裡就不展開了。

所有決定不實現的需求,都需要對提出者進行有效反饋,留到反饋階段慢慢說。

明確需求

我們也需要對採集到的需求進行明確。

首先,明確需求的類型,到底是Bug還是狹義需求。

然後,我們要對需求的信息進行全面搜集。

1. 找需求來源進一步溝通,獲取更多信息;

大部分人在溝通時,都會對信息進行加工,這會產生信息缺失。

可能是覺得某些背景信息,大家都知道,不需要再說一遍;可能是覺得某些細節不是關鍵信息,所以故意略去;可能是完全沒有察覺某些相關信息。

信息的缺失,會讓需求變得難以理解或產生偏差。

找到需求的提出者進行溝通,使用“5W1H”提問法,不斷循序漸進的提問。

如果是Bug,要了解清楚它發生的具體場景,發生在什麼情況下,什麼機型,什麼系統,使用的賬戶,前面做了什麼操作等等;

如果是狹義需求,要了解提出它的背景,基於什麼場景,希望達到什麼目的,是否還有其他相關意願,偶然提出還是長久期望等等。

2. 對需求進行分析

獲取儘可能多關於需求的信息,對信息進行分析,進一步消化需求。

可以通過演繹法和歸納法,推斷出需求的規律和更深層次原因。

需求分析可參照《如何深入挖掘用戶需求-產品問答第二篇》,這裡不再展開。

3. 假設初步實現方案

對需求進行分析之後,在進入實施環節之前,我們可以嘗試初步假設多個實現方案。
在實現階段前,初步假設實現方案的好處有很多:

a.可以檢驗是否真的了解需求。

很多時候我們覺得已經完全了解需求,但是進行功能規劃時,才發覺還需要補充信息,又要找到提出者進行溝通。

b. 可以快速獲取反饋者的驗證。

具像化的方案,能讓提出者看到,他提出的需求是否得到理解,也讓他對產品產生期待。

c. 可以讓實現團隊快速理解需求。

提出多個初步方案,可以幫助實現團隊(產品和開發)快速理解需求,也可以讓他們更容易提出合理化建議,並為實現階段做好準備。

完成篩選和明確后,保留下來的需求,我們要確定重要緊急度及在哪個版本去實現。

你應該已經發現,篩選和明確並不是完全獨立,一前一後的工作。而是互相滲透,互相支撐。

需求的處理階段,你需要明確需求才能更好的篩選需求,同時篩選后確定實現的,也正是你要花更多力氣去明確的需求。

處理階段的信息,是在「採集記錄表」中更新。

經過處理階段,保留下來的需求,確定了實現版本和重要度,接着就進入實現階段了。

實現階段

實現階段有兩項工作:功能規劃和功能開發。

功能規劃

從處理階段傳遞過來的需求,安排了具體的產品線及版本,明確了優先級。

我們要做的就是把它們規劃成一個個的功能,並通過產品規劃交付物的方式來輸出給相關團隊。

這部分工作,是產品經理日常工作中,所佔比重最大的。

正因如此,很多產品經理沉溺其中,逐漸變成一個“畫原型的”或“寫文檔的”。這是很危險的!通過前面兩個階段介紹,你可以發現:做不好需求採集和處理,直接進行需求實現是多麼可怕。

具體的功能規劃,涉及到的方法論和工具,有許多書籍和文章都在講,我就不再贅述。

我要強調的唯一一點就是,提高對產品規劃交付物的標準。不要讓自己的原型和文檔,成為阻礙開發的障礙。有興趣可以看我這篇《產品問答 | 提崗管理后,如何進行團隊管理及項目管理?》。

功能開發

功能進行開發階段,產品經理的注意點就轉化為項目管理。
項目管理不僅僅要管理項目的進度,還要管理項目的質量。
同樣在《產品問答 | 提崗管理后,如何進行團隊管理及項目管理?》這篇文章中,我有詳細講。

實現階段的需求信息,要及時更新到「跟蹤記錄表」中。

反饋階段

需求不光要採集、處理和實現,還要不斷讓信息迴流,反饋給需求的源頭-提出者,讓需求管理成為閉環。

需求的反饋,不是等前三個階段完成後,再去獨立進行的。

在採集、處理和實現階段,要一直保持反饋的習慣。

  • 在採集階和處理階段,我們可能會不斷找反饋者溝通,以獲取更加全面的信息;
  • 在處理階段,我們反饋信息給提出者:需求是否要實現及何時實現,或是為什麼不實現;
  • 在處理階段,我們還要反饋初步方案,讓提出者確信併產生期待;
  • 在實現階段,我們要有節奏的反饋實現進展,並在實現時儘可能的告知提出者,甚至準備好相關培訓。

良好的需求反饋習慣,可以讓需求管理的可信度更高,而不是將功能規劃和開發變成“閉門造車”。

反饋階段主要維護「採集記錄表」,但需要及時將「跟蹤記錄表」的信息同步進去。

最後強調,需求管理的四個階段,也不是互相獨立,互分先後的。

實際的需求管理工作,可能會有多個階段的工作在同步進行。需求管理,需要你努力練習,完成技能內化,最終成為你的核心武器。

千萬別當一隻日夜操勞的工蜂!一個需求的搬運工,不是合格的產品人。

 

作者:十八子殺,微信公眾號:產品狗的思考(ID:PM-Doggy)。10年產品人,射手座,愛自由,喜攝影,好讀書,涉獵廣泛,望與同路人勉勵前行。

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《產品不給力?可能是沒做好需求管理》
文章链接:https://www.pmbear.com/%e7%94%a2%e5%93%81%e4%b8%8d%e7%b5%a6%e5%8a%9b%ef%bc%9f%e5%8f%af%e8%83%bd%e6%98%af%e6%b2%92%e5%81%9a%e5%a5%bd%e9%9c%80%e6%b1%82%e7%ae%a1%e7%90%86/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们