我帮企业省下研发成本后，发现了这些问题
去年年末，我接触到一家做智能硬件的中小型制造企业。老板愁眉苦脸地跟我说，他们每年研发投入接近两千万，但产品上市总是慢半拍，成本还降不下来。他问我有没有什么办法能让研发体系变得更高效。当时我心里就想，这事儿我见过太多了，很多企业在研发上花了不少钱，但效果总是不尽如人意。今天我想聊聊IPD研发体系咨询是怎么帮助企业真正把研发成本降下来的，顺便分享几个我亲身经历的案例。
为什么研发成本总是居高不下？
在聊IPD之前，我想先说说为什么很多企业的研发成本像是个无底洞。我观察下来，主要有这几个方面的原因。首先是重复劳动，不同的项目组在干类似的事情，工具链、基础模块大家各搞各的，导致资源严重浪费。其次是需求变更太随意，产品做到一半，市场部门说需求要改，技术部门只能推翻重来，这种返工的成本是最高的。还有就是决策流程不清晰，一个技术方案该用不该用，没有明确的标准，大家开会讨论来讨论去，最后往往是谁声音大谁说了算，时间就这么过去了。
更关键的是，很多企业没有把研发当成一个完整的体系来管理。研发不仅仅是写代码、做测试，它涉及到市场调研、需求分析、架构设计、开发实现、测试验证、发布维护等等环节，任何一个环节掉链子，都会导致整体成本上升。这就像做饭一样，如果食材采购、刀工处理、火候控制、调味分别由不同的人负责，但这些人从来不沟通，那做出来的菜不翻车才怪。
IPD到底是什么？
说到IPD，可能有些朋友觉得这是个很高大上的概念。但如果你让我用大白话解释，我会说IPD就是一套帮企业把研发这件事做得更有条理的方法论。它的核心思想很简单：把研发当作一个产品来做，而不是当作一堆技术任务来做。
IPD强调几个关键点。第一是以市场需求为驱动，研发不是技术人员想做什么就做什么，而是市场需要什么我们就做什么。第二是跨部门协同，研发、市场、生产、财务、采购这些部门要在同一个框架下工作，而不是各自为战。第三是阶段性评审，在研发的每个关键节点都要评估这个项目还要不要继续走下去，避免在错误的方向上投入太多资源。第四是平台化和模块化，尽量复用已有的成果，而不是每次都从零开始。
这套方法论最早是IBM提出来的，后来华为花了几十亿学费把它引入国内，经过二十多年的发展，已经有很多企业在这套体系上尝到了甜头。但我要说的是，IPD不是万能药，不是照搬照抄就能成功的，关键是要结合企业的实际情况做定制化落地。
案例一：一家智能家居企业的蜕变
来说说开头提到的那家智能硬件企业。这家公司大概有三百多人的研发团队，做智能门锁、智能摄像头、智能音箱这些产品。我刚进去做调研的时候，发现他们的问题挺典型的。
项目延期是家常便饭。平均每个产品从立项到上市要十八个月，而竞争对手只需要十二个月。硬件开发周期长，软件更是经常拖后腿，因为硬件一旦定版，软件这边还在改需求，两边协调成本极高。我问他们为什么不做模块化设计，他们说以前也尝试过，但维护成本太高，后来就放弃了，各做各的。
研发成本像是个黑洞。他们每年研发费用占营收的比例超过百分之十五，但新产品带来的营收增长却越来越慢。更让他们头疼的是库存问题，因为研发周期太长，市场变化又快，产品上市时已经不是市场最需要的了，只能低价促销。
我们花了大概三个月时间帮他们做IPD体系改造。主要做了这么几件事。首先是建立需求管理委员会，所有需求必须经过评审才能进入研发排期，需求变更要付出代价，这个代价不是说要罚钱，而是要让变更发起人明白，变更会导致资源重新分配，可能影响其他项目的进度。其次是重构研发组织架构，按照产品线而非职能线来组建团队，每个产品线都有完整的端到端负责人，从需求到交付一个人牵头，避免部门墙。第三是搭建技术平台，把通用的技术能力沉淀下来，比如联网模组、云端接口、APP框架这些，做成标准化的平台，新产品只需要在平台上做定制开发就行。
大概一年之后，他们的研发周期从十八个月降到了十三个月，研发人员没增加，但人均产出提升了百分之三十。更重要的是，因为交付周期缩短，产品能更好地跟上市场节奏，库存周转率提高了，滞销产品少了，研发投入的回报率自然就上去了。
案例二：一家软件公司的意外收获
再说一个软件公司的例子。这家公司是做企业级SaaS的，规模不大，一百多号人，但技术氛围很浓。老板是个技术出身的人，很注重技术先进性，但不太关心管理。他跟我说，他们从来不缺技术牛人，但项目总是延期，成本也控不住，他不知道问题出在哪里。
我去调研之后发现，这家公司的研发管理基本上是放养状态。程序员想怎么开发就怎么开发，没有统一的技术规范，每个人写代码的风格都不一样。代码Review偶尔做一下，但流于形式，发现了问题也没人改。项目排期就是老板拍脑袋定个时间，程序员埋头干，干到哪算哪。测试环节经常被压缩，因为要赶上线时间，导致线上Bug不断，维护成本飙升。
我们帮他做了几件事。第一是建立技术规范和工程实践标准，包括代码规范、文档要求、CI/CD流程、自动化测试覆盖率要求，这些看似琐碎，但对研发效率影响很大。第二是引入迭代开发模式，把大项目拆成两周一个迭代，每个迭代都能交付可工作的软件，及时获取用户反馈，避免闭门造车。第三是建立技术决策机制，重要的技术选型要经过技术委员会讨论，不能某个人说了算，避免技术债务累积。
这个改造大概进行了六个月，效果挺让人惊喜的。首先是Bug数量明显下降，线上故障从每月十几次降到了每月两三次。其次是新员工入职效率提高了，因为代码规范、文档都比较齐全，新人不用花大量时间看代码就能上手。还有一个意外收获是，因为开发流程更透明了，项目进度更容易追踪，老板对研发团队的信任度反而提高了，不用天天追问进度，沟通成本也降低了。
这两个案例的共同点
回顾这两个案例，我发现有个共同点：研发成本降低不是靠省钱，而是靠减少浪费。那些重复造轮子的时间、那些因为需求变更导致的返工、那些因为沟通不畅产生的内耗，这些才是研发成本居高不下的真正原因。IPD体系咨询做的事情，就是帮助企业识别并消除这些浪费。
当然，改造过程并不轻松。第一个案例中，技术平台建设花了将近半年时间，期间还要保证现有业务正常运转，团队压力很大。第二个案例中，推行代码规范的时候，有些老程序员不适应，觉得写文档太麻烦，差点闹情绪。这些都需要企业有足够的决心和耐心才能扛过去。
薄云在研发体系咨询中的角色
说到这里，我想提一下薄云。薄云一直专注于帮助企业构建更高效的研发体系，在IPD落地这块积累了很多实战经验。我们发现，不同行业、不同规模的企业，面临的问题虽然表象不同，但底层逻辑是一样的。关键是要找到适合企业现阶段的那个切入点，而不是一上来就要搞大而全的体系变革。
比如对于初创企业，可能最重要的就是先把需求管理和版本规划理清楚；对于成熟企业，可能更需要关注平台化建设和跨部门协同。薄云的方法是先做深入的诊断，找出最痛的那个点，先打穿这个点，让企业看到效果，再逐步铺开其他方面的改造。这种小步快跑、持续迭代的方式，比一刀切式的变革更容易成功。
我们还发现，研发体系咨询最难的不是方法论本身，而是如何让方法论真正落地。很多企业请咨询公司做了方案，但方案躺在抽屉里没人执行，最后不了了之。薄云在这一点上做得比较扎实，我们会陪着企业一起做落地，把咨询成果转化为企业自己的能力和流程，而不仅仅是交付一份报告。
关于研发成本的几点真心话
聊了这么多，我想分享几点我自己的体会。研发成本不是越低越好，关键是要花在刀刃上。有些企业为了省研发成本，砍掉必要的测试环节，结果产品上市后问题频出，反而花了更多钱去补救，这种省钱的思路是有问题的。
研发体系的建立需要时间，不可能一蹴而就。那些希望三个月就能让研发成本大幅下降的企业，大概率会失望。研发体系咨询能帮你少走弯路，但该花的精力一点都不会少。重要的是坚持做正确的事情，时间会给出答案。
还有一点，技术人才是研发体系的核心，再好的体系也需要人来执行。如果企业的人才培养机制跟不上，再好的方法论也发挥不出作用。所以我们在做咨询的时候，往往也会帮企业梳理人才发展通道，帮助技术人员成长，这对于研发体系的长期健康运行至关重要。
如果你正在为研发成本发愁，不妨先静下心来想想，问题到底出在哪里。是需求太随意，还是复用太少，还是流程不透明？找准问题，对症下药，比盲目上系统、招人要有效得多。希望今天的分享能给你一些启发。
