我的產品方法論之需求分析(下)
需求分析就是:觀察——篩選——判斷——迭代。這同樣是一個產品的從零到一的發展歷程,每一步都任重而道遠。
1
今天終于要完結了,內心還是忐忑不安的,一方面特別興奮,能夠將自己的學習與實踐經驗認真總結,并得到了同行的認同,另一方面,我擔心自己如何收場,與資深玩家相比,我深知有不小差距,不過我會嘗試通過自己的思考來幫助大家梳理。
2
今天的主要話題是需求管理、需求池與版本迭代。
前文說到,作為產品經理,需求分析的核心方法分別為:
- 在遇見單個需求時,首先要分析用戶、場景、問題以及現有解決方案,利用思維導圖將思考過程完整記錄并梳理,從中篩選并提煉出最有價值的信息與開發方向。
- 在遇見海量需求時,要明確需求優先級排序原則,逐一運用四象限分析法來判斷,然后再結合公司產品發展階段與具體場景來思考。
這些都是十分具體而復雜多樣的,在日常工作中,我們難免遇到各式各樣的需求,第二篇文章中我也有所提及,例如:
- 場館需要增加視頻入口,從而擴大現場曝光,突出智慧場館優勢,進而做到線上線下雙重結合;
- 電商模塊需要在訪問量較大的頁面上增加彈窗或是提示,以此結合具體場景來實現銷售轉化;
- 新賽事系統上線后,領隊反饋需要了解賽事進程,修改比分或是撤銷比賽,給予賽事管理者較大的靈活性。
這些都是內部或外部需求的舉例,我們第一步要做的當然是區分不同來源進而梳理需求。
1. 領導、同事
一般而言,在公司所在行業,領導與同事都是對業務十分熟悉并且思考更為獨到,無論是工作溝通還是開會討論都能夠碰撞出火花。當然,他們的訴求點可能更偏向于商業利益,有時我們很難理解他們的決定,這時候就需要認真記錄并且后續深入溝通了。
2. 行業調研與競品挖掘
這考驗產品經理甚至是整個公司的行業趨勢與動態的敏感程度,有時我們在專心按照規劃做產品時,很容易忽視其他競爭對手或是行業動態,這就需要產品經理在日常工作中多關注行業數據與動態。
行業數據可參考艾瑞咨詢、企鵝智酷、QuestMobile 等,競品調研可參考 App Annie、各大應用市場中同行業產品,從中挖掘出背后的商業與產品邏輯。
若是一味地閉門造成,后果就是,團隊想出來的靈感早就被人家鉆研并且實踐了,此外,別人不做的功能說不定早就已經被市場拋棄了。
最好的辦法就是讓團隊的每一個成員都關注其他產品的功能更新,然后再開會討論,由產品負責人統一管理。
3. 用戶、客戶反饋
產品面向的對象一般為大眾用戶或是企業級客戶,他們是產品的直接使用者與反饋者,通常會通過評價、投訴、分享等方式向客服反饋,我們需要特別關注。特別是早期階段的種子用戶,他們對于產品的態度能夠讓我們在第一時間了解產品功能與體驗上的問題,從而更快地迭代。
3
這里,我們就不得不提及需求池這個概念了:
從名稱上我們不難看出,需求池是各方需求的集合與整理,這些需求是我們在工作中提出的想法或是問題,但是尚未實際開發或是梳理。
建立需求池的理由特別簡單:每個人都是健忘的,很多靈感或是想法當時大家興致勃勃,后續執行很容易偏離軌道,第二天再來詢問,發現自己已經全然不知需求產生的背景與解決方向。
因而,我們必須通過需求池來記錄并且尋求更深入的解決方案。
首先,我們要明白,每個團隊都有一堆待辦事項,作為產品經理,首要任務就是了解并掌握你所負責的產品,版本的演變過程以及未來迭代的方向,這一方面大公司文檔或是信息溝通可能更為完善,小公司基本上就是通過上級領導或是同事來解答,剩下的就自己體驗一遍,這樣做其實效率很低,大部分人只有在遇見具體問題時才會深入去思考。
推薦做法是向公司了解是否有項目文檔或是相關產品業務介紹與說明,然后下載最新的產品自己體驗,一方面熟悉公司業務,另一方面作為用戶體驗并發現問題,最后,通過?App Annie 等同類型的數據統計或工具來詳細了解迭代過程。
通過以上步驟,你會有較為清晰的業務輪廓,這時再與公司交流未來的版本究竟如何事半功倍。
無論是個人還是團隊,都需要通過需求池來了解想法并且適時推進。
圖片:App Annie – 極客時間
其次,我們究竟如何高效方便地管理需求池呢?
常見的需求池工具如下:
- Excel:個人特別合適,每天的溝通與交流都有明確的指向與展示,然而對于團隊而言,十分麻煩,即便有同步工具,還是很難處理并且無法了解動態。
- Worktile:個人與團隊皆有,個人版側重于任務管理與資料記錄,企業版關注內部管理與信息同步,這是我個人一直在使用的工具,同時與 Excel 相結合。
- Teamabition/Tower:團隊特別合適,這是項目管理與團隊信息同步的工具,若是要采用,必須要求團隊統一思想,一起使用,否則毫無意義。
- Trello/JIRA:它們都是國外公司所開發,功能強大,但受限于互聯網政策,采用的公司不多。
- 禪道:這是一款適合團隊的應用工具,專注研發項目管理,支持敏捷開發過程。目前公司就是采用這款工具,優點是所有模塊清晰準確,缺點是無法即時同步信息。
4
接下來,當我們采用了合適的需求池工具后,我們必須認真思考需求收集這個過程:
需求收集
在這里,我們要清楚地描述需求得到的背景與狀況,通過反饋者、受影響用戶、描述問題并且補充信息幾個方面來闡述。
客服告訴技術:今天有用戶反饋掃碼無法開門,希望你們處理下。
矛盾就很容易產生,因為缺乏必要的信息我們就無法判斷問題的起因與解決方案。
我們再來看更為專業的方式,你們感受下差異:
今天用戶 XXX,手機號碼 XXXX(反饋者)打電話給我,他昨天下午四點在南江苑的訂單無法掃碼開門,提示他服務器異常(描述問題),他是用 IOS V3.1 ?版本的韻動網球 App 掃碼的(補充信息),希望你們盡快處理。
兩者相比,高下立見。
需求整理
需求收集后,我們接下來需要整理需求,推薦采用流程來處理:
- 第一步,判斷這個問題是屬于 Bug、改進還是全新需求?
- 第二步:這個需求是有效的還是無效的?
- 第三步:我們是否要做?我們如何做?
流程如下圖所示(圖片),思維導圖分析和四象限分析法在前兩篇文章中已經充分闡述了。
圖片:需求分析流程(ProcessOn)
那我們再來看上面的需求如何按照流程處理:
根據信息,用戶無法掃碼開門,原因為服務器異常,這顯然是屬于重要且緊急的 Bug,并且十分重要,可能會涉及更多訂場用戶,需要立即修復,這是影響用戶體驗的巨大問題。
需求反饋
需求反饋也有原則需要執行:
- 盡量當下反饋結果;
- 盡量真實反饋結果;
- 進入需求池后,盡量有行動計劃。
無論是立即修復,還是無法復現,無論是接下來版本上線,還是暫無關注,我們都需要告知反饋者相應結果,并適時調整需求池內容。
綜上所述,我在結合上述思考后為公司提出的需求反饋原則如下:
向項目或產品負責人反饋問題,說清楚具體問題與反饋渠道。
統一收集需求池,將反饋分為 Bug、改進與新增,Bug 提交禪道,直接交由相關人員處理并告知反饋者結果,改進和新增則進入下一版本需求,同時調整產品開發優先級。
5
最后,我們要明確產品需求與版本的關系。
在我看來,版本是圍繞著產品需求來設定的,我們先要了解公司的產品線,一般會分為官網及后臺、App、微信公眾號網站、小程序、運營 H5 等幾類。
關于如何定義版本號,互聯網公司的方法多種多樣。我倒認為,方式是次要的,而核心是讓團隊輕松理解并且統一思想與認知,最為簡單的方式就是:
主需求我們可以采用 V1.0 來表示,例如訂場、電商、課程等都是產品的主要模塊;
若有與主需要相關的其他需求,可以采用 V1.1 的版本號,例如場館中增加視頻入口與視頻播放,
若是修復 Bug 或是改進等需要單獨跟進,可以采用 V1.01、1.02 來區分,例如最后兩片場地捆綁銷售、過了當前時間還能夠訂場等。
至于何時發版本,這需要各方(市場、產品與技術)開會討論確定,根據需求的優先級以及開發進度來控制,當然,最終確認只能視具體請可定,這里就不展開討論了。
6
聊了這么多關于需求分析的那些事,想必大家已經有了更為深入的理解與認識了。需求真的不是一件小事,通過這些思考,轉念一想,自己未來還得和它打交道,內心還是充滿期待的。
總結就是,需求分析就是:觀察——篩選——判斷——迭代。這同樣是一個產品的從零到一的發展歷程,每一步都任重而道遠。
本文最后,奉上我自己總結的產品開發流程,這是我個人對于從需求分析到產品上線整個流程的分析,我會在后續的文章中對每一部分盡力闡述與思考。同時,歡迎分享你的見解與思考。
圖片:產品開發流程(ProcessOn)
希望你能夠有所啟發。
相關閱讀
作者:劉禎(公眾號「聽天由己」),現在互聯網體育領域創業,擔任產品經理。
本文由 @劉禎 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖由作者提供
很好,非常感謝
很好,感謝。
不錯,贊一個!