幼稚園是人從小開始學習與他人生活的第一個階段。他們學到只要知道如何分享，即使一個玩具卡車、洋娃娃、故事書或拼圖也足夠讓10個小朋友用。他們也學會當別人說話時要安靜地乖乖坐好，要發言時先舉手，並且等到該說話時再發言。他們也學到開始一件工作就要把它做完。最重要的，他們學到每個人只要有心，都有可能當美國總統，如(圖一)。總而言之，他們所學習的一切都是不利於嵌入式設計的。

《圖一　幼稚園所教的事》

當談到如何管理一個嵌入式設計方案時，我們在幼稚園時學的所有一切都是不適用的。要讓一個嵌入式設計方案成功必須遵行下列原則，如(圖二)：

《圖二　嵌入式設計必備的條件》

共享並非照顧

幾乎每個剛進到幼稚園的小孩總是會在內心掙扎是否要分享他們的玩具。如果有某個學生在一年後還不願分享玩具，他的老師應該會很煩惱是否是自己教育失敗。但是資源共享在嵌入式軟體方案中是最危險的動作。如果真的想把設計方案好好完成，請務必自私點吧！

沒有任何一個嵌入式方案會採用時間表排程。要讓一個團隊在最短的時間內貢獻最多的產出就必須儘量減少文字交換。像多餘的公司會議、不相關的訓練課程、外部團隊聯誼等活動都會轉移整個團隊的注意力而危及到嵌入式方案的成功。不會有任何工程師期待員工大會更甚於和另一半去採購（有的話那就值得延攬進團隊）。這類活動會消降低整體方案的成效，因為這會轉移工程師對於解決難題的專注力。

有許多工程師在下班後心裡還會想著那些惱人的問題，而且常常只有在晚上6點到隔天早上8點之間才會有新的點子。而這些工程師往往會不安地再回頭檢查其設計方案，不管還有沒有問題。這類影響他們注意力的事都會以各種方式持續地影響到最終的成果。當面對層出不窮的問題與迫在眉睫的期限之時，還是要讓團隊全心全意地專注在手上的計畫。當方案結束進行收尾時，自然會有時間可以好好消遣娛樂，但在那之前，就請盡您所能地讓團隊專注於手邊的工作。這樣不但可以提昇成效，也能振奮工程師的士氣。

當團隊裡的菁英突然受到其他計畫（通常是問題重重的計畫）的「諮詢」時，就極有可能在不知不覺中分散掉團隊的重心。這種中途打斷別人的工作，婉轉的說法叫「多工」（multiplexing），私下叫「救火」，而打岔的人經常會懇求其他自尊心強且頭腦清醒的人接受一些荒唐的工作，並且必須公開表示這救援工作不會影響其主要計畫。在工程實務上要設計硬體來處理多工程序是很好，但在人力資源方面就非常不恰當了。讓您的工程師專注於一項工作就好，並且務必拒絕其他的協助要求（必要的話可以會議室中發頓脾氣表達不滿都行）。

別等著輪到你

在開始念幼稚園時，每位父母都會看到小朋友在剛開始加入團體活動時的驚惶恐懼。因為在上學前的過去五年來，這些小孩可能都一直是他們身邊一些大人關心的焦點，每項日常需求也都會適時地得到關照。但是現在突然有12個或20個和自己類似的人要搶著獲得一個老師的注意，對小朋友來說是多麼大的衝擊，而且過去常用來博取注意的老方法，卻剛好成為那些滿懷熱忱的老師想要壓制的事。排好隊，舉起手，等著輪到你，學校學到的良好相處之道，對嵌入式方案來說卻是大災難。

在嵌入式方案中，做決策絕不能安靜地圍著圈圈坐著舉手等待，設計工作絕不能讓你還能乖乖站著排成一列，安靜地等著輪到你。各項計畫方案必須要同時全速進行，因此計畫團隊就必須隨時準備好同時作出多項決策。當某個決策會牽連到設計中的其他部分時，這種作法就可能造成一些人的麻煩，但這也都是為了整個團隊要能同步處理問題的作法，運用團隊中跨功能性（cross-functional）的力量來排除多重假設（what-ifs）和不相關的因果關係。計畫絕不能用一個接一個的決策方式，因為要是這樣做的話，你就會發現排隊等著決策的事將沒完沒了。

當一個嵌入式處理器的作業要完成其指定的工作時，讓其排隊等待工作是絕對要避免的。嵌入式方案的工作無論大小都必須要分成多個執行緒（threads）與工作項目，也許是前景與背景作業之分，也許是有無商用即時作業系統（real-time operation system；RTOS）的協助之分。

每個部分如果都受到某些規則和預算的規範，則它們多少能被設計成獨立運作。試想海軍和空軍的特技飛行小組表演時，會先進行看似無規則的盤旋，接著以高速會合，並用近乎奇蹟的貼近距離讓彼此擦身而過。一項具備多個執行緒和工作項目的方案，經過縝密規劃後而各自作業時，整個看起來像毫無規則的運作，而執行交會時卻還能很順暢，絕無停止和等待其他工作結束的狀況發生，且每項工作能確實完成其任務，讓其他工作在適當的時候交會而不產生衝突。

在幼稚園所學到的是周遭的人在說話時別插嘴，讓他講完再發言，但在嵌入式方案設計中，插斷動作卻是一項有效率設計的基礎。若只為了完成工作，執行定期的插斷並不適當，但這也僅表示不善用插斷的功能而已。插斷是更有效率的多工設計之基礎，例如通訊裝置會靜靜地收集傳入的訊號位元組並將其存放在緩衝器中，直到前景工作準備要處理新指令時，就利用插斷方式通知處理器位元處理器已滿，而主處理器就會暫停現有工作，然後把該緩衝器的資料傳送到儲存緩衝器，接著再回頭繼續原來的工作。

別把任何已開始的工作都做完

我在幼稚園所學的最難的一課（不知是不是算有學到）就是每當開始做一件事，就得把它做完；或是用另一種常見的說詞，「有始有終」。又或許您曾經聽老師說：「你必須專心完成一件事後，再開始新的事。」請勿將這種思維模式帶入您的嵌入式方案中。

在嵌入式設計（也是人生的許多時刻）的實際狀況中，處理事情的第一種方法往往不是最好的，而且有時整個方案中確實有些要在一天內就要完成的事，這些方案很快地就會顯現本身就是分散的徵兆，而且可能需要繁雜的解決方案。因此，無論如何您面對選用方式無效的可能性，並且時時刻刻要檢視您的決定，直到證實這些方法確實有效為止。

在不得不用某種方法時，之後又毫無理由地換成另一種方法，這樣絕非是一項明智的作法。每個問題都有多種解決方案，因此有必要先收集數據以研擬一項特定的方法作為選擇，並且還要常常回顧這些數據和結論，當新的資料顯示有更好的方法或需要一個更好的方法時，才能確實加以掌握。要用實際數據證明每個方法的優點，而不是只用理論和假設。要注意千萬別一廂情願地陷於某個方法，而無視於有違原先前提的實際數據。

如此顯然有違「做完一件事後再開始另一件新的」，但當秉持務實的態度依照數據並自我檢視，而且張大眼睛觀察以隨時準備好迅速轉換方法，那就可以更快達到最終目標。雖然難以置信，但有經驗的嵌入式設計人員都很清楚，計畫最後20％的部分必定會佔去80％的時間，而一個拙劣設計的最後20％更會佔掉80％的週末。儘早明快地決定改變方法或許會讓人覺得許多原先的努力都白費了，但實際上要決定改變的時機是越早越好（而且當有人表示要改變也太晚了的時候，別忘了20/80的準則）。

不是每個人都能當總統

在美國，每個男孩女孩都會學到一個崇高且光榮的概念，就是只要立下志願努力去做就有機會美夢成真，包括晉升到最高執政位階。雖然現在可能不會有太多的父母希望小孩將來能當總統，但廣為接受的概念仍然是，只要有足夠的動機，每個人都可能在團體中擔任最高的職位。

在嵌入式設計方案中，這也是一項會引起重大災難的概念，因此必須徹底捨棄。儘管一些民主（讓每個人都能發聲）的政策很有用，因為來自更多觀點的其他更多意見將有利於勾勒特定問題的輪廓以及可能的解決方法，但是嵌入式設計卻無法在這類多數決的規則下運作，所以善意的獨裁會是比較好的手段。要有一個人做為決策者，而且不是每個人都具備擔任這項職務的能力。更何況也並非總是由最聰明的人出線，就像並非總是由最佳解決方案勝出是一樣的道理。

身為一個領袖，是唯一必須能承擔所有責任的決策者。這個人必須要能決定困難的決策（他會說：「我們採用A方法，我也會去說服管理團隊更改原訂計畫」），而且也要能收集資料並且能向團隊與其他世人說明採用這些決策的立基點（他會說：「我們需要發表這個版本作為試用版，並且告訴客戶關於XYZ的問題，這樣我們就能在ABC這項功能上得到更好反應」）。這類的決策有可能造成某些後管，但還是必須要有人站出來做出明確果斷的決定。

就像在一家經營成功的餐廳中不能有太多廚師一樣，因為終究只能有一個主廚，而其他廚師要做的就是接受這件事，而不是暗自相信說「如果我真的想成為主廚，我就能做到」。在緊急狀況時，不尊重領導者極可能付出生命的代價；這在嵌入式方案中也是一樣（那通常看起來像是一連串無止境的緊急事件），不過所付出的代價更長也更為緩慢。選擇一個領導者，與其共事，提供有用的資訊，並且尊重團隊每一份子的價值。如果還是堅持想當領導者，那就辦個俱樂部好了。

幼稚園學習還是有用，只是不適用於嵌入式系統實驗室中

讓我們面對現實吧！您的幼稚園老師也許會說：「你真糟糕！」，但嵌入式設計絕不像周期循環的時間一樣。您可以借用釘書機，但請保護好團隊資源；您可以在隊伍中耐心等待，但請在設計中填滿優先插斷及工作程序。好好完成在停車場中描述疏散出口的訓練演習，但請盡快終止無用的設計方法（或注定失敗的計畫）。鼓勵同事帶領公司的壘球、棒球或躲避球隊，但也要確定每個參與計畫的人都知道誰能投下決定的一票。如此一來將可以看到您的團隊成功地完成嵌入式設計方案。

---作者為Cypress Semiconductor PSoC嵌入式開發工具產品經理---