如果我是 Goertek CEO，我对研发行管组织的期待不是“多建流程、多做检查、多收报表”，而是让公司研发体系更可预测、更高质量、更有利润意识、更能跨 BG 复用，并且能把优秀实践沉淀为组织能力。
研发行管组织的价值，不是证明自己比 BG 更懂项目，而是帮助 BG 更少踩坑、更快复用、更早暴露风险、更稳交付客户、更好支撑利润。你们要做公司级研发能力的“基础设施”，不是项目现场的“旁观评委”。
不要一上来发布一套完整制度。先到项目现场识别痛点，在 3 到 5 个高痛点项目中证明方法有效，再沉淀为公司级标准。
我不看为了管理而管理的指标。每个指标都必须回答：对客户、利润、质量、效率、复用或组织能力有什么影响。
流程、数据、知识、模块、专家和专项机制都要沉淀下来，让公司研发不依赖少数英雄，而依赖可复制的组织能力。
研发行管组织没有对 BG 的直线管辖权，因此更要把定位讲清楚。你们的权力来自公司授权，影响力来自专业可信和结果可信。
我会用这十二项要求衡量研发行管组织是否真正发挥作用。每一项都要能落到机制、产出和月度跟踪上。
| 要求 | 具体含义 | 必须交付 | 衡量方式 |
|---|---|---|---|
| 1. 先建信任 | 到 BG 项目现场理解客户、产品和痛点，用解决问题换取合作 | BG 访谈、项目诊断、痛点清单、试点承诺 | BG 接受度、试点参与度、问题闭环数 |
| 2. 统一最小框架 | 统一阶段、Gate、交付物、原因码和指标口径，但允许客户/BG 裁剪 | 公司级最小研发流程框架和裁剪包 | 主要 BG 覆盖率、裁剪例外闭环率 |
| 3. 看见重大风险 | 战略客户、重大收入、重大技术风险项目必须进入红黄灯看板 | CEO 月度红灯项目清单 | 风险提前识别率、红灯事件闭环率 |
| 4. 做准归因 | 延期和问题必须区分客户、研发、供应链、产线、测试、质量等责任域 | 统一原因码和复盘模板 | 阶段偏差归因率、归因争议率 |
| 5. 推动质量前移 | 把重大问题挡在设计评审、FMEA、EVT/DVT 前期，而不是量产后救火 | 设计评审清单、失效模式库、前移专项 | 重大问题前移率、逃逸缺陷率、重复问题率 |
| 6. 建立成本意识 | 研发方案必须从前端考虑目标成本、BOM、NRE、复用和良率 | Design-to-Cost 评审机制 | 目标成本达成率、Should Cost 偏差区间、NRE 偏差率 |
| 7. 防止指标博弈 | 不能让指标诱导少报问题、虚高初始 BOM、拒绝难项目、形式评审 | 指标护栏和月度误用复盘 | 指标纠偏次数、异常行为复盘结果 |
| 8. 沉淀复用资产 | 模块、物料、测试方法、失效模式、评审清单必须可查询、可采用 | 复用资产库和采用机制 | 高价值模块/物料复用率、复用收益区间 |
| 9. 打通数据口径 | 和 IT、财务、质量、采购、BG 一起建立最小数据字段和权限模型 | 研发经营数据字典 | 核心指标数据覆盖率、人工补录比例 |
| 10. 管好专家机制 | 关键专家不能只靠人情调用，要有公司级专家池和评审节奏 | 专家池、评审排期、贡献记录 | 重大评审覆盖率、专家瓶颈事件数 |
| 11. 做成专项闭环 | 每个专项必须有痛点、试点、数据、产出、推广和复盘 | 专项章程、试点报告、推广包 | 专项收益、复制项目数、BG 采用率 |
| 12. 服务经营决策 | CEO 月会只汇报风险、趋势、专项收益和需要拍板事项 | CEO 月度研发经营看板 | 决策事项闭环率、看板使用满意度 |
CEO 不会用“你们开了多少会”评价研发行管组织，而会看你们是否沉淀了可复用、可执行、可持续的组织资产。
包含最小统一阶段、关键 Gate、角色责任、裁剪规则和例外机制。必须能解释 OEM/ODM/JDM 的差异。
包括效率、质量、成本、复用、风险、数据可信度指标，明确 Owner、口径、数据源和权限。
模块库、优选物料库、测试方法库、失效模式库、评审清单、案例库都要能被项目真正使用。
明确专家池、评审范围、准入条件、排期机制、结论闭环和贡献记录。
围绕重大问题前移、变更治理、试产问题、BOM 成本、模块复用、阻塞事件等做出可复制样板。
只呈现重大风险、经营影响、系统性改善、成本质量趋势和需要 CEO 决策事项。
研发行管组织要用机制影响 BG，而不是靠临时协调和个人关系。机制要轻，但要稳定。
| 机制 | 参与方 | 节奏 | 输出 | CEO 要求 |
|---|---|---|---|---|
| 研发经营月会 | CEO/经营层、研发行管、BG、质量、制造、采购、财务 | 月度 | 红灯项目、指标趋势、专项收益、决策事项 | 只讲需要经营层知道和拍板的事情 |
| BG 联络人例会 | 研发行管、BG 研发管理接口人、PMO | 双周 | 痛点、数据、试点、阻塞、反馈 | 必须共创，不允许单向发制度 |
| 专项战队 | 研发行管牵头，BG、质量、制造、采购、IT 参与 | 8 到 12 周 | 诊断、试点、改善数据、推广包 | 每个专项必须产生可复制成果 |
| 重大项目风险会 | 项目团队、BG 负责人、关键平台部门 | 周度或按需 | 红黄灯、阻塞事件、升级事项 | 只跟踪关键路径风险，不制造周报负担 |
| 专家评审委员会 | 公司级专家、BG 专家、质量/制造/测试专家 | 按 Gate 和专题 | 技术风险、评审结论、改进动作 | 评审必须基于证据，不做形式审签 |
研发行管组织要有数据，但不能越权拿敏感明细。对利润、BOM、NRE、客户报价、供应商报价等敏感信息，必须采用脱敏指标、分层授权和财务/成本工程背书。
第一年不要贪大求全。我要看到研发行管组织在少数关键战场上建立可信度：风险看得见、归因说得清、问题能前移、成本有约束、经验能复用。
| 阶段 | 重点任务 | CEO 验收标准 |
|---|---|---|
| 0-90 天 | 完成主要 BG 访谈和项目诊断，统一红黄灯、阶段偏差、原因码、重大问题分级 | 能拿出一份公司级研发痛点地图和第一批试点项目名单 |
| 3-6 个月 | 上线 CEO 月度研发经营看板，运行重大项目风险会和 BG 联络人机制 | 红灯项目能被提前暴露，阶段偏差能完成归因，不再只做事后解释 |
| 6-9 个月 | 打穿 3 个高痛点专项：质量前移、阻塞事件闭环、目标成本/Should Cost 试点 | 每个专项有试点数据、改善结果、推广模板和 BG 反馈 |
| 9-12 个月 | 形成公司级流程裁剪包、专家评审机制、复用资产库一期、年度白皮书 | 至少 2 个 BG 复制试点成果，CEO 月会持续使用看板做决策 |
研发行管组织的考核不能只看自己做了多少动作，而要看 BG 是否采用、项目是否改善、公司是否形成能力。
红灯项目、重大问题、成本风险是否更早被看见并推动闭环。
BG 是否愿意参与试点、采用模板、共享案例和复用资产。
流程、清单、问题库、模块库、专家机制是否可持续运行。
指标是否来自系统和轻量归因，而不是大量人工填表。
研发行管组织越想证明价值，越容易走偏。下面五件事，一旦发生，要立即纠偏。
| 风险 | 典型表现 | 纠偏要求 |
|---|---|---|
| 流程主义 | 流程越来越厚，项目越来越烦，风险仍然后知后觉 | 所有流程必须绑定一个真实痛点和一个经营指标 |
| 数据主义 | 指标很多，但没有管理动作，BG 只是在填数 | 没有动作的指标砍掉，优先保留能触发决策的指标 |
| 越权管理 | 平台部门替 BG 做项目承诺或商业取舍 | 平台负责风险和方法，BG 负责经营和交付 |
| 指标博弈 | 少报问题、虚高初始 BOM、形式评审、拒绝难项目 | 建立指标护栏和误用复盘，必要时停止该指标 |
| 只管研发内部 | 忽略供应链、制造、质量、采购、客户输入对研发结果的影响 | 所有重大偏差必须跨部门归因，平台部门推动协同闭环 |
我会要求研发行管组织承担公司级责任，也会给它必要授权。没有授权的要求是不公平的，没有结果的授权也是不可持续的。