people management - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

假设你是公司的高阶主管，为了缩减这一季的费用，来让损益表好看一点，以便于让你手上高额的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。 （待续）
---------------------------------------------------------------
布鲁斯：最近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.
                                    (完)
上班挺累，看看文章轻松一下，呵呵。

[ 本帖最后由 pacman2000 于 2011-3-21 16:22 编辑 ]