控制軟體開發多工作業探討

PC-based控制軟體開發多工作業探討

曹永誠

[刊登於機電整合雜誌第100期 (2006年12月)]

前  言

對於開發機台PC-based控制軟體來說，同時間進行數個開發專案應該是常有的事。但是這種同時進行多項任務的多工作業究竟是提高效率的「良方」，或是不得已而為之的「權宜之計」，會去深入探討的人並不多。本文就PC-based控制軟體開發時的多工作業執行狀況、接續成本等進行探討，並提出建議方案以期降低多工作業的接續成本。

多工作業探討

對於機台開發專案，參與過的先進應該都有同時進行數個專案的多工作業經驗。還記得在進入這行業初期，上級就曾公開表示：「每個人都應該同時做二個以上的專案，因為專案有『緊』的時候也有『鬆』的時候，同時進行可以『鬆』『緊』互補，以『鬆』補『緊』提高效率」。我想有這種想法的不在少數，就算不公開表示贊同也多半認定這是無法避免的事情。但是這種同時執行二個以上專案的多工作業模式，是否真的比較好？為此後文試圖重新針對多工作業的狀況、產生的問題、接續成本與改進方案來探討。

首先我們先來探討「多工作業比較好」或是「多工作業比較有效率」中的好與效率的定義。基本上所謂的「好」或是「效率」，大多數的管理者都會以員工的忙碌程度或是是否有空閒時間來主觀評估，直覺認定只要員工閒閒沒事做，就沒有任何產出。簡單來說就是領薪水不做事，當然對公司不利，這種領薪水不做事的時間總合越多，效率當然越低也就是越不好。因此如果是以這種觀點來看，每個人都應當要多工作業，儘量把時間塞的滿滿的得到的成效就越高。若我們從另外一個角度來看，假設專案的完成時程是否準時，或是時程的長短對於公司的獲利影響遠超過人力的短暫閒置成本的話，那就不該只考慮人員的忙碌程度或是空閒時間的頻率與數量，而是必須從根源來探討多工作業對於專案時程以及對於公司實際獲利狀況的影響。以賣方市場來說，不管專案的完成時程如何被展延或是品質如何降低，獲利與銷售量並不會因此受到太大的影響；但是如果是買方市場，或是現今的消費性電子產品模式的市場，開發成本對於公司的營運其實影響不會很大，產品上市的時機才是影響獲利的重大因素。因此如果該公司或產業是面對這種模式的市場，整個思維模式就得重新考量。換句話說，當準時上市的獲利遠超過人力些微閒置的成本時，寧可讓員工偶爾清閒，以保障產品的準時上市。

我們先不就市場模式與公司運作考核等方向探討，先就多工作業特性、影響與成本來探討。以定性的角度來觀察，一個程式設計師在執行專案的某個步驟（TASK）時，有沒有可能不被中斷而能專心工作直到該步驟結束。我想只要該步驟所需執行時間超過數小時者應該都不可能不需要中斷，至少執行人員也得吃飯、睡覺與休息。其次是執行人員工作被中斷之後，回頭繼續該項工作是否需要成本（接續時間、品質降低）？答案是一定會的，而且成本並不固定。設想如果一個程式設計師設計某段程式第1000行之後被中斷與調派執行另一項工作，一年後回頭繼續撰寫該段程式時，怎麼樣也不可能立刻可以開始著手撰寫第1001行而能維持相同的品質；但是如果只是前往餐廳吃飯而工作中斷30分鐘，我想接續撰寫所需要的時間一定很少。不管如何只要有中斷與回復，一定得付出成本，就像電腦的多工（multi-task）與多執行緒（multi-thread），當作業系統（OS）進行程序與執行緒切換（context switch）時，必然需要一小段CPU時間成本；相對的人也是相同的，對於某個TASK工作，中斷後的回復必然需要額外的時間來回復記憶。而且對於電腦來說，除非硬體出問題，記憶體的內容必然存在不會消失或無端更改；但是人可不是這樣的，人會忘記與混淆，勢必得花更多的時間來回憶，並且因為無法完整的回想起當初的構思與考量點，因此接續時的軟體品質必然下降。這些零零總總因為多工中斷後的接續工作所發生的額外成本，我們統稱「接續成本」。

以機台開發PC-based控制軟體設計的模式來看，影響多工作業下工作中斷後的接續成本有以下四類因素：預定與否、中斷時間長短、中斷的時機與中斷後執行的工作同質性程度。如果是計畫中預定的中斷，工程師會比較有心理準備，會盡量將事情做到某個比較明確的段落，甚至有時間可以記錄下相關資訊，降低因為忘記等因素的接續成本，這算是較佳的狀況。以中斷時間長短來看，中斷時間的長短會嚴重影響回復作業時的成本，而且有類似正比的關係式，只是不見得是線性關係。而中斷的時機影響則是很微妙，如果中斷時機是在思考很複雜的問題的時候，由於變數繁多且關係複雜，執行時幾乎花費全部腦力來思索，如果此時被中斷，回復的時候勢必從頭思考。因此接續成本與中斷時的工作複雜度應該也有正比關係，只是數額比較難數量化。最後是同質性問題，以過去的經驗而論，中斷後執行的工作如果與被中斷的工作同質性程度過高，則會有相當不確定的影響，有時候成本高昂但是有時卻不受干擾。例如機台程式開發到一半被中斷去處理另一台的程式碼Debug，因為二機台的程式都是自己寫的因此同質性高但是卻又不盡相同時，等Debug完成之後回來處理原機台開發時，有時會發生思考邏輯無意間被混淆而不自知，因此回復時間短但是品質低，容易產生隱藏的Bug。

圖一、機台開發多工作業模式

多工作業模擬

接著我們以機台開發專案中的控制軟體設計與製作來模擬多工作業狀況。以圖一為例，比如說機台X的開發（Project 1）與機台Y的開發（Project 2）同時進行，二者對於公司的未來營運都很重要，機台X的開發要先進行TASK 1工作由B工程師負責，等到TASK 1完成之後TASK 2才能開始進行由A工程師負責，完成之後TASK 3才能開始進行由D工程師負責。而機台Y的開發要先進行TASK 1工作由C工程師負責，等到TASK 1完成之後TASK 2才能開始進行由A工程師負責，完成之後TASK 3才能開始進行由E工程師負責。因為A工程師的專長特殊，沒有其他人員可以幫忙或取代，而機台的開發又一定需要A工程師才會的TASK 2工作。因此當二個專案同時（或幾乎同時）開始進行時，A工程師勢必得面對二份必須同時處理的工作，假設TASK 2的工作得花5工作天，那麼勢必有機台可以先被進行（5工作天完成），有機台會被延遲執行（5天延遲加上5工作天），問題是TASK 2完成之後TASK 3才能被執行，因此只要被延遲的勢必延遲整個專案的完工期限（除非該專案有緩衝Buffer）。不管是機台X還是機台Y的專案經理，當然都不會希望自己的專案被延遲完成，因此他們共通的想法是-請A工程師加班進行。其實這是很糟的解決方案，加班應該是不得已時的救命王牌，是不可常用也不可習以為常的。當這種資源衝突的頻率不高時，或許加班可以暫時解決問題，但是如果常常資源發生衝突而不停的要求加班，或是衝突時期長達數週或數個月時，那麼加班除了成本提升之外，也會造成人員流失或是品質與效率降低的副作用。

圖二、機台開發多工作業模擬狀況

首先我們來探討A工程師因為承受上級的壓力而開始多工作業時的狀況。如圖二所示，如果我們要求A工程師開始多工作業，二個機台開發專案的執行狀況可能會有三種結果：Case A、Case B、Case C。以Case A的狀況來說，當Project(1) TASK2與Project(2) TASK2衝突的時候，A工程師不管二個專案經理的壓力與抱怨，先將Project(1) TASK2完成，讓Project(2)等待到Project(1)的TASK2完成之後才開始進行Project(2)的TASK2部份，因此Project(1)對於這部份將可以進度正常（理論上如果無任何延遲的話）。而對於Project(2)來說，因為A工程師被Project(1) TASK2佔用了5工作天，因此Project(2)進度延遲了五天；而二個專案總共延遲了五天。

以Case B的狀況來說，因為A工程師耐不住壓力，反正工程師領薪水上班做事，一天八小時的工作時間，誰的專案趕、誰的嗓門大，就著手先寫他的程式。因此就會發生如圖二Case B所示的狀況，A工程師先開始寫Project(1) TASK2的程式(X1)，寫了二天之後Project(2)的專案經理發現了，開始好言勸說，A工程師不敢得罪於是開始寫Project(2) TASK2的程式(Y1)。二天之後Project(1)的專案經理發現自己的專案停擺，暴跳如雷因此A工程師就又轉回來繼續寫Project(1)的程式(X2)，又二天之後，Project(2)的專案經理也發現A工程師怎麼不寫自己的程式，於是找他來「談心」，雖然A工程師一再強調人只有一個，請雙方專案經理自行協調之後再來告訴他先寫誰的程式，但是顯然Project(2)的專案經理聽不下去，一直強調自己的專案才是最重要最優先的專案，於是A工程師只能在這種壓力下又轉回寫Project(2)的程式(Y2)。如此下去，A工程師不停的在二個專案之間切換工作，最後的結果變成Project(1) TASK2第九天才完成，延遲四天；Project(2) TASK2第十天才完成，延遲五天；而二個專案共延遲了九天。[5]

如果以更真實的角度來看，執行狀況應該比較接近Case C。當A工程師由Project(1) TASK2的工作做到一半轉到Project(2) TASK2的工作，然後又轉回來的時候，實際上必須花費額外的時間來回想當初設計的構思與考量點。由於人的記憶會隨著時間的長短而逐漸遺忘，因此當回頭設計程式時的程式品質勢必降低，程式除錯的成本必定增加。因此X2的部份就不會如原先預期的進度只需要二天，而是必須得加上接續成本變成三天（估測值）。因此模擬的結果變成，A工程師不停的在二個專案之間切換工作，最後Project(1) TASK2第十二天才完成，延遲七天；Project(2) TASK2第十四天才完成，延遲九天；而二個專案共延遲了十六天。

以過去的經驗來說，去年筆者的團隊成員共7人，而一整年的專案執行數目有6個。以時間切面來看，絕大多數的時候每個人手頭上總有二三個以上的案子得同時進行。也就是當專案被陸續啟始之後，專案的工作被會如期的下達到每個工程師的工作列表中，讓工程師自行決定如何安排時間與執行次序。但是這種方式無疑的會讓整體效率變的很糟，一方面切換的效率很低，因為工程師決定先做後做的考量點往往不是依照專案的重要優先程度來排定，也不會考慮該工作在專案中的相依性高低，常常是憑感覺、興趣或是先做什麼比較省事等等個人主觀理由來排定；另一方面多工作業也提供了工程師摸魚打混的煙幕，因為工程師可以對專案(1)的專案經理說很忙因為在忙專案(2)的要緊工作；同時對專案(2)的專案經理說很忙因為在忙專案(1)的要緊工作。

  

多工作業建議方案

雖然不當的多工作業對於機台開發專案來說，往往問題很嚴重甚至導致出機時程的延誤，但是專案經理往往不願意去面對與解決這些問題。以決策分析中人性的角度來看，「二利相比取其大」對人來說因為都是有利的選擇，比較願意去面對與抉擇；而「二害相權取其輕」因為都是壞的不好的選擇，基於人性就有人會選擇儘量不去面對。因此這種專案工作衝突所導致的不當多工作業，專案經理往往期盼工程師會自我規範主動加班，拼死拼活工作雙倍時間（16小時工時）以完成任務。但是，一方面這是很不人性也是不對的想法；二方面對於過去的年代來說，這種狀況或許可以行的通，如今面對臺灣的現狀與七年級生的特性，情況只會更壞不會更好。況且就算允許時間加倍以因應同時進行二件事的多工作業，卻也避免不了工作切換所產生的額外成本。以下為筆者建議的幾類概念與方案，期能儘量降低多工作業的接續成本。

1. 盡可能不要讓專案衝突：如果是事先排定的專案，建議排開啟始時間避免專案時程與資源衝突，不要在一開始就給自己找麻煩。
2. 衝突時的裁決由主管負責：公司的決策不可能事事順利，改期、變更或是突然插入執行的狀況總是無法完全避免，而這類臨時性變更往往造成專案時程與資源衝突。遇到這種狀況專案經理、PMO或是部經理要負起排解的責任，不可將工作排程責任下放到基層工程師身上。最佳狀況是基層工程師同時間只會接收到一份命令，一份單純而明確的命令，例如：A工程師請您於M月N日前完成TASK XXX。
3. 專案要區分優先等級，中斷點最好在TASK完成點：負責排解衝突的管理階層要區分衝突專案的優先順序，而且除非事關重大不可中斷正在進行的專案TASK的執行，最好等到該TASK完成之後才進行轉移執行優先順序高的專案TASK。如果真有非常緊急非中斷不可的情況，最好坦白告知基層工程師實情並中斷工作，只是一旦緊急插入的TASK完成之後，再回頭繼續執行原專案時，不管被中斷的TASK被中斷當時的進度是多少百分比，一律從頭開始執行，以維持程式品質與工作的公平性。對於中斷與插入所造成的品質下降與時程增加等接續成本，管理階層一定要概括承受以取信基層工程師。
4. 專案的TASK切割要細並適切安排：專案TASK的安排優劣與否對於多工作業的接續成本影響很大，因為TASK的連接點就是允許插入優先權高的專案的中斷點。因此TASK的切割要細，每個TASK的間隔時間要短。原則上物件導向是必備的要求，並且適度的切割Class以降低TASK間的相依性。例如Class的程式設計TASK要切割成二部份：介面（Interface）的制訂、實作程式（Implement）的撰寫。畢竟撰寫實作程式的時間比起制訂介面的時間要長很多，只要Class的介面制訂完成，其後相關的TASK就可以開始進行，不需要等到整個程式都撰寫完成。
5. 排程程式與操作流程部分建議不要分割也不要中斷：對於排程程式與操作流程部分，建議最好不要分割也不要中斷工作，因為排程與操作流程是龐大繁複又需要審慎考量邏輯的部分，如果切割或中斷，極有可能會因此忘記某些考量點或是思路上的中斷造成隱藏的bug。
6. Class之間的邏輯與流程關連性要儘量降低：Class的安排與設計要儘量降低彼此之間的邏輯與流程相關性，並且避免全域變數（或是物件）設計。因為TASK被中斷之後到回頭接續執行這中間的時間長短不定，有時會拖很長的時間才得以接續進行，如果彼此的相關性太高，後續的程式撰寫就容易因為邏輯、流程與考量點忘記而產生隱藏的bug。
7. 設計技術文件要與程式撰寫同步進行，以降低中斷後遺忘的接續成本，並為成員異動或是進度延誤時新成員的加入做準備。

  

結  語

多工作業容易造成開發成本增加與軟體品質下降，但是在現實環境中卻又很難避免，因此透過專案管理的安排與軟體架構設計，或許可以儘量降低多工作業所造成的接續成本損失。通常實際發生的狀況總是比前文模擬的複雜，相對的軟體Class的安排也變的很難掌控，如果專案的數量多而且完工時程又短，不當多工作業的頻率就會提高，而隱性或顯性的接續成本將會變的很高昂。但是如果能從經驗中已知的瓶頸處（關鍵成員或關鍵技能）著手，儘量依照本文建議的方案改善，或許可以降低部份的接續成本。

參考文獻

[1]曹永誠，共通控制程式架構，電機月刊第99期，1999/3
[2]曹永誠，控制程式發展系統，電機月刊第140期，2002/8
[3]曹永誠，機台控制系統軟體開發效率提升探討，電機月刊第162期，2004/6
[4]曹永誠，漫談PC-Base控制程式設計(1)(2)(3)，工業電機&自動控制裝置與設計雜誌，1998/7,8,9
[5]高德拉特，關鍵鏈－突破專案管理的瓶頸，天下文化，2002/6/20