我的博客原文： https://blog.licsber.site/2024/03/29/人月神话的困境/
很多“聪明人”的思维都是线性思维，拿到任务，分解成小项，逐个完成，一步一步的像是在做证明题：期待着攒够一个又一个的事实和推理，最后拼图一般将它们串起来，达成某项任务。逻辑层面上看起来无懈可击，仿佛一切困难都可迎刃而解。
不可否认的是这套思维在应试方面屡试不爽，因为有一个天然的假设是存在的：“所有问题都有标准答案，问题在设计上就是逻辑可解的”。但是习惯这套“逻辑“的人，在处理现实世界的问题时，往往会不自觉地将自己带入死胡同。
我将这个方法论称之为逻辑关联，与之相对的即是事实关联，生活中不乏遇到这种思维陷阱：
有时候其实很难意识到这样的思考模式存在的问题，这也是《人月神话》里屡次提到的困境，可能上面的例子不太直观，代入下现实生活：
专注解决问题的思维方式久了，就会慢慢开始只在乎逻辑关联，而忽略事实关联，就会开始期待一种“银弹”，说是缘木求鱼也不过如此。
很多初级项目经理最常犯的错误就在这里，总是期待着任何事情都有一个进度条，这样就可以直观的反馈当前进展，自己要做的也就不过是按照排期表往下催进度。
这种人最喜欢问的问题就是“你这个要多久才能做出来？”，行使着身为“管理者”的特权，却不承担应有的角色义务。
项目经理这个角色，真正应该问的问题是“你还需要哪些其他的帮助可以提升你的速度？”。优秀的项目经理知道，项目进度不是靠完成了多少来判断，而是靠如何拥有足够的资源进行最大规模的试错。项目经理确保的应该是满足需求，成功交付，然而现实中 X-Y 本末倒置的现象非常普遍，即为了完成某个目标，制定了一些 KPI （关键绩效指标），最后完全忽视了原初的目标，而去追求后定的 KPI 。就像是前段时间北京环卫工人买新鲜白菜当厨余垃圾事件，政策目标是垃圾分类，管理者制定了每种垃圾必须的数量指标，然后只考察这个数量指标，下面执行的人就变了味，偏离初衷，最终酿成悲剧。
再者，项目经理在向上汇报进度的同时，也在享受作为一个管理者的荣誉，以及成功后收割胜利果实。这使得执行层面的人本身就对这些只能汇报进度，却无法承担执行工作的人非常敌视。
况且在软件开发这个对人依赖非常大的领域，管理起来更需要一定的水平积累。项目经理每天跟人打交道，要知道人是有感情的，绝对不是你给他输入 1+1 ，他就给你输出 2 。同一个功能点同一个人，由于其工作状态的差别，也会产生巨大的差异，如果主动积极做，可能只要 1 天，消极怠工的做，就无法预期了。这在传统行业是无法想象的，因为只要按规定的程序和规范来做，即使换一拨工人，也可以在同样的时间建造出来，建出来的房子的质量也不会相差太远。要知道，再烂的挖土机也能挖出一个大坑。
执行时，对软件工程师来说，遇到问题，解决问题。但如果遇到的问题占用了比预期更多的时间，则是对自己能力和自信的打击。此时如果项目经理也不专业，硬推进度，工程师就会出现一些掩盖问题的行为。
我总觉得，负责技术攻坚的人也去追进度就很可惜。悲剧的根源是管理能力和技巧的不足，如果真的想做到结果导向，需要的是目标的制定和拆解，工作计划的精确评估和执行，真实有效的复盘，信息同步与应对突发状况的能力，这些都对领导者有很高的要求，如果能力不足以管理结果，那大家就只能来管理过程，最终陷入恶性循环。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.