3個步驟,做中後台產品的需求管理

PMBear

在產品經理的工作中,需求管理無疑是最核心的工作內容之一,但如何做好這項工作呢?筆者將為我們分析個人怎麼做中後台產品需求管理的思路和步驟。

中後台的產品往往是面向企業或者組織的產品。在進行需求管理時,除了要關注產品的實際使用者,還需要關注企業或組織的需求。

我們可以簡單地把所要面對的用戶進行分類:高層領導、中層管理者、普通員工。其特性分別如下:

  • 高層領導:關注長遠期產品價值,希望通過產品能夠對公司業務有整體的了解;
  • 中層管理者:關注目標的達成、關心業務流程的順暢、各個環節的職責,希望對團隊中的成員的完成結果有詳細的了解;
  • 普通員工:關注自己需要進行的功能操作,及判斷其操作的標準。

我們把需求管理劃分為如下幾個步驟:需求調研、需求分析、需求實現(優先級劃分),其他的產品工作環節暫且忽略。

一、需求調研

在做需求調研之前,我們一定要確定調研對象,我們可以通過公司的組織架構,對整體的業務有一個初步的了解。如果已經配合過多次的項目,則要自己整理整體的業務流程中涉及的用戶。

在確定了調研對象后,需要組織專門的需求調研會議。會議形式可根據實際情況而定,但一定要通過郵件的形式完成會議邀請和會議紀要。

在需求調研會議上,我們需要對參會人進行一個初步的判斷,有兩個標準:權利和相關度。

  • 權力大、相關度高的參會人提出的需求或問題,一定要進行詳細地了解,並記錄清晰;
  • 而對於權利大、相關度小的參會人提出的建議,則需要虛心接受,若不能進行實現需要及時說明;
  • 對於權利小、相關度高的人需要重點關注,在會後可與其進行更多細節性的討論;
  • 而對於權利小、相關度低的人則充分聽取其意見即可。

以上分類,也是各類用戶的需求產生矛盾時解決問題的標準:第一類人的需求最需求優先解決;其次看權利小、相關度大;再次看權利大、相關度小;最後一類視情況進行完成。

在會上,我們要儘可能地引導用戶把需求描述的更準確,可採用如下固定模式:

(1)你們想在有哪些崗位或者角色?

(2)每個角色有負責有哪些業務?

  • 描述下該業務的流程是要解決一個什麼樣的問題?
  • 業務中涉及哪幾個崗位或角色?
  • 業務的步驟有哪些,並簡要描述下。
  • 有沒有異常情況,異常情況如何處理?
  • 在管理上有沒有什麼要求?例如:異常預警;領導查看權限;領導才有的特殊操作;報表。

(3)每個崗位或角色如何進行彙報,有沒有相關的報表格式

二、需求分析

通過以上的相關問題,我們可以清晰地了解到公司業務的基本情況,而以崗位或角色為切入點進行需求的調研,會十分方便我們後續進行需求分析。

中後台產品重業務邏輯,而業務邏輯就是通過每一個角色的一個一個操作動作串聯起來的。

從收集到的需求中,分辨出來哪些步驟或邏輯能夠在系統中實現,哪些不能。這樣,能很好地劃分系統的邊界。

系統最擅長處理計算、存儲、查詢以及跨地域傳輸信息的工作,我們不能把所有的業務操作都系統化,系統如果管得過細會加重業務人員的負擔。

在需求分析中,我們首先需要根據前面所整理的資料按業務功能建立用例圖,用例圖一般有三種元素:參與者、用例、系統邊界。

用例圖的繪製需要注意一下幾點:

  • 以一個解決具體事務的流程為視角,一張用例圖盡量把一個業務說清楚。
  • 用例圖的描述要以用戶的角度出發。例如:“添加員工信息”對於用戶來講應當是做什麼呢——填寫新員工資料;“更新員工信息”對於用戶來講又是做什麼呢——更改員工資料;“刪除員工信息”又是什麼呢——員工註銷。
  • 用例圖也可以有層級,可以有系統級的用例圖,也能有功能級的流程圖。

我們根據用例圖中定義的角色、操作,通過業務流程圖按執行的時間順序或分角色串聯起來。

我們需要準確定義順序、分支、循環等邏輯的判斷標準,使其形成完整的業務流程。

在業務流程中,我們需要已明確的圖示來區分系統完成和線下完成,且設計好從線下到線上、線上到線下的對接功能。

通常這種從虛擬到現實的對接功能,包含:導出、打印、發送、導入、上傳等。在設計這種功能時需要注意相關的校驗、去重、個性化定製等特殊的需求。

在需求分析階段,我們經常會發現一些新的衍生需求,這時我們需要快速找到對應的干係人,與其溝通討論。

用戶在未見到系統之前,其提出的需求都有可能把某一些關鍵信息遺漏,有些他們習以為常的常識我們做需求分析的人是不知道的。

由於我們進行完需求分析后可能會發現有大量的需求要去實現。如果一次把所有的需求都進行實現,我們付出的成本太高,用戶等待的周期過長。而且可能會發生實現的產品與客戶的期望差距太遠。

為了解決成本、周期、期望的問題,我們需要對需求進行優先級劃分,以實現快速迭代逐步交付的目的。

通過快速迭代能夠讓用戶提前接受產品,以矯正前期由於空對空造成的需求缺陷的問題,一般第一個迭代的周期在兩個月之內為正常,後續的迭代需要維持在2到4周為最佳。

三、如何進行優先級的劃分呢?

有一個基本的原則供大家參考:權利大的優於權利小的,相關度高的優於相關度低的,功能優於報表,正常優於異常。

如果使用原則是有衝突,則找到實際使用者中的業務專家,與其確定優先級,在彙報該權力大且相關度高的領導。

通過基本原則劃分后,我們還需要組織相關的需求優先級確認會議,與相關干係人達成共識,讓其了解迭代計劃的具體情況。

而在每一周,我們均需要對迭代計劃執行的情況以郵件的形式進行同步,對於核心干係人則可以在固定周期以彙報的形式同步情況。

 

本文由 PMBear 作者:小熊爸爸 发表,其版权均为 PMBear 所有,文章内容系作者个人观点,不代表 PMBear 对观点赞同或支持。如需转载,请注明文章来源。
PMBear

发表评论