A11 流程與資源的關聯(2)──資源部分

工作項目的目標是為了產出，在一開始我們就應該規定好各種產出的規格與內容。要記得產出的每一個部分都有其用處，不管是作為其他工作項目的輸入，或者是規定的內容。如果產出裡夾雜一些說不出用途的內容，那一定是做著開心的。

在工作項目裡，對於起始條件的判斷應予以註明，用明確的敍述來表達條件的判斷。輸入引用的如果是其他工作項目的產出，最好可以註明引用的是產出的什麼部分。請注意一個現象：使用同一個產出／輸入的物件造成了前後兩個工作項目的關聯

依以上的定義，我們可以得到三種物件：工作項目、產出／輸入、執行者（工作項目雖然不是實物，但它是一個可定義的事，所以可視為一種物件）。其中工作項目與產出／輸入有關聯，與執行者有另一種關聯，另外工作項目與工作項目也有先後的關聯存在。

在這裡有一個很重要的觀念是：“有關聯的物件都應該記錄其追溯關係，而且得是雙向的追溯”。

A10 流程與資源的關連(1)──流程部分

計畫的開始，首先要儘可能地列出所有的工作項目；要記得所有制定的項目都要確實做到review的動作，藉由其他瞭解的人來確認有沒有遺漏或多餘並加以調整。最後確認的所有工作項目應該收集到“清單”裡。

接下來要做的是把工作項目指派給人來執行，被指派的人依照工作項目來訂定工作步驟，決定要做哪些事情。訂定好起始的條件、各個步驟的輸入與產出並集合到工作項目的定義，同時預估每個自己應執行的工作項目各需要多少工時來處理。

理論上，所有的工作項目是沒有關連的，讓工作項目間產生順序關係的是彼此使用的資源。工作項目Ａ的起始條件或輸入如果必須依賴工作項目Ｂ的產出，那麼一定得先做Ｂ再做Ａ；如果工作項目Ｃ與Ｄ都依賴工作項目Ｅ的產出，那麼Ｃ與Ｄ都必須都在Ｅ後面而且Ｃ與Ｄ沒有先後關係。先按照輸入與產出的關係擬定所有工作項目的順序是此時要做的。

還有一個會影響工作項目順序的是執行者，原則上所有的人一次應進行一個工作項目，做完該項後再做另一項。如果有兩個重要的項目必須由同一個人來做，那麼不是找另一個可以處理的人在同一時間來做，就是得把其中一個工作項目排在另一個工作項目之後。

安排工作項目與管理資源，Microsoft Project是一項著名的好用工具。

A09 清單與項目(1)──目標與步驟

不管是里程碑、工作項目，每一項的存在都是為了要達成一個（或以上）的目標，而那些目標必須是可檢驗的。也就是說在進入那個項目之前與之後，會產生目標未完成與已完成的差異；這些差異應該要可以被比較出來。

每一個目標，理論上應該排出一個對應的工作項目作為它的處理。接著根據目標的達成容易與否，再將目標切割為幾個階段性的部分，每個小階段視狀況分配一個（或以上）的工作步驟與之對應。以此原則處理，一個目標對應一個工作項目，一個小階段對應一組工作步驟，就可以保證每個目標都會被處理到，而且每個步驟都是可執行的。

有時在工作項目的起始階段需要某些特定事物成立才能開始，這是起始條件。負責處理工作步驟的是人；工作步驟裡如果需要不是由這個工作項目產出的事物則稱為輸入；而工作項目的目標成果被稱為產出。起始條件、人、輸入與產出等被統稱為“資源”，工作項目執行順序被決定後則是“流程”。

有一個笑話可以作為工作步驟執行條件訂定失敗的例子。小明出去買東西，爸爸叮嚀說：“一定要等車子過了才能過馬路喔！”，結果小明一去去了半天。爸爸問他：“你怎麼買個東西去這麼久？”，小明委屈的說：“我等了快兩個小時才有車子出現……。”

A08 Blog Roadmap

每個人的Blog裡都有許多篇的文章。雖然有作分類與時間排序，但是乍看之下總覺得千頭萬緒，不知從哪裡開始才好。

想表達的想法事先列出來超過六十個標題。如果隨心所欲，想到什麼寫什麼，看的人想由雜亂無章中再組織起來實在是很難的事。所以我事先把各篇文章的標題分類，儘量循序漸進地結構化表達想法而不要跳來跳去。（這就是一種計畫）

這張用Rose裡Activity Diagram所畫的圖大致顯示現在Blog裡文章的表達順序與屬性。看一張結構圖總比一一看過一堆文章後再來推測彼此間的關連快上許多。這張圖將會依Blog最近的狀態時常更新。

Ａ、基本觀念之顏色範例：
淡藍色──記錄的重要性
淡綠色──做事的方法
淡黃色──資源管理
淡灰色──追溯關係

Ｂ、需求階段之顏色範例：
淡藍色──專案的概念
淡綠色──Use Case Diagram
淡紫色──Activity Diagram
淡灰色──其他基本概念
淡黃色－－Data Model

Ｃ、架構設計之顏色範例：
淡藍色──架構設計的基礎
淡綠色──架構設計的層次
淡紫色──MVC的設計方法

Ｄ、架構設計之顏色範例：
淡藍色──細部設計的基礎
淡綠色──細部設計的層次
淡紫色──應該做到的設計

A07 做事的方法(3)──逐步執行且可驗證的計畫

小時候寫我的志願作文時，記得自己寫下了什麼嗎？在作文裡只需志願、達到志願後的好壞與想做的事，但這些並沒包括要怎麼去達成志願。夢想是可以達成的，只要你列得出可以執行的計畫與步驟！

小的目標當然可以針對目標寫下所有要做的事；大型的計畫會在眾多的步驟裡切割出幾個重要的里程碑，並各自訂出達到的檢驗標準。每個里程碑都可視為一個小型的階段性目標，計畫時只需個別針對一個里程碑擬定執行各自的計畫。

當夢想可以切割為數個有希望達成的里程碑，從現在狀況邁向下一個里程碑都擁有計畫，計畫再切割為數個工作項目，每個工作項目再切割出可以執行的簡單工作步驟。從最小的工作步驟開始、累積成工作項目、再到完成里程碑，一項項可以逐步執行並累積的成果，正代表著一步步往夢想目標走去的你。

把一件大的工作切割成多個可執行的部分，是一項重要且應該具備的做事能力。切分工作的原則很難描述清楚，不過大致上與其他的工作項目、輸入及輸出、處理該工作步驟的人有關係（有時這種動作可以稱為決策）。處理的流程與使用的資源會是下面所要討論的。

A06 日常生活中的SOP

標準作業程序（SOP）應用在生活裡會不會小題大作？同時給人太刻板的感覺？

身為資訊人，重灌電腦的經歷一定少不了，安裝的次數少說也有幾百次。以前都比較隨性，直接從事先燒好的軟體光碟裡裝上當時想要的東西，系統的設定也以設定當時想到的。最近使用Windows Mobile手機，同樣經歷需要重灌的過程，但是手機程式小而多，每次安裝選好軟體後都感覺還是少了什麼。

有次終於受不了，真的逐步寫下安裝手機時需要設定的步驟與安裝的軟體。寫的時候花了一些思考與記錄的時間，但是安裝時就不需要再動腦，只要依照手冊按部就班照著做。我在想，如果哪天手機掛掉我卻沒時間處理的話，就可以把手機、軟體與這份SOP拿給別人代為安裝而不需特別交待什麼。（那個人當然必須懂得安裝的基本，這是必要條件）

同樣的想法可以應用在其它方面：比如總會有幾位朋友會來跟你借車，而你需要一一對每位朋友說明車子應注意的事項；朋友不見得每次都記得該注意什麼，為了避免問題你也只能全部再重講一次。沒錯，把你想說的話記錄在一張紙上，請朋友依清單逐一檢視他該遵守的事項，你就不用再囉嗦啦。

在此得到的通則是，需要特別處理的生活事件而且會重覆發生時（參與者可能都是自己也可能是不特定的人），適合記錄下處理的方式讓當事人遵循；如此就可以保證每次處理事件的方法都會相同。

A05 做事的方法(2)──Standard Operation Procedure

反應事件的程式經過測試後，可以保證事件發生時都會有同樣的處理。同一個人在同樣的情況下都不見得會有同樣的處理方式了，更何況換不同的人來處理呢？為了保證不管是誰，都能在指定的事件發生時有同樣的處理，因此產生SOP。

簡單地舉個範例，幼稚園老師面對一群還不會上大號的小孩一定不會一個一個教他們，而會公開宣布首先要脫褲子，再來坐上馬桶，然後排便，擦屁股，最後穿回褲子並洗手。可是不管講了幾遍，一定會有小朋友忘記或是把順序弄反了（譬如先坐上馬桶，排便，才脫褲子）；最後老師把正確的動作順序寫成海報貼在廁所，要小朋友們依海報內容做事，這樣教的人不用一直講，使用的人也不會做錯，大家就跟著輕鬆囉。

可是有一天，小朋友回來哭訴說家裡沒有馬桶，沒法執行坐上馬桶的動作。這時老師就發現在這個動作時可能有一些例外情況，因此就加上例外流程：馬桶要用坐的，蹲式的要蹲下來，在野外的草叢要找隱密點的地方蹲等等。這些相關的程序也應該全部收集到SOP的文件裡。

一個有完整制度的公司，會先設想好所有的事情先行擬好SOP，所有的人員只要照章行事即可。那麼一個設計良好的系統，是不是也應該先依據所有的功能與事件，思考出對應的方式呢？當然，想出的方式如果直接變為可讀性差的程式，會使得除了你之外的所有人要再花時間回溯你的想法。

這些因應功能與事件流程的產出可以用文字檔記錄或是畫成UML裡的Activity Diagram收集起來作系統的正式文件。

A04 做事的方法(1)──事件或狀況發生時

當一個狀況成立的時候，一個人應對這個情景的相關行為，會被定義這個人的做事方法。

每天早上妻在小朋友們上學前都會一項一項問說什麼帶了沒，這對當時還窩在床上的我來說實在是難以忍受的噪音轟炸。有天我終於受不了，先在門口的小白板上寫下“上學”兩個字，並在下面列出五項平時叮嚀要帶的項目。現在小朋友們在“上學”這個事件發生的時候，就依照指定的項目逐一檢查，全部確認完畢後就可以安心出門而不用怕忘記帶什麼東西。

這種思維在程式設計領域裡很眼熟吧？當我們檢查一個變數（或API）傳回我們想要的值或是某個event發生時，controller就會開始執行一段特定的程式碼。系統在不同的時間點，不同的事件發生時，都會有其對應的事情要做；這樣的情形在有使用者操作介面時更多。把這些與系統行為有關的處理記錄下來並加以分析，將會影響到系統的行為模式。

對人來說，事先預想各式各樣有可能發生的事件並決定應對方法，可以加速處理事情的速度。當然，在相同的狀況下應該要保持相同的處理方式。如果每次相同的情況發生系統的反應都不一樣的話，使用者會把系統嫌到爆；這種現象要是發生在人身上的話，就會令人無法相信那個人。

因此，人應該努力維持相同的反應行為才能建立屬於自己的原則。不是嗎？

A03 程式註解的習慣

1997年的某一天，上班後我照例開啟了當時以Ｃ語言開發的。那是一隻已經幾千行的主程式，宣告的變數大約近百個。這時候的我仗著年輕氣盛，同樣只把功能寫進程式而完全沒有註解的模式，至今從來沒出任何差錯過。

忽然之間，程式追到一個很眼熟的變數，可是我一時之間對它卻沒有回憶。我不死心地向下與向下搜尋，試圖從呼叫的串連裡找到宣告它的意義；然而我忙了半個工作天，還是完全沒法子喚起對它的記憶。

科學家已經證實，“忘記”並不是失去，僅是一時間腦海裡沒法搜尋到該事物的記憶。但半天之後，我已經沒有耐性等待記憶鏈結的回復；我耗費了一天半的時間找出所有變數為什麼會宣告的原因，並將之填寫在該變數旁的註解裡。從此之後為避免遺忘，我養成了隨手輸入簡短註解的習慣。

人應該為自己做過的事負責，在軟體工程裡包括解釋自己曾經寫下過的所有程式碼。當旁人問說：“這段程式為什麼這樣寫？”或者“這段程式做了什麼事？”時，回答忘了或我看一下程式再回答，都是沒法負起責任的行為。

我們沒法時時刻刻記得曾經發生過的大小事件，在當下記錄想法成為註解，是一個即時讓人明白你曾經做過事情想法的最佳方式，而且你還不用花任何時間說明喔。（相信我，當你接連被不同的人詢問同一段程式的寫法或意義時，所耗費的時間遠超過你花在寫簡單註解的）