在日常工作中，文檔是每個人都會用到的工具，它作為功能從抽象到具象的承載者。在一個項目完整的生態(tài)系統(tǒng)中，有著無法替代的重要作用。既幫助我們將確定好的實施辦法和預估效果文字化留存，也便于我們在日后需要時追根溯源
而凡事都是利弊共存的，在項目過程中，會產(chǎn)生大量的冗余文檔。就像撰寫有的文檔會耗費大量時間、資源，但實現(xiàn)的價值卻遠低于成本。而有的文檔可以梳理清楚我們所要完成的工作內(nèi)容，起到功能設計說明書的作用。我們該如何選擇必要的文檔？又該如何對過往文檔統(tǒng)一管理呢？
文檔管理是項目環(huán)節(jié)中所用到的一種管理方法，通常在項目開展前，需明確必要的文檔類型。盡量避免撰寫高成本、低價值的文檔，并對所有文檔進行統(tǒng)一管理。它的核心原則為：
設計思維文字化，追根溯源便捷化
為了梳理清楚文檔管理的整體思維框架，便于宏觀對其進行了解，于是匯總了相關的知識脈絡，如下圖所示：
前言
在項目開展前，我們要了解一些常規(guī)文檔分類，以及映射到我們所要開展的項目中，哪些需要通過當面交流、郵件、即時通訊等形式去傳達，而哪些情況下需要借助文檔的形式？
作為產(chǎn)品經(jīng)理的拿手武器——PRD需求文檔，它的地位是毋庸置疑的。不管公司規(guī)模如何、項目流程如何，需求文檔都會是伴隨產(chǎn)品功能落地的說明書
1.常規(guī)文檔分類
面對日?，嵥榈捻椖抗ぷ鳎覀儠ㄙM太多時間去處理各式各樣的文檔。雖然這些文檔紛雜且冗余，但所蘊含的價值也是極高的
一般而言，會有4種類型的內(nèi)容要以文檔的形式匯總，它們分別是：
BRD/MRD/PRD
立項會議文檔
會議共識
視覺稿
1、BRD/MRD/PRD
對于產(chǎn)品經(jīng)理而言，這三個文檔實在是再熟悉不過的了。事實上，大多數(shù)產(chǎn)品同學不怎么接觸市場相關的分析工作，也就很少涉及到MRD的撰寫。而BRD作為商業(yè)需求文檔，更多時候是在項目開展初期時定方向所需要。相對來說，PRD絕對是所有產(chǎn)品同學都要撰寫的核心文檔
MRD相關的內(nèi)容我?guī)缀鯖]有涉及過，所以就不誤人子弟了
而有關BRD的內(nèi)容，其實主要看公司的要求，需要因地制宜進行側(cè)重。有的可能會把BRD專門拿出來作為一個文檔呈現(xiàn)，更多的則是會和立項會議的文檔內(nèi)容相結(jié)合
立項會議不外乎以下內(nèi)容：項目背景、產(chǎn)品規(guī)劃、商業(yè)價值、功能需求/非功能需求
而BRD同樣是由以下幾部分內(nèi)容：項目背景、商業(yè)價值、功能需求、非功能需求、資源評估、風險與對策
大體上可以劃分為同一文檔，我們要盡量保證不出現(xiàn)內(nèi)容相似的文檔
有關PRD的內(nèi)容參見下面的介紹，由于內(nèi)容較多且對于產(chǎn)品來說更為重要，故通過一章的內(nèi)容詳細說明
2、立項會議文檔
這部分內(nèi)容可以移步《項目流程管理 —— 因地制宜隨機應變》《項目團隊管理 —— 組建團隊凝聚力量》，在上述文章里會有細致講解
3、會議共識
每次項目會議的結(jié)束，標志著我們又達成了一些功能設計的共識。而我們需要對每個項目開了多少會議、每次會議達成什么共識有個記錄。在這之后，最好在一個文檔里對本次項目的所有會議記錄統(tǒng)一整理
首先，便于我們堅決遵守已形成文字的決議，鐵證如山無法狡辯。其次，在項目結(jié)束后，我們可以根據(jù)本次項目的所有會議內(nèi)容，從而復盤開展情況，為以后項目的推進以及會議的召開總結(jié)經(jīng)驗
4、視覺稿
我有個習慣，每次UI同學為功能設計的視覺稿我都會自己留存一份。一是可以在開發(fā)完成后和原始設計的UI圖進行對比，看實際情況和實現(xiàn)效果
二是為了在之后功能迭代的時候，方便開發(fā)同學明確是哪張設計圖的哪個部分需要變動。毋庸置疑的是，PRD中的原型圖遠不如UI視覺稿來的更為清楚
2.PRD需求文檔
需求文檔，顧名思義就是講清楚功能需求的文檔。我們要理解用戶所提出的訴求，并轉(zhuǎn)化為產(chǎn)品功能上的支持，最終落實為開發(fā)的說明
PRD在工作中就像士兵的武器一樣，是我們打好迭代戰(zhàn)爭的關鍵。其重要程度不言而喻，下面我們來著重講講有關內(nèi)容
1、形式
（1）Axure標注
相對而言，在創(chuàng)業(yè)型公司里，敏捷迭代的思維會完全融入公司的基因。所以更多時候，都是直接通過Axure畫原型圖并附上信息標注的形式
這樣可以根據(jù)每頁的圖和文字，清楚了解每個需求點的內(nèi)容，相對直觀的展示給開發(fā)同學。而且Axure自帶上傳分享功能，便于以網(wǎng)址的形式給團隊成員間預覽
但是用Axure標注的形式較難統(tǒng)一管理文檔，且不易保存。原型圖相較UI圖還是差距很大，鑒于開發(fā)是以UI圖為準，所以在原型圖上標注需求內(nèi)容，會誤導開發(fā)同學從而影響進程
（2）word文檔
在一些發(fā)展型公司，或者針對一些非敏捷開發(fā)的項目，需要對各種文檔管理時，word文檔的形式更適合作為需求文檔的載體
相較Axure，它的形式更為流行，格式布局上更為統(tǒng)一。在word上會對迭代概況、目標用戶、功能邏輯等進行說明。同時，在功能需求部分會把UI圖附上，并在下面對每個用例進行細致要求
（3）多人協(xié)作工具
當項目團隊人數(shù)較多，或者一個產(chǎn)品對應多條業(yè)務線時，word文檔的形式也變得愛莫能助了。這時，多人協(xié)作工具的誕生就很好的解決了該困擾
以我為例，我最先接觸的是語雀平臺，不得不說，很大程度上提升了工作效率。在語雀平臺上，團隊成員會實時同步更新文檔信息，并把修改后的內(nèi)容用紅色的字體標注出來。還可以根據(jù)項目需要，在平臺上設置項目分組，以及人員的查看權(quán)限
通常情況下，我們會把視覺稿、需求文檔放進一個項目分組里，并把每個項目都標注清楚版本記錄、平臺整體背景、功能介紹等信息
2、內(nèi)容
一般來說，常見的PRD需求文檔的內(nèi)容分為以下兩部分：
整體說明（版本記錄、目標用戶、產(chǎn)品介紹、功能框架、業(yè)務邏輯）
需求說明（以頁面作為單位，對每個頁面所要實現(xiàn)的功能進行說明并配上UI圖）
網(wǎng)上最全的也是公認度最高的就屬蘇杰大大的PRD范本了，具體內(nèi)容見下圖：
PRD本身就是作為一個工具的意義存在，只要能幫助你更好的完成項目工作即可。形式和內(nèi)容只是方法，而非我們需是追求的目的
小結(jié)
本文針對項目文檔管理的知識點及方法內(nèi)容進行了匯總，良好的管理方法可以讓所有文檔井然有序，同時便于我們在之后需要時追溯源頭
梳理清楚了流程、模型、團隊以及文檔管理的方法后，可以極大程度的提高項目管理的水平，并更加高效的推進項目開展，幫助我們在項目迭代中攻克難關
