01 困惑之前有講過數(shù)據(jù)產(chǎn)品經(jīng)理工作主要集中于平臺建設(shè)及用戶需求滿足，事實上以滿足用戶需求居多。很多時候，數(shù)據(jù)產(chǎn)品經(jīng)理會越來越?jīng)]有成就感，因為一直都在做需求，但是開發(fā)的產(chǎn)品沒有被用起來，周而復(fù)始的做著同樣的事情。 在開始一個產(chǎn)品研發(fā)前，數(shù)據(jù)產(chǎn)品通常要跟用戶博弈很多次，用戶在發(fā)起需求的同時，對開發(fā)出來的數(shù)據(jù)產(chǎn)品，其實是帶著很大的期待去幫助他解決問題的。但是，往往產(chǎn)品開發(fā)完畢后，又會因為這樣或那樣的問題而不被使用，最后不了了之，用戶花費(fèi)了精力，我們也付出了人力物力，卻付諸東流。 02 溯因產(chǎn)品沒有被用起來，原因有很多種，但我認(rèn)為很大一部分原因在需求管控環(huán)節(jié)沒有做好。 原因基本可以分為兩類：一類是數(shù)據(jù)產(chǎn)品經(jīng)理還沒有形成需求管控意識，特別是對于一到兩年的數(shù)據(jù)產(chǎn)品，容易形成一切以用戶為主被動接需求的狀態(tài)；第二種可能因為客觀因素影響，譬如承接項目需求承接，數(shù)據(jù)產(chǎn)品難以介入內(nèi)容設(shè)計環(huán)節(jié)。 數(shù)據(jù)產(chǎn)品經(jīng)理的需求管控意識不是一蹴而就能很快形成的，畢竟我們也需要不斷的成長才能少踩一些坑。對于我自己而言，同樣經(jīng)歷了很多個項目的洗禮，我才意識到需要做一定的規(guī)則去約束需求的提報，或者在平臺上去做一些通用性的開發(fā)減少用戶需求的提報。 03 體系化需求管控是基礎(chǔ)需求管控類似于打柜子的過程。 簡單的理解，可以將整個集團(tuán)的大數(shù)據(jù)平臺理解為一個大衣柜，衣柜里面應(yīng)該有多少個格子，每個格子該放什么衣物，已經(jīng)放了多少衣物，還能放多少，滿足了多少人的日常穿搭等，要有相對清晰的認(rèn)知。 對應(yīng)到數(shù)據(jù)應(yīng)用管理體系，數(shù)據(jù)產(chǎn)品經(jīng)理可以建立一個簡單的集團(tuán)層面數(shù)據(jù)應(yīng)用體系，平臺上有多個報表、多個看板、多個切片等，已經(jīng)支撐到哪幾塊的業(yè)務(wù)數(shù)據(jù)需求，滿足了多少用戶的數(shù)據(jù)需求，還有哪一塊的業(yè)務(wù)數(shù)據(jù)還沒有涉及到等。 這個數(shù)據(jù)應(yīng)用管理體系可以按業(yè)務(wù)組織來劃分，也可以按業(yè)務(wù)分析主題來劃分。一般數(shù)據(jù)平臺剛建立時，采取前者是最方便的，譬如：對于零售行業(yè)，可以按組織將大數(shù)據(jù)平臺分為線下渠道、線上渠道、商品供應(yīng)鏈、財務(wù)、人資等，每一塊大組織下面有不同的部門，每個部門提報的應(yīng)用需求安置在對應(yīng)的組織下面即可。 但是，隨著時間的推移，業(yè)務(wù)部門之間的數(shù)據(jù)交叉應(yīng)用會比較多，按組織架構(gòu)劃分已經(jīng)不太適用，這個時候可以考慮建立一個比較完整的集團(tuán)層面數(shù)據(jù)分析體系，將相應(yīng)的數(shù)據(jù)應(yīng)用放在不同的分析主題或場景之中。 如下圖所示： 有了這個數(shù)據(jù)應(yīng)用管理體系，數(shù)據(jù)產(chǎn)品經(jīng)理針對用戶的需求就能分門別類的進(jìn)行管理及管控，做到有跡可循。現(xiàn)在，我所在部門就在開展全集團(tuán)業(yè)務(wù)分析藍(lán)圖梳理工作，并著手于建立配套管控機(jī)制，未來用戶需求必須基于業(yè)務(wù)藍(lán)圖進(jìn)行來決定是否進(jìn)行研發(fā)。 04 需求可行性評估是保障很多情況下，數(shù)據(jù)產(chǎn)品可行性評估在數(shù)據(jù)產(chǎn)品考慮范圍之內(nèi)，但是技術(shù)性評估是首要考慮因素。然而，往往朝著如何實現(xiàn)的方向去評估，產(chǎn)品不僅會大打折扣，時間上也會出現(xiàn)延期情況。因此，可行性評估上，建議在需求層面做的更加多元一些。 建議從以下幾個方面考慮： 1. 技術(shù)層面研發(fā)人員說的比較多的一句話就是：只要你給時間，沒有開發(fā)不出來的需求。但是在實際項目過程中，時間是有限的，實際交付出來的產(chǎn)品功能上或者頁面呈現(xiàn)效果，會與用戶預(yù)期存在較大的差異。 因此，產(chǎn)品經(jīng)理提前需要與技術(shù)研發(fā)人員進(jìn)行可行性評估，確定可以完成的功能及效果展現(xiàn)，并與用戶確認(rèn)是否能影響到他們的使用熱情。 2. 數(shù)據(jù)質(zhì)量層面數(shù)據(jù)質(zhì)量重要性無需多說，產(chǎn)品研發(fā)前，對數(shù)據(jù)質(zhì)量問題進(jìn)行評估，并給出解決方案是確定產(chǎn)品能否用起來的關(guān)鍵。但是，數(shù)據(jù)質(zhì)量治理問題是個老大難，數(shù)據(jù)治理是個 繁瑣且需要多方配合的過程，甚至?xí)苯佑绊懙接脩舻臉I(yè)務(wù)以及業(yè)務(wù)系統(tǒng)再開發(fā)， 在產(chǎn)品研發(fā)前，產(chǎn)品經(jīng)理最好組織多方人員，針對數(shù)據(jù)治理可行性方案進(jìn)行溝 通，再考慮是否針對這個需求進(jìn)行研發(fā)。 3. 用戶層面我經(jīng)歷過一個項目，報表已經(jīng)全部研發(fā)完成，但是數(shù)據(jù)質(zhì)量只能達(dá)到95%的準(zhǔn)確率，達(dá)到百分之百準(zhǔn)確流程，需要有專門人員對于業(yè)務(wù)系統(tǒng)一個字段的數(shù)據(jù)質(zhì)量定期維護(hù)管理。 在報表研發(fā)前，我們與用戶都覺得是一個很簡單的問題，到時候安排一個人就行了。但事實上，由于這個工作會占用比較多的時間，負(fù)責(zé)的用戶需要額外承擔(dān)工作量，之前說的簡單的一個問題就這樣不了了之，最終影響到產(chǎn)品也沒有用起來。 在一個產(chǎn)品研發(fā)前，需要用戶參與的工作部分，我們往往高估了用戶的配合性，甚 至是用戶自己。 在可行性評估階段，數(shù)據(jù)產(chǎn)品要將會遇到的問題與用戶溝通清楚，并基于 評估結(jié)果給出是否建議研發(fā)的意見，甚至與用戶達(dá)成約束條件，保證產(chǎn)品使用頻率。 05 需求優(yōu)先級管理是最后護(hù)航很難說用戶在提一個需求之前沒有經(jīng)過慎重考慮，但事實上，經(jīng)常會出現(xiàn)用戶自己提的產(chǎn)品需求自己卻不用的情況，經(jīng)過上面兩輪需求管控之后，仍然建議產(chǎn)品經(jīng)理將用戶需求排優(yōu)先級，倒逼用戶再對需求進(jìn)行進(jìn)一步的篩選。 我上一個項目，經(jīng)過前兩輪的溝通后，最后還剩25個報表需求，但用戶堅持是必須要開發(fā)的?；谶@個情況，我讓用戶將25張報表進(jìn)行了高中低優(yōu)先級的排布，選出8張表為期一個月進(jìn)行最優(yōu)先級開發(fā)，并要求用戶針對每張表對應(yīng)的崗位以及每月使用次數(shù)做了使用頻次評估及承諾。 最后，開發(fā)出來的表使用情況都達(dá)到了用戶約定，但是剩余表到今天為止用戶仍沒有要求繼續(xù)。 06 需求管控不是為了讓用戶不提需求之所以要做需求管控，絕對不是為了讓用戶不再提報需求，退一步講，他們沒有開發(fā)需求，那我們這批人存在的價值在哪里？ 大數(shù)據(jù)火了好幾年，但是很多公司仍處于摸索的階段，我們允許去試錯，但是不代表要盲從去滿足。開發(fā)資源很少，時間也很有限，我們希望每一個開發(fā)的產(chǎn)品都是真正用戶需要的且能被使用的。數(shù)據(jù)平臺上的產(chǎn)品從上線下線要有良性的周期循環(huán)，且朝著越來越好的狀態(tài)進(jìn)行。 所以，需求管控很重要，他決定了一個項目是否能成功，甚至影響到數(shù)據(jù)平臺的建設(shè)及影響力。 以上，希望能對你有幫助。 作者：王小涂，微信公眾號：數(shù)據(jù)產(chǎn)品經(jīng)理進(jìn)階之路（ID：DATAPMLZ）希望和你一起探討數(shù)據(jù)產(chǎn)品經(jīng)理進(jìn)階之路！ |
|
|
