这篇文章，第一次看是好几年前，当时没有特别的感觉，现在随着项目越做越多，渐渐的有更深一层的感触，也愈发赞同原文的绝大部分观点了。

假设你是公司的高阶主管，为了缩减这一季的费用，来让损益表好看一点，以便于让你手上高额的stock option更值钱。因此你推行了费用删减计划，目标当然是瞄准最大宗的薪资费用啦。经过你睿智的决定，决定一律砍25%。此计划一出，果然尸横遍野，不但员工薪资费用立刻下降25%，还有许多员工纷纷递出辞呈。如此一来，削减费用当然获得了伟大的成果。这时候项目经理布鲁斯跑到你的房间。
布鲁斯：至高无上的主宰，我该怎么办？我手下最好的五个好手，柏德，强森，欧尼尔，马龙，跟乔登都提出辞呈了，这样下去，我们delay超级久的地雷项目一定会再度delay了。全知全能的老板，我该怎么办呢？
在这个性向测验回答『A.什么？五虎将全部都要走喔，那公司完了嘛，我也要辞职了。』的人，这种人缺乏正面积极的工作态度。只能当工程师，或是在组织图上完全看不到的基层职员。
回答『B.看来我错了。这个措施有一些不好的边际效应。可是这是每个主管都会犯的错。』的人，适合在香港努力拍武打片，到好莱坞当大明星；或是担任美国总统，找女实习生来退火。基本上这种人在市场上的前途大好，不适合在企业里面任职。
回答『C.我来找找公司里面还有谁可以解决这些问题，此外我会先试着把这些人好好谈谈，劝他们留下来。』的人适合当project leader(不是manager喔)，这些人会愿意拿比较少的薪水，挂一个很呆的头衔，就可以为公司卖命。是要努力利用的员工。
只有回答标准答案『D.我知道你有很多问题，不过，你有没有什么backup plan？』的人，才有资格担任公司的高阶主管。只有高手中的高手，主将中的主将才可以脸不红气不喘地，把他所创造出来的问题，丝毫不露任何痕迹地，推到部属的身上。
所以项目经理都应该为下列事情规划backupplan：
＊公司可能会遭到恐怖份子驾飞机进行自杀攻击，以致于整个项目小组成员全部殉职。而所有的sourcecode都随着大楼被炸毁了，完全没有备份。请项目经理想出如何在72小时之内，赶上原有的进度。
＊有三只怪兽正要入侵地球，可是无敌铁金刚的驾驶柯国隆先生已经接受了优退方案，所以不会继续在卡通片里面工作。因此现在只剩下木兰号可以防卫原子光研究所。可是木兰号的驾驶莎莎小姐，今天因为生理期疼痛不已，所以她请了生理假。为了宇宙的爱与正义与和平，请想出如何在没有驾驶的情况下，以两颗木兰号胸前的木兰飞弹击退三只凶狠的怪兽，以保卫全地球的安全。
好吧，有经验的人都知道，没有人会去做全部组员都罹难的这种backup plan。这多难写啊？大部分的plan，都是建立在有些人愿意留下来的假设上。软体公司如果要能长久发展，怎么让人才愿意留下来，会是非常重要的关键。
project做到一半，如果有关键人物要离开，剩下的人，通常就会开始一段刻骨铭心的旅程。当然，这是在这些人还愿意继续留下来的假设之下才会成立。做过项目的人都知道，任何一个成员，如果在事情做到一半的时候离开，接手的人即使花加倍的力气，都还不见得可以在原有的时间内把事情做完。
如果是这样的话，如何做好people management，让有才能的人可以放到适当的位置，并且愿意留下来，就应该是高阶主管最重要的任务。(作者注：后来我想一想，带领公司往正确的方向发展，可能会比这件事还重要一些。)
不过对于大部分的公司来说，people management都是很弱的一环。找不到适合的人才，找到了人又待不久，高流动率似乎是这个业界的常态。在优秀人才这么稀少的状况下，照理说要怎么样让这些优秀的人才发挥最大的功用，就应该是件很重要的事情。不过对于大多数的公司来说，在people management方面，做错的事情远比做对的多。因此我想在这章谈谈我所观察到大多数公司在于这方面，常见的一些问题。
＊＊压力越大，生产力越高＊＊
对于很多主管来说，压力跟生产力之间是成正比的。压力越大，生产力就越高，这就跟越用力拍打皮球，皮球就会反弹的越高是同样的道理。当然，逻辑能力比较好的人马上就会发现，把两件风马牛不相干的事，扯在一起模拟，这需要非常小的脑容量。还好对于大多数主管而言，这一点并不是问题。
在某次整个开发团队的statusreviewmeeting中，我们听到这样的对话。
吉娜：布鲁斯，我从你的statusreport中可以看到，你打算把上线的日期往后延两个月。可是我看你的team，根本下班时间一到人就都走光了，从他们的timecard看来，根本就没有人在加班嘛。你是不是该给他们一点压力？
布鲁斯：整个projectteam经过前一段时间的赶工，现在士气已经很低了。我并不想在这个时候给他们压力。
吉娜：乔安娜(客户部门主管)已经打电话告诉我，他们打算礼拜六日来陪你们加班。晚上还要帮你们准备晚餐，还要帮你们准备睡袋，这使我不得不正视这个问题。如果我们都没有人可以配合加班的话，他们一定认为我们的工程师没有纪律。俗话说的好，『没有功劳，也有苦劳，没有苦劳，也有疲劳。』如果乔安娜对我们有这样的期许，我们一定得要做出响应。这样虽然看起来project的delay已经是事所难免，可是最少在客户面前，我们还是可以表现出我们的专业与用心。
布鲁斯：好吧，我可能会安排大家轮流晚上留下来加班吧。礼拜六日我会自己到场凑人数…
吉娜：话也不是这样说，你还是要想办法多给他们一点压力啊，把生产力都给挤出来。
布鲁斯想，又不是在挤牛奶，如果牛已经没奶了，一直挤会被牛给踹死。更何况是人：…
从上面这个例子看来，当管理阶层找不到比较好的事来改善生产力时，就会倾向施加压力，让项目成员无止尽的加班。这样一来，即使到最后失败了，最少也死得比较好看一点。这通常就是主管们，会莫名其妙地施加压力最主要的理由。
我们小时候读古书，有读到一句话：『取法乎上，仅得乎中。』很多主管对于这句名言的解读就是，如果你把deadline设成一个不可能完成的时间，那么即使你没有达到这个完美的deadline，事实上也不会晚太多。根据同样的推论呢，只要我下定决心要成为一夜千次郎，即使我没有达到这样高的service level，还是可以顺利地晋升为一夜十次郎。
工程师天生就喜欢挑战。如果你详细观察工程师的生态，你会发现，任何时候你想要工程师主动去解决一个问题，只要宣称这个问题根本无解，或是说你找了非常多的高手，大家一点头绪都没有，真正够格称的上是工程师的人，就会卷起袖子，开始动手来解决这个问题。
因为工程师有这么奇怪的天性，所以很多主管就觉得『取法乎上』这种做法应该所以是很可行的。只要我宣称这个deadline是不可能达成的，就会有工程师愿意焚膏继晷的努力工作。通常会得到这样的推论：『如果我们施加压力，例如设定一个不可能的deadline，这样子一定可以产生激励作用。压力越大，生产力越高。』
关于这个问题，科学家尝试做过适度的电击是否会增加生产力的人体实验，不过在找不到愿意参加实验的自愿者之后宣告失败。在找不到人类的情况下，他们做了动物实验。电击老鼠以后，的确会跑的比较快，不过会有一个副作用是老鼠也会死的比较快。
关于施加压力是否可以增加生产力，历史上也有很多例子。比较有名的例子算是韩信的背水一战，士兵因为不想掉到河里而努力作战，结果后来就打赢了。很多主管也认为可以效法这种做法，所以通常就会在原本已经艰困的环境下，制造更多的障碍。例如要求一个非常不适任的项目经理，来带领一个已经快要灭顶的项目。
然而结果通常是出乎他们意料之外。最常看到的结果是员工的辞职风潮像旅鼠的大规模迁徙一样。员工有了危机意识，发现苗头不对，绝对不会去想怎么样拯救公司，而是会开始去写履历表。所以你会发现许多主管会嚷嚷，怎么这年头年轻人一点抗压性都没有…
施加压力通常会有很短期的效果，生产力会迅速上升一阵子。问题是如果持续的施加压力，生产力就会降到一个稳定的水平。等到有人受不了时，生产力就会开始往下降。一直到有人受不了而离职时，团队的生产力就再也回不来了。
<智力测验>现在有一个大型的project正进行到一半，然而此时有关键人物正酝酿离职，请问剩下的工作会由谁分担呢？请问有能力找到更好的薪资待遇的人是否会愿意同甘共苦呢？
答案很简单，能力好有地方去的人早走了，只有没有地方去的人，或是平时就喜欢被滴蜡烛，被人用皮鞭抽打，具有自虐倾向的人，才会愿意留下来收尾巴。
当然施加压力还有另外一种做法。基本的想法，就是绷紧的弦容易断，所以要用的时候就要绷的很紧，不用的时候就可以放的很松。这个方法的好处是通常施压力只有一个很短的时间，所以会有一段生产力突然往上升的时期。最常施压力的时候，也是某个里程碑接近的时候，一旦达成某一个里程碑以后，生产力通常就会直线下降一阵子。一般而言，在这样项目下的团队可以存活比较久，可是如果当你开始严重落后进度时，一旦上紧发条，可能就只会越绷越紧。
我个人是觉得施加压力其实负面影响非常大。每个人的生活不会只有工作而已。你还有家庭、爱情、友情、健康…很多个层面要一起考虑。在工作上承受了过大的压力，以致于没有办法兼顾生活的其它层面。长久下来，员工一定会走人。
况且施压力在短时间内meet某一个milestone，通常会需要付出长期的代价。才会得到相同品质的产出。最常被缩减的时间是什么？测试。接着呢？答案是detailed design。这些流程的删减，通常可以让你在比较短的时间内，就把coding完成。要程序设计师交出一个长的很像可是骨子里全然不是那么一回事的东西，通常不是什么难事。Meet某一个milestone，可以让你有个像是系统的东西，来完成对于某些大头目的demo。可是接着要付出的代价通常都非常惨烈。做项目就像是跑一百公里的马拉松一样，才过了五十公里，就开始用百米冲刺的速度前进，一定会心脏病发。
当然，有些人会用这样的论点来推论。如果你这一百公尺可以保持这样的速度，那为什么你下一百公尺不能保持这样的速度。你应该要有discipline。如果你这两百公尺可以保持这样的速度，为什么你这一公里没有办法保持这样的速度？为什么你没办法整条路都保持这样的速度？好吧。听到这种话的话，deadline就会是你真正的死期了。先帮自己买个保险吧。你们项目在时间内做完的机率绝对比乐透中奖还要低。
＊＊数字管理＊＊
虽然数字不会说谎的，可是解读数字的人会。所以怎么引用正确的数字，推导出根本无关的结论，就是一门很高深的学问。
我们在估计项目大小，或是报价时，最常用的单位就是man-month。也就是一个人努力做事一个月的生产力。然而使用这个数字，却会有很多不好的效应发生。第一个就是直接会有人月=生产力的推论。
＊＊人月=生产力＊＊
对于很多使用者来说，如果项目进度delay了，最直觉的想法，就是要求加多一点人手。对他们来说，写程序就跟盖房子一样。大部分的客户都不知道要怎么盖房子，当然也不知道要怎么写程序，可是感觉起来，好象多找几个人，就会比较快一点。跟建筑业比较不同的是，客户通常还会希望能够找到几个比较强的人，希望透过这些人的加入，可以加速整个项目的开发。对于客户来说，人月是跟生产量成正比的。
软件虽然算是蛮新的工业，不过关于这方面的讨论，大概也有三四十年的历史了，毕竟scheduledelay，一直都是软件产业被人诟病的问题。很多学者做过研究，发现人月是跟生产量不一定会成正比。有些读过书的人，就会听过所谓的人月迷思：
『Addingmanpowertoalatesoftwareprojectmakesitlater.』
(作者注：引自Themythicalman-month.Chapter2page25)
简单的说，就是当project已经delay的时候，加人手不见得可以解决问题。主要的原因有几个：
1.新人需要时间学习才能上手
2.新人一开始参与的时候，会需要对这个系统有经验的老手来加以指导，这会减少老手投入开发的时间。
3.人数增加后，沟通的成本会呈几何级数地增加。
4.生一个孩子要花十个月，即使找来十个人，也不可能一个月就把小孩子生出来。
5.人数变多了，可是现在可以让他们做的工作一下子没有这么多，项目经理得要想办法生工作让这些人都有事做。这样子反倒会让项目经理没有心力专注在真正该做的事情上。
6.如果有人没事做，就会很害怕自己被裁员，就会做一些看起来像是工作的事情，或是做一些抵销别人工作的事情。
所以呢，有读过书的主管(或是有听过的也算)就会知道，增加人手只有对于那种人手超级不足的项目有效。这就是大名鼎鼎的人月迷思。所以呢不可以一开始就主张增加人手…即使要也是等到客户要求以后再说。
好吧，我们可以不要一昧地增加项目的成员数目，可是我们还是要针对项目进行规划啊，不然怎么估计出schedule与成本呢？所以通常就会先把现在有空，可能可以参与这个项目的人列出来，假设这些人都会参与这个项目。然后开始进行规划。
这下子问题来了，每个人工作能力都不一样。所以用人月来估计工作量怎么克服这种能力上所造成的生产力差异？有两个菜鸟，应该跟两个专家不一样才对啊。所以就会有人开始量化所有东西。例如超人的能力超强，所以他工作一个月，就会有十个人月的生产力；可是温蒂就不同了，她这么菜，工作能力这么差，工作一个月大概只有0.142857个人月的生产力。
结论就会是：如果超人没有办法接这个案子，我们就找十个凡人来就好了。
你可能会argue，超人这种大师，绝对拥有自己独到的创见与充分的经验。毕竟一个莎士比亚这样的天才，不是十个凡人加起来就可以取代的。
没错，不过这表示你没有掌握管理这门艺术的精髓。
吉娜：超人，我知道你很忙。没有办法全程参与这个案子。可是我们现在已经火烧屁股了。我想了很久，我想要麻烦你每天，抽出半个小时的时间，来教导这十个平庸的programmer。我不求他们有你一半的功力。你可以把你一甲子的内力传输给他们一点点，只要他们每个人有你十分之一的功力就可以了。我想你每天再花一点点时间指点一下他们的迷津，就可以让他们用十个人的力量，来弥补你没有办法join的生产力。
超人想，我要花多少时间，才能让每个人都有我十分之一的功力啊？可是…我还能说什么呢？：臣当鞠躬尽瘁以谢先主知遇之恩。
主管最常用的手法，就是让超人在各个项目之间流浪，想尽办法把他榨干。于是乎久而久之，宇宙间就会又多了一个累死的诸葛亮。主管常做的事情，就像是不让莎士比亚自己去写作，而是找十个二流的作家，要求莎士比亚去教导他们，期待他们在分工合作之后，可以写出相同的文章。
你觉得好笑吗？数字可是不会说谎的喔。
用数字来表示生产力，最大的问题就是人的生产力被一个数字来代替，完全没考虑到团队中比较人性的层面。布鲁斯跟大卫合得来，可是布鲁斯就是跟尚恩合不来。人与人之间长久工作的默契，以及因为相处以及共同的信念所产生的化学作用，都会影响一个团队的整体表现，这些东西都很难用数字来量化表示。
另一个问题就是人月会跟成本化上等号。
人月=成本
对于很多懂会计的人来说，他们可能没听过Themythical man-month。可是每个人每个月要领薪水，员工的户头会多一笔钱，公司的户头会少一笔钱，这是千真万确的事实。所以人月就会等于成本。
项目人力总成本=Σ项目成员月薪*支薪月数
一增加人手，项目成本马上就提高。所以除非增加人手可以让项目开发加速，降低支薪的月数，否则项目成本一定直线飙涨。
既然随着信息的发达，所谓的人月迷思已经被很多信息业界的主管听到了，所以呢，他们已经在实务上研拟出一套还没听说有什么不好的对策。
这套对策通常包含下列两个步骤：
＊增加每天上班工作时间
＊将非工作日改成工作日。
这个策略的假设在于『增加项目成员的工作时间，能够生产出来的有效产出也会随之增加。』用简单的话来说明就是：『想尽办法操死现在这几个鸟人，要他们无止尽的加班，就可以把进度给赶上。』
台湾大多数的软件公司，都会宣称是采取责任制，通常还会伴随着不是很严苛的打卡制度。这个制度的特点就是公司会宣称他不在乎你一天工作几个小时，只要你把事情做完就可以离开公司，所以不会有任何加班费。接着你的老板会给你一天绝对做不完的工作。然后要你在一天之内把事情做完。所以一天工作十几个小时是家常便饭。
另外一个策略，则是会想办法要求你假日到公司加班。有些主管会采取温情攻势，有些则是采用高压政策。反正就是威胁利诱，要员工无偿到公司加班。
这个策略对于老板来说，显而易见的好处就是
1.不会有人数增加后，沟通的成本增加的问题。因为被操的都是同一票人。
2.没有需要训练新人的问题，也没有任何老手的时间被浪费在训练上。
因为有无偿加班这回事，每天工作二十小时，就算后面这十个小时产出只有原先的一半，那也有十五个小时的产出。所以只要逼员工加班，支薪月数应该可以降低，所以成本可以下降。
这种做法无异是杀鸡取卵，可是通常都要等到大牌中的大牌，被工作压得粉身碎骨，只好提出辞呈后，才会有人出面摸摸头。要你不要工作的太辛苦。毕竟在软件公司里，大多数人的真正价值，只有在他提出离职申请时才会显现出来。你只要还没有想走的念头，都不会是一个值得头痛的issue。
当然有人不会单单从加班费来思考，而会从另外一个层面来推论：如果我们可以用便宜的人员来开发，一定可以减少开发的经费。
吉娜：布鲁斯，听说大陆的薪水大概只有台湾的五分之一。CEO已经指示日后我们的项目要全部outsource到大陆去。这样一定可以降低我们的开发成本…
异地开发的坏处很多，即使现在internet非常发达，很多事情不在同一个办公室，大家对于工作的态度与品质的看法不同，就是一个很难跨越的鸿沟。然而大多数人，只看到遍地便宜的劳工，异地开发的成本，常常会被严重地低估。开发软件需要非常紧密的沟通。异地开发可以省下来的费用，可能是要拿很多无形的东西做代价。表面上看起来公司会因此而赚到钱，可是除了有形的人员出差到另一个国家要花的旅费与薪资加给以外，花在彼此沟通的时间与经费，花在架设相同的开发测试环境的精力，这些被派到异地出差的人，可能会受不了长途跋涉就有了离职的念头，或是开发时间因为异地开发以至于拖长了好几倍的时间…这些不良的效应，常常都会被忽略。
另外一个负面的效应，则比较少被提到。如果外国的工作者会抢现在公司里面成员的饭碗，现在你所雇用的这伙人，心里面会做何感想？Hello，外国人，欢迎来抢我们的饭碗？更不要提一旦项目出现状况，出现在两地之间的争吵，诿过，相互攻讦…
除了使用便宜人力来异地开发以外，另一个常常有的推论如下：
如果员工没有处于忙碌状态，这等于是公司花钱请他来当大爷。这就会造成资源的浪费，这个员工简直就是在抢公司的钱。所以每个人必须在上班时间内，随时处于忙碌状态。
结论通常就是：Keep everybody busy。（待续）
Keep Everybody Busy
——————
吉娜：布鲁斯，我看那个温蒂，上班时间一直在玩ICQ，下班时间一到人就跑得跟飞的一样？这样不行喔。布鲁斯心想，温蒂不是在写操作手册的吗？系统根本就没有写好，她要忙什么？况且她已经去支持总机啦。：我会跟温蒂好好讨论这个问题。吉娜：我们不允许有人idle。公司的财务这么吃紧，每一分每一毫都要妥善运用。如果有一个人idle在那里，公司等于就少了一份生产力。这样我们怎么对股东交代呢？
我小时候也觉得这种理论是正确的。领人家薪水，本来就要在上班时间鞠躬尽瘁嘛。所以要让每个人都要发挥最大的生产力。问题是经验越多了以后，就越不这样认为。我通常看起来最没有生产力的时候，都在思索一些可以改善生产力的问题。有些时候花太多时间去做，就会花太少时间去想。此外，对于最没有生产力的员工来说，你最没有办法找事情给他们做。因为什么事情他都做不好。
为了要让这些人不处于idle状态，你要找个有经验的人来带他。结果就跟找个人背个六十公斤的沙包去跑步一样。沙包是会跑了，可是终究是个沙包，一放下来就不会动了。那也就算了。问题是这个背沙包的人就会铁定跑不快。跑久了还会阵亡。所以有些时候，让没有能力的人闲着，其实对于整体生产力是有帮助的。况且如果manager的重点都摆在怎么让这些没有生产力的人发挥生产力上面的话，他就不会有时间花在怎么让这些有生产力的人可以工作的更好，更愉快。这对团队会是好事吗？我不这样认为。
另外一个keep everybody busy的坏处在于公司会试着同时接下超出他产能可以负荷的工作。以追求每一部份的资源运用的最大化。因为工作总会有要交接的阶段，软件开发尤其是如此。分析做完了做设计，设计做完了以后就写程序写测试个案。系统分析师写完分析文件交给下一关以后，就会比较空闲。通常我们就会帮他另外找事情做。所以通常就会有很多个项目同时在进行。
为了要不让任何resourceidle，如果有一个项目的schedule发生变化，就会有人暂时没事做。所以通常就会接下超过现有人员可以承受的项目，这样就可以确定任何时候，每个人都有事情做。所以呢，我们就会有一个超出我们产能的需求要去满足。而resource就会随着工作的进度变得纷乱，到最后变成严重不足。
Resource不足时，你就会让比较贵的人力去做比较廉价的工作。所以高阶主管变成要自己等候在复印机前面去影印，因为没有工读生可以使唤。
在有工读生的年代，影印一张纸的成本等于租复印机的成本摊销，加上工读生的薪水。现在影印一张纸的成本，等于租复印机的成本摊销，加上昂贵工程师，甚至是高阶主管的薪水。这好象怎么算都不划算。问题是在资源不足的情况下，这种事情总是一而再再而三的发生。而我们从损益表上，只会看到砍掉了一个工读生的薪水。因为那些砍不掉的人，薪水会一直挂在损益表的费用部分。至于他们领薪水做什么事情，这不是损益表关心的重点。
Keeping everybody busy的最后一个坏处在于multi-tasking：
「一个人在同一时间内，要处理多个不同的工作。」
Multi-tasking
————-
开发软件其实是一种经过思考然后消化的活动。一个人必需要花时间去了解并思考目前所面临的问题，依照你的经验，去整理你的想法，最后以各式各样的模型，还是程序语言，来描述这个转化的结果，才能顺利地找出解决方案。这跟做爱差不多，你需要培养情绪，经过前戏爱抚之后，加上身体健壮与感官刺激双重配合之下，才能顺利地做完你想做的事情。
然而对于某些关键的工作来说，我们常常会需要某个重要的超人参与项目的开发。问题是超人通常都忙着拯救世界，所以多半只能在很短的时间内，蜻蜓点水地帮忙一下，或是指点一下迷途的羔羊。这个时候问题就来了，对于客户来说，如果发现超人只是偶尔拯救一下地球，马上就会有不断的抱怨。
如果一个应召女郎，跟客人办事到一半，忽然说：『对不起，我要转台，隔壁桌来了另外一个老主顾。』就硬生生地中断这个快乐的过程，跑去接待另一个客人。你想这个客人会高兴吗？还会高兴地付你钱吗？有经验的人告诉我们，最少你也要完成一整个回合，才可以抽身。否则等你回来时，双方还得要重新培养情绪，才有办法继续办事下去，更不用提心里的那股不爽了。
然而在许多软件公司里，就是不停地上演这出戏码。他们先打着美女的招牌，要求比较好的价码，等到要办事时，再派一个年华老去的大姊来陪你。每次客户问美女在哪里？软件公司就把美女找来坐坐台。这也就算了，更狠的是，他们还要求客户准时付美女加上大姐的坐台费。
对客户而言，这种软件公司，就好象拿了钱，可是跟你做到一半就落跑的小姐一样可恶，等到下一次机会来临的时候，又需要经过漫长的前戏，才可以挑动已经冷却的情欲，这不是令人十分不悦吗？
即使是对于公司内部的开发团队来说，老实说，也是同样受伤害。只是内伤在心里，外表看不太出来。对于这些想要聆听教诲的项目成员来说，才刚开始觉得有一些领悟的时候，佛祖就跑去别家弘法了。下次相逢，已是千载以后。这样子怎么了悟呢？
所以呢，我们不能忽略项目成员的转换成本。一般人要把心思转换到可以很快地学习超人的想法，是需要一点前置的准备时间，还好除了超人以外，其它人的时间其实都可以浪费。所以这些凡夫俗子可以花比较多的时间调整心态，做好接客─不是，是学习的准备。平时多多研读经书，佛祖驾临时，可能会比较容易顿悟。
然而对于超人来说，难道他就不需要任何调整与准备吗？或许偶尔几次的转换，是不需要太多的前置作业时间来准备。可是如果你让他同时在多个项目之间游走的话，还想要一直维持高昂的生产力的话，这就跟要求一个男人需要连续来个十次，中间还不能有任何低潮一样地不可能。更不要说这些项目可能会散布在不同的地点，同时接太多专案的话，他有可能会需要从一个地点赶着到另外一个地点去，光是这
些交通时间累积起来，就会是相当可观的资源浪费。
另外一个严重的影响是在于整体的等待时间。超人没空时，其它人就得等。其实不只是超人所负责的工作，有些工作只要一delay，project铁定就会delay，像这种工作都是等不得的。所以只要这些工作一有些闪失，项目的开发时间就一定会拖得很久。接着整个项目的开发成本，一定就会跟火箭一样一飞冲天。
问题是如果一个人同时间接了很多工作，很容易就会因为分身乏术而拖垮其它项目的进度。例如某甲可能有A、B、C三个项目的工作。每个工作都要做10天。他做了项目A5天以后，B这个项目的PM跑来找他，要他赶快去做B。所以他就做了B项目5天。接着是C项目的PM也来找他，要他帮忙C项目解决问题。所以他就做了C项目5天。接着项目A的PM就跑来追杀他，他就再花5天把A项目做完，同样的戏码上演下去，他花5天把B项目做完，接着再花5天把C项目做完。
让我们看看项目经理对于schedule的估计会死在哪里。每个项目的PM都想，如果某甲可以专心一志地去做的话，只要10天就作完了。问题是现在A花了20天才做完，B花了20天才做完，C也花了20天才做完。依照常理来说，有哪个PM会抓这么高的buffer吗？项目A的PM可能会想，我抓个10%的buffer，所以这件事情应该可以花11天做完。项目B的PM可能想是12天，项目C的PM可能抓了15天。好吧，结果是每个项目都会delay。这还是在每件工作没有转换成本的考量下喔。某甲并没有偷懒，可是每个项目都会delay。
所以现在我每次听到『你要花15%的时间在项目A，30%的时间在项目B，55%的时间在项目C…』的这种说法，就想要打哈欠。数字是不会说谎啦，不过隐藏在数字后面的理论真的是对的吗？这样做下去，真的可以work吗？
我小时候在学校里面学软件工程时，压根儿没听过multi-tasking对于项目会有多大的危害。直到到了职场以后，才开始领教到50%在项目A，25%在项目B…的这种说法。这种分配资源的想法，对于大多数主管来说，是非常直觉的，毕竟我们从小就是第一堂课上国文，第二堂课上英文的这样子长大。我想此刻在台湾的某个项目资源分配会议上，一定还是会听到类似的说法。可是符合直觉的事情并不一定是对的。
multi-tasking对于项目推行时的副作用，实在是不容忽视。我蛮好奇为什么在软件工程或是项目管理的课程里面，居然会忽略了这么重要的一个课题。
然而除了multi-tasking以外，我们还想了很多办法，来浪费员工宝贵的时间。那就是：
「把员工的时间浪费在没有意义的事情上面。」
把员工的时间浪费在没有意义的事情上面
————————————-
会计：布鲁斯，你们部门的那个欧尼尔，已经两个礼拜没有填time card了，这样不行喔。
布鲁斯：不好意思啦，我会赶快催他填。
布鲁斯：欧尼尔，你已经两个礼拜没有填time card了。赶快写一写。
欧尼尔刚好写程序写到一半，忽然被电话中断了思绪：喔。好。
五分钟后，欧尼尔把上上个礼拜的time card copy一份，日期改一改，送给了布鲁斯。布鲁斯：欧尼尔，你上上个礼拜四不是有请假吗？还有你上个礼拜不是有出差到台中吗？而且你charge的projectcode都填错。
欧尼尔：Sorry，sorry。你把它退给我。
欧尼尔花了三十分钟，仔细check他的email信箱，回想这两个礼拜的行程，填好了timecard、假单、出差申请单、差旅费报销单，还把相关的收据通通都贴好，送给了布鲁斯。欧尼尔被打断了以后，大概花了一个小时，一天以后，这些东西跑到了会计部。
会计：布鲁斯，你在差旅费报销单那里签错位置了。你拿回去叫欧尼尔重写一张啦。
布鲁斯：不好意思啦，我会赶快处理…
衙门越多，官僚习气就越重。我怀疑现代会计的基本假设，就是『每个员工都有可能当贼，所以需要内部仔细地稽核。』当组织越庞大，里面的官僚越害怕没有事做会影响工作保障时，就会努力设计出各式各样的表格，五花八门的单据，以免你做了一件僭越身分地位的事情。于是乎，即使是一件小事，也会是每个部门都要会，每个主管都要签。
当然，这也常常是因为政治上摆不平。每个主管，都深怕与他同级的竞争者，会接触到什么他不知道的信息，而会因此取得升官发财的秘诀，所以一定都会想要在决策的过程中参一脚。
所以你用高薪请来的程序设计高手，还有专业经理人，就会拿他们宝贵的时间，可能是一个小时好几千块钱的代价，为了公司一定会发给他们的三五百块，在那里填写单据或是签名盖印章。而这样做的公司，通常还会对于他们内部控制制度的严谨，感到洋洋得意。
另外一种时间杀手就是开没有意义的会。公司一大，分权分的越散，就会有越多人来争取管辖权，人一多开会是很没有效率的。特别是主管。有些主管凡是遇到不是他所负责的业务，总喜欢提供良心的建议，厉害的地方在于这些建议通常可以悖离逻辑，违反常理。根据我的经验，只要人一多，就一定会有人扮演这种神奇的角色。此外，大公司常常会找来没有决定权的人开会。看起来有决定权的人，又常常没有肩膀，就会屈服于更上一层的压力。
布鲁斯：关于网站的风格，我想请教一下贵公司是否有特定的想法？
西恩(IT部门主管经理)：为了争取时效，我想你们先做三种版面给我们挑，我们会在下个月的主管检讨会议中，找时间请高阶主管背书。
两个礼拜后，第一次检讨会议会前会。
西恩：你们做的这三种版面我看了觉得不喜欢，我想请你们的网页设计师再设计几个比较活泼的版面。
布鲁斯：可是这是依据你们现有的网站风格设计出来的啊？
西恩：我们现在的网站被人骂得乱七八糟的。你们还比照这个？你们要做这种决定之前，要先问我啊。请你们的网页设计师换一个比较生动的颜色。
布鲁斯：好吧，下个礼拜就是检讨会议了。我会请网页设计师加班改出新的版面出来。
西恩：辛苦你们了，我们三天后再开一次会前会。我会找使用者方面的主管琳达，还有我老板洁西卡列席。
三天后，第二次检讨会议会前会。
琳达：这是什么东西啊？你们怎么用了这么花俏的颜色？
布鲁斯：这是依照西恩的建议，我们希望可以用比较活泼的颜色。
西恩：我只是建议而已，你们应该依据你们的专业发挥啊。
琳达：这跟我们现在公司的其它网站风格根本就没有align在一起。洁西卡，你觉得呢？
洁西卡想，我应该想办法罩一下西恩，不然场面不好看。对了，公司好象有另一个部门有类似的规定：我记得公司的跨部门网站标准订定小组，应该已经定义出一份我们公司都应该遵循的网站风格标准。西恩，你是否有提供给vendor参考？
西恩：我并不知道有这份标准文件。
洁西卡：下回在做决定之前，可以先来问我。你可以去找跨部门网站标准订定小组的乔依思讨论。我回头把她的email寄给你。
西恩：布鲁斯，那就请你们依照那个标准来设计网站的新风格。
布鲁斯：……..有标准可以遵循当然是最好的啦。(他XX的，有这种东西不会早一点拿出来？)检讨会议当天。
大头甲：这个字体怎么这么小？
布鲁斯：这是依据跨部门网站标准订定小组所订定的标准所设计出来的。
大头甲：我们这些人年纪大了，都有老花眼了，这字这么小看不见啦。
大头乙：对了，你们这个画面怎么还要卷动啊？我们这些老头子要用鼠标这样拉啊拉的，很不习惯也。尽量把内容都放在一个画面里面嘛。
洁西卡：对啊，对啊。这个叙述怎么折行了？你们应该把字段拉宽一点嘛。
大头甲：你在点这个，我看看。好，你鼠标不要动。好，这个鼠标不要动的时候，是不是可以出现什么提示的画面？告诉人家这个功能在做什么嘛。
布鲁斯，可是在我们所拿到的标准里面是禁止这样的做法啊。
大头甲：这样子啊，洁西卡，你回头帮我call个meeting，我来跟哪个小组的成员好好讨论讨论。
洁西卡：没有问题。
大头甲：布鲁斯，这个功能的提示你们先照着做，我们开完会以后，再告诉你这个结果是什么。
大头乙：现在不是很流行什么Flash吗？你们要不要加个动画？
大头甲：对啊，我们可以…….
会场陷入了对于动画效果的讨论，大家各自表述自己喜欢的动画。过了半小时。终于结束了这个会议。所以布鲁斯带着需要把字放大，字段加宽，可是不可以卷动，并且还要加入最新的动画效果的决议回去。
网页设计师丹尼尔：这怎么可能？我们怎么可能把字变大，字段变宽，可是又不要卷动画面呢？
布鲁斯：我也这样说啊，可是他们说，这是你们的专业，你们这么专业的网页设计师一定可以办得到的。
丹尼尔：是啊，我还会让红海的海水分开哩。…
隔了一个月，大头们的老大，带头大哥来看这个系统了。
带头大哥：这个画面怎么开这么久？
布鲁斯：这个是因为上次开会决定要做flash动画，让我们的画面更生动活泼一点。
带头大哥：拿掉。我们这是跟供货商之间信息交换的平台，做这么多花俏的东西做什么？况且我们的供货商的频宽都很有限啊。
大头甲：大哥您真是英明。
大头乙：布鲁斯，我们只是要你们增加一些比较好看的效果，可没有叫你们要做出这么大的档案啊。布鲁斯，你们是这个行业的专家，应该知道不可以使用太大的档案来占用网络的频宽啊。
布鲁斯：可是Flash檔的size本来就会比较大啊，要做动画一定就会有这样的结果啊。
大头甲：我们又不是专家，你应该highlight这个issue啊。
布鲁斯：…….
利用让部属开无用的会议，接着再用推翻部属会议的共识，来证明自己的高瞻远嘱，思虑周密，似乎是许多高阶主管调剂办公室生活的最佳娱乐。类似这样的决策过程，可能在现实生活中屡见不鲜。
我曾经在八卦杂志上看过这样的报导，唱片公司的企划人员，为了帮新人取一个响亮的艺名，经过多次内部开会讨论，最后终于提供给老板三个建议。结果老板去找他最喜欢的算命先生，另外取了三个名字，由老板的小老婆从算命先生的建议里面，挑一个最喜欢的，这样子就成了新人的艺名。接着艺人大红大紫，还一再感谢算命先生的神机妙算。
不过这还不是最糟糕的状况。最惨的状况是参加那种跨国的会议。某些大公司特别迷信国外飞过来的consultant。所以在开会的时候，就会请consultant莅临指导。毕竟外国人有洋枪有洋炮，除了人高马大，船坚炮利以外，大脑可能也会大一点。因此开会的时候，就会有人先用中文交谈，接着为了让大脑比较大的外国人也了解会议的内容，就会有人用生硬的英文解释，接着又有人认为这个翻译的人翻译的不好，就会用更生硬的英文来解释前面的人所说错的地方，最后consultant大概了解状况以后，就会提出他认为最专业的建议。
不过因为consultant通常经过层层转述以后，不是非常了解来龙去脉，所以他的建议通常就是吃这行饭的人，从小时候开始就已经听烂了的废话。接着呢，就会有状况外的人，把consultant的废话，当成是神谕。为了避免大家的英文太糟糕，就会用中文把consultant的英文再翻译一次。接着还会有人继续指正中文的翻译。好吧，这种状况光用写的手就打字打的很酸了，还要继续讲下去吗？
这种会开久了，可以忍住不打瞌睡的人，可以考虑到联合国上班。每次遇到这种状况时，通常我就是负责对话的主角。每次开完这种会议，都会觉得寿命大概折损一半。
另外一种常见的时间杀手就是过多的文件。SA要写analysis document，SD要写design document，programmer要写批注，tester要写test case，test result跟test report，project manager要写各式各样的plan，report，以及meeting minute；每个人每个礼拜都要写status report，timecard…
软件业可以说是专门生产文件的工业。生产没有人有能力看的文件，以及订定无聊的标准，要求各式各样的文件，并写制作没有力气跟着最新的功能同步更新的文件，就变成了这个业界的常态。在大多数的公司里，真正必要的文件可能都没有人去写，可是不必要的文件可能会汗牛充栋。而已经写出来的文件，大多数都跟不上版本更新的速度。所以内容通常是在描述历史上的某一天。而不同的文件，可能讲的刚好是不同天。所以文件与文件之间，很有可能彼此之间还会串不起来。
当然，有很多程序设计师就是厌恶写文件。必要的文件，对于项目的开发绝对会有帮助。生产不必要文件所花费的时间，会吃掉撰写必要文件的时间。所以在大多数的场合里，必要的信息总是被不小心遗漏了，可是不必要与过时的文件，却会一而再再而三地淹没在我们的硬盘中。
有人说过：『错误的决策，比贪污更可怕。』对于资源的不当运用，确实是许多软件公司最大的问题。然而大多数时候，即使你觉得这样的措施不好，你可能还是觉得自己没有能力改变这一切。要根除multi-tasking，得要建立多大的共识基础？要减少施加不当的压力，高阶管理者要更改多少行为模式？要除去无用的数字管理，得要教化多少腐朽的大脑？要尊重员工的时间，需要多么成熟的工作态度？这些都不是容易做到的事情。所以主管们通常能做的就是采取柔性的诉求，例如
＊鼓吹团队精神
＊激励
＊以身作则
鼓吹团队精神
———–
打造一支钢铁劲旅，并不是一件容易的事情。不过对于很多主管来说，他们可以打的牌并不多。公司的人就是那么多，找来找去就是那么几个鸟人，所以呢，只能把几个人硬凑在一起，组成一个杂牌军。通常找人的状况不外乎如此：
＊＊在某次的资源调度会议上＊＊
布鲁斯：这个project我现在还需要5个programmer，coding3个月，测试4个月。
还需要3个tester。
吉娜：看来我们现在人力吃紧。布鲁斯，你有没有什么建议？
布鲁斯：programmer的话，欧尼尔跟史托雅柯维奇现在有空，我已经问过了。
我还需要3个人，我想要找布莱恩、韦柏跟诺威思基帮忙。
杰克森：不可能，布莱恩最少还要在我的project三个月。
尼尔森：诺威思基最少也还要两个月才会从现在的project离开。这还是乐观的状况。
艾德曼：韦柏也不行，他已经提出留职停薪，他打算去动膝盖的手术。他膝盖自从上次受伤以后一直没好。
布鲁斯：那怎么办？我们还要不要做这个project？
吉娜：有了，听说最近刚进来有个叫做艾佛森的工读生还不错。
布鲁斯：可是我们上次从波士顿找来的那个工读生华克，根本就不中用啊，会不会有同样的状况？况且说只有艾佛森，这样也才只有一个人啊。
吉娜：那先让艾佛森顶这个位置。尼尔森，你要诺威思基一个月之内加班把那个案子结掉，不要那副表情给我看。有问题，我负责处理客户那里。已经上线这么久的案子，没理由我们要继续support这么久。杰克森，布莱恩只能留一个半月。
杰克森：不行啦，最近这个案子要上pilotrun，布莱恩不在，会出大纰漏。
吉娜：对喔，布鲁斯，布莱恩看起来是走不掉了。这样吧，不然你先把艾佛森放在你的projectorganization里面，我们再找三个工读生进来。我联络一下华克。
布鲁斯：我不要华克啦，他根本就不能算是一个developer，顶多算半个人。不过我倒是听说他同学皮尔斯还不错啦。
吉娜：那你把华克、皮尔斯、跟艾佛森放到project organization里面，这样加上欧尼尔跟史托雅柯维奇，你就有五个人了。如果诺威思基可以加进来，这样就有六个人了。
布鲁斯：可是华克、皮尔斯、跟艾佛森都是工读生。这三个人顶多算一个半，加上诺威思基我也只能算半个，这样还差一个人。
吉娜：有了，我找一下马龙好了。他前一阵子想离职，我去劝劝他，请他再多帮忙这个案子。
布鲁斯：如果马龙能来那就太好了。那我只剩下tester有问题…
很多时候，如果讨论已经变成了谁是一个programmer，谁只能当半个，这种组队的方法，大概也组不出什么梦幻团队。
由于可用之兵有限，每个人的才智又有所不同。所以很容易就有劳逸不均的状况。主管如果对于每个人的能力了解又不清楚，就会把不对的人放到不对的位置上。接着能做的通常是：
＊＊在某次项目的kickoffmeeting上＊＊
布鲁斯：我们的项目，有很多人都是初次合作，包含了华克、皮尔斯、跟艾佛森，他们都是各国立大学的高材生。我想我们一定要请大家相互配合，发挥团队精神…
＊＊一个月后的项目进度检讨会议上＊＊：
布鲁斯：马龙，看样子这些年轻小伙子还要麻烦你多指点一下。
马龙：那个华克，根本整天都在混，整天在哪里混时间，不晓得在干什么。还有艾佛森，做事情莽莽撞撞，不照规矩来。上次还不小心盖掉我写好的档案，还好我local有备份。
布鲁斯：马龙，既然我们是个team，你又资历这么深，就只好多麻烦你帮忙啦。我们现在在同一条船上，你就发挥一下团队精神，帮他们一把，我看皮尔斯还不错。
马龙想，发挥团队精神也没领比较多钱，谁还管这些人这么多：是啦，这个小子还不错。不过可惜可以来的时间有限。
布鲁斯：是啊…
又过了一个月。
艾佛森：那个布朗在画的是什么图啊，根本整个设计都不对，我们的功能才会有这些问题。他到底懂不懂UML啊？
马龙：这跟UML一点关系都没有。布朗写的spec已经够清楚了，整个东西会写错都是因为你没有跟其它人好好讨论合作的关系。
艾佛森：你怎么可以这么说？这样说一点都不合理。我要求你向我道歉。
布鲁斯从桌子底下踢了马龙一下，看了马龙一眼，求他先闭上嘴：艾佛森，你先把你找到的问题列出来，现在布朗不在，单单听你这么讲，我们根本也不知道事情到底真相是什么。我只知道tester找出了很多问题，而这些程序都是你写的。这不一定是谁的问题，可是我得要知道我们该怎么解决现在面对的状况。现在你先整理出来你发现的问题。
艾佛森不发一语地走了出去，大力地关上了门。马龙：布鲁斯，你为什么不让我讲话？
布鲁斯：为了维持团队的和谐啊。马龙，我知道你一直都是对的，可是你这样子会让场面变得很僵。只好请你相忍为国了…
大多数人对于团队的想法，其实都深受军教片之害，那种要绝对服从命令，誓死效忠，一个口令一个动作的团队，其实在现实生活是不太容易存在的。大多数团队，都有那种好说话的人，跟不好说话的人。
好说话的好好先生其实跟个单细胞生物差不多，原则上他们会信奉『君要臣死，臣不敢不死』的这种理念。所以只要跟他们鼓吹一下『要有团队精神！』，『牺牲小我，完成大我』『成功不必在我』这种观念，就愿意配合进行不可能的任务。
不好说话的人通常都自认才高八斗，当然实际上并非总是如此。这些人的特点就是原则很多，不愿意配合。所以通常鼓吹团队精神只会被他们嗤之以鼻。我比较建议先吹捧几句以后，再使用激将法。大凡自视甚高的人，多半都受不得激。
鼓吹团队精神，在企业内部通常就是把不好说话的人所推托出来不想做的事情，交到好说话的人身上。这好象不是什么很好的分工方式吧。
另外一个常有的想法就是要维持团队的和谐。好象所有的冲突都不可以浮到台面上来，以免影响每个人对于团队的信心。事缓则圆、相忍为国是这类主管常挂在口上的名句。
这不禁使我想起很多黑帮电影。在很多这类型的电影里面，两个帮派之间起了冲突，通常就是为了要抢地盘。对砍了一阵子以后，常常会有很多黑道大哥出来讲情，要大家卖他们一个面子，一笑泯恩仇。不过看了这么多电影，还没看过有哪两个帮派真的就从此风平浪静。
为了强调团队的和谐，变成乡愿俱乐部，其实带来的坏处远大于好处。他只会鼓励人把事情掩盖下来，而不是去寻找真正的答案。我个人觉得冲突是每个团队成员彼此利害关系不同，必然会有的结果。问题不在怎么压制冲突的发生，而是在冲突产生时，怎么样可以找到一个解决的方法。不过对于大多数的主管来说，要人家卖他一个面子，好象比真正解决问题来得省事多了。
反正我已经请你们要互助合作了，你们没有团队精神，怎么能怪我呢？
团队精神其实是需要长时间的相处以后才会产生的。人并没有办法plug&play，即使可以，你在声卡后面接屏幕，画面绝对还是一片空白。我个人觉得，项目经理需要制造彼此互助合作的机会。怎么把对的人放在对的地方，再让这些人可以慢慢融合成为一个团队，绝对是一个软件项目经理人的首要任务。光是讲几句要有团队精神，大家要同舟共济，这是无济于事的。
此外，站在组织的立场上来说，我们对于团队合作到底提供了什么实质的奖励？如果只是『我们在下一次调薪时，会考虑这个因素。』或是颁发几张优秀团队奖状，其实诱因远不及发给奖金、股票、认股权来得有效。如果没有实质的奖励，团队的成功与个人丝毫无关，这样子的话，人们怎么会有动机想要协助团队的成功呢？　　　（待续）
激励
—-
对于工程师无效的激励方式，我还真知道不少。
＊工程师喜欢新科技以及训练，远超过金钱
＊考绩
＊肉麻当有趣
＊想当年…
＊Vision、MissionStatement…
工程师喜欢新科技以及训练，远超过金钱
—————————————————————
布鲁斯：最近projectteam的士气有点低落。
吉娜：那我们来个内部训练好了。我请佛祖来开示一下好了。
布鲁斯：这倒也是可行。什么时间比较恰当呢？要不要用礼拜三下午四点？
吉娜：不要占用上班时间。我想就是礼拜天下午四点开始好了。大家可能会早一点到，还可以加班…
工程师先天就充满了好奇心，喜欢尝试新东西，试试看他所了解的新玩意儿。只要有新的东西发表了，例如某某标准，或是新的工程技法，某个软件的新版本，新的程序语言…他们都有兴趣去了解一下。
对于很多主管来说，这好象就代表了工程师喜欢新科技以及训练远超过金钱。所以讲到要激励员工，通常最直觉的想法，就是来个训练吧。为了要省钱，最好还是利用周末还是晚上的时间，做个内部教育训练，让老鸟来带菜鸟。
其实工程师受了训练，接受了新科技，不是为了现在看得到的薪水，就是为了将来转换新工作可能会获得的加薪。基本上都跟金钱可以画上等号。当然不可以排除有些人会纯粹想要科技上的进步，跟智力上的发展，不过这种人大部分会留在学界，开发一些不切实际的东西。对于一般职场上的工程师来说，如果在追求技术上的创新之余，可以顺便多赚点钱，应该是没有人会反对的。
考绩
—-
布鲁斯：奇德，我知道这一阵子你已经很忙了，可是这个案子现在看起来赶不上进度，我想得要请你礼拜六日都到公司来加班。
奇德：什么？去年我才因为加班太久，心情不好打老婆出气，结果上社会新闻。你还要我假日过来加班？你是想要让我老婆再变成沙包吗？老实说，这个案子会拖这么久，都是史考特一开始没有调度好。
布鲁斯：唉，史考特的调度有问题，这个我们都知道。不过他现在人也走了，就不要再扯这一段了。这样子吧，虽然我们没有加班费，可是你的配合度这么好，今年打考绩时，我一定会记得会好好补偿你。
大多数人有关打考绩的经验，就跟要他们不穿衣服，赤裸裸地站在台上接受检验差不多。大多数的人会这么紧张的原因，主要是在于他们误解了这件事情进行的方式，以为考绩跟他们一整年的表现有关。其实大多数的主管也是视打考绩如畏途，所以多半都是凭着印象，随随便便交差了事。如果一年打一次考绩，通常越接近打考绩时候的表现，会越具有影响力。
如果你只能拿考绩来激励员工的话，其实指的就是你并没有提供其它实质的鼓励。所以只好给他一个可能可以升官发财的梦。这种激励通常对于菜鸟会比较有用。对于老鸟来说，只要被骗个一两次，就会学乖了。
肉麻当有趣
———-
布鲁斯：邓肯，这个案子现在真的要靠你大力帮忙了。除了你，没有别人有办法…
对于某些母性比较坚强的主管来说，激励员工跟哄小孩差不多。所以通常会用对于这个年龄层的人来说，会显得有些恶心的话，企图激励员工。听到这些话，我常常会鸡皮疙瘩掉满地。
:『你是最棒的。』(是啊，要不要给我一个乖宝宝贴纸？)
:『公司要是没有你，那该怎么办？』(还是会活的好好的啊。)
:『只有你才办得到。除了你，没有别人有办法。』
(这连白痴都办得到。是你只叫得动我。)
:『我们公司是从哪里找来像你这么优秀的员工？』
(是啊，可是怎么会领这么少的薪水呢？)
当老板信奉这一套时，你就会多了几个肉麻的朋友，只要他心血来潮，就会时时拍出奇怪的马屁。如果他跟你不熟还装熟时，这就会更尴尬了。他会问候你的家人，成长的环境…然后彻彻底底地把这些信息遗忘。
布鲁斯想，我应该要关心一下小组成员，对了，应该问候一下他的家人：邓肯，你说你太太是在做什么的？
邓肯：我太太在学校当老师。
布鲁斯：当老师，哪很好啊。有寒暑假可以放。工作一定很轻松。
一个礼拜后。
布鲁斯(完全忘记他曾经问过任何问题。)：邓肯，你太太是在做什么的？
邓肯也忘记被问过这个问题：我太太在学校当老师。
布鲁斯：当老师，那很好啊。
又过了几天。
布鲁斯想，得要了解一下项目成员的家庭背景：邓肯，你结婚了吗？
邓肯想，你不是最近才问过我吗：我太太没有换过工作啊，她还在学校里面当老师。
布鲁斯想，咦，难道我问过这个问题而且忘了？不妙，赶快转移话题：喔。你这个礼拜进度怎么样。
当然，有时你会遇到真正很棒的主管。他会清楚记得你的生日，你老婆的职业，你的嗜好，以及你女儿的音乐发表会，而且他还会尊重你家庭生活的时间。不过，在信息产业中，这种主管跟凤毛麟角差不多。
想当年…
会采取这种奇怪的激励方式的人，通常也是各类教条的爱护者。例如『天下没有不是的父母』、『玉不琢，不成器』、『棒头出孝子』…。依照出生年代的不同，通常会有下列不同的夸大版本。
远古时期：『现在的年轻人啊，一点儿苦都吃不得。想当年，蒋委员长领导我们抗战的时候。(这时候要立正站好)那时候，我们整天在重庆被日本鬼子轰炸。常常防空洞一躲啊，就是一个星期。日本鬼子一炸啊，就是一个星期。一整个星期没阖眼啊，要换你们现在的年轻小伙子，我看早就不行啦。你看你们这些人好命的哩。现在不过是加个班，就一副没担当的样子，要遇到战争啊，我看你们只能举双手投降了啦。』
中古时期：『现在的年轻人啊，一点儿苦都吃不得。想当年，我们要读书啊，是历经千辛万苦。每天打着赤脚上学，便当盒里面就装着白饭配着萝卜干，晚上念书没钱可以点电灯，还要去抓萤火虫，萤火虫不够亮还要把墙壁挖个洞跟隔壁借点光。每次要注册了，就要跟街坊邻居借钱去缴学费。你们这些年轻人啊，一点挫折都受不了。不过是加个班嘛。要知道，有班可以上已经多好啦。现在谁不去大陆啊，大陆的人工这么便宜，每个工程师都很拼。听说他们一天睡不到一个小时，只要有钱赚啊，二十几个小时都在工作。你们不学学人家，将来怎么跟他们比啊。遇到大陆的工程师啊，我看你们是铁定失业。』
近代：『现在的年轻人啊，一点儿苦都吃不得。想当年，我们要跑程式啊。还得要把程序都打在卡片上。光compile啊，就要排队等个一两天。拼错一个字啊，就要再等个一两天。哪像你们现在这么方便？按个键等一会儿程序就compile好？你们真是身在福中不知福啊。现在要写程序已经比我们那个年代好太多了。你看看你们写出来的那是什么程序嘛，bug一大堆。』
现代：『现在的年轻人啊，一点儿苦都吃不得。我们前几年在做那个人事薪资系统，要上线前啊，大家整整三个月，每天工作十八个小时，早上八点出门，晚上两点回家。不夸张喔，整整三个月，包含礼拜六礼拜天。现在你们不过是一天工作十四五个小时，还不到一个月，就一直哇哇叫，一点抗压性也没有。你们不知道，比起我们当年啊，实在是好命的太多啦。』
基本上呢，这种激励的方式呢，就是先告诉你一个父母双亡，无力葬父，只好委身青楼的弱女子悲惨故事，希望你能够觉得你的命，其实比别人都好。让你明白，别人这么惨都没去跳楼了，你不过是因为加班时间太多，没时间陪老婆，因此跟老婆吵架的小小个人际遇不算是什么。接着就是要告诉你，在以往那个年代，有一些人，即使身处逆境，也会跟逆流而上的小鱼一样努力往上游，才会完成伟大(？)的成就。你应该效法这种精神，为公司做牛做马。所以礼拜天加班，请务必准时到达。不过身为管理阶层的我呢，有更重要的事情要思考，所以就不奉陪啦。毕竟我已经苦了那么多年，媳妇熬成婆，总该轮到我享清福吧？
我是不知道有多少人会被这种故事激励啦。古人悲惨的故事，当做是上班时候的消遣，听听当然无妨，这就跟看连续剧的意思是差不多的。不过如果我是当事人，切身的问题绝对还是比较重要。女朋友生气，男朋友翻脸，小孩子认不得爸爸，都会比加班赶进度来得重要。况且大多数时刻，长时间加班的效率其实都非常低落。如果一个项目经理不能认清楚这一点，只是一昧地要求team member长期加班，只是看到工作时间延长，好象生产力也跟着增加的假象，总有一天会尝到高流动率的恶果。
Vision,MissionStatement…
—————————–
有些企管顾问非常强调Vision，MissionStatement…这些东西的功用。他们觉得，如果我提出一个宏观的vision(愿景)，并且很清楚地告诉每个员工整个公司的missionstatement(公司宗旨。我个人觉得比较像是任务的宣言)，员工会受到宏观愿景的吸引，而愿意做出超高品质的工作。
这种顾问举出来的例子，通常是某某公司因为有了伟大的愿景，因此整个公司的人都受到这种伟大愿景的指引，愿意牺牲奉献努力工作，最后终于获得前所未有的成功。
原则上呢，我觉得成功的公司拥有解释历史的权利。他们想要让成功看起来比较理所当然一点，找些理由来为自己的脸上贴金也是很正常的现象。
我在不少公司待过。每一家都是立志要成为世界上第一流的企业。每家公司的愿景，大概都是像这个样子：『我们要集合世界上一流的人才，开发世界上一流的产品，然后拿着吸尘器到世上每个人的口袋大吸特吸，直到所有钞票都被我们吸光为止。接着要拿我们赚来的钱的百万分之一，出来造桥铺路做善事顺便抵税。』按照企管顾问的说法，因为我们有捐款助人的那个部分，员工就会被这种世界大同的伟大使命所吸引，然后受到前所未有的激励，就愿意无偿地长时间加班。例如卖彩券的公司都会强调买乐透可以帮助社会资源重新分配，彩券盈余还会提拨出来做社会福利，这样员工就会忘记他们是在鼓吹赌博，而是在从事一项崇高的行业。
选定一个方向，做客户要的东西，并且努力保持自己的竞争力，其实是企业要获得成功的不二法门。没有一家公司，是因为vision太差，所以员工士气低落，导致生意太差，因此关门倒闭的。然而很多经营阶层，一直认为勾勒出一个远大的愿景，是一件很重要的事情，所以要一直努力地跑到风光明媚的山川之间去闭关苦修，才有办法画出一块很大的大饼。
然而对于大多数的公司来说，欠缺的其实不是一块大饼。而是怎么去让这个梦想实现的执行能力。与其拿一个遥不可及的梦想企图激励员工，不如拿实际成功的成绩来激励士气。这世上还有什么比『成功』更能激励士气呢？或许是因为对于这些主管来说，要获得成功的经验太过困难了吧。
以身作则
——–
对于很多主管来说，管理就是要以身作则。所以担任主管的人，要第一个到，最后一个走。我小时候看军教片，那种铁血班长，跟魔鬼士官长，就是以身作则的最佳模范。然而军教片看起来很好的东西，现实生活可不是如此。例如现在我们已经不玩『消灭万恶共匪，解救苦难同胞』这一套了。
很多具有同理心的项目经理，总会觉得大家都在忙，我不可以在旁边休息，我应该比大家更忙才对。所以开始到各地去招揽工作。菜鸟经理常常犯的毛病，就是做自己熟悉的事情。我原本是系统分析师出身的，就继续坐着经理的位置，做系统分析的事情。我原本是写程序出身的，就继续坐着经理的位置，写我想写的程序。特别是当做这个工作的人，做得没有我好时，就更有理由这么做了。毕竟会被升上经理，不会是没有原因的。问题是，当你在身先士卒以身作则时，谁在运筹帷幄呢？当你在努力写程序时，谁在做项目经理呢？
真正的管理，其实不是在于要项目经理做个全能的人，team member看到你很辛苦，确实会认同你的辛劳，不过他们更需要的，是一个可以倾听他们的问题，接着帮他们找资源来解决问题的人；是一个知道该做什么，并且会适切地调度资源的人；是一个可以引领方向，带他们走出重重包围的人。
当你专注在某个工作，而非整个项目时，那么负责那项工作的人，是头一个受害的人。接着受害的，则是整个项目的团队。
结论
—-
大多数的软件公司主管，会花很多时间去招募新人。因为他们认为员工会有高流动率，是一种很正常的事情。因此他们的重点，一直都放在怎么去找到市场上最好的新人。相形之下，花在怎么让现有人力运作的更好，怎么让员工更喜欢这个工作环境的精力上，就显得少的可怜。
软件开发是一种高度需要思考的工作。安静的环境，足够的办公空间，以及采用良好的开发工具，确实可以提高开发工作的效率。然而，减少multi-tasking，以及采用正确的开发流程，并且减少不必要的文件，对于效率的助益可能会更高。
有没有什么比较简单的原则呢？我个人觉得，要能真正的提高效率，你得要先尊重每个人的时间。不要花太多的时间，去做不必要的事情。把事务性的工作，尽量地找行政管理人员帮忙处理。找个工读生来帮工程师填写假单，处理所有要申报的费用，影印所有要打印的文件吧。每次会议要先规划议程，没有必要，不要让每个人从头到尾参与一个会议，先想想这个人出现在这里，有没有什么必要性。没必要的话，就放他先回去工作吧。只有你尊重每个人的工作时间，才能真正打造出一个有效率的团队。
不过，项目经理并不能只把心思专注在效率上。怎么样打造一个适才适所，运作平顺的团队，并且保持高昂的士气，才是项目成败的关键。老实说，我觉得只有每个人都赢的策略，才能获取这样的成果。
有什么策略会每个人都赢呢？让我来教你。
简单的说，针对你现在所有的项目，每个项目依据项目的难易程度，提拨一份项目结案奖金。项目可以顺利结案，发给一笔奖金。如果专案是在预定的时间内完成，就发给另一笔奖金。奖金的金额怎么定呢？对于项目结案奖金，我建议直接从项目总价中抓一个百分比即可。例如，如果项目可以结案，就发给项目成员项目总价的10%做为结案奖金。
至于在预估时间内完成的项目，要提供的奖金，其实也可以用项目总价的固定百分比来算。不过对于那些已经做到一半，而且还没有结案的案子。我个人建议的方法如下：
(预估最糟的结案日期–预订完成日)/2*所有成员的薪水
这里面当然会牵涉到『预估最糟的结案日期』『预订完成日』这个日期怎么得来的。还有这个日期是否需要随着项目的状况进行调整…等问题。我个人认为，这些日期都问主管即可。
预估最糟的结案日期：如果这个项目到这天还没做完，你宁愿从现在开始就不要投任何人进去。
预订完成日：任何你认为合理，并且希望projectteam可以完成的日期。不过要注意如果这个日期完全不可行，那就会失去奖励的诱因。
其实，这只是一个建议而已，你可以依据实际项目的状况自己发挥。只要你把项目的成功，与一个有可能可以得到的奖励绑在一起，就会有一个很好的策略。
怎么样才能让优秀的员工想要长久地待下来呢？我想让员工拥有成功的经验，合理的待遇，良好的生涯规划，发挥才能的机会以及良好的团队气氛，都对于留住人才，有正面的帮助。
人力是软件公司最重要的资源。只有个人的发挥，与公司的成长可以密切地契合，软件公司才有生存成长的空间。找到好的人才，把他放到对的位置上，并且提供他必要的协助，让他愿意持续地为公司效力，实在是高阶主管最重要的工作。有梦虽然很美，可是强将手下如果都是弱兵，大概就只能做做白日梦了。楚汉相争，最后刘邦可以得天下，关键就在于他打造了一个优异的团队。没有优秀的团队，就没有良好的执行力；没有良好的执行力，再多愿景也是空谈。
话说回来，读这本书的人刚好是高阶主管的机率应该很低。所以对于大多数的问题，大概都只能默默地承受或是被动的因应，没办法做出什么前瞻性的思考或是积极的作为。没关系，耻笑老板的无能原本便是一种有趣的事情。如果你是个中阶主管，少做一些傻事，就会被少笑一些。如果你是个小螺丝钉，反正人太菜的话，天生就是要被欺负的，那就保持着愉快的心情继续嘲笑老板吧。我会在这本书剩下的部分，努力帮你保持愉快的心情。你只要负责嘲笑老板就好了。
运用数字来进行项目成本与时间的预估，本来就是最正统的做法。只是在估计的过程里面，所有的数字要建立在合理的假设上，在项目进行的过程中，如果要修正你的规划，就要随时检视你原先的假设是否合理。数字并不是代表项目管理的全部，它只是代表你对于一件事情要做多久，要花多少钱的一个推论。我个人觉得，我们应该要做的，并不是先建立一个推论，接下来就拿着这个推论来指引你全部的行为：
『你不是说这个问题，一个礼拜就可以解决了吗？』
『你不是说SIT只要三个礼拜吗，现在都已经过了两个月了。』…
计划应该只是当成是你在做事情时的参考，一开始规划好了，把要运用多少资源也规划好了，接着当你遇到实际的状况时，再慢慢修正你的计划。我总觉得，当项目过了起初planning的阶段，重点就应该放到team身上，teammember的士气，成员之间是否能够培养出共同开发的默契，是否把正确的资源，在正确的时间点，摆在正确的位置上…这些才是项目进行过程里面最重要的因子。除非你想写一个全部人员都阵亡的backupplan，否则所有项目进行过程中对于计划的修正，都应该建立在你对于现有团队的了解上，而不是直接拿预估人月除以开发人数得到开发时间。
当然，这样子做最大的缺点，就是把太多因素绑在主观的判断上，别人就没有客观的依据可以来判断这样的预测是否可行，也就没有办法进行control，或是riskmanagement。不过项目管理本来就一直在艺术与工程的两极中摆荡，那就看你要从哪一个角度来看待这些事情。当然，这就会跟软件公司要怎么样才会赚钱，或是项目的成败该用什么样的标准来衡量有关了。Well, that will be another story. (完)