IPD研发体系咨询前期诊断调研：那些藏在细节里的"真相"

说实话，我在做研发体系咨询这些年以来，发现一个特别有意思的现象：很多企业在找我做IPD咨询之前，其实心里已经有个大概的判断了，他们觉得自己的研发流程有问题、项目经常延期、跨部门协作不顺畅。但真当我问他"具体哪里有问题，为什么会有这个问题"的时候，能说清楚的人其实不多。

这事儿让我想起一个比喻：就像一个人觉得自己身体不舒服，知道肯定有问题，但到底哪个器官出了毛病，需不需要做手术，得先做个全面体检不是？IPD研发体系咨询的前期诊断调研，说白了就是给企业的研发体系做一次"全面体检"。

那这次"体检"到底要查些什么？怎么查？查完之后能看出什么花儿来？别着急，我慢慢跟你说。

一、为什么前期诊断这么重要？

在展开聊诊断内容之前，我想先说个事儿。之前有家企业找到我，说要做IPD变革，态度特别坚决，恨不得一周之内就把方案做出来落地实施。结果呢？诊断环节我们花了将近一个月，等报告出来的时候，老板自己都愣住了——他以为自己知道问题所在，但诊断结果和他想的完全不一样。

比如说，他一直觉得是研发人员能力不行，所以项目才做不好。但诊断完之后发现，真正的问题是需求管理太烂了，研发团队接到的一百条需求里，有六十条是模糊的、二十条是相互矛盾的、还有十条做到一半被告知不要了。这种情况下，就算把团队换成清华北大毕业的，该延期还是得延期。

这就是前期诊断的价值所在。它不是走个过场，而是帮企业把"我以为的问题"和"真实的问题"区分开来。有很多企业的IPD变革最后没成功，不是方案不好，也不是团队不努力，而是从根儿上就"诊断错了"

做咨询这些 年，薄云团队总结出一套自己的诊断方法论，我们内部叫"五维诊断模型"。这五个维度基本上能把一个企业研发体系的老底儿给摸个七七八八。

二、诊断调研到底查什么？

1. 研发流程与制度——看"规矩"立得怎么样

首先我们要看的，是企业现有的研发流程和制度。这里说的流程，不是墙上贴的那张流程图，而是实际在运行的"潜规则"。

我举几个例子你就明白了。我们会问研发人员："你们的需求变更流程是怎样的？"如果对方说"很简单啊，直接找项目经理说一下就行"，那基本可以判断这个企业的需求变更管理是失控的。规范的做法应该有变更影响评估、有评审委员会、有正式的变更记录，而不是"说一下"这么随意。

还有一个常问的问题："一个需求从提出到开发完成，大概需要经过几次评审？"如果答案是"一两次"甚至"没评审过"，那这个产品的质量风险就很高。反过来，如果流程卡得太复杂，一个小需求光评审就要走两周，那又是过度管理的另一个极端。

在薄云的诊断方法里，我们会详细梳理端到端的研发流程，看看到底是流程缺失、流程过重，还是流程与实际执行"两张皮"。这个环节的诊断报告通常会很长，因为细节太多了，但从这些细节里往往能挖出很多深层次的问题。

2. 组织架构与职责——看"人"是怎么摆的

组织架构这事儿，表面上看一张组织架构图就能说清楚，但实际复杂得多。我们诊断的时候，会特别关注几个问题。

第一个是职责边界清不清楚。比如"架构师"这个岗位，有的企业里架构师只负责技术方案设计，有的企业里架构师还要兼任技术管理，还有的企业架构师实际上就是高级开发人员。名称一样，干的活儿完全不同。再比如测试团队和开发团队的关系，是独立汇报还是隶属于同一个部门？测试发现严重缺陷的时候，能不能"叫停"开发进度？这些组织设计上的细节，往往决定了跨部门协作的效率。

第二个是决策链条长不长。我见过最夸张的一家，一个技术选型的小决定要经过七个层级审批，等批下来黄花菜都凉了。也有的企业走向另一个极端，授权太充分，结果各个团队各自为政，产品版本永远对不齐。

第三个是资源池的运作方式。现在很多企业都搞资源池、矩阵式管理，那我们就要看资源池的调度机制是不是合理，项目经理和职能经理之间的权力边界是不是清晰。我见过资源池运作得很好的企业，也见过把资源池做成"扯皮池"的——每个人都说自己属于资源池，每个项目都说这个人被别的项目占着，最后变成一笔烂账。

3. 项目管理实践——看"事儿"是怎么推进的

项目管理这个维度，可能是企业最关心的一块，因为项目延期、成本超支、交付质量差这些"看得见的痛"都跟项目管理直接相关。

我们诊断的时候，会抽几个典型的项目做深度复盘。不是泛泛地聊，而是把项目的整个生命周期重新走一遍：从立项、需求分析、设计、开发、测试、发布，每个阶段发生了什么，时间花在哪里了，问题是怎么暴露出来的，又是怎么解决的。

通过这种"解剖式"的复盘，往往能发现很多有意思的现象。比如有的项目看起来进度正常，但实际上百分之三十的时间在返工；有的团队说需求变更少，但仔细一算，百分之四十的需求在开发过程中被修改过；还有的团队测试覆盖率号称达到百分之八十，但bug数量一点没少——后来发现所谓的"测试覆盖"就是跑了一遍用例，根本没验证功能正确性。

除了具体项目，我们还会看企业的项目管理机制。比如项目里程碑是怎么设置的，定期的项目评审会议有没有人真的在看、在管，项目风险是怎么识别和升级的，项目的经验教训有没有被沉淀下来下次避免。这些机制性的东西，比单个项目的成功或失败更重要。

4. 技术能力与知识管理——看"活儿"是怎么积累的

我们首先会看技术平台和工具链。你们现在用的开发框架是什么？版本管理怎么做？持续集成和持续交付跑通了吗？自动化测试覆盖率多少？这些看似是"工具"层面的问题，实际上反映了企业的技术成熟度。我见过有的企业还在用五六年前的技术框架，团队成员人均年流失率百分之三十，每来一个新人都要从头学起，技术债务越堆越高。

然后我们会看知识沉淀。技术文档有人写吗？写完有人看吗？项目复盘有人做吗？做完了那些经验教训是不是真的被记住了？有没有建立公共的技术组件库和最佳实践库？如果这些都没有，那就意味着每个项目都在重复造轮子，团队的能力没法叠加式增长。

还有一个维度是技术人才梯队。核心骨干有没有备份？新人有没有系统的培养计划？技术职级体系是不是清晰合理？这些问题现在不解决，等到关键人员离职的那一天，就会变成大问题。

5. 文化与氛围——看"心气儿"是怎么样的

最后这个维度，看起来有点虚，但其实是决定IPD变革成败最关键的因素之一。

我们会通过访谈、问卷和观察，去感受这个研发团队的氛围。大家是"只要把功能做出来就行"，还是"真的在乎产品质量"？跨部门协作的时候，是"这事不归我管"还是"我们一起想办法"？遇到困难的时候，是"先干了再说"还是"等领导指示"？这些文化层面的东西，没有写在制度里，但无处不在地影响着研发效率。

还有一个特别关注的点是"安全感"。团队成员敢不敢提问题？敢不敢暴露风险？敢不敢说"这个我做不了需要支持"？如果团队成员不敢说真话，那所有的流程制度都会变成走过场。我见过太多企业，出了问题大家第一反应是"别让领导知道"，结果小问题拖成大问题。

文化这东西，改起来最慢，但也最重要。薄云在做IPD咨询的时候，从来不会只关注流程和制度怎么改，而是会花很多精力帮企业一起打造"敢于说真话、敢于暴露问题"的氛围。

三、诊断报告里有什么？

诊断完成后，我们会产出一份厚厚的报告。这份报告不是随便写写的，每一页都有它的用处。

首先会有一个"现状全景图"，用可视化的方式把企业的研发体系现状呈现出来。哪些环节正常运转，哪些环节有明显问题，哪些环节存在潜在风险，一目了然。

然后是"问题根因分析"。我们不会只罗列现象，而是要往下挖，找到真正的原因。比如"项目延期"是现象，根因可能是需求频繁变更、资源不足、技术方案有问题、或者是项目管理不到位。找到根因，才能对症下药。

接下来是"对标分析"。我们会拿企业的现状和行业最佳实践对照，看看到底差在哪里，哪些是可以快速改进的，哪些是需要中长期投入的。

最后是"优先级建议"。问题肯定不是一朝一夕能全部解决的，我们会帮企业排出优先级，告诉你哪些问题必须先解决，哪些可以往后放放，解决问题的路径是什么。

四、诊断过程中企业的配合

说完了诊断查什么，我还想说说企业在诊断过程中应该怎么配合。

最重要的一点是"坦诚"。既然找第三方来做诊断，肯定是希望发现问题、解决问题。如果在这个环节还藏着掖着，那诊断就失去了意义。我遇到过一家企业，安排访谈的时候专门挑"嘴巴严"的人去，后来我们跟普通员工私下聊，发现完全是两个世界。这种情况，诊断报告写得再漂亮，也解决不了实际问题。

第二是"开放"。有的时候诊断结论可能会挑战企业现有的认知，比如说"你们引以为傲的某种做法其实是有问题的"。这时候需要企业有开放的心态去接受，而不是急于反驳。薄云在出诊断报告之前，都会跟企业反复确认哪些结论是事实、哪些是推断，确保报告是客观的、有说服力的。

第三是"参与"。诊断不是咨询方单向的调研，而是双方共同探索的过程。企业应该派真正懂业务、了解情况的人参与进来，而不是随便找个人应付。这样既能提高诊断的效率和质量，也能让企业对诊断结果更有" ownership "。

写在最后

IPD研发体系咨询的前期诊断，说起来好像挺学术的，但本质上就是"把脉问诊"。就像老中医要望闻问切一样，我们也要通过各种方式去了解企业研发体系的真实状况。

这个过程可能会发现一些企业不愿意面对的问题，可能会推翻一些习以为常的认知，可能会让有些人觉得"脸上挂不住"。但只有直面问题，才能解决问题。这也是薄云一直坚持的理念：不做表面文章，只做真正有价值的事。

如果你正在考虑做IPD咨询，我的建议是先认真对待前期诊断这个环节。它不是浪费时间，而是帮你找准方向、提高后续变革成功率的关键一步。毕竟，只有诊断对了，治疗才能有效。