我的博客原文： blog.licsber.site/2024/03/29/人月神话的困境/

很多“聪明人”的思维都是线性思维，拿到任务，分解成小项，逐个完成，一步一步的像是在做证明题：期待着攒够一个又一个的事实和推理，最后拼图一般将它们串起来，达成某项任务。逻辑层面上看起来无懈可击，仿佛一切困难都可迎刃而解。
不可否认的是这套思维在应试方面屡试不爽，因为有一个天然的假设是存在的：“所有问题都有标准答案，问题在设计上就是逻辑可解的”。但是习惯这套“逻辑“的人，在处理现实世界的问题时，往往会不自觉地将自己带入死胡同。
我将这个方法论称之为逻辑关联，与之相对的即是事实关联，生活中不乏遇到这种思维陷阱：

白菜 3 块钱一斤，15 块钱可以买五斤白菜
你们工厂一个月可以生产 3000 个零件，那明天先给我 10 个吧
这个项目比较急，上次排期的工时是一周，我再给你一倍的人，三天给我做出来

有时候其实很难意识到这样的思考模式存在的问题，这也是《人月神话》里屡次提到的困境，可能上面的例子不太直观，代入下现实生活：

生一个孩子需要 9 个月，生一对双胞胎需要 18 个月
生一个孩子需要 9 个月，9 个妈妈是不是只要 1 个月？！

专注解决问题的思维方式久了，就会慢慢开始只在乎逻辑关联，而忽略事实关联，就会开始期待一种“银弹”，说是缘木求鱼也不过如此。
很多初级项目经理最常犯的错误就在这里，总是期待着任何事情都有一个进度条，这样就可以直观的反馈当前进展，自己要做的也就不过是按照排期表往下催进度。
这种人最喜欢问的问题就是“你这个要多久才能做出来？”，行使着身为“管理者”的特权，却不承担应有的角色义务。
项目经理这个角色，真正应该问的问题是“你还需要哪些其他的帮助可以提升你的速度？”。优秀的项目经理知道，项目进度不是靠完成了多少来判断，而是靠如何拥有足够的资源进行最大规模的试错。项目经理确保的应该是满足需求，成功交付，然而现实中 X-Y 本末倒置的现象非常普遍，即为了完成某个目标，制定了一些 KPI （关键绩效指标），最后完全忽视了原初的目标，而去追求后定的 KPI 。就像是前段时间北京环卫工人买新鲜白菜当厨余垃圾事件，政策目标是垃圾分类，管理者制定了每种垃圾必须的数量指标，然后只考察这个数量指标，下面执行的人就变了味，偏离初衷，最终酿成悲剧。
再者，项目经理在向上汇报进度的同时，也在享受作为一个管理者的荣誉，以及成功后收割胜利果实。这使得执行层面的人本身就对这些只能汇报进度，却无法承担执行工作的人非常敌视。
况且在软件开发这个对人依赖非常大的领域，管理起来更需要一定的水平积累。项目经理每天跟人打交道，要知道人是有感情的，绝对不是你给他输入 1+1 ，他就给你输出 2 。同一个功能点同一个人，由于其工作状态的差别，也会产生巨大的差异，如果主动积极做，可能只要 1 天，消极怠工的做，就无法预期了。这在传统行业是无法想象的，因为只要按规定的程序和规范来做，即使换一拨工人，也可以在同样的时间建造出来，建出来的房子的质量也不会相差太远。要知道，再烂的挖土机也能挖出一个大坑。
执行时，对软件工程师来说，遇到问题，解决问题。但如果遇到的问题占用了比预期更多的时间，则是对自己能力和自信的打击。此时如果项目经理也不专业，硬推进度，工程师就会出现一些掩盖问题的行为。
我总觉得，负责技术攻坚的人也去追进度就很可惜。悲剧的根源是管理能力和技巧的不足，如果真的想做到结果导向，需要的是目标的制定和拆解，工作计划的精确评估和执行，真实有效的复盘，信息同步与应对突发状况的能力，这些都对领导者有很高的要求，如果能力不足以管理结果，那大家就只能来管理过程，最终陷入恶性循环。
参考
工程师想要做管理？先改变你的思考方式
从程序员到项目经理：为什么要当项目经理

本质上是因为缺乏外部竞争，如果有足够的外部竞争，内部还能屎上雕花？为什么缺乏外部竞争？还用说？

＃1 确实 现状的外部环境可以称得上岁月静好了

今天读过一篇类似的文章，项目的压力往往不仅项目本身，管理能力也是必不可少的 frontendmastery.com/posts/the-three-ds-of-frontend-feature-leading/

这是管理学领域的问题，引用德鲁克的名言：If you can't measure it, you can't improve it

＃3 很同意里面的一句话“一个人可以走的很快 但是一群人可以走的很远”但是只在创业团队里见到过志同道合的一群人 生活中还是太少见了呀 大家的圈子都是什么样子的呢 ＃4 人的工作可以量化吗 感觉重复性的工作可以 创造性的工作很难比较吧

大部分人没有这种思维。没办法，你看能有效沟通的人即使在程序员里有几成？三四成最多了。

一个公司首先是要活下来， 如何能活下来，就如何管理，等公司有钱了在去谈管理，否则都是空谈， 饭都吃不饱，你就跟他谈理想，有什么用。

公司要的是盈利， 股东要的是分红， 员工要的是按时发工资。你管理的再好，前面 3 个目标完不成，有什么用，都是空谈。

＃5 可以参考大厂的工时制度，就互联网领域而言，大部分的“创造性”工作是有迹可循的，比如开发个 XXX 系统，无论是代码层、数据层、视觉层、业务层都有相应的设计模式可参考，对于经验丰富的管理者来说，做好拆解工作后，工时评估结果与实际情况不会相差太大。实际情况是，大多数人在 coding 前连个图纸都不画，脑袋一拍就开干，这种情况下，要评估工期就是个笑话。

＃5 “所有问题都有标准答案，问题在设计上就是逻辑可解的”就产品研发领域而言，不存在标准答案，在不同业务场景下，解决方案差异很大。哪怕就研发领域而言，干同一件事，用什么编码语言、什么框架、是继续维护现有的项目还是重构项目，充满了各种不确定性，根本不存在标准答案。如何在这种不确定性下，带领团队把活给干了，这个就是管理的水平了。可以了解下传统行业的“供应链管理经理”，一边要尽可能准确的预估未来产品的销量，另一边还要管理好研发提前把东西生产出来，以避免供应不足。

＃10 生产多了，库存压力大，可能会滞销，会导致资金压力大。生产少了会让公司损失收益，还可能会导致供应时间过长，降低客户的评价。可以想想这活多难。

主要现在工作需求专业也来却强，外行领导内行就会没事找事。不过现在这年头指望一个明君不如来个和稀泥平时不干事儿的，不拖后腿瞎加码比那种自我表现欲强的“管理经济学”出身的四处挖坑强的多

小公司的项目经理，找只鹦鹉也能干：天天“进度咋样了”就行

＃9 你这根本不是创造性的工作。这只是照着抄罢了。

现实是螺旋上升的，停留在“人月神话”的层级，其实背后可能是放弃对更高效的产研团队合作和系统设计的追求，鼓吹模糊论不可知论9 个孕妇 1 个月生不出孩子是事实，9 个工程师 1 个月也许确实做不出所谓 9 人月的工程，那么我们需要能够回答 9 个人到底需要多少时间的勇气和智慧，需要回答是裁员 8 个人然后做 9 个月，还是同时做 9 个项目，还是 3 人一组同时做 3 个项目越是简单又正确的理论往往越是只能回答和现实距离遥远的抽象问题，可以用来试图理解现实问题，但当真的话，基本只是回避现实的复杂性。就比如人月神话的一个隐藏假设是不同工程师个体投入相同时间就能获得相同的产出

＃6 有效沟通确实很难 所以有时候我也会迷茫于要不要在精神上“自杀” 干脆随他去吧但是我觉得不应该这样 所以宁愿清醒地痛苦着 尝试做点什么改变这一切 ＃7 ＃8 确实存在着这样的诉求关系 就像现在的外卖问题一样 平台、用户、骑手也是死局但是团队问题和外卖又不太一样 外卖行业还有一个外部力量政府在管理 团队就只能倾向于自行磨合平衡 ＃9 ＃10 ＃11 所以说现在很多管理都是照猫画虎 只学到了皮毛 学别人做甘特图 做进度排期然而根本不知道目的是什么 以过程当做目的 现象太普遍了 但现在大家又匆匆忙忙 难以思考和学习总结这也造成了草台班子现象随处可见 混日子比比皆是 难以破局感觉你说的更像是有明确衡量指标的生产环境 对于科研之类难以量化的情况就不太适用了现实世界就是因为没有银弹 没有所谓的标准答案 才会有 N 多不同的可能性 N 多不同的结果 ＃12 外行领导内行 现在在我看来这种情况其实还好了（最怕的是自以为懂的内行领导内行 那真就是完全的一片混乱 学到某某框架看起来好就强推 自己也没实验过想要解决 X 问题 自己想出了 Y 方案 就让手下的人执行 Y 方案 丝毫不讲 X 问题是什么 也不讨论是不是有更好方案 ＃13 哈哈哈 小公司真的有项目经理吗 ＃15 嗯 目前模糊论和不可知论确实能解释很多现象 管理也是在不断进步的自己也在尝试阅读这方面的新产出、新成果 但是作为底层其实很难实践 只能先积累（屠龙之术

对艺术的理解深刻，我们缺乏这级别的想象力 😂

＃4 那管理学可能不太适合软件工程了，代码的复杂度确实比人目前接触其它项目复杂度要高几个量级，建筑结构你可以大差不差弄个结构，算一下应力，然后留好余量就行，机械可以参考公差配比。但是你见过代码传一个参数 这个参数 数字多+1 还能正常运行，何况在这个基础上还要加上一堆 历史遗留的东西，例如历史遗留代码，新增一个字段，好几个系统全得改，还不能漏，还要检查这些字段 是否有其他使用方式，冷不丁的你还要防止之前历史上有没有人 依赖这个字段，或者给你挖过坑之类的

代码复杂度跟要不要管理是两码事，相反，软件越是复杂越要管理，无论是专门的技术领导还是开发者自己来管理。软件工程本身就是利用工程化的方法来构建系统，比如系统架构设计，这就是对代码的“管理”。如果只是把“管理”理解为管人，那就太局限了，这个只是国内大部分企业的管理学，管理学领域有很多非常科学的

op 这个吐槽，其实很长一段时间 都不太可能改善，这本质上并不是一个软件工程上的问题，而是一个资本跟劳工的问题，首先目前软件行业应用的地方很多，在国内依旧属于新兴行业，虽然从业人员收入高，但是架不住行业利润率确实比其他行业高，所以在资本面前，人力显得极其便宜。在这个基础之上，你谈任何软件工程都是空中楼阁，因为没有人会关心这个，老板不会关心，你的领导也不会关心，飞书可以招 8000 人养蛊，大公司内部一堆乱七八糟的项目，有没有用反正先上了再说，至于后面需要改动，没人 care ，先升职加薪再说，至于：业务心智模型要不要建立，是否遵循 DDD 建模，business logical 代码是不是尽量避免重复，代码结构是否应该清晰，是否需要有清晰的分层，是否应该做好系统设计，避免逻辑散落在各个服务里面，是否建立一个防腐层之类的这些很重要么？我跟你说，在我待过的这么多公司里面，几乎没有一个团队的 leader 在乎这个，原因无他，代码能跑 + PPT 糊弄就完了，如果一个事情在长期内有价值，在短期内无法给你带来升职加薪。你放心这个事情，除非是傻子才可能会去做。难道中层领导 主力研发 都看不到 代码在腐烂，业务逻辑在失控，未来需要极高的代价去填坑么？他们并不傻，只是因为人力太便宜了，所以请几个应届生去 业务逻辑的屎山里面吃屎就完了，顺带还解决了就业问题，更何况屎山本身还是一条护城河

我赞同＃15 楼的反对鼓吹模糊论的说法，部分开发者鼓吹模糊论是因为他自己都不知道自己写的代码会有什么影响。写代码前没测试，代码上线后没有遥测系统，这些都是软件工程领域经过大量案例证明有效的实践。

能跑就行。任何多余的操作都是增加风险，多做多错。领导说：你不干有的是人干。既然如此，打工人为啥要投入精力提升。

能不能发个公众号，我想点一下《在看》按钮，TnT~