下面這篇文章是筆者以一家真實公司真實業(yè)務（關鍵內(nèi)容脫敏）為背景，介紹如何在產(chǎn)品規(guī)劃完成的情況下，快速出原型圖的相關內(nèi)容，大家一起往下看了解更多關于修訂記錄與全局說明的內(nèi)容吧！

這一系列文章我會以一家真實公司真實業(yè)務（關鍵內(nèi)容脫敏）為背景，介紹如何在產(chǎn)品規(guī)劃完成的情況下，快速出原型圖。之所以要用真實的公司和業(yè)務，是因為這樣才會有更多的細節(jié)可以給大家解釋，而不是泛泛的畫一些標準的操作流程。很多時候，產(chǎn)品設計的不好就是因為挖掘需求的時候沒有挖掘到關鍵細節(jié)導致流程斷點、功能缺失等從而導致用戶體驗差。

本文大綱

這次先向大家介紹一下產(chǎn)品原型模板中的修訂記錄與全局說明。它們在文檔中的位置：

• 修訂記錄：文檔的修訂歷史，方便以后備查文檔的各個版本更改了哪些內(nèi)容。
• 全局說明：整份文檔的整體說明，主要包含背景、術語定義、規(guī)范說明。

一、修訂記錄

1. 是什么

在發(fā)布產(chǎn)品文檔時，需要在修訂記錄中增加本次發(fā)布與之前發(fā)布內(nèi)容的關鍵差異點，以后備查、復盤會用到。

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

• 發(fā)布產(chǎn)品文檔時記錄：一般是每次公開、正式發(fā)布文檔時，需要添加一條修訂記錄，比如向產(chǎn)品組正式提交需求評審或需求評審有條件通過的更改稿。除此之外，日常工作中對文檔的修改、產(chǎn)品小組內(nèi)部討論后的調(diào)整等都可以不記錄，不然就太雜太細，失去焦點了。
• 記錄的是關鍵差異點，并不是所有的細枝末節(jié)都記錄在這里。關鍵差異點包括什么可以看下面的解釋。

2. 為什么

1. 記錄產(chǎn)品發(fā)布軌跡。一般這個信息會在周期性復盤（如季度、半年）時收集使用，發(fā)布產(chǎn)品的軌跡是如何支撐業(yè)務發(fā)展的，這個優(yōu)先級安排有沒有問題等。
2. 備忘備查。這次發(fā)布如果涉及到對之前已發(fā)布的關鍵要素內(nèi)容的調(diào)整，需要添加說明，這是為了避免扯皮。比如線上系統(tǒng)出現(xiàn)了功能沖突，我們就需要查產(chǎn)品原型文檔，發(fā)現(xiàn)V2.0對V1.3的部分要素做了調(diào)整，但是研發(fā)沒有完全落實，測試也沒測試到。

修訂記錄在文檔中一般長這樣：

• 版本號：這里記錄的是文檔的修訂版本號，而不是產(chǎn)品的版本號。在一個產(chǎn)品版本中，產(chǎn)品原型文檔可能會發(fā)布好幾次，比如需求評審提交多次修改多次。版本號的編碼規(guī)則不同公司不一樣，按公司的產(chǎn)品版本規(guī)劃（迭代計劃）來定義就行。這是更高一層的產(chǎn)品規(guī)劃方面要考慮的問題，跟產(chǎn)品原型文檔沒太大關系。
• 日期：一般是指發(fā)布的日期。
• 修訂人：對這次發(fā)布負責的人?？赡苁悄?，也可能是你的領導（比如你只為這份文檔貢獻了一個小模塊）。
• 修訂內(nèi)容：本次發(fā)布與之前已發(fā)布內(nèi)容的關鍵差異點。主要包含這四個要素：①業(yè)務背景（要解決的問題），②業(yè)務流程，③業(yè)務對象（關鍵數(shù)據(jù)與操作），④UI與UE。從①到④重要性依次遞減，影響的范圍依次遞減。至于為什么是這四個關鍵要素，等到畫頁面原型時再展開說明吧。
• 備注：其他說明信息，比如①本次發(fā)布由多人配合，除了修訂人之外，還有誰參與，貢獻了哪些模塊，②這次發(fā)布對應的是產(chǎn)品迭代的哪個版本號或迭代計劃等。

二、全局說明

1. 是什么

主要包含：業(yè)務背景、上層的應用規(guī)劃、本文檔對應產(chǎn)品的產(chǎn)品規(guī)劃、整份文檔都會用到的術語、整份文檔都需要遵循的規(guī)范等。

2. 為什么

因為這些信息對整份文檔的所有內(nèi)容都有影響或約束。舉例子來說：

業(yè)務背景、規(guī)劃等，是這份文檔的上層文檔，約束了這份文檔的范圍。沒有業(yè)務背景，就沒有要解決的業(yè)務問題。沒有應用規(guī)劃、產(chǎn)品規(guī)劃，就缺失了解決問題的方案的頂層規(guī)劃。這些都是本文檔（OMS系統(tǒng)原型）的上層約束信息。具體可以看看下面我畫的草圖。

術語：主要包含業(yè)務語言中的術語，以及產(chǎn)品技術語言中的術語。你在跟業(yè)務方溝通時，經(jīng)常用的一些名詞、動詞可能就是業(yè)務語言。大家有空可以了解技術領域的DDD的思想，這個我以后在業(yè)務建模相關內(nèi)容時會展開介紹。技術語言就是你和其他產(chǎn)品、技術團隊溝通時用到的名詞、動詞。一般來說，業(yè)務語言和技術語言要盡可能一致，避免理解差異，這樣業(yè)務和技術團隊的溝通成本才比較低。

舉幾個例子吧：

業(yè)務術語：業(yè)務方口中的訂單、渠道、商品分別指代什么？訂單是客戶原始訂單，還是OMS中的標準訂單？渠道是分銷渠道，還是商城店鋪？商品是SPU、SKU還是ERP中的物料等等。

技術術語：虛擬庫存、實物庫存是什么？物料是什么？訂單頭、物料行、配送行等是什么？。

規(guī)范：對文檔中的樣式、描述方法等作出統(tǒng)一規(guī)范。比如文檔的框架、流程圖畫法的規(guī)范、頁面原型的框架等，文檔中重復做的事情盡量形成統(tǒng)一的規(guī)范。比如文檔中有大量的頁面（列表頁、詳情頁等），那就制定一個頁面原型框架；比如有非常多的操作流程，那就制定一個流程圖規(guī)范；比如每個頁面都會有功能的解釋說明，那就制定一個功能解釋的規(guī)范等。跟你配合過幾次的技術同事熟悉這套規(guī)范后，以后看文檔就很舒心，可以很輕松的定位和查找。最好一個產(chǎn)品團隊使用一套規(guī)范。

下面對全局說明的關鍵信息展開講一下。

3. 業(yè)務背景

1） 業(yè)務背景介紹

主要介紹本文檔設計的系統(tǒng)，用來支撐的業(yè)務線的情況，發(fā)現(xiàn)的問題，系統(tǒng)建設的價值預期是什么。這是所有產(chǎn)品規(guī)劃、業(yè)務流程、產(chǎn)品功能設計的起點。

一般來說，在某個系統(tǒng)的原型圖這種最底層的文檔中，會直接引用上層的文檔（如產(chǎn)品規(guī)劃文檔、應用架構規(guī)劃文檔等），而不會直接對業(yè)務背景做詳細闡述?？梢钥匆幌挛蚁旅娈嫷牟輬D，了解不同層次的輸出物的關系。

底層文檔引用上層文檔的好處是：

1. 不會重復。業(yè)務線的情況，業(yè)務最痛的問題，解決方案和價值，問題解決的優(yōu)先級等是分層級逐步分析拆解出來的，在不同的層級會形成不同的輸出物。上層輸出物相對更宏觀、整體，下層輸出物相對更微觀、具體、局部，因此在下層輸出物中一般不會重復的把上層輸出物再闡述一遍。
2. 信息一致。因為下層輸出物引用上層輸出物，所以當上層輸出物中的部分結論產(chǎn)生變更，只需要變更上層輸出物即可。如果同一個結論在不同輸出物中都重新寫了一遍，那更新不完整時會導致信息不一致，進而導致執(zhí)行出現(xiàn)偏差。這類問題在公司流程、制度等文件中廣泛存在。
3. 聚焦。下層輸出物要聚焦到某一個具體問題的解決上，因此在這一層不要過多關注整體，只需要知道我解決的問題在整體中的位置、在整體方案中的價值就可以了。

關于如何從業(yè)務出發(fā)，逐層分析拆解出某個系統(tǒng)的解決方案，版本迭代計劃，是另一個話題，在這里不展開。我畫了一個草圖，大致邏輯如下：

本次系列文章，對標的就是第五、第六層級的原型設計文檔。

上面的邏輯是企業(yè)架構（EA）設計的邏輯，大家感興趣可以去了解一下TOGAF。對比了解過的同學，可以發(fā)現(xiàn)草圖里缺少了技術架構。原因是①技術架構太專業(yè)了，我沒有能力闡述完整。②技術架構一般由技術架構師、技術組長等角色提供，產(chǎn)品經(jīng)理一般不參與技術架構設計。

2）應用規(guī)劃

對標上面的草圖，應用規(guī)劃屬于第三層，要描述整個業(yè)務線或整個企業(yè)的完整的數(shù)據(jù)架構與應用架構。

數(shù)據(jù)架構對企業(yè)非常重要，但是另一個專業(yè)話題，在這里我不展開了。

應用架構就是完整的IT系統(tǒng)規(guī)劃，除了各位比較熟悉的應用層系統(tǒng)（如OMS、SRM、OA、ERP等），還包括了底層的平臺系統(tǒng)（如用戶系統(tǒng)（含統(tǒng)一鑒權）、網(wǎng)關系統(tǒng)、門戶系統(tǒng)、BI系統(tǒng)等）、底層技術系統(tǒng)（如租戶系統(tǒng)、PaaS等）。

應用規(guī)劃要回答的問題是，如何通過一系列的IT系統(tǒng)來支撐業(yè)務發(fā)展，解決業(yè)務問題。

3）產(chǎn)品規(guī)劃

對標上面的草圖，產(chǎn)品規(guī)劃屬于第四層，描述單個系統(tǒng)的整體規(guī)劃，包括系統(tǒng)支撐的業(yè)務描述、系統(tǒng)關鍵用例、系統(tǒng)關鍵業(yè)務對象模型、關鍵業(yè)務流程等。

產(chǎn)品規(guī)劃要回答的問題是，這個IT系統(tǒng)要解決什么業(yè)務問題，如何解決。

4）業(yè)務背景的模板示例

有的同學可能會問，系統(tǒng)價值怎么能精確到數(shù)值的？這主要看調(diào)研的深度和業(yè)務方的重視程度，如果業(yè)務方對這個問題非常痛，我們調(diào)研的深度能足夠深入，那每個具體問題解決后預估的人效提升是能估算出來的，就能轉換成業(yè)務的具體數(shù)值。

比如自動對賬與結算功能，解決的問題主要是：①出我方賬單，②與客戶賬單自動比對并輸出差異報告，③快速調(diào)賬，④出結算單，⑤推送開票與應收。

• 出賬單：原來是人工導出明細表格篩選，每個賬期的賬單要20分鐘。出賬單功能只需要1分鐘。同時減少了人工篩選出錯的問題。
• 自動對賬：原來是人工用表格對賬（各種Vlookup），每次對比要1~2小時（因為要比對的參數(shù)很多，比如訂單號、產(chǎn)品名稱、單價、數(shù)量、總金額、時間、活動促銷等）。自動對賬功能只需要1分鐘，同時減少人工比對出錯的問題。
• 人工調(diào)賬：表格調(diào)賬比較復雜，涉及到要不停地與對方溝通，修正錯誤，一般需要1~2天。人工調(diào)整功能基于自動對賬的差異結果，耗時的是確認差異處理方式（如挪到下一賬期、取消本條明細對賬等），一般需要半天。
• 自動結算：人工創(chuàng)建結算單、發(fā)起開票流程一般需要0.5~1小時。自動結算功能會根據(jù)調(diào)賬后的結果（一般是要經(jīng)過雙方確認審批的），生成結算單，并根據(jù)結算單一鍵發(fā)起開票請求，推送財務系統(tǒng)的應收暫估等，一般幾分鐘。

整體評估下來，對賬功能整體提效80%以上。業(yè)務方領導可以根據(jù)這些方案描述，預估出是不是可以減少編制、減少出錯而避免的經(jīng)濟損失等。減少編制不意味著裁員哈，只意味著這個崗位不需要那么多人了，多出來的人天可以調(diào)崗到別的崗位，或做別的工作。

4. 全局術語

我這里給出示例，大家要根據(jù)自己公司的具體情況整理提煉。

5. 全局規(guī)范

我給出幾個示例供大家參考。

1）流程圖規(guī)范

2）系統(tǒng)首頁規(guī)范（截?。?/strong>