陕西快乐十分开奖预测|陕西快乐十分今日开奖结果查询
  • 產品不給力?可能是沒做好需求管理

    /2019-04-09 13:50:44/

  • \

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

    巧婦難為無米之炊。

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

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

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

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

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

    一款定位小眾社交的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. 可以讓實現團隊快速理解需求。

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

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

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

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

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

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

    實現階段

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

    功能規劃

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

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

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

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

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

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

    功能開發

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

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

    反饋階段

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

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

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

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

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

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

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

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

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

<
上一篇: 小團隊有大能量,聊聊背后的科學依據 下一篇: CRISP-DM:人工智能產品規劃流程

聯系我們

一個新的需求,從這里開始。歡迎填寫表格或發送合作郵件至: [email protected] [email protected] 加微信: 13765801787

13765801787
在線留言
陕西快乐十分开奖预测 四川成都麻将 ff14最赚钱 pc蛋蛋 陕西福利彩票快乐10分钟 网络捕鱼游戏大厅下载 52吉林麻将下载 重庆快乐10分助手 2012足球直播表 909棋牌游戏大厅 在yy怎样赚钱是真的吗 贵州快三走势图一定牛一定牛 电竞比分网 黑龙江快乐10分开奖官网 淘宝快3的开奖时间 北京快中彩 重庆时时彩五星3码必中