編輯導(dǎo)語(yǔ)：曾經(jīng)，系統(tǒng)分析員負(fù)責(zé)需求、邏輯分析并出方案。如今，系統(tǒng)分析員的部分職責(zé)被產(chǎn)品經(jīng)理分擔(dān)。那么，從需求到方案確認(rèn)，產(chǎn)品經(jīng)理們需要考慮哪些核心步驟與因素？本文以“鎖庫(kù)”為例，總結(jié)了五點(diǎn)應(yīng)對(duì)的方法。

曾幾何時(shí)，當(dāng)有系統(tǒng)分析員角色時(shí)，系統(tǒng)分析員負(fù)責(zé)需求、邏輯分析并出方案。

在產(chǎn)品經(jīng)理時(shí)代，系統(tǒng)分析員的工作有相當(dāng)一部分被產(chǎn)品經(jīng)理分擔(dān)。產(chǎn)品經(jīng)理的角色位于：用戶(hù)和開(kāi)發(fā)人員之間，他們既要懂客戶(hù)和業(yè)務(wù)，也要了解大致的開(kāi)發(fā)邏輯。這樣才能盡可能接近系統(tǒng)分析員的初級(jí)能力。

從需求到方案，需要哪些核心步驟，考慮哪些因素，才能做出一份完整的需求和業(yè)務(wù)方案？我們以“鎖庫(kù)”實(shí)例解構(gòu)這個(gè)過(guò)程，共同提取步驟和因素的要點(diǎn)。

• 原始需求：客戶(hù)希望能鎖庫(kù)，銷(xiāo)售遇到核心保障的訂單，在訂單執(zhí)行前鎖庫(kù)。
• 匯總分析：需求方向明確：鎖庫(kù)；需求細(xì)節(jié)模糊；沒(méi)有完整邏輯。
• 重點(diǎn)思考：如何應(yīng)對(duì)類(lèi)似：方向明確、強(qiáng)業(yè)務(wù)場(chǎng)景、細(xì)節(jié)模糊、缺乏完整結(jié)構(gòu)的需求？從下面5點(diǎn)展開(kāi)分析：

一、產(chǎn)品經(jīng)理，需明確理解

用戶(hù)提供需求經(jīng)常是碎片式的。我們需根據(jù)碎片補(bǔ)充：

• 業(yè)務(wù)邏輯：場(chǎng)景、場(chǎng)景的上下文（或者叫前后相關(guān)的業(yè)務(wù)）、崗位、職責(zé)、異常處理、設(shè)備載體（PC，手機(jī)、打印紙張）
• 數(shù)據(jù)邏輯：角色、權(quán)限、狀態(tài)機(jī)、數(shù)據(jù)動(dòng)作、看門(mén)狗
• 泳道圖：當(dāng)需求涉及多角色多狀態(tài)時(shí)，最能清晰表達(dá)業(yè)務(wù)流程
• 流程圖：程序處理的主邏輯

二、基于現(xiàn)軟件已有邏輯來(lái)分析

需求的實(shí)現(xiàn)前提，必須基于現(xiàn)軟件系統(tǒng)的已有邏輯。

即：不能和既有邏輯沖突，也不能和既有的名詞、定義或操作習(xí)慣沖突，所以必須在熟悉現(xiàn)軟件數(shù)據(jù)結(jié)構(gòu)的前提下做可行性思路。

鎖庫(kù)的核心需求：在發(fā)貨時(shí)，能保護(hù)鎖庫(kù)的數(shù)量不會(huì)被發(fā)出。2個(gè)可行思路：

A：虛擬庫(kù)方案：

• 建立一個(gè)虛擬倉(cāng)庫(kù)A，專(zhuān)門(mén)用于存放鎖庫(kù)產(chǎn)品
• 鎖庫(kù)時(shí)，所有鎖庫(kù)產(chǎn)品均調(diào)撥到倉(cāng)庫(kù)A
• 鎖庫(kù)產(chǎn)品出庫(kù)時(shí)，從倉(cāng)庫(kù)A出庫(kù)發(fā)貨，或調(diào)撥到正常發(fā)貨倉(cāng)發(fā)貨
• 其他出庫(kù)時(shí)，因?yàn)殒i庫(kù)產(chǎn)品在專(zhuān)用倉(cāng)，所以不用特殊校驗(yàn)

B：鎖庫(kù)明細(xì)方案：

• 新增鎖庫(kù)明細(xì)表，用于承載鎖庫(kù)數(shù)據(jù)
• 鎖庫(kù)時(shí)，創(chuàng)建鎖庫(kù)明細(xì)數(shù)據(jù)
• 出庫(kù)時(shí)，判斷條件增加鎖庫(kù)數(shù)量

方案對(duì)比：在對(duì)比方案前，均需要細(xì)化方案到具體功能描述和數(shù)據(jù)結(jié)構(gòu)，特別是狀態(tài)機(jī)。只有在方案層展開(kāi)細(xì)化，才能避免開(kāi)發(fā)中途遇到難以逾越的邏輯卡點(diǎn)經(jīng)過(guò)兩套方案的細(xì)節(jié)展開(kāi)后。

A：虛擬庫(kù)方案：

優(yōu)點(diǎn)：沒(méi)有新增表，基本為原邏輯的組合；

缺點(diǎn)：虛擬庫(kù)+調(diào)撥的過(guò)程比較復(fù)雜，在用戶(hù)理解角度會(huì)感覺(jué)不太直接。

B：鎖庫(kù)明細(xì)方案：

優(yōu)點(diǎn)：業(yè)務(wù)含義明確，執(zhí)行邏輯雖然新增校驗(yàn)，但是整體理解更順暢；

缺點(diǎn)：新增數(shù)據(jù)表：鎖庫(kù)明細(xì)。

小結(jié)：功能是為了解決用戶(hù)問(wèn)題，一般我們會(huì)優(yōu)選用戶(hù)角度易用好理解的方案，除非是完全沒(méi)有交互的后臺(tái)功能。雖然鎖庫(kù)增加了實(shí)體表（除非必要勿增實(shí)體），但對(duì)比可知，顯然是必要的。

三、根據(jù)經(jīng)驗(yàn)補(bǔ)充為完整邏輯

到這里，主方案思路確定：鎖庫(kù)明細(xì)表方案。繼續(xù)完整邏輯：

1）鎖庫(kù)有鎖，就要有解鎖

2）解鎖有多種情況

• 手工解鎖，比如訂單取消了；
• 發(fā)貨解鎖，已經(jīng)發(fā)貨，就無(wú)需繼續(xù)鎖定；
• 超期解鎖，鎖庫(kù)不能沒(méi)有期限，雖然手工解鎖可彌補(bǔ)，但加上期限自動(dòng)化程度就更高。

3）鎖庫(kù)的角色權(quán)限

• 銷(xiāo)售提請(qǐng)鎖庫(kù)；
• 庫(kù)管確認(rèn)鎖庫(kù)；
• 庫(kù)管可手工解鎖。

四、按場(chǎng)景業(yè)務(wù)推演，查漏補(bǔ)缺

補(bǔ)充完整邏輯后，要做業(yè)務(wù)功能的要點(diǎn)和場(chǎng)景總結(jié)：

1）銷(xiāo)售基于訂單明細(xì)申請(qǐng)鎖庫(kù)，由庫(kù)管確認(rèn)；

2）庫(kù)管確認(rèn)后的鎖庫(kù)會(huì)參與出庫(kù)校驗(yàn)；

3）出庫(kù)校驗(yàn)時(shí)算法為：庫(kù)存-鎖庫(kù)總量+當(dāng)前出庫(kù)明細(xì)對(duì)應(yīng)的鎖庫(kù)明細(xì)量。即：出庫(kù)自動(dòng)解鎖當(dāng)前鎖庫(kù)，所以校驗(yàn)鎖庫(kù)數(shù)量時(shí)，需去除當(dāng)前鎖庫(kù)量；

4）鎖庫(kù)超期自動(dòng)解鎖（顆粒度：X天）。

五、異常情況復(fù)盤(pán)，查漏補(bǔ)缺

上述主體結(jié)構(gòu)已經(jīng)比較完善，仍然需要根據(jù)所有步驟相關(guān)的數(shù)據(jù)表找異常數(shù)據(jù)情況做一遍復(fù)盤(pán)：

1）如果當(dāng)前庫(kù)存不夠，是否允許鎖庫(kù)？

其業(yè)務(wù)邏輯是：雖然庫(kù)里沒(méi)有，但我需要提前鎖定，因?yàn)檫@個(gè)客戶(hù)重要。

2）如果當(dāng)前庫(kù)存不夠全部鎖庫(kù)，且當(dāng)前出庫(kù)有鎖庫(kù)，是否允許當(dāng)前出庫(kù)？

其業(yè)務(wù)邏輯是：庫(kù)存不夠全部鎖庫(kù)，但是夠我這單鎖庫(kù)的數(shù)量，是否讓我出？

不難看出，上述問(wèn)題均為數(shù)據(jù)異常時(shí)（這里的異常，指的是不滿(mǎn)足業(yè)務(wù)必要條件）出現(xiàn)的；所以我們?cè)诜治鲂枨髸r(shí)，特別要注意，不能只考慮正常邏輯，異常邏輯的處理、容錯(cuò)非常重要，這決定了軟件的魯棒性。

分析：

1）庫(kù)存不夠，提前鎖庫(kù)。——業(yè)務(wù)角度合理，應(yīng)支持實(shí)現(xiàn)。

2）庫(kù)存不夠全部鎖庫(kù)，但是夠當(dāng)前出庫(kù)的鎖庫(kù)，是否允許發(fā)？這背后是一個(gè)鎖庫(kù)優(yōu)先級(jí)的問(wèn)題：

這里的優(yōu)先級(jí)應(yīng)該由人來(lái)判斷，需增加當(dāng)前產(chǎn)品鎖庫(kù)相關(guān)明細(xì)的查看，而不是做嚴(yán)格邏輯約束，以應(yīng)對(duì)各種可能性。因?yàn)殒i庫(kù)本身就就是一個(gè)出庫(kù)的高優(yōu)先，如果再增加內(nèi)部?jī)?yōu)先排序，反而會(huì)增加系統(tǒng)使用的復(fù)雜度，意義不太大。

至此，鎖庫(kù)的需求分析和基礎(chǔ)解決方案確定。中間省略了大量的展開(kāi)細(xì)節(jié)文檔，是為了更容易展現(xiàn)這個(gè)過(guò)程的結(jié)構(gòu)。在實(shí)際工作中，展開(kāi)細(xì)節(jié)文檔很重要，不能用一個(gè)粗線(xiàn)條的方案來(lái)確定整體可行性。把80%的精力放在20%的關(guān)鍵事情上，底層邏輯一旦打通，再由程序員把需求轉(zhuǎn)化為代碼，可大大減少不必要的試錯(cuò)！

本文由 @超兔 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自 pexels，基于 CC0 協(xié)議。