• 3個步驟,快速分析toB産品需求

    /2019-08-10 14:43:18/

  • \

    拿到tob産品需求時,你一般會如何進行分析呢?你的常用分析方法是什麼呢?如果你不知從何下手,那通過本文,你可以快速掌握三個分析方法,解決這一難題。

    一拿到toB的産品需求總是抓耳撓腮,不知道從哪裡開始,甚至開始了也混亂不堪。但經曆幾個産品後發現再複雜的系統也有章可循——通過自下而上的找點、連線、畫面。那如何找點,怎樣連線,用什麼畫面?

    一、用“實體關系圖(ERD)”尋找【點】

    實體關系圖的概念來源于關系型數據庫,也就是ER模型,主要用在信息系統的設計。但我發現簡化了其中的理論後用來做需求梳理也很好。

    具體做法就是:

    • a. 拿到系統需求先抽象其中涉及的實體;
    • b. 找出實體和實體間的對應關系,并繪圖。

    那麼接下來您可能要問:

    什麼是實體?

    實體的官方解釋:實體是客觀存在并可相互區别的事物。就數據庫而言,實體往往指某類事物的集合。

    我認為需求中反複出現的名詞、可用屬性描述的事物都可以抽離出來作為真正實體的備選,然後反複對比、去重(名字不同實際相同)得到所有實體。

    舉個例子:

    需求:客戶希望做一個應用,這個應用能使巡檢員看到企業的所有幫助文檔、可以查看企業的最新資訊;可以通過巡檢員在app的報修行為産生工單,工單可以通過管理員分派給維修人員進行維修,維修完成後管理員檢查是否合格,如果合格關閉工單,如果不合格重新分派。

    根據此需求可以抽象出如下實體:幫助文檔、資訊、工單、用戶、管理員、維修人員,并兩兩關聯看是否有強關聯(兩個實體有關系),如果有則在兩個實體之間畫一條線。

    得到如下實體圖:

    \

    什麼是對應關系?

    對應關系有幾種:一對一、多對多、一對多。

    • 一對一(1:1):1個實體A對應1個實體B,1個實體B對應1個實體A。
    • 一對多(1:N):1個實體A對應多個實體B,1個實體B對應1個實體A。
    • 多對多(M:N):1個實體A對應多個實體B,1個實體B對應多個實體A。

    舉例:依舊按照問題1中的例子:顯然一個維修員可以看多篇幫助文檔,而1篇幫助文檔可以被多個維修員看,那麼維修員和幫助文檔就是多對多的關系,兩兩對應後得出如下結論:

    \

    怎麼繪圖,有什麼工具可以繪圖?

    以前都是用Visio繪制,但現在有很多線上工具也很好用,比如我現在用的ProcessOn。線上工具的好處是:網站不定期提供很多素材和模闆,使用體驗也比傳統的Visio好很多,重點是還可以和其他同事協作。

    經過以上3個步驟後實體以及實體間的關系已經基本清晰了,也就是系統要做哪些模塊大緻确定,如果功力夠深,系統的表結構都有了模糊的呈現。

    舉例:依舊按照問題1中的例子,系統的模塊大緻是用戶管理、幫助文檔管理、資訊管理、工單管理。

    (如果想更深入的學習ERD,比如有在圖上标識某些實體是否可以為空,了解ERD繪制的标準、在ERD中添加屬性等等要求,有很多材料可供學習,在此就不贅述了。

    參考:如何使用Entity Relationship Diagram (ERD) 建模 – 關系數據庫設計

    二、通過“功能權限、數據權限的梳理”連【線】

    功能權限、數據權限的問題在大型系統中是邏輯最為複雜的模塊,牽連甚廣。

    在進行權限的梳理前要明确:使用系統的角色有哪些?角色是自由配置還是内置寫死?

    一般大型系統組織結構複雜,用戶靈活多變,角色是需要自由配置的,而小型的系統可能根據真實場景内置幾個定義好的角色就可以。

    舉例:

    仍舊是這個例子:客戶希望做一個應用,這個應用能使巡檢員看到企業的所有幫助文檔、可以查看企業的最新資訊;可以通過巡檢員在app的報修行為産生工單,工單可以通過管理員分派給維修人員進行維修,維修完成後管理員檢查是否合格,如果合格關閉工單,如果不合格重新分派。

    這個需求的業務足夠簡單,角色隻有:管理員、巡檢員、維修員,可以采用内置于系統的方式。

    功能權限的梳理

    角色是功能權限的集合,那麼功能權限的梳理也就變成了:哪些角色對哪些功能可寫(增删改),對哪些功能可讀(查看),對哪些功能不可讀不可寫?而描述清楚這些問題的最好方式是表格。

    舉例:根據需求,管理員對用戶管理、幫助文檔、資訊、工單可讀可寫,而維修員對幫助文檔、資訊可讀不可寫,對工單可讀可寫,梳理如下:

    \

    有了這張表,各個角色的功能權限就較為清晰了。但是為什麼能看到同一模塊的兩個用戶看到的數據卻是完全不一樣?這是因為他們的數據權限不一樣。

    數據權限梳理

    兩個用戶在同一個模塊看到的數據不一樣是因為他們的數據權限不一樣。梳理數據權限的意義在于明确不同用戶可讀或者可寫的數據範圍。

    如何梳理?

    用戶對哪些數據可讀可寫與角色、組織架構有關。有的組織是扁平組織,有的則是一層一層的樹形組織。我很多時候仍舊是在功能權限說明表的基礎上重新描述數據權限。

    繼續之前的例子,将功能權限表的内的“√”替換為數據權限說明:

    \

    根據功能權限說明表和數據權限說明表,維修員的權限就可以概述為:可讀寫工單,但隻能讀寫自己的工單。

    例子中的需求較為簡單,但真實情況往往是這樣的:

    \

    所以,以上隻是從工具層面介紹如何梳理權限,但真實的系統往往更複雜,比如功能權限的粒度是更小的按鈕或者接口,比如引入标簽系統。如果想深入學習可以繼續研究RBAC權限模型并結合實際項目不斷練習。

    (參考:什麼是基于角色的訪問控制(RBAC)?

    三、用“流程圖”繪制系統的【面】

    系統要對哪些實體進行管理、系統如何進行權限訪問控制兩個問題理清後需要一條橫向的線将業務串起來形成【面】,流程圖便可以幫我們找到那條橫向的【線】。

    什麼是流程圖?

    流程圖是用來描述各個實體間的關系、系統作業順序和信息流向的圖表。任何的系統都有流程,隻是簡單和複雜的區别。

    流程圖可以幫我們理清很多業務流程和數據流向,也是原型之前對系統的邏輯思考,簡單系統的業務流程通常用一個泳道圖就畫完了,而複雜系統可能需要分模塊、分層級進行狀态圖、時序圖、流程圖等不同類型的圖表的繪制才能大緻解釋清楚業務邏輯。

    如何畫流程圖?

    如果流程圖隻是作為需求階段的中間輸出物,天馬行空地畫也未嘗不可,有時還能在某個點迸出創新的火花,但如果作為正式的輸出物,可能就要拘泥于UML的标準了。

    1. 根據需求從開始到終點繪制該角色的操作流程,如果某些活動涉及多種角色則使用泳道圖;

    舉例:

    \

    \

    2. 某些實體有複雜的狀态變化使用狀态圖;

    \

    3. 實體間傳遞信息有明顯的時間順序使用時序圖。

    \

    系統邏輯經過流程圖的繪制後就變得清晰了,系統的神秘面紗被慢慢揭開。原型圖有了這些圖表作為邏輯支撐,效率和可用性都會大大提升。

<
上一篇: 如何定義B端産品的MVP(一) 下一篇: 傳統企業數據中台的建設與思考

聯系我們

一個新的需求,從這裡開始。歡迎填寫表格或發送合作郵件至: 25909395@qq.com 25909395@qq.com 加微信: 13765801787

13765801787
在線留言