<code id="okdk5"></code><strike id="okdk5"><small id="okdk5"><samp id="okdk5"></samp></small></strike>

    <tr id="okdk5"><sup id="okdk5"></sup></tr><strike id="okdk5"></strike>

  1. <code id="okdk5"></code>
    <code id="okdk5"></code><strike id="okdk5"><sup id="okdk5"></sup></strike>
  2. 主頁 > 超兔理念 > 以“鎖庫”實例解構:從需求分析到方案確定

    以“鎖庫”實例解構:從需求分析到方案確定

    曾幾何時,當有系統分析員角色時,系統分析員負責需求、邏輯分析并出方案。在產品經理時代,系統分析員的工作有相當一部分被產品經理分擔。產品經理的角色位于:用戶和開發人員之間,他們既要懂客戶和業務,也要了解大致的開發邏輯。這樣才能盡可能接近系統分析員的初級能力。從需求到方案,需要哪些核心步驟,考慮哪些因素,才能做出一份完整的需求和業務方案?我們以“鎖庫”實例解構這個過程,共同提取步驟和因素的要點。

    ●原始需求:客戶希望能鎖庫,銷售遇到核心保障的訂單,在訂單執行前鎖庫。

    ●匯總分析:需求方向明確:鎖庫;需求細節模糊;沒有完整邏輯。

    ●重點思考:如何應對類似:方向明確、強業務場景、細節模糊、缺乏完整結構的需求?從下面5點展開分析:

    一.產品經理,需明確理解。用戶提供需求經常是碎片式的。我們需根據碎片補充:

    ① 業務邏輯:場景、場景的上下文(或者叫前后相關的業務)、崗位、職責、異常處理、設備載體(PC,手機、打印紙張)

    ② 數據邏輯:角色、權限、狀態機、數據動作、看門狗

    ③ 泳道圖:當需求涉及多角色多狀態時,最能清晰表達業務流程

    ④ 流程圖:程序處理的主邏輯

    二.基于現軟件已有邏輯來分析。需求的實現前提,必須基于現軟件系統的已有邏輯。即:不能和既有邏輯沖突,也不能和既有的名詞、定義或操作習慣沖突,所以必須在熟悉現軟件數據結構的前提下做可行性思路。

    鎖庫的核心需求:在發貨時,能保護鎖庫的數量不會被發出。2個可行思路:

    A:虛擬庫方案:

    >建立一個虛擬倉庫A,專門用于存放鎖庫產品;

    > 鎖庫時,所有鎖庫產品均調撥到倉庫A;

    > 鎖庫產品出庫時,從倉庫A出庫發貨,或調撥到正常發貨倉發貨;

    > 其他出庫時,因為鎖庫產品在專用倉,所以不用特殊校驗。

    B:鎖庫明細方案:

    > 新增鎖庫明細表,用于承載鎖庫數據;

    > 鎖庫時,創建鎖庫明細數據;

    > 出庫時,判斷條件增加鎖庫數量。

    以“鎖庫”實例解構:從需求分析到方案確定
    以“鎖庫”實例解構:從需求分析到方案確定
    以“鎖庫”實例解構:從需求分析到方案確定

    方案對比:在對比方案前,均需要細化方案到具體功能描述和數據結構,特別是狀態機。只有在方案層展開細化,才能避免開發中途遇到難以逾越的邏輯卡點經過兩套方案的細節展開后。

    A:虛擬庫方案:

    優點:沒有新增表,基本為原邏輯的組合;

    缺點:虛擬庫+調撥的過程比較復雜,在用戶理解角度會感覺不太直接。

    B:鎖庫明細方案:

    優點:業務含義明確,執行邏輯雖然新增校驗,但是整體理解更順暢;

    缺點:新增數據表:鎖庫明細。

    小結:功能是為了解決用戶問題,一般我們會優選用戶角度易用好理解的方案,除非是完全沒有交互的后臺功能。雖然鎖庫增加了實體表(除非必要勿增實體),但對比可知,顯然是必要的。

    三.根據經驗補充為完整邏輯。到這里,主方案思路確定:鎖庫明細表方案。繼續完整邏輯:

    1)鎖庫有鎖,就要有解鎖;

    2)解鎖有多種情況:a.手工解鎖,比如訂單取消了;b.發貨解鎖,已經發貨,就無需繼續鎖定;c.超期解鎖,鎖庫不能沒有期限,雖然手工解鎖可彌補,但加上期限自動化程度就更高。

    3)鎖庫的角色權限:a.銷售提請鎖庫;b.庫管確認鎖庫;c.庫管可手工解鎖。

    以“鎖庫”實例解構:從需求分析到方案確定
    以“鎖庫”實例解構:從需求分析到方案確定
    以“鎖庫”實例解構:從需求分析到方案確定

    四.按場景業務推演,查漏補缺。補充完整邏輯后,要做業務功能的要點和場景總結:

    1)銷售基于訂單明細申請鎖庫,由庫管確認;

    2)庫管確認后的鎖庫會參與出庫校驗;

    3)出庫校驗時算法為:庫存-鎖庫總量+當前出庫明細對應的鎖庫明細量。即:出庫自動解鎖當前鎖庫,所以校驗鎖庫數量時,需去除當前鎖庫量;

    4)鎖庫超期自動解鎖(顆粒度:天)。

    五.異常情況復盤,查漏補缺。上述主體結構已經比較完善,仍然需要根據所有步驟相關的數據表找異常數據情況做一遍復盤:

    1)如果當前庫存不夠,是否允許鎖庫?

    其業務邏輯是:雖然庫里沒有,但我需要提前鎖定,因為這個客戶重要。

    2)如果當前庫存不夠全部鎖庫,且當前出庫有鎖庫,是否允許當前出庫?

    其業務邏輯是:庫存不夠全部鎖庫,但是夠我這單鎖庫的數量,是否讓我出?

    不難看出,上述問題均為數據異常時(這里的異常,指的是不滿足業務必要條件)出現的;所以我們在分析需求時,特別要注意,不能只考慮正常邏輯,異常邏輯的處理、容錯非常重要,這決定了軟件的魯棒性。

    分析:

    1)庫存不夠,提前鎖庫。——業務角度合理,應支持實現。

    2)庫存不夠全部鎖庫,但是夠當前出庫的鎖庫,是否允許發?這背后是一個鎖庫優先級的問題:

    這里的優先級應該由人來判斷,需增加當前產品鎖庫相關明細的查看,而不是做嚴格邏輯約束,以應對各種可能性。因為鎖庫本身就是一個出庫的高優先,如果再增加內部優先排序,反而會增加系統使用的復雜度,意義不太大。

    至此,鎖庫的需求分析和基礎解決方案確定。中間省略了大量的展開細節文檔,是為了更容易展現這個過程的結構。在實際工作中,展開細節文檔很重要,不能用一個粗線條的方案來確定整體可行性。把80%的精力放在20%的關鍵事情上,底層邏輯一旦打通,再由程序員把需求轉化為代碼,可大大減少不必要的試錯!

    【文中圖示為:按此方案開發后的鎖庫部分界面】

    韩国专线福二区