你好,我是郭东白。上节课我们讲了为什么要做阶段性的价值交付,以及进入阶段性价值交付环节的准备工作。有了这些学习基础,这节课我们就可以进行阶段性价值交付了。
在交付的过程中,主要有三部分工作:目标分解、定义交付路径,以及项目交付跟踪与路径调整。
从价值交付的角度做MVPU拆分
关于目标分解这部分工作,我们需要从多个维度来进行。
首先是商业价值的视角。这个项目能为企业带来哪些重要的商业价值呢?度量这个商业价值的核心指标是什么?比如一个大促项目,比较重要的指标有GMV、总订单数、总成交客户数、首次下单客户数、超过一定体量的成交商家数等。
其次是用户价值的视角。这个项目能为用户带来什么重要的价值呢?相应的指标是什么?同样是大促的例子,常规的度量用户价值的指标有新买家数、买家满意度、成交用户总数等。
近年来,国内大促项目的用户心智变得越来越淡,我认为核心原因就在于架构师很少关注用户价值的相关指标。大促购物真的有那么高的满意度吗?与去年相比,今年的订单件数、订单金额和访问频次有增长吗?
最后是技术价值的视角。这个项目能为企业带来哪些重要的技术价值?相应的指标是什么?同样还是大促的例子。每秒峰值订单数、机器人会话转人工率、大促会场转化率等,都是对企业技术能力的度量。
除此之外,还有一些其他的附加价值,比如商家增长、全链路履约容量提升、市场渗透、人才培养、技术影响力、企业的社会形象等。这些附加价值,往往不是我们发起项目的主要目的。不过有了这些附加价值,我们就可以从不同的价值维度上对项目做MVPU的拆分了。
有时候一个大促要准备好几个月,像阿里这样的公司,细分项目的数量都是以千计。但是细分到单个维度和单个场景,MVPU就简单许多,比如通过一个反向招商的项目来提升GMV。所谓反向招商,就是根据最近成交的订单,选取销量和满意度较高的商品。然后邀请这些商品背后的商家参加大促,将商品拿到大促上打折售卖。
平台呢,将会有一套数据驱动的商品圈选逻辑、一个活动报名页面,还有相关的商家推广计划,同时也会对预期的GMV贡献有一个估算。
不过这个估算有两个比较大的不确定性:
- 商家的意愿。有多少商家愿意把自己的爆品拿到大促上做深度的打折售卖?
- 用户的意愿。这些商品是否属于小众商品?小众商品意味着转化率在特定人群中较高,一旦放到大促主会场面对所有买家做推广,转化率就不一定能保障。
不过想验证这两个MVPU,也没那么复杂,甚至都不需要开发商家的活动报名页面。只需要通过调研问卷的形式,就可以估算商家的参与意愿和最大折扣力度。而用户意愿,可以通过开发定制化的活动页面,给不同的用户群分别做投放,从而预测转化效率。
这是个常见的投放逻辑,开发这种定向的活动页面和相关的后端应用,在大促之外的其他场景下也可以复用。
同样,你可以用类似的逻辑来拆分会话机器人的项目,找到对应的MVPU。反向招商项目和会话机器人项目完全不干扰,可以各自以独立的进度来做MVPU验证。事实上,大多数项目都是可以独立做MVPU拆分的,不需要和其他项目耦合。当然也有特殊情形,比如订单中心的研发可能跟很多项目都形成了耦合。不过即便如此,我们还可以分批次上线。
你可能会有疑惑,大促本来就是一个聚合型项目,这么做当然可以了。但如果是更底层的技术项目,比如多个BU之间的数据模型统一的项目,那该怎么办?在没统一之前,怎么度量统一之后的价值呢?其实这种架构统一的项目更好拆分,可以先在风险小、回报大的场景上做统一。一方面,参与方的动力足;另一方面,MVPU的成本也低。
等做出来一两个案例并确认回报后,就可以固化方案和工具,并加速推广了。越做到后面,你的技术方案越健壮,接入就越容易。这时候不仅得到的回报变低了,实现成本也会降低,最终会得到一个比较高的渗透率。
反倒是一上来就起一个全员都参与的大项目,成本高、压力大,失败的概率也更大。在真正的竞争压力面前,这种ROI最大化的路径,是我经历过的最有效的项目推进方法。 那种高举高打的方法,最终能获得预期效果的反倒不多。
假设你找到了多个维度的MVPU的目标和KPI,那么下一步就要发挥你的架构师能力,来定义好交付路径了。
交付路径设计
架构师的价值就在于保障整个架构活动的结构性,以及交付顺序的合理性。因而在不破坏整体结构的前提下,我们需要尽早交付MVPU。主要有如下三件事需要做:
- 梳理强依赖关系;
- 控制联调的成本和节奏;
- 把握速度和结构性之间的平衡。
如下图所示。多个MVPU和功能模块之间形成了网状关系,一个MVPU是它所有强依赖的组合。很明显,这是一个树结构的遍历问题。
顺便说一句。正如我之前分享的性能优化的案例。我个人喜欢先做ROI最大的项目,投入少、验证简单,未来还可以逐步投入人力再做工具的打磨和优化。在这个过程中,我一般不太考虑风险的大小。我的逻辑是,高回报永远伴随着高风险。既然迟早都要面对风险,还不如早点面对,这样自己还能有更多的思考时间,避免走太多弯路。
如上图所示。1是整个架构活动的目标,a、b、c是三个MVPU,它们各自依赖的交付任务由带箭头的线来表示。比如对于MVPU a来说,任务2是它的强依赖,而任务3是它的弱依赖。
一个MVPU是一个树状结构,比较容易计算总交付成本和交付时长。其中c节点与整个架构活动的目标无关,它只是附属在架构活动上的一个“小确幸”,不应该作为MVPU的选择。如果说一个节点始终没有通向节点1的路径,那么这些节点可以看作技术的自嗨任务,应该砍掉,或者作为低优先级任务。
如果要交付MVPU,那就需要跟团队同学提前做联调。很多技术同学非常讨厌中途停止编码去配合其他团队做联调,所以我们不能把MVPU的交付做得过于频繁。我的建议是在两周到一个月之间。因为大项目的联调成本很高,交付过于频繁会打乱研发节奏。但是如果超过一个月还没有交付任何的MVPU,积攒的风险就会变得很高。
最后是把握速度和结构性的平衡。还是拿性能优化的项目来举例。我们第一个MVPU的交付完全没有考虑结构性,只想看清楚价值是否成立。确定价值成立后,我们才开始设计更稳定的架构。
当然,如果是个重构项目,这么做就有点激进了。整个架构活动的结构性和价值交付,跟我们确定的交付路径的价值最大化,就是一对互相冲突的矛盾。在互联网企业里,架构师始终面临一个现实的问题——架构活动是随时可以被抢占的。事实上,的确也应该被抢占。所以这两个目标之间是在博弈。
也就是说,在一个MVPU带来的小确幸、项目的整体结构性、最终目标这三个选项中,哪个更重要?关于这个问题,我们在法则一就给出了答案:先提升最终目标的成功概率。
如果只有一份资源,那么到最终目标最短路上的强依赖必须要先完成。而那些与最终目标没有形成依赖关系的小确幸,只能算是附加提案,是大架构活动的一个伪需求,应该舍弃。至少不需要放在你的注意力范围之内。
交付跟踪与路径调整
在交付的过程中,你还需要跟踪每个任务的进度,把实际观察到的结果跟MVPU的目标反复做校准。任务进度的跟踪属于项目管理层面的问题,这里不做更多的解释。我们主要讨论MVPU的目标达成情况。
多数时候,你会发现目标没有达到预期,这是很正常的。我们的假设往往过于乐观,逻辑也不够严谨。这是个非常重要的决策点。因此我们必须寻找目标不满足预期的原因,看看问题出在哪里,是否有解。
比如用户转化率远低于预期,那么研发人员、 BI分析师、用户调研员、市场分析师都可以来帮忙寻找根因。在这个过程中,技术人员可能会发现设计和算法实现的问题,营销人员可能会发现营销发案的设计问题,用户调研人员会发现用户群的定位偏差,等等。不过无论如何,这个排查过程都会影响交付的进度,这也是为什么有些项目选择不做拆分的理由。
不过我们既然选择了分阶段交付,那么这些排查就是有必要的。举个例子,我曾经经历过一个叫SABbc的项目。控货商A从供应商S那里拿货,卖给跨境的进口商批发商B。批发商B再卖给零售商b,最后零售商b卖给了终端用户c。
这么长链路的商业模式,注定了会失败。不过在老板的压力下,大家还是硬着头皮冲上去了。项目Owner还是比较聪明的,他先做了S2A的环节,很快就发现找不到愿意拿货的控货商A。因为这是一环套一环的长链路,其中一环失败了,整个链路都会失败。不过老板还是坚持继续尝试,只不过尝试的范围和投入都大幅缩小了。
结果呢,好几百人日的大项目,最终上线跑了两个多月,得到的订单收入还不够给参与项目的研发人员每人买一杯咖啡。不过,也多亏项目Owner先做了S2A的环节。虽然项目失败了,但最终的浪费比之前的规划小了一个倍数。
这个例子比较有代表性。在一个大公司里,哪怕做分阶段的交付,也很少有架构活动会在一个MVPU上线效果不满足期望的时候,选择立即停下来。大多数时候,在一些人员排查问题时,项目组的其他成员还在持续交付。你可能会问,既然这样,为什么还要耗费时间做分阶段交付呢?
因为这个发现和后续排查的动作,其实给了整个决策团队一个调整的机会。很多因素都会影响项目的结果,比如用户没有意愿,或者是商业模式不成立。这两种情况非常棘手,要做大范围的目标或产品方案的调整。
但是其他因素,比如产品细节和技术实施问题、竞争对手的干扰、合作伙伴出现问题和用户恶意行为等,都有很多应对方案。 越早发现问题,就越有时间来调整,从而提升最终的成功概率。
比较好的例子是与第三方供应商深度合作。如果在项目初期就请一两个供应商参与,以最简易的方式完成集成,然后迅速进入试运营,那么考虑不周的设计很快就会暴露出来。这么做,虽然会延长整个项目的交付时长,但是重大风险,在全面上线之前几乎都排查得差不多了。
这里有一点需要稍微注意一下。架构师往往没有权力去调整整体的项目计划和上线节奏,一般要由决策者来拍板。
完成阶段性交付
整个交付过程就是逐个遍历之前的MVPU树,最终完成整个架构的目标。我们已经描述得很清晰了,这里就不再赘述。
小结
我们这节课讲了怎么从架构师视角来组织阶段性的价值交付。这个过程,其实在最大程度上保护了活动参与者和赞助者的利益。哪怕架构活动不能满足预期,但是一个真正有价值的MVPU却是可以独立存活的,从而减少项目的浪费。
在这种交付方式之下,我们是随着时间逐渐交付用户价值的,而不是把所有的系统集成置后,在架构活动交付的最后期限才来一个系统大集成。在互联网时代,这么做的好处是显而易见的:给自己和团队赢得了宝贵的试错机会和调整方案的时间。
原本这应该是项目交付的一个基本原则,但国内的大公司却很少这么做。原因很简单,很多大公司设定的项目交付日期本来就不合理。排期就是一个决策者一句话压下来的,所有人都知道完不成,但大家都认为自己团队可以逃脱木桶最短板的命运。所以人人都硬着头皮接了下来。
结果就是无论团队任务重不重,能集成的最早日期,就是整个架构活动的上线日期。日子一到,多数团队都没有准备好,所以一上线就掉链。这种做法的伤害极大,不仅影响整个项目,还会破坏公司的整体文化。
通过这节课,我期望你能意识到最小价值交付单元方法的优势,也希望你能在自己主导的项目中认真尝试一下。我相信它会带给你不一样的惊喜!
思考题
三个思考题,任选一个作答。
- 你有没有碰到非常成功的MVPU?这个MVPU为企业带来了哪些价值呢?
- 有的项目自始至终都没有度量过商业价值、用户价值和技术价值。你参与过这种佛系的项目吗?参与这种项目的感受是什么?轻松、意外,还是失落?
- 请你估算一下,在你参与过的项目中,MVPU占项目总投入的比例大概是多少?可以描述一下项目背景,并给出以人日计算的大致成本。