多元思维模型-别急着加人.md 9.8 KB
title: 老板老问工期能不能再快点，怎么聊 date: 2026-03-11 20:00:00 author: Gamehu tags:
- 思维模型
- 团队管理
- 查理·芒格 categories:
- 技术管理 ---
最近输出有点频繁，主要是这几天项目没那么满，再加上龙虾每天都在逼我成长，老跟我聊各种话题。
今天刚好聊到一个很典型的管理问题：老板觉得工期慢，或者会追着问一句“这个时间还能不能再快点？”后来回头看，这事儿还真不是一个维度能说清的。
这事我是真踩过坑。
前阵子带团队做项目，老板很着急，想尽快把产品推出来。这个诉求本身没毛病，谁做项目不想快一点呢。
问题是，每次汇报进度，他都觉得还是慢，或者会继续追问一句：
“这个时间有没有办法再压一压？”
这句话听起来很普通，但真落到团队身上，杀伤力其实不小。
因为它后面往往会带出一连串动作：要不要加人，要不要并行，要不要砍流程，要不要先糙一点上线。
我后来回头看，问题根本不是一句“人不够”能解释的，甚至很多时候，核心矛盾都不是“要不要加人”。
真正的问题是：老板觉得慢，到底是真的慢，还是大家看问题的角度不一样？
如果硬套芒格那句老话，就是：别一上来就拿一个动作当答案。
单一思维最容易把人带沟里
工程师和老板在这件事上，其实都很容易掉进同一个坑：
- 进度慢
- 开始着急
- 立刻想办法压工期
- 先上动作，再看问题
逻辑听起来很顺，但现实里经常不成立。
因为软件研发不是搬砖。你以为自己在压时间，实际可能只是把复杂度、返工和沟通成本往后推。
所以这类问题，如果只用一个视角看，很容易越搞越乱。你得换几个角度一起看，才比较接近真相。
下面这几个角度，是我后来觉得最有用的。
五个视角，拆开看这件事
1. 心理学：损失厌恶——团队不一定是不会干，可能是不敢快
很多团队进度慢，不是因为能力差，而是因为大家怕出错。
一旦环境里“延期要挨骂”“出问题要背锅”这种信号太强，团队就会本能地保守。估时往大了估，执行往后拖，很多人宁愿慢一点，也不想冒风险。
这时候表面上看像是效率低，实际上是恐惧驱动出来的低效。
这种场景下，你跟老板如果只说“时间不够”，他通常听不进去。更有用的话术反而是：
“我观察下来，团队最近估时都比较保守，执行也容易拖到后面。不是大家不想快，更像是怕出问题。要不要先看看是不是当前沟通方式让大家太怕犯错了？”
这个说法的关键，不是替团队喊冤，而是把“慢”从能力问题，拉回到环境问题。
2. 经济学：边际效用递减——你想压工期，先算算代价
很多人一听“能不能更快”，第一反应就是加动作。
比如：
- 多上几个人
- 并行做更多事
- 少做一些校验
- 先把过程压扁
但经济学里有个很朴素的点，叫代价。
任何“更快”都不是白来的，你这边省下来的时间，往往会在另一边以返工、沟通、质量风险的形式补回来。
其中最典型的，就是中途加人。团队从 3 个人变成 5 个人，看上去只多了 2 个人，但沟通路径会从 3 条变成 10 条。再加上新人熟悉业务和上下文，短期内未必真能把工期压下来。
所以这时候你跟老板沟通，不要只说“压不了”，而是把代价说清楚：
“如果要继续压时间，不是不行，但代价得一起看。比如中途补人，短期内协作成本会明显上升；如果砍流程，后面返工和质量风险也会跟着上来。”
这类话比“我们已经很努力了”更有效，因为它是在聊投入产出。
3. 系统论：瓶颈理论——老板看到的是工期，项目卡住的可能是别的地方
这是我后面越来越信的一件事。
很多项目看起来卡在开发，实际上真正堵住节奏的，压根不是开发。
常见的瓶颈可能是：
- 需求反复改
- 产品决策慢
- 测试环境不稳定
- 关键人拍板不及时
- 上下游依赖一直等
如果真正卡住项目的是这些地方，那你就算拼命压开发时间，也不一定有用。
就像高速收费站堵了，你在后面再多放几辆车，意义并不大。
我后来比较常用的做法，是先把时间花在哪儿拆出来。比如开发占多少、等确认占多少、返工占多少、等环境占多少。只要这个账一拉，很多争论就会自动消失。
因为当你能明确说出：
“开发只占整个周期的 30%，等决策和返工占了大头。”
那老板自然就会明白，问题不在“开发还不够快”。
4. 概率论：规划谬误——不是大家故意乐观，是人天生就会低估难度
项目管理里有个很烦但很真实的事：大家总会低估复杂度。
估计划的时候，脑子里默认都是理想状态：
- 需求差不多稳定
- 没有特别难的坑
- 联调不会出问题
- 关键人能及时回复
但真实项目哪有这么顺。
所以很多“老板觉得慢”的背后，其实不是团队真慢，而是最开始那个预期本来就立得太乐观。
这时候最有用的不是争辩，而是把历史数据翻出来。
比如你可以这么聊：
“同规模的需求我们过去做过 4 次，平均耗时是 3.5 周，最短也接近 3 周。现在按 2 周来压，风险会很高。”
一旦把“我感觉”换成“历史上就是这样”，沟通就会轻松很多。
老板不一定认同你，但他很难无视数据。
5. 决策理论：选项设计——别只回一句"压不了"，给他选项
这是我自己吃过亏之后改得最明显的一点。
以前老板一问“还能不能更快”，我第一反应就是解释为什么快不了。后来发现这种沟通方式很被动，因为你只有一个姿态：否定。
否定久了，对方很容易觉得你是在挡事。
更好的办法，是别只给结论，给方案。
比如直接摆三个选项：
方案 A：继续压工期，比如补人或者并行赶工，短期看上去积极，但协作成本和质量风险都会上来。
方案 B：先切核心功能上线，剩余部分下一轮补，整体节奏更稳。
方案 C：不继续压时间，接受延期一周，把质量保住。
这时候你不是在和老板对抗，而是在帮他做决策。
很多管理沟通，关键不在于“你说得对不对”，而在于“你有没有把选择面铺开”。
我后来是怎么处理这类问题的
后面再碰到类似场景，我基本会先做三件事。
1. 先找真实瓶颈
别急着下结论，先看时间到底耗在哪儿。
开发慢，只是结果。真正的原因，可能是确认慢、返工多、依赖卡住，甚至是汇报链路太长。
2. 汇报时别只报进度，要报权衡
我后来比较喜欢把方案讲成“快、稳、折中”三个版本。
- 快：能更早上线，但要接受技术债和返工风险
- 稳：周期更长，但质量更可控
- 折中：先上核心，剩下分批补
这样老板听到的就不只是“你们做不完”，而是“不同选择分别意味着什么”。
3. 核心团队尽量小
很多事情不是人越多越好，尤其是前期探索阶段。
团队小一点，沟通短一点，边界清一点，节奏通常反而更快。真要补人，也尽量补在外围，不要一股脑全塞进核心链路里。
一个很实用的自检框架
下次老板再说“这个时间还能不能再快点”，你可以先在脑子里过一遍这五个问题：
| 视角 | 先问什么 |
|---|---|
| 心理学 | 团队是在缺能力，还是在怕出错？ |
| 经济学 | 如果继续压工期，代价会落在哪？ |
| 系统论 | 真正的瓶颈到底卡在哪个环节？ |
| 概率论 | 现在这个时间预期，是不是本来就太乐观？ |
| 决策理论 | 除了死压时间，还有没有更划算的选项？ |
有时候你把这五个问题想清楚，答案基本就出来了。
写在最后
我现在越来越觉得，管理里很多“看起来很简单”的问题，其实都不能只拿一个招去解。
老板觉得慢，未必是真的慢。
他说“能不能再快点”，很多时候也不是在指挥具体动作，而是在表达压力、目标和预期。
而我们如果只会回一句“快不了”，那本质上也没有把问题讲清楚。
多元思维模型对我最大的价值，不是让我显得懂很多学科，而是提醒我：
先把问题看准，再决定用什么办法。
不然的话，压工期、加人、砍流程，最后都可能只是看起来很努力。
你最近如果也碰到类似的问题，不妨别急着给动作，先换两个角度看看。
很多时候，真正该先补的不是人，而是对问题的判断。
参考资料
- 《穷查理宝典》（Poor Charlie's Almanack） - 彼得·考夫曼（Peter D. Kaufman）编，2005 年
- 查理·芒格 1994 年南加州大学商学院演讲 - 《论基本普世智慧及其与投资与商业的关系》
- 《人月神话》（The Mythical Man-Month） - 弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）著，1975 年
- 《目标》（The Goal） - 埃利亚胡·高德拉特（Eliyahu M. Goldratt）著，1984 年
- 丹尼尔·卡尼曼（Daniel Kahneman） - 损失厌恶（Loss Aversion） 理论