My stories 我的故事 Góa ê kò͘-sū - 麥道之旅 00-1(倉庫寫作實例)
My stories 我的故事 Góa ê kò͘-sū - 麥道之旅
（已經忘了是哪一年在長途旅行的飛機座位上寫的。居然沒有有寫下日期與時間。）
服務將近十年時，有一天中午跟當初面試我的那位科長（branch manager）聊天。(一位科長管理兩位股長 section manager，股長各管理五位最基層的股員)
他那時正在夜間進修要取得學士學位。他說當年部門裡並沒有缺，可是看我用那麼多年在唸書（6+6+4+2+4)，覺得不可思議，就以系統分析員的職位雇用我。反正遲早會有缺。
記得上班後約兩個星期，我的股長告訴我，說我是 underpaid (不足薪？低於市價雇用) 認為我不會留太久。實際上他們看好一位早我一週進去的女孩，盡力栽培她。結果她只待了全職受訓的兩週就走人了。
當時系統分析員的工作有三層：最基本的就是照顧至少一套定期運作的系統。其次是維護、改善既有系統。資深的人才能在一套系統裡面設計新的程式規格。最資深的人才有機會設計包含多程式的全新的系統，甚至提供新系統的構想引導使用者思考。
當時的資訊系統都是在印製報表而已，沒有及時系統，沒有螢幕監視器 monitor，資料只能經由卡片輸入。所謂照顧就是掌握資料進入的狀況，包括時間與數據。確定收到的資料室正確的。大家輪流值班待命。值班期間若接到電話說系統不正常，中途停頓，就立刻進辦公室，找出設計的規格文件對照印出來的報告，追尋問題的所在，提出解決方法。必要時找出所牽涉到的程式，呼召程式撰寫者 （programmer）進辦公室漏夜校正、修改程式，直到完成報告才回家睡覺，不管所遇到的系統是誰設計的，碰到的人就是要去研究。好像沒聽過有「無法解決」的事情。
我的第一個任務是照顧空軍的戰鬥機維修記錄。每個月會定期收到至少一大盤的磁帶。經由公司內部的郵寄系統，把磁帶交到資訊自動化公司 McAuto 去保管、等候上架處理。然後檢驗看看資料是不是有效。實際用電腦溜覽一次，記錄一些相關的數據。若有人要求製作新的報表我就要負責把選取資料跟排版的指令整理好，排入例行行程，按時印出報表交給需要的人。工作看似簡單其實沒有幾個人會。因為系統是公司內部自己設計的，指令當然是外面學不到的。我必須很快地學會那些指令快速上手。
上班後沒幾天就接到一個令人啼笑皆非的任務。當時公司很努力培養員工。經常開辦或是付費讓員工參加許多公司內外的訓練課程。可是老員工大多不喜歡上課。報名是逃不掉的，上課卻可以找人代打。我很快地就被邀請代替別人去受訓。至於「老員工不喜歡受訓」這個怪話題以後另外來寫看看。
第一個課程就是我剛在大學夜間部修過的「系統分析」。我沒敢拒絕，因為我是新手，需要受訓，而且手中不可能有什麼關鍵性任務。要我頂替的人是比我早大約三年就職的次資淺員工。不可能找到比他資深的人去頂替了。我也樂得重修一門剛剛修過、很喜歡的課。或許是因為修過兩次，可能心得超人，幾年後曾有一位使用者部門派來擔任專案領班的同事跟我說我是他看過的當中最好的分析員。記得那好像是他在一次「由我幫他解套」之後的感想。
那次，是他所代表的部門要他領班的這個隊伍，包括我在內，執行一件事情。他沒有提出來討論，不想作，而單刀獨自努力拒絕卻無法得呈。大約爭執兩週之後有一天他叫我跟他一起與那一群提出要求的人開會。很快地，他們就重演爭執，互不相讓。我開口說讓我分析看看。然後我就用流程圖列出兩種作法所牽涉到的動作來比較。他們都同意我所列出的行動。結果，由我這個隊伍執行的話仍免不了要動到他們的人力、時間、與成本。因為我們受委託，一定要花他們的時間講解，並且對照我們提出的步驟，檢驗結果，他們不會較省力或省時，他們就主動收回了。這關鍵在他們都沒有分析，沒有看出並不會涉及「他們不會作的技術」，而只想省自己的事、省自己的力與時間。
還有另一段沒有人知道的故事。我的股長臨時邀請我在完全不知情的前提下跟他的上司科長一起開會。三個人關在會議室裡，很快地他們兩人就吵起來了。我根本沒有開口的餘地。我抓到一個機會問說，可不可以讓我來畫個流程圖看看。他們都同意。我在黑板上畫出一個流程草圖後，問他們對不對。他們都說對。我說聽起來兩個人在講的事情其實是同一件事情在流程裡的不同階段出現。在某個步驟，甲說的有理。到了另一個步驟時。就要換成乙說的方法了。結果兩個人都同意。高高興興地結束會議。
這兩個故事都引我想到自動化其實也是行為科學，因為要電腦取代人的動作與行為時，不認識行為的話是行不通的。
這牽涉到一項有趣的現象：處理資訊的同事們開始使用電腦時只需要處理報表。螢幕終端機出現後，我們需要提供「及時輸入資料」所需的工具，情況就會涉及人際互動而就跟著變複雜了。
在收集需求時，就會看到衝突，爭執不下。最初遇到的是螢幕上顯示跟填空的位置。各個部門看資料跟輸入資料的重點與順序各不相同。剛開始設計螢幕時想的是大家共用一個螢幕版面。很快就踢到鐵板，吵得不可開交。書本上當然還沒有提到這些現象。因為太新了。我們是第一代使用螢幕終端機輸入資料的人。我自己想到說「設計不同的螢幕版面給不同業務的人」就可解套了。反正每個螢幕都會有身份碼可區別，也可限制使用者，每一份資料的輸入也會記載輸入者及時間，不怕用錯或錯用。使用者也不用知道一共有多少不同的螢幕版面在處理相同的資訊。我們就真的帶頭這樣處理了。
其中還有另一層的爭執。產品服務包括許多功能：提供零件與材料、發行使用手冊、訓練技術人員提供高層維護、提供改良或特製的零件組、零件、整理、分析維護記錄、等等。大家都在使用同一套資訊，卻各有不同任務、優先順序、約定的時程。因此，某甲很急的事情，需要用到某乙提供的資訊，乙卻可能另有急事而不急著要輸入甲所急需的那些，因為兩邊的優先次序與業務壓力不同。這吵起來是很嚴肅、又嚴重的。因為一切都有契約的控制。違約是很嚴重的事情。
飛機製造全部過程都倚靠工程師的設計圖。可是工程師提出的不見得可行，必須由撰寫修護手冊的人點頭，認為「可能快速維修、維修的步驟夠方便可行」才行。還要由提供材料/零件的單位找到價格與品質都合格的供應商和出貨承諾才可進行施工。
服務將近十年時，有一天中午跟當初面試我的那位科長（branch manager）聊天。(一位科長管理兩位股長 section manager，股長各管理五位最基層的股員)
他那時正在夜間進修要取得學士學位。他說當年部門裡並沒有缺，可是看我用那麼多年在唸書（6+6+4+2+4)，覺得不可思議，就以系統分析員的職位雇用我。反正遲早會有缺。
記得上班後約兩個星期，我的股長告訴我，說我是 underpaid (不足薪？低於市價雇用) 認為我不會留太久。實際上他們看好一位早我一週進去的女孩，盡力栽培她。結果她只待了全職受訓的兩週就走人了。
當時系統分析員的工作有三層：最基本的就是照顧至少一套定期運作的系統。其次是維護、改善既有系統。資深的人才能在一套系統裡面設計新的程式規格。最資深的人才有機會設計包含多程式的全新的系統，甚至提供新系統的構想引導使用者思考。
當時的資訊系統都是在印製報表而已，沒有及時系統，沒有螢幕監視器 monitor，資料只能經由卡片輸入。所謂照顧就是掌握資料進入的狀況，包括時間與數據。確定收到的資料室正確的。大家輪流值班待命。值班期間若接到電話說系統不正常，中途停頓，就立刻進辦公室，找出設計的規格文件對照印出來的報告，追尋問題的所在，提出解決方法。必要時找出所牽涉到的程式，呼召程式撰寫者 （programmer）進辦公室漏夜校正、修改程式，直到完成報告才回家睡覺，不管所遇到的系統是誰設計的，碰到的人就是要去研究。好像沒聽過有「無法解決」的事情。
我的第一個任務是照顧空軍的戰鬥機維修記錄。每個月會定期收到至少一大盤的磁帶。經由公司內部的郵寄系統，把磁帶交到資訊自動化公司 McAuto 去保管、等候上架處理。然後檢驗看看資料是不是有效。實際用電腦溜覽一次，記錄一些相關的數據。若有人要求製作新的報表我就要負責把選取資料跟排版的指令整理好，排入例行行程，按時印出報表交給需要的人。工作看似簡單其實沒有幾個人會。因為系統是公司內部自己設計的，指令當然是外面學不到的。我必須很快地學會那些指令快速上手。
上班後沒幾天就接到一個令人啼笑皆非的任務。當時公司很努力培養員工。經常開辦或是付費讓員工參加許多公司內外的訓練課程。可是老員工大多不喜歡上課。報名是逃不掉的，上課卻可以找人代打。我很快地就被邀請代替別人去受訓。至於「老員工不喜歡受訓」這個怪話題以後另外來寫看看。
第一個課程就是我剛在大學夜間部修過的「系統分析」。我沒敢拒絕，因為我是新手，需要受訓，而且手中不可能有什麼關鍵性任務。要我頂替的人是比我早大約三年就職的次資淺員工。不可能找到比他資深的人去頂替了。我也樂得重修一門剛剛修過、很喜歡的課。或許是因為修過兩次，可能心得超人，幾年後曾有一位使用者部門派來擔任專案領班的同事跟我說我是他看過的當中最好的分析員。記得那好像是他在一次「由我幫他解套」之後的感想。
那次，是他所代表的部門要他領班的這個隊伍，包括我在內，執行一件事情。他沒有提出來討論，不想作，而單刀獨自努力拒絕卻無法得呈。大約爭執兩週之後有一天他叫我跟他一起與那一群提出要求的人開會。很快地，他們就重演爭執，互不相讓。我開口說讓我分析看看。然後我就用流程圖列出兩種作法所牽涉到的動作來比較。他們都同意我所列出的行動。結果，由我這個隊伍執行的話仍免不了要動到他們的人力、時間、與成本。因為我們受委託，一定要花他們的時間講解，並且對照我們提出的步驟，檢驗結果，他們不會較省力或省時，他們就主動收回了。這關鍵在他們都沒有分析，沒有看出並不會涉及「他們不會作的技術」，而只想省自己的事、省自己的力與時間。
還有另一段沒有人知道的故事。我的股長臨時邀請我在完全不知情的前提下跟他的上司科長一起開會。三個人關在會議室裡，很快地他們兩人就吵起來了。我根本沒有開口的餘地。我抓到一個機會問說，可不可以讓我來畫個流程圖看看。他們都同意。我在黑板上畫出一個流程草圖後，問他們對不對。他們都說對。我說聽起來兩個人在講的事情其實是同一件事情在流程裡的不同階段出現。在某個步驟，甲說的有理。到了另一個步驟時。就要換成乙說的方法了。結果兩個人都同意。高高興興地結束會議。
這兩個故事都引我想到自動化其實也是行為科學，因為要電腦取代人的動作與行為時，不認識行為的話是行不通的。
這牽涉到一項有趣的現象：處理資訊的同事們開始使用電腦時只需要處理報表。螢幕終端機出現後，我們需要提供「及時輸入資料」所需的工具，情況就會涉及人際互動而就跟著變複雜了。
在收集需求時，就會看到衝突，爭執不下。最初遇到的是螢幕上顯示跟填空的位置。各個部門看資料跟輸入資料的重點與順序各不相同。剛開始設計螢幕時想的是大家共用一個螢幕版面。很快就踢到鐵板，吵得不可開交。書本上當然還沒有提到這些現象。因為太新了。我們是第一代使用螢幕終端機輸入資料的人。我自己想到說「設計不同的螢幕版面給不同業務的人」就可解套了。反正每個螢幕都會有身份碼可區別，也可限制使用者，每一份資料的輸入也會記載輸入者及時間，不怕用錯或錯用。使用者也不用知道一共有多少不同的螢幕版面在處理相同的資訊。我們就真的帶頭這樣處理了。
其中還有另一層的爭執。產品服務包括許多功能：提供零件與材料、發行使用手冊、訓練技術人員提供高層維護、提供改良或特製的零件組、零件、整理、分析維護記錄、等等。大家都在使用同一套資訊，卻各有不同任務、優先順序、約定的時程。因此，某甲很急的事情，需要用到某乙提供的資訊，乙卻可能另有急事而不急著要輸入甲所急需的那些，因為兩邊的優先次序與業務壓力不同。這吵起來是很嚴肅、又嚴重的。因為一切都有契約的控制。違約是很嚴重的事情。
飛機製造全部過程都倚靠工程師的設計圖。可是工程師提出的不見得可行，必須由撰寫修護手冊的人點頭，認為「可能快速維修、維修的步驟夠方便可行」才行。還要由提供材料/零件的單位找到價格與品質都合格的供應商和出貨承諾才可進行施工。
一旦設計圖通過了，進入產品服務的領域，大家同意以供貨部門為第一關卡。他們同意的資料才有效。在各自收集資料的時代，因為各自為政，沒有優先次序的問題，只有資料不一致的問題，往往出現資料兜不攏或互相抵觸的現象。在舊的「資料島」時代裡，資料由各單位各自經營、收藏、管理，資料矛盾的事情層出不窮，無法預防，只能在發現後再說了。
我加入資訊自動化的陣容之後不久（大約五年），國防部要求資訊必須保存在整合性，「共用的」資料庫，以便維持內容一致，就出現新的挑戰了。
根據設計圖所衍生的成千上萬的材料與零件名稱個個都需要供貨部門點頭、輸入資料庫才可以使用。那不是一兩個月內就可完成的事情。因為需要交涉到有合格的供貨商簽約才行。
撰寫維護手冊的人看到設計草圖後就立刻開工撰稿，往往是建立在「使用尚未完稿、核准的設計圖」這樣的前提上。每一冊使用手冊每一版本有不同的交卷日期。飛機出廠後繼續開發的「追加修改 retrofit」更是複雜，因為不見得會牽涉到全部已經出廠交貨的飛機。
手冊撰稿者希望提早開始作業，自行輸入零件或是材料的名稱，供貨部門堅持不准逾越權限、損傷工作權，就吵了。後來我創造新的概念，推出「暫存用的過渡抽屜」收藏「待確認的資料」，讓供貨部門追認或否認撰寫者抽屜裡的資料，才解套，皆大歡喜。
當時我設計的是撰稿用資料庫。要讓撰稿者只操心資料的正確性，而不必操心版面觀瞻。也不必去檢驗資料是否在不同的手冊之中一致。那是全新的寫作方法。
...應該還有補充的餘地
2020/3/8 8:21 或許這就是我在勵馨基金會服務的時候突然冒出「倉庫寫作與櫥窗寫作」的基礎。這個倉庫寫作現在是我在探討的「回憶錄寫作法」的骨架。這是出乎意料之外的「跨領域應用」的產品。曾聽說航太工業的新科技大多會延伸逐漸進入一般生活裡面廣泛應用。這是一項印證。相信每個人在各自領域裡的心得也可能在其他領域裡致蔭（造益）他人。8:28
Comments
Post a Comment