节点六: 如何组织阶段性的价值交付?

架构系列课专栏目录总览

上节课我们讲了为什么要做阶段性的价值交付,以及进入阶段性价值交付环节的准备工作。有了这些学习基础,这节课我们就可以进行阶段性价值交付了。

在交付的过程中,主要有三部分工作:目标分解、定义交付路径,以及项目交付跟踪和路径调整。

从价值交付的角度做 MVPU 拆分

关于目标分解这部分工作,我们需要从多个维度来进行。

首先是商业价值的视角。这个项目能为企业带来哪些重要的商业价值呢?度量这个商业价值的核心指标是什么?比如一个大促项目,比较重要的指标有 GMV、总订单数、总成交客户数、首次下单客户数、超过一定体量的成交商家数等。

其次是用户价值的视角。这个项目能为用户带来什么重要的价值呢?相应的指标是什么?同样是大促的例子,常规的度量用户价值的指标有新买家数、买家满意度、成交用户总数等。

近年来,国内大促项目的用户心智变得越来越淡,我认为核心原因就在于架构师很少关注用户价值的相关指标。大促购物真的有那么高的满意度吗?与去年相比,今年的订单件数、订单金额和访问频次有增长吗?

最后是技术价值的视角。这个项目能为企业带来哪些重要的技术价值?相应的指标是什么?同样还是大促的例子。每秒峰值订单数、机器人会话转人功率、大促会场转化率等,都是对企业技术能力的度量。

除此之外,还有一些其他的附加价值,比如商家增长、全链路履约容量提升、市场渗透、人才培养、技术影响力、企业的社会形象等。这些附加价值,往往不是我们发起项目的主要目的。不过有了这些附加价值,我们就可以从不同的价值维度上对项目做 MVPU 的拆分了。

有时候一个大促要准备好几个月,像阿里这样的公司,细分项目的数量都是以千计。但是细分到单个维度和单个场景,MVPU 就简单许多,比如通过一个反向招商的项目来提升 GMV。所谓反向招商,就是根据最近成交的订单,选取销量和满意度较高的商品。然后邀请这些商品背后的商家参加大促,将商品拿到大促上打折售卖。

平台呢,将会有一套数据驱动的商品圈选逻辑、一个活动报名页面,还有相关的商家推广计划,同时也会对预期的 GMV 贡献有一个估算。

不过这个估算有两个比较大的不确定性:

商家的意愿。有多少商家愿意把自己的爆品拿到大促上做深度的打折售卖?

用户的意愿。这些商品是否属于小众商品?小众商品意味着转化率在特定人群中较高,一旦放到大促主会场面对所有买家做推广,转化率就不一定能保障。

不过想验证这两个 MVPU,也没那么复杂,甚至都不需要开发商家的活动报名页面。只需要通过调研问卷的形式,就可以估算商家的参与意愿和最大折扣力度。而用户意愿,可以通过开发定制化的活动页面,给不同的用户群分别做投放,从而预测转化效率。

这是个常见的投放逻辑,开发这种定向的活动页面和相关的后端应用,在大促之外的其他场景下也可以复用。

同样,你可以用类似的逻辑来拆分会话机器人的项目,找到对应的 MVPU。反向招商项目和会话机器人项目完全不干扰,可以各自以独立的进度来做 MVPU 验证。事实上,大多数项目都是可以独立做 MVPU 拆分的,不需要和其他项目耦合。当然也有特殊情形,比如订单中心的研发可能跟很多项目都形成了耦合。不过即便如此,我们还可以分批次上线。

你可能会有疑惑,大促本来就是一个聚合型项目,这么做当然可以了。但如果是更底层的技术项目,比如多个 BU 之间的数据模型统一的项目,那该怎么办?在没统一之前,怎么度量统一之后的价值呢?其实这种架构统一的项目更好拆分,可以先在风险小、回报大的场景上做统一。一方面,参与方的动力足;另一方面,MVPU 的成本也低。

等做出来一两个案例并确认回报后,就可以固化方案和工具,并加速推广了。越做到后面,你的技术方案越健壮,接入就越容易。这时候不仅得到的回报变低了,实现成本也会降低,最终会得到一个比较高的渗透率。

反倒是一上来就起一个全员都参与的大项目,成本高、压力大,失败的概率也更大。在真正的竞争压力面前,这种 ROI 最大化的路径,是我经历过的最有效的项目推进方法。 那种高举高打的方法,最终能获得预期效果的反倒不多。

假设你找到了多个维度的 MVPU 的目标和 KPI,那么下一步就要发挥你的架构师能力,来定义好交付路径了。

交付路径设计

架构师的价值就在于保障整个架构活动的结构性,以及交付顺序的合理性。因而在不破坏整体结构的前提下,我们需要尽早交付 MVPU。主要有如下三件事需要做:

梳理强依赖关系;

控制联调的成本和节奏;

把握速度和结构性之间的平衡。

如下图所示。多个 MVPU 和功能模块之间形成了网状关系,一个 MVPU 是它所有强依赖的组合。很明显,这是一个树结构的遍历问题。

顺便说一句。正如我在第 xx 讲分享的性能优化的案例。我个人喜欢先做 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 却是可以独立存活的,从而减少项目的浪费。

在这种交付方式之下,我们是随着时间逐渐交付用户价值的,而不是把所有的系统集成置后,在架构活动交付的最后期限才来一个系统大集成。在互联网时代,这么做的好处是显而易见的:给自己和团队赢得了宝贵的试错机会和调整方案的时间。

原本这应该是项目交付的一个基本原则,但国内的大公司却很少这么做。原因很简单,很多大公司设定的项目交付日期本来就不合理。排期就是一个决策者一句话压下来的,所有人都知道完不成,但大家都认为自己团队可以逃脱木桶最短板的命运。所以人人都硬着头皮接了下来。

结果就是无论团队任务重不重,能集成的最早日期,就是整个架构活动的上线日期。日子一到,多数团队都没有准备好,所以一上线就掉链。这种做法的伤害极大,不仅影响整个项目,还会破坏公司的整体文化。

通过这节课,我期望你能意识到最小价值交付单元方法的优势,也希望你能在自己主导的项目中认真尝试一下。我相信它会带给你不一样的惊喜!

免责声明:
1.本站所有内容由本站原创、网络转载、消息撰写、网友投稿等几部分组成。
2.本站原创文字内容若未经特别声明,则遵循协议CC3.0共享协议,转载请务必注明原文链接。
3.本站部分来源于网络转载的文章信息是出于传递更多信息之目的,不意味着赞同其观点。
4.本站所有源码与软件均为原作者提供,仅供学习和研究使用。
5.如您对本网站的相关版权有任何异议,或者认为侵犯了您的合法权益,请及时通知我们处理。
火焰兔 » 节点六: 如何组织阶段性的价值交付?