前言
很多技術同學在日常的工作中接觸到的大多是TO C的業務或者對外業務，由於大多數企業的主要營收是來自外部用戶，
因此內部的一些項目不會有太規范的流程和太高的要求標准。什么高可用高性能都是扯淡，良好的用戶體驗根本不存在。
但如果是一些內部的技術項目，特別是一些基礎技術設施的技術項目，反而對技術要求是比較高的。
我目前在基礎架構團隊負責內部技術項目的一些工作，包括產品設計、交互邏輯、撰寫PRD、項目管理以及測試工作。
這篇文章，想和大家聊聊，技術項目中一個良好的文檔結構如何設計。
思維導圖
一般來說技術項目可以分為四大階段，本篇文章我會從四個階段分別來介紹，在不同階段需要設計哪些項目文檔。
項目管理
無論是TO C的外部業務需求迭代還是內部的技術項目，項目管理是必不可少的事情。這里我想介紹下面三點我個人認為在項目管理中比較重要的點。
流程規范
流程規范相關的話題，我在之前的文章《測試工程師的職場發展二三談》中做了很長篇幅的描述，這里再次重溫下。
問：流程是什么？為什么要有流程？流程能解決什么問題？流程能帶來什么保障？
流程是什么？
流程是保障團隊目標達成的最佳實踐，因人/團隊/業務類型/迭代速度/資源緊張程度而異。
為什么要有流程？
沒有流程會導致團隊中的個體各自為戰，目標不統一，進度不協調，資源配給失衡而導致交付質量下降。
流程能解決什么問題？
流程能保障團隊或者群體在大方向上保持協調一致，盡可能降低由於團隊人員能力、認知水平、資源不足、意外情況導致的項目延期或者質量下降。
流程能帶來什么保障？
想象一個場景：產品三天兩頭改需求，接還是不接？不接的話，產品說需求很緊急，會影響運營指標、GMV、DAU......等等很多理由，技術不配合，怎么辦？
雖然說職場是個講規則講道理的地方，但實際上從業務和產品團隊的實際操作來看，當他需要和你講道理時候，道理才成立。如果她不想講道理，技術絕大多數時候就是故障定責時候背鍋的。
這個時候，流程的作用是什么？流程可以保障你可以有底氣的據理力爭，雖然不一定能扭轉局勢，但在一定層面上，會哭的孩子有奶吃，偶爾學會受委屈給領導看，也是以退為進保障自己利益不受太多損失的技巧。
流程規范的價值：風險可識別+問題可追蹤+結果可驗證+數據可量化！
上面引用了之前對流程規范的一些描述，在具體的項目管理中，常見的流程規范有如下幾種：
- 需求評審流程
- 方案評審流程
- 功能提測流程
- 發布變更流程
- 信息同步流程
- 項目復盤流程
迭代記錄
目前在我負責的項目中，采用的是敏捷迭代機制，每周都會交付一個版本，可以是新功能上線，也可以是功能優化。
敏捷迭代模型的核心是快速交付可用的質量有一定保障的產品，讓用戶給到反饋和建議，不斷迭代，不斷滿足用戶新的需求，直到最終交付一個比較成熟的技術產品。
這種模型比較適用於內部或者需求不明確的項目；如果是需求明確對質量有高要求的，反而不適合這種迭代交付模式。
而迭代記錄，是將每次迭代的內容，通過小的內部版本號進行記錄。它的作用有兩點：
- 記錄每次交付內容，向上有交代，對外有信心（即領導知道你在做什么，用戶知道你再不斷滿足他們的需求）；
- 定期復盤的素材，通過定期復盤迭代交付過程的內容，找到做的不好的點，避免在后續迭代中犯錯踩坑；
會議記錄
一般這種內部技術項目，流於形式的務虛內容可以盡量減少，但下面兩點我個人覺得是很有必要保留和執行到位的。
進度追蹤：內部宣講形成習慣，每天更新今天的進度，遇到的問題風險，評估是否需要調整優先級和迭代計划；
周報匯總：雖然說寫周報我個人覺得是個很智障的事情，但這也是一種管理手段。
我們不能祈求所有人都具備良好的職業素養和較高的自覺性，只能通過一些流程規范去盡可能降低和避免帶來的問題。而且，周報也是向上管理的重要方式！
四大階段
啟動階段
項目概述：即為什么做這個項目？背景是什么？要解決什么問題？面臨哪些風險？項目的價值是什么？
項目規划：長期規划是什么？分幾個階段實現？每階段重要產出物和里程碑是什么？如何量化評估每個階段的交付物？
設計階段
原型圖：即這個技術項目的web頁面或者后台管理頁面，交互邏輯等。
需求調研：一般內部的技術項目，需求大多來自內部其他部門或團隊。在設計階段盡可能多的進行需求訪談是很重要的一件事。多去聽用戶的痛點是什么，他們想要什么，然后將用戶需求轉化為產品需求。
PRD文檔：PRD是需求的最終產出物，有了PRD才能開展后續的如需求評審、架構設計等工作。
研發階段
研發階段實際上要做的事情是很多的，下面列舉幾項比較重要的需要產出的文檔。
架構設計：架構設計即項目的技術實現方案，包括功能架構圖、系統技術架構圖、環境配置、各項參數等重要信息說明。
接口文檔：接口的作用是約定數據的交互邏輯和出入口，也是功能聯調和測試階段需要重點關注的對象。
測試用例：沒有一個產品是不需要測試驗證的，測試用例的最大作用是驗證產品實現是否是按照預期設計來實現的。
BUG列表：記錄問題的本質，是梳理和復盤產品不足之處，並快速加以改正。
交付階段
交付階段即項目的線上發布，我個人認為下面2個文檔是很有必要的。
使用手冊：見文知意，使用手冊的最大作用是幫助用戶可以快速熟悉並使用起來。當然還有一個作用，避免用戶沒得看而導致不斷詢問你各種問題，你可以甩給他使用手冊，培養他學習使用的能力，降低自己的對線壓力。
接入文檔：因為是內部的技術項目，部分功能需要業務或者用戶接入或者做一些配置上的變更。接入文檔作用是賦能用戶去做變更，而不是項目的技術同學去幫他們做變更，這也是節省資源的一種方式。
附：相關工具
項目wiki：飛書文檔
原型圖設計：墨刀
架構圖設計：ProcessOn
接口管理工具：Swagger
這篇文章主要內容是介紹技術項目中比較重要的文檔結構，以及對部分文檔的作用做一個簡單的說明，僅供參考。
后續我會和大家聊聊，技術項目落地交付以及交付質量的一些事情，敬請期待。