岗位与角色：研发、产品、运营、测试、算法、数据
大厂里的很多摩擦，来自不理解对方的目标函数。产品经理催排期不是针对你，是他的绩效看需求上线；测试卡发布不是刁难，是出了事故他背锅。理解每个角色被什么考核，合作会顺很多，也更容易判断谁是真正的盟友。
| 角色 | 核心产出 | 被什么考核 | 典型压力来源 | 与研发的关系 |
|---|---|---|---|---|
| 研发（RD） | 可运行的系统 | 交付、稳定性、技术影响力 | 排期、事故、技术债 | — |
| 产品经理（PM） | 需求与方案 | 业务指标、需求上线率 | 老板的想法、数据不涨 | 需求方，最频繁的合作者与冲突方 |
| 运营 | 增长与活动 | 业务指标（DAU、转化、GMV） | 数字、活动节点 | 通过 PM 提需求，大促时直接找你 |
| 测试（QA） | 质量保障 | 线上缺陷率、发布质量 | 排期被压缩、背事故 | 发布前的最后一道门，天然盟友 |
| 算法 | 模型与策略 | 指标提升（CTR、GMV、留存） | 实验不显著、算力 | 需要研发做工程化，边界常模糊 |
| 数据（DA/DE） | 报表、指标、数仓 | 数据准确性、需求响应 | 口径争议、临时取数 | 提供你论证价值所需的数字 |
| 项目经理（PMO） | 进度与协调 | 项目按时交付 | 各方拖延 | 帮你追依赖，也帮 leader 盯你 |
| 设计 | 视觉与交互 | 还原度、体验指标 | 需求反复 | 前端接触多 |
研发内部的分工
Section titled “研发内部的分工”研发自己也不是一个整体：
- 前端 / 客户端：离用户最近，需求变更最频繁，被产品和设计双向挤压；技术深度容易被低估。
- 后端：系统核心，事故责任最重；技术深度最容易被认可，也最容易陷在"接口人"角色里。
- 基础架构 / 中间件：离业务最远，技术含量最高，价值最难向业务方解释。
- 数据开发：介于研发与数据之间，需求碎片化，容易变成"取数工具人"。
- 测试开发 / 效能：做工具与平台，影响力靠"被多少人用"。
- SRE / 运维：保稳定，出事第一个被叫，功劳最难被看见。
同一个职级，不同方向的成长路径、晋升难度、跳槽行情都不一样。选方向时，除了兴趣，也要看它在这家公司的位置：核心业务的后端与算法通常资源最多，边缘业务的前端与测试通常最先被裁。
与产品经理工作
Section titled “与产品经理工作”产品是研发最重要的合作方，也是最多冲突的来源。几条经验：
- 需求评审时把问题问完。 目标是什么、怎么衡量成功、边界在哪、优先级如何。评审时不问，开发到一半再问，代价是你的。
- 排期给缓冲，但说明理由。 "三天"和"三天，其中一天是联调和自测缓冲"，后者更容易被接受，也更容易在超期时自证。
- 书面确认变更。 需求变了，让 PM 更新文档并在群里确认。口头变更等于没变，出问题时是你的锅。
- 理解 PM 的压力来源。 PM 的老板要数据，PM 就要功能；PM 催你，是因为有人在催他。把 PM 当成同一条绳上的人，而不是对手。
- 好 PM 是稀缺资源。 遇到逻辑清晰、需求稳定、愿意为研发争取时间的 PM，珍惜并主动配合；遇到反复无常的 PM，用流程和文档保护自己。
测试是研发天然的盟友——你们的共同敌人是线上事故。尊重测试的排期、提供清晰的测试范围、自测后再提测，测试会在关键时刻替你把关，也会在事故复盘时替你说话。反过来，把测试当作"挑刺的"，你会在最需要有人兜底的时候没人兜底。
算法与工程的边界在很多团队里是模糊的，容易产生"谁做工程化"的争议。原则是尽早约定：模型训练与离线评估归算法，在线服务、特征工程、AB 实验平台归工程，中间地带按项目谈。算法的绩效依赖实验指标，指标不显著时压力很大，可能会要求反复上线尝试——理解这一点，但也要保护自己的排期。
角色之间的"翻译"
Section titled “角色之间的"翻译"”每个角色说的话都要翻译：
- PM 说"这个很简单"→ 他没考虑过实现。
- PM 说"老板要的"→ 优先级最高，且不要问为什么。
- 运营说"活动明天上线"→ 一周前就定了，只是现在才告诉你。
- 测试说"这个风险有点大"→ 出了事他不想一个人背。
- 算法说"效果显著"→ 问一下置信区间和样本量。
- 数据说"口径不一样"→ 两个数都对，取决于你想证明什么。
- leader 说"你看着办"→ 他有答案，你需要猜出来并确认。
- 每个角色被不同的指标考核，摩擦大多来自目标函数不同，而非人品。
- 研发内部方向差异大，选方向要看它在这家公司的位置。
- 与 PM：评审时问完、排期给缓冲、变更书面确认。
- 测试是天然盟友；与算法要尽早约定边界。
- 学会翻译各角色的话。