對于長篇文檔的評審，其實結果是很滑稽的，往往是通過稍作修改。很少有不通過的。而稍作修改就是隨便改改。最終文檔質量是沒有保障的。因此現在條目化文檔處理成為了新常態。比如需求是分條起草并評審的，通過就是通過。

? ? ??diabloneo：確實是這樣，我還沒遇到完全重寫文檔的情況

因此，有效評審長篇文檔的辦法就是把長篇文檔拆短。

需求被分解為小顆粒度的條目，請產品經理或者產品主管逐條確定，讓各方理解。user story，use case是最好的載體。把長篇大需求文檔的評審分解為多次小顆粒度的評審。更加有針對性，更準確，更高效

對有些條目，同意就通過，對有些條目如果不同意就不通過，同意的條目就往下流轉。不同意的條目就請原作者修改整改。

因此當今需求工程的發展，已經有明確的趨勢，就是拋棄長篇大文檔，改為短篇條目來處理。

建議政府工作報告采納在軟件業界得到了這些經驗。把報告分成一條一條的，讓人民代表們逐條來表決。更加體現人民代表大會是全國最高權力機關，真正的為人民的利益說話。

總結

以上是生活随笔為你收集整理的说说长篇文档的评审的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。