<em id="pn7p8"><acronym id="pn7p8"><u id="pn7p8"></u></acronym></em>

    <th id="pn7p8"></th>

    <button id="pn7p8"></button>

      <dd id="pn7p8"></dd>
      <progress id="pn7p8"><track id="pn7p8"></track></progress>

      Linux培訓
      達內IT學院

      400-111-8989

      需求分析之“試紙測試”是什么?

      • 發布:Linux培訓
      • 來源:Linux培訓常見問題匯總
      • 時間:2017-12-05 17:06

      今天和大家聊一聊一個需求驗證的小技巧:“試紙測試”。

      一、初衷

      眾所周知,產品上線以后,經過一段時間的運營,同時隨著戰略的調整和需求的逐步明朗,會有許多新的需求和方向產生,此時就不得不進行產品迭代,而任何的新功能和改變背后,都充滿了風險和未知,作為產品經理,該如何用最小的代價來驗證改變的價值?

      今日就和各位聊一聊一種需求驗證的小技巧:“試紙測試”

      二、定義:

      何為“試紙測試”?

      任何產品或功能的設計價值體現在設計動機,而設計動機的價值就是為了滿足需求!

      而需求之間是存在關聯性的,如果假設現有功能是滿足需求的,那其周圍一定存在著潛在的關聯需求等待滿足,同時會有很多偽需求伴生,此時就需要去做判斷,之所以觀主把這種方法稱為“試紙測試”,就是寓意“猶如化學實驗的試紙一樣,用一片小小的試紙附帶著現有產品去對未知做判斷”!

      說白了,“試紙測試”的核心理念就在于——

      依附現有產品,以最小代價,在盡可能少的改變現有產品的前提下,去對未知需求做判斷和預演!

      從而確保在新功能或改變正式上線前,掌握主動,做到進退自如!

      ps:任何新功能的上線,都是有代價的,比如開發成本、比如用戶接受度的不確定等,不管團隊大小、資源多寡,作為一名產品經理,需要學會盡可能的“一擊即中”,在低成本下試錯!

      三、舉例:

      (市面上每個產品的背后也有自己的故事,所以這里的例子都是經過一定轉化的,不具名了,請勿對號入座;另外很多現有的功能做的很好,但是并不代表其在當初上線前就已經能確定上線后的結果,在這里我用“試紙測試”的方法,架空這些功能,做出了一些假設,為大家提供另外一種更穩妥的思路,即“如果有了試紙測試,花很小的代價,可能可以預測結果”)

      1.電商平臺商品詳情頁增加“一鍵下單”功能

      (任何創新功能在設計時的預期,實際上線后可能根本無人問津,“試紙測試”可以把試錯的成本降低,無論是開發成本,還是用戶認知的成本)

      現狀:詳情頁有立即購買功能,點擊后進入訂單確認頁面,確認商品和配送、支付等相關信息后支付,支付成功后流程結束。

      需求:降低用戶操作難度,縮短、簡化用戶操作流程,使用戶從決策到完成支付的過程更緊湊。

      方案:分析下來,在訂單確認環節上,存在很多重復性的輸入和操作,而個人消費者的收獲、配送、支付等信息可選范圍極小,所以希望通過復制上一次(或預設)的訂單確認頁面輸入內容,來去掉這一環節,直接完成支付,所以需要增加“一鍵下單”功能。

      正常迭代:直接增加“一鍵下單”功能。

      試紙測試:在訂單確認頁面增加一個按鈕“與上次訂單相同”,通過對這個按鈕的監控來看增加“一鍵下單”功能的必要性。

      ps:很多人要問了:正常迭代和試紙測試感覺在功能上差別不大,為什么要多此一舉?原因如下——

      · 首先在訂單頁面增加按鈕和在商品詳情頁加按鈕相比,前者僅僅是對上一次的信息做緩存和讀取(自動填充),后者需要開發一套全新的自動化邏輯,明顯“試紙測試”的試錯成本更小;

      · 其次在頁面的邏輯上,直接增加“一鍵下單”面臨著從商品詳情頁就把流程做分支,改變了現有的產品和頁面邏輯,而“試紙測試”采用的方法,則是不對頁面和流程做調整,依然是通過“立即購買”進入訂單確認頁面,這樣的更改對用戶來說基本無變化,也不存在認知上的難度。

      2.B2B平臺是否增加采供交流頻道?

      (“試紙測試”除了可以幫助產品經理降低試錯成本,也同樣可以為產品經理砍去偽需求提供事實依據)

      現狀:某化工平臺提供的交易模式為詢盤交易(撮合交易)和現貨交易(類庫存交易),采購商只能向某一家或多家同時進行采購意向的提交,而現貨交易由于品類的限制,可能存在現貨與采購需求有細微出入的問題。

      需求:公司高層以及業務線認為,需要通過類似交流社區或頻道的功能,幫助采購商把需求給擴散,在提升采購效率和反饋率的情況下,又能吸引有潛在供貨能力的供應商參與到平臺交易中。

      方案:在原有的主線交易流程外,增加一個單獨的二級子頻道“采供交流區”,功能類似于簡化的“58同城”這類的。

      正常迭代:直接增加二級子頻道,需要做很多開發,包括一整套新的邏輯:從瀏覽到發布到接觸到初步達成意向后的關閉。

      試紙測試:直接在現有的商品,無論詢盤或者現貨的“詢盤/購買”按鈕邊上增加兩個按鈕“我也能供貨”和“這不是我要的,讓平臺幫我找更多供應商”,統一跳轉一個簡單的采供信息提交表單(包含聯系方式),而在用戶端后臺中只增加一個記錄該次提交的跟蹤模塊,通過運營人員的介入來幫采供雙方完成:其原本通過采供頻道可能達到的預期效果,即如果是采購商發布采購信息無非是要供應商應答,這個找供應商的過程前期就用人工來完成。

      ps:如此做的原因如下:

      · 通過“試紙測試”降低了開發成本是其一,同時避免了在需求未驗證前,盲目進新版塊上線所帶來的流量切分和意外跳出;

      · 這里的核心思路是“先證明對錯,再完善功能”,原有的需求需要進行一定的轉化,表面是要做一個新頻道,實際需求不是非要這個頻道不可,而是需要一條幫助采供雙方在原有交易線外,把潛在需求給釋放的路徑,所以“試紙測試”通過簡化和運營人工介入,就是為了證明這個點。

      · 產品經理要學會砍需求,這是老生常談,觀主平均要砍掉全公司(包含老板)的80%需求,這個“砍”不僅僅是不做,有時候是雙方互相讓步后簡化著做,而“試紙測試”很大的一個作用就是為你提供“砍需求”的理由。

      3.電商平臺增加新的品類前的試紙測試

      (“試紙測試”不僅適用于產品設計和開發,還能用于運營場景)

      現狀:某珠寶B2B平臺,80%的商品為黃金類珠寶首飾,而在品類上也是以這個為基礎,但是珠寶首飾的品類其實極其豐富,同時延伸的周邊產品,如加工用具、包裝盒等也極多,但是客觀的說該行業為非標定制行業,又是柔性手工生產業,所以在信息化的難度上不小,很難做到全品類的普適(意味著每增加一個品類,起碼商品管理和展示、下訂上要多一套新模板)。

      需求:業務團隊需要在現有品類上增加很多其它品類,逐步轉化成全品類平臺。

      方案:原平臺從展示、搜索到下訂,以及后臺的結構都需要從適用于黃金品類轉化為全品類,如黃金是沒顏色的,而新增的K金有雙色和三色,同時顏色不同工費等都不同,原模板需要更改。

      正常迭代:直接分析每個品類后設計開發,從上傳到展示,從搜索到下訂,幾乎全流程需要翻一遍。

      試紙測試:不做任何更改,將一些已經談好的供應商的非黃金(即新品類)類商品,通過現有的商品體系上傳,很多關鍵信息無法很好展示,但是起碼采購商可以看到圖片、名稱和備注,這些粗淺的顯示無法幫助采購商做購買決策,通過人工介入來完成這一步需求的驗證。

      ps:原理如下:

      · 當時我評估的開發量很大,而且不確定性太多,于是就試圖用冗長的開發周期嚇退業務團隊;

      · 原先的產品結構,僅僅是不適合全品類,但是不代表完全無法進行初步信息的展示和溝通,人工的介入很好的彌補了這一缺陷,所以何不先不做改變,通過運營來做些嘗試呢?如果用戶真的對這些品類存在需求,再開發新模板也不遲。

      · 我的經驗就是:很多時候你沒推出某個功能或商品前,用戶滿口說好,但是實際上線后,會不會買或者用,還是兩說,做產品的童鞋們嚴謹些。

      4.常旅客積分管理app,增加優惠券功能后的反思

      (“試紙測試”的有趣之處在于替代,把從開始到結果的每個步驟,盡可能的用比較小代價的行為去做替代,從而做到“不大動干戈”而完成嘗試)

      現狀:一款常旅客(整天上天入地飛飛飛,各種酒店嗯嗯嗯的物種)專用app,包含社區、信息交流和各大航空酒店集團的會員積分管理功能,同時附帶著教你如何“薅(HAO)羊毛”以及推送精準的優惠信息。

      需求:業務團隊(又是萬惡的業務團隊)需要增加一個優惠券的功能,無非是與現有可綁定會員卡的集團進行談判后,拿一些甜頭給用戶,三方互利互惠,優惠券用于夠用戶在預定酒店或者飛機時使用。

      方案:根據需求,當時需要做的最低要求也不簡單,起碼包含三塊:優惠券前臺入口(查看和領取),個人中心中的優惠券查看功能(包含優惠券的使用狀態同步等),以及app運營后臺的優惠券錄入和管理模塊。

      正常迭代:把app折騰翻一遍,再把后臺翻一遍,同時還可能需要和不同酒店航空集團做后臺技術對接(取決于給券的合作方),整個開發周期各位童鞋應該也初步有概念了,我們當時的開發配置(2ios,2安卓,2java,1測試)需要折騰半個月。

      試紙測試:(首先要說,這是個曾經失敗的功能,做好后沒人用,原因多樣,包括比較二的是合作方不提供優惠券,今天拿出來說也是一些反思后的結果)現在想想完全可以簡化,app是以手機號注冊的,每個用戶的手機號都有,app優惠券前臺也不需要做那么復雜,直接給個點擊領取的功能,點擊后新頁面也不跳,直接提示成功與否,成功就下發短信把優惠券推到手機,然后,個人中心也不做優惠券的查看和管理,前期反正券少,先借用用戶手機的短信功能對優惠券做管理和狀態查看,app端可以少改動就少改動,可以不動就不動。

      ps:來說說這個“試紙測試”的思路:

      · 分解需求后無非是幾點需要證明:用戶在看到優惠券后是否會點擊領取,領取后是否需要一個管理的功能,領取后實際是否會去用。

      · 根據分解的點用“試紙測試”的思路做替代:核心點在于把整個領取后的優惠券代碼查看和管理這塊,借用手機自帶的短信管理功能來做替代實現,省掉了app兩個界面“優惠券領取后詳情頁”和“已領取優惠券列表頁”。

      · 還是“試紙測試”的核心思路,盡量“不大動干戈”的去做些低成本試錯,先驗證這個優惠券的出發點和結果是用戶認可的再去完善功能。

      相關的例子數不勝數,觀主就不一一道來了,各位可以結合自己做過的產品,來看看從“試紙測試”的思路上,是否有新的破局方法。

      四、總結

      “試紙測試”是一種新的解題思路,是我根據自己的產品經歷總結提煉的方法論,可能各位都有用過類似方法,但是希望通過這次提煉可以幫大家更體系化的去思考和應對產品需求,在實際場景中使用“試紙測試”時需要注意以下幾個要點:

      · “試紙測試”的核心是以小博大,用小代價去預測大方向。

      · 有時候別人說的需求是需要經過轉化的,“試紙測試”就是教你如何用小而美的方案去做替代法,然后把別人的實際需求給低成本的進行試錯。

      · 如果一項新功能或者改動對原來的產品影響不大,那其實可以不用“試紙測試”,切勿陷入非用不可的泥潭,這是笨辦法和無奈之舉。

      · “試紙測試”的大前提是保護現有產品,但是也切勿忘記要試錯的目的,有時候過于簡化,可能達不到試錯的目的。

      · “試紙測試”是一個平衡的技巧,是一種雙方理解下的妥協,需求方如果很堅定的認為要做,產品經理非不做時,你得明確告訴需求方,我們需要通過“試紙測試”,更有目的、更低成本的做著看看。

      · 最后再重復一下,“試紙測試”的代價如果很大,需要謹慎是否有必要了!

      以上只是我對過去的思考和沉淀,希望對諸位有所幫助,換一種思路,一起在產品的道路上走的更遠,謝謝觀賞!

      預約申請免費試聽課

      填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

      上一篇:如何在Linux下安裝安卓文件傳輸助手?
      下一篇:如何在Linux系統中通過用戶組來管理用戶?

      Linux培訓機構學費多少錢?【越少越好嗎】

      Linux培訓機構哪個比較好?【親自測試】

      Linux如何系統的學習才能學的更好?

      linux培訓機構哪個比較好?

      • 掃碼領取資料

        回復關鍵字:視頻資料

        免費領取 達內課程視頻學習資料

      • 視頻學習QQ群

        添加QQ群:1143617948

        免費領取達內課程視頻學習資料

      Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

      選擇城市和中心
      黑龍江省

      吉林省

      河北省

      湖南省

      貴州省

      云南省

      廣西省

      海南省

      高清特黄a大片,日本真人真做爰,特级做人爱C级,免费a级毛片 百度 好搜 搜狗
      <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>