不懂业务创新的工程师，不是好的架构师

阿里妹导读：对于高阶的工程师来说，光有持续交付价值的能力还不够，我们必须保证交付的东西是有用的，能带来真正的价值。持续交付和业务创新是相互关联，相辅相成的。持续交付是业务创新的基础，而持续交付的收益最后要落实到业务创新中去。

如何在深刻了解业务的基础上，完成有效的业务创新？下面为你送上由阿里资深技术专家何勉老师带来的精彩分享。

有效的业务创新离不开持续交付能力的支持。持续交付能力让我们可以更快地获取反馈，它是互联网时代创新的基础。互联网时代的创新究竟有什么不同呢？我们看下面这幅图。

第一幅是部分共享单车App的图标，其中相当部分在过去一年已经退出了竞争；第二幅是部分直播App的图标，业界流行所谓“百团千播”一说，“百团”说的是当年的团购大战，“千播”说的直播竞争的盛况空前，如今直播风潮还未过去，小视频的战火又已经燃起。

移动互联网时代，创业和产品开发的成本大幅降低，触达用户的渠道也更加直接，用户的选择急剧增加，选择权迅速从生产者转移到了消费者一侧了。交付的东西，用户不会选择或者根本不在乎，成为创新过程中最大的浪费。

除此之外，我们还不得不面对加速变化的世界，业界称其为乌卡（VUCA）时代。乌卡最早用来形容冷战后的国际政治环境，它由Volatility（易变性），Uncertainty（不确定性），Complexity（复杂性），Ambiguity（模糊性）四个单词的首字母构成。今天乌卡被更多用来形容技术和商业环境，而这也是产品交付和创新所必须面对的环境。

环境加速变化和选择权向用户侧转移，这两个趋势对产品的创新和交付模式，提出了全新的挑战。我们需要更有效的产品创新模式。

以持续交付为基础，我们有机会也必须引入系统创新方法。这就是我们后面要讲的从持续交付到产品创新。

有效的创新从明确目标开始。目标从哪里来？它源自使命和愿景，源自使命和愿景在空间和时间上的分解。所谓空间分解是指分解和分析达成目标的各个要素，以及各个要素之间的关系。而时间分解指如何按步骤的去构建这些要素，实现这个最终的目标。

先看一个空间分解。为此，要先介绍一个概念叫飞轮效应。飞轮的概念最早是在《从优秀到卓越》这本书提出来的，作者柯林斯通过研究那些基业长青的企业发现，在它们背后往往都存在一个飞轮——也就是业务的正向加强循环。如果去仔细分析，这个飞轮也存在于所有快速发展的互联网业务中。

以亚马逊为例，贝佐斯在97年上市招股书里面就明确提出并描述了亚马逊的飞轮。我们要为用户提供足够多的选择，选择多用户体验就好，体验好用户流量就会多，流量多，就会吸引更多卖家加入，从而提供更多用户选择，实现更好的体验，形成正向反馈，不断加强实现增长。这个飞轮还有另一个分支，业务规模的增长带来更好的成本结构，这样价格就会更低，这也会促进客户体验变好，这个循环也是飞轮的一部分。

飞轮效应看上去很美，然而它的困难之处在于如何启动和维持它。为了使静止的飞轮转动起来，一开始你必须使很大的力气，一圈一圈反复地推，每转一圈都很费力，但是每一圈的努力都不会白费，飞轮会转动得越来越快。当达到一个很高的速度后飞轮所具有的动量和动能就会很大，使其短时间内停下来所需的外力便会很大，便能够克服较大的阻力维持原有运动。

飞轮的另一个难点在于，它环环相扣，一个环节脱节它就转不起来，比如在亚马逊的例子中，如果用户的核心体验并不是选择多，他们不会因为选择多就来到网站，那我们就必须重新挖掘用户的诉求或问题。正因为如此，我们才必须知道飞轮背后的逻辑是什么，有哪些假设。验证这些假设，构建合理的商业闭环，飞轮才能真正运转起来。

我们可以从很多成功的业务中看到这样的飞轮。淘宝、盒马、抖音、微信背后我们都能看到他们的飞轮。飞轮是实现规模化的产品的必备选项，否则以今天竞争环境之残酷，别人的产品有飞轮，而你没能成功构建的话，那你就很难竞争了。

让我们虚拟一个场景，假设我们要做一个短视频应用，类似抖音，看看我们最初设想的飞轮是什么样的呢？以下只是理论上的推演，现实中的情况一定要复杂很多。

更好的观看体验带来更多用户使用，更多的用户使用就带来更多的内容创造，更多的内容创造就带来更多的优质内容，更多的优质内容又带来更好的体验，形成加强回路。这是飞轮的核心，问题是从哪里开始旋转飞轮呢？这成了先有鸡还是先有蛋的千古难题。

我们先完善一下飞轮的构成要素，再来分析。更好的体验，还可能产生更多的分享，而分享带来新的用户。增长带来更多收入可能，收入多的话就会带来更多KOL（达人），KOL带来更多优质内容，并且一些素人也会成长为KOL。飞轮更完善了，但鸡和蛋的问题依然没有解决。比如在你能够带来可观收入之前，KOL凭什么来？KOL不来又如何实现增长和带来收入？

为了飞轮转起来，我们必须找到初始的转动把手。比如，对于更多优质内容，我们可以先去梳理现有的内容供给，保障初期的供给。或者挖掘OGC周边内容，保障持续的精品内容的供给，这些行为在飞轮的周边，没有先有鸡还是先有蛋的问题，是我们可以着力的地方。因此我们称之为把手。

图上，我们分析了启动和持续驱动飞轮的把手。比如，初始的KOL怎么来？你可能需要内容补贴，或者是站外拉取等等。比如，如何构建更好的初始观看体验要素？比如，如何让用户贡献内容创造？等等。

除此以外，还有非常重要的一点，就是在增长中如何建立合适的调性。这也是让飞轮可以相对长期运转必须考虑的。快手和抖音的调性就不同，也决定了其后的扩张路径和难度的不同。并不是孰优孰劣，重要的是，这对你后面的增长策略影响很大，需在业务发展过程中给与关注。

基于业务目标，我们构建了增长飞轮，并分解了驱动飞轮运转的把手。这是对愿景和使命在空间上的分解，它给出了从哪里着力去构建产品和业务模式的初始方向。

有了空间的分解，从理论上，我们有了转动增长飞轮的着力点。但我们还必须面对一个问题——具体从哪个地方开始。这就是我们接下来要讲的从时间上分解。先关注什么，后关注什么？这是一个路径问题，错误的路径是产品创新过程中经常会犯的错误。

关于产品创新的路径问题，我们要介绍一下关隘模型。它认为做创业或者做一个新产品、新的业务需要经过各个阶段，每个阶段是上一阶段的前置条件，因此称之为关隘模型——过了上一关才能进入下一关。

关隘模型的第一步是共情——发现一个未被满足的需求，有足够强的理由引发用户的兴趣，这是产品存在的理由；接下来是粘性——解决方案要能够让用户愿意持续使用；然后是病毒——用户愿意告诉或拉来他们的朋友一起使用；再然后是收入——你得有支持持续运营和增长的收入来源；最后才是规模化。

关隘模型的核心是“关隘”——过了上一关才能进入下一关。比如没有共情就不可能有粘性；没有粘性你也无法让产生口碑和病毒，即使通过激励的手段又不持久，而且病毒带来的用户也会流失。

为什么要介绍关隘模型呢，因为它看上去很简单、合理，但现实中，我们还是会一再犯错。特别是在产生粘性之前，就去规模化扩张。这是最常见的错误，这和人类急功近利本性以及KPI的影响都有关系。

关隘模型，为愿景和使命在时间上的分解提供了概念上的指导。

回到增长飞轮，我们如何判断从哪里开始，找到着力点呢？基本的判断是，从用户体验开始，它与用户的共情和粘性直接相关。

还是以亚马逊的飞轮为例，粘性来自于什么？当然是用户的体验，所以从用户体验出发，是启动飞轮运转的关键。在亚马逊的案例中，用户的体验的核心是价格和选择。但做到这一点并不容易，如果亚马逊一开始就做全品类，那需要花很长时间也不会构建起基本的用户体验，亚马逊也不可能坚持到今天。

理解了这一点，我们就能理解亚马逊为什么要从图书做起，因为在那个时刻，图书是最有可能和快速建立起选择和价格这两大体验的。亚马逊最初的LOGO上也写着，全球最大的书店就是这个道理。图书是亚马逊其后20年品类扩张的起始。

我们说以体验为核心，但对体验是什么一定要有自己的理解。体验绝不仅仅是网站或 App 的交互好这么简单，它体现为特定场景下，用户核心诉求被满足的程度。

比如盒马，它最初定位解决的是25岁以上都市白领买菜的问题，那它的核心体验就是：1）所想所得，你一想到马上就能够送到，半小时送达；2）一站式购齐，比如说买韭菜炒香干，有韭菜，没有香干，就不是好的体验；3）足够新鲜和方便，这是它的核心体验。

比如说百度做MP3的时候，俞军面试产品经理，有一道题目是如何才能做好百度 MP3 产品。其他人洋洋洒洒写了几页纸，而李明远就写了两句话，六个字——搜得到，能下载。这就是抓住了核心体验。

小视频的核心体验又是什么呢？我看到的是：持续供给的优质内容，并且能精准的分发。做到这两点并不容易。这是我们一开始应该聚焦的地方。可能还应该更聚焦，如针对一小部分初始核心人群的优质内容和精准分发。

不同的人对核心体验会有不同的理解, ，你可能也有自己的理解，比如觉得用户的参与和自我展现才是最核心的诉求，这都可以，关键是你必须对核心体验有一个明确且聚焦的定位，还必须能够差异化和聚焦，这只是举个例子，肯定不容易，特别是一个追赶型的产品。

这就是我们所说的时间上的分解。你必须在一开始聚焦核心的点，这个核心的点往往是体验，不同产品体验是不同的，围绕体验要做的事情也并不少，团队应该尽量聚焦，比如抓住核心体验和核心人群。盒马就是一个很好的例子，尽管梦想很大，但一开始他们牢牢抓住了都市白领一日三餐这个核心场景，做深做透，满足用户的核心诉求，打造自己的核心能力。

这是时间的分解的例子，它的核心是必须聚焦，正确的时间做正确的事，一步一个脚印，才能更坚实的进入下面的步骤。还是以盒马为例，解决好三口之家买菜的问题。为盒马建立了两个基础：1）对用户而言是心智——盒马是一个身边的可靠服务；2）对内部而言是能力——供应链能力，管理能力等等。这时我们进入下面的阶段，才更可靠。不管是口碑的建立——如：本地社区的运营；还是服务类型的扩张——如：24小时应急服务，3公里的生活服务圈等；还是规模和渠道的扩张。

以上，我们分享了对目标和愿景在空间和时间的分解。它们是产品创新过程的出发点。对于空间的分解我们讲了，如何构建增长飞轮，以及找到飞轮的把手。它是对业务增长的基本逻辑的假设，而业务成功是建立在这些假设的基础上的，因此我们必须在产品交付和创新过程中不断的验证调整，打造有效运作的业务闭环；对于时间的分解，我们介绍了关隘模型，以及从用户体验开始，找到着力点，开始最早的业务闭环的打造和探索。

对目标和愿景在时间和空间上的分解，我们构建了业务大图，它指导我们在什么时刻关注什么目标。接下来，我们还要对目标进行量化，量化的目标和度量让我们更能够知道我们是否在向着正确的方向前进。

怎么去量化呢？这就要回到具体的产品，去看产品的指标。为此，我们需要构建产品的大图，从产品的大图上，发现和定义正确的指标。

满足用户的诉求是产品的核心，从用户使用路径出发来构建产品大图是有效方法。还是看假想的小视频例子，图中每一个框是用户的一个行为节点，其中深蓝色的框是内容生产的节点，浅蓝色的是内容消费的节点，绿色的是我们最期望产生的用户行为——在这里是内容的发布和观看以及关系的沉淀。

看一下最核心的行为路径。最上方是用户从哪里来。用户进入后，可能会直接生产内容——如拍摄上传，更可能从消费内容开始。内容消费过程中会产生互动，如：评论、关注等，也有可能被引导向话题参与或者是内容创作。对于内容创作也存在一系列路径，包括进入、选素材、拍摄、编辑、发布等，其中任何一步用户都可能退出。不管是内容消费还是发布，我们都希望用户能够积极的分享，分享带来新的用户流量。最左边是站外的内容供给。

用户路径图的核心是用户，也就是产品满足用户并引导用户行为的过程。产品的成功，很大程度上取决于用户行为的转化，我们的服务是否满足了用户，并且让用户产生了期望的行为。比如，各个环节的转化率、活跃率和留存率等。

我们称用户路径图为产品大图，基于产品大图我们设计和审视更合理的产品路径，定义核心的产品指标。图中，红色和灰色的文字是其中一些产品指标，其中红色是当前时刻重点关注的指标，它们大部分与用户的核心体验和粘性相关，如用户人均VV（video view播放视频）数、次日留存，视频的播放完成率等。

基于业务大图，我们确定了特定时刻的主要目标。基于产品大图，我们可以进一步确定相关的指标。定量目标回答的是 Why 的问题，接下来我们要探索用什么抓手 (How) 实现目标，以及通过什么样的产品功能或运营活动 (what)。从Why 到 How 再到 What 这是定义产品功能的路径。

比如提高某个活动的用户参与率是我们的目标，是 Why。那如何才能实现这一目标呢？我们必须找到适当的抓手。比如：让用户感知到这个活动；要让用户有参与活动的意愿；要降低用户参与活动的门槛；要让用户参与这个话题后得到报偿从而重复的参与其中，我们称这些为抓手，也就是 How。

如何能产生这样的 How 呢，我们需要提供相应的产品功能，比如为了让用户感知到话题，我们需要在产品中增加活动的透出，并精准的推送消息；为了降低用户的参与门槛，我们可能要重新设计活动的流程，这些是 What。

Why、How 和 What 这三个圈被称为黄金圈，它也是从目标到功能的映射。在产品开发中，我们可以把 How 称为抓手——如何影响用户才能实现目标。有时在 How 这个层面，我们会区分对不同用户的影响 (针对不同用户的抓手)，于是它就变成了 Why，Who，How 和 What。

这幅图就是一个例子，目标是提高导购活跃度，这是 Why，对此我们可以做出量化的定义，如：即时回复率达到xx%等等；为此我们要分别影响导购和品牌这两个角色，这是 who；如何影响这两个角色，来促成目标的达成，这是 How，如：“让导购即时知道应该做的事”就是一个影响手段；最后如何实现这些影响呢，这是 What，如新会员的加入语音提功能，提供即时备注功能等等。

以上从业务目标出发定义产品功能的实践，被称为影响地图。其背后的假设是：产品通过功能 (what)，影响 (how) 特定用户角色 (how) 的行为，从而实现业务目标 (why)。影响地图帮助团队更有效地拓展思路挖掘和组织需求。

基于影响地图，接下来我们要做的是选择其中最有效的功能，合理规划，迭代的实现目标。关于规划，我想问大家一个问题。我们的目标是实现整张地图吗？

显然不是。在需求的挖掘阶段，我们可以集思广益、充分发散，但做规划，我们则要有效收敛。我们的目标是在地图上找到从功能到目标的最短路径。以最少的功能，最快地实现目标，或验证假设。影响地图让我们可以更聚焦。第一：聚焦有限的目标，过滤与目标无关的需求，防止范围蔓延；第二：在资源有限的情况下，强制做出优先级的判断，选择对实现目标影响最大的需求。

图中标了“1”和“2”的就是对优先级的标识。“1”表示接下来就要去做的，它们构成一个最小的可发布产品——MVP (Minimal Virable Product) 。“2”则是后面将要考虑的。

我们做了选择的需求，并完成交付。这就代表成功了吗？显然不是，我们的目的是实现目标，而不是交付功能。成功与否最终还是要看目标的达成情况，而功能只是手段。功能与目标之间还差着两道假设。第一：我们假设这些功能会产生设想的影响，让用户产生我们期望中的行为；第二：假设对用户行为的影响能帮我实现目标。这两类假设，在被事实验证之前，只能是假设。

影响地图的一个重要的优点是，它保留并直观呈现上面两类假设。这样，当功能交付后，我们可以也应该去检视影响和目标的达成情况。我们希望引导团队更多关注业务成果，为业务负责，而不仅仅只是交付功能。

所以，功能交付后，我们要基于影响地图去检视影响和目标的达成情况，并作出及时的调整，这样才能形成闭环。之前我们对目标的量化为这一闭环的有效性提供了好的基础，我们应该在交付功能后去收集和有效分析数据，形成数据化的闭环。通过这一套机制，我们希望培养：关注业务结果，数据驱动的实验文化和增长文化。

到此为止，从持续交付到业务创新的内容就讲完了。它的核心是要形成一个有效的创新循环。这个循环从确定业务目标开始。

基于业务大图，团队把整体目标拆解成相互关联的子目标，确定实现目标的步骤和当前时刻应该重点关注的细分目标，并基于产品大图确定相关的度量指标，让目标量化；从量化目标出发，建立从 Why 到 How 再到 What 的映射，构建实现业务目标的影响地图；接下来，基于持续交付能力，顺畅的交付需求；需求交付后，我们要回到目标有效反馈并即时调整。

以上的各个环节构成了面向业务目标、数据驱动和即时反馈调整的有效创新循环，而持续交付能力则是这一循环运作的基础，它让创新循环得以加速。面对今天加速变化且竞争激烈的环境, 加速有效创新循环是产品交付及创新的必然选择。

最后我做一个总结，图中的这个人是阿基米德。我们都知道他在一次洗澡中得到灵感，发现了浮力定律。我今天的问题是，阿基米德在此之前洗过澡吗？那之前为什么没有发现浮力定律呢？这一次有什么不同？对，国王问了问题——皇冠中的黄金有没有掺假？是问题引导阿基米德发现了浮力定律。正确的问题带来好的结果。

我把这个故事作为总结，是想说：我们实施敏捷也罢，提升效能也罢，一定要知道我们想解决的问题是什么，这样才能找到正确的实践和方法。

图中，我们列出了产品开发实践栈，大部分产品团队更多关注的是中间橙色的部分。但今天的业务不确定性在持续提升，选择权在向用户侧转移。持续变化和激烈竞争的环境，对产品开发提出了更高的要求。产品开发的敏捷实践需要突破原有边界。这当然不容易，重要的是，我们首先必须弄清楚想要解决的问题是什么? 它比答案更重要。

总结今天分享的内容，我们一直在回答两个问题。

第一：沿着实践栈往下追问，我们要回答的问题是：“如何才能顺畅和高效的交付？”为此有了我们以流动效率为核心的技术和管理实践，以及如何让开发人员专注于业务逻辑，而不用过度分心于其他事务的工程实践。

第二：沿着实践栈往上追问，我们要回答的问题是：“如何保证交付的是有用的价值？”，为此才有了我们在第三部分所讨论的有效创新实践——从业务目标出发，并最终回到业务目标形成有效的闭环。

为了回答以上两个问题，我们需要从业务目标到产品设计和交付，直至运维的全方位实践，这是一种全栈的敏捷实践，业界也称之为Biz-Dev-Ops。

我们还想告诉大家，持续交付和业务创新是相互关联，相辅相成的。持续交付是业务创新的基础，而持续交付的收益最后要落实到业务创新中去。

我们今天讲得更多是一个方法论，实践不可能非常全面。最重要的是我们一定要明确问题是什么。从正确问题出发，相信大家一定能找到适合自己的实践框架，切实提升交付和创新能力，助力业务成功。

不懂业务创新的工程师，不是好的架构师 | 深度相关推荐

哔哩哔哩殷汶杰：合格的多媒体技术工程师有成为全栈架构师的潜质
英雄会是CSDN旗下针对国内IT技术领域专家展示和交流的平台.通过线下线上的互动形式,为CSDN社区专家提供更多学习.合作.宣传的机会.英雄会后续将在北上广深等国内一二线城市建立分会,各个分会后期将组 ...
高级开发工程师如何快速晋升为架构师？高级开发工程师与架构师到底有啥区别？
大家好,我是冰河~~ 一直以来,都想写一个系统介绍架构师核心技能的专栏,那就是<架构师进阶系列>.为什么要写这个专栏呢?很多人认为自己技术能力不错,但是每次想面试大厂的时候,总是被面试官吊 ...
企业IT工程师，如何向云计算架构师转型
人们处理和思考IT的方式已经发生了根本性的变化,一些成功的IT专业人员现在影响了企业的业务模式和策略.数字化转型正在影响所有业务垂直领域,而云计算架构师在支持下一代业务计划时必须开始思考有什么不同. ...
开课吧：为什么AI工程师都要懂一点架构呢？
AI时代,我们总说做科研的AI科学家.研究员.算法工程师离产业应用太远,这其中的一个含义是说,搞机器学习算法的人,有时候会因为缺乏架构(Infrastructure)方面的知识.能力而难以将一个好的算 ...
高级软件工程师和架构师的区别
本文转载连接: http://www.codeisbug.com/Doc/4/1112 架构师倾向于通信 . 通信框架 .队列和分布式框架运用以及阿里云和微软现有分布式组件的运用. 高级软件工程 ...
公开课：如何成为一名高级系统运维工程师（架构师）？
如何成为一名高级系统运维工程师(架构师)? --老男孩教育赵班长内容简介: 突破瓶颈,从普通系统运维成长为高级系统工程师.架构师,如何提升,需要掌握哪些技能和知识,公开课上为您解惑. 分享形 ...
Windows Azure-2.5天免费深度技术训练营——面向软件工程师和架构师
Windows Azure-2.5天深度技术训练营--面向软件工程师和架构师 ●[深圳场]3月13日.14日全天,3月15日上午在线报名 ●[北京场]3月20日.21日全天,3月22日上午在线报名 ...
助你成长为优秀的程序员杰出的软件工程师、设计师、分析师和架构师
编码规范往往只是对具体编程的格式及细节要求进行规定,但对于提高软件人员编程能力而言,编程规则更具有价值,下面将我的一些观点和想法提出来供大家参考,也希望大家批评指正,谢谢! 1 概述编程是一个软件工 ...
程序员职业发展路径图：从菜鸟工程师到高级架构师
http://www.sohu.com/a/249729952_355140 踽踽独行上下求索总是痛苦,如果有良师益友陪伴点拨必能事半功倍.从新手码农到高级架构师,要经过几步?要多努力,才能成为为人倚 ...

不懂业务创新的工程师，不是好的架构师 | 深度

不懂业务创新的工程师，不是好的架构师 | 深度相关推荐

最新文章

热门文章