IPD研发流程培训的员工技能认证标准

说到IPD研发流程，可能很多朋友第一反应是"那套华为用的管理方法"。确实，集成产品开发这套体系最早是IBM提出来，后来被华为发扬光大。但现在越来越多的企业都在搞自己的IPD体系建设，这事儿其实跟咱们每个搞研发、技术的人都有直接关系——因为最终落地执行的是人，而人的能力得有个标准来衡量。

薄云在推进IPD落地的过程中，发现最大的难点不是流程设计，而是人。流程写得很漂亮，培训也做了，但实际执行起来往往走样。这时候我们就需要一套相对客观的技能认证标准，让每个人知道自己处在什么水平，也让我们知道培训效果到底怎么样。今天这篇文章，想跟各位聊聊这套认证标准到底是怎么回事儿。

为什么需要专门的技能认证体系

先说个事儿吧。去年我们公司有个项目延期了整整两个月，事后复盘的时候发现，问题出在需求评审这个环节。产品经理写的需求文档，开发人员说看不懂；开发人员做的技术方案，测试人员说没问题，结果上线之后Bug一堆。大家面面相觑，都觉得自己没问题。那问题出在哪儿？

后来我们意识到，IPD流程里每个角色都有自己的职责边界，但这个边界到底怎么界定，不同人理解不一样。需求分析师觉得自己只需要写出功能列表就行，但开发人员等着他给出技术约束条件；架构师觉得自己画完架构图就完事了，但下面做详细设计的人根本不知道他的设计思路。这中间的GAP，就是缺乏统一的技能标准导致的。

我们薄云内部讨论了无数次，最后觉得必须建立一套认证标准。这套标准要解决三个问题：第一，明确每个岗位应该具备哪些能力；第二，提供一个可操作的评估方式；第三，给员工成长指明方向。听起来挺简单，做起来才发现里面的门道比想象的多。

核心能力框架是怎么搭建的

搭建能力框架这件事，我们参考了市面上好几种方法论，最后决定用"知识-技能-态度"三维模型来做基础架构。这个模型的好处是比较全面，不会只盯着技术能力而忽略软技能。

在知识维度上，我们把IPD相关的知识分成了几个层次。最底层是概念性知识，比如IPD的核心思想是什么、阶段门评审是什么意思、PDT团队是怎么运作的。这些概念性的内容，是个人都要掌握，没有商量余地。再往上是流程性知识，要求知道每个阶段有哪些活动、输入输出是什么、关键交付物长什么样。最上面是结构性知识，能够把各个流程串起来理解，知道某个决策会对上下游产生什么影响。

技能维度就比较具体了。我们把IPD流程中需要的技能一项一项列出来，比如需求分解与定义能力、技术方案评审能力、项目计划编制能力、风险管理能力、跨部门协调能力等等。每项能力都给出了具体的行為指标，而不是空泛的描述。比如需求分解能力，不是说你"能够分解需求"，而是说要能够"将用户需求转化为可验证的验收标准，并且识别出需求之间的依赖关系和优先级排序"。

态度维度可能是最容易被忽视的。我们最初也觉得态度这个东西没法量化，但后来发现，IPD推不下去很多时候不是能力问题，而是态度问题。比如有些人觉得流程太麻烦，能省则省；有些人觉得评审会议就是走过场，随便应付一下；有些人遇到问题第一反应是藏着掖着，而不是及时上报。这些态度问题，比能力不足危害更大。所以我们专门列出了一些态度指标，比如流程遵从意识、持续改进精神、协作共赢思维等等。

认证的层级是怎么设计的

有了能力框架，接下来要考虑怎么给人定级。我们设计了五个认证层级，从L1到L5，每个层级都有明确的定义和标准。这个设计参考了能力素质模型的一些通用做法，但做了很多针对IPD场景的定制。

L1级是基础级，定位是"流程参与者"。这个层级的人需要理解IPD的基本概念和核心理念，知道自己在流程中处于什么位置，承担什么角色，能够按照模板完成规定动作。举个具体例子，L1级的需求工程师，应该能够理解需求的基本分类（功能需求、非功能需求、约束条件），知道需求文档的基本结构，也知道评审的流程是怎样的。但这个阶段的人，更多是在指导下工作，独立处理复杂问题的能力还不够。

L2级是胜任级，定位是"流程执行者"。到了这个层级，就要求能够独立承担某个具体角色的大部分工作了。仍然以需求工程师为例，L2级不仅要会写需求文档，还要能够做需求分解，把大需求拆成可管理的小需求；能够跟客户做需求访谈，把模糊的业务语言转化为技术语言；能够参与需求评审，并且根据反馈修改文档。这个层级是团队的中坚力量，大部分骨干员工应该达到这个水平。

L3级是熟练级，定位是"流程优化者"。这个层级的人不仅要会执行，还要能够思考为什么要这么做，有没有更好的方式。他们能够发现流程中的问题，并且提出改进建议；能够在项目组中指导L1和L2级别的同事；能够处理比较复杂或边缘的情况。我们薄云现在大概有不到20%的员工达到L3级别，这个层级的人是各项目的核心骨干。

L4级是专家级，定位是"流程设计者"。到这个级别，已经不满足于优化现有流程了，而是能够根据实际情况裁剪流程、设计新的流程机制。他们能够诊断组织层面的流程问题，并且提出系统性的解决方案。这个层级的人在薄云不超过5%，都是各个领域的大拿了。

L5级是卓越级，定位是"流程布道者"。这个层级的人，不仅自己精通，还能够把经验沉淀下来，传播出去。他们能够编写培训教材，能够做内外部的分享交流，能够影响整个组织的流程文化。目前薄云只有极少数几位老同志达到了这个标准。

各层级关键差异对比

评估方式和认证流程

标准再好看，如果评估方式不靠谱，最后也会变成形式主义。这一块我们花了很多心思，也走过一些弯路，现在算是总结出了一套相对可行的方法。

评估方式我们采用了"理论+实操+答辩"三结合的模式。理论部分主要通过在线测试来考核，内容涵盖IPD的概念、流程、工具、方法论等等。这个测试不是简单的选择题，而是设计了一些场景题，让被评估者做判断或者选择解决方案。测试题库大概有三四百道，每次随机抽取，保证一定的覆盖面。

实操部分是最花时间的。我们会根据被评估者的岗位，设计一个实际的任务场景。比如评估一个项目计划能力，就让他基于一个给定的项目背景，编制完整的项目计划，包括工作分解结构、进度安排、资源估算、风险识别等等。完成后，由评委组来评审，看他的方案是否合理、是否考虑了各种约束、是否有可操作性。这个环节的评委一般由L4或L5级的人员担任，确保评估的专业性。

答辩环节主要是考察综合素质。评委会让被评估者介绍自己做过的一个项目，在项目中承担什么角色，遇到了什么问题，怎么处理的，最后复盘有什么收获。通过这个环节，可以看出一个人的思维深度、表达能力和反思能力。这个环节我们特别强调"说人话"，不想要那种背课文式的回答，而是真实地分享自己的经验和思考。

认证流程大概是这样一个顺序：先参加规定的培训课程，然后在线完成理论测试，测试通过后预约实操评估和答辩，三个环节都通过之后就可以获得相应层级的认证证书。证书有效期是两年，到期需要重新评估。这个设计是为了避免"一劳永逸"的情况，毕竟IPD体系本身也在不断演进，人的能力也需要持续更新。

培训体系如何支撑认证

认证不是为了卡人，而是为了促进成长。所以在认证体系之外，必须有配套的培训体系来支撑。我们薄云的培训体系是跟认证标准一一对应的，每个层级都有对应的培训课程。

L1级别的培训主要是导入性质的，内容包括IPD概述、各角色职责介绍、基础工具使用等等。这个层级的培训以线上课程为主，辅以一些简单的练习任务。培训周期大概两周，目的是让新人快速建立对IPD的整体认知。

L2级别的培训就开始分角色了。不同岗位的人，学习的内容会有差异。比如项目管理人员要学项目管理在IPD框架下的应用，需求工程师要学需求分析与需求管理的技术，开发人员要学技术方案设计的规范与评审方法。这个层级的培训以线下工作坊为主，强调互动和实操。培训周期大概一个多月，期间会有不少作业和小组讨论。

L3级别的培训就更深入了。这个阶段会有很多案例研讨，分析实际项目中的成功经验和失败教训。学员要自己组队，选择一个真实的项目做流程审计，找出问题和改进机会，最后形成报告并汇报。这个过程很痛苦，但收获也很大。培训周期大概两个月，都是周末上课。

L4和L5级别的培训主要是通过参与实际项目来完成了。我们会让资深人员参与流程改进项目，在实践中提升能力。同时也会推荐他们去参加外部的一些认证培训或者行业交流，开阔视野。

落地过程中遇到的一些实际问题

说完了理论层面的东西，最后想聊聊在实际落地过程中遇到的一些问题，有些解决了，有些还在想办法。

第一个问题是认证标准与日常工作如何结合。最初我们把认证做成了一个独立的事情，员工为了拿证去突击学习，但学习的内容跟日常工作脱节，学完就忘了。后来我们调整了思路，把认证考核的内容嵌入到日常工作中。比如项目复盘的时候，要求用IPD的框架来分析；阶段评审的时候，要求按照标准模板来准备材料。这样一来，日常工作本身就在积累认证所需的证据。

第二个问题是不同部门的标准如何统一。研发部门、产品部门、项目管理部门、职能部门，对IPD的理解和执行方式都不太一样。研发觉得产品给的需求不清晰，产品觉得研发的理解能力有问题，项目经理夹在中间两头受气。我们后来花了很大力气来做跨部门的拉通，用共同的项目来建立共识。现在各部门在同一个项目里协作，争议比以前少很多了。

第三个问题是如何避免认证变成新一轮的形式主义。这个确实挺难的。我们的做法是不断强调认证的目的是为了帮助大家成长，而不是为了制造压力。同时在评估的时候，尽量选择实际工作中的案例，而不是假设性的场景。另外，我们也建立了申诉机制，如果有人觉得评估结果不公平，可以申请复核。

说到底，IPD技能认证这件事没有什么捷径，就是不断实践、不断总结、不断优化。薄云自己也是摸石头过河，目前只能说初步跑通了，但距离理想状态还有很大差距。如果各位朋友所在的企业也在做类似的事情，欢迎一起交流心得。

流程是骨架，人是血肉。骨架搭好了，血肉也要跟上。希望这篇文章能给正在推行IPD的朋友们一点参考。各家企业的情况不同，最好的做法还是要结合自己的实际情况来调整。毕竟，适合自己的才是最好的。