原创六西格玛精益制造IPD敏捷开发为什么不适用于“互联网+产品”研发？（长文）

Posted 2021-04-25 艾老思

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了原创六西格玛精益制造IPD敏捷开发为什么不适用于“互联网+产品”研发？（长文）相关的知识，希望对你有一定的参考价值。

六西格玛、精益制造、IPD、敏捷开发等先进方法帮助过很多企业提升产品研发速度、企业管理水平。然而时过境迁，到了互联网+时代，当传统企业想要研发互联网+产品的时候，发现以上先进方法似乎都不再奏效，甚至会阻碍新产品的研发。是这些方法真的失效了，还是我们用错了地方？让我们一起回顾一下这些方法，再作评判。

我将从产生时间、来源企业、产生原因、核心目标、方法论、局限性等六个方面对四种方法来进行剖析。

六西格玛

产生时间

1986年

来源企业

摩托罗拉

产生原因

在20世纪80年代和90年代早期，摩托罗拉与许多美国和欧洲企业一样，其“午餐及其他膳食和点心”都在遭受日本竞争对手的蚕食。当时，摩托罗拉的高层领导们承认其产品质量低劣。

摩托罗拉通信部门的乔治•费希尔（George Fisher）提出了一个新的质量项目，称为“六西格玛”。而后在董事长鲍勃•高尔文（Bob Galvin）的大力支持下，六西格玛在全公司进行了推广。六西格玛使摩托罗拉有力地推动了在当时看来几乎是不可能的改进目标：初始目标是在20世纪90年代的初期用5年时间实现10倍的改进，而后每两年实现10倍改进，即在4年里改进100倍。

从六西格玛开始的1987-1997年的10年时间里，取得了如下成就：销售额增长5倍，利润每年攀升将近20%。由六西格玛努力产生的累计节约额达140亿美元。摩托罗拉的股价平均每年上涨21.3%。

核心目标

通过减少缺陷和差错，提高客户满意度，增加利润的管理方法。

方法论

六西格玛方法体系分为DMAIC和DFSS两种。DMAIC通常被用于对企业现有流程的梳理和改善。而DFSS则主要用于企业新产品和服务流程的设计，以及旧流程的再造等工作。

DMAIC

DMAIC是指定义（Define）、测量（Measure）、分析（Analyze）、改进（Improve）、控制（Control）五个阶段构成的过程改进方法，一般用于对现有流程的改进，包括制造过程、服务过程以及工作过程等等。

定义（Define）

界定核心流程和关键顾客，站在顾客的立场，找出对他们来说最重要的事项，也就是「品质关键要素」（Critical to Quality，CTQ）。理清团队章程，以及核心事业流程。

测量（Measure）

找出关键评量，为流程中的瑕疪，建立衡量基本步骤。人员必须接受基础概率与统计学的训练及学习统计分析软件与测量分析课程。为了不造成员工的沉重负担，一般让具备六西格玛实际推行经验的人带着新手一同接受训练，帮助新手克服困难。对于复杂的演算问题，可借助自动计算工具，减少复杂计算所需的时间

分析（Analyze）

探究误差发生的根本原因。运用统计分析，检测影响结果的潜在变量，找出瑕疪发生的最重要根源。所运用的工具包含各类统计分析工具等。

改善（Improve）

找出提升关键指标和质量特性的最佳解决方案，然后拟定行动计划，确实执行。这个步骤需不断测试，以观察改善方案是否真能发挥效用，减少错误。

控制（Control）

确保所做的改善能够持续下去。不断测量，才能避免错误再度发生。在过去许多流程改善方案里，往往忽略了控制的观念；而在六西格玛改进中，控制是它能长期改善品质与成本的关键.

DFSS

六西格玛设计DFSS（Design For Six Sigma）系统方法的核心是，在产品的早期开发阶段应用完善的统计工具，从而以大量数据证明预测设计的可实现性和优越性。在产品的早期开发阶段就预测产品或服务在客户处的绩效表现是实现更高客户满意度、更高利润和更大市场占有率的关键。

【原创】六西格玛、精益制造、IPD、敏捷开发为什么不适用于“互联网+产品”研发？（长文）

六西格玛设计的步骤

定义（Define）

通过项目团队章程，创建项目计划，确定顾客需求，并根据顾客需求说明产品要求和目标，同时明确整个项目开展中所需的资源和受限条件。

测量（Measure）

确认采用何种方法获知顾客的需求，并将它们列入“顾客的声音（VOC）”清单中，将顾客的声音转化为实际的要求，确认关键质量特性（CTQ）的衡量方法。

分析（Analyze）

利用创造性的方法确定可行的概念，使用符合逻辑的、客观的方法来评估可选的方案，确认并消除产品或服务失效的潜在可能。

设计（Design）

落实具体的产品研制规划，尽量减少产品或流程的差异性（稳健性优化），调整输出信息，使其达到可测量的指标。

验证（Verify）

验证生产过程的能力，进行试生产，建立、测试并固化原型。

局限性

1. 业务必须是基于确定性的客户需求的

六西格玛的核心逻辑是通过defect reduction（减少缺陷），从而yield improvement（提高产量）、improved customer satisfaction（提高客户满意度）、higher net income（较高的净利润）。

这么做之所以有效，是基于一个假设前提的——质量是业务成败的唯一核心要素。只要质量提升了，就能带来客户满意度提升。

能够设定这个前提的前提是——确定性客户需求，因为只有产品方向是确认无误的时候，竭力提升质量才有意义，否则是在错误的方向使无用功。

然而，这一前提在“互联网+产品”上几乎不成立。因为互联网+的跨界结合产生了无限可能性，客户的需求也会因此而变动复杂多样。想要让客户在早期就确定需求，并且在整个质量改进过程中都不发生改变，将会越来越难。

2. 主要适用于大型制造业企业

采用六西格玛的企业有：摩托罗拉、德州仪器、霍尼韦尔、通用电气、ABB、柯达、西门子、诺基亚、索尼、东芝、三星、LG、戴尔、惠普、宝钢、徐工集团、海尔、中国航天集团、中铁等。

他们有两个共同特征——“大型企业”和“制造业”。

为什么只适合于“大型企业”？因为实施六西格玛需要花费很高的成本，这包括研究改进成本、人员培训成本、实施过程对现行工作的影响等。任何变革对一个企业来说都是一次伤筋动骨的改变，对管理、文化、架构、人员、流程、业务、协作等各个方面都会产生巨大的冲击，改变的成本极高。这对中小企业来说是承受不起的。只有大型企业，这种变革成本相比其庞大的业务量才是可以接受的。

为什么是“制造业”？制造业最擅长的是基于客户明确需求（订单）大批量的生产同一种产品，从而大幅度的降低单件产品的生产成本。所以它天然具备了我刚刚说的前提条件“确定性客户需求”。除去原材料成本，生产过程中的主要开销来源于管理成本、人工成本、缺陷成本、资金成本等。六西格玛就着眼于缺陷成本。

互联网+产品大多数不是基础制造，而是在制造基础上增加智能、定制化、甚至资源衍生业务，或者干脆就是服务业。对于这类业务的用户来说，相比缺陷更加重要的是体验，好的体验甚至可以让用户包容你的缺陷，因此缺陷成本变得没有那么关键。这块成本投入应该转移到产品设计、运营服务等新的方面。

虽然也有一些服务业企业和政府机构尝试使用六西格玛，例如花旗银行、亚马逊，试图提升服务性业务流程的管理方法。但毕竟是凤毛麟角。即便使用，也仅限于一些确定性业务领域。因为对于服务业，客户的需求是多样的甚至是定制的，或者缺陷成本并不是主要成本因素，改进质量的投入产出比不高。

精益生产

产生时间

1990年（《改变世界的机器》第一次将丰田生产方式定义为“精益生产”）

来源企业

丰田

产生原因

20世纪初，从美国福特汽车公司创立第一条汽车生产流水线以来，大规模的生产流水线一直是现代工业生产的主要特征。大规模生产方式是以标准化、大批量生产来降低生产成本，提高生产效率的。这种方式适应了美国当时的国情，汽车生产流水线的产生，一举把汽车从少数富翁的奢侈品变成了大众化的交通工具，美国汽车工业也由此迅速成长为美国的一大支柱产业，并带动和促进了包括钢铁、玻璃、橡胶、机电以至交通服务业等在内的一大批产业的发展。大规模流水生产在生产技术以及生产管理史上具有极为重要的意义。但是第二次世界大战以后，社会进入了一个市场需求向多样化发展的新阶段，相应地要求工业生产向多品种、小批量的方向发展，单品种、大批量的流水生产方式的弱点就日渐明显了。为了顺应这样的时代要求，由日本丰田汽车公司首创的精益生产，作为多品种、小批量混合生产条件下的高质量、低消耗进行生产的方式在实践中摸索、创造出来了。

核心目标

消除一切无效劳动和浪费，把目标确定在尽善尽美上，通过不断地降低成本、提高质量、增强生产灵活性、实现无废品和零库存等手段确保企业在市场竞争中的优势。

方法论

精益生产方式基于这样的假设：时间的浪费是由不得不修复次品导致的，而资源的浪费则是由保留非必需的巨大存货引起的。精益生产的精华在于：其一，只生产所需的东西，适时生产而不是生产大量产品以备不测；其二，每个人都是

质量检查员，有责任随时纠正错误；其三，按照从供应商到客户的价值流向，把产品和生产过程联系起来，强调由需求拉动生产，也就是按单制造。

精益生产的基本理念可概括为以下几点： ⑴“利润源泉”理念；⑵“暴露问题”理念；⑶“遵守标准”理念；⑷“以现场为主”理念；⑸“持续改善”理念；⑹“人本化”理念；⑺“团队”理念；⑻“职能化”理念。

其核心理念是追求消灭包括库存在内的一切“浪费”，并围绕此目标发展出一系列具体方法，逐步形成适于企业特色的生产经营管理体系。

“精益生产方式”的基本构成有：“准时生产（JIT）”、“小批生产”、“自动化”、“全面质量控制（TQC）”和“现场改善”。其中，“准时生产（JIT）”和“自动化”是“精益生产方式”的主要构成，也是“精益生产方式”的基本原理和思想。即通过“JIT”实现生产的“准时化”，通过“自动化”确保质量方面的要求。构成“精益生产方式”主流的JIT生产的4个核心要素是：⑴看板系统；⑵生产均衡化；⑶小批生产；⑷设备布臵和多能工制度。为了实现JIT生产，“精益生产方式”把过剩生产的浪费、等待的浪费、运输的浪费、加工过程中的浪费、库存的浪费、动作的浪费、因发生不良造成的浪费等作为持续改进的对象。而“精益生产方式”中的“自动化”，除了代表“自动作业”功能外，更多地是指“自动停止”功能，特别是代表发生不良事件时能“自动停止”的自律机制。精益生产的“自动停止”尤其强调人的作为因素，例如丰田公司采用的“停线（LineStop）”制度，就要求在生产过程中，即使发生小故障，员工也有权停止整条生产线的运转进行排障（大野耐一首创）。 JIT生产和“自动化”机制之间是相辅相成的。JIT生产和看板系统的运转机制，促使质量控制活动不断深化，并进一步提高了“自动化”机制的效能。JIT生产和“自动化”机制之间的相互制约又相互促进，推动着企业生产过程的现场改善，保障了企业生产活动的最佳状态。在必要的时间、按照必要的数量、生产必要产品的“精益生产方式”，是对传统的“成批操作是最好的方法”的否定。其思维方式起源于“顾客根据所选商品的数量和时间来支付金额”的商业超市模式。即“精益生产方式”是将商业超市的运作模式应用于生产环节，将生产过程所需的零部件，在必要的时间，按必要的数量提供给必要的生产现场或工序，追求“准时生产（JIT）”的一种生产现场管理技术。

局限性

1. 以产品确定性为前提，牺牲了“可逆性”

精益生产和六西格玛一样，在竭尽全力追求完美。追求完美是没错的，但是追求完美所需付出代价的就是牺牲“可逆性”。

精益生产过程在启动生产之前要对产品目标百分百确认，也就是“绝对确定性”。否则后续精益求精的过程所生产出来的就有可能不是客户所要产品，那么这一切在追求完美上的花费就没了意义。

于是要求对产品目标、生产流程、岗位技能、物料准备等环节都要做到绝对确定。如果一旦出现问题就需要停线处理（LineStop）。

这意味着生产一种产品的整个过程非常刚性，中途修改是不可容忍的，不可试错，不可逆。

于是要求前期的准备必然需要花费大量的时间做充分的论证，投产前成本便占到了很大比例。如果一但中途取消，或者论证失败，前期花费的巨大成本便付诸东流。因此整个过程是牺牲了“容错性”换取确定性。

牺牲“不可逆性”，也与前者有关，当过程绝对刚性的情况下，中途修改是不可能的，因此这种情况下是不可以试错的。也就“不可逆”。

然而这些都很好的满足的了在确定性目标下的生产过程，而不能加入研发过程。

对于“互联网+产品”可逆性是其研发的基础保障，面对不确定目标、不确定过程，只有不断迭代试错才有可能接近正确。放弃、修改、重做将会是“互联网+产品”常见工作，要做的就是要将这一系列“逆操作”的成本降到最低，而不是拒绝。

2. 研发与生产必须绝对分隔，牺牲了“容错性”

精益生产既然叫生产，那么它就是限定于生产领域的，产品研发被至于之外。然而研发过程是不可被忽略的，从下图可以看出，对于一款汽车而言，研发时间是生产时间的50倍上下。

对于研发而言，企业可以采取自己熟悉的产品研发方式。如果你钟情于精益生产，还可以学习“精益产品开发”，这一理念来自于2006出版的《丰田产品开发体系》（中文版2008出版）。书中讲述丰田如何将精益生产的理念延伸到产品研发领域，并形成了方法论。但因出版较晚，且不易掌握，所以并没有流行起来。详见下图。

精益生产的假设前提是“产品研发已经完成，且产品已经得到客户或市场的确认，可以进行批量生产。”因此，它是不接受产品在生产过程中的调整的。通过牺牲“容错性”换取了“高品质、低成本、短交期”。因此它对于存在大量不确定性的“互联网+产品”研发是不友好的。

《失控》书中曾讲到：“在计算机的大规模应用之前，科学包含两个方面：理论和实验。一个理论会构造出一个实验，同样实验则会证实或证伪这种理论。但是，在计算机那里却诞生出了第三种进行科学工作的方式：仿真。一次仿真，同时就会既是理论也是实验。”

产品研发领域也出现了完全相同变化。因为互联网和软件的加入，让以前研发和生产不再独立存在。软件使得“研发”和“生产”合二为一，研发的同时即在生产。这点归功于计算机软件的“可复制”属性，研发出的产品可以近乎零成本的复制出无数份可供大量企业的使用。不仅如此，通过互联网实现的云计算，又使复制也被取消。软件即服务SASS（Software-as-a-Service）的理念就是让产品像水和电一样，在你需要的时候随时使用，而不需要在自己复制一座水厂或电厂。

“互联网+产品”就会面临这一境况。“互联网+产品”虽然是在原有传统业务上加上互联网属性，但是随着时间的推移，企业一定会选择用软件替代硬件，至少是大部分功能。因为这样做所带来的成本下降、灵活性提升、便于试错的特性非常适合于去满足不确定性的市场和用户需求。如果企业已经习惯于精益生产，当面临“互联网+产品”研发的时候，必然短期内难以适应。

IPD集成产品开发

产生时间

1992年

实践公司

IBM

产生原因

1992年IBM在激烈的市场竞争下，遭遇到了严重的财政困难，公司销售收入停止增长，利润急剧下降。经过分析，IBM发现他们在研发费用、研发损失费用和产品上市时间等几个方面远远落后于业界最佳。为了重新获得市场竞争优势，IBM提出了将产品上市时间压缩一半，在不影响产品开发结果的情况下，将研发费用减少一半的目标。为了达到这个目标，IBM公司率先应用了集成产品开发（IPD）的方法，在综合了许多业界最佳实践要素的框架指导下，从流程重整和产品重整两个方面来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为顾客和股东提供更大价值的目标。

IBM公司实施IPD的效果不管在财务指标还是质量指标上得到验证，最显著的改进在于：

1、产品研发周期显著缩短；

2、产品成本降低；

3、研发费用占总收入的比率降低，人均产出率大幅提高；

4、产品质量普遍提高；

5、花费在中途废止项目上的费用明显减少；

核心目标

以市场需求作为产品开发的驱动力，将产品开发作为一项投资来管理。

美国空军的研究机构把集成产品开发定义为“一种系统地运用多学科小组来集成和并行地实施所有必要的过程来生产满足顾客需求的有效产品的理念”。从该定义可以看出，IPD的“集成”是所有与产品开发有关的过程的集成，通过多学科小组来实现；同时产品要能满足顾客需求。

德国学者S. Vajna（1998）在综合IPD的研究文献的基础上给出IPD的一种定义：“IPD是在合适的时机、以合适的价格性能比开发有竞争力的高质量的产品或服务的以人为中心的工作方式。它描述了在最少和持续地利用生产要素及资源情况下，应用整体的和多学科的方法、过程和组织形式以及人工的或计算机支持的工具。”这种定义也包括了对产品的要求和跨学科的方法，同时强调对资源的有效利用和组织形式以及支持工具。

美国卡内基•梅隆大学软件工程研究所对IPD作的标准定义为：IPD是一种面向客户需求，将贯穿产品生命周期的活动进行及时协同的产品开发的系统方法。

从IPD的组成来看，IPD的基本思想是将从新思想、新概念的形成到产品商业化及产品生命周期完成的整个产品开发过程划分为若干结构化的阶段，并由来自各部门的人员组成的跨部门产品开发团队负责产品开发全过程。IPD关注市场与客户需求，在相关工具的支持下，使公司的研发活动通过分析客户需求、优化投资组合和合理使用资源，保证产品开发过程的顺利进行；通过建设使用共用基础模块，采用并行开发模式缩短开发时间，降低综合成本；通过建立跨部门的产品管理团队与开发团队，并辅以有效的考评体系来保证整个产品开发有效地进行。IPD是一种领先的、成熟的产品开发的管理思想和管理模式，同时也是一套产品开发管理的系统解决方案。

在产品设计中就构建产品质量、成本、可制造性和可服务性等方面的优势。尤其重要的是它将产品开发作为一项投资来管理。在产品开发的每一个重要阶段，都从商业的角度而不只是从技术的角度进行评估，以确保产品投资回报的实现和尽可能减少投资失败所造成的损失。

在阅读了大量相关资料之后，我并没有找到一句简单的话来代表IPD核心目标。这可能就是IPD的一个特点，它更像一个通用的产品开发模式，而不是一个从问题出发的方法论。

方法论

- 把新产品开发作为一项投资决策，并通过预算来管理项目

对高技术企业来说，新产品开发不但是投资决策，而且是最重要的投资决策,因为不仅要考虑投入的资金，还要考虑市场机会和企业发展的机遇。对于任何一家企业，资源总是有限的，选择A项目往往意味着不能选择B项目和C项目，正确的选择给企业带来利润；选择失误，造成的不仅是资源浪费，更可怕的是失去市场机会和企业发展的机会。

而IPD强调要对产品开发进行有效的投资组合分析；对新产品开发进行分阶段投资，并在开发过程中设置检查点，加强阶段决策，通过阶段性评审来决定项目是继续、暂停、终止还是改变方向，从而达到减少投资失误和使失误损失降至最低的目的。

- 基于市场进行新产品开发

不管企业采用什么样的策略，新产品开发的目的无非是为了企业赢利（包括未来能赢利），所以新产品开发只能面向当前或能预见到的未来的市场需求。IPD以市场驱动为导向，强调产品创新一定是基于市场需求和竞争分析的创新。因此，IPD把正确定义产品概念与市场需求作为流程的第一步，着眼于一开始就把事情做正确，并且在产品的整个生命周期都从客户的要求出发制订有关计划。

- 跨部门、跨系统的协同

在传统的产品开发模式中，企业内部的市场、研发、财务和制造等部门都是按学科功能划分的，彼此相对独立，各部门之间存在明确的界面，如研发－市场界面、研发－制造界面、市场－制造界面等。

由于缺乏有效的界面管理模式，企业内部各职能部门之间的界面成为彼此沟通与合作的障碍，导致部门间缺乏交互作用、缺乏沟通和缺乏对对方的积极评价，甚至造成相互不信任。同时，传统的部门界面分割的开发模式可能造成产品开发早期存在的问题直到下游的相应功能部门才暴露出来,由此导致设计反复修改和返工，造成资源的巨大浪费。

IPD通过建立跨职能部门的团队,为部门间界面管理提供了一种有效的解决方案。跨部门团队消除了部门界面隔阂，使产品开发团队成为各部门沟通和共享信息的桥梁。在IPD模式下，开发团队从一开始就综合考虑产品生命周期中的成本、开发、可测试性和可维护性等各种因素,从而能在最大限度上避免上述弊病的产生。

IPD在项目初期即由不同功能部门共同参与，组成跨部门团队。在IPD中有两类跨部门团队，一个是集成产品管理团队（Integrated Product Management Team，IPMT），属于高层管理决策层，其工作流程是市场管理流程；另一个是产品开发团队（Product Development Team，PDT），属于项目执行层，对IPMT负责，其工作采用结构化开发流程。IPD通过跨部门团队有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。

- 大量采用异步开发模式，也称并行工程

采用异步开发模式（并行工程）就是通过严密的计划、准确的接口设计，把原来的许多后续活动提前进行，这样可以缩短产品上市时间（TTM）。并行工程不仅仅是产品设计活动的并行展开，也包括其它相关部门的活动。

- 重用性

采用公用构建模块（Common Building Block，CBB；又称共用基础模块）提高产品开发的效率。CBB是实现异步开发的基础和手段。当产品是基于许多成熟的共享的CBB和技术搭建或集成而成，产品的质量、进度和成本会得到更好的控制和保证。

- 结构化与非结构化之间的合理平衡

产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡。产品开发是复杂的，因为产品开发人员必须完成成千上万项活动，而这些活动涉及到方方面面、各个部门，如何协调这些活动便成为极其复杂的工作。为了能管理好这些庞大而复杂的活动，产品开发过程必须成为结构合理、定义清晰的过程。但产品开发流程不同于生产流程，具有相对的不确定性。理想的生产过程是拷贝，强调全程固化的流程以保证产品的一致性。而产品开发是有限度的创新，因此 IPD流程是有限度的结构化，不同于生产流程。

局限性

1. 以市场可被预测为前提

IPD中有一个核心概念MM：Market Management（市场管理），它是一套系统的方法，用于对广泛的机会进行选择收缩，制定出一套以市场为中心的、能够带来最佳业务成果的战略与计划。

市场管理的使命：提供一个基于充分了解市场状况和客户需求的集成的市场营销方法，使公司更好地实现收入和利润目标，同时提高客户的满意度和忠诚度。

这意味着，对于一个企业市场管理是产品研发的起点，而这个起点必须是经过充分研究和论证的，这样才可以尽可能在早期降低投资的风险。

为了达到这个目的，MM被设计为六个步骤：

STEP1：理解市场

STEP2：进行市场细分

STEP3：进行组合分析

STEP4：制定业务战略和计划

STEP5：融合并优化各产品线的业务计划

STEP6：管理业务计划并评估表现

这是很严谨的做法，但是同时也意味着这个过程的巨大投入和对结果的高度依赖。

巨大投入导致，不会经常进行一轮完整的市场管理流程，通常只会在企业早期阶段或者转型阶段才会进行。这样会产生对市场变化的“滞后反映”，即在发现市场已经变化了之后在进行彻底的市场分析，再加之整个流程耗时过长，很可能会丧失市场时机。以至于后续的产品研发和生产都会大大晚于市场需求。这就给大量的小企业、创业企业留下来时间窗，甚至有可能借机反超。

对结果的高度依赖，体现在企业内所有人都会对花费了巨大投入并经过严谨流程把控得出的市场分析结果深信不疑，并且在之后的工作中对之前的结论不断加强确信，并用各种证据来佐证它的正确性。

这就是著名的“晕轮效应”。人们会对自己之前做出的判断，在后续的行为中不断对其确认和加强，而且这种心理还会在组织内传播和蔓延。曾经在一家企业里听到很多人都提到一个很生动的故事，讲的是“我们的产品让一个不爱学习的孩子开始喜欢学习”。这其实是来自一个销售人员的一个经历，但是这个故事因为太激励人心了，企业内所有人都会深信不疑，然后告诉给身边的人，于是这便成为这个产品的绝对标签。然而真的是这样吗？所有产品用户都是这样的看法吗？肯定不是，那只是一个个案，但当被无数次提及时，就变成了所有。

市场管理流程产出的结果也是一样。难道之前的分析过程就100%正确吗？就没有漏洞吗？既然是预测，本身就是不准确的。但如果你将它看做是后续工作的依据，那么之前的一点点误差，就会在后续执行过程中无限放大。

当然对大型投资，必然需要经历前期严谨的论证。但市场必须是可被论证的。在工业时代企业所经营的主要是社会基础产品，市场是确定的，可被预测的。然而在互联网+时代，需求变化、市场变化、竞争变化、政治变化都异常迅猛，叠加在一起的变化只能用“极速”来形容，于是这样的市场管理流程就会在一些情况下失效或者不适用。

2. 适合于大型复杂产品研发

IPD拥有完整的管理架构与流程体系，非常全面系统的支持起产品全生命周期的研发。

仅看IPD的整体架构图就能看出它的复杂程度。这从一个侧面说明它的适用性。小产品、小项目、小企业是不可能采用这种流程的。可以说IPD天生就是为大组织设计的，所以特别适用于唐山轨道客车有限责任公司（简称唐车）来研发动车组、城轨车等大型复杂产品。

3. 高度依赖高层决策

IPD中有一个重要的团队构成IPMT（Integrated Portfolio Management Team）集成组合管理团队。IPMT类似于一个投资银行家，而产品开发团队（PDT）则类似于被投资的公司。IPMT的投资活动包括：

（1）根据新产品的投资优先级管理，使投资组合合理化。

（2）对新产品开发是分阶段进行投资，在每个阶段设有决策评审点，只有通过了决策评审，IPMT才会进行下一阶段的投资，这样就可以提前发现新产品开发的问题，避免投资的浪费。

（3）在决策评审点IPMT更多的是考虑产品的投资回报率，评审的对象是新产品的业务计划，而不是产品开发计划，产品经理（PDT leader）要对产品的市场成功和财务成功负责，而不仅仅对产品的研发成果负责。

IPMT是一个高层跨部门团队，成员包括各个部门最高主管。对各产品线运作进行指导和监控，并推动各产品线、研发、市场、销售、事业部、服务和供应链等部门全流程的协作。

因此，IPMT是公司的大脑，产品的关键环节都由大脑决策。这是对大脑智慧的充分信任，也是高度依赖。这会带来两个问题。

一是高层必须能够深刻理解市场。这就要求他们对市场的变化保持高度关注。这本无可厚非，但当组织变大，高层在管理方面的精力必然会被分走很多，有些甚至会占到其80%的工作投入，再要想保持对市场的时时关注便是非常困难。另一方面，市场变化极快，高层逐渐年长，思维保守和固化会越发突显，这也带来对决策结果的不良影响。

二是对基层决策力的抑制。在高度依赖高层的状况下，事事汇报，等待批复变成基层工作的习惯性思维。长此以往，他们便放弃了决策，只是执行。一旦高层决策失误，他们也没有能力帮助高层规避和纠正。特别是创新方面，企业不可能长期依赖高层的创新想法，既有限又不长久。基层决策力被抑制的同时创新能力也被抑制，于是就会出现，曾经辉煌的企业在产品青黄不接的时候，老板想破头，员工没想法的窘境。

敏捷开发(Agile Development)

产生时间

2001

来源企业

敏捷宣言（2001年2月由17位当时称之为“轻量级方法学家”所编写签署的）

产生原因

传统开发方法是基于客户能够在需求阶段就给出完整、准确的需求的假设，所以期望于在项目初期获得详细的需求，然后严格控制需求变更，最终完成符合需求的软件。

但我们发现实际上往往需求是“涌现”出来的，也就是说是随着开发的不断进展而不断发现出来的，而无法在项目初期就明确的定义它，也就是说传统开发方法的基本假设是错误的，这一新的假设导致了敏捷方法的一系列实践。

另外，传统的软件开发方法认为需求是可以确定，所以采用的是基于工程的开发方法，也就是说期望通过事先的详细策划定义开发的整个过程，而敏捷认为需求是无法在早期完全确定的，所以采用的是基于经验的开发方法，也就是说事先不详细定义整个开发过程，而通过多次迭代来逼近最终目标

核心目标

以人为本、价值驱动、减少浪费、拥抱变化、

方法论

基于敏捷宣言的核心思想，敏捷开发产生了多种不同的方法流派，其中应用较广有两种。

 Scrum

Scrum包括一系列实践和预定义角色，是一种灵活的软件管理过程。它提供了一种经验方法，可以帮助你驾驭迭代，实现递增的软件开发过程。这一过程是迅速、有适应性、自组织的，它发现了软件工程的社会意义，使得团队成员能够独立地集中在创造性的协作环境下工作。

 极限编程（XP）

极限编程是由Kent Beck提出的一套针对业务需求和软件开发实践的规则，它的作用在于将二者力量集中在共同的目标上，高效并稳妥地推进开发。其力图在不断变化的客户需求的前提下，以持续的步调，提供高响应性的软件开发过程及高质量的软件产品。

虽然Scrum偏向管理实践，XP偏向技术实践，但万变不离其中，他们都遵循着以下几个核心方法。

1）迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2）增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3）开发团队和客户反馈推动产品开发。敏捷开发方法主张客户能够全程参与到整个开发过程中。这使需求变化和客户反馈能被动态管理并及时集成到产品中。同时，团队对于客户的需求也能及时提供反馈意见。

4）持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成，有些项目则每天都在这么做。

5）开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

局限性

1. 对人要求很高，难于掌握

敏捷开发与IPD一样都是在解决产品研发的问题。只不过敏捷开发是从软件领域开始的，所以在软件研发上应用较多，而后引入到部分可编程硬件领域。它与之前的三种方法最大的不同是，它从以“流程”为核心转变成以“人”为核心。这是研发方法从工业领域转向到高科技领域的一个重要标准。前者是以机器为核心的，把人当做资源看待，努力将人的工作标准化可替代，因此需要靠精心设计的流程保证其高速运转。后者是以智力为核心的，把人当做不可替代的核心创造者看待，让工具为人服务，提升其创造力。因此大幅度弱化了流程，承认了人的不确定性，即承认人会犯错，客户会犯错，开发者会犯错。从靠流程、制度、评审来规避犯错转变成为接受错误，尽早发现尽早修正。同时承认高智商高经验人的产出是低者的上百倍，因此要为其营造高产的环境，即宽松的环境。这些都是与传统方法相反的思维方式。

在它带来好处的同时，也带来了问题。敏捷开发方法因为缺乏严格的操作方法，过度灵活，难于掌握。这就对采用敏捷开发的企业员工提出了更高的要求。他们需要深刻理解其背后的逻辑才能够让方法发挥正向效用，否则会导致更低的效率，甚至混乱的状态。这也是历时十多年，敏捷被谈多做少的原因。

不仅如此，敏捷开发本身对每个人的技能要求也极高，例如对开发人员，要求能够具备对架构持续重构，保持简单，这都是需要很高的技术修养才能做到的。同时要求团队要能够做到“自组织”，即“团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估，并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。”这是非常理想的状态，几乎没有企业能够做到一点。然而这却是很多敏捷方法的基础，这便造成敏捷开发落地的很多难题。

2. 以项目交付为主命题

敏捷开发产生是源于企业软件交付的诸多难题，比如变更、缓慢、高成本等。这类交付大多以项目形式组织、以产品为结果。

项目有两个核心特征“为客户服务”、“一次性”。

项目的发起是从客户需求出发的，这隐含了客户必定是存在的，而且是明确的，通常客户是一个人或一个公司的需求提出人。通常是一对一服务的。他们的需求一般也是明确的，至少方向是明确的。

但这并不是用于产品研发。产品通常是自主研发的，它是有企业对市场的分析，洞察出一个普遍性需求，进而研发出产品，然后寻找购买者进行销售。通常是一对多服务的。因为面对大量用户，他们会存在各种各样的个性化需求，因此便不能想做项目一样有明确的需求，这就需要主创者对产品方向进行判断和把控。

所以敏捷开发中“客户合作”、“客户现场”等都是对客户重要性的确认，一旦客户不存在，例如自主产品研发早期还没有用户的时候，需求的挖掘、产品的验收就都成了问题。

项目一般是为一个确定目标所完成的一次性活动，所以项目是以客户验收为结束标志的。然而产品因为存在大量用户，它是持续交付的过程，再加上产品的更新换代，还需要对老用户进行升级。

敏捷开发中强调“客户验收”的重要性，要求与客户频繁验收，从而尽早发现问题，尽早调整，减少返工浪费，同时收敛项目范围。但这并不是用于产品，因为产品的功能是越做越多的，不断发散，同时还无法快速与用户验收，甚至无法验收，因为用户太多，不知道以谁为准，或者用户拒绝对未成形产品验收。这都让敏捷开发更多的局限在项目交付范畴之内。

方法并无好坏之分，也无过时之说。方法只存在适不适用。通过系统性回顾各种方法的背景、理念和方法，可以很清楚看到各种方法的适用性。它们都在他们所擅长的领域发挥着巨大的作用。

同时，我们也发现方法不是孤立存在的，它们之前有着很多共性。

四种方法都在努力服务客户，以客户为中心。

六西格玛和精益都在追求完美。

敏捷和精益都在努力减少浪费。

六西格玛和敏捷都强调质量内建。

IPD和敏捷都以人为核心。

正确的事情总是殊途同归。方法也不例外。在相同的处境下遇到相同的问题，最有的办法总是非常相似。与之相反的是，错误的方法却千差万别。

但当处境和问题发生变化的时候，一部分方法就会失效。比如互联网+产品带来的变化：