人件 学习笔记 之四

第 V 篇 在这里工作应该很开心

这一篇介绍软件经理要做些什么来让程序员觉得工作是充满乐趣的。

第 24 章                     混乱和秩序

如果一个项目进行得按部就班、循规蹈矩，那么也就意味着这个项目没有太多挑战性，对程序员而言，这样的工作和项目就是无趣的。软件经理对此能做点什么呢？一个最基本的回答是：给项目引入一些未知和混乱，从而提高项目的难度，从而激发起工程师的兴趣。下面来介绍一些具体的做法。

1.       前导项目

所谓“前导项目”，是指尝试一些你不熟悉的、未经证明的技术的项目。有经验表明：那些试用任何改进方法的前导项目的生产力，往往高于平均净生产力。这意味着，聪明的软件经理可以选择把一个既定项目作为使用一些新技术的前导项目来管理。实际上，可以把所有的项目都当成前导项目来管理。

这里的技巧是：软件经理允许人们胡乱修改开发过程中的某一特定方面。这样，项目成员在这一特定方面就会需要去学习新的方法和技术，这会给他们带来挑战。但是，必须强调的是，应该在项目的其他方面遵循标准做法，而不是四面出击。四面出击往往带来巨大的风险，也不利于项目的最终成功。

2.       头脑风暴

头脑风暴是精心安排的交互式会议，尤其以创新的洞察力为目标。6人以上聚在一起，集中讨论一个相关主题。会议没有什么规则和限制，大家只有一个目标：尽量多地提出看法和主意，而不必在乎这些主意的质量。在头脑风暴会议上不对提出的主意进行评估，评估会在以后进行。不鼓励诸如“那是不明智的主意”之类的消极评论，因为愚蠢的主意经常会引领其他人思考聪明的主意。

3.       培训、旅游、会议、庆祝和疗养所

给团队成员提供一起培训、旅游、开会、庆祝的机会，团队成员会在这样的相处的方式中加深了解，增强联系，形成真正的胶冻团队。

第 25 章                     “自由电子”

现在有许多优秀的工程师都脱离了企业组织，成为独立的咨询师或顾问。这种现象也促使企业反过来思考：是否应该为企业内部那些有才华的提供一个宽松规定责任的职位，以便使他们有更多权力界定其工作。

最好的软件经理应该具备这样的能力：能够鉴别出那些有过人才华的团队成员，并给他们充分放权，让他们自行决定要做什么，以及怎么做。

第 26 章                     霍尔加·丹斯克

在本书中，我们列举了软件经理应该做的许多事情，比如为员工争取更好的办公环境，允许员工中的异端，鼓励追求产品质量（即使时间不允许），废止加班，给员工自行做决定的自由，等等。如果你照着这样去做的话，你就会发现，你会遇到一些阻力，这些阻力来自你的上层领导。但是，你也大可放心，因为你并不是一个人在战斗，你的团队成员都站在你的身边。你是软件经理，所以你为你的手下员工创造好的工作环境是理所应当、天经地义的，你的手下会为此感激你，他们会用出色的工作成果来回馈你。

第 VI 篇 《人件》续集

第 27 章                     再论团队自杀

我们在第20章“团队自杀”中已经讲到过团队自杀的若干情形。但是我们还漏掉了两种。

软件经理遏制胶冻团队形成的做法	软件经理鼓励胶冻团队形成的做法
表面功夫：仅仅利用海报、张贴画、奖章这样的宣传品来宣扬质量意识、领导艺术、创造性、团队精神、忠诚度等公司美德。	软件经理应该明白：空洞的宣传和口号都是些花架子假把式，仅仅靠捣弄点标语海报张贴画是绝对不可能真正培育起胶冻团队的。软件经理必须采取一些真正的举措，让员工切实感受到公司的美德。
加班：让员工加班。更恶劣的是，让某些员工加班而允许另一些员工不加班。	加班会导致简略不增反降，这是软件经理应该知道的基本常识。并且，由于团队成员对加班有不同的承受能力，让某些人加班而允许另一些人不加班会导致团队分裂。

第 28 章                     竞争

软件经理不应该在团队内部培养竞争情绪。这种团队成员内部的竞争会导致团队无法“胶冻”，因此，内部竞争也是导致团队自杀的原因。

软件经理遏制胶冻团队形成的做法	软件经理鼓励胶冻团队形成的做法
制造内部竞争：在团队内部培养团队成员之间的竞争情绪。常见的做法是： 针对个体的绩效考评 褒奖工作出色的某些员工	聪明的软件经理采取一些措施来减少团队成员的内部竞争。例如： 向手下的成员切实表明自己倚重的不是个别成员的单兵能力，而是团队整体的实力。因此只有团队所有成员都做出成绩才是真正的团队胜利，只要有一个团队成员工作得不开心，就是整个团队的失败。 尽量避免按不同的规格来奖励团队成员。

第 29 章                     过程改进步骤

在第17章“自愈系统”中，我们便提出软件经理应该鼓励工程师自己去开动脑筋，改进软件开发流程，而不应该用硬性的公司规章去强制工程师们要做这个做那个。但是，这些年过去，这样的行径并没有减少，反而愈演愈烈。能力成熟度模型（CMM）就是一个典型例子。

在追求CMM等级认证的公司中，CMM所宣扬的软件开发实践被当成谕旨一样被执行。这样的公司，毫无疑问是追求死板的流程，而完全忽视了程序员本身的思维能力。

从根本上讲，识别出软件开发过程中的最佳实践并向大众推荐，是一种有意义的行为。但是，如果试图把这些最佳实践不加区分地作为公司或项目的制度固化下来，强制大家执行，那么很可能这些“最佳实践”会在公司和项目中水土不服。

从另一个角度讲，如果公司或项目只着眼于追求所谓的“成熟度”，那么成熟度越高，公司的熵就越高，公司的创造性越弱，公司越发无力孕育真正有挑战性和高利润的项目。这样的公司，成熟度是上去了，但是其雄心和利润却下来了。

第 30 章                     使改变成为可能

如果你是软件经理或者公司高层，你希望给你的团队或公司引入一些改变，例如使用新的编程语言、使用新的开发环境和工具、使用新的开发流程。你会怎么做？

首先，你必须要有思想准备：你会受到一些挑战和质疑。因为人们都不喜欢改变，而你想促成改变的发生，所以你就站在了人性的对立面，自然你就会受到他人的挑战。

其次，你必须讲究策略。人们反对改变，是因为他们已经习惯了旧有的做法。如果你想引入改变，你就不能去贬低那些已有的做法，这样只会招致人们更加强烈地去维护和捍卫旧有的做法。你应该说服人们：旧有的方法是不错的，但是现在的环境、条件和形势已经发生了一些变化，因此必须对旧有方法作出一些调整，这才是真正的保全旧有方法之道。

最后，你必须要有耐心。人们刚开始采用新的做法时，也是摸着石头过河，所以出点岔子是在所难免。安抚大家，不要因为一点点混乱就放弃。让你的员工相信，他们不会因为尝试新事物犯了错闯了祸而遭到惩罚。如果大家都有这样的安全感，那么你想要的变化就能更容易地被大家接受并尝试。

第 31 章                     人力资本

作为软件经理或公司老总，你必须要有这样的意识：公司的每笔支出，可以分成两类，要么是属于费用，要么是属于投资。费用是一笔花出去以后就再也回不来的开支，比如公司的办公场地费。而投资则是用一种资产去买另一种资产。你怎么看待你给你的员工支付的工资？是看成费用，还是投资？

聪明的管理者把花在员工身上的钱（工资、培训费、福利，红利，等等）都看成是投资。投入这些钱，换回的是一个更了解公司业务领域、更和谐融入所在团队、更能为公司创造利润的工程师。

如果你真地把这些花在员工身上的钱看作投资，你就会格外珍惜你的投资成果——你的员工，你就会尽最大努力让他们爱上你的团队你的公司，让他们不愿离开。因为一旦他们离开，你的这笔投资也就真地变成了费用，收不回来了。所以，有远见的管理者和公司是绝不会做裁员这样的事的。裁员就是杀鸡取卵，表面上是削减了成本，但实际上却是让公司多年的人力投资付之东流。

第 32 章                     公司的学习

作为个体的人必须不断学习，才能持续进步。同样地，作为组织的公司也必须不断学习，适时做出变化，才能长期发展。但是，公司的学习是一项时间跨度很长的活动（以年计），因此一个公司真地想要“学有所得”，就必须能够留得住人。否则，公司的员工来了又走，根本谈不上公司智慧的传承，这样的公司自然无法积累起厚实的底蕴，也就不可能从自身的发展中学习到什么经验和教训。因此，一个公司的学习能力，受制于该公司留住人才的能力。

公司学习的关键问题不是学习如何进行，而是由谁进行。公司的高层通常把主要的时间花在采纳改变或拒绝改变的决策上面了，所以没有时间来做公司的学习。公司的底层员工，囿于其视野警署和自身影响力，也并不是公司学习的主体。因此，公司学习的主体是公司的中层管理层。成功学习的公司，总是以有强有力的中层管理层为特点的。

但是，必须注意的是，所谓“强有力的中层管理层”，是指公司的所有中层管理人员能够形成一个胶冻团队，能够彼此沟通，在一起有效、和谐地共事。这种现象极其罕见，我们更多听说的是中层管理人员之间内斗倾轧的故事。因此，公司高管的一项重要职责，就是想法消除中层管理者之间的内部竞争，让他们能够一起充当公司的重新设计者，并从成果中分享共同利益。

第 33 章                     管理上的最大恶行是……

管理上的最大恶行是浪费人的时间。下面是一些典型的例子。

1.       工作情况汇报会议

觉的工作情况汇报会议的形式是：与会者轮流与一位重要人物进行交谈，而其他人则只是坐在那边，思考轮到自己时要汇报些什么。这种会议浪费了下属的时间，会议的重要人物原本只需要单独与各个与会者交谈就可以。这样的会议的目的不是开会，而是完成一种仪式，通过这个仪式，领导者向下属们表明：老板就是老板，他/她有足够的权威召集所有手下放下手头的工作，来向他/她汇报。

2.       早期的人员超编

软件项目的早期活动一般是项目规划、需要分析和软件设计。这样的活动是不需要太多人同时参与的，往往一个由少量骨干成员组成的团队就可以完成。而当项目进行到实施和部署阶段时，对人员数量的需要都会大量增加。因此，在项目开始的初期就为项目配备大量开发人员的做法，实际上是对人力资源的浪费。但是，多数项目正是这样做的。

3.       员工的时间分割

我们已经在第20章“团队自杀”中讨论过这个问题。让员工同时参与多个项目，员工的大量时间必然被浪费在“上下文切换”中，却没有任何实际产出。

第 34 章                     社区的形成

现代社会的钢筋森林让人们在生活中不太容易形成社区了，你可能对你的邻居并不了解。但是，这也正刺激了人们对社区情感的渴望，这种渴望有可能在公司中得到实现。

在公司中形成社区有什么好处吗？最直接的好处是：社区形成了维系愉快工作关系的情感纽带，这使公司能够留住人才。当然，这并不是说社区就能保证你的员工永远都不离开公司，而是说他们会舍不得离开，而且即使离开，他们也会选择在对公司和项目不利影响最小的时候离开。这正是社区的魔力，它使分手变得不那么痛苦。

软件经理怎样才能在公司内部建立起一个良好的社区呢？这项任务非常复杂，没有简单的答案可循。软件经理在这件事情上面需要动用自己的智慧、勇气、创造性和巧思。当然，软件经理仅凭个人的力量肯定是无法建立起社区的，软件经理应该把自己定位成“催化剂”，鼓励身边的同事一起来打造共同的公司社区。