一 前言&序
用戶需求、業務需求、系統需求...... 但是今天我要給大家介紹一種我自認為一種別出心裁的需求！【指標類需求】
在龐大的需求體系里，一個完整的系統設計流程是非常必要的，好則效率百倍，壞則加班熬夜。
本文嘗試以另一種需求管理方式來處理一種特殊的需求【指標類的需求】，希望大家能所有收穫一起成長。當然不積跬步無以至千里，不斷的進階才是王道！歡迎大家一起交流！
二 指標類需求1 什麼是指標類需求？指標類需求，顧名思義也叫分析性需求，是需求的一種變種，本人在商品開發中負責品規的階段，如果把整個供給側劃分成一個戰場那麼品規側承載着製造五花八門彈藥的使命，在製造彈藥的過程中，我們要做到以下幾點！
3.最近哪些彈藥賣的好還便宜，日均銷量不錯的，gmv不錯的！（找到）
2 forexample
給我計算各種維度=月日均+爆品數+訂單分層+類目分層+質量分層+排行榜+品控+gmv+人標籤+店鋪+使用率+滲透率xxxxx等等等等......
在當前的階段品規側，計算了大量的指標。據不完全統計，我已經計算了大概不亞於幾千個指標，本人對於這種需求也是一臉懵！月日均，爆品數，訂單分層，類目分層，質量分層，排行榜，品控，gmv,人群，應季，趨勢，增長率，曲線，複合曲線...... 哪一個拿出來都夠喝倆壺了。
3 指標類需求難點？在海量的指標需求下，總結來說有以下幾個問題？（在當PM熬過無數個日夜決定痛定思痛）
5.如何保證開發時間不被數據check打擾？（正在開發功能說數據不對，check數據導致功能延遲加班熬夜！）
以下是我在進行了一定的指標需求後得到的一點點經驗，希望和大家一起分享下！
三 如何解決
對於這種需求不破不立我們可能要打破原有的需求設計的規則單獨定製一種規則，下面這個圖是我通過不斷地踩坑總結出來的一種方式。
1 需求階段(開發側)
指標開發幾個階段：1）指標初步確認階段
2）指標計算階段在指標計算確認階段我們要做的需要幾步：
3）指標最終確認階段
1.開發測試PD統一根據prd統一確定指標與指標口徑2.開發先去計算指標計算完成----->測試和PD驗證
測試與PD在指標計算時，提前介入，開發提前計算，提前測試，在正常功能前保證數據指標完整
2 需求階段(PD側)三個要點（個人的三個建議）
1）指標要具有確定性爆品定義是什麼？分層的定義是什麼？口徑要先定義清楚，方便後面開發！
2）指標要具備可開發性3）指標與功能匹配性需要所有的需要的指標要全覆蓋避免漏指標，指標再次計算往往耗費人力更為可怕！
3 需求階段(測試側)參與開發指標的全流程的對焦，開發側在產出數據後進行數據驗證sql產出。
四 經驗思考1 數據前置指標數據分析型需求我們需要拆解，把數據開發測試校驗前置，可以有效避免在開發功能時，數據check影響整體進度，往往找一個指標的錯誤，會比功能錯誤難上幾倍！在大數據的情況下尤為如此！所有前置條件做好可以有效避免項目的判斷失誤，可以讓項目有效的進行！
2 數據分析在測試與PD要介入確定問題時，可參考以往數據！避免重複對焦不準確。
如何與測試建立指標的測試規範下一篇文章我可能會繼續迭代出來！讓指標的驗證不僅僅有跡可循，也讓錯誤無處遁形！
3 如何減少指標計算既然指標計算無可避免那麼我們應該如何去減少指標計算，節省人效，之後我會去分享下商品開發&運營品規側在計算了無數指標後，痛定思痛，如何嘗試與數據應用團隊結合來提高我們的指標計算效率！節省人效，非常nice！就不用大量的人工計算不同層級維度的指標，環比數據等等，這期間品規域我與同事進行了很多的嘗試 。
五 完結在做指標類需求過程中，從小白到一個數據開發值得信賴的數據開發者，是一個痛苦和漫長的過程！在這過程如何保證開發數據的周期，如何更快的承接需求，如何更高效的計算指標，減少人效是值得深思的地方，希望本文能夠幫助你！
阿里雲鏡像站體驗官招募中，Airpods耳機等你來領！
鏡像站體驗官第二期招募回歸, 在各大社區平台分享相關內容累計積分就可贏得Airpods耳機和移動硬盤等獎勵，銀牌體驗官的獎勵人數不設限，趕緊參與報名吧！
鑽石舞台 發表在 痞客邦 留言(0) 人氣()
留言列表