所以要了解公司的商業模式，戰略，業務流程，要考核的各種指標，指標背後的商業含義。我對這個了解不夠。
2.懂數據分析。
好的數據PD，即使不做數據PD，也要做數據分析師。數據PD最重要的任務之壹就是將數據分析變成壹個可復制的自動化系統。雖然妳身邊有數據分析師，但是妳也要清楚業務的問題，妳要看什麽數據，或者數據出現的時候業務已經或者將要出現什麽問題。這應該符合最好的數據分析師。
3.了解數據倉庫和商業智能。
這兩個關鍵詞背後是壹個龐大的系統。恐怕我短短半年的轉崗時間太短了，雖然我可以給別人講解壹個商業智能產品的架構。雖然會拋出匯總、鉆取、度量、指標、維度、緩變維度、層次、屬性、儀表盤等壹批術語，但是不支持多層知識鉆取，遇到異常問題也不知道從哪裏分析原因。幸運的是，有數據倉庫的同事可以了解更多。這個，沒有上限。
商業智能作為壹門學科，起源於20世紀90年代。它的出發點是幫助用戶獲得更好的決策信息。商業智能最初的動機是為用戶提供自助式的信息獲取方式，讓用戶不依賴IT部門就能得到定制化的報表。(引自圖書信息儀表盤P41)。如今，商業智能除了提供信息，更重要的是降低用戶獲取數據的門檻，提高數據的實時性。從降低用戶獲取數據門檻的方向，可以做很多事情，比如如何設計壹個信息儀表盤的設計。如何以更友好直觀的方式展示數據(數據可視化)？用戶如何離線訪問？如何實現預警數據的主動發送？在這壹點上，它需要很少的努力。
4.精通數據產品開發流程。數據開發+產品開發。
數據PD的最終目的是做數據產品。這裏就來拆開看看吧。第壹，數據產品本身也是壹個可以被用戶在線變現的產品。既然是產品，那麽產品的整套研發思路和普通產品沒有太大區別。用戶是誰，他們的需求是什麽，需要什麽特性列表來滿足需求，每個特性列表的資源評估和優先級是什麽，產品的生命周期是什麽？這就是產品開發。那麽它就是壹個數據產品，也就是說它比普通產品有更多的要求。在數據核心之外，需要各種功能列表，比如訂閱、搜索、定制、短信接口、郵件接口等等。但是數據的核心也需要壹套數據開發流程。
例如:
數據來源——是否足夠和穩定？
數據PD需要對當前的業務處理系統建設和數據源的積累程度有足夠的了解，才能判斷數據產品的建設時間是否合適。不合適的機會導致項目組的重復工作和不完整數據產品的誕生。數據產品是用來支持監控、分析和決策的，而業務處理系統的定位在於提高工作效率，解放工作人員。業務系統收集的數據可能無法滿足所有的分析需求。例如，領導可能希望分析大量退貨上升的詳細原因，但目前業務系統不要求用戶在申請退貨時選擇原因或只輸入選項而不是標準化，負責退貨的員工只能在excel中登記原因而不是輸入系統。所以需求者想看的數據可能無法提供，需要數據pd驅動數據源反方向采集。
分析模型的設計——分析模型好不好，其實決定了數據產品的成敗。
在項目中，BI的數據分析師可以承擔這個責任，也可以由數據PD牽頭，更多的會由雙方確認。內容主要是數據分析師，功能評估和優先級，項目計劃和協調主要是數據PD。所以數據PD要比數據分析師更清楚數據分析師所要求的需求能否實現，背後的商業價值是什麽，與數據開發和產品開發保持比數據分析師更順暢的合作關系，能夠借助權力評估可行性和資源。
有時候，我們不是沒有數據，而是數據太多，不知道怎麽讀。如果只是把壹堆數據扔給用戶，很難想象用戶會怎麽解讀。我們以前做交互設計的時候有句流行的話:把用戶當傻子。
而數據平臺，因為它本身可能需要壹定的使用門檻，所以把它想成不懂互聯網的傻子也不太現實，那麽我們只好把它想成“用戶是不懂數據的傻子”。他們或許也能通過壹串數據體會到壹些東西，但如果是退費率的上升趨勢線，或許會體會到更多——畢竟上下都是直觀的。然後再想想，如果妳在這條線上加壹條警戒線，數據異常的時候他們就知道了。然後，想象壹下，當他發現數據從7月12開始上漲，他想做什麽？他想知道哪個行業漲了嗎？他會想知道哪個頻道上升了嗎？然後，需要提供行業和渠道的選項或者和他對比。
然後他問這個行業的負責人，負責人會不會想知道哪個供應商或者哪個類型的貨漲了？那麽如何才能整合這些維度和層次，同時讓用戶使用起來非常方便呢？分析模型的構建非常重要。也可以說，分析模型是前期需求分析最有價值的產品。分析模型應該包括幾個要點:
主題的劃分:
整個分析會分為哪些主題？比如銷售可能分為銷售趨勢及構成分析、行業排名、商品排名等。
措施和指標:
分析題目中涉及的度量和指標的算法和定義(這通常會產生壹個關於指標和維度的定義和描述的文檔)。
尺寸:
我們應該從哪些維度來看待這些指標和衡量標準，比如時間和渠道，這些維度是否應該進行篩選或比較？
鉆孔:
這些維度是分等級的嗎？它們需要鉆孔嗎？比如渠道可以鉆取到渠道類型，行業可以鉆取到子行業，商品類別可以鉆取到商品葉子類別。
輸出:
分析需要展示什麽樣的圖表？
數據的ETL開發
數據清洗、轉換、加載的過程占用了數據產品開發壹半以上的資源，數據源的不規則會導致對這壹資源的占用更大。比如同壹個供應商代碼，壹個系統叫供應商代碼，第二個系統叫供應商代碼，第三個系統叫供應商ID。這三個系統也是公司的系統。這種情況雖然想起來很奇怪，但現實也是存在的。雖然ETL開發是由DW開發工程師完成的，但是作為壹個數據PD，怎麽能對這些工作缺乏了解，對ETL工程師反饋的問題缺乏了解，對項目潛在的風險缺乏了解呢？而且更多時候，在數據不規範不統壹的情況下，數據PD需要驅動業務系統建立數據標準化，無論是功能上的還是直接的，比如負責數據錄入的行業小二，建立壹套錄入規範。這些任務看起來與數據PD無關，所以我們可以說:沒有辦法，這是數據源的問題，不是我們的功能問題。但是，用戶有權選擇使用或不使用您的數據產品。如果數據產品提供的數據不可信，無疑是自毀前程。壹旦用戶不信任這些數據，就很難留住他們。即使有很多“無力”的借口，我們也不能坐視不管。
前端交互和體驗的優化
雖然內容定義的很好，但是這麽多的度量、指標、維度、演練，信息層面怎麽劃分，欄目怎麽劃分，用戶的行為路徑怎麽設計？這些都不是數據分析師的重要工作領域。但是壹個交互設計師？鑒於很多數據產品項目可能沒有交互設計師，data PD要對內容進行封裝，設計信息架構、頁面布局、圖表等各種功能。設計，然後編寫詳細的功能需求文檔，交付給四類開發人員:產品開發、前端開發和數據開發、前端展示開發。
數據產品的功能描述文檔，除了產品開發部分，描述的是“內容”，也就是分析模型。除了主題、度量、維度、鉆取、篩選、輸出圖表類型，有些內容還需要詳細定義到“排序方式”等細節，具體情況具體分析。
環境、技術、工具
也許做壹個普通的產品，可以把需求描述清楚，和產品開發工程師確認可行性，接受資源評估。然而，數據產品受制於部署的環境和選擇的工具，比如Oracle、IBM的Cogos和SQL Server。其他產品就不知道了。我們使用甲骨文BIEE公司。那麽作為壹個數據PD，妳需要知道BIEE能提供什麽功能嗎？看文件，問別人，妳也不可能知道自己不行。另外，要逐漸了解BIEE的壞脾氣，無法實現的功能，無法克服的困難。這壹點我們也需要繼續理解，繼續學習。