本文轉載自微信公眾號「大數據技術與數倉」，作者西貝 。轉載本文請聯系大數據技術與數倉公眾號。

引言

伴隨著業務的發展，業務方通常會提各種各樣的數據需求。面對繁雜的需求，數據研發可能會遇到下面這些問題：

• 怎么才能做到高效、高質量地交付數據需求?
• 對于新業務需求，怎么才能快速把握?
• 怎么應對需求的反復修改?
• 該如何say no
• ...

面對這些問題，我們需要學會做好業務方的管理，這樣才不至于讓自己陷入被動的深淵而不能自拔。

窘境

面對源源不斷的需求，數據研發會越發地感覺到自己只是一個取數的工具而已，因為都是在被動的接需求，久而久之，業務方也會覺得你就是一個取數的工具。大小問題，隨時拋過來，只管要數，其他的一概不管。你要是說：[我事情太多，沒空做]，或者[需求沒有意義，往后排]，那么業務方可能直接找到你的主管來協調，最后事情還是你的事情，還是要乖乖地去完成他們的需求，即便你是不情愿的。那么怎么才能改變這種局面呢?

屁股決腦袋，立場不同，思考問題的角度也不同，做出的判斷和決策也是不同的。所以想要破解這種尷尬的境地，需要我們轉換一下立場去看問題。

• 從個人主觀因素出發

業務方把自己當做了取數的工具，很無奈，很排斥，總之一句話，就是不想做，即便是要做，業務方也要把背景講清楚，而不是隨便拋過來需求。

• 從做事情的角度出發

靈魂拷問：需求的背景是什么?有什么價值?對后續的運營決策有什么幫助?沒有其他的數據可看嗎?不做行不行，如果資源有限改如何排優先級?該如何去獲取更多的背景信息，為什么業務方要關注這些指標?需求背后的真正訴求是什么?我能夠提供什么?

可以看出，從不同的角度看問題，會出現不同的判斷，我們應該站在解決問題的角度去思考，與業務方達成某種潛規則，這樣我們才能做到來者可拒，游刃有余。

破局

轉換角度看問題之后，具體我們要怎么做呢?首先我們來看下一個需求開發的流程：

• 首先，業務方提交MRD，交由數據PD去判斷整理
• 然后，數據PD產出PRD，交由數據研發開發
• 最后，數據研發評審，給出具體的排期

我們先來看MRD是干什么用的，MRD指的是市場需求文檔，主要描述通過什么業務方案來解決什么問題、達成什么業務目標。要解決的是讓關聯 PD 清楚業務訴求、認可業務方案，并可落地設計產品方案。MRD 書寫語言為業務視角語言，無需涉及產品/技術實現。通常情況下，MRD包括以下內容：

• 業務問題：客戶是誰、業務背景是什么、業務的痛點是什么、業務的痛點是什么
• 業務目標：包含具體的業務目標、業務價值
• 業務方案：包含整體的方案、涉及的業務流程、具體的業務功能需求、運營計劃

基于這些內容，數據PD要產出一份PRD，基于業務需求及產品能力進行產品方案設計，通過產品方案支持業務方案落地，使業務、研發認可通過產品方案可支持業務目標實現，通常情況下，PRD要包含以下內容：

• 需求背景
• 業務價值
• 需求描述
• 產品方案

有了PRD之后，就到了數據研發登場了，這個時候需要把所有事情搞清楚，不然的話很容易跑偏影響交付的效率。到了需求評審階段，數據研發需要做三個方面的事情：核心思想是批判與挑戰，當然是要有理有據有節，而不是為了逃避任務而無理取鬧。

• 挑戰：需求是否合理，可不可以不做

需要了解數據的使用方是誰?業務背景，業務痛點?期望達到的業務目標(最好是定量)是什么?數據的使用場景是什么?緊急程度如何?

• 評審：需求溝通

積極了解業務需求相關資料，包括業務背景，痛點、目標、及運營方案。知道業務想干什么，為什么要這么干，我們在這里面能做什么。

考慮實現方案設計

對于比較復雜的數據產品，需要提前進入產品的規劃中

確定相關干系人在場，避免導致重復溝通

詳細的數據口徑確認(數據范圍、維度、指標口徑、產出時間等等)

• 排期

經過前面的溝通，可以跟業務、PD、前端達成一致，這個時候就需要我們給出一個具體的排期，包括什么時候開始做，什么時候交付。對于復雜的需求或者新業務需求，要做到需求的拆解，給出預估的時間，同時也要留出一定的buffer，用于數據驗證和方案調整，如果實在給不出一個具體的排期，也要告知到相關的業務，等梳理清楚之后，再給出一個合理的排期。

總結

本文主要介紹了作為數據研發該如何破局被動接需求的尷尬境地，核心的點在于要改變看問題的立場，多站在解決問題的角度去思考背后的邏輯。與業務方及相關干系人達成某種潛規則才是我們解決問題的杠桿，這樣才能真正做到來者可拒，使自己不至于那么被動，同時也能夠明確責任，提高效率。