程序员也要学会说不：如何与产品经理相处

程序员也要学会说“不”：与产品经理相处的那些年

我至今还记得那个周五的下午。产品走过来，轻轻敲了下我的工位：“这个功能下周上线吧？你看需求挺简单的。”当时我刚从一个线上问题处理完回来，头还有点晕。没怎么想就点了点头。

结果那一周我们团队几乎全员加班到凌晨三点。需求看似简单，但背后需要做大量的架构调整和性能优化。上线前还出了个缓存穿透的问题，差点影响整个服务稳定性。

这是我职业生涯中一次非常深刻的经历，也让我开始思考一个问题：作为程序员，我们该如何正确地与产品经理沟通？更重要的是——要不要学会说“不”？

一、当技术理想遇上现实需求

事情发生在2019年底，我负责一个电商平台的用户中心重构项目。当时我们正在进行微服务拆分，目标是提升整体系统性能和可维护性。业务逻辑已经基本完成，数据库设计也考虑了读写分离和扩展性，整体架构朝着高可用方向推进。

就在这时，产品经理提出了一个新需求：在用户个人主页加一个推荐功能，“类似社交平台那样”，显示你可能感兴趣的商品、达人推荐内容。

这个功能本身不算复杂，但问题在于：

• 用户中心原本是个纯用户信息服务，突然要接入推荐系统
• 推荐数据需要实时计算，对QPS要求较高
• 项目时间已经被压缩得很紧，没有预留相关开发周期

如果我们直接答应下来，就得临时接入推荐系统接口、改架构、加缓存层……而这些改动一旦出错，可能会拖慢整个项目的进度。

于是我们开了一个会。会上我和CTO都明确表示：“这个功能现在接入不合适。”

那天之后，我就开始被叫去讨论很多次。产品经理问：“能不能只展示静态数据？”我说：“可以，但用户体验不好。”他问：“那少做一点，先做个雏形出来行不行？”我说：“可以，但后续维护成本会很高。”

最终的结果是：我们决定把这个功能独立出去，由推荐系统团队接手，用户中心只提供基础信息接口。虽然看起来有点“推责任”，但从技术和产品角度来看，这是最优选择。

二、技术决策背后的考量

这次事件后，我在内部做了一个简单的总结，分享了几个关键的技术点：

1. 架构设计：拒绝“越界”的逻辑入侵

我们原本的设计是：用户服务 → 提供基础信息 → 前端聚合其他服务（如订单、收藏等）。

推荐系统的介入会打破这种结构，使用户服务变得臃肿。这不仅会影响已有接口性能，还会增加未来维护成本。

所以我们坚持使用统一网关做服务聚合，而不是让单个服务承担太多职责。

2. 数据库设计：别让非核心业务污染主流程

推荐数据本质上属于冷热混合数据。如果强行把这部分数据写入用户服务的数据库，会造成索引膨胀、查询变慢。

后来我们决定采用异步同步的方式，将推荐数据写入另一个Redis集群，通过定时任务更新热点内容，确保用户访问的高性能。

3. 性能与容灾：不能因为一个小功能牺牲大局

推荐接口一旦失败，会不会影响用户中心首页加载？会不会导致雪崩？这些都是需要提前评估的风险点。

我们制定了严格的降级策略：

• 主页请求优先保证用户基础信息返回
• 推荐数据异常时，返回默认内容或空值
• 加入熔断机制，防止依赖服务崩溃引发连锁反应

4. 接口设计：保持简洁清晰的原则

用户中心对外暴露的API本应专注于身份认证、基础信息管理等功能。我们始终坚持一个原则：每个服务只做一件事，并做到极致。

所以我们在原有接口基础上只做了轻微拓展，比如增加了/user/recommendations接口，但并没有深入参与推荐逻辑的实现。

5. 生产环境运维经验：小改动也可能带来大问题

那次上线后我们监控到一次长尾请求，发现是因为缓存未命中导致的数据库压力突增。我们迅速引入了本地二级缓存，并配合布隆过滤器防止缓存穿透。

这也提醒我们，在任何看似简单的改动面前，都要做好性能评估和容灾准备。

三、学会说“不”也是一种能力

回顾那段经历，我最深刻的体会是：作为技术人员，我们不是来“执行指令”的，而是要站在更高维度帮产品把事做成。

有时候“拒绝”并不是抗拒，而是一种更负责任的态度。

以下几点是我和团队慢慢摸索出来的经验：

• “不行”要说清楚原因，而不是甩锅

  比如说：“如果现在接入推荐功能，会导致用户服务延迟上线两周，影响双十一备战计划。我们可以考虑放在下一个版本。”

• 给出替代方案比只说“不”更有价值

  如果对方提的功能短期内确实难以上线，不妨试着提供一个轻量级实现路径。例如用静态规则代替动态推荐，用前端模拟代替后端调用。

• 多和产品站在一起，理解他们的目标

  很多时候他们提的需求，是来自于市场反馈或老板压力。我们需要做的不是盲目满足，而是帮助他们在合理范围内达成目标。

• 建立良好的协作机制

  我们逐渐形成了一套机制：每轮迭代前必须有技术可行性评审；产品经理需提前两周确认需求细节；对于变更频繁的需求，设立“冻结期”。

四、结语：技术人的温度在于理性表达

在我从业这些年里，遇到过不少优秀的同行。真正厉害的人，并不是代码写得最快的，也不是架构画得最多的，而是懂得什么时候该坚持，什么时候该妥协，什么时候该说不的人。

技术是理性的，但我们做事的方式可以充满温度。

如今再面对产品经理的需求，我不再是一味点头或者冷漠拒绝，而是会认真分析每一个改动的影响，权衡利弊，给出最合适的建议。

如果你问我：“程序员要不要学会说不？”我会说：“要，但前提是你说得出理由，并愿意承担责任。”

愿我们都成为既能扛住压力，也能温暖彼此的开发者。