首次需求流程

對于業務方首次提出的需求，重點工作在于評估完成該需求的技術、數據、合規的可行性后，以細化需求的方式完成產品需求文檔，并組織需求評審會議多方共同敲定需求最終實現方案。

首次需求流程包括以下步驟：

1. 提出需求
   • 外部溝通：數據產品經理主導，負責與外部門業務方充分溝通。力求獲取并理解業務場景（背景）、目標和實現價值。
     說明 此處不必與業務方討論需求實現的途徑或細節，雙方只了解需要達到什么目標，而不討論如何實現。
   • 完成產品需求文檔的初稿：得到充分信息后，按照數據倉庫需求模板中的常規需求申請單，將需求轉化為產品需求文檔的初稿。
2. 分析需求
   • 可行性分析：數據產品經理主導，邀請設計、數據安全與合規人員，對需求進行評估。
     • 需求合理性：評估該需求的合理性。
     • 數據可行性：評估當前已有數據能否支撐需求開發，如果缺少數據，則需要另行規劃缺失數據的抽取方案。

       同時建議進行深入的數據探查，包括但不限于數據完整性、字段離散值分布情況、空值、零值、重復值占比等情況。

     • 技術可行性：評估當前已有數據模型能否支撐需求開發，如果不能，則需要規劃模型改造方案，并充分評估其影響。同時在測試環境進行模型測試。
       說明 如果涉及資損、精確對賬或其他關鍵模型的改造，測試人員必須進行測試。
     • 是否滿足安全與合規要求：根據企業自身數據安全的要求，嚴格控制數據內部流向，劃分研發過程中數據可流入的庫、項目、表、字段等。對于流出外部的數據，更需要嚴格評估流出數據內容、流出目的地是否符合公司數據安全的要求。
       說明 此項評估是不可跳過的步驟。
   • 實現細節分析：數據產品經理主導，對實現需求的細節關鍵點進行確認，包括但不限于數據口徑、接口格式、供數頻率和需求優先級。
   • 完善產品需求文檔：完善產品需求文檔的初稿。
3. 評審需求

   數據產品經理主導，邀請設計人員、測試人員發起需求評審會。會議內容主要包括：

   • 各方提出對于產品需求文檔中各細節的疑問。
   • 共同達成對于疑問的解決方案。
     說明 評審會議上不得遺留影響后續研發流程的關鍵問題，否則視為評審不通過。
4. 確認需求

   N個工作日（視各企業實際情況而定）內如果無異議，則產品需求文檔定稿，并開始進入后續的設計與開發階段。

迭代需求流程

對于同一需求，在完成首次需求評審并定稿產品需求文檔后，業務方再次提出的需求，均屬于迭代需求。

迭代需求的流程與首次需求流程類似，均需進行可行性分析、實現細節分析。分析完成后，視實際情況來定是否需要再次進行需求評審，最終將新老需求合并至產品需求文檔終稿。

迭代需求流程包括以下步驟：

1. 申請需求變更

   數據產品經理完成業務方迭代需求對接后，將新的需求錄入數據倉庫需求模板的迭代需求申請單中。

   說明 如果企業具備需求相關管理平臺，建議通過平臺+數據庫形式規范化存儲不斷迭代的每個需求版本。
2. 評審需求變更

   原則上需求評審需由數據產品經理發起評審會議來完成，但如果需求迭代內容不多，評審方式可視情況而定選擇郵件或現場會議方式，具體視變更內容由變更委員會決定。

   評審內容仍為實現需求必須面對的技術可行性、數據可行性、安全與合規要求性展開討論，如果多方有異議，則必須共同達成一致性解決方案。

3. 確認并合并需求

   數據產品經理將上一版本定稿的產品需求文檔內容，與本次評審定稿的產品需求文檔內容進行合并。

   如果兩個工作日內無異議，則視為需求確認。