论坛

对于年营收3~100 亿、研发团队 10~200 人的中小企业而言，完整的华为式 IPD 流程资源投入门槛极高，反而容易造成“流程空转、效率下滑”。经过实践验证的Lite-IPD 轻量化方案—— 保留 IPD4 大核心精髓（以客户为中心的需求驱动、跨部门协同协作、结构化阶段门管控、公共模块复用），裁剪 50% 以上冗余评审节点与流程环节，以单产品线试点、逐步推广为核心落地路径，可实现低成本、快迭代、高转化的实际效果。

第一阶段：前置诊断 —— 精准把脉企业现有研发管理痛点（1 个月标准周期）

精简 IPD 的前提是精准识别企业专属痛点，而非通用套模板。诊断需由“外部 IPD 顾问 + 企业高管 + 核心部门骨干”联合开展，交叉验证避免表面化结论。

1.1 诊断核心目标

量化识别三类差距，定位研发低效的根因：

1. 业绩差距：直观业务数据痛点（如新品滞销占比高、研发延期率高、产线返工频繁、核心技术经验流失）；

2. 流程差距：现有研发流程的断点与冗余（如评审形式化、部门决策脱节、需求变更无受控机制）；

3. 能力差距：组织底层能力缺失（如无公共技术模块库、缺乏客户需求验证环节、跨部门协同无明确规则）。

1.2 诊断实操四步法（含可直接复用工具）

步骤 1：企业资料全景复盘（前置准备，1~2 周完成）

提前调取近 3 年业务资料，按标准化维度归档梳理，避免凭空判断：

• 经营数据类：财务报表、新品营收占比、项目延期 / 废弃统计、客户投诉记录；

• 流程文档类：现有研发流程图、历次评审会议记录、需求变更申请单据、项目验收报告；

• 组织管理类：组织结构图、部门职责说明书、研发人员绩效考核制度、核心岗位任职资质；

• 产品技术类：核心产品 BOM 清单、技术模块复用统计、供应商协同记录、竞品技术对比报告。

步骤 2：分层深度访谈（核心环节，挖掘真实隐性痛点）

针对不同岗位设计专属访谈提纲，营造平等对话氛围，通过追问挖掘流程背后的真实障碍，重点问题示例：

• 决策层（CEO / 研发总监 / 市场总监） ：未来 1~3 年核心细分市场机会是什么？当前产品错失订单的核心原因是技术还是需求预判偏差？跨部门协同最大的权责卡点在哪里？

• 管理层（研发 / 生产 / 销售经理） ：研发图纸下发后，生产端常出现哪些无法落地的问题？需求变更时，哪个部门最容易推诿责任？现有评审机制能否提前识别量产风险？

• 一线员工（工程师 / 产品经理） ：现有技术评审中，哪些环节属于重复汇报？客户需求收集后，有没有明确的验证标准？设计方案定稿后，采购端物料供应是否同步确认？。

步骤 3：IPD 成熟度量化自评（用数据精准定位短板）

采用行业通用4 分制 IPD 成熟度自评表，覆盖 5 大核心维度、20 + 细分考核项，量化打分明确薄弱环节：

考核维度                             评分标准（0-4 分）
产品战略与路标规划        0 分无明确产品规划；2 分有正式流程但未对齐市场需求；4 分有跨部门规划团队 + 落地路标图
结构化研发流程                0 分无固定流程；2 分有完整流程但执行流于形式；4 分有明确阶段门准入 / 准出标准
跨部门协同机制                0 分部门完全独立；2 分项目临时对接无明确职责；4 分有专职 PDT 团队 + 并行开发模式
需求管理体系                    0 分无统一需求收集渠道；2 分有需求库但无验证环节；4 分有完整需求收集 – 分析 – 溯源流程
技术模块复用能力           0 分无通用模块积累；2 分少量项目间复用；4 分有标准化 CBB 库 + 技术货架规划

注：得分≤2 分的维度，即为后续流程裁剪的重点优化方向。

步骤 4：行业标杆对比验证（校准优化方向）

选取同行业、同营收规模、同产品复杂度的 Lite-IPD 落地标杆企业，对比关键运营指标，将现状差距转化为可量化的优化目标，例如：“标杆企业的传感器开发周期为 3 个月，我方当前为 6 个月，核心差距在于无公共算法模块复用库”。

1.3 诊断输出成果

提交正式《研发管理现状诊断报告》，作为后续裁剪的核心依据，包含三大核心内容：

1. Top3 痛点根因分析（如：需求无验证环节→60% 研发资源投入非客户真实需求；跨部门无前置协同→设计变更率高达 40%）；

2. 现状与 Lite-IPD 的能力差距清单；

3. 专属轻量化 IPD 裁剪方向建议。

第二阶段：精准裁剪 —— 识别 IPD 可精简冗余环节（核心适配方法论）

Lite-IPD 的裁剪逻辑是删冗余、保核心、强适配，根据行业特性、产品复杂度、现有资源定制化调整，绝对不能照搬大厂标准流程。

2.1 三大底层裁剪原则

1. 业务结果导向：保留直接影响产品上市、营收、质量的核心环节，删除无明确业务产出的形式化步骤；

2. 行业特性适配：装备制造行业重点强化生产评审环节，软件行业完全裁剪硬件协同流程，医疗行业保留合规性评审节点；

3. 阶段动态匹配：落地初期优先精简评审节点，待流程稳定后，再逐步补充优化细分管理环节(40)。

2.2 具体精简操作方案（行业通用标准）

（1）技术评审（TR）节点：采用压缩至 3 个核心评审

标准 IPD 流程设置 6~7 个技术评审点（TR1-TR6），中小企业可通过合并冗余节点，将评审次数压缩至 3 次，既控制研发风险，又避免会议冗余：

• 第一：合并 TR1（需求概念评审）+TR2（需求规格评审） ：整合为”需求真实性验证评审“，输出《客户需求规格验证书》，必须邀请 5~10 名种子用户、销售端一线业务人员参与评审，以客户真实使用场景为验收标准，仅保留≥80% 投票通过的需求立项；

• 第二：合并 TR4（设计可行性评审）+TR4A（工艺可行性评审） ：整合为”制造可行性评审“，输出《可制造性设计（DFM）报告》，研发、工艺、采购三方必须同步签字确认，提前核实物料供应能力、生产线工艺适配性；

• 第三：删除 TR5/TR6 内部收尾评审，置换为”客户买单验证会“：取消内部技术闭环式评审，将最终评审权交给种子用户，试产样品提交客户现场实测，收集实测反馈作为量产准入依据(65)。

（2）决策评审（DCP）：设置”双轨制评审“，杜绝层级审批拖延

标准 IPD 的 3 个投资决策评审点精简为两类快速决策机制，匹配不同项目优先级：

• 正式评审（全新研发 / 高风险项目） ：仅保留”概念阶段决策“、”计划阶段决策“2 次跨部门评审，由市场 / 研发 / 财务 / 生产负责人组成决策组，采用加权评分法，过半投票即可通过；

• 快速评审（迭代优化 / 低风险项目） ：启动绿色通道，由对应部门专职对接人在 24 小时内完成标准化 Checklist 线上评审，结果同步至全团队，无需召开正式会议。

（3）全阶段合并：IPD 经典 6 阶段→精简为 4 核心阶段

按并行工程逻辑，压缩串行环节，下游生产、采购、市场团队提前同步介入，压缩整体项目周期：

标准 IPD6 阶段                 Lite-IPD 精简 4 阶段            核心调整内容

概念阶段                             概念验证阶段                         合并需求调研与客户场景验证，同步启动小批量样品实测，快速验证需求真实性
计划阶段                            方案规划阶段                          整合技术方案、生产工艺、财务预算、营销计划，跨部门同步输出一体化项目总计划
开发阶段                            并行开发阶段                          研发完成核心设计后，工艺、采购同步开展模具开发、物料寻源，边设计边确认供应可行性
验证 + 发布 + 生命周期  量产运维阶段                           合并试产验证、上市发布、售后运维，建立”产线问题扑杀机制“，快速闭环量产缺陷

（4）组织架构轻量化：压缩 PDT 团队，建立”铁三角作战单元“

标准 IPD 的多层级决策团队（IPMT 投资决策委员会、PDT 产品开发团队），压缩为两级轻量化执行架构，避免决策层级过多：

• 决策层：成立 3 人核心决策组（总经理 + 研发总监 + 市场总监），直接掌握项目立项、资源调配、量产终止决策权，避免层级审批；

• 执行层：精简 PDT 核心组为 5 人，覆盖产品经理（需求统筹）、研发经理（技术交付）、工艺经理（生产协同）、采购对接人（物料保障）、市场对接人（上市准备），采用全职核心团队 + 兼职外围专家模式，一人多岗，整合资源投入。

关键优化：推行”人质机制“— 研发核心工程师必须驻场代工厂 / 客户现场 48 小时，全程跟进试产或实测环节，确保设计方案可落地执行。

（5）支撑系统低成本化：放弃复杂 PLM，用轻量化工具组合替代

中小企业无需投入数十万部署专业 PLM 产品生命周期系统，适配现有办公体系，搭建低成本协同架构：

• 需求管理：用飞书 / 钉钉文档 + 表格搭建统一需求收集库，设置需求变更自动通知流程；

• 项目管理：用板栗看板、Trello 等可视化工具，按阶段划分任务卡片，实时拖拽更新状态，自动预警超期任务；

• 知识沉淀：用企业微信 / 钉钉文件夹，按项目归档交付物，建立 CBB 公共模块检索库，强制新项目优先复用现有模块。

工具选型标准：支持与企业现有 ERP、MES 系统 API 对接，无需额外培训成本，满足 10~50 人团队协同要求。

（6）核心实践保留：绝不裁剪 IPD 底层精髓

为避免流程轻量化沦为”无序研发“，以下 4 个 IPD 核心环节必须 100% 保留，作为流程落地的底线：

1. 需求过滤漏斗：收集≥100 条客户反馈 / 竞品需求，通过优先级打分、客户场景验证，仅保留 3~5 个高频核心痛点立项；

2. 跨部门前置协同：生产、采购、市场团队必须在方案阶段同步介入研发，禁止研发闭门造车；

3. 阶段准入 / 准出标准：每个阶段设置明确的交付物验收规则，未通过评审的项目不得进入下一环节；

4. CBB 公共构件模块复用：从历史产品中提炼通用算法、通用结构、通用工艺模块，搭建轻量化技术货架，新项目优先复用成熟模块。

2.3 行业专属裁剪差异化参考

不同行业产品复杂度、合规性要求不同，裁剪重点需针对性调整，绝不能一刀切：

行业类型                                  核心裁剪优化点                       必须保留的核心环节
装备制造 / 汽车零部件         弱化技术预研环节，强化生产工艺评审；删除平台化管理初期部分节点，重点压缩采购提前期                   需求现场验证、可制造性评审、客户量产现场确认
消费电子 / 智能硬件             合并 TR3/TR3A，简化环境测试评审；重点优化量产导入流程，缩短上市时间           概念样机验证、工艺协同评审、用户众测差评快速整改
软件 / 工具类 APP                 完全裁剪硬件相关所有环节，合并开发与验证阶段，采用敏捷迭代模式                需求原型评审、MVP 上线评审、用户留存数据验证
医疗器械（合规要求高）     保留完整决策评审点，精简技术评审文档模板，用行业法规标准替代冗余内部评审     需求溯源管理、设计变更评审、国内 / 国际医疗合规验证

第三阶段：落地实施计划 ——6~9 个月轻量化可执行路径（试点优先）

中小企业严禁全公司、全产品线全面铺开 IPD 变革，必须采用单产品线试点、沉淀成功经验、逐步推广的落地策略，用可见的业务效果获得全员认可。

3.1 第一阶段：1~3 个月 —— 基础流程搭建，落地核心团队

核心目标：完成 Lite-IPD 流程适配，组建轻量化跨部门团队，选定试点项目启动。

时间节点             核心任务                                                                                 交付成果
第 1-4 周              1. 成立 IPD 变革专项组，由总经理担任组长；2. 完成全公司研发现状诊断；3. 结合行业特性，确认专属 Lite-IPD 裁剪方案；4. 选定试点产品线（优先选择中等难度、交付周期适中、团队配合度高的项目，严禁用战略级高风险项目试点）               《研发管理现状诊断报告》《Lite-IPD 流程裁剪确认书》
第 5-8 周             1. 设计精简后的 4 阶段研发流程，明确各阶段准入 / 准出标准；2. 定制轻量化评审 Checklist 与交付物模板；3. 正式组建轻量化 PDT 铁三角团队；4. 搭建适配企业现有办公系统的协同工具               《Lite-IPD 流程操作手册》《阶段评审 Checklist 全集》
第 9-12 周           1. 试点项目正式按新流程启动；2. 完成概念验证、方案规划阶段的合并评审；3. 培训核心团队流程执行标准；4. 建立每周铁三角进度复盘机制                     《试点项目立项书》《概念阶段评审报告》

3.2 第二阶段：4~9 个月 —— 试点迭代验证，沉淀可复制经验

核心目标：按新流程完成试点项目从开发到量产的全链路验证，优化流程细节，沉淀专属技术模块库与执行规则。

时间节点              核心任务                                                                             交付成果
第 4-6 个月          1. 试点项目按并行开发模式推进；2. 严格执行制造可行性评审，采购、工艺同步确认供应能力；3. 从现有产品中提炼 CBB 公共构件模块，搭建轻量化技术货架；4. 每周记录流程执行中的痛点，如评审标准模糊、部门协同脱节                             《试点项目开发进度报告》《首批 CBB 公共模块库》
第 7-9 个月          1. 试点项目进入量产 / 上线阶段，召开客户买单验证会；2. 建立”产线问题扑杀清单“，集中资源解决 TOP5 量产缺陷；3. 对比落地前后关键指标，验证流程效果；4. 培养 3~5 名内部 IPD 种子人才              《试点项目量产验证报告》《Lite-IPD 流程优化细则》
第 10-12 个月      1. 组织全公司试点成果复盘，用实际数据展示落地效果；2. 制定分阶段多产品线推广计划；3. 重构绩效考核体系，将模块复用率、需求准确率纳入团队 KPI；4. 建立 Lite-IPD 月度复盘机制，持续优化流程                    IPD 变革试点成果报告》《全公司分阶段推广计划表》

3.3 落地三大核心保障机制

1. 高层必须深度挂帅：由企业一把手亲自担任 IPD 变革组长，统筹跨部门资源，快速拍板决策，避免部门负责人因短期业绩需求阻碍流程变革。

2. 顾问驻场陪跑赋能：优先选择有中小企业落地经验的 IPD 咨询团队，驻场辅导 6~8 个月，共同设计流程、培训员工、指导试点项目，避免企业闭门造车照搬大厂模板。

3. 正向激励驱动变革：试点阶段设置专项变革奖金池，对流程执行到位、提出有效流程优化建议的员工及时奖励；将新流程执行情况与个人绩效挂钩，引导员工从”抗拒变革"转变为"主动参与"。

第四阶段：实操落地案例（直接对标复用）

案例 ：智能硬件企业（营收 12 亿，研发团队 40 人）

企业痛点：照搬大厂 IPD 流程，技术评审会议占比高达 30%；研发与生产脱节，试产返工率高达 35%；产品上市后才发现需求偏差，滞销库存积压严重。

裁剪策略：将 6 个 TR 评审压缩为 3 个；将 TR6 改为客户买单验证会；建立产线问题扑杀清单。

落地操作：合并 TR1+TR2、TR4+TR4A，仅保留 3 次核心评审；试产阶段邀请 10 名核心种子用户现场实测产品，收集 TOP3 痛点快速整改；研发工程师驻场代工厂 2 天，闭环解决生产问题；用客户场景蹲点替代大数据需求分析。

实际效果：评审会议时长压缩 50% 以上，研发周期缩短 25%，试产返工率降至 12%，首批量产产品客户满意度提升 28%，滞销库存减少 60%(65)。

案例：装备制造企业（营收 20 亿，研发团队 50 人）
企业痛点：跨部门协同低效，采购、工艺环节在开发末期才介入研发，导致设计变更频繁；项目延期率高，核心技术经验掌握在老员工手中，人走技失。

裁剪策略：精简 IPD 决策评审，设置快速评审通道；强化并行工程，采购、工艺提前进入方案阶段；部署轻量化飞书项目流程。

落地操作：PDT 团队包含采购、工艺全职对接人，方案阶段同步核实物料供应可行性、加工工艺合理性；设计变更必须经过研发、工艺、采购三方同步评审签字；建立 CBB 通用结构模块库，沉淀核心设计经验，避免重复开发。

实际效果：设计变更次数减少 40%，项目延期率从 45% 降至 10%，采购提前期缩短 18%，技术经验流失风险降至极低水平。

第五阶段：落地常见误区与规避方案

1. 误区：盲目照搬华为 / 大厂完整 IPD 流程，认为环节越多、评审次数越规范

规避：Lite-IPD 的核心是"适配业务"，以单个产品线试点的实际效果说服全员，后续再根据业务规模逐步补充流程细节，绝不追求形式上的体系化。

2. 误区：过度裁剪，省略核心需求验证或制造可行性评审环节

规避：严格保留"需求真实性验证"、"制造可行性评审“、”客户买单验证“3 个核心 TR 评审，每个评审设置标准化 Checklist，必须由对应领域负责人签字确认。

3. 误区：只优化流程，不调整组织考核机制

规避：重构团队 KPI 指标，放弃单纯以”研发进度“为核心的考核目标，将”需求准确率“、”模块复用率“、”评审一次通过率“、”量产返工率“纳入核心考核指标，用绩效指挥棒引导行为。

4. 误区：依赖免费办公工具，忽视流程沉淀与知识复用

规避：投入少量预算部署轻量化项目管理工具，满足流程可视化、文档归档、资源协同的基本需求；强制要求新项目优先复用 CBB 模块，将模块复用率纳入研发团队考核。

5. 误区：将 IPD 变革当作一次性项目，而非持续优化机制

规避：建立每月 Lite-IPD 复盘会，每季度开展 TPM 变革进展指标评估，收集一线员工流程优化建议，持续裁剪低效评审环节，让流程适配企业业务发展，而非限制业务发展。

第六阶段：落地效果验收标准（量化考核）

中小企业 Lite-IPD 落地成功，需同时满足以下 5 项量化业务指标，而非仅看流程文档完整性：

1. 研发效率：新产品开发周期较历史水平压缩≥20%；

2. 投入产出：无效研发项目占比下降≥30%，CBB 公共模块复用率提升≥40%；

3. 协同效果：设计变更次数减少≥30%，跨部门评审时长压缩≥40%；

4. 市场结果：新品上市成功率提升≥25%，新品营收占比提升≥15%；

5. 组织能力：沉淀企业级 Lite-IPD 流程操作手册，培养≥3 名内部 IPD 种子人才，具备自主优化、推广流程的能力。

华为公司在引入IPD体系的时候，将研发合格产品整个过程分为确保开发做正确的事和如何正确地做事两个阶段。所谓正确的事，核心是确保产品能够对准客户需求，能够给客户带来商业价值。要求在产品进入研发或开发之初就应该清晰地定义出有竞争力的产品。在华为公司，确保开发做正确的事是通过商业计划书(Charter)来决定的。

2006年，徐直军在“战略与Marketing体系”大会上指出:“做正确的事是华为面临的最核心的问题，解决这个问题是’战略与Marketing’最核心的职责。这就要求我们重点抓好’产品规划’，要明确未来应该开发什么产品、产品应该有哪些具体特性、产品应该何时上市，产品的成本应该是多少。产品立项是战略性的，只有战略正确，后续的Marketing活动、市场活动才有意义、有价值。”

一、 Charter是说明机会、投资收益的商业计划

Charter是任务书，又称商业计划书，是产品规划过程的最终交付，是对产品开发的投资评审决策依据。Charter的价值在于确保研发做正确的事，主要回答两个核心命题:一是这种产品值不值得投入；二是这种产品如果值得投入，怎么做才有竞争力。每一个Charter决定了做什么产品，做什么样的产品，确定产品的竞争力，也就是说，Charter是解决方向性的问题，解决要做什么产业、做什么产品、达到什么目标的问题。

Charter的核心内容包含产品规划最关注的重要问题，这些重要问题可以用4W+2H(Why What When Who+How How much)来表达：

Why：回答产品为什么要立项。通过市场宏观和微观分析，围绕客户的“痛点”和商业价值，明确目标市场和市场机会点，以及商业变现手段，如何获取利润。如果不进入这个市场、不做这个产品，对华为的损失有多大?

What：市场需要的产品包需求是什么样的?针对客户的商业“痛点”场景，描述华为的独特价值和关键竞争力要点，以及如何构建核心竞争力。

When：什么时候是最佳市场时间窗，讲清楚预计产品推出的时间和对客户承诺的符合度，以及版本相关里程碑。

Who：完成此产品开发需要的项目组团队、角色。

How：产品的开发实现策略、商业计划盈利策略、上市营销策略、存量市场的版本替换更新策略等。

How much：从资源、财务、设备等多维度视角说明开发产品需要投入的成本与费用。

二、 Charter质量是整个产品质量的基础

Charter是产品开发的源头，是正确识别客户需求和传递产品包器求到后端产品开发的重要载体，因此，Charter的质量是整个产品质量的基础。徐直军在2006年度PDT/TDT经理高级研讨会上指出:“所有的前端的前端的最前端，就是Charter，如果Charter做错了，那事实上全是错的，所以我觉得Charter的质量应该是我们整个产品质量的根本。Charter开发定位为做正确的事，它确认了方可，研发是正确地做事，如果前端出错了，产品就不可能有高质量了。”

2007年，华为“战略与Marketing”办公会议明确指出:“Marketing要保证开发出’好’Charter，从根本上提升华为研发效率，扭转目前3万多研发人员天天加班但却有25%的版本被废弃的被动局面。产品管理体系的各级主管、员工一定要清楚自己的责任，要认识到产品管理部做任何工作都是为了Charter的质量提升。”

2006年，徐直军在“战略与Marketing体系”大会上谈道:“我们要提前用足够的时间立项进行Charter研究，组成一个有足够力量的团队，基于现有产品，仔细分析跟踪市场需求、客户需求，再结合技术发展，那么完成高质量的Charter就是水到渠成的事。在Charter这个阶段，业界的交流是不设防的，很多问题都可以互相探讨。这样，既有利于掌握产品发展蓝图，以保证产品的竞争力，同时，我们也就会有真正的3~5年的产品规划。因此，对于Charter的开发要进行立项管理，只有立了Charter的项，再进行考核，产品管理部才会有压力，才会重点投入资源。我们后续要对产品线逐个讨论确定今年要立项进行 Charter开发的Charter项目清单。”

三、CDP为开发高质量Charter提供流程保障

Charter开发过程的好坏直接影响Charter的质量，决定产品的竞争力，以及如何取得市场的商业成功。为了开发出真正高质量的Charter，华为强调要像开发产品一样开发Charter，要像管理产品开发过程一样管理Charter开发过程，包括要有团队、管理体系、流程的支持，人员要专职;要全流程受控，对各个环节都要提出质量要求。在华为公司，Charter的开发由Charter开发团队(Charter Development Team，CDT)负责，Charter商业计划书开发流程(Charter Development Process，CDP)提供流程保障。

CDP流程分五个阶段:CDT立项准备、市场分析、产品定义、执行策略和Charter移交。

1、CDT立项准备(原始构想)

这个阶段主要是由产品管理部专家根据产品原始构想，形成CDT立项自请报告和CDT组织建议，向决策组织提出Charter开发立项，以正式启动Charter开发项目。

产品管理部在例行工作中，通过产业规划、市场分析、客户需求、竞争分析、行业洞察、标准专利分析等孵化出新产品构想概念，产品构想概念相对比较简单，可以是一个轮廓。新产品构想概念形成后，产品管理部向商业决策组织自请成立CDT开发产品Charter，如果获得批准则正式启动Charter开发，进入市场分析阶段。

CDT是开发高质量Charter的组织保证。CDT是一个跨领域、跨部门的团队，团队角色来自Marketing、销售、服务、研发、制造、供应、合作、财经等专业领域，由产品管理专家作为CDTLeader。CDT Leader是否有成功洞察力的经验、在洞察这方面是不是有成功的实践，非常关键，很大程度上决定了Charter质量。

2、市场分析阶段

Charter开发的第一个活动是市场分析，目标是回答清楚为什么要做这件产品，也就是“Why”问题。为了做到这一点，CDT团队要拿着产品构想，去与客户进行直接的沟通交流，从而弄清楚市场有什么样的商业机会，有什么样的应用场景和需求，主要的客户问题和期望是什么，市场竞争形势是怎样的。在这个基础上，初步形成产品备选特性，明确新产品目标客户是谁、新产品能为客户带来什么价值、给公司带来什么价值。例如:

宏观市场形势是怎样的，产品未来的市场前景如何，有什么样的机会?

细分市场应用场景、客户和竞争对产品都有什么样的需求?

新产品的目标细分市场和客户是谁，新产品给客户带来什么价值?

目标市场有没有吸引力，实现新产品将给公司带来什么市场收益?

新产品有哪些市场风险?如不提供新产品将给华为带来的影响?

此阶段一般可分为以下几方面关键活动:客户互动、市场分析、行业技术分析、竞争分析、合作分析、商业模式分析等，最终形成新产品能为客户带来的价值及能为公司带来的价值的判断。

客户互动是以确认产品/解决方案构想的市场认可度为目的的重要活动。徐直军在2011年产品管理部长角色认知研讨会议上指出:“产品管理部要跟客户在不断的互动中，形成一个个Charter，Charter开发的过程就是不断与客户互动的过程。一个Charter最终形成，跟客户互动过几次，跟多少客户进行过互动。如果我们的Charter不跟客户互动，怎么清楚产品开发是以客户需求为导向的，怎么能够知道我们的产品开发是客户需要的。”一般而言，CDT团队会提前准备互动交流的材料或者场景化需求、产品原型Demo，与客户互动的方式也是多种形式和多种渠道，如高层拜访、专题交流、路标交流、联合创新等方式。近几年，为了更高效地与客户沟通，华为公司还构建了与客户直接连接的互联网产品定义社区(Joint Product Definition Community,JDC)，通过扁平化、社交化、需求众筹、需求互动等方式与客户和最终用户互动，共同定义需求和产品构想。

市场分析从宏观市场、细分市场和重点/典型客户三个层面分析新产品所面对的市场。宏观市场分析从标准与管制、市场发展趋势、产业发展趋势，竞争态势等方面分析产品的未来市场前景以及市场宏观环境对产品市场机会的支撑和制约。细分市场分析以及重点，典型客户分析给出各细分市场特征需求，竞争需求，应用场景需求，客户期望需求和解决方案配套需求。市场分析要基于产品生命周期进行判断，明确新产品的市场目标和定位，同时要通过分析细分市场的吸引力和竞争趋势，预测新产品未来5年的可参与市场空间、销售份额、销售收入等数据。根据前面的市场分析总结形成新产品能给客户带来的价值及给公司带来的价值，得出新产品的战略目标。

行业技术分析主要分析与新产品相关的技术环境驱动因素，给出行业技术变化对新产品的驱动或限制，特别是产业链发展健康与否对新产品的驱动或限制。行业技术分析范围较为广泛，如标准、产业链、技术、芯片、组件、IPR11等。行业技术分析一般会围绕行业资源对新产品商业成功和关键实现路径给出先验分析，如产业链整合需求、新技术和芯片给新产品带来能力提升等，输出关键技术能力需求和产品目标成本要求，包括关键技术、芯片、组件、端到端(End to End，E2E)配套产品、IPR、目标成本等向相关部门提出需求，并努力在研发体系推动落实。

竞争分析在此阶段的主要目的是论证新产品给华为带来的竞争力提升，通过对竞争环境和竞争地位分析给出新产品市场竞争策略，评估产品组合竞争力给出新产品竞争力需求。

合作分析是从解决方案E2E配套的角度分析合作的关键资源，给出合作资源地图，评估合作方产品及综合能力，提出合作策略和建议，提出合作产品/部件对周边产品的需求。

商业模式分析是在承接产业商业模式设计结论的基础上，针对本 Charter，结合当前行业变化趋势、客户商业诉求及采购模式变化、友商报价变化，以及华为该产品历史交易模式和价格兑现水平的分析和宙视，完成对本Charter商业设计方向的构想。

在完成上述市场分析等一系列工作之后，CDT团队会向商业决策组织汇报市场分析结果，评宙通过后进入产品定义阶段。

3、产品定义阶段

产品定义阶段回答“What”问题，主要输出是在市场分析阶段形成的客户需求特性基础上，归纳总结解决方案/产品包需求，阐述产品应该做成什么样才能够满足客户需求和产生客户商业价值，比如客户体验竞争力提升等内容。要点如下:

讲清楚产品应该做成什么样，识别出价值特性并排序；

基于客户价值特性排序及研发资源进行需求优先级排序，形成初始产品包需求；

归纳总结产品的价值特性和成本目标，明确产品的客户价值和竞争力构建。

本阶段完成以下关键活动：确定产品目标成本、确定产品可销售价值特性及盈利控制方式、确定产品包需求及排序。

确定产品目标成本阶段强调产品的公司内部全流程成本(内部 TCO112)和客户生命周期应用成本(客户TCO)，其目标是希望在理想的情况下，产品实现的各类TCO相关的需求带来的价值能够达成内部和客户TCO成本目标。

内部TCO成本目标的设定需站在华为公司运营的角度使端到端成本最优，而不是局部最优，这些成本目标主要包含产品制造成本、期间成本、服务成本、维护成本等。

客户的TCO目标成本则根据选定的客户、典型场景，确保产品在市场项目竞争由价格和毛利润达到一定的平衡。

内部或客户TCO目标成本可以从两个视角去宙视:一个视角是自底向上的，也就是产品实现的部分功能、性能、可服务性、可靠性等需求带来了内部或客户TCO节省的价值;另一个视角是自顶向下的，需要从产品运营财务视角提出内部和客户TCO节省的目标，并作为后续产品包必须达到的目标。

确定产品可销售价值特性和商业设计概要。在这个阶段，CDT团队在前期市场分析阶段输出的基础上，进行可销售价值特性的识别，并提出该Charter的商业设计概要，比如销售量纲是要卖用户数还是卖连接数，或者是卖端口数。这样做的目的，一是要将“如何卖”以需求包的形式往研发传递，比如以用户数销售，则需要开发控制用户数的 license：二是在后期需求和特性排序申始终聚焦高价值的部分。

确定产品包需求及排序阶段。CDT团队将初步的包需求与主要竞品进行比对分析，发现不足，进行规格和需求的调整，确保规划版本的需求和规格具备竞争力。然后进入对特性/需求进行动态优先级排序的过程，对整体的产品包需求进行排序的主要目标是希望价值客户需求可以尽早地、完整地、清晰地传递给后端研发，在产品开发过程中能快速响应价值客户需求。CDT团队在特性价值排序、非特性市场需求及内部需求排序的基础上，应用多种方法进行整个产品包需求排序，组织利益各方讨论，最终形成与研发团队达成一致的产品包需求。CDT还需按照需求闭环确认的原则，组织与典型客户进行沟通，确保客户重要需求没有遗漏，以保障产品规划需求是符合客户要求的。

完成上述过程之后，商业计划的开发就进入了执行策略的制定阶段。

4、执行策略

执行策略阶段是指开发这个版本需要用到的资源、成本、费用、团队的具体执行计划和措施。在这个阶段主要回答When/How/How Much/Who的问题。

新产品应该什么时间上市；

为保障产品的市场成功，应该采用怎样的开发策略、配套策略、营销策略、生命周期策略和服务策略；

产品实现的关键路径是什么，需要投入多少资源；

产品开发团队。

本阶段一般可分为以下几方面关键活动：确定产品关键里程碑，确定E2E配套策略和开发实现策略，确定定价策略和营销关键策略，确定服务策略，进行产品投入产出分析，完成风险分析。

确定产品关键里程碑主要是确定本产品版本按照IPD开发管理规定的版本计划时间表，一般而言包括本版本的开发启动时间、编码、测试、系统集成测试、上市发布时间等。在此里程碑里一般还会明确周边配套产品的互锁关联版本计划，以方便多产品的集成和配套测试验收。

E2E配套策略和开发策略由CDT团队负责，从面向交付的E2E规划角度，给出新产品涉及的全部配套产品或组件需求，包括各配套产品的需求描述、准入认证要求、版本交付计划，提出E2E配套获得策略。同时，CDT团队还要从业务分层角度，对配套产品的长期发展思路给出建议。

定价策略和营销关键策略是本阶段的一项重要工作。之所以说营销和定价策略非常重要，是因为这个阶段会明确产品上市的商业模式和定价。怎么做生意和定价好不好，会影响产品将来的财务盈收结果。CDT团队需要根据前期输出的市场分析相关信息(市场空间预测、价格预测、销量预测等)，初步制定新产品营销目标和营销策略，定义产品如何走向市场，被市场和客户所感知，提出新产品的渠道策略(如直销、分销等多种方式)、提出新产品成功的关键市场策略，明确在哪些市场树立标杆。在前期输出的细分市场分析基础上明确商业模式，用什么样的方式做生意，我们的盈利控制点在哪里。在执行策略阶段初期，CDT团队会把所有相关利益部门联合起来进行研讨，有时会按照“红蓝军角色扮演”方式进行，其目的是希望找到规划的盲点进行优化改进。定价阶段则基于前面阶段完成的产品商业模式设计，评估定价模式，给出产品初步的定价策略建议。定价时会考虑细分市场和销售区域的特点，结合可能的竞争需要，既保证产品盈收又能够具有商务竞争力。

服务策略由CDT团队的服务代表提出技术服务目标和策略，给出技术服务资源估计，提出技术服务领域主要场景的服务成本目标。

之后是对开发团队的组建提出建议，是否由跨多种产品的团队组成，以及如何管理协作。

CDT团队需要给IPMTI13清晰的投入产出分析的答案。基于产品定义阶段的目标成本、销量、价格等数据，给出新产品损益分析。从投入产出财务角度评估新产品投资价值，形成新产品以解决方案业务盈利计划。这是获取开发投入预算和费用的重要手段，只有获得了足够的预算和费用，产品才能够按照原定计划完成。

风险分析工作负责针对该产品的商业风险，包括市场/客户、产品开发实现、项目管理等方面进行风险分析，确定风险规避措施、责任人和跟踪要求。需要强调的一个重要方面是CDT团队评估技术需求的落地情况，评估所有的支撑该产品技术需求验证是否能够按期高质量完成，技术因素往往是影响产品能否顺利开发的关键路径。

完成上述所有环节后，CDT团队会完成向IPMT汇报的Charter Review材料，向IPMT商业决策组织进行汇报，获得商业计划的批准。

IPMT在评雷Charter时必须思考以下问题，如果回答都是积极的，就投票通过，并成立一个PDT。

目前在华为公司和产品线的组合路标中是否包含该产品?

该产品是否能够给客户带来价值?是否能够吸引客户?

该产品通过什么商业模式实现持续盈利?如果不盈利，有没有其他收益(是不是可以促进其他产品的销售和盈利)?

目前的行业环境怎么样?产业链成熟情况怎么样?后续发展情况怎么样?

产品是否有竞争力?怎样构建我们的竞争力?

如果不做这个产品，华为会有多大损失?

5、Charter移交

Charter经IPMT评宙通过后，CDP主要阶段完成，进入Charter移交收尾期。在这个时期，CDT完成项目总结和文档归档，并正式移交 Charter给PDT后才可以解散。随着PDT成立，原先CDT各领域的关键成员加入PDT团队继续进行产品开发，产品管理代表负责持续跟踪需求落地。

四、 Charter开发是螺旋式上升过程

前文详细介绍了华为公司开发商业计划书的全过程。由于市场在不断变化，CDP每个阶段都要对前面阶段的分析结论进行“螺旋式”Review，提升对市场、需求和竞争的认识，刷新前一个阶段的输出结论。例如，在产品定义阶段可能会刷新市场分析阶段关于市场分析的结论。

围绕前面所说的4W+2H，Charter的核心是清晰地呈现要开发产品的完整的、对准客户商业价值、有竞争力的产品构想，这些产品构想会在开发的每个阶段进行客户互动确定，并持续刷新。在Charter开发过程中，Charter开发团队基于收集和获取的客户需求，首先形成产品的初步构想，然后在内部进行讨论。内部讨论之后，结合现有分析结果优化出新的产品构想。此阶段产品构想只是一种产品大概是什么样的描述。随后，Charter开发团队就产品构想和客户进行交流。为了确保交流得到高质量的输出，Charter开发团队要确保按流程要求的具体交付和活动严格执行。和客户交流之后获得客户反馈意见，有些意见可能还需要做一些更广范围的调查来明确。调查完毕后，产品构想在原来的基础上进一步清晰，当然也可能对原来的构想有一些否定。不管是否定还是肯定，产品构想都会更清晰化。

清晰化后的产品构想与客户(也包括行业专家、产业链上下游专家及合作伙伴等)沟通、交流后，形成更清晰化的产品构想，这样的交流可能需要进行3~4次或者更多次的选代。随着交流一轮一轮地进行，产品构想对于产品的特性描述越来越清晰，对于产品架构的描述也越来越清晰。最后到需要向IPMT汇报Charter的时候，CDT就能拿出保证商业成功、满足客户需求和对准客户商业价值、有差异化竞争力的产品构想。

五、 产品包需求

Charter商业计划的核心输出件是产品包需求，用于指导下游研发按照产品包需求开发出合适的产品。产品包需求来源于对客户原始需求的分析判断加工，是对最终要交付给客户(包括外部客户、内部客户)的产品包的完整、准确的描述，是对产品包进行开发、验证、销售、交付的依据。

产品开发的核心目的就是交付产品包，而不是裸机产品。正如2008年徐直军在IPD试验局、ESP14及GA5验收业务改进高级研讨会上的讲话中所说:“产品包除了裸机以外，还应该包括产品走向交付一系列的相关因素，包括包装，包括一系列的资料:对照安装资料可以安装，对照维护资料可以维护，对照问题处理资料可以处理问题，按照销售资料销售不能出错。另外，报价、配置器、网络设计工具以及跟产品销售、交付、制造及Marketing相关的所有东西，应该都是产品包的部分。”

任何产品包需求都应先从客户的商业问题分析开始，然后确定解决这些问题需要的系统特性，最后对系统特性进一步细化形成若干个系统需求。所有客户问题、系统特性及若干个系统需求的全集以及不同层次需求之间的分解，统一构成一个产品包需求。

对于产品包需求如何分层并形成，华为Marketing在2008年《全力构建对客户需求的理解力》一文中提道:“产品包需求是一个关键交付，产品包需求必须分层，需求分层方法论的研究工作要继续深入下去，要让人很容易理解产品包需求的重点在哪里，价值是什么，脉络是什么样的。商业价值如何转换成一条条产品包需求，既要看到树木，也要看到森林。当我们对产品有了清晰的价值定位时，就可以通过产品包需求分层清晰地知道产品特性是否支撑产品的价值定位，还需要在哪些方面加以改进。”

产品包需求的重点在于给出客户最关心，解决差异化、竞争力等最核心的需求。产品包需求从CDT交接到PDT，要保证产品商业价值和一条条需求都能传递给SESystem Engineer，系统工程师)，保证他们可以从商业价值的角度去看问题，否则看到的只是一条条的需求，不明白所做事情的价值是什么。理解了产品包商业价值和产品需求之间的内在关系，也就知道了产品包内在的驱动力，这对于SE准确设计出符合客户要求的产品是非常重要的。

产品规划阶段的产品包需求与IPD研发阶段的侧重点是不一样的。徐直军指出:“从Charter立项到PDCP6还有一个过程，大概是3个月到半年。在CDP阶段，产品包需求的重点在于给出客户最关心，解决差异化、竞争力等最核心的需求。现在我们回想起来，R4软交换里面最重要的是2G 3G合一，做到这一条，就解决了差异化和竞争力的问题。然后再配合其他的总共七八条特性，就有竞争力了。Charter开发阶段不要搞很多面面俱到的细节需求，结果反而把最重要最根本的问题忽视了。在Charter立项到PDCP这个阶段，就要着重解决产品包需求的细节完整、周全的问题，不能空有完美的概念，以致做出来的产品到处都是问题。”

六、敏捷持续规划

2011年，来自硅谷的风险投资家马克·安德森(Marc Andreessen)在报纸上发表了一篇题为《软件正在吞噬整个世界》的文章。安德森认为，未来以软件应用和互联网服务为代表的科技将会颠覆和冲击现在已经建立起来的行业结构，会有很多的成熟行业被软件和互联网服务所重构和瓦解。2013年10月，著名分析公司Gartner指出未来十大战略技术中，一个重要的趋势就是“软件定义一切”，包括软件定义的网络，软件定义的存储等。华为公司也清晰地认识到了这个趋势和变化给华为在ICT领域带来的挑战。在IPD的基础之上，针对软件和云服务产品“需求多”“变化频繁”“无统一标准”的特点，于2016年引入了ODP(Offering Definition Process，Offering定义流程)，ODP相对CDP是一种新的规划作业模式，ODP流程的特点是将商业投资决策与需求决策分离。

ODP把过去CDP基于版本的商业投资决策转向按年度投资决策并例行宙视。产品管理团队通过开发OBP(Offering Business Plan，产品包年度商业计划)，提交给商业领袖作为投资决策参考的依据。这里的OBP作为商业计划书，本质也需要回答前面产品规划中提到的4W+2H问题，包括本年度该产品的商业计划和目标是什么，以及如何达到该目标。相比Charter而言，OBP减少了对于产品包需求的严格要求，并不强调产品在年初规划立项时就搞清楚要做的需求，而是把注意力更多放在回答“市场策略”“客户价值”“规划方向”“花多少，赚多少”的问题上，通过描述本年度产品的经营计划和目标，并定期进行回顾，真正实现商业决策与需求决策分离。OBP改变了Charter传统上以研发项目、产品包需求为中心进行汇报决策的操作方式，更多把产品规划的注意力和中心专注在商业设计问题上。

ODP的另一个显著变化是需求的持续规划。在这里，需求持续规划的一个核心是价值驱动:需求不是按计划驱动，而是按价值驱动的，总是交付最高优先级的需求。通过小批量规划、短周期迭代，来实现产品增量的快速交付、快速反馈，做到尽可能少地减少由于需求不确定而带来的浪费和损失。在这里，和Charter的开发过程一样，更加强调客户协同合作，通过在前端需求分析、排序阶段卷入客户，后端和客户联合验证，由多个灵活敏捷的全功能团队负责特性/需求的E2E完整交付，来适配软件和云服务发布周期更短、需求变化更快的特点。

ODP是IPD为了适应业务变化，不断开放和演进的结果。2016年，任正非在华为公司IPD建设蓝血十杰及优秀XDT颁奖大会上指出：“IPD就像修万里长城一样，非常重要，不要因为互联网公司总是攻击我们，就对IPD失去信心。互联网公司响应客户需求的速度比我们快很多，我们对一个需求的满足，最短时间三五年，最长时间七八年。其实客户并不需要做到万无一失，我们有坚实的一面，也要有灵活的一面，要学习互联网公司轻和灵活的一面，让IPD也能敏捷起来。”

这两年我接触过不少企业,基本上都是细分行业的头部企 业,很多公司的老板,包括研发高管、人力资源副总,他们很 关心研发绩效管理这个话题。就研发本身来说,其实有几个概念要澄清。

一、研发体系的两个不等式
1、第一个不等式:工作时长≠工资绩效

这句话看上去简单易懂，但是每位研发高管仔细想一想,你有没有在私下里去统计你的下属工时?你在做绩效考评的时候,是不是也会根据加班的时长来给印象分呢?举个例子,比如说有很多同事在自己的微信朋友圈里面会秀一秀办公室的夜景啊!他这个背后想说什么?极有可能是向同事、向领导表表我自己工作勤奋,工作产出。所以说,从认识上和行动上并没有完全一致,这种情况在研发领域是非常普遍的一个现象。

2、第二个不等式:工作产出≠工资绩效

这句话就需要讨论一下,需要我们大家想一想,我们现在很多公司在计算设计的工作量的时候,经常是用文档的页数来 做评价的。软件我们就用代码行数,硬件我们就用网络数或者网络应交数。我们这种绩效的度量方式,就必然会使大家去做 一些工作,因为绩效的牵引作用是非常明显的。比如说我到一 些公司里面去,看到他们项目组的一些交互经验;到一些家电 企业、高科技企业,他们有很多设计文档,坦率的讲那个信息量太低了。本来是十几页能够说清楚的事情,一做就是一百多页设计文档,这种就是只有投入其实是没有产出的。做软件的也是这样的,就说代码,这个代码就是因为你考评的代表行以后,大家都是一个拷贝的方式,其实用函数调用,或者是采用 一些比较好的一个设计模式,都可以使这些代码既简洁又高效。 但是绩效牵引下面他们就会把这个代码做的很长。绩效也是这样的。所以这个地方大家想一想,我们不同的考核方式,不同的绩效经营方式会带来不同的行为,对公司来说是不同的效益的问题。总的来说,我们的绩效是一定要对照价值的,千万不要工作量导向。这个方面,现在有的公司已经在改,包括华为公司也在改。我们现在做度量的时候已经不再用代码行数了, 而是用特性点数,特性就是客户价值的特性点数、功能数,或者是敏捷里面的思道睿数,用这样的一些东西来度量,这就是 一个改良。

二、研发体系的三个不同

三个”不同”：与销售、服务、制造体系相比,研发体系的不同:
工作特征不同：创造性劳动、长周期、难量化、集体贡献
团队特点不同：学历高、相对单纯、流动性小、抗压能力不强
绩效表现不同：不直观、难评估、滞后效应明显、团队间可比性不强

为什么有三个不同呢?因为研发跟公司的其他部门相比如销售、服务、制造体系相比,在很多方面是不一样的。

首先,工作特征不同

研发的创造性劳动比较多,一个项目组的工作跟其它项目 可比性不强;现在的项目跟上一个项目很多地方也是不一样的; 研发里面很多工作是集体完成的,很难区分各自的问题及贡献, 所以研发的工作特征是特别不一样的。

第二,就是团队的特点不一样

研发团队有一个比较好的特点就是人比较单纯,队伍也较 稳定,和销售队伍比肯定强很多。但是它也有一个弊端,抗压 能力不够强,所以对有些简单粗暴的管理方法是不适应的,特 别现在90后都是主力的时候,是越来越不适应。我们怎么样去激发研发队伍?怎么样去做绩效牵引?

第三,绩效表现也是不一样的

因为在销售、服务、制造,他的绩效是很客观的,销售有 销售额、合同数、客户的满意度;制造有产量、产出、质量。 研发很多地方是不那么直观的,有时也不能完全地客观,他需要辅助一些主观的因素。举例:研发里面有一个项目进度延迟 了,这个原因是什么呢?有时候就是因为一个意想不到的技术难题卡在那里,团队不是不努力,也不是能力不行。一般来说, 遇到困难的那个团队都是非常勤奋,非常努力的。这个时候如果简单粗暴的去做评价,那肯定是不公平的。所以研发里面他的绩效考评会有一些主观的一些修正。这是研发体系跟销售、 服务、制造体系不一样的地方。

三、研发体系的四个不满意

公司视角： 研发目标难以定义 研发成果转化偏少
研发视角： 公司缺乏战略定力 研发人员难以激发

下面是四个不满意,首先公司有两个不满意。第一个不满意,中国企业很多公司老板是销售出身,他们对销售怎么样评 价,对制造的评价心里是有底的。但是对研发的目标、绩效评价难以定义。基本上都是研发的主管或者研发团队自己去制定的,他也把握不住,也就默认了,但是内心并不太认同。

第二个不满意,有很多老板觉得研发投入这么大,但是绩效产出并不高,也就是研发的转化率不高。有一家企业有350 个研发人员,每年是两个多亿的研发投入,但是这么多年投下去以后,他们现在销售产品中自营产品只占30%,另外70%, 还是会用别人的,所以老板就很抱怨,说研发的投入产出比太低,十多年20多亿下去,还只有30%是自己的产品。这就是公司层面的两个抱怨。

接下来是研发层面的两个不满意。研发高管、研发副总觉得公司在销售渠道、广告方面的投入是非常大的,但是一到研发投入的时候,就急功近利没有耐心,公司缺乏战略定力。研 发主管对下面的也会抱怨,现在的工程师越来越不好干,不像自己当年多么自觉、多么勤奋、多么努力,现在的很多工程师, 都是按部就班没有激情,干一天拿一天工资,队伍也不好带。

四、研发五个”困惑”

打仗的团队容易评价,进度/性能/质量/成本等很清楚,但中长期的技术研究、能力建设的绩效评价是个难题。特别是对于技术部门、平台部门、专业部门、重量级团队、技术专家等。”绩效评价如何能留得住顶尖的人才?如何能让冷板凳坐得住?”

研发部门的五个困惑:在我们定绩效目标,做绩效评价的 时候,对于那些直接打仗,做交付的一些部门,我们是很好定目标和做评价的。你只要把进度、性能、质量、成本这几个纬度看一下,就可以看得比较清楚。但是对于那些做长期研究的, 做基础能力建设的就比较难了。因为技术部门、平台部门他们的工作成果是很滞后的，还有很多成果都是 3 年以后才有绩效，但绩效评价是要当期的。所以很难看出来，通过当期价值来做评价很难评定这些专业部门。例如质量部本身并不能对质量负责，因为那个产品都不是他们自己做的。他们的绩效在哪里呢？公司里很多人其实是没有达成共识的，自己内部也没有达成共识，这种情况是非常普遍的。第四个关于重量级团队也是这样，专业团队绩效非常急功近利。这些团队他们口头禅是什么？长期目标达不成了还能活几年，如果今年的目标达不成今天就被砍头了。所以这些团队在长期投资上面没有意愿，后劲不足。

对于技术专家也是这样，不少公司的高管就抱怨说，引进的一些行业的大拿。引进的时候这些高管的简历看起来很闪亮，名头都很响。但是他们进来以后，好像并没有发挥多大的价值，与公司付出的成本相比，相差的很远。

我刚才就用 2345：两个不等、三个不同、四个不满意、五个困惑来做了一个表达。带着这些问题，分享几个关键的理念。
 
五、几个关键的理念

第一个理念，研发绩效管理要体现商业价值

这句话是没人反对的，一说起来大家都认，但是我下面说三句话大家要想一想了，自己企业有没有这个现象。

例如有的主管会说，“这个人水平很高”，如果我们把他考评给低了，他这个人就会走，走了公司损失比较大；有的研发团队做自我价值主张时说，我这个技术领先、行业首创；主管有时候评价一个部门的时候，也经常说我们这个部门能够产出很丰富、成果很多这些话，但是按照华为的说法：第一，茶壶里的饺子，我们是不承认的。不能以哪个水平的高低来定绩效结果。第二，我们是工程商人，我们要追求商业价值。就是我们要反对盲目创新，反对没有商业价值的创新。第三，我们要对标部门直接的产出才是有效产出。就是你的产出一定要对标组织，对标你的期望是在做布朗运动，你做再多产出也没用。这三句话都是华为任总的原话。研发绩效的管理要体现商业价值，但实际上我们在执行的时候并没有这么去做。

第二个理念，研发绩效需要当期和远期的均衡

尽管我们说销售、服务、制造也要有当期和远期的均衡，也不能急功近利。但是我们研发体系这一点就显得特别重要。因为研发这边有三代管理的概念：第一个成熟一代应用一代；第二个开发一代；第三个研究一代运营一代。你只有做三代管理以后公司才是有后劲的，才可能持续成功，才可能从偶然成功到必然成功。所以我们考核研发的时候，不仅要抓当前的项目交付和维护，还要特别在意前瞻性的技术研究，面向未来和长期的品牌建设能力打造。有人说，我们公司还在跟随阶段，不可能面向未来做太多投入。我的建议是什么呢？不用遍地开花，但一定要选择聚焦在几个点上做压强投入，否则你没有参与，你是很难在市场竞争中存活的。左边的这些技术突破、平台建设、能力打造都是要花时间来积累的， 都是见效比较慢的投入。公司在这方面要有耐心、有战略定力， 要久久为功。

第三个理念，责任结果导向不是单纯的结果导向

责任结果导向不是结果导向，多了责任两个字。现在很少有公司会基于个人的素质来做绩效评价，但是有些公司在做绩效评价的时候，会加入一些能力和行为这些因素。多数公司还是基于结果的，我觉得中国企业做得还是不错的。但是今天强调的是责任结果，是你的结果工作产出，要与这个部门的个人职责匹配上，你的定位和职责匹配上了，这样才能更认可你的结果。前两天有个老师分享绩效的时候，提了个话题，就是我们一个组织不能做布朗运动，做布朗运动是很低效的。通过此类的信息都是一个方向，这样才有力量。这个方向就是战略前沿，我们要通过战略解码来明确各个组织的职责和目标，然后做的工作要匹配这些职责部分,这才是对战略目标最高效率的一个支持。

材料里面举了三个例子。第一个例子:产品部,如果我们的产品部的部门职责是竞争力和交付进度的话,我就评价产品部技术、性能、交付进度偏差。尽管你支撑市场项目取得的了一 些收益,但这不是你的重点,这个方向不能偏了。

第二个例子,对平台部来说,如果我解码出来,对你的要求是要把平台做好,先把平台推广好,提高平台的复用率。这样你才能够把整个公司的竞争力和持久能力拉上去,如果你网建的这个主页,赚一些零头小利,你去支持那个项目或者进度偏差一点,这虽然有价值,但他不是核心的。

第三个例子就是另外一个角度,对于技术部门来说,如果你的职责是技术探索、 技术创新。这个时候上级部门就一定不能够以一时的成败论英雄,因为技术创新本来就是一个非常大的不确定性的活动,即使失败了以后,他也可以证明这个技术,只是路线不可行,他 这个工作也是很有价值的,这个团队也是很好的在履行自己的职责,他们的结果也是要被认可的。当然你可以说,如果是因为这个团队管理不善,大家不努力导致的失败,这个考评要打B或者是打C都是可以的。那就有个话题来了,怎么去判断这两种情况呢?我的经验就是要看过程。你要看这个项目组他在过程中的各种活动,各个交付件,他们的活动质量、交付件的质量,这就要求我们的研发主管一定要懂业务,并且要深入业务,研发是没有纯管理的,研发干部不能是纯管理者。

第四个理念,组织绩效不是个体绩效的简单叠加

一些企业他们是没有组织绩效的概念,给的绩效都是员工绩效,索取组织绩效他们就说主管的绩效不就是组织绩效。这个地方是要澄清这个话题,很多主管的工作习惯就是这样的, 我们很多主管在定自己绩效的时候,先让自己的下属分头定自己的目标,然后他再汇总形成自己目标。这种管理方式我觉得有点偷懒,有点不称职。

组织绩效是什么呢?组织绩效他一定是战略驱动、定位驱动和短板驱动。战略驱动这个词大家好理 解,我就不展开了。定位驱动是什么意思呢?就是你有不同的 定位不同的追求,你的绩效方向或计算目标是不同的。举个例子,如果你仅仅满足于支撑当前的交付,只要在我这个任期市场部、公司不抱怨不投诉就行。如果这样的话,你的注意力就肯定是放在当前的交付上面。但是,如果你想在3到5年走到业界的前列,你一定会想办法腾出资源,投入比较大的资源去 做技术研究、平台建设、能力打造,这就是定位驱动,不同的定位会有不同的结果。那什么是短板驱动?一个组织如果有短板的时候他肯定会限制自己的发展的。所以我们在定绩效目标的时候,就会针对短板特意的做一些牵引,就会给比较高的权重。举个例子,假设我们现在的产品质量不够好,那今年绩效几项目标里要加大质量考核的权重： 假设我的研发效率不高，那我就会加大效率考核的权重， 就用这种方式来牵引我们的组织绩效。然后有了组织绩效以后， 我们才能够牵引我们下级团队、下级部门和员工的个人绩效。

这两个过程就是要通过解码才能够做的好的， 所以要做好解码， 解码是一个团队的基本功。我们研发团队的一定要做好解码， 解码一定是我们做绩效管理这个关键的使能动作。我发现很多企业做管理没有方法， 大都是凭经验， 没有一个套路。其实我们做绩效管理， 一定要把解码这个动作， 这个方法要导入进来。你才能做好这个事。我觉得要把这个理念里面一些概念做一下澄清,例如我们说责任结果不是结果,责任结果不是做两个资料,多了责任两个字,组织绩效不是个人绩效。

研发的绩效评估不是那么直观,创造性劳动不是那么好管, 简单粗暴的管理是做不好的。据了解研发绩效管理在中国企业、 产业界做得都不好。所以这也是我们专门把研发绩效管理作为 一项来讲的原因。

七、重量级团队怎么考?

第一,重量级团队的绩效是战略驱动的,我们要围绕战略目标定绩效目标,来作为绩效结果评价。
第二,重量级团队作为一个经营单位,要对经营结果负责。
第三,就是我们要采用平衡计分卡的均衡,要避免急功近利。

很多重量级团队的主管就是活过今天再说,明天的事情明天再说。这个时候一定要用平衡积分卡做牵引,避免大家的急功近利。我们的产品线是一个经营单位,他不像阿米巴那种绝对的交易化。在我们的经营理念中,我们的内部管理开销不能太高,所以我们要把有限的管理资源投在客户界面上。阿米巴就是违反了这个原则,产品线也不是事业部,因为事业部太独立了。产品线是把一些公司级的平台和职能,仍然在公司层面共享,它实际上是效率更高的同时,风险也可以管控。这是华为选择产品线而不选择事业部的背后原因。

重量级团队怎么考?(示例)
PDT(产品团队)KPI指标
财务| (60%) | 订货额、销售收入、贡献利润率、回款
客户| (20%) | 客户关系、山头项目达成率
内部运营|(10%) | 存货周转率、成本目标达成率
学习成长|(10%) | 干部梯队准备度、骨干员工流失

PMT(组合管理团队)KPI指标
财务| (40%) | 销售收入、贡献利润率
客户| (15%) | 市场准入目标达成率、山头项目达成率
内部运营| (30%) |Charter偏差率、低效版本率、废弃项目占比
学习成长|(15%) | 区域骨干到位率、骨干员工流失

举一个例子:产品线下面的两个重量级团队,一个是PDT 产品团队,他是个经营单位,一个是PMT,它是个专业技能团 队,是个跨部门的重量级团队。这两个团队指标的条目、权重是不一样的,因为他们的责任结果、责任定位是不一样的,我们在设定考核条目、权重的时候,我们一定要基于战略、定位、 短板三个驱动。指标的设定是非常难的一件事情,因为考核的指挥棒和效应是非常强的,所以,我们设定一些指标的时候, 我们一定要去评判这些指标的正效应和负效应,任何一个指标都有正效应,也有负效应。看我们右边这个PMT的指标叫低效版本率,低效的版本哪一些版本是低效?比如有些公司他们有 200多个产品在卖,但是实际上畅销的产品有24个,这个低效版本率就有点低。如果把这个指标设定的挑战值太大,设成低效版本率低于30%,就会导致这个PMT趋于保守尽量少立项, 保守一定会带来组织的平庸那是得不偿失的,我宁愿组织犯错误,也不愿意组织保守没有活力,这是我们做管理特别忌讳的。 一个组织没有活力是非常糟糕的事,所以在设定指标的时候, 跟这个被考核的对象一起探讨,一定要探讨他的利和弊,这是设定指标的一个重要经验。

八、研发部怎么考?

“好交付、好平台、好队伍，研发核心价值在哪里,我们就考哪里”(任正非)
项目研发： 研发质量/成本/进度、研发周期/TTM
竞争力： 技术领先:技术竞争力 平台战略:效率/成本/质量
组织能力： 管理体系、人才队伍

因为很多老板是销售背景出身,对于研发是很陌生的。但是公司发展到这个程度以后要加强研发,他们对研发怎么考就没底。我的回答是你对研发有什么定位就怎么考。就如我公司的战略是做快速的跟随者,只希望研发是对比标杆快速跟进, 这个时候研发的重心就是打造执行力。如果你想从跟随市场到超越甚至到领先,那你一定要在技术研究、平台建设、能力打造上要多投入,面向未来多投入,你的考核就不一样了。就是公司的战略追求、研发核心价值在哪里我们就考哪里,这就是对研发部考的基本原则。、

一个好的研发部他一定会有这么几点,他一定有好的交付、有好的平台、有好的队伍,我们就拿这三个来评价我们的研发部。
做出好平台才是好部长,作为研发部长都没有平台给公司, 你就不是一个好部长。这就是我们对研发怎么考的一个大的原则和要求。

研发部怎么考?(示例)
财务| (15%) | 销售收入、贡献利润
客户| (50%) | 技术竞争力(技术标综合得分)、产品交付TTM、产品质量事故次数、目标成本达成率
内部运营|(20%) | 人均效率提升率、平台/CBB重用率、开发周期改进、研发费用执行偏差率
学习成长|(15%) | 干部梯队准备度、骨干员工流失

举研发部KPI的一个真实例子,稍微说明一下,就是研发部也要对财务承担连带责任,只是说比例不高。重量级团队他 的财务指标可能是70%,最低也是60%,但是我们研发部承担财务指标可能是15%。但是我用这个指标可以牵引研发,主动支持我们的市场、销售、制造和服务。还有研发主管说我对财务指标使不上劲,给我也没用,这个观点我是不认可的。对于研发部按期交付你的项目,把产品技术、质量、成本的竞争力拉上去,研发部的这些动作对于一线的响应更好一点,都能对财务产生直接的影响。所以挂财务指标它是有必要的。华为公司这么多年都是这么牵引的,用指标来牵引研发对一线的支持。

九、技术团队怎么考？

这也是一个高频话题， 技术团队常见的问题就是自我欣赏、自娱自乐。因为技术团队的一些主管一般都是技术比较浓厚的人， 经常是自我欣赏， 所以我带队伍的时候， 我就特别强调技术团队一定要有内部的客户意识， 我们一定要通过绩效KPI 的牵引来强化他们的意识。

技术部门一般有四个常见问题。第一个就是假ready, 有的技术团队开发的这个技术平台他说是ready ， 但实际上我们拿的产品不经用， 就发现有很多问题， 要么是质量不够成熟， 要么是考虑到场景不够丰富， 给产品的进度和质量带来很大的隐患，这是第一个假ready。技术项目究竟要做到什么程度才算ready呢？ 我们把技术项目要分类， 第一类是前瞻研究类的， 成果体现在专利上,体现在标准上就可以。第二类就是技术印证类的, 你证明这个路线可行或者不可行,就可以了。第三类就是技术货架类,这一项目就必须按照高质量的标准来交付,一定要有内部的测试,有内部的集成认证,你要做产品化管理,把工程特性DFx要做到位。在一个公司70%的技术项目应该都是第三 类的。

第二个问题就是我们很多技术项目没有应用,它的根因就在于技术规划和产品规划没有互锁。这个技术项目做出来以后内部没人用就放在那里,一年四季都没人用,这样就太低效太 浪费了。

第三个问题就是急功近利。技术团队走另外一个极端,它只强调短期的价值。如果你这样做我就要挑战你,你为什么要成立独立的技术部门?为什么不把那个技术部门和产品部门二合一,合在一起不是更高效?当然,我们也不要以一时成败论英雄,因为你这样会把技术部门赶到急功近利的路上去,这个时候就与他们的责任定位和核心使命错位了。

第四个就是缺乏应用支持。表现就是技术团队缺乏应用文档、缺乏支持团队,没有持续的对缺陷的修改,没有持续的版本升级,这样的产品部门就不敢用。所以技术部门一定要保证第三类技术项目的交付一定是完整的,一定要有产品交付包的概念。不仅仅只有那个核心的裸产品,还有一堆应用工具、技 术文档、一些推广的资料、售后的支持， 还有应用支持的内容。这些问题我们都需要通过对技术团队的KPI 的牵引避免他们走入这四个误区。

看一个真实的例子， 一个技术团队第一要有商业价值， 第二要有内部的客户意识， 要有技术支持， 这上面都
有指标来体现。同时在执行上也要强化开放合作、开放创新，不能什么事都是自己自娱自乐。一定要跟我们的供应商、客户、社会上的技术机构一起合作， 特别是跟供应商的合作。因为有时和他们一起创新容易在质量、成本、进度和TPM 上面有收益的。作为技术团队一定要有领军人才， 特别是人才的准备度，这是一个独特的地方。

回到前面的一个话题， 领导抱怨说很高成本找来的专家不好用，我来分析一下， 第一， 我们要认识到专家的技能并不完整， 他只精通某个方面或者精通某个层次， 要么是某个单点技术， 要么是加固型、系统型、网络性或解决方案型的。这时候需要公司为他配备一些资源、平台、队伍,至少要配个助手,形成一团队来支持他发挥价值。并不是每个人都能够创造平台,更多的人他只能在一个平台上跳舞。所以主管要为这些刚进的专家打造一个让他施展才华的平台。第二,专家要发挥价值,必须要让他们介入到我们研发的主业务流程里面去,不能浮在空 中,以前的一个说法叫专家进项目,专家进决策,专家要进到项目组里面,参与决策会议,特别是技术类的会议,这样才能够发挥专家的价值。第三,识别专家也会出现一些偏差,有些单位为了树立标杆的需要,或者工作的需要,他会把团队的或者部门的一些成果挂到某个专家头上。使这个专家带的光环会更好一点,不管以后跟客户交流,参加行业会议或其他方面影响力比较好。有时我们参加标准组织的一些专家,他很多的一 些工作成果、会议材料、会议策略都是在他去开会之前谋划好的,都是整个公司、整个部门帮他一起谋划好的,这个时候他只是一个科技活动家。有时,我们因为某种需要,也会把一些成果挂在某个专家头上,包括我们有时把国内的成果挂到海外专家头上去。这个时候也是市场和工作的需要。所以我们招聘专家的时候,要注意这个问题,因为这些专家他本人的水平没有他表现出来的那么高,很多时候他是一种组织成果,组织能力的一个载体,所以我们招聘专家的时候,要去识别这个问题。因为， 应聘的时候并不是每个专家都能够把这些话题主动谈出来。这就是为什么有的专家不好用， 背后的三个原因。

技术团队怎么考?(示例)
财务| (50%) | 平台发货套数、技术和平台项目进度偏差、断裂点技术目标达成率、发明专利数/标准组案被接纳数
客户| (20%) | 平台遗留缺陷密度、平台原因重大质量事故次数、平台目标成本达成率、平台问题评价解决周期
内部运营|(15%) | 人均效率提升率、、预算执行偏差率、技术合作项目执行偏差率
学习成长|(15%) | 干部梯队准备度、领军技术人才到位率、骨干员工流失

十、如何评价做工作无声无息的下属？

这个话题在研发是很有必要讨论的， 因为其他体系如销售体系、服务体系、制造体系都是有刚性的、有直观的绩效数据握在手上， 但研发绩效没那么直观， 所以这个话题必须要讨论一下。有些研发主管不走动管理， 获取的信息都是通过看邮件或者会议室听汇报， 我见过有些公司研发主管， 管的人就一百多个人， 都不怎么去走动。这样做的后果， 就是那些做事“ 轰轰烈烈， 有声有色” 的人容易获得认可。而那些踏踏实实做事的人常常看不到， 那些主管就觉得这些人好像比较平淡、比较平庸。

如果我们是基于外在的表现来评价， 而不是基于交付的价值来评价的时候， 这个动作对我们的组织氛围， 对我们的战斗力，伤害是非常大的。它会导致什么后果， 就是大家都去找亮点，都去整理汇报材料。而不是把精力放在为客户创造价值上面，这些开销都是无谓的开销， 并且成本也挺高。在华为， 我们一页ppt 成本大概是一万元钱， 一个十页的ppt 可能需要两个人的工作量才能做出来， 这个成本是非常高的。孙子兵法里面也提到过“ 善战者无名” 。华为任总也提到要警惕那个百灵鸟。那些静水潜流、无声无息能把事情做好的人， 他一般都有几个特征：
第一个思维比较缜密；第二组织能力比较强， 组织比较有序；第三风险考虑比较完善， 所谓的一切尽在掌握。这些人才是真正的高水平、高价值， 这些人才是真正值得我们激励的。我并不是反对必要的仪式感， 有时立下军令状、做一些嘉奖函、开庆功会， 这些仪式我觉得还是有意义的， 对加深团队的成就感，鼓舞士气还是有必要的， 只是绩效评价的时候我们一定要基于实际的贡献， 千万不要被表象所蒙蔽了。我们做研发主管你不深入业务， 也不走动管理你不是一个合格的主管。因为我也是这么评价我的下属， 你不深入业务不走动管理， 你就是一个不
合格的主管。

十一、绩效应用的强度多大为好?

我做了绩效考核肯定要去用,但怎么用,应用强度有多大?用轻了大家可能不重视,轻了作用就不大。你用太强了以后也会影响同事间的协作,因为每个人都会自我欣赏,主管对他的评价,与他的自评都是有落差的,每个公司都这样。运用 太强了以后就会导致这样的一个问题,就使那些优秀者大家都敬而远之。我的经验数据就是只要绩效结果导致大家的总体收入之比不超过2.5倍。这个效果就是正能量。如果我们考评为A的前10%的人的收入只有考评后为B的后三分之一的人的收入的130%,有的还低一点,这样对优秀的激励就太弱了。我始终相信,对团队中落后分子的温柔就是对优秀分子的伤害。 因为优秀人员的价值是非常重要的,我们的工作量可能大家都承担,但是工作的推进,技术的突破,项目的成功常常取决于关键的少数。这些人如果不做激励,不做挽留,那我们的管理就错位了。我接触了很多公司,他们对先进分子的激励,考评为A的年度奖比考评成为B的年度奖高30%。这个奖金在收入包里只有3个月到6个月的工资。只有这么一点差别,这个激励我觉得就太弱了。因为我刚才讲的这个130%是指年度收入包的差距不是奖金的差距,这个要说明一下。为什么有些公司的研发副总总是抱怨,研发团队缺乏奋斗精神没有活力,我的建议是他的绩效考评、绩效应用没有他的参与,对先进的激发不够,对后进的鞭策不够,这是一个很关键因素。第二,我们要把好招聘关,要选择那些只有通过自己的奋斗,才能改变命运的人,我们要把这些人招进来,这些人会更加珍惜我们提供的舞台。

举个H公司的例子,考评为A的人,他的年度税后的总收入是考评为B的税后总收入的197%,这个强度应该是够的。
下面这个表是Z公司的,他们的结果只有124%。这个强度就稍微弱了一点,但是比我刚才说的那个例子好。华为公司有个说法叫”两个嗷嗷叫”,绩效压力我们是嗷嗷叫,绩效激励我们也是嗷嗷叫,华为公司敢压担子舍得分享。这是华为公司充满活力的一个重要因素。

十二、绝对考评还是相对考评?

绝对考评:结果导向,减少内耗，适用于标准化工作,确定性工作:职员
相对考评:活力曲线,导向冲锋，适用于创造性劳动,不确定性工作:管理者/创造者

因为十多年以前,杰克·韦尔奇”活力曲线”在中国是很有市场的,大家都推相对考评。但是三十年河东,三十年河西,现 在我们有些企业去做相对考评,只做人与目标的比较,不做人与人的比较。有的是相对考评但对比例不做刚性控制。他们的想法就是强调激发组织活力,试图营造一个宽松的工作氛围。 我的观点是:规模小的研发团队是一个典型的熟人社会,主管对每个人都比较了解,我们的考评就可以灵活一点。但是如果你规模到了一定程度,你有100个人以上,我建议还是相对考评。为什么呢?因为研发的工作创造性比较强。有时我们做绝对的目标设定,我们是很难进行精确定义的,很难去设定绝对目标。如果你不控制比例,不做相对比例控制,就会导致部门之间、部门主管之间的一些博弈。就会导致放水,就是你好, 我好,大家都好。这样导致我们的考评失去作用,因为考评就是识别人,实施差异化激励,激发先进,鞭策后进。如果你失去了这个效用还不如不考。因为考核的开销是比较大的,所以研发的考核有时是需要的,因为我们的目标是很难定义的,特别是我们在制定目标的时候是很难预判的。所以我们的研发考核一定是客观加主观的一个组合。相对考评就能够激发队伍奋勇向前,争先恐后,早点突破。我们企业在社会上是充分竞争的,如果在内部一团和气的话,我们怎么样在市场上获得胜利? 企业没有胜利哪来的价值给大家做分配?谷歌以前考评也是很宽松的,后来他们也是强调人和人的比较。人性就是这样适度的压力可以避免懈怠,我们做管理一定要顺应人性管理的艺术。 我们刚才说的是指研发考评,非研发有一些直观度量,比如说生产线的工人计件就行了。对于一些资源类的工作,例如华为对后台支撑,比如说人事专员,总账会计这样的标准化岗位也是绝对考评,相对考评只是对研发岗位的考评。

最后,我给大家提三条建议:第一,你要考虑一下你的薪酬结构;第二,你的考评导向一定要旗帜鲜明,第三,你的激励强度一定要充分。94年,我们刚进华为的时候,华为的薪酬也不足,但是那时候华为给大家一个股票,那就不一样了,有想象空间,我做好了以后股票收益会非常高。以前我们在公司的时候,老板就跟我们讲过几次,什么时候要在阳台上去晒钞 票。这种想象空间是很有意义的,这个是薪酬结构上的话题。

第二,就是你要做到考评上一定要坚持用战功来做激励,要树立正气。要给那些出生无依赖,草根出身的人一个奋斗舞台, 这个很重要。第三,留住了一批人,留住奋斗者,这是我跟大家分享的三点。

再说一遍,就是对团队内的落后分子温柔就是对先进分子的伤害。因为先进分子是关键的少数,我们事业的成功常常取决于关键的少数。越是研发规模不大的公司越是激励资源不足的公司,我们越要做精兵战略,不养庸人、不养懒人、不 养闲人。

很多企业的绩效考核工作常常会面临这样的问题:相对其他部门,研发部门的考核指标提取、考核方式确定都有一定的难度。这也是人力资源专业人员和研发部门管理者困惑的难题。

曾经有企业试图对研发人员实行完全的定量考核,甚至提出以编写软件代码的行数作为一个重要考核指标,结果员工开始将一个命令可以解决的问题,拆分为几个命令,于是”大家都很忙,疲于写程序,工作结果完全超过了预期目标,但是软件的功能却没有实现”,完全背离了绩效考核设计的初衷,考核不得不紧急叫停。虽然这种方式停止了,但如何公正客观地评价研发人员工作业绩的问题却依然摆在管理者面前。

一、 研发人员考核难在哪里?

研发人员考核的困难主要集中于以下几点:

• 绩效指标提取困难,由于研发人员工作本身的独特性以及工作成果不易衡量,因此难以提炼直观量化的数字性指标;

• 工作内容界定困难,特别是预研人员,一些成果仅仅是证明某种试验或测试方法可行与否,证实与证伪具有同样的价值,难以在任务下达之前予以明确;

• 定性内容较多,影响考核的公正性;

• 考核方式的选取问题,很多企业的研发管理者为了回避考核的难题,而采取背后打分、不沟通的方式。

面临如此多的问题,如何对研发人员进行业绩评价呢?其实,考核中最为关键的是指标和评价方式,这两者是员工工作的向导和公司的价值取向,出不得偏差,否则就可能事倍功半,甚至劳而无功了。这里,我们也从这两点出发,分析研发人员的指标提炼和评价方式。

二、怎样提炼绩效指标

任何一项工作的展开必然是这样的思路:”正确的行为,沿着正确的道路,达成正确的结果”,提炼绩效指标也需要沿着这样的逻辑关系,从研发成果向前推出成功的路径以及正确的行为要求,具体见下图。

调研 → 可行性分析 → 设计路径 → 实施 → 结果实现

研发人员的考核指标可以界定为两个方面:一个是效益指标,一个是效率指标。效益指标是研发的成果在市场中产生的价值反映,如产品销售额、市场占有率等。效率指标则是指公司内部的研发效率和阶段成果完成情况,包括路径指标和行为指标,具体如产品开发周期、研发费用、产品规划符合度、批次整改率、单板/整机直通率、产品数据准确率等等。绩效指标提炼的过程实际上就是管理程序和工作流程的分析过程:

2.1  路径指标

路径指标是衡量研发过程是否符合总体研发规划的过程检测指标。从研发的整体流程环节看,虽然研发的成果不同,但是他们所遵循的程序是一致的,明确每一环节的关键监控点,也就可以形成考核的路径指标。这些路径指标的达成保证了最终结果的实现。

产品开发周期、研发费用等指标比较易于理解,产品规划符合度指标虽然不多见,却非常重要,下面是某公司对此的界定(见表一)。

表一 某公司对产品规划符合度的界定

指标名称：产品规划符合度
指标定义：产品线通过概念决策评审的版本和路标规划的符合程度衡量
指标算法：产品线规划符合度=1-M/(T+M)x70%-N/(T+M)x30%

T:在计算时间段内该产品线应该启动的版本数；
M:在计算时间段内该产品线非正常增减版本数,包括非正常新开发的版本数,这些版本没有进行路标规划,也没有进行路标更改,以及非正常取消版本,这些版本有路标规划,但是没有进行路标更改而非法取消了版本；
N:在计算时间段内该产品线未按路标执行的版本数,这些版本在没有经过路标更改的情况下,概念决策评审完成的时间(如果第一次评审不通过,则为第一次评审完成时间)与路标规划偏差一个月及以上。

2.2  统计方法

路标和0级计划、1级计划基本数据和经过更改认可后的数据。

在进行决策点评审(主要是概念决策评审)时,对照路标和0级计划、1级计划,检查是否在规划范围内以及时间偏差,在会议纪要中说明:

• 本版本是否计入非正常增删版本数;

• 本版本是否计入未按路标执行的版本数;

• 本版本启动时间与规划的时间偏差(天);

• 本版本与路标偏差的情况分析(包括情况说明、反映出的问题、改进措施等)。

2.3 行为指标

行为指标是研发过程中对正确职业行为的评价指标。

正确的路径还需要有正确的行为方式,许多公司重视研发过程性内容的积累和知识共享平台的搭建,这些内容就要求员工在研发的过程中关注文档的积累、数据的准确、程序的明晰记录等等。因此,可以设置文档完整率、项目报告完整性、数据差错分析等指标,以提出对研发人员具体行为的要求,这些也是许多职业化通道方案设计时需要分析的内容。如果公司已经建立了研发人员的职业发展路径标准,许多行为指标是可以从中提炼的。

2.4 效益指标

作为经济性的组织,任何一个研发成果都必须在市场上实现价值,效益指标就是用来评价产品对公司带来的价值和客户对其的认同度,例如产品销售额、市场占有率、客户满意度、产品故障率等等。由于这些指标具有明显的滞后性,不能即期反映研发的成果,因此,这种指标的使用更多要和公司的中期激励方案相结合,具有明显的项目制考核指标的特点。

同时,效益指标不适用于研发部门的个人考核,因为研发成果往往是团队合作的产物,作为部门、事业部、项目开发团队的考核更为合适。

三、如何选择考核方式

研发工作由于贡献特点和侧重点不同,在考核方式上可重点区分部门团队考核与员工个人考核两种。

3.1 部门团队考核

在研发工作中,部门、团队为基本的业务单元,对直接产品和最终产品的市场价值负有责任。因此,对部门、团队考核侧重的要素为效益指标和路径指标。但因为效益指标的滞后性问题,在整体的考核周期的设计上需要认真考虑以下两点:

对于效益指标,采取按项目周期进行考核的方式。许多研发成果的好坏是在项目结束之后一段时间体现出来,这部分指标的考核要在这个周期之后进行。

对于路径指标,采取按固定时间段进行考核的方式,多数为季度,以保证产品的研发过程符合公司预定的目标。

其中,路径指标占整体考核成绩的50%~70%,甚至更高,以体现公司的业绩导向和市场导向。为此,公司在奖金分配制度上也需要做相应的考虑,以配合这样的考核方式。

3.2 员工个人

由于研发成果更多属于团队合作的结果,每位研发人员只是负责最终成果的某个功能模块或某个环节,甚至有的研发人员不清楚自己的工作输出在最终产品中所起到的作用。他们的考核主要侧重点在于行为指标和路径指标。因此,结合这种工作特点和考核侧重点,可以采用PBC(Personal Business Commitment个人业绩承诺)评价方式。PBC的程序是:设定清晰的目标,并承诺为实现目标采取的具体策略和措施,以及对团队建设的贡献,并通过对这些承诺进行评价来考核研发人员。

PBC的重要特点就是将目标与实现的行为要素紧密结合起来,更像是一种计划考核,强调了行为和团队合作的重要性。其具体操作方式如下:

1）建立PBC目标
考核周期(一般为季度)之初,直接主管或是项目组组长交流部门或是项目组的工作目标,然后员工根据团队目标制定个人的工作目标。这些目标应该是简洁、易于考核、基于结果的,一般通过WIN、EXECUTE、TEAM三个层次来表达:

赢的承诺:为了支持部门或是项目组工作目标的完成,你必须做些什么。指标主要是行为指标和路径指标的结合。

执行的承诺:通过什么方法完成你赢的承诺呢?必须分析为了达成目标,需要采取的策略、方法以及对工具的需求,形成清晰的执行方案,并且有明确的时间限制和规定,若承诺按照计划按时执行,就能保证实现赢的承诺。

团队的承诺:为了同团队成员更好的合作,更加高效的完成赢和执行的承诺,员工应该做些什么。高效的团队工作需要有好的交流、参与、理解和相互支持,以一个整体去完成工作,保证团队成果的实现。PBC的举例见表二。

表二 PBC评价方式

PBC               不恰当的PBC                                       恰当的PBC
赢                   提高客户满意度                                  通过收集客户群体的反馈,提高客户满意度10%
执行               准备客户的分析材料                          依据解决顾客投诉的行动计划,在十天内解决相关的客户投诉
团队               解决如何评价客户满意度的问题      建立一个跨部门的合作小组,来确认和解决客户不满意的事件。每个季度末,交流小组工作

三、过程辅导

任何绩效考核工作都不是秋后算帐的评判,在工作的执行过程中,主管要即时给予员工支持和辅导,帮助员工解决问题和提升能力,这一点在一般的考核评价方式中都有介绍,在此不再赘述。

四、考核评价

依据考核周期之初确定的业绩承诺,主管对员工的整个工作情况进行评价,员工的绩效考核以目标完成结果为依据,考核的等级将影响员工的价值回报。

4.1 部门团队与个人考核的关系

部门团队的考核与员工个人的考核虽然在考核周期和侧重点不同,但两者不是孤立的,只有员工个人的业绩达成了,才能保证整个组织绩效的实现。为此,针对部门团队绩效考核的中长期激励方案必须体现出员工个人的价值回报，保证两者成为有机的整体。

KPI可以明确每个部门以及部门人员的业绩衡量指标,华为对于中高层的绩效管理是通过述职和KPI考核来完成的,即采用年终述职的方式,全面检查上一年的工作情况,并对下一年的KPI做出新的计划,同时阐述本部门达成KPI的措施与策略。

华为通过这种方法将公司的战略目标分解成各部门可直接行动的纲领,为各部门分解和监督工作提供了依据;述职报告结果直接作用于中高层,这提高了中高层人员的责任意识,鞭策其更加努力开展工作。

1 华为中高层述职方式、述职模型以及述职内容

1）、述职方式

华为的述职方式是逐级向上的,且多为中期述职。通常公司总裁向董事会述职;各委员会主要负责人、部门正职向总裁述职;各部门副职向各委员会述职;二级部门主要负责人向部门正职述职,由此,形成了一个层层负责的述职机制。在述职日程上,从每季度的第一个月中旬开始,这有利于公司绩效考核、定期审视和评估当下绩效,以及时进行改进。

2）、述职模型

华为的战略要实现长期目标与短期目标之间、财务目标与非财务目标之间、结果与过程之间的平衡。华为将公司战略分解为客户、财务、内部流程、学习与成长,并依据这四方面的内容制作综合平衡计分卡,具体内容详见表。

3）、述职内容

述职人员陈述述职年度的业务规划、预算指标和KPI指标的实际完成情况,并与年初制定的年度业务规划、预算指标和KPI指标进行对比,就完成程进行分析,找出差距;预测下一年度的各项任务、指标,并且提交具体的实施方案,以及需要的资源支持,做出承诺。

华为中高层管理者的具体述职内容体现在以下8个方面:

（1）目标完成情况

目标完成情况即本期业务完成情况,主要针对各项指标,按照最主要、主要、次要的顺序列出自己的不足和成绩,并且分析出现这种结果的原因。

（2）外部环境分析

外部环境分析即比较客户、竞争对手和自己的地位、差异、潜力与策略,机会;关注影响公司、部门KPI指标的环境因素、市场因素;以及业界最佳基准,这些都需要准确的数据来说明。

（3）KPI实现程度

KPI实现程度即报告近几期KPI完成情况,并进行对比,同时,报告述职年度的KPI完成情况,分析目标与实际完成情况之间的差距,并找出原因。

（4）提升核心竞争力的措施

提升核心竞争力的措施即完成KPI指标能力和增强管理力的措施。本部门在完成绩效指标的推进过程中,对即将采取的措施进行计划,预测实施效果。

（5）客户满意度分析

客户满意度分析即客户与内部客户的满意度,要有准确的数据,并分析满意与否的原因,制定相应措施。

（6）学习与成长

检查公司重大管理项目在本部门的推进计划和阶段目标的完成情况,提出和检查提高员工技能的计划、具体措施和效果,报告和分析组织氛围指数。

（7）预算与KPI承诺

根据公司战略目标、往期计划及指标完成情况,结合公司面临的国内、国外形势对下一期业务目标和KPI指标,提出挑战目标,并且做出承诺。

（8）反馈意见

在目标实施过程中将必要的人、财、物以及技术等各方面资源列示出来,便于公司协调,及时调配。

华为的中高层述职,结合KPI考核,考核制度均衡、有效,且注意到过程的控制与管理。绩效管理呈闭环模式,形成一种自我激励、自我约束的机制,从而不断提升公司的核心竞争力。

2 华为是怎么做年度述职的?

企业管理,核心在于对中高层及骨干的有效管理。普通员工难道不重要吗?这里不做讨论,各人有自己不同的理解方式。

不少企业的年终述职比政府工作报告的含水量还高,读起来感觉已世界大同,但细究起来,没有几句话是有用的。

那么,华为在2000年前后规模还相对较小的时候,怎么做中高层的年度述职呢?

1）、述职目的

先搞清楚述职的目的是什么。华为主要立足于以下三个目的:

强化中高层管理者的责任和目标意识,促使中高层管理者在实际工作中不断改进管理行为,促进员工和部门持续的绩效改进。

深化公司原有的绩效考核及任职资格管理制度,不断增强公司的整体核心竞争力。

强化部门间的协作关系,使各部门及其管理者为实现公司或上级部门的总体目标结成责任和利益共同体。

其目的并不是通过述职打个分、给个绩效结论就结束。持续的绩效改进、任职资格管理、部门协同等才是根本,也就是说,通过一次述职,能看到管理的螺旋提升。

2）、述职原则

华为的年终述职遵循三个原则:

以责任结果为导向,关注最终结果目标的达成。

坚持实事求是的原则,注重具体实例,强调以数据和事实讲话。

坚持考评结合原则,考绩效、评任职,面向未来绩效的提高。

这里面容易被忽略的两个关键词:强调数据讲话、面向未来绩效。而这两个思维在企业绩效管理过程中非常重要。

3）、述职内容

有哪些述职内容呢?包含两个部分:

一是绩效考核:

1年度初承诺目标或KPI指标,如组织增幅、人均创利、成本控制。

2本期工作中遇到的问题及改进策略。

3直接上级要求汇报的其它工作。

二是任职资格:

1绩效要求:近几年绩效考核连续成绩、年度工作目标达成度、年度工作目标完成效果。

2管理行为:华为有针对三、四、五级的管理干部建立任职资格行为标准,并对管理工作领域工作活动的成功行为有做解读,据此对应。

3管理绩效:组织在流程中的运作效果:与组织的可持续发展相关的工作进展情况;其它反应组织核心竞争力的指标。

4必备知识:包括两部分内容,专业技术、管理实务。

5品德要求:诚实正直(在与自己坚信的人生信条及价值观相冲突矛盾时仍能坚持公司原则,言行一致);廉洁奉公(一切遵从公司的规章制度,不因私利/私欲影响自己所从事的工作)。

6素质要求:业务(系统思维,收集与消化信息,组织成就导向,自信与自律):管理(献身精神,组织意识,领导能力,监控能力,前瞻性);协调(原则性与灵活性,人际理解关系建立,合作精神,影响能力,360°服务精神);改进(培养人才,自我批判)。

7经验要求:比如四级管理者,要具有本系统主要业务部门管理经验或职能部门副职经验。相关领域一定的工作经验(含基层工作经验),所管理的下属至少有两类人员(三级管理者、专业/技术人员),有一定的管理跨度。

似乎任职资格的内容和要求比工作绩效内容还多!

4）、述职流程

年终述职流程如下:

流程说明：

01下发年度述职表或通知

每年1月5日前,干部部(处)或总裁办下发年度述职表或通知

02述职者自检并提议本年度工作目标

每年1月10日前述职者对照年初制定的工作目标及四级管理任职资格要求,进行自检并结合主管的总目标及流程需要,以KPI指标体系为指引,确认该年度的主要工作目标或KPI指标。

自检表

述职者根据工作目标及任职资格要求,填写自检表一、二及年度工作目标卡。

信息收集

公司考核部门负责收集考评信息及对述职者进行管理绩效的周边调查;由任职资格体系专业人员负责收集部门管理绩效信息,

03述职评议

每年1月15日前由直接主管负责,针对考核内容组成评议小组。根据述职人自述、提问与答辩,评议小组根据工作目标及任职资格要求进行评议。

评价表

每年1月15日前由直接主管针对年初制定的工作目标及四级管理者任职资格要求,填写评价表。

04结果反馈

每年1月30日前评议小组对述职者本年度工作中出现的问题进行深入分析,并提出具体可行的改进策略。

沟通卡

每年1月30日前述职双方在充分沟通的基础上填写沟通卡及本年度工作目标。

05结果上报

每年2月5日前干部部(处)/总裁办将评定结果上报人力资源管理部。

附:自检表

5）、述职评定

述职成绩评定,华为没有采用100分制,而是采用等级评定。定义为四级:A(杰出)、B(良好)、C(尚可)、D(不足)。现在已调整为5级,且理解上已有些差异。

最后的结论怎么使用呢?

a) 工作业绩与任职资格的综合考评成绩作为工资、奖金、股金等价值分配的依据。

b) 依据制度性甄别程度,对有突出才干和突出贡献者实施职务的破格晋升。

c) 综评成绩作为管理者培训、职务置换等人力资源管理活动的依据。

1 新产品开发是企业的一种 “投资” 行为

这个跟平常我们对待产品开发的态度是完全不同的，一般从财务的角度来看，产品开发往往被看作是一项费用。比如有 A、B 两个项目，A 项目要花 1000 万，B 项目要花 100 万，如果公司只有 500 万，该上哪个项目呢？如果把产品开发看成费用，企业往往会从成本管控的角度来决定开发什么产品，不开发什么产品。但是，如果把产品开发看成投资，企业就会更多地考虑产品的前景、投资回报和风险。如果 1000 万的投资项目能够挣回一个亿，那就算是贷款也要做这个产品。对于公司来说，一定要清楚为什么要贷款，是因为预期这个投资能挣钱，投入会有产出。所以，把新产品开发看作 “投资” 还是看作 “费用”，不同的态度会导致企业不同的管理方式和决策方式。

新产品开发是一项投资，开发过程中的每个监控点都是对投资进行的决策，企业是否进行某个产品开发这项投资，要看市场环境有没有变化，投入的大小有没有变化，能不能达到预期的回报。产品开发过程中的每一个评审点（DCP）都是在检查是否要继续进行投资。所以 DCP 决策时主要关心是否投资，而不讨论技术细节。公司领导组成的决策团队 —— 集成组合管理团队（IPMT）开会时主要进行这样的投资决策，开会讨论某个产品要不要继续开发下去，不讨论技术问题，技术问题在产品开发团队（PDT）这个层面解决，所以 IPMT 的定位其实是银行家，研究的是投资问题。

2 检验产品开发成功与否的唯一标准就是市场成功

就是看市场反响好不好、赚不赚钱。这可能跟很多公司的理念不一样，很多公司会说通过产品开发积累了人员的经验，积累了一些技术成果。而在 IPD 模式里，这不是检验新产品开发成功与否的最重要的标准，最重要的标准就是赚不赚钱。如果产品不能给企业赚钱，那就是失败的。至于说锻炼了人、积累了技术成果，那只是副产品，是意外的惊喜，赚钱才是最核心的目标。

产品要赚钱，那就必须以市场为导向来进行设计，客户才能买账。所以产品开发是基于市场和客户需求进行的，如果没有市场需求绝对不能进行产品开发。在实践中，大家常常争论，做新产品是应该以 “技术驱动” 为主还是以 “市场驱动” 为主？这里可以明确地说，如果是要面向市场批量销售的 “产品”，就必须以 “市场驱动” 为主。很多创新型公司，往往以 “技术创新” 为主，忽视客户需求，造成所谓 “创新性产品很难被客户接受”，导致丢失市场和利润，甚至造成公司经营的重大危机。20 世纪 80 年代时 IBM 就曾发生过这样的事情，而 IBM 后来能走出这场危机，和全公司推行 IPD 体系是密切相关的。

3 高效的产品开发需要跨部门、跨系统的协同工作

人们往往认为产品开发是开发部一个部门的事，这种想法其实是错误的。产品开发绝对不是开发部一个部门就能完成的，开发部一个部门也无法掌握整个投资决策中的所有信息，比如新产品的市场有多大、供应链该如何搭建、生产线如何设置、未来的售后体系如何规划…… 这些工作都不是开发部一个部门能完成的。所以，产品开发需要跨部门的团队来完成，这个团队就是 “产品开发团队”（PDT）。

在这种新的组织架构下，产品开发团队彻底打破了 “部门墙”，整合了公司各部门的资源和功能，因此可以做出有效的业务决策。在 PDT 中，研发人员往往还是最多的，研发部外的人员虽然人数不多，但由于他们的资源和能力完全是研发人员所不具备的，因此这些少量的人员投入，却能让 PDT 真正从业务和生意的角度来策划和执行新产品的各项开发活动，而不是仅仅从技术的角度出发来做研发。这就像炒菜时放的佐料一样，虽然佐料只有那么一点点，却往往会让整盘菜的味道发生巨大的变化。
 
4 产品开发流程要在非结构化与结构化之间找到平衡

由于新产品开发活动中有大量的新型工作，所以产品开发项目中存在不确定性，这就要求产品开发流程在非结构化（随意的、无标准的）与过于结构化（官僚主义的、缓慢的）之间找到平衡，不能过于死板也不能过于随意。

因为产品开发是创新活动，所以不可能走一套非常严格、死板的流程，也就是说流程应该是可以变化的；但是产品开发又涉及各部门的大量工作，为了提高各部门之间的沟通、协调效率，同时保障开发质量，产品开发需要非常规范的流程。所以，第一，一定要制定一个很清晰的流程；第二，在具体的产品开发过程中，每一个项目又可以灵活处理，比如裁减这个流程，选择走某些环节，省略某些环节，这样就可以做到不教条，也不随意。

5 改造产品开发流程需要整个公司的变革

改造产品开发流程是一项系统工程，须要在流程、组织、激励、文化等方面进行改造，并持续进行。这期间 “变革管理” 是非常重要的一种策略和管理方法。很多公司老板在了解了上述优秀的产品开发体系思想后，往往头脑发热，认为整个体系的建成是非常迅速和容易的，甚至搞 “一夜切换”：今天还是老体系，明天新体系就开始运作了。

这种简单化思维，往往导致将来在业务压力和新体系的冲突中痛苦挣扎，最后的结果无非是两种：要么放弃新体系用老做法去赢得市场，虽然市场未丢失，但是变革已经名存实亡，企业还是回归了老体系；要么强行推行新体系，严格要求，最后丢失了大量的市场机会，虽然建成了新体系，但付出了过大的市场代价。

其实变革管理的核心是对人的管理。新体系理论上是相对容易理解的，但新体系涉及很多人，这些人的思想和认识的改变是非常困难的，这都要花很多的时间和精力。通过采用小范围试点再逐步推广等策略，既给人们留下了转变的思考期，又不会太大影响新产品推向市场的节奏，这才能真正完成 “在正在飞行的飞机上更换发动机” 这样困难的变革任务。

6 总结

以上这些产品开发管理的基本思想和原则，都是基于很多优秀公司的实践总结出来的。类似的思想大家往往都清楚，也很认同，但是，如何贯彻这些思想，如何保证这些思想的落实和执行，这才是 IPD 这个体系的精髓所在。

这些抽象的思想，在产品开发的过程中会体现在如何确定客户需求、如何定义产品、如何评审、如何测试、如何写文档、如何开会、如何制订和执行计划、如何交付成果、如何评价等细节中。所以，优秀的结果首先源于正确的思想，然后还需要正确的执行，这两者缺一不可。