◎​ 以业务成功为出发点

有这样一则笑话：古时候有个神医，以擅长治疗驼背而远近闻名，据说可以手到病除。一个驼背的人找上门来，请神医治病。只见神医将病人用两块门板紧紧固定起来，然后将其放倒。接下来，神医在病人的后背上不断跳来跳去，完全不顾及病人的呼喊。

通过神医大汗淋漓的卖力治疗，驼背算是治好了，可以病人也奄奄一息了。有人质问神医为何不顾病人的死活，神医回答：“我只管治驼背，其他的事情不归我管。”

保证病人的生命安全是医生治病的基本出发点。相应的，研发体系改进的出发点就是获得业务成功，否则无论多么先进的管理理念、多么完善的改进措施，都沦为纸上谈兵。一个高质量的解决方案，不仅需要解决当前的主要业务矛盾，还应该满足于长期的业务发展。

下面是一个从业务成功角度考虑解决方案的案例：

某公司依托于大型央企，具有雄厚的经济实力和技术基础，但是技术民用化进程却不理想，尚未有一款市场成功的产品。咨询方对该公司的研发体系进行了诊断，发现在管理体系中存在明显的改进点。如图3-4所示。

图3-4研发管理问题清单

面对如此明显的改进点，针对性的解决方案并不难提出，此处不再赘述。

但是请大家思考一下，如果您是公司的总经理或者研发负责人，迫在眉睫的事情是什么？是立即建立保证市场成功的研发体系吗？显然不是。

当前最重要的是迅速推出一款真正意义上获得市场成功的产品。这样可以稳住员工的心态，使管理者拥有将公司带向更高台阶的基础和施展空间。因此，比较切实的建议应当是：“将原型产品尽快获得市场验证并加快市场化进程，与其他公司合作开拓市场及产品研发，必要时开展并购”。如果此时一味强调管理改进的重要意义，显然是隔靴搔痒、远水解不了近渴。

企业的研发体系改进并非是在真空中进行，一个重要的出发点就是符合当前业务发展的重点，这需要咨询师适时地变换身份，站在企业经营者的角度，兼顾当前业务与长期发展，寻求那些重要且紧急的事情去发力。

◎​ 基于问题设计解决方案

基于问题分析的成果去设计解决方案，也就是要求方案具备针对性。否则，就好比打靶时没有瞄准，随便打出一枪，能否击中目标全凭运气。实际上，很多改进者在面对问题时，确实没有认真思考，而是简单地把“一时的想法”称之为解决方案，甚至通过堆砌名词概念，以提升解决方案的档次。这种解决方案纵使华丽，也经不起推敲。

很多研发改进者并不否认针对性的重要意义，只是不知道怎样才能做到。若想令解决方案真正具有针对性，需要足够的业务能力作为支撑。当改进者仅仅了解某个研发领域的一种管理实践时，很容易将其当作解决问题的不二法门。

某高科技企业拥有一个研发中心和若干事业部，研发中心负责新产品研制，事业部负责当前产品的销售和定制交付。企业的研发资源分别配置在研发中心和事业部。

每当面对技术难度高、研发工作量庞大、需要多个部门参与的产品研发项目时，资源协调和协作就会出现问题，结果研发项目在质量和进度方面都无法得到保障。

如何解决该企业遇到的协作难题？

这需要从该企业的研发问题分析入手。在研发项目这个层面，比较明显的问题是跨部门协作不畅、项目经理缺乏权力、研发协作流程不清晰。基于这样的问题分析，改进者可以从优化产品开发流程，强化项目经理权力和跨部门的绩效评价等措施入手。

这个解决方案是以问题分析为基础的，可以说具备一定的针对性。但是仔细考虑一下，就会发现解决方案对该企业问题而言力度不足，对问题尽管有一定的缓解作用，但是并不会取得决定性改善。

造成这个问题的根本原因在于研发资源被分散在不同部门，部门本位主义使得跨部门协作困难重重。如果不从根本上消除，问题依旧会出现，只是程度不同罢了。

对于企业同时拥有研发中心和事业部的情况，资源配置大致有表3-1的三种方式。

表3-1资源配置方式

方式一表示将主要的研发资源划归研发中心，并由其承担产品研发和改进工作；事业部保留部分服务支持能力，负责提出研发意向，并不承担具体研发任务。这种方式并不存在资源配置问题，需要注意的是，脱离了市场一线的研发中心，对产品规划提出了不小的难题，因此应该成立专门组织负责规划工作。

方式三与方式一正好相反，将研发资源直接配置到事业部，研发中心仅执行管理职能。这种方式也不存在资源配置问题，甚至效率更高。但是由此出现的问题就是，事业部为了完成当期的经营指标，不大乐意为长期发展进行储备，将会导致企业缺乏后劲。

方式二就是上述案例企业的现状，资源配置分布在各个部门，期望在两者之间取得平衡。令人遗憾的是，由于缺乏统一领导和协作意识，实际操作时还是会各自为战。

因此，类似于方式二的资源配置是不稳定的，尤其是在资源紧张的情况下，时常产生协作不顺畅的杂音。如果想获得根本性的改善，要么在方式一和方式三中做出选择、要么成立专门的组织实施更高级别的管控15。具体何种方式更有效，还需要进一步分析。

解决方案的针对性并非一句空话，要真正做到“知行合一”，就需要从研发问题分析阶段入手，进行系统化思考。

◎​ 边际收益递减

改进收益从何而来？

事实上，解决方案本身并不会凭空带来收益，任何一项收益都需要付出相应的代价。比如将串行的研发过程调整为并行，将获得周期缩短的收益，随之付出的代价就是资源配置增加、对并行工作能力提出更高的要求；将产品研发流程进行更加专业性分工和细化，有利于提高产品质量，同时研发资源投入增加、项目工作量增加（可能引起项目周期延长）是必然付出的代价；在软件开发过程中实施“敏捷模式”，如果研发团队的开发技能和需求分析能力没有相当幅度的提升，恐怕不会获得明显的收益，“敏捷模式”的附带品显然还包括研发团队的工作量增加。

解决方案实质上是付出某种代价而博得更具价值的收益。随着某个要素的不断强化，其边际收益将会不断下降，而边际成本却不断上升，当两者接近时，更多的努力投入反而使整体效率降低，此时解决方案的效果适得其反。比如产品规划工作，当投入规划的资源从零开始增加，对市场的把握也随之增强，规划质量随之提高；但超过一定阈值时，无论再投入多少资源，都无法改变市场不确定性这一现实，不可能产生万无一失的规划成果。流程优化对企业有重要意义，但当研发流程已经不是主要矛盾时，一味地在流程管理上下功夫，只会使流程体系愈加复杂和僵化，实际运作效率越来越低。

更广泛地说，不顾及企业的差异性，看起来再完美的研发管理体系，都会由于边际收益递减的规律，令收益不如预期的那样显眼，甚至会出现抱薪救火的局面。

为了使解决方案能够取得良好效果，务实的策略是“总体规划、分步实施”：将企业多方面的研发体系问题，根据优先次序，分步骤、分阶段解决，每次都聚焦于当前的首要问题。这样可以事半功倍、及时获得改进效果，同时也兼顾了企业的承受能力。

◎​ 关注重点而非追求完美

从前有个人来到一个偏远的山村，看到大家都趟着水过河，于是他就出钱在村里建了一座桥。一年后，桥建好了，很漂亮。但是他惊奇地发现，人们依然是趟着水过河。

他百思不得其解，就赶到河边问一个刚上岸的村民：“河上不是有桥吗？你们为什么还要趟着水过河呀？”村民回答：“桥？太不方便了，你看我到桥边要走500米，过了河再回来还要走500米，我从这里趟着水过河多近啊！”

如果将产品研发看成过河，以往简陋、粗暴的研发流程就好比趟水过河：河里有鳄鱼（缺陷），可能把渡河者吃掉；河中有洼地（人力不足），渡河者可能陷入其中，不知何时才能上岸；上游随时可能有山洪暴发（需求变更），把渡河者冲得远远偏离目的地。

而建好的桥就好比规范的、完善的研发流程，纸面上可以解决上述全部问题。但在执行的时候却会发现，为了解决诸多个性问题而统一的流程，对某个浅滩而言实在是规范过剩，对研发效率起到负面影响。这就是大家都不愿意“多走一公里”而选择趟水的原因。

结合前面谈到的代价和收益原则，我们发现任何解决方案都不会无懈可击，而且实际工作是千变万化的，不可能对每种情况都提供适应性的管理机制。能够满足70%以上的需求，或者规避70%以上的问题，已经算得上高质量的解决方案。

另外，“完美”的解决方案更加关注质量，但是研发体系需要在进度、质量和成本方面取得均衡。仅仅有质量并不能带来企业的市场成功，对“完美”的追求往往是徒劳的，改进者也不必去孜孜以求。在解决方案设计的时候，改进者是在均衡的基础上追求效益最大化。

某公司在进行客户定制产品研发时，为了保证立项的权威性和可靠性，其审批流程示意图如图3-5所示。

图3-5审批流程

项目立项主要涉及技术方案可行性、部件可采购性和制造系统的准备情况，因此需要三个部门负责人分别做出批示后，项目才能完成立项。如果立项过程能够在时间允许的条件下认真履行，确实可以规避风险。

但是在行业竞争的形势下，公司并没有足够的时间完成整个审批过程；公司80%以上的项目属于定制类型，并不存在技术风险，这类项目都会通过立项审批，也就是说审批实际上并没有发挥作用；少部分项目属于新型产品，确实存在技术风险，需要各个部门参与审核。该公司在执行立项审批流程时，一般都是在项目启动之后补上的，有时甚至由于某个领导的“驳回”而大费周章。

为了满足该公司的业务需求，咨询师将原有近乎完美的流程做了大幅度的简化。如图3-6所示。看起来简陋，但在实际运行时却取得了良好的效果。它对于大多数立项情况是适应的，尽管确实并不能100%地规避风险，这样已经足够了。

图3-6简化流程

◎​ 考虑业务能力的支撑

某公司为解决研发项目立项仓促、产品缺乏亮点、市场成功率低的问题，要求研发团队在产品概念阶段进行充分论证，确定产品需求和技术路线、评估产品可行性，目的是在项目初期把握好方向。

就这样，原来大约十天的工作，现在扩展到一个月。项目团队严格执行各项任务，最大限度地投入精力。但是结果并不令人满意：领导层认为概念阶段的工作成果和原来相比尽管充实了许多，不过却没有质的变化。看到自己的辛苦努力并未得到领导认可，项目团队感觉很失望。

这是很多改进工作的真实写照：在拿到整套标杆公司的标准模板时如获至宝，抱有很大的期待；在实施过程中也是竭尽全力，但是做着做着，感觉困难重重。业界标杆在他们心目中走下神坛，认为不过如此。

为什么会有这样的感受？

研发体系的两大重要工作是产品规划和产品开发。但研发工作不同于简单的程序化工作（比如审批、通知、检查等），它面临着巨大的不确定性，因此对执行主体的业务能力和主观能动性提出了很高的要求。当研发管理体系进行改进时，原来的工作模式和业务流程发生了变化，在多数情况下业务能力需要与之相适应。

在上述案例中，流程改进的大方向应该是切实的，但项目可行性评估、产品包需求定义、技术路线选择等活动是原来流程中缺乏和不充分的。这就对项目团队和决策团队提出了全新的业务能力要求。

值得注意的是，能够高质量地完成活动，取决于业务能力和资源投入。即使投入再多的时间也无法弥补业务能力不足的短板，类似“不同的人可以做好相同的事情”的期望是不切实际的，只会让上述案例类似的场景不断发生，令悲情的研发团队被诟病为“缺乏执行力”。

我们知道研发体系中产品方向、团队技能、技术积累和管理体系需要相互匹配。在管理体系进行调整时，对其他要素将会造成影响，比如影响团队的业务能力、基础的技术积累等。因此，好的研发管理体系改进，需要考虑业务能力的支撑情况，并有意识地促进其提升。

如何做到这一点？下面的案例就展示了如何在内部需求实现过程中考虑能力建设与支撑。

DFX16需求，也称为内部需求，是为了满足企业内部客户的工作便捷性而实现的功能。在企业中内部需求需要做到什么程度？如何去做？这个问题在不同企业中的答案是不同的。

首先应该理解，内部需求对于产品而言并非必不可少，即使它没有实现，客户和用户并不在意，他们关注的是产品功能是否被实现及实现的可靠性。考虑内部需求时，需要站在产品全生命周期的角度，使得产品的总体成本、交付周期、客户满意度、企业收益等综合效益最大化。

因此，在制定DFX策略时，需要充分考虑产品目标、当前技术积累水平、产品交付要求等因素，分步骤、有侧重地建立DFX规格，而不是一下子将全部DFX需求都实现在产品中。

在具体研发项目中，如何定义和实现DFX需求？

一种方式就是在需求定义阶段，邀请测试、制造、服务等领域工程师，提出各自的内部需求，由需求分析师进行整合，但是通常不会取得理想效果。即使是各个领域的资深工程师，也很少会深入研究和思考DFX需求，急切需要时只能提出一些零散的、不完整的需求，对实际工作意义不大。

笔者推荐一种比较务实的工作方式。可以事先要求测试、制造、服务等部门整理本领域的DFX需求，一个部门的集体贡献显然要高于某个工程师的临场发挥。这样就会形成一份比较完整的DFX需求规范，图3-7展示了DFS需求的片段。

图3-7 DFS需求的片段

在进行特定产品需求定义时，各领域工程师按照上述《DFX需求规范》中的条目，确定与当前产品相匹配的内部需求，最终由系统工程师负责需求整合、提交技术评审。

这种做法充分考虑到目前研发团队在DFX需求领域的实际业务能力，并不会对其造成工作负担，在多家企业的实际执行效果良好。