《人件》 学习笔记 之一
第 I 篇 管理人力资源
这一篇中的章节讨论软件项目经理如何管理手下的程序员。
绝大多数软件经理有一种特别不好的习惯：总是把人当作模块组件来管理。这种习惯的起源可能是软件经理在作为技术人员期间接受了很好的“模块化”的熏陶，因此当他们成为管理人员之后，这种“模块化”的思维也惯性地成为了他们的管理方式。
不幸的是：这种方法并不有效。我们将在本篇中讨论管理程序员的“非模块化”方法。
第 1 章 在今天的某个地方，一个项目正在失败
绝大多数以失败告终的软件项目，其失败的原因不是技术水平不够，那么这些项目的失败原因又是什么呢？
本质上，软件经理工作中的主要问题，不是技术问题，而是社会学（sociology）问题。基于这样的观察，软件经理最应该花时间关注的是“人”的方面的问题，而不是“技术”方面的问题。软件经理把精力错误地集中于技术方面，而不是人际关系方面的主要原因，不是因为技术方面更重要，而是因为它更容易做。人际关系是很复杂的，并且就其效果而言也并不明晰清楚，但是它却是软件经理工作中最重要的方面。
软件经理只有把关注点放在“人员”方面，而不是“技术”方面，才是在工作中真正走上了正道。
第 2 章 做吉士汉堡，卖吉士汉堡
软件业和传统制造业有根本的不同，因此管理软件工程师的方式与管理产业工作的方式也有天壤之别，两者甚至是截然相反。下面的表格表明了两种管理方式的巨大差异。
| 传统制造业的经理这么做 | （优秀的）软件业的经理则这么做 |
| 不允许员工犯错，因为任何形式的错误都会导致整个组织运营效率的下降。 | 营造允许员工犯错的氛围。对于脑力劳动者而言，偶尔犯一个错误是自然的，也是他们工作的一个健康组成部分。没人犯错只能说明没人敢于尝试。出现问题，不要责备，而是弄清原因。 |
| 采取强硬手段迫使员工工作，而不是偷懒耍滑。 | 很少需要严厉的措施来迫使员工工作。软件工程师大多是热爱工作并且自我激励的。软件经理甚至需要采取措施让员工少做些工作，从而做更有意义的工作。 |
| 漠视个体员工的个性，把所有员工视为可拆换的机器零件一样看待。 | 理解每位员工都是一个不可复制和替换的独特个体，充分尊重每位员工培养其独特性的举动，而不会视其为对自己权威的挑战和威胁。 |
| 力争让生产系统处于稳定状态。 | 软件项目没有“稳定状态”这个概念，否则就只是死水一潭。软件项目需要的是参与人员全都融入项目和团队，给团队带来活力，让项目持续推进。软件经理的职责就是寻找到恰当的凝聚剂和催化剂，让团队成员凝聚在项目周围，充满乐趣地工作。 |
| 消灭思考。员工不需要考虑任何与工作有关的事情，只要照指令行事把任务完成就行。 | 鼓励员工多花点时间来思考工作本身，而不要只埋头苦干。必要时，通过做些头脑风暴、培训、阅读活动、知识分享等来帮助员工打开思路和视野。 |
第 3 章 维也纳在等着你
强迫手下的程序员在没有工资的情况下加班加点地工作，这是软件经理容易犯的一个错误。软件经理对此最爱用的借口就是项目进度异常紧张，而按时交付又异常重要。
有许多理由可以证明这种“胁迫员工更努力、更长时间工作”的做法是完全错误的：
l 员工可以加班，但是其后果是那总伴随着一个相等时段的补偿性“减班”，比如员工会打电话、闲谈、甚至干脆就是请假休息。
l 要求员工加班加点完成工作，这本身并不是在提高生产力，而只是一种剥削和榨取。一旦员工明白过来，他就会离开团队，这才是团队最大的损失。
l 用一个本就不可能按时完成的进度表来给员工施压，这样的结果不是让员工工作得更好，只是让他们工作得更快。
第 4 章 质量——如果时间允许
人都有一种强烈的倾向，就是把我们的自尊同我们生产的产品的“质量”联系在一起。因此，产品的生产者倾向于强调他们自己的质量标准，而对于产品的购买者，由于产品质量并不同其自尊心挂钩，因此购买者的质量标准往往会低于生产者的质量标准。
把这种现象投射到软件业上，软件工程师对软件产品的品质要求往往会高于市场标准。那么，软件经理应该站在哪一边呢？是鼓励员工追求卓越品质，还是向较低的市场标准妥协？
有若干理由表明软件经理应该站在员工一边：
l 对高品质的追求将带来更高的生产力水平，而这种更高的生产力水平将使公司长久受益。
l 如果于外部压力（如一个本就无法完成的进度表）而要求员工牺牲品质，这实际上是在伤害员工的自尊，这会导致员工产生直接反对你的情绪，进而引起人才流失。
因此，明智的软件经理会这样做：
l 在团队内部，树立质量意识，鼓励员工追求卓越的产品品质并交付令他们自身满意的产品。对本身具有较强品质意识的程序员加以奖励和宣传，从而让团队中的所有成员知道团队最看重的是“质量”而不是“速度”。
l 对外，顶住进度表等外界压力，让团队成员与这些压力尽量隔离。
第 5 章 重新研究帕金森定律
帕金森定律认为：无论给予一个项目多少时间，参与项目的人员总是会拖拖拉拉地将时间耗完，直到最后一刻才完工。帕金森定律带给管理者的启示是：给项目制定一个尽最大可能短的交付时间，然后在这期间催促项目人员拼命赶工。
对于软件行业而言，帕金森定律几乎总是不适用的。为什么？因为程序员大都热爱工作，大都不需要外界的驱使和命令就会努力工作。因此，如果软件经理不分青红皂白就给项目制定一个紧张的进度表，然后拼命催促程序员完成任务，那么项目的进展很可能不会太顺利。
让我们用新南威尔士大学的研究数据来说明问题。
| 制定项目进度表的方式 | 项目的生产力 |
| 由软件经理单独制定 | 6.6 |
| 由软件经理和程序员共同制定 | 7.8 |
| 由程序员单独制定 | 8.0 |
| 由系统分析师制定 | 9.5 |
由这张表格，我们看出：软件经理不参与项目进度表的制定，而把项目进度制定交给程序员或系统分析师，这样的项目的生产力水平会比较高。这就说明：如果程序员试图实现由他们自己所制定的目标，那他们就会更加努力地工作。
这份研究的最令人惊讶的部分是表格的最后一行：
| 制定项目进度表的方式 | 项目的生产力 |
| 由软件经理单独制定 | 6.6 |
| 由软件经理和程序员共同制定 | 7.8 |
| 由程序员单独制定 | 8.0 |
| 由系统分析师制定 | 9.5 |
| 不制定项目进度表 | 12.0 |
换句话说：软件经理不给项目施加任何进度上的压力，这样的项目反而具有最高的生产力。这就告诉我们：软件经理如果能够对外顶住进度上的压力，为团队营造出不赶进度的氛围，那么这样的团队反而能创造出很高的生产力。
第 6 章 苦杏仁苷
软件经理为了提高团队的生产力可谓是殚精竭虑。但是，软件经理必须把握住根本方向：处理好团队中的“人”的方面的问题，让员工愿意工作，而不是强迫员工工作，这才是管理的精髓。
此外，也有一些技术方面的手段可以提高团队的生产力。比如启用一套更合适的开发流程，换用一种更强大的开发环境和开发工具，使用新的编程语言。但是，这些技术方面的手段不应该是软件经理的主要考虑方面，只有团队中的“人”，才是软件经理最应该关注的。
