首页 运维资讯整个硅谷都在谈的Growth是什么?

整个硅谷都在谈的Growth是什么?

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

整个硅谷都在谈的 Growth 是什么?

本文根据邵震在2016GMTC全球移动开发大会上的演讲整理而成。

老司机介绍

邵震,Google Search前员工,Square全栈工程师、Mobile Growth Tech Lead,专注Square App的业务增长,关注Growth方法论在Mobile开发中的具体应用。

我以前在谷歌工作,大概2013年的时候到 Square 公司,后来一直做 Growth 的工作。在一个技术论坛上,可能我讲的这一部分内容是最不技术的。提起 Growth,大家认为很神奇。以前范冰老师写过一本书,叫《增长黑客》,这个书名非常迷惑人:黑客像是超人一样的存在,一个人坐在黑漆漆的屋子里面。实际上 Growth 很现实,整个硅谷都在谈论它。不但在谈论,而且他们认真在做。

据我了解,Growth在国内也是非常火的概念。首先,每个公司都在谈;每个人都觉得他自己知道 Growth 在做什么;Growth 的一个小概念叫病毒式营销,每个人挂在嘴边。第二,在所有人都不认识我的情况下,很多人还会来听讲座,完全是因为 Growth 本身的魅力。

再谈 Growth第一个部分是“再谈 Growth ”。为什么是再谈?虽然Growth 这个词已经很火了,但是在火的背后,我看到大家对它有很多误解。

Growth

第一个问题是,什么是 Growth 。我对 Growth 的一个比较简短准确的定义是,Growth 就是“实现业务的有效增长”。这里面有几个关键词:实现、业务、有效,最后是增长。Growth Hack,我把它翻译成,不是“增长黑客”,而是“增长法”。“法”这个字在汉语里包含“工具”和“思路”的成分。Growth 是一个相对新的想法,硅谷一直在谈、在实践、从下往上在摸索。一直到近两年,才有人把 Growth 的概念提炼出来,将它作为一个方法论。

那么,为什么现在在中国火起来了?因为现在中国的公司感受到压力。Growth 可以带来效率的提高,不管是工程效率,还是使用钱的效率、获取用户的效率。这种效率的提高,对公司非常重要。在市场增长天然特别好的情况下,把资源使用在实现产品特性上面,会获得更大的价值;而在市场走冷,竞争变强,每个人都不得不计算获客成本的时候,Growth 就重要起来了。

Growth 在中国以及整个硅谷,有什么样的难点?这是由 Growth 本身的性质所决定的。在一个小公司,Growth 其实就是适应市场,就是说公司给用户提供什么样的价值,最终决定了用户会有多少人、以什么样的频率停留在平台上面。

在 Medium 上面有一篇比较有名的文章,叫“ Why startups shouldn’t have a growth team? ”(为什么一个小公司不应该有 Growth组)。虽然有标题党之嫌,但有可取之处。因为全公司都是 Growth 组,应该由 CEO 带头做 Growth。在公司的发展前期,Growth 用来贴近产品的本质,寻找它的市场立足点。

在发展后期,当市场需求很稳定了,公司做什么、怎么挣钱很稳定了,Growth 可以去更靠前的位置,向用户传播价值,让用户的行为“快速收敛”到你想提供的价值,这时候,Growth就变成向用户展示公司价值的一种方式。

公司怎么把有限的资源,不管是钱,还是工程师、产品经理等,放在一个无限的机会空间上,都是 Growth 擅长做的。Growth 从中找出用最小的代价获取最大利益的点。但是这件事情不好做。

Growth 代表了工程师跨界的思路。硅谷绝大部分的 Growth 是由工程师来驱动的,他们不是普通的工程师,而是需要很好的产品和运营知识,需要懂设计,需要懂data,很少有人能够胜任。

在国内,我认为还有一些额外的挑战。大家对Growth有一些误解:把买流量看作 Growth 本身;重视非技术运营;产品迭代特别快,快到数据埋点、整个数据收集都来不及做;国内创业有自顶而下做决策的习惯,老板说了算;还有工具不到位的挑战。硅谷已经到了创业环境比较成熟的阶段了,很多工具已经用了很多年。但是在国内想找一个特别值得信赖的工具很难,同时还要考虑这个工具的背景、是不是属于某一个竞争对手。这些都是数据缺失、工具不到位造成的困难。

Growth

 

 

现在我把所谓的“增长法”拆解,用一种简单直白、尽可能诙谐的方式讲出来。

Growth

首先是 Growth 关心的核心话题。我们把 Growth分成4个部分:用户获取、用户转化、用户变现和用户留存。AARRR 这个模式,和以前看到的一些技术分享,稍微有些不一样的,但本质上是差不多的。AARRR 会给人一种误解,就是整个 Growth 是一个漏斗,它是逐渐变细的。盈利一定是通过忠诚用户产生的?不一定。推荐一定是通过付费的用户产生的?也不一定。新用户能不能做?可以。

Growth

我们来看一个现实版的 Growth。现实中 Growth 就关注这几个核心话题,但是这几个话题实际上是纠缠在一起的,而且非常零碎。如果有真正可以将它看成比较严格漏斗模型的地方,只有用户转化:以“潜在用户知道你的品牌”作为起点,把“把潜在用户变为一个你的忠诚用户”作为终点。每一步都严格依赖上一步的成功。

Growth最基本的单位是什么?

首先观察产品或者用户行为的模式。比如,这个模式可能是说,用户在某一个页面丢失得非常快。根据观察到的模式,去设计一个方案,这个方案会假设一个解决方法,同时设计一个指标,也就是“到底哪一个数据可以清楚告诉我这个解决方法是好还是坏,有多好”。

方案设计完了之后,要做工程实现。如果这个实验是成功的,要投入应用和监测,因为短期的实验结果并不代表长期带来的收益。最后,如果有比较强大的数据分析人员或者产品人员,会进一步挖掘这个实验所带来的启示。

整个硅谷都在谈的 Growth 是什么?

上图所示是一个比喻。就像开发药物,要先研究这个病,开发这个药,做临床实验,最后,这个药应用之后还要做监测,最后回到理论。在美国做药是非常非常复杂的,药使用在人的身上,而人是国家的根本。医药的整个体系都是以人为本。对于 Growth 也是这样。用户体验是很敏感的内容,要非常小心,否则一旦你的用户走了,再把他叫回来,是非常难的一件事情。

整个硅谷都在谈的 Growth 是什么?

图中这个流程里面,需要一些工具支持。比如需要有深挖数据的工具,具体做实验的时候,A/B Test 是很重要的工具。

从操作者的角度来讲还有几个步骤很重要。首先,操作的人需要理解他的产品,所有从事 Growth 的人,需要统计素养,需要理解用户,同时要理解工程实现的难度。

整个硅谷都在谈的 Growth 是什么?

Growth 组的操作,其实会把它组织成一个实验的管道,用某种方式来跟踪有哪些实验想法,有哪些已经开始了,哪些已经完成了,对完成的实验要计算影响,成功实验的影响相累计,大致上可以估量一个 Growth 组的成功与否。这是非常粗略的表述。任何一个 Growth 背后都有实验,每个实验都非常小,每个季度可能可以做上百个实验。虽然一个实验带来的收益非常小,但是整体加起来很大。

Growth 里面经常会讨论这样一件事:我有很多很多的主意,哪一个先做,哪一个后做?这个时候就会在心里画这张图,去思考每一个实验,机会有多大,工程成本有多大。如果工程师比较熟悉工程,那么对工程成本应该有一个非常清楚的估计,对数据比较熟悉的,也会对机会大小有一些估计,这其实都是在算性价比。

整个硅谷都在谈的 Growth 是什么?

这个图还有一个额外的维度。图中的圆有大有小,表示在一个点上的同一思路会有一系列的想法,可以产生一系列的实验。我们验证了其中一个实验,很可能会提示,在同一个坑里挖到更多的金子。

下面是 Growth 实践中的一些心得,比较零碎不成体系。首先,Growth 最重要的部分是用户留存。没有人是傻子,可能某一个阶段他会受到欺骗,但是他最终留在你的平台上,完全取决于你的平台能带来多大的价值。

整个硅谷都在谈的 Growth 是什么?

在组织架构上,一个最小的 Growth单位,至少要有工程、产品、数据、设计,还有运营。不一定每个部分都有一个人,但是每个部分都有人能覆盖到。之所以要由工程师来驱动,是因为工程师是组里最了解产品的人。他了解你有没有触发产品的特性,写代码的时候明确知道性能的弱点,知道埋点在哪里最好,甚至产品是否有修改,工程成本有多大,工程师必须有第一手的信息,任何实际改动都要由工程师落实。由工程师来驱动其实是最少沟通成本的方式。

从公司的角度来讲,做 Growth 需要有一个自顶而下的战略:公司需要从结构上去保护这个思路。如果你要求技术工程师追求技术难度,用这个事情衡量的他的工作,他不会把对公司业务的影响放在最核心的部分,他被迫想的事情与 Growth 的思路是相悖的。

最后,快速迭代并非必不可少,但是有了它可以做得非常顺。在最后的数据出来之前,谁也不知道好坏。比如,想做能够支持匿名用户的实验,想知道用户不用注册是否会留存更多人。那么,立刻去做全 App 的匿名支持、完全不需要登录的产品,还是去做非常小的实验,比如推迟一到两步要求登录,来验证不需要登录这件事对用户有多大的影响。

Growth 方法论 

Growth是一个方法论,理论很美,但是不一定适合所有的公司。你至少需要同意,或者从内心深处认同几个理念。

Growth

第一个理念是,你是否认为,产品的成功是由用户是否喜欢来决定的。比如,你做政府项目,或者做市场稀缺功能,用户可能不得不去用,所以 Growth 在你的用户行为里面的影响其实只占了很小很小的部分,这个时候你没有必要去考虑 Growth。

第二,你是否认同,所有事情最后都是可以衡量的。比如,产品受喜欢度,是否可以量化,获客策略是否可以量化。

最后,Growth是否只是产品中锦上添花的部分?因为做这件事消耗很大,硅谷的Growth经常挂在总监下面,Growth这个大坑挖出来,需要人,需要资源,需要协调关系,可能开始的时候都很顺利,但是你很快就需要考虑“到底值不值得做”这个问题。从硅谷现在来看,绝大部分的公司都把这个坑挖出来了,这是有一定的道理的。

从抽象层面上看,Growth 的方法论就是,怎么看待 Growth,怎么做 Growth。现在小结 Growth 的方法论我觉得功力不够,我更愿意引用这方面的一个大师讲的一段话,这个大师的名字叫庄子。

Growth

彼节者有间,而刀刃者无厚,以无厚入有间,恢恢乎其于游刃必有余地矣”。这句话是说,产品里边有一些“解决起来很简单,但是影响非常大的”问题,就像“关节里的缝隙”;刀刃者无厚,Growth 就一把锋利的刀,要“以无厚入有间”,就是用最有力的资源去做这些成本低影响大的“关节”之处,这样才能,“十九年而刀刃若新发于硎”。

当你看到一个服务的交汇点,或者是用户体验或者性能非常敏感的点,你要慎重,这就是所谓的“族”,“血脉筋肉交错的点”。你要重视,要有畏惧之心,“见其难为,怵然为戒”。那这时候应该怎么做呢?庄子告诉我们“视为止,行为迟,动刀甚微”,就是说你要先看,过一会再做,每一刀都特别小。

在 Growth 方法论里面这个非常典型,要先去观察,然后用数据指导该怎么做,想清楚之后再动手,每一个实验都非常精准,非常小,但是这些实验累积起来总是能把事情解决的。这时候庄子生动描绘了解决了一个大问题之后的模样,“提刀而立,为之四顾,为之踌躇满致”,赶紧写一篇报告,发给全公司看,非常开心。最后,“善刀而藏之”,也就是要清理实验代码。

Mobile Growth的机会和挑战

在 Mobile 里面,Growth 的概念一样可以使用。只不过平台不同,会有一些特别的挑战和机会。在Mobile上面很难做跨链接,很难做属性,很难快速迭代,因为有发布周期的要求,也很难去做一些 A/B test,而且还有下载的障碍。这是 Mobile 独有的挑战。

同时,Mobile 里面有一些独特的机会。手机是一个个人的设备,手机打开一个 Square,基本上可以知道你这个人是谁。可以长期跟踪一个用户在这个平台的很多操作。 从产品设计的角度来讲,也不需要登录,这点也是不错的。

第二,设备即入口,打开手机, App 已经在那里了。不再受到搜索引擎的钳制,只需要通过用户习惯就好。第三,设备即通道,App 在手机上,就打开了服务用户的沟通通道。这个通道是驻留的,你可以通过它找到你的用户,而这在Web 上是不存在的。

User Onboarding顶层思路

Growth

User Onboarding 非常重要。用户获取到了,准备下载这个 App,这时候就是User Onboarding 的起点了。如果你熟悉这个图,说明你已经有一定的 Growth 的基础,这是最典型的 Funnel Analysis(漏斗分析),把用户的量作为指标,然后按照这个流程来进行分解。

可以看到,每个大红柱,相当于一次用户丢失。假如有100%的用户在起点位置,可能只有一半用户会下载App,经过登录页面,有少量用户丢失。注册这一步需要用户提供身份信息。搜集完信息之后,让他体验产品最核心的功能。然后第二次使用、第三次使用,一直到付费阶段。

在这个流程里面,用户数量是递减的。一个最基本的 Growth 方法就是,去看你的用户在每一步产生了多大的递减,做一些相应的优化 ,把一部分用户挽回回来。

用户到底有多大的意愿去下载App?可以在下载页面去做一些 ASO,比如,测试用什么样的图、什么样的标题更吸引人。可以去做一些很精准的评估,一个比另外一个到底好多少,好在哪儿? App 本身的大小也会影响下载意愿。

再比如,支持匿名来减少用户在注册时候的流失。也许因为需要输入 email,用户就不愿意继续了。可以考虑取消、推迟注册,或者接入第三方,比如微博、微信,通过这种方式来减低登录的难度。搜集信息的过程中,把需要手动输入的变成选择,把能猜的猜出来。通过了Aha Moment,也许下次他会想不起来这个App 而丢失了用户,这个时候就要推送一些信息。在真正付款的时候,因为付款流程做得不好,或者用户觉得这笔钱太多了,他也会放弃,所以要提供更灵活的付款方式。

这就是在Onboarding 里面如何做漏斗分析的最典型的方法,可以找到一些优化的办法。

漏斗分析是非常基础、非常有用的工具。但是它有它的问题。第一,建立了一种和用户对立的心态:不管你的产品做得再好,用户总是会离开。就像登录页面做得再好,用户数量还是会降,Aha Moment做得再好,用户数量还是会降。跟用户不一样,产品设计者在看漏斗分析的时候,是基于统计的角度,而用户并不是用统计的方式留存的。

第二,当大问题解决得差不多,就开始专注解决这些小流失,这些小流失可能很大程度上是因为性能的问题,Growth 就慢慢变成了性能优化。第三,用户不愿意付款,不一定是因为付款页面做得不好,很可能是因为他觉得不值这个价,而这个问题,你没法通过漏斗分析来解决。

硅谷

我建议的一个方式是,你要从用户的视角去看流程。这里面横轴依然是流程,纵轴变成用户用这个App有多少的意愿,这个意愿大致用了一个数字来描述。首先,假设意愿都是100,这个时候,用户需要耗费他的意愿去下载。用户来到了登录页面 ,如果登录页面提供了好的信息和材料,用户会对未来有更多的期待,或者想对产品了解更多,他的意愿可能会上升。

用户在注册和激活的过程中依然是降的,但是如果你的Aha Moment做得好,再次调起他的兴趣,可以重新激起他对后面的付费行为有更多的意愿。如果产品体验做得好,每一次的使用行为都可以积累意愿,最终支撑一次变现。一个好的产品,在这条思路下,会一直思考用户到底怎么想。

从这条思路可以推导出另外一套优化方法:是不是可以做一些正向的改进。首先在登录页面上可以做一些优化。比如,讲清楚App到底对你有什么价值,把推荐人的头像信息放进来,提供上下文,让推荐的社会信用变成App本身的吸引力。如果做2B的产品,需要搜集身份证号、电话号码,或者企业信息,用户可能在这个过程中没有准备好,那么可以在登录页面告诉他,“需要准备这些信息再开始注册”,避免用户在流程的一半卡住而流失。

在整个激活的过程中可以给一些引导和解释。比如,为什么需要电话号码,并不是要把个人信息卖给下家,而是要在你的业务出问题的时候快速找到你。需要强调和解释“对用户的价值”,这个“价值”很多时候,你在设计产品的时候其实已经考虑到了,所以在设计流程的时候就也要考虑怎么呈现出来。比如,在做Aha Moment的时候,需要强调让用户感觉到自己得到了价值;做一些比较有趣的动画,甚至实质性的奖励,能够提升用户的兴趣。Aha Moment是一个重要节点,这里可以提高很多用户的兴趣。

完成了第一个最关键的功能之后,要对其他新功能做引导,在合适的时机把功能推送给用户,以至于用户还有兴趣继续使用。谨慎地请求访问,避免让用户感觉不舒服。在收费之前,对收费的功能到底干什么,通过收费能够得到什么价值,还有别的用户在收费之后得到了怎样的利益,对他的企业有什么帮助,可以逐步预先展示给用户。这些都是在为收费做准备。

硅谷

User Onboarding 有两个关键点:一点就是传输价值,要让用户看到价值在哪儿;另一点是除去痛点,需要去除用户在流程中遇到的痛点。如果能正确做到这两点,是非常好的Onboarding体验。还有第三点,在 Onboarding 的时候,要建立一条通道,比如让用户允许推送通知,以便于之后引导他去使用更多新功能。

Mobile Growth 关键技术

 

下面讲 Mobile Growth 的几个关键技术。从上往下看,  Growth 是一个非常复杂的流程,用到的技术也非常驳杂。这里将其中一些最重点、最关键的部分提出来讲一下。

硅谷

这里有一份来自Mobile Growth Tech Stack的总结,作者大概每年都会总结一下,今年有哪些技术趋势,罗列得非常细致,也许只有特别大的公司才会使用其中的很多部分,但的确是一个很好的总结。

A/B testing系统搭建

硅谷

第一个是 A/B test 。以前修电脑有一个概念,电脑坏了,到底哪儿坏了,把内存拔出来,换一个内存,如果系统修好了,那么就是内存坏了。在分析产品流程的时候可以采取同样的思路。设计一个叫做分组器的机制,分组器告诉产品:让这个用户去实施行为A,让那个用户去实施行为B。通过数据分析看出来,实施A的用户下游行为好还是B的好,能够好多少。这个就是最基本的 A/B test。

硅谷

分组器和产品之间,交流“A还是B”,这个就是 A/B test 系统中最基本的部分。再增添一些“细节”,就是可以规模使用的 A/B Testing 系统了。图中这些绿色的组件就是所说的“细节”。分组器告诉产品怎么分组,分组结果和下游行为通过“埋点”进入Log,Log 需要进行处理。Log处理之后,一方面用于指导下一次的实验流量分配,一方面是用于计算指标。

这个指标可能会向实验的设计者、产品经理或者工程人员,形成一个图表,展示在面板上。数据人员可能需要一些额外的深度分析指标的工具。实验配置工具是配置实验的入口,这个系统既决定了分组器怎么分组,也决定了最终需要计算哪些指标,还跟流量分配有一些关系。QA 测产品的时候,可能需要精确控制在一次测试中的实验行为是A还是B。

这是一个比较复杂的多方系统,想要一次全部写对比较困难。幸好大部分时候不需要考虑太多的技术细节,很多第三方的工具会帮你完成整个流程。

对于A/B test 系统,更多的不是技术上到底怎么去写,而是怎么选择和使用。如果要设计一个系统,或者评价一个A/B test系统,首先需要考虑两个内容,第一是核心,第二是优化。

黑客

核心的部分是“一个A/B test 的 MVP 到底需要哪些条件”,优化是说扩展方向。避免伤害用户体验,这是最基本的要求。在决定选择A还是B之前,发出一个请求,这个请求最迟要5秒才返回,整个界面都停止,这当然伤害了体验。比如,后端不小心改了实现,发回来一个不规整的响应,这时候客户端报错说,“非法的实验分组数据”,这当然也是对用户体验的伤害。一个系统出了故障,能不能回滚到正确的产品行为,优雅处理,让用户不知道,这个是最基本的要求。

其次,统计有效。到底怎么设计实验或者怎么评价实验的结果,有一些统计上的具体要求。比如,是不是做到了真正的控制变量,实验的设计是不是对A组或者B组有天然的 偏见,对统计结果是否存在主观误读,实验之间有没有交叉影响,实验有没有新鲜感效应或者上手期,等等。做实验涉及很多统计知识,才能正确地设计和分析,A/B test 系统要基于正确的统计假设来计算、判断和展示结果。

黑客

这个系统的“优化”里面还有非常多的细节,比如,性能方面的考量,扩展性方面的考量等。

Deep-link的趋势和使用

黑客

Deep-link在国内很火。比如有这样一个场景,在百度上搜了一个新闻关键词,条目是某新闻 App 提供的,点击这个条目,结果打开了某个新闻 App,并且把这个具体的新闻页推送给我,这就是 Deep-link。换句话说,可以从 App 外面直接跳转进去,发现App里面某个深度内容页面,这就是Deep-link。

黑客

在一些复杂的情况下,有一个叫做 Deferred Deep-link的变体,可以在 App 没有预装的情况下实现类似的效果。这在技术上做起来没那么简单,但是依然可以实现。从图中可以看到效果还不错,减少了一些步骤,每个步骤原本都有用户流失。

黑客

Deep-link的实现细节,这里不仔细讲了,很多第三方的工具可以帮你实现。原理上比较简单,通过一个短链接,把参数存在第三方服务器里面,使用这个链接的时候,会询问第三方,通过指纹匹配取回参数。原理不是特别复杂,但是实现起来比较难。

黑客

另外,我最想讲的是:Deep-link 对产品设计和 Growth 会带来什么影响?

首先,它解决了跨链接和属性的困境。特别是在iOS上,你进入 App Store,本来所有的参数全丢了,但是 Deferred deep-link 可以帮你再找回来。

第二,它改变了 App 只能从 App Store 中得到的现状。使用Deep-link 之后,传统的搜索引擎或者内容门户网站也可以变成 App 的入口了,这很有利于以内容为主的 App 来进行病毒式传播。

最后,是入口多样化和业务的切片化。App 的入口不再仅限于下载、点击App 图标、注册、使用。从某个具体内容或者某个子功能进来的用户期待短平快的流程,快速进入感兴趣的内容。是否要对这些新的入口做单独的优化,这会是新的问题和机会。

这种改变同时代表了“业务流程切片化”的趋势。这种趋势告诉我们,把一个大而全的 App 直接推到用户面前可能不是一个好的选择。Facebook 的主App有 100+MB,基本上包含了所有功能,但是可能今后的 App 会设法避免这种情况,因为下载这样的一个 App 对用户来说是一个负担。

一个 App 有几个不同的业务入口,每个业务对应有一个相对独立的模块,甚至子 App,或者像谷歌的即时App 倡导的那样,只装载一个小的 App 功能切片,在这个切片里实现简单的功能,再推销整个全功能的App。这样的做法可能会成为趋势。

这种趋势不仅是一个外部的切片化,也是内部的切片化。即使不考虑外部怎么接入,你在 App 的内部也可以做切片化。手机 App 的一个很大的特点是屏幕小,分区多。设计产品的初期总是希望流程是清楚、专注、不被干扰的。但是到了后期,功能多了之后,又希望流程之间的跳转更灵活一些。

一个折中的方案可能是,把每个业务流程起点设置成一个Deep-link目标,这样跳转操作可以用一个 URL 精简地表达,既可以方便跳转,也不用泄露太多实现细节。这种内部的可跳转性,有助于灵活地做Growth。

Growth中的内容动态化   

Growth

动态化是一个很大的话题,但是这里我们只讲一件事,就是 Growth 的眼中怎么看动态化。

Growth 眼里的动态化,并不是一个大而全的系统,比如 React Native。Growth 考虑的最多的问题就是,用最小的代价来实现一件事情。我们看一个功能开关,on/off,是动态化;动态内容填入静态模板,是动态化;可动态调整组件来构建的页面,是动态化;一个业务模块的流程可以从服务器端获取,也是一种动态化。在考虑动态化的时候,会有一个权衡,具体的用例到底要用什么办法来实现。如果只需要改一个标题就可以实现,何必要上 React Native。

高度的动态化牺牲了可测试程度,也提高了使用时需要的后期资源。功能开关是不需要后期资源的。内容模板至少需要一个写作者的参与。具体的可拼装页面就需要设计者来设计。如果讨论动态流程,可能 UX 和 PM 都要跳进来问:这个流程是不是科学,是不是符合我们产品的理念。React Native 搭建的动态结构,在使用的时候,可能需要整个开发团队都参与进来。既然Growth 讲成本效率,动态化也要讲效率,即用最小的代价去做你想做的事情。

总结

 

Growth是真实存在的,在硅谷被广泛使用,并且现在已经来到中国。有很多客观原因导致在中国没有使用起来。但是现在条件已经逐渐成熟了,比如竞争激烈导致的对各种效率的要求。最终你一定要用 Growth,唯一的忠告是,不要急于做出一个大而全的系统,可以选择第三方工具,可以选择定制的逐渐演进的系统。因为,用最小的代价完成最大的事,才是Growth的核心所在。

 

文/邵震

文章出处:InfoQ

本文链接:https://www.yunweipai.com/8210.html

网友评论comments

发表回复

您的电子邮箱地址不会被公开。

暂无评论

Copyright © 2012-2022 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部