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