精选书籍《智慧研发管理》

来源:伯特管理咨询公司发布时间：2020-03-24 浏览次数：

作者：谢宁

伯特咨询为您呈现经典管理书籍的内容摘要，帮助高管们随时随地——拿出5分钟，读完这本书。

微信图片_20190917143719.png

- 关键词1：质量保证、技术评审 -

技术评审是在研发过程中由技术专家对研发人员交付的工作产品从技术角度进行评审。技术评审是以发现工作产品的缺陷为目的，帮助纠正缺陷，避免把缺陷带入到下个阶段。针对一些技术风险，要帮助研发团队进行分析以及决策是否可以带着风险进入下个阶段或者如何跟踪防范风险的发生。另外，许多企业只有生产产品的测试工作，没有研发过程测试，如单元测试、集成测试等。某公司的产品质量控制手段从质量度量与测评、引导和培训、质量审计、问题沟通协调及上升以及问题分析及回溯五大方面展开。

将质量控制目标分解到各个阶段，以便于分阶段进行质量控制活动。

- 关键词2：产品可维护性、客户导向 -

华为工程师早期在“技术文化”引导下开发的产品在市场上遭到了大量的问题和挫折，同时因为可维护性差导致技术服务难度加大，供应链库存积压严重。最明显的是研发工程师喜欢采用新工艺、新技术（或受到供应商推荐影响）导致量产不良率非常高，BOM（Bill Of Material的缩写，指物料清单)数量在同类公司中最多，部件零件数量最多，更改通知单“满天飞”，这样状况导致内部管理成本急剧膨大，因为这些产品过度地强调了“创新”。华为为了解决这个问题，在内部搞了一个“反幼稚病”活动，把从运营商退回来的设备单板和为运营商进行维护的往返机票，“奖”给了研发人员。后来，在针对市场、研发等新员工入职引导培训中，增加一项“巡查供应链物流‘三品’库房积压物品”。这些宣传、培训等种种措施都是为了将“以客户需求为导向”、“创新更强调对成熟技术的继承”、“下一个工序就是客户”等理念灌输到研发工程师脑海里面。

- 关键词3：系统工程师的职能、专业烟囱 -

在很多企业中，由于开发技能和知识的不同，人员按照专业技能需求被分到不同的职业序列中，这往往容易造成每个专业领域的人员站在各自的立场上考虑事情，只关注于本领域效果的最优化，而非整体的、系统上的最优化。久而久之，便形成了专业领域的“烟囱”（或叫做专业技术上的“官僚主义”），纵向沟通不强，横向整合不够，一旦出现问题后，互相推诿，导致质量恶性循环下去。设计工程师与系统工程师在思路上的差异。设计工程师从专家的角度看问题，从内部看系统：只关心那些会影响其个人的设计任务的系统其它部分；但不一定关心设计工作如何影响其它人的工作。系统工程师具有系统观，从外部看系统：关注系统所有部分，这些部分会影响系统总体设计/性能/成本/进度。系统工程是对将需求转换为一个具体的技术工作的管理，需要对以下各项进行综合考虑，以满足成本、技术性能及计划目标：系统性能参数、满足需求的、最优的系统配置、技术活动的计划和控制、各个专业领域的集成等。系统工程师要倡导系统的整体性。复杂系统的成功设计需要在设计概念的选择、各个相互关联的功能间的优先级及子系统间的接口定义进行大量的折中性考虑。每位技术专家或子系统设计者必须在其负责的范围内尽力减少这些折中性因素的影响。然而，系统工程师必须根据其对系统总体性能、设计风险、成本、进度等的影响而对这些问题进行审视，系统工程师是系统和项目的整体性的倡导者。

- 关键词4：研发人才培养的策略、战略分解、业务能力建设、标杆管理 -

“上接战略、中接标杆和下接业务”的人才培养机制从总体来说，“上接战略、中接标杆和下接业务”的人才培养机制需要从战略分解、业务能力建设和参考标杆企业做法三个方面来搭建整体的框架。

企业战略是人才培养规划和各项工作开展的总纲领和源头。反过来说，人才培养说到底是为了支撑并服务于战略目标的实现，必须围绕着核心战略目标进行设计。原则上，是从战略和项目规划分解下来对各类别、各层级的人才需求以及人才现状对比来形成所需解决的人才缺口（结构化缺口），具体从战略项目数量与级别、战略要求的关键领域突破、关键能力建设等逐步分解到对人才结构化需求缺口（这点可以和任职资格等级对应起来）。

标杆企业的标杆做法是企业进行人才培养的一面重要镜子。针对现有业务模式和标杆企业模式的差距，可以进一步将这种差距映射到平台或能力的要求中。例如，需求管理与规划能力、系统设计能力、DFX能力，进而提出对流程、业务建设能力更高的要求和对员工更高级别的能力要求，从而清晰化“下接业务”的人员培养需求。

- 关键词5：知识管理、流程管理 -

知识管理、流程管理是“基于任职资格的人才培养机制”的支撑基础。知识管理、流程管理在一般中小企业的困境是太随意、个体化以及肤浅化，无法形成可以集成的爆破力；流程管理改善未聚焦于“问题引入活动”的控制和对关键业务能力提升的帮助上；知识管理、流程管理在案例、检查清单、规范的“三位一体”架构中未形成生动、形象、有趣的知识数据库，难以吸引也难以激发员工的学习兴趣。其实，企业在发展过程中摸索出来的成功经验或失败教训是一笔宝贵的财富，因此需要对这些经验或教训进行系统化的总结。模板化是企业将良好经验成功复制的有效手段，是知识管理和流程管理的基本手段，通过模板化，可以避免大部分工作重新开始探索，提高工作效率和效果。另外，知识管理、流程管理对人才尤其是高级别人才的要求需要进一步落实到任职资格标准的建设中。

- 关键词6：并行开发模式、异步开发模式、技术与产品开发分离 -

并行开发模式，是通过跨部门团队的方式，整个团队一起策划如何开发和交付有利可图的产品及其它关键的商业问题，以达成公司的商业目标。另外研发以外的功能部门代表能在产品需求和方案阶段就能将可服务性、可制造性、可测试性等需求和相关配套方案加入到产品的早期设计中。

通过向并行开发模式转变，解决了很多串行开发的弊端，大大降低了返工，缩短了产品的开发周期，同时也大大地提升了产品的交付质量。随着技术开发和管理能力的提升，产品平台和组件逐渐成为减少产品开发总体工作量、提升产品多样化与系列化战略的有力武器。通过对产品平台或共用模块的开发和管理实现跨产品的技术封装和共享，为企业进一步缩短产品的上市周期提供了很好的基础，这就是异步开发模式。异步开发模式的重中之重是技术和产品开发相分离，识别产品开发所基于的平台和能够共享的基础模块来达成提高技术共享，用来支持各业务分层的产品和技术进行统一协调的规划和独立开发。

- 关键词7：产品平台 -

一个产品平台是关于产品规划及其战略决策而制定的一个概念。它是整个系列产品所采用的共同要素，特别是基本的决定性技术（核心技术）的集合。——《PACE》中关于产品平台的定义

产品平台是战略性的、对产品起到核心作用的共同要素的集合。产品平台和产品的开发息息相关。从平台化角度出发，任何独立的产品开发只是产品平台或公司产品线的一个分支，是实现公司开发战略的一个要素。而产品平台的作用与影响是根本性的，同时由于产品平台的开发周期较长且需要很好的前瞻性，通常通过技术开发与产品开发相分离的方式，搭建货架化的技术体系（如分为技术、部件、模块、子系统、系统和平台等）。

因此，企业想要成功，必须要有效地掌握产品平台和各产品方案之间关系处理的多项目管理技能。技术和产品开发相分离，确保产品在业务分层中考虑到各层次技术、平台、产品和解决方案等规划，这种考虑需要通过自身的业务模型来驱动，根据技术创新的速度和及时向市场交付具有竞争力的产品的要求来加以均衡。在每个合适的业务层次上进行“恰当”的整合，如外购、合作开发或自主开发。

- 关键词8：异步开发模式的方法、产品平台类型 -

采取异步开发模式，在进入一个新的产品领域之前，就根据关键的市场需求和技术架构选择和规划产品平台，先进行产品平台或平台产品的开发，然后在平台的基础上规划产品线和开发具体的产品。进行技术预研和平台规划需要较长的时间和大量投入，过程中会探索不同的技术和平台，并进行选择。

原则上，应该只选其中一种产品平台和相应的技术。根据细分市场栅格（细分市场栅格是一个矩阵，横轴代表企业产品针对的主要细分市场；纵轴表示企业面向的市场中不同层次的价格和性能，以“低成本、中间范围和高成本”表示），可以将产品平台分成四类：特定利基产品平台、横向产品平台、纵向产品平台和桥头堡产品平台。

- 关键词9：产品平台类型 -

特定利基产品平台：每种产品开发群体和制造厂完全致力于一个非常特定的利基。虽然这种模式有其优势，但成本也非常高。研发可以很容易复制，一个团队的发现对于其他团队来说仍然保持未知。

横向产品平台：优势是公司在一系列相关的客户群体引入多股新产品，而不必为每种客户群体单独投资。研发的主要利益是，新产品可以更快开发。

纵向产品平台：一个原来在高端细分市场的企业将平台往下延伸至更低水平的价格/绩效；另一种通过增加更有力的技术或新的模块，满足了更高水平市场的需求，从而从低端产品平台升级至更高的价格/绩效水平。

桥头堡产品平台：这是一种低成本但有效的平台，工程师提高平台的绩效，增加用来吸引其他细分市场的特征。对初始平台进行扩展，使之吸引不同的细分市场，提供细分市场内部高端客户所需的功能

- 关键词10：研发任职资格体系构建 -

从总体来说，“上接战略、中接标杆和下接业务”的人才培养机制需要从战略分解、业务能力建设和参考标杆企业做法三个方面来搭建整体的框架。原则上，是从战略和项目规划分解下来对各类别、各层级的人才需求以及人才现状对比来形成所需解决的人才缺口（结构化缺口），具体从战略项目数量与级别、战略要求的关键领域突破、关键能力建设等逐步分解到对人才结构化需求缺口（这点可以和任职资格等级对应起来）。标杆企业的标杆做法是企业进行人才培养的一面重要镜子。针对现有业务模式和标杆企业模式的差距，可以进一步将这种差距映射到平台或能力的要求中。

例如，需求管理与规划能力、系统设计能力、DFX能力，进而提出对流程、业务建设能力更高的要求和对员工更高级别的能力要求，从而清晰化“下接业务”的人员培养需求。知识管理、流程管理是“基于任职资格的人才培养机制”的支撑基础。知识管理、流程管理在一般中小企业的困境是太随意、个体化以及肤浅化，无法形成可以集成的爆破力；流程管理改善未聚焦于“问题引入活动”的控制和对关键业务能力提升的帮助上；知识管理、流程管理在案例、检查清单、规范的“三位一体”架构中未形成生动、形象、有趣的知识数据库，难以吸引也难以激发员工的学习兴趣。其实，企业在发展过程中摸出来的成功经验或失败教训是一笔宝贵的财富，因此需要对这些经验或教训进行系统化的总结。模板化是企业将良好经验成功复制的有效手段，是知识管理和流程管理的基本手段，通过模板化，可以避免大部分工作重新开始探索，提高工作效率和效果。另外，知识管理、流程管理对人才尤其是高级别人才的要求需要进一步落实到任职资格标准的建设中。

- 关键词11：研发团队管理模式 -

一般而言，项目团队结构从职能结构发展到“轻度矩阵”，再到“重度矩阵”团队结构，甚至到完全独立运作的团队结构。

1、职能结构的特点：· 职能部门经理处理本部门的所有决策· 当项目或组织变得很大或需要广泛的跨部门运作时，难以协调

2、“轻度矩阵”的特点：· 项目经理是协调人· 项目组成员是职能部门的联络员（没有权力）· 职能部门经理仍然做出本部门的关键决策· 当规模和复杂度增大时，这种结构也难以支持

3、“重度矩阵”的特点：· 项目经理在不同功能中发挥直接的、综合性的影响· 组员完全代表相应的职能部门· 项目经理和成员有项目权力和责任· 职能部门经理关注于建立优秀的部门，而不是日常的决策· 是复杂项目和组织的最好的组织结构。

现在我们要用虚拟的团队来开发、生产产品和提供服务，以虚拟团队来应对挑战已经成为现实的革命。事实上，“随需而变”整合资源能力正在成为企业的支柱，尽管这个能力是全新的，也有可能是短暂的，但企业想要在知识经济时代的社会网络中构筑自己的生态环境，就必须拥有它。不管知识来自何方，团队来自何处，必须快速加以整合、融合，以应对市场瞬息万变的需求。团队围绕着客户需求运转，知识围绕着客户需求才能产生价值。矩阵式管理模式在寻找有效项目管理答案的路上，确实起到了很大的启示作用，不过，在企业实际运作中的结果却很糟糕，项目经理被授予的权利名不符实，反而容易陷入到无休止的跨领域的纠纷之中，在较为强势的功能部门经理的相互推诿下，项目经理往往“孤掌难鸣”。这里有企业本身功能领域建设滞后的原因，也涉及到了对项目经理的定位、项目经理和功能部门经理相互关系等因素。以市场为导向、以项目为导向，就要给予项目经理足够的权利和要求，从企业运作规则上明确功能领域对项目运作、项目经理的支撑要求。例如，某企业对项目经理就赋予了足够的授权——在对项目成员的绩效管理中，项目经理有“一票否决”的权利，从而保证“重度矩阵”团队运作模式的成功建立。

- 关键词12：研发目标的平衡 -

如何在需求、质量和进度以及成本之间达到一个合理的均衡？在达到控制研发产出变异的过程中，有哪些措施可以协助我们在诸多约束条件下取得一个“最优解”？不同的企业采取的方法不同：有的倾向于要求员工加班加点来保证完成，但这毕竟不是长久之计，员工成就感低，容易疲劳，离职率高；有的喜欢砍掉一部分需求或降低质量，匆忙上市，但这如果把握不当的话，会造成客户不满和在维保阶段的成本剧增；有的倾向于放松过程控制，托付给“高手”，但问题是高手是“稀缺资源”，“不能以一己之力承担重托”……如果从项目管理的角度出发，通过分析企业可以采取不同的措施和手段对项目整体产生影响.

我们发现，流程裁减、砍掉部分需求、降低质量要求、增加人手、加班等手段要么对质量、成本，要么对时间产生一定的不良影响，而对技术评审和共用模块重用却不会产生不良影响。从整体上看，技术评审和共用模块重用从项目质量、成本和时间都可以生产良性的正作用。

- 关键词13：研发标准化 -

标准化的形态主要有三种：设计标准化、过程标准化和工程方法标准化。下面简单介绍它们的相关定义：标准化的三种形态·

设计标准化：主要指使用面广、通用性强、作用时间较长、与产品的特性关系较小，并且已被公司广泛接受的技术，它往往是公司产品平台、模块化的重要组成部分。

· 过程标准化是指相互关联的工作形成一定的管理框架结构，并要有一定的组织原则来支持，对于每项工作都应清清楚楚地明确规定，与产品开发有关的人应该清楚工作内容、工作方法以及输出内容，同时能够配套度量指标以进一步衡量和优化过程。

· 工程方法标准化可以提高专业设计人员的生产力和高效工作，它是技术团队、工程团队的技能与能力的标准化，是设计手段、工程优化的工具。每种工程方法，如果能够加以适当运用，将对产品开发过程起到很大的改进作用。

- 关键词14：检查清单 -

检查清单是设计标准化的一种非常重要的途径。对检查清单不断优化，是不断固化经验教训、避免同样错误的过程。在产品开发过程中，往往出现一种场景：在某产品某事故总结会议上，有人指出“之前好像在另一个产品中也发生过这样的问题”。交了学费，而没有学到东西，这是多么令人遗憾。如果不能形成检查清单就不能够进行设计标准化，同时，公司对经验的学习也是零散的、艰难的、迷失的。检查清单的使用是通过嵌入相关流程的方式来实现的。在需求阶段，市场工程师、系统组和设计工程师等通力合作，对需求的各个方面，以需求检查简单为指导，直到得出明确的、达成共识的需求。在设计阶段，随着设计从总体、模块到详细设计的展开，都有各自配套的检查清单。在验证、试制阶段，检查清单用来把握前段环节输入的准确性、验证和试制输出的有效性。

- 关键词15：研发流程结构化 -

流程结构化可以达到共用流程共享和业务增值的效果。结构化流程能够让团队和角色了解自身在什么时候应该做什么活动，并且也清楚彼此的需求以及何时需要对方的投入，释放了员工的创造力。同时，结构化可以凸显更有价值的活动，团队成员尤其是高级人员应该重点聚焦、投入更多的时间在此类活动中。在企业管理层面，可以将员工的能力和流程活动类别对应起来（一般而言，高级人员从事创造性大、难度大和风险高的活动，而基层员工执行相对简单的基础活动），这样更容易达到“让合适的人做合适的事情”的目标。结构化开发流程自上而下总共有4个层次：阶段、步骤、任务和活动。一般有3～6个阶段，每个阶段里有多个步骤，每个步骤里有多重任务，每个任务里又有多重活动。结构化的最高层次是阶段。阶段的终点是开发过程的里程碑，在某些阶段的关键节点上，需要对是否进入下一环节做出决策。每个阶段都由一些具体的步骤组成。在结构化开发中，步骤是最重要的。步骤为开发活动计划的制订和监控提供基础。大部分公司的开发过程中有15～20个步骤。虽然某些项目或许不包括所有步骤，但是步骤一直应用于所有项目。例如，软件开发步骤虽然在所有项目中是一样的，但是，没有软件开发部分的项目就会省去这个步骤。步骤由多个任务组成。一般来说，每个步骤有12～35个任务。一般说来，如果没有非常合理的理由要做出改变，任务在各种项目中是一致的。人们用任务来计算标准周期时间及定义要做的工作。完成任务是负责具体步骤的核心小组成员的职责。任务又可分成一定数量的活动。每项任务的活动数额从几个到上百个不等。它们是每个项目小组成员每天都在做的事情。与任务不同，活动常常因项目的不同而有所变化，因为各个项目的实际工作划分可能是不同的。这4个层次综合起来形成了一个决策、项目进度制订、资源规划、过程衡量以及持续改进的基础。