在軟體專案中，文件既是一項的重要成果，也是專案管 理的有力工具。通過文件，可以穩定、明確的傳達資訊，實現專案內的有效溝通。所以寫文件對專案經理來說，是一項必備的技能。
然而很多專案經理害怕寫文件，似乎這是一個很麻煩、 很困難的工作。其實會不會寫文件，只是一種外在的表現，通過一個人寫文件的情況，可以看出他對工作的理解程度，發現潛在的問題和風險。一個合格的專案經理，不但不會怕寫文件， 而且會覺得這是一件簡單、很自然的情，就像一個人吃飯、喝水一樣，何難之有？
1.編寫文件的常見問題
每個專案都要寫不少文件，比如專案實施計劃、系統需 求說明書、系統概要設計設計、系統詳細設計、測試計劃……在不少軟體專案中，大部分文件寫出來只是為了應付檢查或驗收，如果要對這些文件較真的話，就會發現它們存在著各種各樣的問題。
該 有的文件沒有
什麼叫該有的文件？我想有兩點含義：一是合同、招標 檔案規定必須提交的文件；二是專案本身確實需要的文件。如果僅僅是前者沒有，我一般不會怪專案經理，因為事後可以補上。但如果是第二種情況，那就不只是文件本身的問題了。試想 ，如果專案執行了一半，還沒有專案計劃，顯然就無法就事論事只談論計劃了，這反映了專案經理對整個專案的管理具有隨意性，盲目性；如果沒有設計文件就完成了大部分編碼工作，那 麼程式碼的質量就得打上一個大大的問號了。
專案需要的文件沒有，要麼是專案經理的疏忽，要麼是 寫不出來，這本身也是很危險的訊號。如果專案經理連必需的文件都可以疏忽，說明他的工作完全沒有系統性，那他對專案的管理工作怎麼值得信任呢？如果是寫不出來，這說明專案經理 沒有想好怎麼做，同樣也是一件很危險的事情。
丟 三落四，內容不完整
開啟文件一看，總是有一些你想看的內容找不到，或者 對關鍵的內容輕描淡寫，這多少會讓人覺得有點生氣。專案計劃沒有工作分解，設計文件沒有系統邏輯結構，專案週報沒有當前進度情況，試執行報告沒有系統執行的統計資料 ……出現這樣的狀態，說 明專案經理缺乏經驗，對專案沒有總體的認識，更加把握不了工作的重點。
照 搬模板，徒具形式，內容空洞
這種文件還真讓人有點無可奈何。乍一看，文件格式規 範、內容完整，似乎沒什麼問題，但心裡總覺得少了一些東西，看完了什麼也沒記住，彷彿沒看過一樣。簡單的說，就是沒有實質性內容，缺乏對問題的具體分析，同樣的內容，改一下名 字，可以給其它專案用。
這樣說專案經理可能會不服氣：我文件有幾百頁，怎麼 會沒內容呢？好吧，我們來清理一下，把模板自帶的內容去掉、把合同和招標檔案中Copy的內容去掉、把網上抄的內容去掉、把不相關的內容去掉、再把不重要內容去掉，再來看看究竟還剩下幾頁？這剩下的內容才是真 正有價值的東西。如果這一部分內容很少，你文件越長，就會越像懶婆娘的裹腳布，讓人生厭。
看這樣的文件，讓人覺得就像吃了蒼蠅一樣難受。有人 將這種文件稱之為“模板殭屍”，真是既準確、又解恨。這種文件徒具形式，沒有靈魂、沒有精神，就像一具只有骨架、沒有血肉的殭屍。
寫出或者接受這種文件的專案經理也很可怕。 他有經驗，但是沒想法；他知道流程，但不知道變化；他能把握形式，但把握不了內在；他明白要做什麼，卻永遠也理不清楚工作的內容；他寫的內 容很多，腦中卻幾乎一片空白。他們寫出來的文件像殭屍，做專案也像被殭屍附身一樣，只能沿著固定的路徑一蹦一跳的前進，哪怕前面有深淵，他也會直接跳下去，因 為他壓根就看不到！
2.怎樣寫好文件
我見過不少工作十年以上、管過專案五年以上的同事， 對於寫專案文件仍然是愁眉苦臉、痛苦不堪。難道寫文件真的有這麼難嗎？怎樣才能寫出合格的專案文件呢？
最核心的一點，寫你所想的
俗話說：“言為心聲”，寫作也是一種 “言”，同樣體現了作者的內心想法。寫專案文件，最重要的就是要寫自己的真實想法，展示自己的思路。如果說寫文件有什麼訣竅的話，這就是最重要的訣竅。從哲學上來說 ，這是知行合一的重要一環；從寫文件本身來說，只有這樣才寫得好、寫得快。所以如果有誰說自己不會寫文件，我們首先應該想到的不是什麼技巧問題，而是他真的想好了嗎？
體現了知行合一
“知行合一”也就是“想”和 “做”應當保持一致。知行合一最簡單的方法，就是想了就去做，由想直接到做。在軟體行業個人英雄主義年代，程式設計師有好的想法，然後實現它，就有可能成就一段傳奇，例 如UCDOS、WPS、RichWin、江民防毒等都是那個時代的產物。由想直接到做，這對於一個人完成的 簡單工作是可以的，但並不適合於由多人協作完成的複雜任務，因為團隊作戰還有一個關鍵環節——溝通。
溝通有口頭和書面兩種方式，也就是說和寫。想、說、 寫、做四者統一，才完整體現了專案中的知行合一。說你所想的，寫你所想的，否則就是言不由衷、表裡不一；然後做你所說的，做你所寫的，這叫說到做到、一諾千金。
圖 想說寫做的統一
由此可見，寫你所想的，是知行合一的重要體現。
寫所想的才能寫得好、 寫得快
為什麼有些人寫文件寫得很慢 、覺得很痛苦呢？最根本的原因就是因為他沒有想法，或者說沒想好，肚子裡沒貨自然拿不出來。比 如說，如果你不熟悉Java技術，讓你 來寫一個Java系統的設計文件，你自 然不知從哪裡下手，縱使你有莫言一樣的文采和想象力，也沒有辦法完成。
寫你所想的，其實只是把想法 謄到紙上而已，就像把杯子裡的水倒出來一樣。有思路的話，當然能寫得快、寫得好。如果沒有想法 ，千萬不要不懂裝懂，到網上到處複製一些看上去相關的內容來填補，因為這會誤導別人，雖然掩蓋了自己的無知，但也掩蓋專案隱藏的問題和風險。所以對於沒有想清楚的地方，最好的 處理方法就是直接寫上“沒想好”三個大字，等想好了再補上。記住：說假話的人最辛苦，因為他總是要琢磨該怎樣編故事，怎樣自圓其說。講真話的人最輕鬆，寫文件就是要 寫自己的真心話。
不要拘泥於形式
有些人說：“我有想法，就是寫不出來。” 這種情況多半是由於寫作者拘泥於文件的形式，不知該如何下筆。這樣的話，有一個簡單的方法：先把你的想法說出來，用手機把聲音給錄下來，然後對照錄音來整理文件。也就是說，我 們要像說話一樣寫文件，說話是很自然的事情，寫文件也是很自然的事情。如果你沒辦法說清楚，那估計神仙也法辦法了——除非有誰懂得讀心術。
文件最重要的是內容和思想，讓讀者能讀懂你的思路， 而不是構思有多精巧，語言有多優美。如果總是在琢磨先寫什麼，再寫什麼，用什麼詞，怎麼能快得了呢？
不拘泥於形式的另一含義是不要有過多形式化的內容。 有時一篇30頁的文件，專案背景、建 設目標、參考資料之類就佔掉15頁， 並且在每一篇中都千篇一律。這些東西不是完全沒用，但過多就會影響對文件重點的把握，儘可砍掉或簡化。
另外不要湊篇幅。專案文件是用來指導專案實施的，因 此把問題寫清楚就可以了，多寫無益。有些人寫文件時，喜歡問要寫多少頁，其實這根本不應該成為一個問題，如果把想說的都說清楚了，你管它有多少頁呢 ？
文 檔結構要具邏輯性
在第三章中，曾經提到PMBok專案管理理論遵循結構化的思想，即自頂向下、逐層分解。 這一規律同樣可以用來指導文件的編寫，專案文件在結構上同樣應該是“結構化”的，自頂向下、逐層分解，形成金字塔形的結構。
還記得在學校里老師教我們怎樣寫作文了嗎？要按 “總分”或“總分總”的結構來寫，這其實也是結構化方法的體現。結構化方法之所以放之四海而皆準，是因為它符合人對事物的認識規律。
設想我們要研讀一本書，一般我們首先會看書名、作者 ，再看目錄、前言或簡介，對全書全形成一個總體的印象，這是“總”的過程。然後我們會逐章逐節的閱讀，一步一步消化全書的內容，這是一個“分”的過程。部 分讀者在讀完以後，可能還會對全書的內容進行再次總結回顧，以進一步加深理解，這又是一個“總”的過程。通過這樣一個“總分總”的過程，我們形成了對事物 的深刻理解。
所以一本書按照金字塔結構來組織文件，其實就是為了 迎合讀者，降低他們理解的難度，讓他們只需要更少的時間就可以對整個文件的精要有一個完整準確的理解。作者寫得輕鬆、讀者讀得開心，真是皆大歡喜。
結構化方法不但適用於文件的整體結構，同樣適用於局 部結構，例如文件的某一節。只要事物具有一定的複雜度，我們都可以用這種方式將其講得更加透徹。
採用結構化方法來編寫文件還有一個好處，就是可以檢 驗思維的嚴謹性。結構化方法的一個重要工作就是對事物進行分解，而分解的過程其實是一個再次深入思考的過程，例如分解的標準是什麼，上層結構是否完整的包含了下層結構等，從而 發現被遺漏的問題，並進行完善。
注 意排版
文件排版是許多人容易忽視的問題。一份內容上乘的文 檔，如果用工整悅目的排版來展現，那就是錦上添花了，反之就有損文件作者的形象。這就好比一個人心靈美固然重要，但如果穿著邋遢，面目可憎，也不大可能會受到別人的歡迎。
排版並非難事，只需要投入很小工作量，就可以為文件 獲得一定的加分，這就是排版的價值。事實上，排版還是對讀者尊重的表現。作者多花一點點精力，就可以讓讀者擁有更好的閱讀心情，更快的閱讀速度，實在是一種設身處地為他人著想 的美德。