編輯導語：產品業務文檔應該如何整理才能讓產品新人快速上手、讓文檔分類清晰從而能夠輕鬆地繼續查詢、讓研發新人了解過去的邏輯，保證迭代的質量呢？本文作者為我們總結了三個步驟，幫助我們有效避免重複造輪子，提升文檔撰寫效率和價值。
在創業公司中，當產品由v1.0版本逐漸穩步迭代至2.0、3.0甚至更高版本時，後續的迭代肯定不再是百分百在創造新的東西，而是在原有的基礎業務和數據架構上進行延伸和再創新。
那麼在這種背景下，我們就很容易遇到下述3種問題：
問題一：產品新人上手難
剛入職的產品新人對系統的架構和業務邏輯不熟悉，這時往往需要產品leader花大量的時間去解答其提出的各類問題；同時，新人也難以在零散的問答中快速把握整個系統全貌，很難快速開展新工作。
問題二：文檔分布零散、難以統一查詢
當原來專門負責某模塊的同事離職後，產品小黑被派至接替他的迭代。但是此前該同事在很多版本都零散地迭代優化過這一模塊的功能，文檔十分分散，難以進行統一的查詢和追溯。
這就導致了小黑需要東一塊西一塊地自行拼湊文檔來了解這部分的邏輯，很大程度上耽誤了該模塊的迭代進度。
問題三：研發新人不熟悉老邏輯，影響迭代質量
新來的前端小綠在入職後的第一份迭代文檔中，發現產品文檔裡很多處都只寫了個「遵循原邏輯」，而小綠對原來的老邏輯幾乎完全不清楚。
但是他又想著這一塊可能不需要做改動，在新版本中就直接忽略掉了這一部分，僅關注了列出需要改動的前端邏輯，結果導致最終代碼質量不佳，從而影響了迭代質量。
從上述3個場景來看，當團隊出現了人員變動（流失or擴張）時，我們就需要儘快對產品業務文檔進行歸檔整理，以幫助新人快速上手並保證後續的迭代質量。
解決了為什麼要做產品業務文檔整理歸檔的問題，下面我們就步入正題：產品業務文檔應該如何整理歸檔？
首先，我們要明確做這件事的核心思路：即把歸檔整理後的產出——「產品業務文檔知識庫」當作一個產品來看。
核心用戶：產品和研發新人。
核心需求：
針對上述需求，我們可以按照下面3個步驟去逐一實現：
為了幫助新人快速掌握系統全貌，我們需要給出一個經過產研團隊共同確認過後的業務架構圖，幫助他們從系統地角度去看待產品，更清晰地了解產品各個模塊的劃分、價值以及模塊之間的交互關係。
與此同時，根據業務架構圖，我們也能更容易就接下來按模塊對文檔進行分類達成共識。
下圖為一個脫敏之後的業務架構圖，僅供大家參考：
此前，我們都是以迭代版本號為主，對迭代文檔按時間順序進行了縱向歸檔，但這樣卻不便於按模塊進行橫向查詢。因此在第一步完成業務架構圖梳理之後，我們需要把已有的迭代文檔按模塊進行統一匯總。
下圖為筆者的迭代文檔歸類表格，僅供參考：
當我們按模塊整理完迭代文檔之後，短期內能夠方便產研新人按模塊對業務邏輯進行熟悉。
但我們仍舊面臨著一個不可避免的問題：每一個迭代都較為零散，只是將文檔簡單匯總在一起，還是難以快速為業務有一個全局的掌握。為了解決這個問題，因此我們要完成接下來的第三步：模塊核心邏輯撰寫。
在資源和時間有限的前提下，我們需要為核心模塊邏輯的撰寫劃分優先級，以快速打造一個mvp知識庫給到產研新人，這裡也同樣遵循了二八原則，用20%的時間完成80%價值的核心模塊邏輯撰寫，後續再逐步補全剩餘優先級略低的模塊文檔。
那麼優先級應該怎麼劃分呢？評估優先級的角度和方法有很多，但是無論按照何等標準進行劃分，我們都應該圍繞我們的用戶和產品目標來展開。
下面給出一種廣為認知的評估思路：按照緊急/重要四象限來對模塊優先級進行劃分。這個方法想必大家已經很熟悉了，此處不再贅述。
在確定好優先級之後，我們就需要開始著手完成核心模塊的邏輯撰寫工作了。
下面給出筆者的撰寫框架，供大家參考：
1）版本記錄
從使用場景可以判斷得出，此處的文檔肯定後續會經歷持續的完善和優化，因此我們需要在每一篇核心模塊邏輯文檔的第一部分就加入該文檔的版本記錄。
文檔版本記錄需要包含文檔版本號、修改記錄、修改人及修改時間。
2）文檔正文
接下來就步入文檔的正文撰寫階段，此處給出筆者的正文撰寫結構供大家參考，共包含4部分：需求場景、數據字典、業務邏輯和相關迭代文檔連結。
其中，需求場景、數據字典和相關迭代文檔連結都是建議儘可能完善的部分，而業務邏輯則可以按需優先梳理出核心邏輯，剩餘細節可以及時告知讀者在具體的迭代文檔中查看。
這樣，能夠有效避免重複造輪子，提升文檔撰寫效率和價值。
在完成上述3步之後，我們就上線了產品v1.0版本，交付給了產研新人第一版的產品業務文檔知識庫。
當然，遵循pdca原則，我們需要通過監測和反饋收集，對該知識庫進行持續的優化，以保證知識庫的效能最大化，而不是最終淪為一座沉睡的地下圖書館。
作者：冰冰醬；公眾號：setmefree
本文由 @冰冰醬 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。