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