本文主要是介绍独孤木专栏＞ 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。 （待续）
这篇关于独孤木专栏＞ People Management（上）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
