阿里巴巴數(shù)據(jù)產(chǎn)品經(jīng)理工作(總結(jié)篇) -0

[產(chǎn)品經(jīng)理]阿里巴巴數(shù)據(jù)產(chǎn)品經(jīng)理工作(總結(jié)篇)2015－3-17１7:07|發(fā)布者:貓兒來自:阿里巴巴PD|關(guān)鍵詞:PD（指產(chǎn)品經(jīng)理,下同)本身就是在做牛做馬,關(guān)系圈異常復(fù)雜。數(shù)據(jù)PD也不例外。而且打交道的人更多。以下是我用ＰPT繪制的數(shù)據(jù)產(chǎn)品經(jīng)理關(guān)系圈?？破眨篜D:對于ＷＥB產(chǎn)品設(shè)計人員而言,它的意思是“產(chǎn)品設(shè)計人員”，即proｄucedesｉgｎer。PＤ：在IT企業(yè)中，一般是ProductＤiｒeｃtｏr(產(chǎn)品主管）或PｒojecｔＤirｅcｔor(項目主管)的意思一.如何做一個好的數(shù)據(jù)產(chǎn)品經(jīng)理?PＤ(指產(chǎn)品經(jīng)理,下同)本身就是在做牛做馬,關(guān)系圈異常復(fù)雜。數(shù)據(jù)ＰD也不例外。而且打交道的人更多。以下是我用PPＴ繪制的數(shù)據(jù)產(chǎn)品經(jīng)理關(guān)系圈。如果你也做過數(shù)據(jù)產(chǎn)品的產(chǎn)品經(jīng)理(好拗口），相信也有同感。既然要和這么多人打交道,要推動數(shù)據(jù)產(chǎn)品的上線,數(shù)據(jù)產(chǎn)品經(jīng)理自然有著一定的要求。我的體會如下——也借此去鞭策自己在朝這個方向努力:１．要極其熟悉公司業(yè)務(wù)及動向。所以要了解公司的商業(yè)模式、戰(zhàn)略、以及業(yè)務(wù)流程、要考核的各種指標,以及指標背后的業(yè)務(wù)含義等。這一點，再了解都不夠。2.要了解數(shù)據(jù)分析。好的數(shù)據(jù)PＤ,即使不做數(shù)據(jù)PD,也應(yīng)該是個數(shù)據(jù)分析師。數(shù)據(jù)ＰD的一大要務(wù)就是將數(shù)據(jù)分析做成可復(fù)制，可自動運轉(zhuǎn)的系統(tǒng)。雖然有數(shù)據(jù)分析師們圍繞在自己周圍，但是自己也要清楚業(yè)務(wù)的問題，分別要看什么數(shù)據(jù),或者當(dāng)數(shù)據(jù)出現(xiàn)后,意味著業(yè)務(wù)出現(xiàn)了什么問題或者會出現(xiàn)什么問題。這一點,要向最好的數(shù)據(jù)分析師們看齊。3.要了解數(shù)據(jù)倉庫及商務(wù)智能。這兩個關(guān)鍵詞背后都是龐大的體系,恐怕我短短半年的轉(zhuǎn)崗時間太短，雖然能夠?qū)e人講解一通商務(wù)智能產(chǎn)品的架構(gòu)。嘴里雖然會拋出若干個類似于匯總，鉆取，度量,指標,維度,緩慢變化維,層次,屬性,儀表盤等等術(shù)語,但是也不支持多幾層的知識鉆取，遇到異常問題，也不知道該從什么地方分析原因。幸而身邊有數(shù)據(jù)倉庫的同事,可以多多學(xué)習(xí)。這一點,沒有天花板。而商務(wù)智能，做為一門學(xué)科，起源于20世紀9０年代,它的出發(fā)點是幫助用戶更好地獲取決策信息,最初商務(wù)智能的動機是為用戶提供自助式的信息獲取方式,這樣,用戶就可以不用依賴于IT部門去獲取定制的報表。（引自《信息儀表盤》一書P4１)。而如今，商務(wù)智能除了提供信息,更主要的是降低用戶獲取數(shù)據(jù)的門檻,提升數(shù)據(jù)的實時性等方面。從降低用戶獲取數(shù)據(jù)的門檻一個方向，我們就可以做很多事情，比如如何設(shè)計信息儀表盤（ｄesiｇninｇofinfoｒmatiｏndａshboard)？如何讓數(shù)據(jù)以更親和的更直觀的方式展示(數(shù)據(jù)可視化）？如何能夠讓用戶離線訪問？如何能夠?qū)崿F(xiàn)警戒數(shù)據(jù)的主動發(fā)送？這一點上，花多少功夫都不多。4.要精通數(shù)據(jù)產(chǎn)品開發(fā)流程。數(shù)據(jù)開發(fā)+產(chǎn)品開發(fā)。數(shù)據(jù)PD的最終目的是要做數(shù)據(jù)產(chǎn)品。這里要拆開看,其一,數(shù)據(jù)產(chǎn)品本身也是在線可供用戶實現(xiàn)的產(chǎn)品，既然是產(chǎn)品,產(chǎn)品的整套研發(fā)思路和普通的產(chǎn)品沒有太大區(qū)別，用戶是誰，他們需求是什么，滿足需求需要什么ｆｅａｔｕｒeliｓt，每個feａt(yī)urｅlist的資源評估以及優(yōu)先級如何，產(chǎn)品的生命周期如何?這是產(chǎn)品開發(fā)。然后他是個數(shù)據(jù)產(chǎn)品,意味著這比普通的產(chǎn)品，多了更多的要求。在數(shù)據(jù)這個內(nèi)核之外，它需要各種featurelist，如訂閱,搜索,自定義,短信接口,郵件接口等。但是數(shù)據(jù)這個內(nèi)核，也需要一套數(shù)據(jù)開發(fā)流程。比如：數(shù)據(jù)源——是否足夠，是否穩(wěn)定——數(shù)據(jù)PD需要足夠了解目前的業(yè)務(wù)處理系統(tǒng)建設(shè)情況，以及數(shù)據(jù)源的積累程度，用以判斷數(shù)據(jù)產(chǎn)品的建設(shè)時間是否合適。不合適的時機會導(dǎo)致項目組的重復(fù)勞動和殘缺的數(shù)據(jù)產(chǎn)品誕生。數(shù)據(jù)產(chǎn)品是用以支持監(jiān)控,分析,決策的，而業(yè)務(wù)處理系統(tǒng)的定位在于提升工作效率,解放工作人員手腳。業(yè)務(wù)系統(tǒng)采集的數(shù)據(jù)未必滿足所有分析需要。比如或許領(lǐng)導(dǎo)要分析大量攀升的退換貨的詳細原因,而業(yè)務(wù)系統(tǒng)目前并沒有要求用戶在申請退換貨的時候選擇原因或只有輸入而非標準化選項，負責(zé)退換貨出力的員工也只有在eｘｃel里登記原因,而不是錄入到系統(tǒng)里。所以可能會導(dǎo)致需求方要看的數(shù)據(jù)提供不出來,那么數(shù)據(jù)ｐd就有必要反向驅(qū)動數(shù)據(jù)源得以采集。分析模型的設(shè)計——分析模型的好與不好，其實決定了數(shù)據(jù)產(chǎn)品的成敗。在項目中,可以由BI的數(shù)據(jù)分析師們擔(dān)綱此職責(zé),也可以由數(shù)據(jù)PD擔(dān)綱,更多則由雙方一起確認,內(nèi)容以數(shù)據(jù)分析師們?yōu)橹?功能評估及優(yōu)先級、項目計劃和協(xié)調(diào)、統(tǒng)籌以數(shù)據(jù)PD為主。所以數(shù)據(jù)PD要更加清楚數(shù)據(jù)分析師們所需要的需求是否能夠?qū)崿F(xiàn)，背后的商業(yè)價值如何，并與數(shù)據(jù)開發(fā)、產(chǎn)品開發(fā)保持比數(shù)據(jù)分析師們更加通暢的合作關(guān)系,能夠借力進行可行性和資源的評估。有的時候，我們不是沒有數(shù)據(jù),而是有了太多的數(shù)據(jù),不知道怎么去看。如果只是拋給用戶一堆數(shù)據(jù)，很難想象用戶會如何去解讀它。以前做交互設(shè)計的時候，我們流行一句話：把用戶當(dāng)成傻瓜。而數(shù)據(jù)平臺,因為可能本身就要求有一定的使用門檻,所以想成不會互聯(lián)網(wǎng)的傻瓜不太現(xiàn)實，那么我們就要想成“用戶是不懂?dāng)?shù)據(jù)的傻瓜”。他們或許也能通過一串串?dāng)?shù)據(jù)體悟到什么，但是如果是一條上升的退款率趨勢線，或許他們會體悟到更多——畢竟，上和下本身就是直觀的。然后再想一下，如果將這條線上加上一條警戒點的線，他們會知道從什么時候開始數(shù)據(jù)是異常的。再然后,就要設(shè)想,當(dāng)他發(fā)現(xiàn)從７月1２日數(shù)據(jù)上升后,想干什么?他會不會想了解是哪個行業(yè)上升了？他會不會想了解是那個渠道上升了?那么,就要提供行業(yè)和渠道的選項或者對比給他。再然后,當(dāng)他過問了這個行業(yè)的負責(zé)人后，負責(zé)人想不想再了解是哪個供應(yīng)商或者哪類商品上升了？那么要如何將這些維度、層次都融合在一起,同時又能將用戶非常方便地去用呢?分析模型的建設(shè)至關(guān)重要，也可以說,分析模型是前期需求分析的最有價值的產(chǎn)物。分析模型應(yīng)該會包含幾點：主題的劃分:整塊分析會劃分成什么主題，比如銷售可能會分成銷售走勢及構(gòu)成分析，行業(yè)排名,商品排名等度量及指標:分析主題會涉及到的度量及指標的算法、定義等(這通常會產(chǎn)生一份指標以及維度的定義及描述文檔)維度：要分別從什么維度去看這些指標和度量,如時間,渠道,這些維度是要篩選還是要對比鉆取:這些維度本身有沒有層次，需要不需要進行鉆取,如渠道可鉆取到渠道類型，行業(yè)可鉆取到子行業(yè),商品類目可鉆取到商品葉子類目等輸出:分析需要用何種圖表進行展現(xiàn)數(shù)據(jù)的EＴL開發(fā)——數(shù)據(jù)的清洗，轉(zhuǎn)換，裝載流程占用了數(shù)據(jù)產(chǎn)品開發(fā)的大半資源,不規(guī)范的數(shù)據(jù)源會導(dǎo)致這一塊的資源更大程度的占用。比如同樣是供應(yīng)商編碼,系統(tǒng)之一稱為供應(yīng)商編碼,系統(tǒng)二命名為供貨商編碼,系統(tǒng)三命名為供應(yīng)商ID,這三個系統(tǒng)同時是公司的系統(tǒng)，這種情況雖然想起來匪夷所思,但是現(xiàn)實情況卻也存在。雖然ETL開發(fā)是DW開發(fā)工程師在做,但是作為數(shù)據(jù)PD,焉能對這些工作缺乏了解，對ＥTL工程師反饋的問題，缺乏認知，不理解對于項目的潛在風(fēng)險是什么？而且更多時侯,當(dāng)遇到數(shù)據(jù)不規(guī)范，不統(tǒng)一的問題,數(shù)據(jù)PD需要反向驅(qū)動業(yè)務(wù)系統(tǒng)進行數(shù)據(jù)規(guī)范性建設(shè)，無論是功能上，還是驅(qū)動直接的使用方——如負責(zé)錄入數(shù)據(jù)的行業(yè)小二，建立一套錄入規(guī)范。這些工作看似和數(shù)據(jù)PD無關(guān)，我們大可以推脫說:那沒辦法,這是數(shù)據(jù)源的問題,不是我們功能的問題。但是,用戶是有權(quán)利選擇使用不使用你的數(shù)據(jù)產(chǎn)品的,當(dāng)數(shù)據(jù)產(chǎn)品提供的數(shù)據(jù)不值得信賴的話,無疑是自取滅亡。一旦用戶對數(shù)據(jù)不信任,再想挽留他們，是很難的。即使有很多“無能為力”的借口，我們也不能坐觀其變。前端交互與體驗的優(yōu)化——雖然內(nèi)容定義好了，但是那么多度量、指標、維度、鉆取，如何劃分信息層級,如何劃分欄目,如何設(shè)計用戶的行為路徑？這些就不是數(shù)據(jù)分析師們的重要工作范疇。而是交互設(shè)計師？鑒于很多數(shù)據(jù)產(chǎn)品項目可能會沒有交互設(shè)計師,所以數(shù)據(jù)PＤ應(yīng)該對內(nèi)容進行封裝，進行信息架構(gòu)、頁面布局以及圖表各種功能設(shè)計。設(shè)計,然后撰寫詳細的功能需求文檔，交付給產(chǎn)品開發(fā)，前端開發(fā)以及數(shù)據(jù)開發(fā)，以及前端展現(xiàn)開發(fā)四種類型的開發(fā)人員。數(shù)據(jù)產(chǎn)品的功能描述文檔，除了產(chǎn)品開發(fā)部分,其他的就是在描述“內(nèi)容”,即分析模型，除了主題、度量、維度、鉆取、篩選、輸出圖表類型，有些內(nèi)容還需要詳細定義到“排序方式”等等細節(jié)，這就casｅbycaｓe來看了。環(huán)境,技術(shù)，工具——或許做一個普通的產(chǎn)品，你把需求描述清楚,與產(chǎn)品開發(fā)工程師確認好可行性，接受資源評估就OＫ了。但是數(shù)據(jù)產(chǎn)品,受制于所部署的環(huán)境，所選型的工具，如Oｒacｌe,IBM的Cogos,以及SQLＳeｒver。其他的產(chǎn)品我不知道怎么樣，我們用的是OracｌeBＩEE。那么作為數(shù)據(jù)PD,是否需要了解BIEＥ能夠提供的功能是哪些呢？看文檔,請教別人，不能知其不可而為之。另外,也需要逐漸摸透BIＥE的壞脾