[转帖]People Management(再转一篇,有参考价值)

深蓝

People Management 假设你是公司的高阶主管，为了缩减这一季的费用，来让损益表好看一点， 以便于让你手上高额的stock option更值钱。因此你推行了费用删减计划。 目标当然是瞄准最大宗的薪资费用啦。经过你睿智的决定，决定一律砍25%。 此计画一出，果然尸横遍野，不但员工薪资费用立刻下降25%，还有许多 员工纷纷递出辞呈。如此一来，削减费用当然获得了伟大的成果。这时候 项目经理布鲁斯跑到你的房间。 布鲁斯：至高无上的主宰，我该怎么办？我手下最好的五个好手，柏德， 强森，欧尼尔，马龙，跟乔登都提出辞呈了，这样下去，我们delay超级久 的地雷项目一定会再度delay了。全知全能的老板，我该怎么办呢？ 在这个性向测验回答『A.什么？五虎将全部都要走喔，那公司完了嘛，我 也要辞职了。』的人，这种人缺乏正面积极的工作态度。只能当工程师， 或是在组织图上完全看不到的基层职员。 回答『B.看来我错了。这个措施有一些不好的边际效应。可是这是每个主 管都会犯的错。』的人，适合在香港努力拍武打片，到好莱坞当大明星； 或是担任美国总统，找女实习生来退火。基本上这种人在市场上的前途大 好，不适合在企业里面任职。 回答『C.我来找找公司里面还有谁可以解决这些问题，此外我会先试着把 这些人好好谈谈，劝他们留下来。』的人适合当project leader(不是manager 喔)，这些人会愿意拿比较少的薪水，挂一个很呆的头衔，就可以为公司卖 命。是要努力利用的员工。 只有回答标准答案『D.我知道你有很多问题，不过，你有没有什么backup plan？』的人，才有资格担任公司的高阶主管。只有高手中的高手，主将 中的主将才可以脸不红气不喘地，把他所创造出来的问题，丝毫不露任何 痕迹地，推到部属的身上。 所以项目经理都应该为下列事情规划backup plan： ＊公司可能会遭到恐怖份子驾飞机进行自杀攻击，以致于整个项目小组成 员全部殉职。而所有的source code都随着大楼被炸毁了，完全没有备份。 请项目经理想出如何在72小时之内，赶上原有的进度。 ＊有三只怪兽正要入侵地球，可是无敌铁金刚的驾驶柯国隆先生已经接受 了优退方案，所以不会继续在卡通片里面工作。因此现在只剩下木兰号可 以防卫原子光研究所。可是木兰号的驾驶莎莎小姐，今天因为生理期疼痛 不已，所以她请了生理假。为了宇宙的爱与正义与和平，请想出如何在没 有驾驶的情况下，以两颗木兰号胸前的木兰飞弹击退三只凶狠的怪兽，以 保卫全地球的安全。 好吧，有经验的人都知道，没有人会去做全部组员都罹难的这种backup plan 。这多难写啊？大部分的plan，都是建立在有些人愿意留下来的假设上。软 体公司如果要能长久发展，怎么让人才愿意留下来，会是非常重要的关键。 project做到一半，如果有关键人物要离开，剩下的人，通常就会开始一段 刻骨铭心的旅程。当然，这是在这些人还愿意继续留下来的假设之下才会 成立。做过项目的人都知道，任何一个成员，如果在事情做到一半的时候 离开，接手的人即使花加倍的力气，都还不见得可以在原有的时间内把事 情做完。 如果是这样的话，如何做好people management，让有才能的人可以放到适 当的位置，并且愿意留下来，就应该是高阶主管最重要的任务。(作者注： 后来我想一想，带领公司往正确的方向发展，可能会比这件事还重要一些。) 不过对于大部分的公司来说，people management都是很弱的一环。找不到 适合的人才，找到了人又待不久，高流动率似乎是这个业界的常态。在优秀 人才这么稀少的状况下，照理说要怎么样让这些优秀的人才发挥最大的功用， 就应该是件很重要的事情。不过对于大多数的公司来说，在people management方面，做错的事情远比做对的多。因此我想在这章谈谈我所观察 到大多数公司在于这方面，常见的一些问题。 ＊＊ 压力越大，生产力越高 ＊＊ 对于很多主管来说，压力跟生产力之间是成正比的。压力越大，生产力就越 高，这就跟越用力拍打皮球，皮球就会反弹的越高是同样的道理。当然，逻 辑能力比较好的人马上就会发现，把两件风马牛不相干的事，扯在一起模拟 ，这需要非常小的脑容量。还好对于大多数主管而言，这一点并不是问题。 在某次整个开发团队的status review meeting中，我们听到这样的对话。 吉娜 ：布鲁斯，我从你的status report中可以看到，你打算把上线的日 期往后延两个月。可是我看你的team，根本下班时间一到人就都 走光了，从他们的time card看来，根本就没有人在加班嘛。你是 不是该给他们一点压力？ 布鲁斯：整个project team经过前一段时间的赶工，现在士气已经很低了。 我并不想在这个时候给他们压力。 吉娜 ：乔安娜(客户部门主管)已经打电话告诉我，他们打算礼拜六日来陪 你们加班。晚上还要帮你们准备晚餐，还要帮你们准备睡袋，这使 我不得不正视这个问题。如果我们都没有人可以配合加班的话，他 们一定认为我们的工程师没有纪律。俗话说的好，『没有功劳，也 有苦劳，没有苦劳，也有疲劳。』如果乔安娜对我们有这样的期许 ，我们一定得要做出响应。这样虽然看起来project的delay已经是 事所难免，可是最少在客户面前，我们还是可以表现出我们的专业 与用心。 布鲁斯：好吧，我可能会安排大家轮流晚上留下来加班吧。礼拜六日我会自 己到场凑人数… 吉娜 ：话也不是这样说，你还是要想办法多给他们一点压力啊，把生产力 都给挤出来。 布鲁斯想，又不是在挤牛奶，如果牛已经没奶了，一直挤会被牛给踹死。更 何况是人：… 从上面这个例子看来，当管理阶层找不到比较好的事来改善生产力时，就会 倾向施加压力，让项目成员无止尽的加班。这样一来，即使到最后失败了， 最少也死得比较好看一点。这通常就是主管们，会莫名其妙地施加压力最主 要的理由。 我们小时候读古书，有读到一句话：『取法乎上，仅得乎中。』很多主管对 于这句名言的解读就是，如果你把deadline设成一个不可能完成的时间，那 么即使你没有达到这个完美的deadline，事实上也不会晚太多。根据同样的 推论呢，只要我下定决心要成为一夜千次郎，即使我没有达到这样高的 service level，还是可以顺利地晋升为一夜十次郎。 工程师天生就喜欢挑战。如果你详细观察工程师的生态，你会发现，任何时 候你想要工程师主动去解决一个问题，只要宣称这个问题根本无解，或是说 你找了非常多的高手，大家一点头绪都没有，真正够格称的上是工程师的人 ，就会卷起袖子，开始动手来解决这个问题。 因为工程师有这么奇怪的天性，所以很多主管就觉得『取法乎上』这种做法 应该所以是很可行的。只要我宣称这个deadline是不可能达成的，就会有工 程师愿意焚膏继晷的努力工作。通常会得到这样的推论：『如果我们施加压 力，例如设定一个不可能的deadline，这样子一定可以产生激励作用。压力 越大，生产力越高。』 关于这个问题，科学家尝试做过适度的电击是否会增加生产力的人体实验， 不过在找不到愿意参加实验的自愿者之后宣告失败。在找不到人类的情况下 ，他们做了动物实验。电击老鼠以后，的确会跑的比较快，不过会有一个副 作用是老鼠也会死的比较快。 关于施加压力是否可以增加生产力，历史上也有很多例子。比较有名的例子 算是韩信的背水一战，士兵因为不想掉到河里而努力作战，结果后来就打赢 了。很多主管也认为可以效法这种做法，所以通常就会在原本已经艰困的环 境下，制造更多的障碍。例如要求一个非常不适任的项目经理，来带领一个 已经快要灭顶的项目。 然而结果通常是出乎他们意料之外。最常看到的结果是员工的辞职风潮像旅 鼠的大规模迁徙一样。员工有了危机意识，发现苗头不对，绝对不会去想怎 么样拯救公司，而是会开始去写履历表。所以你会发现许多主管会嚷嚷，怎 么这年头年轻人一点抗压性都没有… 施加压力通常会有很短期的效果，生产力会迅速上升一阵子。问题是如果持 续的施加压力，生产力就会降到一个稳定的水平。等到有人受不了时，生产 力就会开始往下降。一直到有人受不了而离职时，团队的生产力就再也回不 来了。 <智力测验> 现在有一个大型的project正进行到一半，然而此时有关键人 物正酝酿离职，请问剩下的工作会由谁分担呢？请问有能力找到更好的薪 资待遇的人是否会愿意同甘共苦呢？ 答案很简单，能力好有地方去的人早走了，只有没有地方去的人，或是平时 就喜欢被滴蜡烛，被人用皮鞭抽打，具有自虐倾向的人，才会愿意留下来收 尾巴。 当然施加压力还有另外一种做法。基本的想法，就是绷紧的弦容易断，所以 要用的时候就要绷的很紧，不用的时候就可以放的很松。这个方法的好处是 通常施压力只有一个很短的时间，所以会有一段生产力突然往上升的时期。 最常施压力的时候，也是某个里程碑接近的时候，一旦达成某一个里程碑以 后，生产力通常就会直线下降一阵子。一般而言，在这样项目下的团队可以 存活比较久，可是如果当你开始严重落后进度时，一旦上紧发条，可能就只 会越绷越紧。 我个人是觉得施加压力其实负面影响非常大。每个人的生活不会只有工作而 已。你还有家庭、爱情、友情、健康…很多个层面要一起考虑。在工作上承 受了过大的压力，以致于没有办法兼顾生活的其它层面。长久下来，员工一 定会走人。 况且施压力在短时间内meet某一个milestone，通常会需要付出长期的代价。 才会得到相同品质的产出。最常被缩减的时间是什么？测试。接着呢？答案 是detailed design。这些流程的删减，通常可以让你在比较短的时间内，就 把coding完成。要程序设计师交出一个长的很像可是骨子里全然不是那么一 回事的东西，通常不是什么难事。Meet某一个milestone，可以让你有个像是 系统的东西，来完成对于某些大头目的demo。可是接着要付出的代价通常都 非常惨烈。做项目就像是跑一百公里的马拉松一样，才过了五十公里，就开 始用百米冲刺的速度前进，一定会心脏病发。 当然，有些人会用这样的论点来推论。如果你这一百公尺可以保持这样的速 度，那为什么你下一百公尺不能保持这样的速度。你应该要有discipline。 如果你这两百公尺可以保持这样的速度，为什么你这一公里没有办法保持这 样的速度？为什么你没办法整条路都保持这样的速度？好吧。听到这种话的 话，deadline就会是你真正的死期了。先帮自己买个保险吧。你们项目在时 间内做完的机率绝对比乐透中奖还要低。 ＊＊ 数字管理 ＊＊ 虽然数字不会说谎的，可是解读数字的人会。所以怎么引用正确的数字，推 导出根本无关的结论，就是一门很高深的学问。 我们在估计项目大小，或是报价时，最常用的单位就是man-month。也就是一 个人努力做事一个月的生产力。然而使用这个数字，却会有很多不好的效应 发生。第一个就是直接会有人月= 生产力的推论。 ＊＊人月 = 生产力 ＊＊ 对于很多使用者来说，如果项目进度delay了，最直觉的想法，就是要求加多 一点人手。对他们来说，写程序就跟盖房子一样。大部分的客户都不知道要怎 么盖房子，当然也不知道要怎么写程序，可是感觉起来，好象多找几个人，就 会比较快一点。跟建筑业比较不同的是，客户通常还会希望能够找到几个比较 强的人，希望透过这些人的加入，可以加速整个项目的开发。对于客户来说， 人月是跟生产量成正比的。 软件虽然算是蛮新的工业，不过关于这方面的讨论，大概也有三四十年的历史 了，毕竟schedule delay，一直都是软件产业被人诟病的问题。很多学者做过 研究，发现人月是跟生产量不一定会成正比。有些读过书的人，就会听过所谓 的人月迷思： 『Adding manpower to a late software project makes it later.』 (作者注：引自The mythical man-month. Chapter 2 page 25) 简单的说，就是当project已经delay的时候，加人手不见得可以解决问题。主 要的原因有几个： 1.新人需要时间学习才能上手 2.新人一开始参与的时候，会需要对这个系统有经验的老手来加以指导，这会 减少老手投入开发的时间。 3.人数增加后，沟通的成本会呈几何级数地增加。 4.生一个孩子要花十个月，即使找来十个人，也不可能一个月就把小孩子生出来。 5.人数变多了，可是现在可以让他们做的工作一下子没有这么多，项目经理得要 想办法生工作让这些人都有事做。这样子反倒会让项目经理没有心力专注在真 正该做的事情上。 6.如果有人没事做，就会很害怕自己被裁员，就会做一些看起来像是工作的事情 。或是做一些抵销别人工作的事情。 所以呢，有读过书的主管(或是有听过的也算)就会知道，增加人手只有对于那种 人手超级不足的项目有效。这就是大名鼎鼎的人月迷思。所以呢不可以一开始就 主张增加人手…即使要也是等到客户要求以后再说。 好吧，我们可以不要一昧地增加项目的成员数目，可是我们还是要针对项目进行 规划啊，不然怎么估计出schedule与成本呢？所以通常就会先把现在有空，可能 可以参与这个项目的人列出来，假设这些人都会参与这个项目。然后开始进行规 划。 这下子问题来了，每个人工作能力都不一样。所以用人月来估计工作量怎么克服 这种能力上所造成的生产力差异？有两个菜鸟，应该跟两个专家不一样才对啊。 所以就会有人开始量化所有东西。例如超人的能力超强，所以他工作一个月，就 会有十个人月的生产力；可是温蒂就不同了，她这么菜，工作能力这么差，工作 一个月大概只有0.142857个人月的生产力。 结论就会是：如果超人没有办法接这个案子，我们就找十个凡人来就好了。 你可能会argue，超人这种大师，绝对拥有自己独到的创见与充分的经验。毕竟 一个莎士比亚这样的天才，不是十个凡人加起来就可以取代的。 没错，不过这表示你没有掌握管理这门艺术的精髓。 吉娜 ：超人，我知道你很忙。没有办法全程参与这个案子。可是我们现在已经 火烧屁股了。我想了很久，我想要麻烦你每天，抽出半个小时的时间， 来教导这十个平庸的programmer。我不求他们有你一半的功力。你可以 把你一甲子的内力传输给他们一点点，只要他们每个人有你十分之一的 功力就可以了。我想你每天再花一点点时间指点一下他们的迷津，就可 以让他们用十个人的力量，来弥补你没有办法join的生产力。 超人想，我要花多少时间，才能让每个人都有我十分之一的功力啊？可是…我还 能说什么呢？：臣当鞠躬尽瘁以谢先主知遇之恩。 主管最常用的手法，就是让超人在各个项目之间流浪，想尽办法把他榨干。于是 乎久而久之，宇宙间就会又多了一个累死的诸葛亮。主管常做的事情，就像是不 让莎士比亚自己去写作，而是找十个二流的作家，要求莎士比亚去教导他们，期 待他们在分工合作之后，可以写出相同的文章。 你觉得好笑吗？数字可是不会说谎的喔。 用数字来表示生产力，最大的问题就是人的生产力被一个数字来代替，完全没考 虑到团队中比较人性的层面。布鲁斯跟大卫合得来，可是布鲁斯就是跟尚恩合不 来。人与人之间长久工作的默契，以及因为相处以及共同的信念所产生的化学作 用，都会影响一个团队的整体表现，这些东西都很难用数字来量化表示。 另一个问题就是人月会跟成本化上等号。 人月 = 成本 对于很多懂会计的人来说，他们可能没听过The mythical man-month。可是每个 人每个月要领薪水，员工的户头会多一笔钱，公司的户头会少一笔钱，这是千真 万确的事实。所以人月就会等于成本。 项目人力总成本 = Σ项目成员月薪 * 支薪月数 一增加人手，项目成本马上就提高。所以除非增加人手可以让项目开发加速，降 低支薪的月数，否则项目成本一定直线飙涨。 既然随着信息的发达，所谓的人月迷思已经被很多信息业界的主管听到了，所以 呢，他们已经在实务上研拟出一套还没听说有什么不好的对策。 这套对策通常包含下列两个步骤： ＊ 增加每天上班工作时间 ＊ 将非工作日改成工作日。 这个策略的假设在于『增加项目成员的工作时间，能够生产出来的有效产出也 会随之增加。』用简单的话来说明就是：『想尽办法操死现在这几个鸟人，要 他们无止尽的加班，就可以把进度给赶上。』 台湾大多数的软件公司，都会宣称是采取责任制，通常还会伴随着不是很严苛 的打卡制度。这个制度的特点就是公司会宣称他不在乎你一天工作几个小时， 只要你把事情做完就可以离开公司，所以不会有任何加班费。接着你的老板会 给你一天绝对做不完的工作。然后要你在一天之内把事情做完。所以一天工作 十几个小时是家常便饭。 另外一个策略，则是会想办法要求你假日到公司加班。有些主管会采取温情攻 势，有些则是采用高压政策。反正就是威胁利诱，要员工无偿到公司加班。 这个策略对于老板来说，显而易见的好处就是 1.不会有人数增加后，沟通的成本增加的问题。因为被操的都是同一票人。 2.没有需要训练新人的问题，也没有任何老手的时间被浪费在训练上。 因为有无偿加班这回事，每天工作二十小时，就算后面这十个小时产出只有 原先的一半，那也有十五个小时的产出。所以只要逼员工加班，支薪月数应 该可以降低，所以成本可以下降。 这种做法无异是杀鸡取卵，可是通常都要等到大牌中的大牌，被工作压得粉 身碎骨，只好提出辞呈后，才会有人出面摸摸头。要你不要工作的太辛苦。 毕竟在软件公司里，大多数人的真正价值，只有在他提出离职申请时才会显 现出来。你只要还没有想走的念头，都不会是一个值得头痛的issue。 当然有人不会单单从加班费来思考，而会从另外一个层面来推论： 如果我们可以用便宜的人员来开发，一定可以减少开发的经费。 吉娜：布鲁斯，听说大陆的薪水大概只有台湾的五分之一。CEO已经指示日后 我们的项目要全部outsource到大陆去。这样一定可以降低我们的开发成本… 异地开发的坏处很多，即使现在internet非常发达，很多事情不在同一个办公 室，大家对于工作的态度与品质的看法不同，就是一个很难跨越的鸿沟。然而 大多数人，只看到遍地便宜的劳工，异地开发的成本，常常会被严重地低估。 开发软件需要非常紧密的沟通。异地开发可以省下来的费用，可能是要拿很多 无形的东西做代价。表面上看起来公司会因此而赚到钱，可是除了有形的人员 出差到另一个国家要花的旅费与薪资加给以外，花在彼此沟通的时间与经费， 花在架设相同的开发测试环境的精力，这些被派到异地出差的人，可能会受不 了长途跋涉就有了离职的念头，或是开发时间因为异地开发以至于拖长了好几 倍的时间…这些不良的效应，常常都会被忽略。 另外一个负面的效应，则比较少被提到。如果外国的工作者会抢现在公司里面 成员的饭碗，现在你所雇用的这伙人，心里面会做何感想？Hello，外国人， 欢迎来抢我们的饭碗？更不要提一旦项目出现状况，出现在两地之间的争吵， 诿过，相互攻讦… 除了使用便宜人力来异地开发以外，另一个常常有的推论如下： 如果员工没有处于忙碌状态，这等于是公司花钱请他来当大爷。这就会造成资 源的浪费，这个员工简直就是在抢公司的钱。所以每个人必须在上班时间内， 随时处于忙碌状态。 结论通常就是：Keep everybody busy。 （待续） 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，即使可以，你在声卡后面接屏幕，画面绝对还是一片空白。我个人 觉得，项目经理需要制造彼此互助合作的机会。怎么把对的人放在对的地方， 再让这些人可以慢慢融合成为一个团队，绝对是一个软件项目经理人的首 要任务。光是讲几句要有团队精神，大家要同舟共济，这是无济于事的。 此外，站在组织的立场上来说，我们对于团队合作到底提供了什么实质的 奖励？如果只是『我们在下一次调薪时，会考虑这个因素。』或是颁发几 张优秀团队奖状，其实诱因远不及发给奖金、股票、认股权来得有效。如 果没有实质的奖励，团队的成功与个人丝毫无关，这样子的话，人们怎么 会有动机想要协助团队的成功呢？ 　　　 （待续） 独孤木专栏＞ People Management（下） 激励 ---- 对于工程师无效的激励方式，我还真知道不少。 ＊工程师喜欢新科技以及训练，远超过金钱 ＊考绩 ＊肉麻当有趣 ＊想当年… ＊Vision、Mission Statement … 工程师喜欢新科技以及训练，远超过金钱 --------------------------------------------------------------- 布鲁斯：最近project team的士气有点低落。 吉娜 ：那我们来个内部训练好了。我请佛祖来开示一下好了。 布鲁斯：这倒也是可行。什么时间比较恰当呢？要不要用礼拜三下午四点？ 吉娜 ：不要占用上班时间。我想就是礼拜天下午四点开始好了。大家可 能会早一点到，还可以加班… 工程师先天就充满了好奇心，喜欢尝试新东西，试试看他所了解的新玩 意儿。只要有新的东西发表了，例如某某标准，或是新的工程技法，某 个软件的新版本，新的程序语言…他们都有兴趣去了解一下。 对于很多主管来说，这好象就代表了工程师喜欢新科技以及训练远超过 金钱。所以讲到要激励员工，通常最直觉的想法，就是来个训练吧。为 了要省钱，最好还是利用周末还是晚上的时间，做个内部教育训练，让 老鸟来带菜鸟。 其实工程师受了训练，接受了新科技，不是为了现在看得到的薪水，就 是为了将来转换新工作可能会获得的加薪。基本上都跟金钱可以画上等 号。当然不可以排除有些人会纯粹想要科技上的进步，跟智力上的发展 ，不过这种人大部分会留在学界，开发一些不切实际的东西。对于一般 职场上的工程师来说，如果在追求技术上的创新之余，可以顺便多赚点 钱，应该是没有人会反对的。 考绩 ---- 布鲁斯：奇德，我知道这一阵子你已经很忙了，可是这个案子现在看起 来赶不上进度，我想得要请你礼拜六日都到公司来加班。 奇德 ：什么？去年我才因为加班太久，心情不好打老婆出气，结果上 社会新闻。你还要我假日过来加班？你是想要让我老婆再变成 沙包吗？老实说，这个案子会拖这么久，都是史考特一开始没 有调度好。 布鲁斯：唉，史考特的调度有问题，这个我们都知道。不过他现在人也 走了，就不要再扯这一段了。这样子吧，虽然我们没有加班费 ，可是你的配合度这么好，今年打考绩时，我一定会记得会好 好补偿你。 大多数人有关打考绩的经验，就跟要他们不穿衣服，赤裸裸地站在台上 接受检验差不多。大多数的人会这么紧张的原因，主要是在于他们误解 了这件事情进行的方式，以为考绩跟他们一整年的表现有关。其实大多 数的主管也是视打考绩如畏途，所以多半都是凭着印象，随随便便交差 了事。如果一年打一次考绩，通常越接近打考绩时候的表现，会越具有 影响力。 如果你只能拿考绩来激励员工的话，其实指的就是你并没有提供其它实 质的鼓励。所以只好给他一个可能可以升官发财的梦。这种激励通常对 于菜鸟会比较有用。对于老鸟来说，只要被骗个一两次，就会学乖了。 肉麻当有趣 ---------- 布鲁斯：邓肯，这个案子现在真的要靠你大力帮忙了。除了你，没有别 人有办法… 对于某些母性比较坚强的主管来说，激励员工跟哄小孩差不多。所以通 常会用对于这个年龄层的人来说，会显得有些恶心的话，企图激励员工 。听到这些话，我常常会鸡皮疙瘩掉满地。 : 『你是最棒的。』(是啊，要不要给我一个乖宝宝贴纸？) : 『公司要是没有你，那该怎么办？』(还是会活的好好的啊。) : 『只有你才办得到。除了你，没有别人有办法。』 (这连白痴都办得到。是你只叫得动我。) : 『我们公司是从哪里找来像你这么优秀的员工？』 (是啊，可是怎么会领这么少的薪水呢？) 当老板信奉这一套时，你就会多了几个肉麻的朋友，只要他心血来潮， 就会时时拍出奇怪的马屁。如果他跟你不熟还装熟时，这就会更尴尬了 。他会问候你的家人，成长的环境…然后彻彻底底地把这些信息遗忘。 布鲁斯想，我应该要关心一下小组成员，对了，应该问候一下他的家人 ：邓肯，你说你太太是在做什么的？ 邓肯 ：我太太在学校当老师。 布鲁斯：当老师，哪很好啊。有寒暑假可以放。工作一定很轻松。 一个礼拜后。 布鲁斯(完全忘记他曾经问过任何问题。)：邓肯，你太太是在做什么的？ 邓肯也忘记被问过这个问题：我太太在学校当老师。 布鲁斯：当老师，哪很好啊。 又过了几天。 布鲁斯想，得要了解一下项目成员的家庭背景：邓肯，你结婚了吗？ 邓肯想，你不是最近才问过我吗：我太太没有换过工作啊，她还在 学校里面当老师。 布鲁斯想，咦，难道我问过这个问题而且忘了？不妙，赶快转移话题： 喔。你这个礼拜进度怎么样。 当然，有时你会遇到真正很棒的主管。他会清楚记得你的生日，你老婆 的职业，你的嗜好，以及你女儿的音乐发表会，而且他还会尊重你家庭 生活的时间。不过，在信息产业中，这种主管跟凤毛麟角差不多。 想当年… 会采取这种奇怪的激励方式的人，通常也是各类教条的爱护者。例如 『天下没有不是的父母』、『玉不琢，不成器』、『棒头出孝子』…。 依照出生年代的不同，通常会有下列不同的夸大版本。 远古时期：『现在的年轻人啊，一点儿苦都吃不得。想当年，蒋委员 长领导我们抗战的时候。(这时候要立正站好)那时候，我们整天在重 庆被日本鬼子轰炸。常常防空洞一躲啊，就是一个星期。日本鬼子一 炸啊，就是一个星期。一整个星期没阖眼啊，要换你们现在的年轻小 伙子，我看早就不行啦。你看你们这些人好命的哩。现在不过是加个 班，就一副没担当的样子，要遇到战争啊，我看你们只能举双手投降 了啦。』 中古时期：『现在的年轻人啊，一点儿苦都吃不得。想当年，我们要 读书啊，是历经千辛万苦。每天打着赤脚上学，便当盒里面就装着白 饭配着萝卜干，晚上念书没钱可以点电灯，还要去抓萤火虫，萤火虫 不够亮还要把墙壁挖个洞跟隔壁借点光。每次要注册了，就要跟街坊 邻居借钱去缴学费。你们这些年轻人啊，一点挫折都受不了。不过是 加个班嘛。要知道，有班可以上已经多好啦。现在谁不去大陆啊，大 陆的人工这么便宜，每个工程师都很拼。听说他们一天睡不到一个小 时，只要有钱赚啊，二十几个小时都在工作。你们不学学人家，将来 怎么跟他们比啊。遇到大陆的工程师啊，我看你们是铁定失业。』 近代：『现在的年轻人啊，一点儿苦都吃不得。想当年，我们要跑程 式啊。还得要把程序都打在卡片上。光compile啊，就要排队等个一 两天。拼错一个字啊，就要再等个一两天。哪像你们现在这么方便？ 按个键等一会儿程序就compile好？你们真是身在福中不知福啊。现在 要写程序已经比我们那个年代好太多了。你看看你们写出来的那是什 么程序嘛，bug一大堆。』 现代：『现在的年轻人啊，一点儿苦都吃不得。我们前几年在做那个 人事薪资系统，要上线前啊，大家整整三个月，每天工作十八个小时 ，早上八点出门，晚上两点回家。不夸张喔，整整三个月，包含礼拜 六礼拜天。现在你们不过是一天工作十四五个小时，还不到一个月， 就一直哇哇叫，一点抗压性也没有。你们不知道，比起我们当年啊， 实在是好命的太多啦。』 基本上呢，这种激励的方式呢，就是先告诉你一个父母双亡，无力葬 父，只好委身青楼的弱女子悲惨故事，希望你能够觉得你的命，其实 比别人都好。让你明白，别人这么惨都没去跳楼了，你不过是因为加 班时间太多，没时间陪老婆，因此跟老婆吵架的小小个人际遇不算是 什么。接着就是要告诉你，在以往那个年代，有一些人，即使身处逆 境，也会跟逆流而上的小鱼一样努力往上游，才会完成伟大(？)的成 就。你应该效法这种精神，为公司做牛做马。所以礼拜天加班，请务 必准时到达。不过身为管理阶层的我呢，有更重要的事情要思考，所 以就不奉陪啦。毕竟我已经苦了那么多年，媳妇熬成婆，总该轮到我 享清福吧？ 我是不知道有多少人会被这种故事激励啦。古人悲惨的故事，当做是 上班时候的消遣，听听当然无妨，这就跟看连续剧的意思是差不多的 。不过如果我是当事人，切身的问题绝对还是比较重要。女朋友生气 ，男朋友翻脸，小孩子认不得爸爸，都会比加班赶进度来得重要。况 且大多数时刻，长时间加班的效率其实都非常低落。如果一个项目经 理不能认清楚这一点，只是一昧地要求team member长期加班，只是看 到工作时间延长，好象生产力也跟着增加的假象，总有一天会尝到高 流动率的恶果。 Vision, Mission Statement … ----------------------------- 有些企管顾问非常强调Vision，Mission Statement…这些东西的功用 。他们觉得，如果我提出一个宏观的vision(愿景)，并且很清楚地告 诉每个员工整个公司的mission statement(公司宗旨。我个人觉得比 较像是任务的宣言)，员工会受到宏观愿景的吸引，而愿意做出超高品 质的工作。 这种顾问举出来的例子，通常是某某公司因为有了伟大的愿景，因此 整个公司的人都受到这种伟大愿景的指引，愿意牺牲奉献努力工作。 最后终于获得前所未有的成功。 原则上呢，我觉得成功的公司拥有解释历史的权利。他们想要让成功 看起来比较理所当然一点，找些理由来为自己的脸上贴金也是很正常 的现象。 我在不少公司待过。每一家都是立志要成为世界上第一流的企业。每 家公司的愿景，大概都是像这个样子：『我们要集合世界上一流的人 才，开发世界上一流的产品，然后拿着吸尘器到世上每个人的口袋大 吸特吸，直到所有钞票都被我们吸光为止。接着要拿我们赚来的钱的 百万分之一，出来造桥铺路做善事顺便抵税。』按照企管顾问的说法 ，因为我们有捐款助人的那个部分，员工就会被这种世界大同的伟大 使命所吸引，然后受到前所未有的激励，就愿意无偿地长时间加班。 例如卖彩券的公司都会强调买乐透可以帮助社会资源重新分配，彩券 盈余还会提拨出来做社会福利，这样员工就会忘记他们是在鼓吹赌博 ，而是在从事一项崇高的行业。 选定一个方向，做客户要的东西，并且努力保持自己的竞争力，其实 是企业要获得成功的不二法门。没有一家公司，是因为vision太差， 所以员工士气低落，导致生意太差，因此关门倒闭的。然而很多经营 阶层，一直认为勾勒出一个远大的愿景，是一件很重要的事情，所以 要一直努力地跑到风光明媚的山川之间去闭关苦修，才有办法画出一 块很大的大饼。 然而对于大多数的公司来说，欠缺的其实不是一块大饼。而是怎么去 让这个梦想实现的执行能力。与其拿一个遥不可及的梦想企图激励员 工，不如拿实际成功的成绩来激励士气。这世上还有什么比『成功』 更能激励士气呢？或许是因为对于这些主管来说，要获得成功的经验 太过困难了吧。 以身作则 -------- 对于很多主管来说，管理就是要以身作则。所以担任主管的人，要第 一个到，最后一个走。我小时候看军教片，那种铁血班长，跟魔鬼士 官长，就是以身作则的最佳模范。然而军教片看起来很好的东西，现 实生活可不是如此。例如现在我们已经不玩『消灭万恶共匪，解救苦 难同胞』这一套了。 很多具有同理心的项目经理，总会觉得大家都在忙，我不可以在旁边 休息，我应该比大家更忙才对。所以开始到各地去招揽工作。菜鸟经 理常常犯的毛病，就是做自己熟悉的事情。我原本是系统分析师出身 的，就继续坐着经理的位置，做系统分析的事情。我原本是写程序出 身的，就继续坐着经理的位置，写我想写的程序。特别是当做这个工 作的人，做得没有我好时，就更有理由这么做了。毕竟会被升上经理 ，不会是没有原因的。问题是，当你在身先士卒以身作则时，谁在运 筹帷幄呢？当你在努力写程序时，谁在做项目经理呢？ 真正的管理，其实不是在于要项目经理做个全能的人，team member 看到你很辛苦，确实会认同你的辛劳，不过他们更需要的，是一个可 以倾听他们的问题，接着帮他们找资源来解决问题的人；是一个知道 该做什么，并且会适切地调度资源的人；是一个可以引领方向，带他 们走出重重包围的人。 当你专注在某个工作，而非整个项目时，那么负责那项工作的人，是 头一个受害的人。接着受害的，则是整个项目的团队。 结论 ---- 大多数的软件公司主管，会花很多时间去招募新人。因为他们认为员 工会有高流动率，是一种很正常的事情。因此他们的重点，一直都放 在怎么去找到市场上最好的新人。相形之下，花在怎么让现有人力运 作的更好，怎么让员工更喜欢这个工作环境的精力上，就显得少的可 怜。 软件开发是一种高度需要思考的工作。安静的环境，足够的办公空间 ，以及采用良好的开发工具，确实可以提高开发工作的效率。然而， 减少multi-tasking，以及采用正确的开发流程，并且减少不必要的文 件，对于效率的助益可能会更高。 有没有什么比较简单的原则呢？我个人觉得，要能真正的提高效率， 你得要先尊重每个人的时间。不要花太多的时间，去做不必要的事情 。把事务性的工作，尽量地找行政管理人员帮忙处理。找个工读生来 帮工程师填写假单，处理所有要申报的费用，影印所有要打印的文件 吧。每次会议要先规划议程，没有必要，不要让每个人从头到尾参与 一个会议，先想想这个人出现在这里，有没有什么必要性。没必要的 话，就放他先回去工作吧。只有你尊重每个人的工作时间，才能真正 打造出一个有效率的团队。 不过，项目经理并不能只把心思专注在效率上。怎么样打造一个适才 适所，运作平顺的团队，并且保持高昂的士气，才是项目成败的关键 。老实说，我觉得只有每个人都赢的策略，才能获取这样的成果。 有什么策略会每个人都赢呢？让我来教你。 简单的说，针对你现在所有的项目，每个项目依据项目的难易程度， 提拨一份项目结案奖金。项目可以顺利结案，发给一笔奖金。如果专 案是在预定的时间内完成，就发给另一笔奖金。奖金的金额怎么定呢 ？对于项目结案奖金，我建议直接从项目总价中抓一个百分比即可。 例如，如果项目可以结案，就发给项目成员项目总价的10%做为结案 奖金。 至于在预估时间内完成的项目，要提供的奖金，其实也可以用项目总 价的固定百分比来算。不过对于那些已经做到一半，而且还没有结案 的案子。我个人建议的方法如下： (预估最糟的结案日期 – 预订完成日) / 2 * 所有成员的薪水 这里面当然会牵涉到『预估最糟的结案日期』『预订完成日』这个日 期怎么得来的。还有这个日期是否需要随着项目的状况进行调整…等 问题。我个人认为，这些日期都问主管即可。 预估最糟的结案日期：如果这个项目到这天还没做完，你宁愿从现在 开始就不要投任何人进去。 预订完成日：任何你认为合理，并且希望project team可以完成的日 期。不过要注意如果这个日期完全不可行，那就会失去奖励的诱因。 其实，这只是一个建议而已，你可以依据实际项目的状况自己发挥。 只要你把项目的成功，与一个有可能可以得到的奖励绑在一起，就会 有一个很好的策略。 怎么样才能让优秀的员工想要长久地待下来呢？我想让员工拥有成功 的经验，合理的待遇，良好的生涯规划，发挥才能的机会以及良好的 团队气氛，都对于留住人才，有正面的帮助。 人力是软件公司最重要的资源。只有个人的发挥，与公司的成长可以 密切地契合，软件公司才有生存成长的空间。找到好的人才，把他放 到对的位置上，并且提供他必要的协助，让他愿意持续地为公司效力 ，实在是高阶主管最重要的工作。有梦虽然很美，可是强将手下如果 都是弱兵，大概就只能做做白日梦了。楚汉相争，最后刘邦可以得天 下，关键就在于他打造了一个优异的团队。没有优秀的团队，就没有 良好的执行力；没有良好的执行力，再多愿景也是空谈。 话说回来，读这本书的人刚好是高阶主管的机率应该很低。所以对于 大多数的问题，大概都只能默默地承受或是被动的因应，没办法做出 什么前瞻性的思考或是积极的作为。没关系，耻笑老板的无能原本便 是一种有趣的事情。如果你是个中阶主管，少做一些傻事，就会被少 笑一些。如果你是个小螺丝钉，反正人太菜的话，天生就是要被欺负 的，那就保持着愉快的心情继续嘲笑老板吧。我会在这本书剩下的部 分，努力帮你保持愉快的心情。你只要负责嘲笑老板就好了。 运用数字来进行项目成本与时间的预估，本来就是最正统的做法。只 是在估计的过程里面，所有的数字要建立在合理的假设上，在项目进 行的过程中，如果要修正你的规划，就要随时检视你原先的假设是否 合理。数字并不是代表项目管理的全部，它只是代表你对于一件事情 要做多久，要花多少钱的一个推论。我个人觉得，我们应该要做的， 并不是先建立一个推论，接下来就拿着这个推论来指引你全部的行为： 『你不是说这个问题，一个礼拜就可以解决了吗？』 『你不是说SIT只要三个礼拜吗，现在都已经过了两个月了。』… 计划应该只是当成是你在做事情时的参考，一开始规划好了，把要运 用多少资源也规划好了，接着当你遇到实际的状况时，再慢慢修正你 的计划。我总觉得，当项目过了起初planning的阶段，重点就应该放 到team身上，team member的士气，成员之间是否能够培养出共同开 发的默契，是否把正确的资源，在正确的时间点，摆在正确的位置上 …这些才是项目进行过程里面最重要的因子。除非你想写一个全部人 员都阵亡的backup plan，否则所有项目进行过程中对于计划的修正， 都应该建立在你对于现有团队的了解上，而不是直接拿预估人月除以 开发人数得到开发时间。 当然，这样子做最大的缺点，就是把太多因素绑在主观的判断上，别 人就没有客观的依据可以来判断这样的预测是否可行，也就没有办法 进行control，或是risk management。不过项目管理本来就一直在艺 术与工程的两极中摆荡，那就看你要从哪一个角度来看待这些事情。 当然，这就会跟软件公司要怎么样才会赚钱，或是项目的成败该用什 么样的标准来衡量有关了。Well, that will be another story. (完)