独孤木专栏＞ People Management（中）

独孤木专栏＞ People Management（中）
Keep Everybody Busy
------------------
吉娜：布鲁斯，我看那个温蒂，上班时间一直在玩ICQ，下班时间一到
人就跑得跟飞的一样？这样不行喔。
布鲁斯心想，温蒂不是在写操作手册的吗？系统根本就没有写好，她要
忙什么？况且她已经去支持总机啦。：我会跟温蒂好好讨论这个问题。
吉娜：我们不允许有人idle。公司的财务这么吃紧，每一分每一毫都要
妥善运用。如果有一个人idle在那里，公司等于就少了一份生产
力。这样我们怎么对股东交代呢？
我小时候也觉得这种理论是正确的。领人家薪水，本来就要在上班时间
鞠躬尽瘁嘛。所以要让每个人都要发挥最大的生产力。问题是经验越多
了以后，就越不这样认为。我通常看起来最没有生产力的时候，都在思
索一些可以改善生产力的问题。有些时候花太多时间去做，就会花太少
时间去想。此外，对于最没有生产力的员工来说，你最没有办法找事情
给他们做。因为什么事情他都做不好。
为了要让这些人不处于idle状态，你要找个有经验的人来带他。结果就
跟找个人背个六十公斤的沙包去跑步一样。沙包是会跑了，可是终究是
个沙包，一放下来就不会动了。
那也就算了。问题是这个背沙包的人就会铁定跑不快。跑久了还会阵亡
。所以有些时候，让没有能力的人闲着，其实对于整体生产力是有帮助
的。况且如果manager的重点都摆在怎么让这些没有生产力的人发挥生产
力上面的话，他就不会有时间花在怎么让这些有生产力的人可以工作的
更好，更愉快。这对团队会是好事吗？我不这样认为。
另外一个keep everybody busy的坏处在于
公司会试着同时接下超出他产能可以负荷的工作。以追求每一部份的资
源运用的最大化。
因为工作总会有要交接的阶段，软件开发尤其是如此。分析做完了做设
计，设计做完了以后就写程序写测试个案。系统分析师写完分析文件交
给下一关以后，就会比较空闲。通常我们就会帮他另外找事情做。所以
通常就会有很多个项目同时在进行。
为了要不让任何resource idle，如果有一个项目的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的project code都填错。
欧尼尔：Sorry，sorry。你把它退给我。
欧尼尔花了三十分钟，仔细check他的email信箱，回想这两个礼拜的行程
，填好了time card、假单、出差申请单、差旅费报销单，还把相关的收
据通通都贴好，送给了布鲁斯。欧尼尔被打断了以后，大概花了一个小时
，一天以后，这些东西跑到了会计部。
会计 ：布鲁斯，你在差旅费报销单那里签错位置了。你拿回去叫欧尼尔
重写一张啦。
布鲁斯：不好意思啦，我会赶快处理…
衙门越多，官僚习气就越重。我怀疑现代会计的基本假设，就是『每个员
工都有可能当贼，所以需要内部仔细地稽核。』当组织越庞大，里面的官
僚越害怕没有事做会影响工作保障时，就会努力设计出各式各样的表格，
五花八门的单据，以免你做了一件僭越身分地位的事情。于是乎，即使是
一件小事，也会是每个部门都要会，每个主管都要签。
当然，这也常常是因为政治上摆不平。每个主管，都深怕与他同级的竞争
者，会接触到什么他不知道的信息，而会因此取得升官发财的秘诀，所以
一定都会想要在决策的过程中参一脚。
所以你用高薪请来的程序设计高手，还有专业经理人，就会拿他们宝贵的
时间，可能是一个小时好几千块钱的代价，为了公司一定会发给他们的三
五百块，在那里填写单据或是签名盖印章。而这样做的公司，通常还会对
于他们内部控制制度的严谨，感到洋洋得意。
另外一种时间杀手就是开没有意义的会。公司一大，分权分的越散，就会
有越多人来争取管辖权，人一多开会是很没有效率的。特别是主管。有些
主管凡是遇到不是他所负责的业务，总喜欢提供良心的建议，厉害的地方
在于这些建议通常可以悖离逻辑，违反常理。根据我的经验，只要人一多
，就一定会有人扮演这种神奇的角色。此外，大公司常常会找来没有决定
权的人开会。看起来有决定权的人，又常常没有肩膀，就会屈服于更上一
层的压力。
布鲁斯：关于网站的风格，我想请教一下贵公司是否有特定的想法？
西恩(IT部门主管经理)：为了争取时效，我想你们先做三种版面给我们挑
，我们会在下个月的主管检讨会议中，找时间请
高阶主管背书。
两个礼拜后，第一次检讨会议会前会。
西恩 ：你们做的这三种版面我看了觉得不喜欢，我想请你们的网页设计
师再设计几个比较活泼的版面。
布鲁斯：可是这是依据你们现有的网站风格设计出来的啊？
西恩 ：我们现在的网站被人骂得乱七八糟的。你们还比照这个？你们要
做这种决定之前，要先问我啊。请你们的网页设计师换一个比较
生动的颜色。
布鲁斯：好吧，下个礼拜就是检讨会议了。我会请网页设计师加班改出新
的版面出来。
西恩 ：辛苦你们了，我们三天后再开一次会前会。我会找使用者方面的主
管琳达，还有我老板洁西卡列席。
三天后，第二次检讨会议会前会。
琳达 ：这是什么东西啊？你们怎么用了这么花俏的颜色？
布鲁斯：这是依照西恩的建议，我们希望可以用比较活泼的颜色。
西恩 ：我只是建议而已，你们应该依据你们的专业发挥啊。
琳达 ：这跟我们现在公司的其它网站风格根本就没有align在一起。洁西卡
，你觉得呢？
洁西卡想，我应该想办法罩一下西恩，不然场面不好看。对了，公司好象有
另一个部门有类似的规定：我记得公司的跨部门网站标准订定小组，应该已
经定义出一份我们公司都应该遵循的网站风格标准。西恩，你是否有提供给
vendor参考？
西恩 ：我并不知道有这份标准文件。
洁西卡：下回在做决定之前，可以先来问我。你可以去找跨部门网站标准订
定小组的乔依思讨论。我回头把她的email寄给你。
西恩 ：布鲁斯，那就请你们依照那个标准来设计网站的新风格。
布鲁斯：……..有标准可以遵循当然是最好的啦。(他妈的，有这种东西不
会早一点拿出来？)
检讨会议当天。
大头甲：这个字体怎么这么小？
布鲁斯：这是依据跨部门网站标准订定小组所订定的标准所设计出来的。
大头甲：我们这些人年纪大了，都有老花眼了，这字这么小看不见啦。
大头乙：对了，你们这个画面怎么还要卷动啊？我们这些老头子要用鼠标这
样拉啊拉的，很不习惯也。尽量把内容都放在一个画面里面嘛。
洁西卡：对啊，对啊。这个叙述怎么折行了？你们应该把字段拉宽一点嘛。
大头甲：你在点这个，我看看。好，你鼠标不要动。好，这个鼠标不要动的
时候，是不是可以出现什么提示的画面？告诉人家这个功能在做什
么嘛。
布鲁斯，可是在我们所拿到的标准里面是禁止这样的做法啊。
大头甲：这样子啊，洁西卡，你回头帮我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，time card…
软件业可以说是专门生产文件的工业。生产没有人有能力看的文件，以及订
定无聊的标准，要求各式各样的文件，并写制作没有力气跟着最新的功能同
步更新的文件，就变成了这个业界的常态。在大多数的公司里，真正必要的
文件可能都没有人去写，可是不必要的文件可能会汗牛充栋。而已经写出来
的文件，大多数都跟不上版本更新的速度。所以内容通常是在描述历史上的
某一天。而不同的文件，可能讲的刚好是不同天。所以文件与文件之间，很
有可能彼此之间还会串不起来。
当然，有很多程序设计师就是厌恶写文件。必要的文件，对于项目的开发绝
对会有帮助。生产不必要文件所花费的时间，会吃掉撰写必要文件的时间。
所以在大多数的场合里，必要的信息总是被不小心遗漏了，可是不必要与过
时的文件，却会一而再再而三地淹没在我们的硬盘中。
有人说过：『错误的决策，比贪污更可怕。』对于资源的不当运用，确实是
许多软件公司最大的问题。然而大多数时候，即使你觉得这样的措施不好，
你可能还是觉得自己没有能力改变这一切。要根除multi-tasking，得要建
立多大的共识基础？要减少施加不当的压力，高阶管理者要更改多少行为模
式？要除去无用的数字管理，得要教化多少腐朽的大脑？要尊重员工的时间
，需要多么成熟的工作态度？
这些都不是容易做到的事情。所以主管们通常能做的就是采取柔性的诉求，
例如
＊鼓吹团队精神
＊激励
＊以身作则
鼓吹团队精神
-----------
打造一支钢铁劲旅，并不是一件容易的事情。不过对于很多主管来说，他们可
以打的牌并不多。公司的人就是那么多，找来找去就是那么几个鸟人，所以呢
，只能把几个人硬凑在一起，组成一个杂牌军。通常找人的状况不外乎如此：
＊ ＊在某次的资源调度会议上＊ ＊
布鲁斯：这个project我现在还需要5个programmer，coding 3个月，测试4个月。
还需要3个tester。
吉娜 ：看来我们现在人力吃紧。布鲁斯，你有没有什么建议？
布鲁斯：programmer的话，欧尼尔跟史托雅柯维奇现在有空，我已经问过了。
我还需要3个人，我想要找布莱恩、韦柏跟诺威思基帮忙。
杰克森：不可能，布莱恩最少还要在我的project三个月。
尼尔森：诺威思基最少也还要两个月才会从现在的project离开。这还是乐观的
状况。
艾德曼：韦柏也不行，他已经提出留职停薪，他打算去动膝盖的手术。他膝盖自
从上次受伤以后一直没好。
布鲁斯：那怎么办？我们还要不要做这个project？
吉娜 ：有了，听说最近刚进来有个叫做艾佛森的工读生还不错。
布鲁斯：可是我们上次从波士顿找来的那个工读生华克，根本就不中用啊，会不会
有同样的状况？况且说只有艾佛森，这样也才只有一个人啊。
吉娜 ：那先让艾佛森顶这个位置。尼尔森，你要诺威思基一个月之内加班把那
个案子结掉，不要那副表情给我看。有问题，我负责处理客户那里。已
经上线这么久的案子，没理由我们要继续support这么久。杰克森，布莱
恩只能留一个半月。
杰克森：不行啦，最近这个案子要上pilot run，布莱恩不在，会出大纰漏。
吉娜 ：对喔，布鲁斯，布莱恩看起来是走不掉了。这样吧，不然你先把艾佛森
放在你的project organization里面，我们再找三个工读生进来。我联
络一下华克。
布鲁斯：我不要华克啦，他根本就不能算是一个developer，顶多算半个人。不
过我倒是听说他同学皮尔斯还不错啦。
吉娜 ：那你把华克、皮尔斯、跟艾佛森放到project organization里面，这样
加上欧尼尔跟史托雅柯维奇，你就有五个人了。如果诺威思基可以加进
来，这样就有六个人了。
布鲁斯：可是华克、皮尔斯、跟艾佛森都是工读生。这三个人顶多算一个半，加
上诺威思基我也只能算半个，这样还差一个人。

吉娜 ：有了，我找一下马龙好了。他前一阵子想离职，我去劝劝他，请他再多
帮忙这个案子。
布鲁斯：如果马龙能来那就太好了。那我只剩下tester有问题…
很多时候，如果讨论已经变成了谁是一个programmer，谁只能当半个，这种组队
的方法，大概也组不出什么梦幻团队。
由于可用之兵有限，每个人的才智又有所不同。所以很容易就有劳逸不均的状况。
主管如果对于每个人的能力了解又不清楚，就会把不对的人放到不对的位置上。接
着能做的通常是：
＊ ＊在某次项目的kickoff meeting上＊ ＊
布鲁斯：我们的项目，有很多人都是初次合作，包含了华克、皮尔斯、跟艾佛森，
他们都是各国立大学的高材生。我想我们一定要请大家相互配合，发挥
团队精神…
＊ ＊一个月后的项目进度检讨会议上＊ ＊：
布鲁斯：马龙，看样子这些年轻小伙子还要麻烦你多指点一下。
马龙 ：那个华克，根本整天都在混，整天在哪里混时间，不晓得在干什么。还有
艾佛森，做事情莽莽撞撞，不照规矩来。上次还不小心盖掉我写好的档案
，还好我local有备份。
布鲁斯：马龙，既然我们是个team，你又资历这么深，就只好多麻烦你帮忙啦。我
们现在在同一条船上，你就发挥一下团队精神，帮他们一把，我看皮尔斯
还不错。
马龙想，发挥团队精神也没领比较多钱，谁还管这些人这么多：是啦，这个小子还
不错。不过可惜可以来的时间有限。
布鲁斯：是啊…
又过了一个月。
艾佛森：那个布朗在画的是什么图啊，根本整个设计都不对，我们的功能才会有
这些问题。他到底懂不懂UML啊？
马龙：这跟UML一点关系都没有。布朗写的spec已经够清楚了，整个东西会写错都
是因为你没有跟其它人好好讨论合作的关系。
艾佛森：你怎么可以这么说？这样说一点都不合理。我要求你向我道歉。
布鲁斯从桌子底下踢了马龙一下，看了马龙一眼，求他先闭上嘴：艾佛森，你先
把你找到的问题列出来，现在布朗不在，单单听你这么讲，我们根本也不知道事
情到底真相是什么。我只知道tester找出了很多问题，而这些程序都是你写的。
这不一定是谁的问题，可是我得要知道我们该怎么解决现在面对的状况。现在你
先整理出来你发现的问题。
艾佛森不发一语地走了出去，大力地关上了门。马龙：布鲁斯，你为什么不让
我讲话？
布鲁斯：为了维持团队的和谐啊。马龙，我知道你一直都是对的，可是你这样
子会让场面变得很僵。只好请你相忍为国了…
大多数人对于团队的想法，其实都深受军教片之害，那种要绝对服从命令，誓
死效忠，一个口令一个动作的团队，其实在现实生活是不太容易存在的。大多
数团队，都有那种好说话的人，跟不好说话的人。
好说话的好好先生其实跟个单细胞生物差不多，原则上他们会信奉『君要臣死
，臣不敢不死』的这种理念。所以只要跟他们鼓吹一下『要有团队精神！』，
『牺牲小我，完成大我』『成功不必在我』这种观念，就愿意配合进行不可能
的任务。
不好说话的人通常都自认才高八斗，当然实际上并非总是如此。这些人的特点
就是原则很多，不愿意配合。所以通常鼓吹团队精神只会被他们嗤之以鼻。我
比较建议先吹捧几句以后，再使用激将法。大凡自视甚高的人，多半都受不得
激。
鼓吹团队精神，在企业内部通常就是把不好说话的人所推托出来不想做的事情
，交到好说话的人身上。这好象不是什么很好的分工方式吧。
另外一个常有的想法就是要维持团队的和谐。好象所有的冲突都不可以浮到台
面上来，以免影响每个人对于团队的信心。事缓则圆、相忍为国是这类主管常
挂在口上的名句。
这不禁使我想起很多黑帮电影。在很多这类型的电影里面，两个帮派之间起
了冲突，通常就是为了要抢地盘。对砍了一阵子以后，常常会有很多黑道大
哥出来讲情，要大家卖他们一个面子，一笑泯恩仇。不过看了这么多电影，
还没看过有哪两个帮派真的就从此风平浪静。
为了强调团队的和谐，变成乡愿俱乐部，其实带来的坏处远大于好处。他只
会鼓励人把事情掩盖下来，而不是去寻找真正的答案。我个人觉得冲突是每
个团队成员彼此利害关系不同，必然会有的结果。问题不在怎么压制冲突的
发生，而是在冲突产生时，怎么样可以找到一个解决的方法。不过对于大多
数的主管来说，要人家卖他一个面子，好象比真正解决问题来得省事多了。
反正我已经请你们要互助合作了，你们没有团队精神，怎么能怪我呢？
团队精神其实是需要长时间的相处以后才会产生的。人并没有办法plug &
play，即使可以，你在声卡后面接屏幕，画面绝对还是一片空白。我个人
觉得，项目经理需要制造彼此互助合作的机会。怎么把对的人放在对的地方，
再让这些人可以慢慢融合成为一个团队，绝对是一个软件项目经理人的首
要任务。光是讲几句要有团队精神，大家要同舟共济，这是无济于事的。
此外，站在组织的立场上来说，我们对于团队合作到底提供了什么实质的
奖励？如果只是『我们在下一次调薪时，会考虑这个因素。』或是颁发几
张优秀团队奖状，其实诱因远不及发给奖金、股票、认股权来得有效。如
果没有实质的奖励，团队的成功与个人丝毫无关，这样子的话，人们怎么
会有动机想要协助团队的成功呢？　　　 （待续）