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