起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識全面復盤——數據管理系統如何從0到1
數據運營和數據規范管理對一個公司來講是很重要的，而很多產品新人因為經驗較少，對這方面不是很清楚，來看本文作者全面復盤他建立從0建立數據管理系統的經驗。
一、前篇（辛路歷程）
本人13年畢業，在畢業前三年從事的是市場的工作，主要是針對現有產品的銷售，以及對銷售出去的產品提供配套服務的工作。像剛剛畢業的年輕人一樣，有很多想法，也有自己創業的想法。但是，太！年！輕！
慢慢在市場的工作中，覺得運營自己的客戶是一種提升渠道的方式，并且在產品層面也有一些自己的想法，也沒想到就這樣慢慢開始對運營產生了興趣，于是毅然決然的轉到了現在的行業和崗位—互聯網產品經理（其中的故事非常曲折，感興趣的可以加我微信一起交流）。
在我的定義中，互聯網產品經理是你所負責的互聯網產品的第一負責人，以滿足商業價值、開發邏輯，迎合用戶需求的產品為導向，不斷學習、實踐、創新的一類人。網上針對產品經理的描述優秀的表達有很多，我就不再做闡述了。
二、初識到收獲
剛剛從事產品經理的工作的時候，并沒有針對一款真正的產品作為第一負責人開展工作，而是從前端商務產品頁面的設計入手的。
當時的業務來源是業務部門，但是之前的學習告訴我：需求不是一兩單業務能夠帶來的，而是認真的調研分析之后確定的產品方向，從調研方式入門到用戶研究也是那個時候開始去學習的，但是并沒有得到很好的實踐（弱弱的做過每個業務人員的問卷調查），但是還是將學習的內容整理到了自己的知識框架中。這里要敲個黑板，知識學習整理的重要性！
從頁面產品功能設計中，其實是對之后的產品思維打下了基礎的一項工作。產品的定位在設計規劃的過程中也發生過調整，從服務內容上找到了適合企業資源應用和發展的路徑，驗證了大處著眼小處著手的思想。
頁面設計和產品設計是由我作為第一負責人，做過的工作包括：市場調研（市場、環境、用戶需求、競品、商業畫布）、產品設計規劃（頁面前臺、頁面后臺、數據管理）等，但是市場決定一切，公司戰略發生轉移，所以這個產品靜默了！（心里想還沒開始真正的迭代，還沒有進入和開發的撕*，怎么能結束?。?/p>
從上一個產品接觸到數據之后，公司也開始重視了數據的運營和數據規范管理的重要性，這和我之前想象的數據運營似乎有關聯。所以是興趣驅使我們繼續前行嗎？是對生活的無限熱愛嗎？是對工作內容的無比熱情嗎？是閉卷考試這道題你做過！開個小玩笑，產品經理時常也是要給自己打打雞血的。
三、上壘（主導一個產品）
從上個產品中，我已經反饋了公司內部數據管理薄弱的情況，加上公司本打算建立一套新的數據管理系統，所以這個任務被我們這個資源管理部門承接了。
產品立項之前的流程就不在做介紹了，因為之前的產品設計已經有過相應的流程介紹，而且大家在自己的知識框架中也有自己一套或者公司有一套標準的產品立項流程，接下來從實際的操作層面做個復盤的闡述。
之前做的時候也是摸著石頭過河，從產品生命周期出發復盤產品的建設過程：
1.初入期
1).產品設計
明確產品的定位：支撐業務；發現數據價值。
產品設計是貫穿整個產品周期的工作，你在初期設計的方案可能會在后期被推翻，所以不斷更新迭代自己的產品規劃設計是正常不過的事情，這邊說的是初期的產品設計規劃。
之前公司有一套老的ERP系統，所以需要設計一套新的ERP來代替它，在定位中有說到發現數據價值，那么就賦予了它的發展中又不僅僅是一個單方面的ERP，可能也承載著衍生出業務行為的功能。
在設計中就要考慮到產品整個生命周期中的總體規劃，而在初期除了總體規劃上需要去做思考，我整理了一下我遇到的幾個重點問題：
(1).技術架構
技術架構設計：就是在產品設計完成之后，需要找公司的技術部門溝通產品的架構設計和技術選型思路。
在成熟的產品開發流程中，這個部分是必不可少的，這影響到之后的產品成長性，就像我們搭積木，底層搭的好，上層的積木才能更穩、更豐富。
我們公司之前跳過了這個步驟，使用的是開源的框架，導致現在產品開發出來之后受底層半結構型數據庫的影響，整體響應較慢，而且從技術層面去改善響應問題，需要花費更長的時間，所以有條件的盡量自己開發。
(2).權限設置
權限設置：就是針對不同的用戶角色，設置的不同的使用權限。包括權限規則設計和權限內容設計。
權限規則設計思路是從組織架構-部門角色-角色職責-角色權限，而角色權限就是權限內容設計的范疇。
之前我們設置權限的步驟分布在四個頁面，現在改版之后在一個頁面就能完成權限的設置，只有運營人員才能設置權限。
而且針對不同部門的業務協作，權限設置要考慮到每個部門在業務流程中的角色，不能夠以偏概全，要有更好的延展性和全面性，就要求我們產品部門對業務的了解程度一定要高，要充分了解業務流程。按照一般的系統流程，權限設置的權限應該下放給對應的主管領導，這樣能減輕運營人員的壓力。
(3).內容設置
一般的中小企業針對數據的規范是沒有概念的，他們考慮的是生存。但是企業發展的一定階段，再也不通過野蠻生長來帶來利益的時候，就需要去規范數據管理的工作。需要針對不同的客戶主體設置相應的數據標準，并且做好全方位（其他產品也包括在內）自上而下的數據改版的思路規劃。
以上只是舉例我踩到的坑，產品設計中還包括文檔、原型、匯報、開發團隊選擇等很多內容，就不一一舉例了。
2).數據管理
數據管理在一個企業信息化產品的地位至關重要。這一切當然要從上面的內容設置入手，能使用國標的盡量使用國標數據，這樣方便之后與其他內外產品關聯；能開一個領導站臺的貫宣會的，就不要拖沓；能設計出一套數據管理流程的，就盡量用流程規范！
標準的事情就是從細節去摳的。
數據規范是難，但是對于歷史數據的處理，也是一項比較大的工程。新系統和舊系統的對應情況，同步的規則，之前沒有收集的數據規范工作也是需要我們去設置相應的規則，保證咱們數據的唯一性。要考慮的是基于數據分析相關的數據，如果收集的數據不能共支撐我們數據分析，那只會讓我們的系統更加冗余。
數據互通，作為平臺級的數據產品，在產品初期就要考慮到和各個產品之間的數據流轉和關聯，預留接口、信息同步、調用規則等。
敲黑板，數據的本質是什么？規律和思維方式。
3).開發測試
進入到了產品迭代的環節了，就需要我們將需求文檔盡可能的詳細描述，讓開發能夠按照我們的要求開發出完整的功能。
(1).盡可能的詳細文檔
針對我們需要開發的需求，要做詳盡的描述，但不能排除客觀存在的主管判斷帶來的偏差，開發只會按照你描述的內容去開發，并不會幫你想你存在的遺漏，所以需要你主動去和開發溝通，在開發過程中遇到的邏輯上和操作上不合理的地方及時改進，在這個過程中高頻的交流是至關重要的。
要非常感謝公司的開發的小姐姐，能夠及時幫我發現一些問題，并及時改正。
(2).開發出完整的功能
這就需要我們在做需求文檔的時候將流程主線描述的詳盡，并且在開發過程中進行高頻的溝通，保證信息互通（我們公司有早會，可以跟蹤產品開發情況），這樣才能保證功能能保證基本使用正常。借用我們公司CTO的話：完成比完美重要。
開發流程中可能還會牽扯到需求排期、開發延期等問題，可以從公司流程上去規范，并出臺相應的制度去規范。
4).交付環節
這個環節其實在之前我們公司的開發流程中是缺失的，自己默默找測試小姐姐商量，形成了這個機制。交付環節其實是很重要的一個驗收工作，針對開發完成的功能，能否達到部署的需求，以及上一期開發遇到不能解決需要下期解決問題的溝通。
其實每次迭代結束都有開發的總結會，但是我們公司的迭代總結會在執行層面的總結沒有提及，更多的是管理層面的總結，所以這些也是可以自己去推動的。
永遠忘不了，在交付時因為上面第三點沒做好，被啪啪打臉，并且項目延期帶來的痛楚，所以第三點請大家深刻體會。
5).部署
正式環境和測試環境，真！的！不一樣！部署會出現各種問題，之前也是因為部署的問題，處理用戶問題處理了一天，所以建議大家將部署的時間安排在風險較小的時間段。
可能也是和我們公司的開發部署方式有關，我們公司的開發部署方式是打包成一個文件一起部署的，這樣降低了部署的敏捷性。
2.成長期
1).運營反饋
因為公司比較小，所以產品和運營的工作沒有分割的特別細，在做產品的時候你就需要針對產品有一套初步的運營方案，現有的運營機制并沒有形成完整的文檔，所以還是口口相傳以最基本的記錄形式流轉。
基本的流程是用戶到運營到產品，受開發迭代的速度影響，很多在運營層面需要解決的，如：新系統使用率不高（雖然關閉了舊系統）、管理層使用率低、使用效果不佳、用戶體驗不佳（之前說過的底層數據庫的問題導致的響應速度問題）等。
TC的產品面向的是每一個自然人，而我們企業信息化產品面向的是企業內部的員工，雖然和TC相比我們不會接到過激的用戶反饋，但是我們也要給用戶一個自助的反饋渠道，所以整個運營機制的搭建十分重要。
當然除了基于產品的運營層面，我們也希望能夠通過數據反映問題?；诂F有數據的報告，如何提高使用效率等的分析報告也有在同步推進中，不能因為客觀因素影響我們的主觀能動性。
2).其他
現在產品的成長才剛剛進入成長期，想要達到成熟期的全面“爽”的體驗還有很長一段路要走?，F在作為一個小部門的負責人，需要從產品、數據、管理上，從更高的角度出發去思考部門和產品的發展，盡快進入成熟期。
三、許諾（看見看不見的）
其實剛剛開始做這個產品，能看見的可能是規范公司數據、統籌管理公司數據、支撐公司現有業務的發展，也有從季度報告、年度報告從數據結合業務的角度出發去給出分析結果，但這個都是非系統性的解決方案。
在產品和部門發展的角度上，按照我的想法可以從以下三步形成完整的解決方案：
1.數據驅動業務
現在有著手從現有數據統計和展示層面，結合系統內現有主體的業務流程，做出可視化方案，提供給管理層使用。
用數據代替人工統計和分析，給日常工作提供記錄，使業務結果和業務過程都能夠在系統上體現。并且在未來的時間內，能通過算法和匹配能達到業務推介功能。
2.數據驅動產品
做過企業信息化產品的產品經理應該都知道，企業內部使用的產品是很多的，我們公司現在在大力發展信息化管理，每個產品之間的關聯性既是數據的關聯性， 只有關聯起來才能將相關產品打通完成互相促進，共同發展的美好愿望。
同樣，也會加速數據產品市場化的進程。
3.數據驅動決策
關聯產品的數據分析，能夠提供給管理層針對公司業務范圍層內外的市場化機會分析，讓決策層能夠更快的看到市場化化方向，隨時調整公司戰略布局。
路漫漫其修遠兮，吾將上下而求索！汪汪汪！（來自產品汪的吶喊）
這也是本人第一次投稿人人，希望能得到大家的更多的指正和批評。
本文由 @Veyron 原創發布于人人都是產品經理。未經作者許可，禁止轉載。
題圖來自 pexels，基于CC0協議
新人做數據產品，首先要注意縷清，數據的來源，數據的級別，數據的使用目的。弄清楚這三個問題，才能在上手時不迷茫。至于說技術結構和實現方式，只要不是深度數據挖掘，通常會有一定的局限性。前期用到的地方有限。最重要的是，一定要跟開發事先溝通明確，并弄清楚哪些數據是已有的，哪些數據結合哪些數據才能有作用，舉個簡單的例子，注冊數據要結合留存數據和增長數據才有用，單獨一項數據作用不大。
恩，針對自己設計的這款產品在數據來源、類別都有梳理清楚，維度使用目的在初期的時候沒有做好規劃，而且現在有進行深度數據挖掘的需求，所以在深刻的補課中。謝謝指導，學習了！
技術架構？產品需要提供什么呢
這個其實是從技術構架出發的問題，需要考慮到產品的可靠性、安全性、使用范圍、可擴展性等等。都是可以從業務角度出發去設定的指標
小哥哥繼續加油↖(^ω^)↗
同是產品新人，共勉
小白求帶~
謝謝！ ?
厲害
厲害了，多多交流~