人件 学习笔记 之三

第 III 篇 适当人才

这一篇探讨软件经理应遵循怎样的选人标准来为工作岗位物色合适的人员。

对任何努力的最终成果，谁做这项工作往往比这项工作如何做的影响更大。然而现代管理科学几乎不注意雇用并留住适当的人。管理学更关注的是管理者在工作中扮演的重要战略家和战术家的角色。在本篇中，我们试图消除战略家型管理者的观点所造成的损失，并鼓励软件经理用下面的方式追求成功：

l  雇用合适的人

l  使他们觉得开心，这样他们就不想离开

l  宽松对待员工

第 14 章                     霍恩布洛尔因子

软件经理想要真正去改变和塑造手下的程序员是不现实的，因为程序员经常不会在同一个组织中呆很长时间，而且软件经理也没有足够能量来改变程序员的本性。因此，在任何一段时间内为你工作的程序员，在工作结束与工作开始时或多或少是一个样。如果一开始他们就不适合干这份工作，那么他们直到工作结束时仍是不适合干这份工作。

这就意味着：在重要的位置上安排合适的人是至关重要的。为项目挑选团队成员的技巧，在很大程度上决定了一个软件经理能否成功。

公司的“熵”是指公司员工在态度、相貌和思维过程方面的统一性。就像宇宙的熵在不断增加一样，公司的熵也总是在增加。也就是说，公司总是喜欢招入一些看起来、听起来、思考起来跟公司其他员工差不多的新人。但是，随着公司的熵的增加，公司的员工愈发趋同，公司越发失去活力或创造性，这也就是为什么大多数资历老的公司比年轻公司更严厉、更缺少乐趣。

所以，最成功的软件经理在招聘新人时，应该是跳出公司的条条框框，去寻找那些合适的人选，哪怕他们与公司的选人标准有出入。也就是说，要不拘一格降人才。软件经理引入这种有独特个性的合适的人员，实际上就是在减缓公司的熵的增加，对公司有有益的。

第 15 章                     雇用一个变戏法的人

软件公司雇用程序员是有讲究的。一个比较推荐的方法是让应聘者举行一次工作试讲。你要求应聘者准备10到15分钟的跟过去工作有关的某个方面的陈述，然后当着你和团队其他工程师的面，把准备的内容讲出来。试讲结束之后，你和团队成员再就应聘者的表现进行讨论和评价。在集思广益的基础上，决定是否雇用该应聘者。这样的好处是每个团队成员都能对未来加入团队的同事有个预先的了解，同时，由于大家都对新同事的加入发表了意见，所以吸纳的决定是由团队共同作出的，这有助于新人尽快地融入团队。

第 16 章                     很高兴在这里

“工程师年流动率”是衡量一个软件公司和软件团队管理水平优劣的重要指标。“工程师年流动率”的计算方法是 。“工程师年流动率”的倒数，则是“工程师平均服役年数”。软件经理通过了解公司的“工程师年流动率”，可以知道公司当前的管理状况；通过总结自己的团队的“工程师年流动率”，可以掌握自己团队的管理状况。

人员流动会增加公司的运营成本，这种成本有显性成本和隐性成本两种：

显性成本：一般地，替换一个软件工程师所花的账面开销是该工程师4.5 – 5个月的薪水。因此流动率越高，公司的开支也就越多，公司的账面成本就越高。

隐性成本：公司的流动率高，会使为公司工作的员工无法建立起对公司的忠诚度。这样，员工不会长期呆在公司，也不会从公司的长远出发考虑问题。

由于较高的人员流动率会给软件公司带来巨大的显性成本和隐性成本，因此真正有远见的公司和有远见的软件经理都致力于营造良好的工作氛围，让优秀的工程师愿意长久地高兴地在自己公司工作。一些常见的降低离职率的措施包括：

l  从长远而非短期出发，舍得为员工的工作环境投入资金（比如前一篇中所讲过的那些措施）。

l  舍得在员工身上投资。为他们提供付费培训，提升他们的技能，帮助他们升值。

l  尊重员工的个性，不把员工当零件看，而是好好爱护，增加员工对团队的归属感。

l  逐渐在团队中培养社区情感，化同事关系为亲属关系，这样有助于提高团队的粘合度。

第 17 章                     自愈系统

软件经理应该鼓励团队的员工灵活地处理工作中遇到的事务和问题，而不是把员工当作运转的机器上的零件。

为团队和项目制定好全套的规则和流程，然后把员工当成规则和流程之下的零件，这是典型的传统制造业的经理的所作所为。但这绝对不适合于软件业的经理。上述的作法会带来以下灾难性的后果：员工的主观能动性和创造力被扼杀在条条框框和所谓的“流程”之下，这让他们感觉自己的头脑被浪费了，甚至感觉自己的能力没有得到应有的信任。

软件经理制定规则和流程的本意，其实是想把一些经过汇总的好的想法和做法推介给程序员，让大家尝试。但是过死的规则和流程却会挫伤团队的士气和创造力。要想把好的想法做法汇总后反馈给每个程序员，其实最好的办法就是：

l  培训。通过培训，让程序员们了解新的工具、方法，并加以讨论。

l  同级技术评审或者说头脑风暴。

第 IV 篇 培养高生产力团队

在我们大多数珍视的工作记忆中，让人印象深刻的是团队交互作用。当小组成员团结起来时，大家会工作得更好，并且更开心。本篇将研究“胶冻团队”，以及软件经理为了让团队“胶冻”应该和不应该做什么。

第 18 章                     整体大于部分的总和

所谓“胶冻团队”，是指团队的成员紧密地团结在一起，团队整体大于部分的总和。胶冻团队的生产力比非胶冻团队更高，而且胶冻团队的成员工作得也更开心。

那么，是什么让团队成员凝聚起来，形成一个胶冻团队呢？一个目标，一个团队成员愿意为之奉献的共同目标。这个共同目标不一定是物质目标，它可能只是“开发出比XXX更受欢迎的播放器”这样的目标。这个共同目标的作用，不在于一定要实现它，而在于它充当了团队成员的粘合剂，让团队能够“胶冻”。

因此，软件经理的职责之一，是想出好办法，使用一些巧妙的手法，让团队成员能够认同团队的共同目标，并逐渐接纳它成为他们自己的目标。团队成员接受团队目标的过程，就是胶冻团队形成的过程。

胶冻团队一旦形成，就往往会表现出如下的一些特征：

l  在项目过程中的低人员流动率。因为团队成员都想追求团队的共同目标，因此在项目完成之前大家都不愿意离开。

l  具有“独特个性”或者说是“品牌意识”。胶冻团队往往在一个组织中是精英团队，引人注目。

l  对自己的产品充满感情。胶冻团队的成员愿意把自己的名字刻在产品上，向世界宣告这是他们的优秀成果。

l  团队成员工作得很快乐。团队成员之间的关系是互信的、热情的、无障碍的。

第 19 章                     黑衣团队

胶冻团队一般来说都是组织中的精英团队。团队中的成员会为他们的产品和成果感到自豪，并且有种心理上的“优越感”，觉得其他人无法交付像他们那样高品质的产品。而这种团队整体的精英意识，又反过来会促使团队中的每个个体做得比一般人强。

第 20 章                     团队自杀

在本章中，我们列举一些阻止胶冻团队形成的做法，同时也给出鼓励胶冻团队形成的做法。

软件经理遏制胶冻团队形成的做法	软件经理鼓励胶冻团队形成的做法
防范式管理：对手下的员工的能力不信任，担心他们缺了自己的指导就会把事情搞砸，担心他们的头脑没有自己“聪明”而无法想出好办法，因此总是给项目事务插进自己的“高见”，给团队加上各种规则，防止员工犯错。	信任员工的能力，放手让他们开支脑筋去想问题。不拿条条框框，尤其是不拿自己的意见去左右手下的员工，鼓励员工尝试，哪怕最后会犯错。
物理隔离：把本该在一起紧密工作的人从物理上隔开。	把经常在一起紧密工作的人安排到一起，让他们有机会多相互接触，相互了解，培养起团队的亲和力和默契感。
员工的时间分割：让员工同时参与四、五个项目。	让员工在某一时段只参与一个项目，让他跟项目团队中的其他成员有充分的时间交流，从而形成胶冻。
要求降低产品质量：无视团队成员对于产品和成果抱有的那份情感。更恶劣的是，在项目进度的压力下，还会要求团队成员牺牲产品质量换取进度。	完全理解并支持员工珍视产品质量的情感。当进度压力袭来时，替员工承受压力，保证他们交付高品质的产品。
虚张声势的“最后期限”：拿虚张声势的“最后期限”吓唬员工，要求员工为之加班加点地工作。	让员工自己制定进度。甚至更好的方法是不给团队施加任何的进度压力，让员工完全自主地决定进度。
私党控制：因为软件经理感觉自己的地位受到挑战和威胁，所以或暗中或露骨地破坏和拆散团队。	努力维持团队成员的稳定性。项目可以结束，但团队人员仍属于同一个团队，共同迎接下一个项目。

在第27章和第28章还列举了另外几种团队自杀的情形。

第 21 章                     一顿意大利通心粉晚餐

好的软件经理会为团队提供频繁而又容易一起实现成功的机会。这些机会可以是很小的预研性质的子项目，可以是一些示范或暗示，可以是使团队快速养成一起去获得成功的习惯的任何事情。好的软件经理的管理方式就是“润物细无声”，让手下的程序员感觉不到“被管理”，而只是感觉到在这个团队中能够和其他同事一起取得成功。

第 22 章                     思想开放

软件经理自身的心态也影响着一个团队能否“胶冻”。下面是软件经理应该具备的一些积极的开放的心态。

疑人不用，用人不疑	在给工作岗位挑选合适人选时，谨慎考察，坚持给一个岗位安排你觉得最合适的人。一旦你作出了认真的决定，让某个人上岗之后，就不要再怀疑他/她的能力，完全信任他/她，放手让他/她在这个岗位上去发挥，相信他/她的专业水准和判断力。当你的员工明白你是相信并依赖于他/她的能力时，他/她会努力工作来回报你的信任。
宽松地对待程序员	优秀的程序员根本不需要其他人来督促其工作。所以如果你真地相信你的程序员的能力，那么你完全不用把自己搞得像“监工”一样。你要做的只是把任务告诉程序员，让他们自行决定进度安排，然后从他们眼前消失，不去烦他们。过不了多久，你的员工就会拿着他们的成果回来找你，产品的质量和完成速度超出你的预期。
允许员工自己拿主意	程序员本身是靠头脑吃饭的，因此如果软件经理剥夺他们动脑子作决定的权利的话，无异于逼他们离开。所以，软件经理千万不要用公司的规章、决定，尤其是经理自己的决定去“绑架”手下的程序员。给他们思考和作决定的空间，信任他们。
尊重团队的共同意愿	团队的共同意愿是把团队中的每个个体形成胶冻团队的凝合剂，因此软件经理应该尊重团队的共同意愿，不要做有悖于共同意愿的事情。
谁在哪方面是权威，哪方面的决策就听谁的	软件经理必须跟跨过这样一道心理障碍：“我是经理，你们这些程序员都该听我指挥。”软件经理必须明白，术业有专攻，每个人都可以在他/她所擅长的领域发挥主导作用，但在其不太擅长的领域则要听从指挥。 软件经理所擅长的是制定总体方向、谈判或招聘，但在其不擅长的技术领域，软件经理如果试图充当“权威”，那么下场很可能不太好。 软件经理尤其应该明白：没有谁是永远的权威。在某个方面某个领域中谁是权威，在那个方面那个领域就应该听谁的。

第 23 章                     促使团队形成的亲和力

软件经理有些什么具体的做法来帮助自己的团队“胶冻”呢？下面是一些建议。

1.       质量崇拜

前面已经谈到，程序员对产品的卓越品质有一种本能的追求，而这种追求，正是胶冻团队形成的最佳催化剂。因此软件经理应该时刻注意保护程序员的这种质量意识。

但是，这种对质量的追求，对于公司的短期利益是没有帮助的，它只会对公司的长期赢利产生影响。因此，这种对于产品质量的重视态度，也就反映了一个公司和软件经理是否具有长远的眼光。目光长远的公司和软件经理，会顶住短期利益的压力，让团队拿出最高品质的产品。

2.       提供许多机会让员工感到满意

聪明的软件经理会将工作分成若干个小阶段，并且确保每个小阶段都能有实质性的成果来标识阶段性的成功。每个小阶段的任务完成，就是一次团队庆祝成功的机会。这样，团队能够不断地从一个小成功走向下一个小成功，团队的士气可以不断增加，团队的自信也稳步提升。

3.       建立精英意识

由于胶冻团队的表现通常优于其他非胶冻团队，因此来自胶冻团队的成员往往心理上比其他人更有优越感。换句话说，胶冻团队往往会表现得比其他平庸的团队更有精英意识，更具独特个性，更不走寻常路，因此看上去也就更桀骜不驯一些。所以，精英团队也就比普通团队更难以管理，对吗？

对这个问题的答案，关键是看软件经理怎么定义“管理”二字了。平庸的软件经理把“管理”等同于“控制”，认为只有把对团队的控制权牢牢掌握在自己手里，事情才不会失控。所以，平庸的经理试图用自己的意识去控制团队成员，让成员服从于自己的意志。而精英团队的成员往往是有鲜明个性和独立精神的，这就自然会与“控制型”经理的控制欲形成冲突，“控制型”经理会明显感觉到挑战和压力，进而扼杀团队成员的个性。而真正伟大的软件经理则明白：本质上人是不可控制的，要对手下的程序员加以控制本身就是妄想，因此成功管理的本质是尊重精英成员的个性，并设法引导他们施展其才华和个性，为项目和团队的共同目标服务。

综上所述，“面对特立独行、不服从管理的程序员，你的第一反应是什么？”这个问题，是检验软件经理优劣的试金石。如果回答：“第一反应是我还要加强对属下员工的教育”，那么这个经理是一个还没开窍的“控制型”经理。如果回答“我喜欢这种有个性的员工，而且我还要反思可能是我对他/她管太多了”，OK，这就是优秀的软件经理的回答。

4.       保持和保护成功的团队

如果一支团队的确很团结，那么不要分裂它。保持团队的稳定，让团队一起接手下一个项目。

5.       团队的结构应该是网络状的

正如前一节所言，在最好的团队中，不同的人在其擅长的领域内提供临时的指挥。因此，没有人（包括软件经理）是永远的领导。所以，胶冻团队的成员之间并不存在上下级关系，每个人都是一个平等的节点，大家共同组成一个网络。软件经理也只是这个网络中跟其他节点对等的一个普通节点。

6.       允许和鼓励异端

胶冻团队的战斗力源自于团队成员的多样性。只有团队成员各自身怀不同的绝技，团队才能自信地迎接各种环境和条件下的挑战。因此，软件经理应该注意给团队引入多样性，鼓励不同的思想碰撞出火花。