幼稚园是人从小开始学习与他人生活的第一个阶段。他们学到只要知道如何分享，即使一个玩具卡车、洋娃娃、故事书或拼图也足够让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嵌入式开发工具产品经理---