--- 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）](https://book.douban.com/subject/3550167/)** - 彼得·考夫曼（Peter D. Kaufman）编，2005 年 - **查理·芒格 1994 年南加州大学商学院演讲** - [《论基本普世智慧及其与投资与商业的关系》](https://www.jianshu.com/p/8b5c7b2b615a) - **[《人月神话》（The Mythical Man-Month）](https://book.douban.com/subject/1102259/)** - 弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）著，1975 年 - **[《目标》（The Goal）](https://book.douban.com/subject/25847387/)** - 埃利亚胡·高德拉特（Eliyahu M. Goldratt）著，1984 年 - **丹尼尔·卡尼曼（Daniel Kahneman）** - [损失厌恶（Loss Aversion）](https://en.wikipedia.org/wiki/Loss_aversion) 理论