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

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

本文大綱

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

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

一、修訂記錄

1. 是什么

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

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

2. 為什么

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

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

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

二、全局說明

1. 是什么

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

2. 為什么

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

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

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

舉幾個例子吧：

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

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

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

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

3. 業務背景

1） 業務背景介紹

主要介紹本文檔設計的系統，用來支撐的業務線的情況，發現的問題，系統建設的價值預期是什么。這是所有產品規劃、業務流程、產品功能設計的起點。

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

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

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

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

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

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

2）應用規劃

對標上面的草圖，應用規劃屬于第三層，要描述整個業務線或整個企業的完整的數據架構與應用架構。

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

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

應用規劃要回答的問題是，如何通過一系列的IT系統來支撐業務發展，解決業務問題。

3）產品規劃

對標上面的草圖，產品規劃屬于第四層，描述單個系統的整體規劃，包括系統支撐的業務描述、系統關鍵用例、系統關鍵業務對象模型、關鍵業務流程等。

產品規劃要回答的問題是，這個IT系統要解決什么業務問題，如何解決。

4）業務背景的模板示例

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

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

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

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

4. 全局術語

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

5. 全局規范

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

1）流程圖規范

2）系統首頁規范（截?。?/strong>