最近重温《人件》这本书，看了一下购买日期是2022年10月14日。当时也不用管团队啊，看这书干嘛呢。现在也算是“温故而知新”了，简单写写读后感。

项目成败的关键是“人”

有时候我就会琢磨，要是当时招聘到的不是现在这帮人，回流项目还能做起来吗？恐怕不会吧。

以前总喜欢去讨论，X技术更好，Y编码方式更先进，Z语言永垂不朽等问题。说句实话，当年纪足够大，社会给予一定程度的毒打，这些都无关紧要了。一个项目不会因为用了Java而更容易成功，也不会因为选了PostgreSQL作为数据库就能安枕无忧。同样的工具，在不同的人手上可能会产生不一样的效果。也有能把Java写得很烂的程序员，用MySQL会遇到的性能优化场景，PostgreSQL未必就能躲掉。

本书的书名是《人件》，类比于常说的软件，硬件。项目的成败更多在于“人”，而非技术本身。书中提到的许多项目失败的根本原因还是在于对“人”的不够重视，过于纠结于技术本身就容易本末倒置。

项目最终也是是服务于人，无论技术多么先进牛逼，最终还是要人来提出需求，梳理需求，寻求合适的解决方案。这“人”的可贵之处，也是AI难以替代人类的地方。

无形的成本

项目上了轨道之后，技术团队就是肉眼可见的成本。

“狡兔死，走狗烹”的现象应该不仅仅出现在中国古代，海内外各国的职场上也会出现类似的事情，对于技术团队来说尤为如此。

如果熟悉楚汉争霸的故事应该了解笔者所说的意思，业内经常会把技术管理者比作韩信，技术团队就是打天下之后的军队。“这帮整天只会敲键盘的，怎么拿这么高的工资？”相信有这种想法的公司并不在少数吧。

渐渐地他们会把原来一个高薪的核心员工替换成几个底薪的应届生。这让笔者不甚唏嘘，确实只要给予足够的时间，几个应届生或许真的能够接手原来老员工的工作吧，但也只是MayBe。

他们觉得程序员只不过是敲敲键盘，多个人就相当于生产效率翻倍。能不能翻倍，这里且不讨论，毕竟有些东西很难量化。一个老员工工资2w，三个应届生加起来只需要1.5w，看似节省了5k块的成本，其实不然。说不定这帮人忽略了一些无形的成本：

• 忠诚与担当。老员工呆在一个地方这么长时间，对一个项目自有他自己的责任与担当，这是新员工在短时间内难以培养起来的。当然并不排除有那种吃大锅饭混日子的老员工，只不过您也知道，笔者抱不平的并非这帮人。
• 新员工的培训成本。老员工贵有贵的道理，关于系统的很多经验，不可能通过短短几个月就完整传达给新员工的。最起码，培训这几个月，新员工几乎是无法做核心工作的，相当于公司掏钱在培训他们。
• 沟通成本。以为多个人生产力就能翻倍，笔者也不知道该据理反驳好，还是随便给他们一个眼神就好。多个人意味着管理者调配人手的时候得多一层顾虑，手下人员之间相互的协调也会更加困难。降低沟通成本对于团队来说是一个永恒的话题。
• 故障恢复成本。不管您愿不愿意相信，一个系统很多细枝末节之处，在老员工离去（或者被离去）之前不可能事无巨细都记在交接文档上。也可能他们觉得这无关紧要，干脆不写了，但是对于新员工来说，一旦老员工离去，这将是难以绕过去的坎。说不定哪天系统就因为这事而崩溃了，新员工将难以在短时间内恢复。

其实从以上角度来分析，花多点钱，把有价值的老员工留住可能对公司来说更划算。有形的成本没错是升高了，然而所节省下来的时间成本却往往遭人忽视。

《人件》里面也提到了许多项目太过执着于有形的成本，而忽视隐形成本，最终导致项目的失败。挑选一个不成熟但是很便宜的服务看似省了钱，但是可能要花更多的时间去进行对接维护，还要忍受不太稳定的服务质量，这些成本我们都可曾考虑过？

犯错的自由

剥夺了团队犯错的自由，哪怕现今一切看起来运行良好，早晚也会出大问题的。

回流的技术团队发展至今已经两年多了，大伙因为缘分聚一起，共同完成了不少项目。当然也会存在一些问题，都在不断磨合优化中。

现在无论是团队合作，还是个人成长都渐入佳境，眼看是一件不错的事情。然而，读完《人件》这本书之后，笔者发现了一个挺大的弊端。没错，现在跟业务方只要对接完需求，笔者根据自己的判断往下分发并划分好优先级，大家都能有条不紊地完成所有任务，并得到业务方的尊重。然而为了避免成员们犯错误，笔者往往干涉太多，替他们考虑了很多本该由他们去思考的细节问题。这样一来犯错的机会确实少了很多，然而却剥夺了他们犯错的自由。

无论技术方面还是制度方面，回流这支技术团队一直处于不断优化的状态，也基本没犯什么大错。对比起很多的技术团队，这里还能远程工作，有一定的自由度。然而要想团队每个人都能独当一面的话，便要给予他们犯错的自由。人类还是善于反省的动物，在项目中吸取犯错的教训，记忆更深刻些，下次考虑问题应当会更为周全。这一切适合从旁指点却不宜代劳。

团队管理者，在前期越是殚精竭，团队的人便会越发依赖他。时间长了之后，管理者自己也容易筋疲力竭，队员们的成长空间也十分有限，是一个“双输”的局面。剥夺了团队成员犯错的自由，相当于变相剥夺他们成长的机会，长远来看也是罪恶的。

像《人件》中所说的，笔者应该只负责给成员们扫清前面的路障，适当的时候给予指点，具体的任务怎么协调，有哪些需要注意的坑，尽可放心交给他们自己解决。这样一来团队成员会有更大的成长空间，角色认知也会有所转变，不会只把自己当作写代码的无情机器，笔者也能喘口气去规划其他更重要的事情，何乐而不为呢？

尾声

以上就是笔者读完《人件》这本书之后的三点思考，书是好书，就是翻译有点不对口味，往后有机会还是找原版来读读。无论技术怎么发展，“人”永远都是项目成败最关键的因素，很多团队过于纠结于技术本身，而轻视了“人”这个因素。这或许也是许多项目失败的本质原因吧。