向市场交付突破性创新成果（图文）

企业高管一直面临着推动业务增长压力，但是如今快速发展、竞争激烈的商业环境并没有让这一切变得更容易。Arthur D.Little咨询公司对突破性创新的研究表明，领先的公司期望他们来自突破性创新而非渐进式创新的收入份额，在未来5年内能翻一番。

但是，取得突破说起来容易做起来难：研究还发现，88%的商业领袖对他们的突破性创新绩效不满意。他们对现有创新体系在产生重大成果方面的局限性感到越来越沮丧。

这些组织的根本问题通常是，他们采用并非最优的创新方法来实现突破性创新。在过去的三十年里，大多数技术型公司都采用了瀑布式或阶段式方法来进行所有的创新工作。事实上，他们在这些方法的设计和采用上投入了大量的资金，因此他们变得苛刻和呆板。他们的基本目标是使一组充分理解的需求和详细计划的偏差（即：风险）最小化，这两项在开发项目一开始就建立了。因此，他们为渐进式创新创造了完美的环境，减少了循环时间，促进了准时交付。

不幸的是，这种精致的模式并不利于突破性创新。这是因为，在突破性创新中，需求很少是一成不变的，不确定性不仅是一种常态，而且是突破常规界限的手段。尽管一些公司意识到，他们需要为突破性创新创建独立的创新计划，独立于核心研发部门更狭窄的专注领域和官僚主义，但创新过程以及管理者和团队的工作方式却基本上没有改变。

与此同时，在过去的二十年里，信息技术和软件世界一直在运用自己的、高度动态的创新模式——敏捷方法。一段时间以来，敏捷几乎只应用于软件开发，而且已经结出硕果：软件行业的专利数量一直是第二名行业水平的三倍。

如今，敏捷方法正越来越多地部署在非软件的工程和研发部门的阶段式流程中，而且产生了非常积极的成果。Arthur D.Little公司的研究表明，那些成功地将敏捷方法添加到工具箱中，并根据创新类型调整创新方法的公司，其表现要比那些坚持单一瀑布式方法的公司要好得多。

　　将敏捷方法应用于产品开发

将软件开发的敏捷方法应用于产品开发时，关键的敏捷原则仍然是一样的。但是，某些元素会有不同的变动。

迭代方法。在产品开发中，敏捷方法的核心是使用一系列快速迭代循环，类似于软件的敏捷迭代。在开发生命周期早期“探索”阶段，每个循环都着重回答一个确认有高度的重要性和不确定性的关键问题，以便对期望的解决方案建立逐步清晰的图像。循环目标的例子包括技术可行性评估、用户体验评估和商业模式测试。通过这些循环，团队可以有效地构建用户故事。每个典型的两到四周循环的关键工件是原型，用于测试问题中的部分概念。原型需要快速又便宜，因此适合使用简单的图样、模型、视频和模拟。这可能需要组织使用新的工具和方法，甚至与外部设计和原型公司合作。原型与客户的样本、测试的关键问题以及评估的经验共享，以确定团队是否可以继续下一个循环新目标。

在开发周期的后期，循环将焦点转移到“实现”上，并开发与软件敏捷类似的部分解决方案。循环模拟迭代并实现优先级功能。但是，有一些重要的约束条件和注意事项，导致一些公司将敏捷方法的采用限制在早期活动中，至少最初是这样的。

团队。清晰的角色和职责以及权力和责任良好的平衡，对于团队在敏捷产品开发环境中的成功是很重要的。团队必须是敏捷的，并且每个成员都能适应不确定性和实验。在产品开发环境中，敏捷团队是多学科的专家团队，其规模根据当前的项目焦点扩大和缩小。例如，如果团队正在测试一个商业模式概念，可能需要更多有金融、销售和行为经济学方面的经验和知识的人参与进来，这与进行技术可行性循环所需的技能不同。为了支持这一模式，敏捷产品开发团队经常与兼职或限时（即“任期”）资源联系在一起。其中，一个很小的“核心”保持不变，而且在整个开发周期中有一个指定的团队领导；但是，这个角色更像是一个体育团队的队长，而不是层级经理。最有效的团队是那些意识到自己无法得到全部答案，并欢迎外部合作伙伴或专家参与循环活动的团队。

管理者。虽然管理者通常不被认为是敏捷软件开发的关键要素，但它在产品开发中是至关重要的。在敏捷环境中，管理者不像是“通过/不通过”的决策制定者，更像是项目团队的教练。管理者还可以减少“组织抗体”，因为这些抗体试图阻碍或排斥突破性创新。在每个循环结束时进行循环检查，以评估是否已经解决了关键问题，这是项目团队与管理者之间要进行的讨论，他们需要使用海报板、原型和其它可视化辅助工具以促进对话。为了使这种环境成为可能，重要的是敏捷管理者团队要由这样的人组成，他们能够培养实验和学习文化、紧迫性和敏捷性观念以及帮助团队跨越障碍的热情。

　　把敏捷作为整体创新方法的一部分

当应用于生产工程产品的公司环境时，阶段式（瀑布式）和敏捷方法在它们的实现中是截然不同的，并且通常适用于不同的创新目标。我们发现，当试图将敏捷引入到现有的阶段式流程中时，组织会采用两种一般性的方法：

• 将敏捷整合到单个创新流程中

• 添加部分并行的敏捷路径

将敏捷整合到单个创新流程中，通常需要在现有的阶段式流程中使用迭代循环，但是其整体结构保持原样。Arthur D.Little咨询公司的经验是，尝试整合方法只能次优化其中至少一个。尽管在开发阶段在速度方面可能会有一些小收益，但其影响充其量是有限的，最坏的情况是它会导致团队受挫和错过市场机会。使用这种方法，公司可能是在欺骗自己已经采用了敏捷原则，其实却没有任何基本的改变。

更好的解决方案是同时使用阶段式和敏捷，这样组织就可以将正确的方法应用于渐进式和突破性创新的创新组合中。

在这个模式中，按照公司的特定创新策略，敏捷路径的规模很适合处理突破性创新的预期流程，它通常比阶段式路径要小得多。考虑到上面所述的动态团队模式，专用资源也明显减少了。现有的阶段式路径已经投入了大量的资金建立和优化流程、团队角色和职责以及管理者和工具，因此仍然需要它为市场带来渐进式创新。在大多数公司中，这些都是“保持轻量”的关键项目，并占据了创新组合的大部分。

当从头开始建立一个敏捷路径时，一个关键的考虑因素是该方法如何连接到下游的现有流程。通常，敏捷方法开始都是应用于开发流程的前端。在这里，通过研究和更好地理解有很大不确定性的概念，可以得到明显的收益。对于下游的开发活动，如详细的设计、测试和发布，公司可以继续利用他们的重要人才来实现。在这种情况下，敏捷过程和现有阶段式过程之间的转接点需要仔细地定义和管理，尤其是详细设计的各个方面已经包含在早期原型开发中的情况。最终，许多公司可能希望演进到完全端到端的敏捷开发路径，其中已包括这些下游活动。这种设计能够更好地获得敏捷方法的全部好处，又能避免退回到阶段式文化和工作方式的陷阱。

在基于产品的公司中实现这些敏捷开发实践可能会遇到许多挑战。下图重点说明了公司预计会遇到的一些更常见的障碍，以及如何克服这些障碍。

障碍1：退回到“舒适”的瀑布过程，仅口头上支持敏捷。其解决途径是：由经验丰富的实践人员对早期/试点团队进行大量的影子引导，以加速学习，并确保团队和管理者成功地应用方法。

障碍2：团队成员带着不确定性挣扎着工作。其解决途径包括：仔细选择团队领导和成员资格，寻找那些未被发掘的、善于跳出固有模式思考的人才；避免创建只有习惯在现有环境中工作的“平常角色”的团队。

障碍3：组织的其它部分干扰了敏捷开发/突破创新路径。解决途径有：为突破性路径建立高级资助；将团队/小组与现有的业务部门和企业经营问题隔离开来（例如，季度损益），但是，确保有权使用资源和信息。

障碍4：管理者成员继续以一种专制的“我知道最好”的方式运作。解决途径包括：调和来自组织不同部门和层级的典型管理者特征；从外部资源中挑选20-40%的管理者，包括企业家、风险投资公司和私人股本公司。

障碍5：有限的突破性想法或执行能力。其解决途径是：使用多种方法获取客户和关键利益相关者的洞察力；充分利用生态系统和伙伴关系，以获得新的想法和执行能力。

障碍6：突破性创新概念在从敏捷路径发展到开发阶段时停滞不前。解决途径是：使用特别管理者审查，以确保对新产品的生产能力、性能和商业化路线方面的项目准备和组织接受能力。

障碍7：突破性团队与组织的其他成员隔离开来，这就产生了缺少商业价值的感觉。其解决途径包括：定期轮换核心部门和突破性团队的员工；确保整个组织对突破性组合决策有充分的可见性；按照适当的标准表彰价值创造与短期项目管理重要事件。

原文经许可，摘自Mitch Beaumont、Ben Thuriaux、Prashanth Prasad、Chandler Hatton和Colin Davies发表在Arthur D. Little咨询公司出版的《Prism》杂志2017年第1期上的《Using agile approaches for breakthrough product innovation》一文。Arthur D. Little咨询公司2017年登记版权。Geoffrey Bi译。

文 / Mitch Beaumont、Ben Thuriaux、Prashanth Prasad、Chandler Hatton与Colin Davies

图 / 图虫