线性思维坑了多少聪明人
很多“聪明人”的思维都是线性思维，拿到任务，分解成小项，逐个完成，一步一步的像是在做证明题：期待着攒够一个又一个的事实和推理，最后拼图一般将它们串起来，达成某项任务。逻辑层面上看起来无懈可击，仿佛一切困难都可迎刃而解。
不可否认的是这套思维在应试方面屡试不爽，因为有一个天然的假设是存在的：“所有问题都有标准答案，问题在设计上就是逻辑可解的”。但是习惯这套“逻辑“的人，在处理现实世界的问题时，往往会不自觉地将自己带入死胡同。
逻辑 vs 现实
我把上面那种叫”逻辑关联”，与之相对的是”事实关联”。生活中这种思维陷阱到处都是：
- 白菜3块钱一斤，15块钱可以买五斤白菜
- 你们工厂一个月能产3000个零件，那明天先给我10个吧
- 这个项目比较急，上次排期一周，我再给你一倍的人，三天给我做出来
听起来好像没毛病？但仔细想想：
- 生一个孩子需要9个月，生一对双胞胎需要18个月
- 生一个孩子需要9个月，9个妈妈是不是只要1个月？！
有时候其实很难意识到这样的思考模式存在的问题，这也是《人月神话》里屡次提到的困境。
专注解决问题的思维方式久了，就会慢慢开始只在乎逻辑关联，而忽略事实关联，就会开始期待一种“银弹”，说是缘木求鱼也不过如此。
初级项目经理最爱的蠢问题
很多初级项目经理最大的毛病，就是总觉得所有事都该有个进度条。这样他们就能直观地”看到”进展，要做的也不过是按排期表往下催。
这种人最喜欢问：”你这个要多久才能做出来？”
享受管理者的权力，却不承担该有的角色义务。
项目经理真正该问的是：”你还需要什么帮助才能做得更快？”
优秀的项目经理知道，项目进度不是靠”完成了多少”来判断的，而是靠如何拥有充足的资源去大规模试错。项目经理的任务是确保需求被满足、项目成功交付。
但现实里X-Y本末倒置的现象太多了：为了完成目标定了一堆KPI，最后完全忘了最初的目标，只顾着追KPI。就像前阵子北京环卫工买新鲜白菜当厨余垃圾事件一样————政策目标是垃圾分类，上面定了每种垃圾的数量指标，一执行就变了味，最后闹出笑话。
程序员不是推土机
还有一种常见的误区：很多项目经理在向上级汇报进度时，乐于享受“管理者”的光环和成果，却常常忽略了一线执行者的感受。这也是为什么一线员工本能地反感那些只会催进度、不懂业务、不下场执行的管理者。
本质上，软件开发的最大变量是“人”，“人”不是可以随意替换的零件。对“人”的管理，远比流程管控复杂得多。写代码不是搬砖，项目经理面对的，是有情绪、有思考、有惰性、更有创造力的活生生的人。你不能指望给出1+1，总能收到2的结果；同样的任务，同一个人在不同状态下，效率和成果也可能天差地别。积极主动时，1天就能搞定；消极怠工时，再多时间也谈不上交付。
这正是与传统行业的根本区别。造房子，哪怕换了工人，只要按照规范施工，进度和质量差异不会特别大；但在软件开发中，再烂的挖土机也能挖出一个坑，而最厉害的程序员如果状态不佳，也可能写出一堆“屎山”代码。
因此，优秀的项目经理绝不是填进度表、出汇报PPT那么简单。管理“人”是一项更高阶的挑战。
悲剧是怎么炼成的
对工程师来说，遇到问题、解决问题是日常。但如果问题占用了远超预期的时间，那就是对自己能力和自信的打击。
这时候如果项目经理不专业，硬推进度，工程师就会开始”掩盖问题”。
我一直觉得，让负责技术攻坚的人去追进度是件很可惜的事。悲剧的根源其实是管理能力的不足。真想做到结果导向，需要的是：目标的制定和拆解、工作计划的精确评估、真实有效的复盘、信息同步和应对突发状况的能力。
这些都对领导者要求很高。如果能力不足以管理结果，大家就只能去管理过程————那结果便可想而知了。