程序员也要学会说不：如何与产品经理相处
作者：某厂搜索算法工程师，坐标杭州，2年百度履历，日常和Query理解、召回排序死磕，业余时间翻开源项目源码找乐子。最近在刷LeetCode准备跳槽，顺便更新简历。
上周五晚上九点半，我正对着屏幕调一个离线特征pipeline的OOM问题，钉钉突然弹出一条消息：“这个需求很简单，就加个开关，明天上线能搞定吗？”——又是熟悉的配方，熟悉的味道。我深吸一口气，默默把键盘推远了十厘米，避免自己一激动砸了电脑。
其实这已经不是第一次了。自从去年双11期间我们组因为临时改排序策略导致线上RT飙升30%，被SRE拉进小黑屋复盘之后，我就发誓：再也不能无条件答应PM的需求了。
那些年，我们被“简单”坑过的日子
刚入职百度做搜索算法时，我对“产品驱动”抱有浪漫幻想——以为是“产品提方向，技术来实现”的理想协作。结果现实狠狠打了脸。最经典的一幕发生在某次周会上：
PM：“我们就加个‘用户可能还喜欢’模块，逻辑不复杂，前端展示一下就行。”
我（天真）：“哦，那数据从哪来？用现有召回链路还是新训练模型？”
PM（微笑）：“你们技术看着办嘛，反正就是个推荐。”
后来我才知道，“看着办”三个字背后藏着多少坑。为了这个“简单”的模块，我们硬是重构了整个相关性打分模块，还临时搭了个轻量级向量召回服务。最后上线当天，因为没做缓存预热，QPS直接打爆Redis集群，凌晨三点被oncall叫醒修bug。
那一刻我悟了：不会说“不”的程序员，迟早变成救火队员。
技术人设崩塌现场 vs. 职业素养觉醒
在阿里网易扎堆的杭州，跳槽机会多，但竞争也卷。我更新简历时特别注意一点：不能只写“参与XX项目”，得写清楚“拒绝了哪些不合理需求，推动了哪些技术决策”。毕竟，一个只会点头的工程师，在面试官眼里就是个高级执行器。
举个真实例子。上个月有个PM想让我们在搜索结果页加个“实时热点词云”，要求每5秒刷新一次。我第一反应是：“兄弟，你当我们的ES集群是空气做的？” 但这次我没直接怼回去，而是做了三件事：
- 量化成本：拉出当前集群负载数据，算出新增请求会增加多少CPU和内存开销；
- 提供替代方案：建议用T+1的离线热词，前端加个“更新于XX:XX”的文案；
- 绑定业务目标：反问“这个功能的核心指标是什么？DAU提升？停留时长？”
结果PM自己退缩了——因为他根本没想清楚业务目标。你看，说“不”不是对抗，而是用技术语言把模糊需求翻译成可衡量的问题。
下面是我整理的“需求合理性评估表”，每次遇到模糊需求就甩给PM看（当然语气要友好）：
| 评估维度 | 合理需求示例 | 危险信号 |
|---|---|---|
| 目标清晰度 | “提升长尾Query的点击率5%” | “让页面看起来更智能” |
| 技术可行性 | 已有数据源/模型支持 | 需要从零训练新模型且无标注数据 |
| ROI评估 | 预估带来XX万GMV增长 | “竞品有，我们也得有” |
| 排期弹性 | 可配合大促节奏调整 | “必须明天上线，老板要看” |
代码可读性之外，更要维护“沟通可维护性”
作为一个注重代码可读性的工程师，我写Python函数都恨不得docstring写满三行。但以前在沟通上却是个“单行注释党”——PM问“能不能做”，我答“能”或“不能”，然后各自闷头干活。
直到有次因为误解需求，我吭哧吭哧写了三天的特征交叉逻辑，结果PM想要的是简单的关键词匹配。那天晚上review代码时，我盯着自己写的def calculate_user_interest_score(...) 函数，突然意识到：沟通也需要“接口文档”。
现在我的标准操作是：
- 需求评审时当场写Confluence文档，明确输入/输出/边界条件；
- 对模糊表述直接标红：“此处需PM确认具体规则”；
- 复杂逻辑画流程图，哪怕手绘拍照发群里。
有一次我甚至给PM画了张状态机图解释“用户从搜索到点击的路径分支”，他看完后沉默三秒，说：“原来这么复杂啊……那这个需求我们先放放？”
说“不”的正确姿势：从情绪对抗到价值共建
当然，也不是所有PM都通情达理。遇到那种“需求紧急程度=老板心情指数”的主，硬刚只会两败俱伤。这时候就得用点职场智慧。
比如，我会把技术限制转化成业务语言：
❌ “这个需求做不了，系统扛不住。”
✅ “如果强上，预计会导致核心链路延迟增加200ms，影响双11 GMV。建议先灰度1%流量验证效果？”
或者用数据说话：
# 伪代码：需求成本计算器
def estimate_cost(pm_request):
if "实时" in pm_request and "全量" in pm_request:
return {"engineer_nightmares": 999, "risk_level": "CRITICAL"}
elif "简单改个字段" in pm_request:
return {"hidden_workload": "refactor_entire_module", "time_estimate": "3人日"}
else:
return {"feasible": True, "but_let's_talk_details": True}
最关键的是——永远给台阶下。告诉PM：“不是不做，而是怎么做得更稳”。毕竟大家目标一致：做出好产品。只是我们工程师背负着线上事故的KPI，而PM背负着DAU的KPI，本质上都是打工人。
写在最后：你的简历里，该有“拒绝的艺术”
最近帮前同事改简历，看到他写“高效配合产品团队完成20+需求迭代”，我直接划掉改成：“主导技术方案评审，拦截5个高风险需求，保障系统SLA 99.95%”。
为什么？因为在真实的职场，能守住技术底线的人，才值得被信任交付核心系统。
所以，别再把“会沟通”等同于“好说话”。真正的专业，是在理解业务的前提下，用技术判断为团队避坑。当你能在需求评审会上平静地说出“这个方案有隐患，我建议这样调整”，而不是憋着火熬通宵修bug时——恭喜，你离资深工程师又近了一步。
至于我？刚拒掉一个“用大模型重写整个搜索链路”的脑洞需求，理由是：“当前QPS下，光推理成本就能烧掉我们部门半年预算。” PM听完居然笑了：“行吧，那先做个AB实验看看？”
看，会说“不”的程序员，反而更容易赢得尊重。
（完）
P.S. 杭州的兄弟们，最近阿里网易都在扩招搜索/NLP岗，有想内推的可以私聊。不过提前说好——如果你连PM的需求都不敢拒绝，咱可能不太合拍 😏
评论 0