《人件》第一章管理人力资源-CSDN博客

本文链接：https://blog.csdn.net/triticale/article/details/146714864

序

在2024年的冬天，我读完了《人月神话》这一软工领域的巨著，但是《人月神话》更偏向于软件过程，以布鲁克斯在IBM 360项目中的经历为主，从人月、队伍组成、管理模式、交流、实践、做减法、文档、工具、测试等各个方面阐述作者对整个过程中每个部分是否能提高开发效率，软件开发成功率进行论述，最后得出“没有银弹”能解决软件本身的根本性困难

但是《人员神话》中对人本身的论述是较为缺乏的，因此笔者看向了这本大名鼎鼎的《人件》

一、管理人力资源

我们一起来探索一种迥然不同的思考人及管理人的办法。这种办法考虑的是怎样去适应人的“非模块化”特征。

技术决定成败？以笔者的经历，在我见过的一部分项目中，决定这个项目是否成功的关键因素往往不是技术本身，因为技术大多就是一个“重复发明轮子”的过程，我们称自己的工作是赛博搬砖，从官方文档或者别人的经验贴亦或是开源项目中将别人的代码抄过来从而满足自己的业务需要，一个没有技术创新的项目正在滑向失败的深渊，那么使项目遭遇灭顶之灾一定是技术之外因素造成的

人件中作者经过十年的调研统计了500多个项目得出项目出现的问题：项目取消、终止、延迟或者交付产品从未被使用

导致这些的问题原因无非是产品交付的慢了、交付错了（需求问题）

随着项目越大，项目中部门越多，人员也就越多，部门与部门之间，人与人之间的沟通之间存在问题。

我们以谈恋爱举例，谈恋爱失败的原因会是仅仅因为没有钱导致的吗，我认为也不是，爱情的根源是人，人之外的因素会对爱情造成一部分响应，但是其根本原因还是人与人之间的问题

1.1 “政治”游戏

我经常喜欢说我很喜欢两个群体，一个是残疾人群体，一个是程序员群体（笔者没有对其他任何群体带有歧视）。因为这两个群体十分的纯粹，程序员对于技术之间的讨论是十分热爱的，创造性工作带来的满足感和成就感是其他活动或者娱乐所不能比拟的，但是与客户，与公司其他部门人员、与上级之间的交互不是技术难题，而是社会学问题

对于管理者来说，如果总是将对技术的担心看的更重，甚至越俎代庖将时间花在亲自解决技术难题时，这个管理者一定不是合格的管理者，我很喜欢我的第一个项目的项目经理，也是我的老师–胡老师。我的老师给我们整个团队充足的信任（即使当时我们还是刚从知识课程走出的小白），即使遇到技术上的困难，胡老师也是通过引导的方式来对进行帮助。

在《人月神话》焦油坑一章中指出，软件开发的乐趣之一就是亲自解决遇到的困难的成就感，如果管理者剥夺开发者的乐趣，寻找并不存在的“技术银弹”，将最重要的与人相关的要素放在最低优先级，那么在这场“政治”游戏中就很难成功

1.2 高科技的幻觉

在这里我想提出一个问题，我们开发者是高科技人才吗？

我的回答是我们不属于高科技人才，我们做的仅仅是高科技的应用，就像是几十年前智能手机刚刚出的时候，第一批会使用智能手机的人或许很厉害，但是会使用不代表会研发，而随着时代的发展，智能手机已经普及到几乎人手一台。

而现在AI大模型的发展也是如此，我们使用大模型写文章，写代码，看似是与高科技靠近，但实际上也只是调接口，应用AI罢了。有人会说，在AI的冲击下，软件行业会最先死去。但这种说法我并不完全认可，十年间互联网风口期软件行业高薪的辉煌并不代表这就是互联网行业的常态，现在行业平均薪资的下降也是一种恢复常态的标志。

一个培训班半年毕业的java程序员就可以入职互联网行业从而实现“月入过万”的辉煌时代已经过去了，现在AI时代要做的就是学习AI，使用AI。

刚刚跑题了，话说话来，在软件项目开发中，大多数人从事的是要与人交流的职业，我们的失败往往是与人的互动性的缺失。我们习惯专注于工作中的技术问题，是因为它足够简单，比如安装一块硬盘，安装一款软件，比寻思小张为什么整天忧郁更加简单。

1.3 标准化管理

在快餐行业标准化流程，把工人看做机器上可随意替换的零件，让整个流程趋向稳定是很常见的，但是在智力型的软件领域，这种风格与开发工作水火不容

对于脑力劳动者来说，工作偶尔出错再自然不过，对于脑力劳动者，往往把自己对问题的思考是否正确，是否被别人认可看的比一些物质满足更重要，我们都听说过Linus 和 Tanenbaum 对操作系统微内核和宏内核之间的讨论，二人都认为自己的观点更适用于当前的操作系统，但在讨论以外Linus 和 Tanenbaum仍保持着良好的关系。

笔者想通过这个例子表达，对于脑力工作者，标准化的管理会限制思维限制创造性，对于错误本身也不应过于指责以至于整个团队对出现失误持有戒心，针对天生容易出现错误的设计，可以考虑彻底抛弃而不是去修复，或者对于不能抛弃的设计，也应该通过MVP原则去迭代而非一次性实现一种完美的设计

1.4 傻瓜式管理

管理者负责全盘思考，他的手下照章办事，即使向人们施压可以增加短期产出，长远来看还是无效的。把人当做机器上的零件，一批坏了换另一批，这种傻瓜式的管理模式在脑力工作中是必然走向失败的，软件行业中大部分人都是热爱他们的工作的，没必要用这种傻瓜式“踢屁股”的方式促使大家工作，大家真正需要的是提供更多的动力，而非强制性管理。

1.5 人力商店

太多的管理者认为工作人员展现其个性是一种威胁，但公司是讲文化的，个人也是要讲文化的，个人文化和公司文化不相融一定会出现矛盾，表现出个人的个性化。

书中有这么一个案例，某位老板有一个富有才华的员工常年在外地到访客户现场，花销自然不少，但是对他的报销的分析显示他在食物上的花销远远超过了其他出差人员，于是这位老板给这位员工打上“食物犯罪”的标签，但这位员工实际上花费并没有超过预算，他在其他方面节省了。

对于崇拜生产世界管理风格的管理员来说，员工的个性是一种持续的困扰，但是前文也提到了，不应该把人看作是模块化特征，不能以黑盒的角度看待人本身，人性化的管理应该是使人的这种独特性和项目团队产生化学反应，是团队充满活力和高效的源泉。

1.6 稳定的项目濒临死亡

项目的生命周期的最终目标就是结束自己，项目唯一的稳定期就是将死之时。一个在开发期间和维护期间的项目是不可能做到稳定的，这是由软件的根本性困难所决定的(《人月神话》中没有银弹一章的观点）,那么既然项目只有在死亡的时候才是稳定的，我们在开发和维护过程中对于工作人员使用的却是稳定化的评估方法，比如这个员工写了多少代码，写了多少文档等等，而非是对该员工对项目带来的价值

举个不恰当的例子，如果团队中招募了一个十分漂亮，性格温柔的女同事，即使开发能力还不够成熟，但是和我进行双人编程的过程中能给我带来更多创作的动力，从而提高生产效率，那么这位同事带来的价值是否能按照她写了多少代码完成了多少功能来评估呢？

1.7 磨刀不误砍柴工

如果分配给你一个任务，你会花多少时间来真正实施这项任务，不可能百分之百，实施之前肯定需要一些头脑风暴、调研新方法、规避一些子任务的方法或者进行培训

我们花了太长时间去做事，却没有花足够的时间去考虑“这件事到底该不该做”，对于管理者来说，如果用稳定的管理模式驱动员工，让员工把大多时间都投入到做事情上，没有人去考虑这件事本事是否值得去做，团队会变得越来越不稳定。

比如将太多不值得做的任务分给你的员工，你的员工生产力不足，那么最先想到的解决办法是什么，招募新员工吗，但是我们读过《人月神话》，都知道在一个已经进度落后的项目中添加新的人员，项目依然会落后，对新员工的培训依然需要花费时间，花费成本。

思考方法，学习如何多花时间在思考上才是更重要的，项目的投入越夸张，成员越应该学习如何更好地协作，而非一味的苦干实施。

我最喜欢的书中一句话是：项目越是需要在一个无法完成的固定时间交付，项目团队越不能缺乏频繁的头脑风暴，或者项目组聚餐之类的活动来帮助团队形成一个统一的整体

最后还是一句话，磨刀不误砍柴工，以笔者自身经历举例，我会把一部分花费在买工作的设备上，买显示屏，好一些的键盘和鼠标。这些花费对我来说是非常值得的，因为他带来的反馈感会提高我的生产效率

1.8 西班牙理论和英国理论

西班牙理论认为世界上的价值总量是定额的，因为财富积累的道路就是学会从大地或者别人的背上去攫取。

英国理论认为价值通过智慧和科技创造出来的

西班牙的价值理论在很多管理者身上都有看到，无论你的员工工作多久，他们都按照每周5*8小时分配，而不是员工现实工作的80乃至90小时，虽然我们知道这更像是一种欺诈，通过各种方式连哄带骗地延长员工的工作时间，告诉员工DDL的重要性，但不可否认的是大部分管理者甚至个人都是西班牙理论的实践者，通过花费员工更多的时间降低产品价格而非通过创新提高生产效率

有一个很有意思的现象是如果一个问题本身并不复杂和困难，比如对某个系统进行改错和调优，可能对于一个有经验的人员来说花半小时就能搞定，但是甲方可能会认为，我花了这么多钱这么快就容易地解决了，是不是太吃亏了；相反，如果你拖了一两天再告诉甲方，这个东西如何如何的复杂，排查多少问题后才定位到是哪里的错误，甲方可能就会认为得到小便宜了，这钱花的真值啊

管理者使用各种手段让员工接收那些根本没有希望达到的进度安排，让他们因为内疚而不得不牺牲自己的其他时间来工作，对于这个问题的讨论笔者认为应该将生活和工作学习时间的投入能够恰当，即不至于牺牲所有时间在学习和工作上依然愧疚，也不至于完全躺平去追求自己喜欢的生活

1.9 平衡工作与家庭

书中对这一段的论述对我十分有感触

虽然你的员工在办公室里得到的信息是“工作时间长点、强度大点”，但他们在家里得到的信息却迥然不同。家里传递着信息：“生命正在流逝。衣柜里面堆着你的脏衣服，你的孩子们得不到拥抱，你的配偶正在寻找别的地方。那种被称为生命的旋转木马只有一圈，中奖的机会只有一次。如果你把你的生活都消耗在C++上…"

我有一个好朋友的父母因为事业长期在外地工作，从而导致和父母关系的疏远，和父母产生遥远的距离，这份与亲人渐行渐远的工作是值得的吗，或者换个角度，当你在公司疯狂加班，甚至晚上都不得不回家的时候，你的亲人对你的担心会让你考虑，你的这份努力或者是被管理者“欺诈”是值得的吗

1.10 不存在加班的谎言

加班所花费的时间却需要花费“地下时间”来弥补自己的生活，计算投入与产出，每加班一个小时，就需要一个或更多小时的“地下时间”来弥补。

比如我在田界智航项目组中，前期疯狂加班花费自己娱乐和休息时间完成工作，但是后面在工作中尽可能多的摸鱼来弥补曾经的损失，对于脑力工作者来说，没有人能真正工作超过40小时，至少不可能持续，加班就像冲刺，若一开始就冲刺，那就是纯粹的浪费时间。

在敏捷开发中，可以将工作让燃尽图一样进行下去，应该以一个稳定的状态去交付，过快以及过慢都应该进行调整。

1.11 工作狂

工作狂是一种病，但不像酗酒那样只影响不幸的少数人，工作狂就像常患的感冒，每个人都可能染上，而一旦工作狂认识到自己为了一些不那么重要的工作而牺牲了生命中更重要的价值，如家庭，爱情，青春等，这种打击会促使他们一旦这个项目结束后会永远离开这个团队。

所以无论如何加班，都不能让大家以牺牲个人生活为代价，失去好的员工绝对不划算。

1.12 赢得战斗，输掉战争

在《人月神话》中我们讨论过，招募新员工对于员工培训所花费的时间和经济成本是很大的，如果因为采用加压、流程机械化、牺牲质量或者标准化这些方式来提高开发效率从而导致“员工流失”是很不值得的。

这里还有一个有趣的故事，是通过降低别人的预期来保证别人的满意程度（不过是个反例）

在我早期的一个咨询项目中，项目运行平稳，项目经理知道她能够按时交付产品。她被叫到管理委员会（management committee）做进度报告。她说她可以保证产品在 3 月 1 日的最后期限完成，完全准时地遵循最初的估算。上层管理者仔细地讨论了这意料之外的好消息，第二天又把她叫来。他们解释道：因为她能够在 3 月 1 日准时交付，所以最终期限被提前到 1 月 15 日。

压力不会让工作做的更好，只会让工作做的更快

这句话我是认可的，但是对于不同时期的人来说压力不一定是一种坏事，对于精神麻木，没有自控力的人，施加一定的压力会促进他们的工作，因为并不是所有人都能够很好地控制自己，对工作一直保持热爱。

1.13 质量–如果时间允许

人们通常倾向于将我们的自信与生产出的产品质量紧紧关联，如果因为某些原因，从而不得不牺牲产品质量，生产出大量质量马虎的产品，从而使得带来的满足感很小，你的员工可能会挑起反对你的情绪。

管理者设定的不可达到的期限威胁着产品的质量，当员工处于极度的压力之下时，质量就开始被牺牲了。

也许管理者会说：“我们一些同志会为了质量在一个任务上无休无止，但市场才不管你什么质量–昨天就赶着要这个产品了，即使质量粗糙也行”，这句话对市场的判断是没错的，但是如果不能在上市之后将缺失的质量弥补回来，最后一定还是错误的。

客户想象的产品质量往往比制造者认为的要低，这是一个天然的冲突，降低质量可能会让一些人不再购买，即使通过降低成本提高单个产品的利润也无法弥补损失的市场占有率。

1.14 质量免费

质量免费是Philip Crosby在《质量免费》一文中提出的，但是宣扬的并不是质量免费，因为质量是无价的，其核心观点是只有愿为质量倾其所有的人，质量才是免费的。

一个组织如果为了质量一毛不拔，那么收获的质量也是一文不值的，提升质量是需要花费成本的，提高质量不代表牺牲生产效率，提高效率也不一定意味着生产效率的下降。

举个例子，假如客户要修改一个业务逻辑，在实现上可能就是修改一个SQL语句，但是依然要经过评审测试才能完成修改，如果为了追求效率绕过这些环节导致最终数据库挂了，最终的效率不见得是提高了

1.15 帕金森定律

帕金森定律是一位喜剧作家提出的，但并没有收集数据没有提供统计推论规则，这个定律被大家接受仅仅是因为十分有趣

帕金森定律认为工作会自动膨胀，占满一个人的所有时间

看到这里大家可能会想到，在敏捷开发中一次次冲刺最后都变成了加班，是不是正好论证了帕金森还是有一些道理的，一个平庸的管理者会招募很多比自己强的员工吗，我想是不会的，因为他们害怕员工会取代自己，那么平庸的管理者招募的会是更多的平庸的员工，恶性循环往复，最终整个团队都会平庸下去

帕金森定律所说的是官僚主义中存在的一些问题，在软件行业中，给一个能力欠佳(如快速培训出来)的人施加压力，他依然无法完成自己的工作。更合适的应该是调换工作或者跳槽到其他的公司

在这一小节中，我们讨论的是团体整体的问题，讨论了一种帕金森团队的组成，那么有什么办法能够促进团队的协调。

书中通过比较各种估算方法给产能带来的影响，得出的结论是能力越强的系统分析师给出的估算更为合理，因为他们既了解具体的细节，又不会陷入自然的乐观估计中。

不准确的估算，会消磨构建者的精力，通过加班来完成只会让项目团队变得更为烦躁和暴躁。

如果惩罚比较少见，而时间点也能够掌握得恰到好处，惩罚就可能起作用。若经常需要施以惩罚，就说明你自身是有问题的

1.16 软件行业的七宗罪

有不少对提高产能的说法，但是实际上就是虚假宣传，因为所有的简单手段在之前就已经被尝试和实施过，根本没有这种灵丹妙药

有一个你不知道的新窍门可以让产能飙升

错误的，这只是一种纯粹的心理上的恐吓战术，让你觉得这一神奇的创新不容错过
其他管理者正在收获 100%、200%乃至更多的增长

错误的，软件生命周期不仅仅有编码和测试，即使去掉某些环节也不能做到100%的增长
技术日新月异，你已经过时了

错误的，软件开发本身就不是高科技行业，技术的提升不会带来生死的决定，还要考虑项目成员对技术的偏好和学习成本
改变程序语言能带来巨大提升

错误的，编码本身在整个生命周期中占比并非最重的，而且编程语言也可能只是在编码阶段中能带来一点提升
因为backlog需要让产能翻倍

错误的，一个经济上的失败之作，项目根本不应该存在库存里
你自动化了所有其他东西就不能自动化掉你的你的软件开发人员吗

错误的，软件开发人员面对的最主要的问题是与人沟通，把用户的需求改变为正式的程序，这一步是无法自动化的
你的员工在巨大的压力下会工作的更好

错误的，员工更喜欢减少压力