產(chǎn)品方法論:我的一些經(jīng)驗(yàn)

18 評(píng)論 57575 瀏覽 466 收藏 12 分鐘

在B端產(chǎn)品的工作當(dāng)中,常常要與不同的業(yè)務(wù)部門打交道,他們的角色眾多、訴求各有差異,造就了后臺(tái)業(yè)務(wù)產(chǎn)品的復(fù)雜性,下面介紹一下我在國內(nèi)排名第一的房產(chǎn)中介公司工作以來總結(jié)的一套產(chǎn)品方法論。

需求梳理

我們常常收到來自用戶(業(yè)務(wù)部門)或老板,以一句話高度概括提出的需求:“我需要對(duì)掛牌房源進(jìn)行回訪,并進(jìn)行判定”、“我需要一個(gè)對(duì)網(wǎng)站400來電錄音進(jìn)行打分的平臺(tái)”……因此,需要一個(gè)框架有序、完整的與用戶一起梳理需求十分有必要。

需求梳理框架:用戶-場(chǎng)景-路徑

用戶

在B端產(chǎn)品中,用戶即業(yè)務(wù)部門或前線業(yè)務(wù)人員的角色。

在面對(duì)分工精細(xì)的企業(yè)內(nèi)部,我們可以從“現(xiàn)在是怎樣的?”去入手了解當(dāng)前的部門架構(gòu)、崗位分工。

因?yàn)樗袠I(yè)務(wù)線,無論它現(xiàn)在如何低效或我們看來是多余的,但也是多年來一直優(yōu)化,被證實(shí)有效的才得以保留和運(yùn)作至今。所以即使新產(chǎn)品基于新流程、新技術(shù),可以節(jié)省某些職能角色的參與,也只有從了解現(xiàn)有架構(gòu)開始,理解現(xiàn)時(shí)為何這樣配置,每個(gè)崗位有何目的和作用,才不至于在產(chǎn)品上線后,才發(fā)現(xiàn)一些業(yè)務(wù)部門隱藏的需求。

這一步,我們的目標(biāo)是了解有哪些人(角色),會(huì)參與到這個(gè)產(chǎn)品流程中。

場(chǎng)景

即:在什么場(chǎng)景下,有什么需求,要完成什么目標(biāo)。把每個(gè)角色的場(chǎng)景、需求、目標(biāo)都一一列出來,然后把需求打碎、重組,即可定義出相關(guān)的功能。

這一步可以結(jié)合思維導(dǎo)圖,采用發(fā)散思維方式,與用戶一起完全窮盡各種可能發(fā)生的情況,再結(jié)合業(yè)務(wù)的考慮,提出對(duì)應(yīng)的解決辦法,與用戶敲定。

如何窮盡所有可能?這里有個(gè)小技巧:把問題拆解為一個(gè)個(gè)小問題,對(duì)每個(gè)小問題追問下去,直至無解、清楚為止。

舉個(gè)例子:400來電錄音檢核平臺(tái)的需求:來電錄音采用輪循機(jī)制隨機(jī)分配給AE(Agent Energize,經(jīng)紀(jì)賦能師)檢核,以提升經(jīng)紀(jì)人接聽來電的服務(wù)水準(zhǔn)和規(guī)范。

數(shù)據(jù)來源:

  1. AE的職位架構(gòu)取自哪里?K3人事系統(tǒng)?雖然從常識(shí)可以知道人事數(shù)據(jù)來源于人事系統(tǒng),但剛好本例是特例,由于歷史原因,受限于K3系統(tǒng)的限制,“AE”這個(gè)的職位數(shù)據(jù)來源二手業(yè)務(wù)系統(tǒng)。所以如果新接觸一個(gè)新角色,特別在歷史悠久的公司,最好先與開發(fā)溝通,確定數(shù)據(jù)的來源,甚至如果當(dāng)前不存在此架構(gòu)數(shù)據(jù),如何進(jìn)一步處理。
  2. 錄音來自于哪里?本例中,錄音來自于北京總部每天會(huì)發(fā)送前一條的錄音數(shù)據(jù)文件給我們,我們作為分公司再進(jìn)一步導(dǎo)入處理。這里涉及到兩地技術(shù)對(duì)接、協(xié)商處理。

邊界情況:

  1. 已分配錄音后,AE離職,錄音無人檢核,是否需要重新分配?
  2. 假如離職錄音重新分配,錄音是否有時(shí)效性,比如只分配當(dāng)月未檢核的錄音?否則將會(huì)影響到報(bào)表周期的數(shù)據(jù)
  3. 如果總部沒有按照約定,在特定試點(diǎn)發(fā)送前一天錄音給我們,后備方案怎么處理?
  4. ……

以上只是簡單舉例,實(shí)際情況要進(jìn)行更多的考慮。

路徑

即:完成任務(wù)所需的流程,用流程把功能串聯(lián)起來。

這一步推薦使用泳道圖,清晰表達(dá)角色之間的任務(wù)流程,和相互的關(guān)聯(lián)。

如果項(xiàng)目比較復(fù)雜,可以用流程圖再進(jìn)一步詳細(xì)描述各個(gè)子流程。

這里稍微提升一下思維高度:不論何種形式的圖表,目的是與業(yè)務(wù)部門和團(tuán)隊(duì)成員溝通,所以選擇的圖表只要大家看得明白,實(shí)現(xiàn)高效溝通即可。

通過以上三個(gè)需求分析框架,我們已經(jīng)能夠清晰與用戶溝通,了解用戶所需的需求,并通過進(jìn)一步發(fā)掘、整合設(shè)想出產(chǎn)品的框架和主要功能。

確定系統(tǒng)信息流、相關(guān)主體

系統(tǒng)信息流

B端的業(yè)務(wù)系統(tǒng),往往需要與很多其他基礎(chǔ)服務(wù)(OA辦公、人事、財(cái)務(wù)、通訊等)、不同業(yè)務(wù)系統(tǒng)間的對(duì)接。因?yàn)檫@些對(duì)接往往決定了新產(chǎn)品的數(shù)據(jù)來源、實(shí)現(xiàn)限制和接口規(guī)范,在動(dòng)手寫需求文檔之前,不妨先與開發(fā)交流一下各關(guān)聯(lián)系統(tǒng)的對(duì)接要求,以便可以寫出更規(guī)范完整的需求文檔。當(dāng)然,一些基礎(chǔ)性服務(wù),如果團(tuán)隊(duì)間默契已經(jīng)形成,可以節(jié)省這個(gè)步驟。

相關(guān)主體

在業(yè)務(wù)上,除了在產(chǎn)品內(nèi)部的操作,還有很多是線下或?qū)ν獠肯到y(tǒng)的操作。如何簡單表述出參與者完整的業(yè)務(wù)活動(dòng)?這里推薦使用——UML用例圖。

用例圖有助于討論和傳達(dá)以下內(nèi)容:

  1. 您的系統(tǒng)或應(yīng)用程序與人、組織或外部系統(tǒng)進(jìn)行交互的幾種方案。
  2. 它幫助參與者實(shí)現(xiàn)的目標(biāo)。
  3. 系統(tǒng)的范圍。

舉個(gè)例子。網(wǎng)簽預(yù)約系統(tǒng)項(xiàng)目:接案專員在網(wǎng)簽預(yù)約系統(tǒng)(內(nèi)部產(chǎn)品)收到經(jīng)紀(jì)人的預(yù)約案件后,需要在房管局的“存量房預(yù)簽約系統(tǒng)”進(jìn)行相關(guān)操作,把導(dǎo)出的成交合同上傳到網(wǎng)簽預(yù)約系統(tǒng)(內(nèi)部產(chǎn)品)以繼續(xù)后續(xù)的確認(rèn)簽約流程。

這個(gè)案例涉及幾個(gè)主體:

  1. 經(jīng)紀(jì)人
  2. 接案專員
  3. 房管局的“存量房預(yù)簽約系統(tǒng)”
  4. 本產(chǎn)品:網(wǎng)簽預(yù)約系統(tǒng)

使用用例圖即可清晰表達(dá)劃分以上主體及其主要功能(任務(wù)),最大好處是以最簡潔、高度概括的外部視角與用戶(業(yè)務(wù)部門)溝通確認(rèn)需求,確保對(duì)復(fù)雜的業(yè)務(wù)過程理解一致。

項(xiàng)目范圍

我把項(xiàng)目范圍歸納為三種邊界:需求邊界、行業(yè)邊界、系統(tǒng)邊界。

需求邊界

需求理應(yīng)沒有邊界,但如果要實(shí)現(xiàn)需求,則存在資源等各種客觀原因,使需求有了優(yōu)先級(jí)——即版本規(guī)劃。我們可以根據(jù)B端產(chǎn)品的特性,結(jié)合業(yè)務(wù)的迫切程度,劃定優(yōu)先級(jí)的判定標(biāo)準(zhǔn),如果你的公司習(xí)慣項(xiàng)目時(shí)間由老板拍板,我這里建議其中一種辦法是:在產(chǎn)品初步策劃階段,拓寬思路,盡可能規(guī)劃完整的產(chǎn)品,向老板、決策者展現(xiàn)完整的目標(biāo)成果。然后,列出各種功能的建議優(yōu)先級(jí)和所耗資源,提請(qǐng)老板根據(jù)時(shí)間期限決定實(shí)現(xiàn)的優(yōu)先級(jí),定下此版本的項(xiàng)目范圍,即交給老板做減法。

行業(yè)邊界

如果我們?cè)O(shè)計(jì)的是會(huì)計(jì)、人力資源等專有行業(yè)的系統(tǒng),我們就不能天馬行空,系統(tǒng)的規(guī)則離不開行業(yè)的法律法規(guī),比如會(huì)計(jì)就像一個(gè)正方形,法律法規(guī)已經(jīng)設(shè)好邊界,我們所做的是在邊界內(nèi)設(shè)計(jì);人力資源的HRBP系統(tǒng)則像一個(gè)水桶,半開放式,有其自由性。所以我們?cè)O(shè)計(jì)產(chǎn)品的時(shí)候,第一是要深入發(fā)掘公司業(yè)務(wù)的需求,理解業(yè)務(wù),通過產(chǎn)品、技術(shù)去提升公司效益;第二是熟悉行業(yè)相關(guān)法律法規(guī),清晰產(chǎn)品的底線要求。為什么自己也要了解?因?yàn)闃I(yè)務(wù)人員很可能會(huì)認(rèn)為一件在TA看來不言而喻的事情,而你作為行業(yè)外的設(shè)計(jì)者,根本不知道,產(chǎn)生需求盲點(diǎn),直至產(chǎn)品上線才發(fā)現(xiàn)問題。

系統(tǒng)邊界

一個(gè)產(chǎn)品,只應(yīng)該為解決一個(gè)(類)問題而生。我們最常接觸的業(yè)務(wù)系統(tǒng),雖然業(yè)務(wù)多變,形態(tài)千變?nèi)f化,每間公司有其特性,但只有找準(zhǔn)主心骨,產(chǎn)品才可以有序健康地發(fā)展,我們可以用魚骨型去比喻它。沒有規(guī)劃的系統(tǒng),將會(huì)越來越變得臃腫難用,或會(huì)有一天系統(tǒng)不足以支撐而崩潰。要避免這個(gè)問題,有幾點(diǎn)心得:

  1. 用程序上解耦的思維,把業(yè)務(wù)按事件拆分成各自獨(dú)立的小產(chǎn)品,特別是把共性的基礎(chǔ)業(yè)務(wù)部分獨(dú)立出來,其他程序需要時(shí)其能力時(shí)調(diào)用接口即可。當(dāng)一個(gè)業(yè)務(wù)變化時(shí),不會(huì)令其他產(chǎn)品受到牽連,靈活性高。
  2. 拒絕不合理需求。雖然B端產(chǎn)品是很多是基于業(yè)務(wù)部門提出的“需求”,但用戶往往習(xí)慣以自己的見解提出他們認(rèn)為合適的解決方案,我們作為專業(yè)的產(chǎn)品設(shè)計(jì)者,應(yīng)該學(xué)會(huì)分辨是需求還是解決方案,發(fā)覺出用戶真正的需求,從全局考慮,整合需求,提出更好的解決方案。
  3. 一個(gè)產(chǎn)品,只應(yīng)該為解決一個(gè)(類)問題而生。如果一個(gè)產(chǎn)品放到了一個(gè)不合適的地方,將會(huì)為未來留下隱患。在面對(duì)各種各樣的需求時(shí),我們應(yīng)該清晰什么需求應(yīng)該在什么地方(產(chǎn)品)解決。就像業(yè)務(wù)系統(tǒng)不應(yīng)該存放人事數(shù)據(jù)一樣。

小結(jié)

最后,分享一下在實(shí)際工作中,產(chǎn)品上線真正的使用者和需求提出者很可能不是同一個(gè)人,需要我們想辦法接觸到實(shí)際操作同事,了解一下他們的想法,考慮到產(chǎn)品中去;需求溝通初步階段,也很可能沒有業(yè)務(wù)部門的主管(有決策權(quán))或所有干系部門參與,所以當(dāng)已有初步方案,一定要找所有與產(chǎn)品有干系的業(yè)務(wù)部門的主管落實(shí)方案,達(dá)成共識(shí),避免上線后才發(fā)現(xiàn)溝通存在問題。

 

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

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. B端產(chǎn)品的需求文檔究竟該怎么寫,尤其是遇到那種邏輯復(fù)雜,體量龐大的系統(tǒng)。我每次的文檔感覺都是偏頁面交互說明。具體到業(yè)務(wù),邏輯,就不知道怎么敘述了。。。很想有個(gè)規(guī)范能參考下。

    來自湖北 回復(fù)
  2. 需求梳理
    需求梳理框架:用戶 – 場(chǎng)景 – 路徑
    1:
    用戶:用戶即為業(yè)務(wù)部門或前線業(yè)務(wù)人員的角色
    需要了解用戶的角色,通俗來說就是了解用戶崗位如何配置,每個(gè)崗位有何目的和作用。
    2:
    場(chǎng)景:在什么場(chǎng)景下,有什么需求,要完成什么目標(biāo)。
    我們可以結(jié)合每個(gè)不同的場(chǎng)景,生產(chǎn)出不同的需求和目標(biāo),從而重構(gòu)出相應(yīng)的功能。
    3:
    路徑:在完成功能的梳理,那便是利用流程圖將功能進(jìn)行串聯(lián)。
    利用泳道圖來畫出每個(gè)角色之間的任務(wù)流程和相互關(guān)系。
    確定系統(tǒng)信息流,相關(guān)主體
    1:
    系統(tǒng)信息流:面對(duì)很多不同的基礎(chǔ)服務(wù)和業(yè)務(wù)系統(tǒng)時(shí)(如OA辦公,人事,財(cái)務(wù),通訊等),需要及時(shí)的和開發(fā)交流一下各關(guān)聯(lián)系統(tǒng)的要求。
    2:
    相關(guān)主體:除了對(duì)接內(nèi)部需求,還有外部的系統(tǒng)需求,可以用UML用例圖。
    項(xiàng)目范圍
    三個(gè)邊界:需求邊界,行業(yè)邊界,系統(tǒng)邊界
    1:
    需求邊界:當(dāng)需求邊界沒有邊界時(shí),我們可以根據(jù)不同的需求規(guī)劃出優(yōu)先級(jí),從而制定版本規(guī)劃。
    2:
    行業(yè)邊界:在進(jìn)行產(chǎn)品設(shè)計(jì)時(shí),面對(duì)著很多不同行業(yè)的系統(tǒng),這時(shí)候我們不應(yīng)該天馬行空,應(yīng)該主動(dòng)的去了解各個(gè)行業(yè)的規(guī)則與需求。
    3:
    系統(tǒng)邊界:一個(gè)產(chǎn)品,應(yīng)該為解決問題而生。市場(chǎng)上有這種產(chǎn)品,產(chǎn)品的業(yè)務(wù)也有很多,這時(shí)候我們需要有系統(tǒng)的方法才能給有序的解決。
    一:用程序思維來思考問題:可以將業(yè)務(wù)按照事件拆分成獨(dú)立的小產(chǎn)品。
    二:拒絕不護(hù)理需求:面對(duì)業(yè)務(wù)部門提出的需求,用戶往往按照自己的需求來提出自己的方案,往往有些方案顯
    得不合理,我們作為產(chǎn)品設(shè)計(jì)者,需要從全局出發(fā),來找出更好的解決方案。
    三:產(chǎn)品為解決問題而生:將某些功能放置在一些地方時(shí),需要考慮這些地方是否合適,以及對(duì)未來是否有隱患。

    來自江蘇 回復(fù)
    1. 課代表

      來自廣東 回復(fù)
  3. 同行你的文章很有道理,可以加個(gè)微信相互學(xué)習(xí)下不

    回復(fù)
  4. 苦苦掙扎在B端產(chǎn)品的路上

    來自上海 回復(fù)
  5. 好棒的文章,在做b端產(chǎn)品運(yùn)營,慢慢懂得并理解了b端產(chǎn)品的美,也理解了這個(gè)文章

    回復(fù)
  6. 理論為主,實(shí)際也許場(chǎng)景復(fù)雜程度往往非系統(tǒng)本身

    回復(fù)
  7. 想問問作者,場(chǎng)景列舉有什么方法嗎?你提到用思維導(dǎo)圖便于發(fā)散思路,是否有劃分維度或者分類方法的?
    就像文中提到的“400來電錄音檢核”這個(gè)是場(chǎng)景還是什么?下面擴(kuò)散的數(shù)據(jù)來源和邊界情況又是什么?都需要在思維導(dǎo)圖中體現(xiàn)嗎?

    來自廣東 回復(fù)
    1. 思維導(dǎo)圖的作用是幫助我們窮舉可能發(fā)生的情況,避免需求盲點(diǎn)的產(chǎn)生。通常來說,在工作一段時(shí)間后,可以形成自己的一個(gè)cheaklist,以后新項(xiàng)目時(shí)候就可以套上模塊自查。就好比C端產(chǎn)品的交互刷新樣式、控件狀態(tài)、無數(shù)據(jù)或斷網(wǎng)提示等這些無論在哪個(gè)頁面都要自查一次的,B端只是多了與不同系統(tǒng)之間數(shù)據(jù)的對(duì)接、可能發(fā)生的極限情況考慮,具體要結(jié)合公司業(yè)務(wù)和內(nèi)部系統(tǒng)考慮

      來自廣東 回復(fù)
  8. 很不錯(cuò),贊一個(gè)

    來自北京 回復(fù)
  9. 正需要,非常棒

    回復(fù)
  10. 干貨 非常感謝!

    回復(fù)
  11. 產(chǎn)品方法論——B端產(chǎn)品需求梳理分析模型總結(jié)
    1、需求梳理
    1.1.用戶
    了解用戶現(xiàn)有的業(yè)務(wù)流程,哪些人參與到流程中
    1.2.場(chǎng)景
    窮盡所有可能的使用場(chǎng)景。每個(gè)角色的場(chǎng)景、需求、目標(biāo)都一一列出來。
    具體方法是把問題拆解為一個(gè)個(gè)小問題,對(duì)每個(gè)小問題追問下去,直至無解、清楚為止。
    1.3.路徑
    任務(wù)->流程->功能——用流程把功能串聯(lián)起來,用流程把功能串聯(lián)起來
    2、確定系統(tǒng)信息流、相關(guān)主體
    2.1.系統(tǒng)信息流
    B端的業(yè)務(wù)系統(tǒng),往往需要與不同業(yè)務(wù)系統(tǒng)間的對(duì)接,在動(dòng)手寫需求文檔之前,不妨先與開發(fā)交流一下各關(guān)聯(lián)系統(tǒng)的對(duì)接要求。
    2.2.相關(guān)主體
    用UML用例圖表述完整的業(yè)務(wù)活動(dòng)(包括線下或?qū)ν獠肯到y(tǒng)的操作)。
    用例圖即可清晰表達(dá)劃分以上主體及其主要功能(任務(wù)),最大好處是以最簡潔、高度概括的外部視角與用戶(業(yè)務(wù)部門)溝通確認(rèn)需求,確保對(duì)復(fù)雜的業(yè)務(wù)過程理解一致。
    3.項(xiàng)目范圍
    3.1.需求邊界
    首先完整規(guī)劃,然后指定需求優(yōu)先級(jí)并根據(jù)需求優(yōu)先級(jí)和所耗資源決定項(xiàng)目范圍。
    3.2.行業(yè)邊界
    第一是要深入理解業(yè)務(wù);第二是作為行業(yè)外的設(shè)計(jì)者,要熟悉行業(yè)相關(guān)法律法規(guī)
    3.3.系統(tǒng)邊界
    規(guī)劃系統(tǒng)防止系統(tǒng)變得臃腫。
    ①運(yùn)用解耦思維,實(shí)現(xiàn)基礎(chǔ)業(yè)務(wù)模塊化
    ②從全局考慮,拒絕不合理需求,提出更好的解決方案。
    ③一個(gè)產(chǎn)品,只應(yīng)該為解決一個(gè)(類)問題而生。
    當(dāng)已有初步方案,一定要找所有與產(chǎn)品有干系的業(yè)務(wù)部門的主管落實(shí)方案,達(dá)成共識(shí),避免上線后才發(fā)現(xiàn)溝通存在問題。

    來自重慶 回復(fù)
    1. 謝謝總結(jié):)~

      來自廣東 回復(fù)
    2. 理論派

      來自四川 回復(fù)
    3. 理論派

      來自四川 回復(fù)
    4. 不是都用實(shí)際案例來分析了么,“理論派”未免過于極端 ??

      來自浙江 回復(fù)
    5. 確實(shí)是理論,但是這理論挺實(shí)用的,感謝總結(jié)!

      來自山東 回復(fù)