1.3　從數(shù)據(jù)技術轉型做數(shù)據(jù)產品經(jīng)理——從具體到抽象

1.3.1　從數(shù)據(jù)技術轉型的困惑

在寫作本節(jié)內容之前，我走訪了幾位符合這種情況的老朋友。

大家的轉型原因答案各異，大體集中在兩個方向：“寫代碼寫煩了”或者“因為之前遇到的產品經(jīng)理不靠譜”，并且說過之后都會哈哈大笑。

第一種回答換一個表述就是，“想向另一個方向擴展自己”；至于第二種回答，我會說：數(shù)據(jù)技術“吐槽”數(shù)據(jù)產品經(jīng)理不靠譜，決定自己來做，和算法工程師“吐槽”數(shù)據(jù)庫里的基礎數(shù)據(jù)不好，便決定自己做，有什么本質區(qū)別嗎？于是大家又是一陣哈哈大笑。產品經(jīng)理和數(shù)據(jù)技術之間的“相愛相殺”在數(shù)據(jù)團隊同樣存在，既相互“吐槽”又相互合作。幸運的是，在我的經(jīng)驗里，大家在磨合期過后總是能變成好朋友。

至于遇到的困難，答案依舊高度統(tǒng)一：之前沒想到數(shù)據(jù)產品經(jīng)理這么累心。至于什么叫“累心”，繼續(xù)聊下去就會發(fā)現(xiàn)，仍然是思維方式的轉換問題。

我有一位曾經(jīng)合作過的數(shù)據(jù)技術好友，具有3年ETL經(jīng)驗，現(xiàn)在轉型做了數(shù)據(jù)產品經(jīng)理。他講話非常實在：以前做技術時，覺得需求不明確或者實現(xiàn)太復雜，可以和產品經(jīng)理吵架（產品經(jīng)理就是我）。現(xiàn)在自己找業(yè)務人員聊需求，再自己定義需求，就發(fā)現(xiàn)一顆腦袋很難想完全，有時需求溝通過后以為自己聊明白了，定義過程又發(fā)現(xiàn)各種細節(jié)需要確認；需求提交之后很快就發(fā)現(xiàn)不夠用了，又要變更；自己覺得不合理的，或者數(shù)據(jù)現(xiàn)狀實現(xiàn)起來過于復雜的，直接告訴業(yè)務人員，居然還被投訴了。后來就只好一遍一遍地來回確認，確認過程中就開始自我懷疑了。

我和他有這么一段對話。

我：你描述的困擾，總結成一句話就是你不咋會聊天？

他：嗯。可是，你也不咋會啊，經(jīng)常一句話懟死我。有話直說效率高，不是你說的嗎？“吵架是最快的產出方式”也是你說的！

我：你聊方案時怎么不這么聽我話！那是跟你們磨合好了之后，（我）才會隨便挑戰(zhàn)。“吵架產出高”有前提條件，就是雙方?jīng)]有認知隔閡。要是你說前門樓子，他說胯骨軸子，吵架除了提升情緒值，沒有任何意義。

（友情提示：個人風格，請勿模仿。）

他：哦，那我記得你也會控制不合理需求吧。

我：當然會，但基礎是要為對方解決問題。有些問題也可以暫時不解決，但是要有明確的理由和共識。最起碼，需求的合理性和實現(xiàn)難度要分開判斷。

他：以前產品經(jīng)理判斷需求合理性，我判斷實現(xiàn)難度，是因為產品（經(jīng)理）沒有判斷實現(xiàn)難度的能力。（壞笑）

我：（白眼）兩個判斷的能力合并在你身上，不代表可以不區(qū)分判斷。需求本身的合理性判斷是基于對業(yè)務問題的解決，實現(xiàn)難度的判斷是基于現(xiàn)狀和技術難度。你不能說因為代碼不好寫所以需求不合理。

他：那肯定是。

1.3.2　從數(shù)據(jù)技術轉型的關鍵點

上面的聊天中我們聊到了兩個點，溝通技巧和需求判斷。

大家都知道，對技術的充分理解是數(shù)據(jù)技術出身的人的絕對優(yōu)勢，即在提產品需求之前就可以預先評估可行性和難度。這種判斷力對很多做產品的人來說是一個難題，但對這些從數(shù)據(jù)技術轉型做產品的人來說卻完全不是問題，甚至可以幫技術人員一起想技術方案。但是與此同時，他們會非常容易在設計還沒完成的階段，就一頭陷入實現(xiàn)過程的細節(jié)里：有時候需求還沒聊完，需求分析和產品設計都還沒做，滿腦子已經(jīng)是“這個SQL怎么寫”了；甚至會直接告訴對方：這個實現(xiàn)不了。這么做的缺點是：即使判斷本身是準確的，但這種反饋信息的方式也只會使對方收到“拒絕”這個信息，因為業(yè)務人員通常無法理解你用技術語言描述的原因，因為不理解，就接收不到“實現(xiàn)不了是有原因的”，只接收到“產品經(jīng)理說做不了”。

這里并不是說所有從數(shù)據(jù)技術轉型的數(shù)據(jù)產品經(jīng)理都有這個問題，而是說，技術和產品的團隊內溝通方式和與用戶之間的溝通方式有很大差異，需要有一個切換過程。這里的用戶指數(shù)據(jù)產品的用戶，包括公司高層、數(shù)據(jù)分析師、運營主管等角色。具體的溝通方式會在第3章詳細論述，大概的原則是“需求本身是否合理”和“現(xiàn)狀下是否能實現(xiàn)”分開判斷。需求不合理的就不實現(xiàn)，需求合理且現(xiàn)狀可實現(xiàn)的就是眼下要做的，需求合理的但是現(xiàn)狀不可實現(xiàn)的：明確問題是什么？是否解決？大概什么時候解決？圖1-3-1描述了大概的判斷過程。

與功能描述的具象化不同，業(yè)務人員對數(shù)據(jù)的使用需求，在大多數(shù)情況下都很難具象（這和不同的公司、不同的部門處于的不同階段也有關，數(shù)據(jù)體系化程度越高，業(yè)務人員和數(shù)據(jù)產品經(jīng)理之間的需求溝通越順暢）。對需求的判斷基于對業(yè)務的充分理解。考慮大多數(shù)公司的現(xiàn)狀，我相信在數(shù)據(jù)需求的溝通中很難直接定位到“我要這些指標和這些維度，來解決這些問題”的程度。挖掘業(yè)務的真正需求就成了數(shù)據(jù)產品經(jīng)理最大的目標之一。

如果我們是數(shù)據(jù)技術人員，就可以要求：數(shù)據(jù)PRD（產品需求文檔）必須具體到“可以拆解至可執(zhí)行任務并完全支撐測試用例定義”的程度。但是當我們成為數(shù)據(jù)產品經(jīng)理時，則只要求業(yè)務方“能講明白要使用數(shù)據(jù)解決什么樣的業(yè)務問題”即可。相關的指標定義和維度定義，均可以由數(shù)據(jù)產品經(jīng)理定義并和業(yè)務人員達成共識。如果組織里有數(shù)據(jù)運營的角色，那么指標定義和維度定義的過程可以由運營角色承擔，但是共識問題的過程不可缺失。

除了實現(xiàn)需求，數(shù)據(jù)產品經(jīng)理還有相當一部分工作獨立于需求存在——這部分工作的目標是“客觀描述”，而不只是“滿足需求”，這一過程需要通過自己對業(yè)務的充分了解來抽象出可用性高的數(shù)據(jù)模型或數(shù)據(jù)產品。這種工作模式就和一些技術角色的工作方式產生了本質不同。例如，“指標體系搭建”和“數(shù)據(jù)質量監(jiān)控”，就是可以獨立于“需求”存在的。以指標體系為例，指標體系對“業(yè)務”和“業(yè)務之間的關系”的描述基于一定的目標和方法論，覆蓋但不僅限于滿足業(yè)務需求（具體過程見第4章）。這種對業(yè)務的整體認知不同于任何單獨的業(yè)務視角，有些人喜歡管這個叫“上帝視角”或者“頂層視角”，而我更喜歡叫“畫家視角”。在這樣的視角里，既不能受限于需求，也不能陷入具體細節(jié)，而是需要“完整且客觀”。這就像是一個畫家在面對一個客觀事物時，目標是盡可能地描繪它，無論怎么畫，它都在那兒，不會改變。

圖1-3-2描述了指標體系和業(yè)務的關系。這一關系意味著只滿足需求是遠遠不夠的。

每個需求方都有自己的視角和意志，他們各自的視角意味著任何業(yè)務角色都無法對自己的業(yè)務做到真正的“客觀”，更不用說去關注自己的業(yè)務和其他業(yè)務之間的關系。所以作為數(shù)據(jù)產品經(jīng)理，需要在滿足業(yè)務需求的同時，保證數(shù)據(jù)對業(yè)務描述的“客觀”和“完整”。這不僅包含溝通技巧，還需要依靠自己的能力去頂住一些壓力，掌握二者之間的平衡。