“代碼越少，錯誤就越少，”Ruby的發明者Matz說。文檔越短，包含的錯誤越少，越容易閱讀，越容易更新，越有可能帶來簡潔的設計。簡而言之，縮短時間有太多的好處。對於產品團隊來說，簡短的文檔更容易編寫，因此這一原則不是負擔。
在剛入行做產品時，我發現一個非常奇怪的現象：在我們開完需求會議把產品大概的需求告訴研發設計人員後，他們在實際功能代碼開發過程中很少去看需求文檔。通常是遇到問題口頭詢問。我當時就很奇怪，產品需求文檔裡每一個步驟和功能點都寫得很細，為什麼他們從來都不喜歡讀我寫的文檔？
於是我帶著疑問和研發溝通，得到的答案是：他們沒時間看我寫的過於冗長的文檔。他們只需要簡單地理解這個功能大概是做什麼的，怎麼去實現它即可。
文檔中的內容又多又複雜，要把文檔完全理解非常費時，一些不影響開發的字段完全可以放在備註中。從這件事之後，我開始反思研究自己平時寫文檔的問題。以前總擔心研發的程序員們看不懂，習慣性的會去把一個需求寫得非常細。複雜的一個功能可能寫到十幾行（一不留神就接近500多個字）。
在研發同事的角度來看，在較短的開發時間裡想用最快的速度去理解需求，長篇幅的文檔確實增加了他們理解上的門檻難度以及閱讀內容的速度。在梳理需求文檔時，保持文檔簡短，會增加整個文檔的易讀性。下面是我總結有關保障文檔簡短的3個步法。
1） 分析需求：開發中需要執行哪些操作。
2） 填寫主幹：畫出主要操作流程。
3） 添加枝葉：顯示詳細信息。減少文檔重量不僅可以提高可讀性，還可以增加靈活性。
因為在開發過程中，您會發現很難在最終開發的產品和原始的書面需求文檔之間保持完全的一致性。由於接口提供、技術等方面的問題，在開發過程中需求會或多或少地發生變化。通過簡短地編寫文檔，還可以幫助修改以後的需求變更。
閱讀更多 鄧鋤頭 的文章
