在執行專案的時候，資訊軟體從業人員最痛苦的事，莫過於寫文件。一個專案下來有許多的文件要寫，例如專案管理計畫、建構管理計畫、品質保證計畫、風險管理計畫、開發計畫、測試計畫、教育訓練計畫、交付安裝計畫、監控計畫......你想得到事的都可以寫個計畫出來，在產品發展及產品與服務描述上，例如：系統規格文件、軟體需求規格文件、介面規格書文件、軟體設計說明文件、資料庫設計文件、系統架構、網路架構......同樣的，想得到的都可以寫成文件。但是，到底為什麼要寫文件，能不能不寫文件、就算要寫，文件又要寫成什麼樣子才是對的？

　　在個人的學習、實作與研究過程當中，有許多的起起伏伏與體認，從最初不懂得如何寫文件、經過以標準範本寫文件、直到現在寫文件已經不再要求開發人員一定要按照業界標準或某個範本，逐項逐條撰寫，這其實是對於系統工程不斷反芻的結果。

　　大家不妨先思考一個問題：在比較具有工程觀念的單位裡，都會要求建構管理(configuration management)這項工程常規(practice)。在納入建構管制機中的項目，大家很容易就想到：程式碼及文件。要管那些文件呢？計畫書、系統文件.....，只要能力夠，什麼都想納管。如果，再問到為什麼要管，大概都會答得出來：要維持版本一致性，避免用錯了版本，造成開發、測試、交付上的困擾。但是，建構管理真的是在管「文件」嗎？「建構管理在管理文件」這個概念，其實說對也不對！

　　看到這裡，大家可能要開始噓聲四起，但是整件事情的事實是：建構管理管的是「資料」，建構管理其實只是一套管理的程序與方法而已，被管到的資料是什麼呢？需求、設計、限制條件、時程、成本、工作的方法、程序、過程等等資料。這些資料的存在，是因為要產出專案的產品或服務，而專案之中有許多的客戶，不論是內在的客戶(團隊裡負責不同工作的成員、高階管理階層等)或是外部的客戶(業主、使用者等)，這些客戶會適地驗收或接收產品與服務，以執行及完成各自的職責或工作。而建構管理就是要運用識別、管制、狀態記述、稽核審查等等手段來維持這些資料的正確、一致、關聯正確……。

　　由專案之中有許多的參與者，有許許多多的客戶，每種客戶又有不同的「知的需求」，所以一定要有一個媒介，來進行溝通的工作。假設，某個客戶(系統設計師)需要業主的需求「資料」，以便進行設計的工作，如果你是系統分析師，你持有這些資料，請問，你會一次給他需要的所有資料呢，還是「先給功能需求，等到設計師問到介面需求時再給介面需求」呢？也許你不怕煩，不怕累，你熱愛你的工作，但是設計師可能不這麼認為，另外，也有可能會因為資料沒有一次給足，設計師就沒有辦法做全面性的思考，做不出好的設計，另外，分次給也可能會面臨各項資料版本不一致的問題。因此，比較好的做法就是建立一個資料版本的關聯性，也就是把相關的資料(正確的版本)串在一起，或放在一起，這樣的話，在各種工作(溝通、協調、執行專案任務)上就方便許多，也便於管理，而這個產出就是一個「文件」，例如我們將專案管理需要用到的資料(專案描述、時程、成本、風險管理、使用技術、專案成員資料……..)集合在一起，就成了專案管理「計畫書」，把功能需求、非功能性需求、介面需求、系統或軟體的限制條件、功能流描述等資料放在一起，就成了軟體需求規格「書」或「文件」。所以，我們談到「文件」，或者「紙張」(把資料記錄及保存在紙上)，其實是一個容器、或者是一個媒介，建構管理中對文件做識別、管制，其目的只是在簡化一些管理的工作，透過管理文件，進而達到「資料」的管理。但是現今，資訊技術、資訊媒體、管理工具都非常發達，是否還需要透過「文件」「紙張」媒體來管理「資料」其實是可以討論的。

　　從上面的討論，我們就可以了解，文件到底是什麼，到底用來做什麼，當然，也就知道為何在現在的一些標準，例如CNS 14837軟體生命週期過程國家標準中，沒有提到工程過程所產生之文件內容及格式(美國版本的IEEE/EIA 12207系列標準則有提列)了，因為文件可以因為需求的不同，而有不同的呈現，這包括使用的媒介、內容及格式。

　　在專案中，該寫那些文件呢？專案中，文件可以由業主來決定，由業主決定的話，最好不要只提名稱，要更具體地提出，內容、大綱，以及每個章節應包括的內容，如果，對於格式沒有特別的偏好，業主仍應說明該項文件要包含的項目為何，以及寫這些項目的目的，否則，建置商或供應商是沒有辦法寫文件的。如果業主認為文件的內容可談，亦應在專案初期(前一個月內)談定，以免因此而影響了整個專案的進程。

　　如果文件由建置商/供應商做決定，建置商/供應商應秉持品質至上的精神，好好提出相關的文件建議，包括名稱、格式及內容綱要。建置商/供應商切不可因為對於文件有建議權，就建議文件都不要寫，因為不寫文件，專案團隊就沒有辦法做有效的溝通、一致性地溝通，這將對專案造成重大的衝擊，更可能因此而無法完成專案，建置商/供應商切不可小覷。因為產品的實際狀況將很難掌控。

如何學習撰寫文件呢？最簡單的方式，就是拿現成的文件來抄寫修改，或是以標準範本作為藍本，撰寫自己的文件。但是，這種寫文件的方法常常會落入「閉門造車」的後果，我們要知道，文件是資料的集合，資料遠比文件範本的格式來得有價值，但是這是否意味著「範本無用」？非也，範本最大的用處除了框出整個文件的架構之外，它還可以導引你寫文件時的思考模式。所以，範本還是有其價值的，但在範本之外，如何產生裡面的資料，則又是基本功夫了。以專案管理計畫書為例，你要估成本、期程、產品的大小、技術難易度、風險管理做法，這其實是建構在系統工程之上的。你首先要了解未來要交付之產品或服務的結構，盡量地向下做區分成一樹狀結構，然後逐項去討論研究複雜度、關聯性等等問題，但這些基本功卻不是透過範本可以看得到的，因此這又是另外一個課題了。

----------------
引文: