根據健力士世界紀錄，我從來沒有寫過程式，以前學一點點Visual Basic也覺得很困難。調職Customer Communications以後，不得不 多聽客戶意見。給錢公司的客戶說想要有方便列印的說明書，於是給錢給我的客戶便自然產生同樣的要求。
現時公司的說明書是以網頁形式發放，將資訊分成容易消化的單位，每單位一頁，方便搜尋和列印，是軟件技術文件的通用標準。可惜公司的客戶比較傳統(麻煩)，即使不看，也要一份看起來像書一樣的說明"書"。基於客戶第一的原則，唯有加以配合。
說一點說明書的背景知識。
剛上任的時候，公司的說明書都是以"書"的方式在Word上製作。而軟件系統的特色是到上市售賣的那天設計都不會定下來，加上功能 眾多，使說明文件也變得篇幅很長，又要時常作出改動，每次修改文件內容時還要顧及格式的統一性，麻煩之極。
說明書作為參考資料，沒有人會由頭到尾看一次。所以能讓人以手頭上的問題為出發點，找尋當下所需的資訊是很重要的。既然不會 順序閱讀，那麼無論在甚麼地方開始看都要看得明白這一點也很重要。
回應第一點要求，說明書的內容被刻意分成細小的單位，以便能針對系統使用者的問題來編寫內容。分成一小塊一小塊的，搜尋起來 亦會比較容易(如google一樣，能根據關鍵字找出不同專題的獨立網頁來)。
回應第二點要求，說明書會提供大量的交互連結，讓讀者透過閱讀相關資訊，自行建構內容的關聯性(因為作者無可能知道讀者喜歡從哪裡開始讀)。說明書中強調的是概念的關聯性而不是文字層面的連貫性("如前所述"、"剛才提到"、"以上/以下的說明"等，都是寫說明書的禁用語)。
總括以上所說，說明書的理想製作方式並不是Word擅長的敍述(narrative)方式，而是能夠被隨意組合的分散(Discrete)方式。因此，編寫說明書需要的是個能夠將資訊隨意組合的編輯工具。
此外，由於說明書格式需要非常統一，互相連結的地方和更新的次數又多，能夠自動排版並追蹤內容之間的聯繫，便顯得特別重要。試想像你在第十頁加了一段文字和幾張圖片，可能從11頁到121頁的連結文字和圖片編號便會被推後，如果說明書中有數十個這樣的地方，而每天都要更新幾個地方，剛是修改"有關XX的資料，請參看第23頁4.2節"一類的句子，已相當費時失事(但很多公司都是這樣做)。
要滿足以上所有的要求，說明書的文字必須能夠被自動化處理，以便能進行"如果段落X的位置往後移動$頁，將所有相關聯結的頁數 增加$"那樣的操作。 Word的文件格式封閉，難以做自動化處理，加上它不擅將一份文件分成多個子文件，並能追蹤之間的關聯，所以經一番研究後，建議公司購買了一個法國出產的編輯工具。該工具能做出很好的分散式說明書，但做不出客戶同時要求的說明"書"。
要使文字能夠被自動化處理，內容編寫和組織方式必須非常有系統，以便電腦能識別(電腦不會知道用Word寫的CV裡哪一段是 公司名稱哪一段是工作經驗描述)。於是，在Technical Communication業界便出現了幾個標準，只要根據標準做人，便可以用支援該些標準的工具去對說明書內容作自動處理和自動排版。可惜，標準之間不是完全兼容，做網頁式說明書的標準用來做傳統的說明"書"，便會出現問題(如不支援亞洲語文)。現在，要兩者兼顧，唯有將跟從標準A編寫的內容用標準B的方式從新排列。
要學習寫程式，就是為了能夠做到上述的標準轉換。
詳細過程相當繁複，簡單說就是將現時已有的符合標準A的分散式檔案輸入到一個局部支援AB標準轉換的工具中，將它們組合成 做"書"所需要的單一檔案(以標準B方式排列)，然後再經過自己編寫程式將剩餘不符合標準的部分改寫成完全符合標準。最後，便能用
支援標準B的工具建立所需的傳統式的說明書。
生平第一次寫程式，剛是以下這幾十行，便摸索了十多個小時。結論是我蠢，不宜當Programmer。不過，這些句子所做的其實已經不少，相當於將英文文章用日文文法重新寫一次，所以還是很有成功感。
沒有留言:
發佈留言