程序员也要学会说不：如何与产品经理相处
上周五晚上十一点半，我正窝在出租屋的懒人沙发上调试一个 Rust 写的异步爬虫，突然钉钉“叮”了一声。打开一看，是我们组的产品经理小李发来的消息：“这个需求很简单，明天上线前加个导出 Excel 功能吧，用户反馈很急！”
我当时手里的 tokio::spawn 刚跑通，看到这条消息差点把咖啡泼到机械键盘上。这哪是“很简单”？这是要把我今晚的福报拉满啊！
我是谁？一个在 996 和开源之间反复横跳的 Rust 新手
先简单自我介绍一下：我是个远程办公的后端开发，目前在一家电商 SaaS 公司搬砖。每天从早上九点干到晚上九点是常态，偶尔还要配合海外客户时差开个夜会。但即便如此，我还是坚持每周抽时间看几个 GitHub Trending 上的 Rust 项目——毕竟，谁不想用更安全、更高效的代码，早点下班呢？
最近我迷上了用 Rust 写数据抓取工具。不是为了搞灰色产业哈，纯属技术探索。比如上周那个爬虫，目标是从某竞品平台抓取商品价格变动，用于我们的动态定价模型。写得挺爽，内存安全、零成本抽象、并发无惧……但爽归爽，一旦产品需求插进来，再优雅的代码也得给“业务价值”让路。
那次差点崩掉的双11：当“小改动”变成线上事故
其实我不讨厌产品经理。真的。我们组的小李人不错，请过我三次奶茶（虽然都是瑞幸券）。但问题在于，很多 PM 对“开发成本”的认知，还停留在“不就改几行代码嘛”的阶段。
去年双11前一周，也是类似场景。PM 说：“咱们加个实时库存预警吧，用户下单时如果库存低于10就弹窗提醒。”听起来合理对吧？但我一翻代码就头皮发麻——我们的库存服务是异步更新的，前端根本拿不到实时值！要实现这个功能，得重构整个库存同步链路，还得加 Redis 缓存层，外加压测验证。
我当时没敢直接拒绝，想着“算了，熬一熬就过去了”。结果呢？临时拼凑的方案上线后，当天下午高峰期 Redis 连接池爆了，订单服务雪崩。运维老哥在群里咆哮：“谁TM动了库存逻辑？！”——那一刻我真的想原地辞职。
那次事故让我明白：不会说“不”的程序员，不仅害自己加班，还可能拖垮整个系统。
学会“结构化拒绝”：用技术语言谈需求
从那以后，我开始练习一种叫“结构化拒绝”的沟通方式。核心思想就一条：别只说“做不了”，要说“怎么做才合理”。
比如这次 Excel 导出需求，我没有回“不行”，而是这样回复：
“李哥，导出功能可以做，但需要明确几点：
- 数据量预估多少？如果超过 10 万行，前端生成会卡死，得走后端异步任务；
- 字段要不要支持自定义？如果要，就得加配置表；
- 用户触发频率高吗？高的话得加限流，不然容易被爬虫刷爆。
咱们今天能对齐下细节吗？我评估下工时。”
你看，这样既展示了专业性，又把模糊需求转化成了可执行项。更妙的是，很多时候 PM 自己都没想清楚，你一问，他反而觉得“好像也没那么急”。
顺便提一句，自从我开始用 Rust 写爬虫，对“边界条件”和“异常处理”的敏感度直线上升。以前写 Python 脚本，遇到网络超时就 try...except 一把梭；现在用 Result<T, E> + ? 操作符，逼着我把每种失败路径都想清楚。这种思维迁移到需求评审上，就是天然的风险预判能力。
开发心得：技术人的“软技能”也是硬实力
很多人觉得程序员只要写好代码就行，沟通是“软技能”，可有可无。但现实是——在 996 的夹缝中，沟通效率直接决定你能不能活下来。
我总结了三条和 PM 相处的心法，亲测有效：
1. 用数据说话，别用情绪对抗
PM 说“用户很急”，你就反问：“具体有多少用户反馈？占比多少？”
PM 说“竞品都有”，你就查：“他们是怎么实现的？有没有性能问题？”
数据一摆，很多“紧急需求”自然就降级了。
2. 给选项，别给答案
永远不要只说“做不到”。而是提供 A/B/C 方案，附带各自的利弊和工期。
比如：“方案 A 两天搞定但体验一般，方案 B 一周但可复用，您选？”
3. 把技术债可视化
我们团队现在有个“技术债看板”，每次临时方案都记一笔，注明“下次迭代必须重构”。PM 看到越积越多，也会主动帮我们争取重构时间。
一个真实案例：用爬虫思维反制“模糊需求”
上个月，PM 提了个需求：“我们要监控全网对我们品牌的负面舆情。”
乍一听很虚，但我灵机一动——这不就是分布式爬虫的典型场景吗？
于是我画了张架构草图发群里：
[舆情源] → [URL 调度器] → [内容解析器] → [情感分析模型] → [告警通道]
然后列了个对比表：
| 方案 | 覆盖平台 | 更新频率 | 准确率 | 开发周期 |
|---|---|---|---|---|
| 现成 API | 微博/知乎 | 5分钟 | 70% | 2天 |
| 自研爬虫 | 全平台 | 实时 | 85%+ | 3周 |
| 第三方采购 | 全平台 | 实时 | 90% | 1天（付费） |
结果 PM 当场拍板：“先用 API 快速上线，效果好再申请预算买第三方。”——你看，用工程师的思维解构需求，反而赢得了信任。
在福报中寻找平衡：我的 Rust 式生活哲学
写到这里，窗外已经凌晨一点。我的爬虫还在跑，但心情比之前轻松多了。因为我知道，真正的专业，不是无底线接需求，而是在约束条件下做出最优解。
Rust 教会我一件事：所有权系统看似限制自由，实则避免了更大的混乱。和 PM 相处也一样——明确边界不是冷漠，而是对项目负责。
我现在给自己定了个小规矩：
- 工作日 9-21 点专注业务开发
- 每周三、六晚 21:30-23:00 雷打不动研究开源项目
- 周日上午陪家人，手机静音
听起来很难？其实只要前期沟通到位，PM 也会尊重你的节奏。上周我拒绝了一个周末加急需求，理由是：“这个改动涉及核心支付模块，仓促上线风险极高，建议排进下周迭代。” 结果 PM 回：“理解，安全第一！”
那一刻，我仿佛看到了 996 福报照进的一缕阳光。
最后几句掏心窝子的话
如果你也和我一样，在 996 的缝隙里坚持学习新技术，我想说：别把“说不”当成对抗，而要当成协作的开始。
产品经理不是敌人，模糊的需求才是。用你的技术洞察力帮他们理清思路，你会发现自己不仅少加了班，还成了团队里不可或缺的“靠谱担当”。
对了，我那个 Rust 爬虫最终加了 Excel 导出——但用了异步任务队列，还顺手加了防刷机制。上线三天，零故障。PM 昨天还问我：“能不能把这个导出框架复用到其他模块？”
你看，当你用专业赢得尊重，需求就不再是负担，而是展示价值的机会。
所以，兄弟们，下次再收到“很简单”的需求时，深吸一口气，敲下这行字：
“这个需求很有价值！咱们一起拆解下实现路径？”
然后泡杯咖啡，打开你的 IDE——用代码，温柔而坚定地改变世界。
（完）
P.S. 如果你也正在用 Rust 写爬虫，欢迎交流！最近我在优化 Tokio 任务调度，感觉还能再榨 20% 性能……（狗头保命）
评论 0