宋小菜有关“能力”的设计和思考

郑舒天 发布于 2018/06/22

如果你仔细观察过宋小菜技术同学的日常工作,你就会发现他们很喜欢谈论一个词,那就是“能力”。无论是在系统架构规划的时候、技术方案设计的时候、开发问题探讨的时候甚至 PRD 评审的时候,“能力”这个词会不停地出现在他们的口中。是什么原因,使得这个词这么频繁的出现在开发小伙伴的交流中呢?

一、什么是“能力”

在详细介绍什么是“能力”之前,先卖个关子,想先给大家介绍另外一个词——VUCA 时代(乌卡时代)。
VUCA是四个单词的首字母组成的新词,分别是 volatility(易变性)、uncertainty(不确定性)、complexity(复杂性)、ambiguity(模糊性)。VUCA 最早出现在军事用语中,但是现在这个词越来越频繁的出现在我们的日常生活中了,原因就是人们发现,这四个词实在是太符合我们现在的社会和时代了。我们的生活、工作、社会以及这个高速发展的时代,不就是充满了易变性、不确定性、复杂性和模糊性吗。

回到技术同学的日常工作中,大家就会惊奇的发现,我们接到的需求、产品方案、视觉稿、运营计划甚至习以为常的框架技术、依赖的服务、使用的中间件工具,不也充满了 VUCA 的特质吗。所以在这里非常想和技术的同学(特别是处于创业公司,业务正处于高速发展的的公司)说一句,不要再沉迷于“打死不改版 PRD”或“再改就杀一个设计师祭天版 UI”的骂战或争吵中了。因为当你回过头 review 的时候就会发现,所有骂战和争吵的结论一定是“该变还是得变”。原因其实很简单,VUCA 是我们这个时代所具备的特点,如果我们不去适应他,而是想尽一切办法去抵抗他,这是一件非常不划算的事情,而且往往你的努力会变成徒劳。

介绍了这么多有关 VUCA 的思考,是时候引出“能力”这个词了。因为我们发现,无论公司的方向变化的有多么快,或是死掉的业务数不胜数,还是创新性的项目一个接一个的诞生,总有一些是相对不变的,并且可以被我们沉淀下来的东西,那就是“能力”。这样介绍,可能还是比较抽象,接下来举两个例子,可能大家就会有些感知了:

  1. 随着业务发展,公司有越来越多的系统或者应用了,每个系统总是需要有登录流程的。一开始登录流程可能全都是独立的,A 系统有一个登录流程(使用邮箱+密码登录),B 系统有一个登录流程(使用动态短信登录),C 系统有一个登录流程(使用登录名+密码+验证码登录)。这个时候我们就发现“能力”了,登录流程,就是我们需要沉淀的“能力”。因为登录流程是可以被枚举完的,并且某一种登录形态一旦被固化下来了,就可以快速的输出给其他的系统使用(高度复用),如下图所示:

image1.png | center | 517x199

  1. 业务总是多样和复杂的,X 业务中有一个场景需要邮件通知主管审批,Y 业务中有一个场景需要短信通知销售某个客户已经下单,Z 业务中有一个场景需要 push 给客户优惠券马上要到期了。这个时候我们又发现“能力”了,消息通知中心,就是我们需要沉淀的“能力”。和第一个例子一样的思考方式,因为通知的途径是固化的,并且某一种消息通知的途径一旦被沉淀下来了,就可以快速的输出给其他的业务场景使用(高度复用),之后这些消息通知的能力,还可以组合使用,如下图所示:

image2.png | center | 508x192

看了上述两个例子的介绍,很多技术的同学会觉得,这些不是很正常吗,在我们的公司里不就是这样设计的吗。举这两个例子,并不是想给各位介绍多么高深的技术方案,而是想把“能力”这个词讲透。因为“能力”的设计更像是一种思维模型,即“将抽象和稳定的向下沉,将多变和不确定的往上浮”。这个思维模型,无论是在接口编写、架构思考、技术方案设计甚至日常的生活工作中,都会起到很大的帮助,并且也是适应 VUCA 时代的有利技巧。

二、设计“能力”的关键点

1. 分清“业务”和“能力”

很多刚毕业的同学或是工作经验尚浅的开发同学,在接到一个需求或任务时,往往会犯一个通病,是什么呢?就是不能很好的区分“业务”和“能力”。他们往往“只面向业务编程”,请注意,在这里提到的是“只面向业务编程”,重点是这个“只”字。好多开发同学一边听着产品经理描述需求和功能,一边脑子在飞快运转。需求评审结束,脑海里已经充满了表结构的设计和字段的含义了,要不是还没确定开发分支,都认为自己已经进入开发阶段了。这里有一句玩笑话“没有什么问题,是加一个接口或者加一张表不能解决的,如果有,那就加两个。”讲到这里,是不是会引起很多开发同学的会心一笑,这个阶段估计所有的程序员都经历过。

为什么我将这个问题总结为——不能很好的区分“业务”和“能力”呢。就像刚才提到的,其实关键是因为没有形成那样的思维模型,即“将抽象和稳定的向下沉,将多变和不确定的往上浮”。“业务”拥有的最多标签,就是易变的、模糊的、不确定的,这是“业务”天生就具备的特质。很多时候,运营同学也是边跑边摸索,还一边修正运营的战略战术,这个情况在创业公司中,就更加明显了。这时候如果技术同学在开发过程中不加思考,开发起功能来兵来将挡水来土掩,不停地加表不停地加接口,可想而知,如果长此以往结果将会多么可怕。这也是宋小菜业务高速发展了三年,我们犯过的错误,也给我们带来了长足的思考。举一个我们犯类似错误的例子:

因为业务发展快速,越来越多的角色被纳入到我们的业务链路当中,比如有“交易客户”、“供应商”、“司机”、“囤货商”等等。因为不同的项目组承接了对应的需求开发,所以设计出来的结果可想而知,只能用“非常贴近我们的业务”来形容了。后面遇到了什么问题呢,比如随着业务变化,用户的身份是会多样化的,比如有的用户可能既是“供应商”又是“司机”,有的用户身份既是“供应商”又是“囤货商”等等。这时候问题就来了,“我怎么知道他到底有几个身份呢?”、“有的身份需要能登录系统 A,有的身份需要登录系统 B 和 C,有的身份不需要登录我们的系统,到底要怎么控制呢?”

其实在我们系统中出现两三个身份后,按照刚才介绍的思考方式,我们的心中就应该敲响警钟了,是时候是要做“业务”和“能力”的区分了,以便让“能力下沉,业务上浮”。我们根据业务的抽象,沉淀了用户中心的“能力”,其中包括了账户体系、用户体系和身份体系,并以相对抽象的“属性”和“标签”的扩展能力对外输出,以此来支持高速的业务变化。

2. 不要一开始就谈“能力”

当开发的同学们慢慢理解了“能力”的作用和价值的之后,往往又会带来一个新的问题,那就是一开始就谈“能力”。“能力”并不是空想出来的,他一定是经过了一些业务形态的观察和抽象,才能被沉淀出来的。比如一上来就谈“我们先做一个库存中心,反正我们是电商模式,一定用的到的”、“这个时候就需要一个商品中心了,因为 XX 公司说他们有,我们业务有很多相似的地方,有个商品中心一定不会错的”等等。像商品中心、库存中心这些核心“能力”,一定不是这样出现的。

切记切记,“能力”不是凭空冥想出来的,也不是靠经验设计出来的。一定是贴合着具体的业务场景,不停的思考和抽象,在合适的实际沉淀下来的。又到了讲述宋小菜惨痛教训的时候了:

宋小菜前两年的业务,物流业务一直处于城际配送,比如从杭州城内的某个地,配送到杭州城内的目标站点。这时候我们做了一个统一的调度物流平台,想将其作为“能力”,输出给宋小菜所有的物流调度业务。现在回过头来看,只能怪当初太年轻了,看的业务太少了。之后我们物流的复杂情况,远远超出了当时的想象,比如我们接入了骨干物流,出现了从上游基地发货的业务;比如城内大车无法通行,必须先由大车倒给多辆小车的业务;比如一辆半挂车,先送杭州再送嘉兴最后送上海的跨城业务。当初设计的物流调度中心,根本承接不了这样多变和复杂的业务场景,而且就现在来看,当时的数据模型抽象都是有问题的。

所以,如果能意识到“能力下沉,业务上浮”这个设计思路,并明白他的价值和威力,只是第一步,千万不要跌入凭空冥想“能力”的坑,这样设计出来的“能力”,往往都只是雾里看花,只是美好的愿景而已。

三、如何建设“能力”

1. 在项目过程中沉淀“能力”

如果认定了某一个能力特别重要并希望沉淀,那接下来怎么做呢?组一个专门的开发小组闷头苦干,快速产出?这样当然可以,但是从创业公司的经验来看,这样的模式往往并不可取。我们更愿意看到的项目形态是这样的:“能力”从 0 到 1 的诞生,一定要紧贴某一个具体的业务 J,以优先级最高的功能需求,输出给这个业务J。别的业务 Q、业务K知道我们开始诞生 0 到 1 的“能力”的时候,一定会向“能力”产出方提出五花八门的需求。这个时候就需要“能力”产出方自己心中有一杆称了,因为现在是“能力”从 0 到 1 的诞生的过程,你不可能满足所有的功能特性,你甚至都无法判断那些需求是否合理。所以我们有一个准则:“能力”的从 0 到 1,只为一个业务服务。这样的好处有哪些呢:

  1. “能力”必须紧贴某一业务,避免了“能力”设计者雾里看花,以防最后做出来的“能力”连一个场景都服务不到;
  2. 只服务一个业务场景,也避免了“能力”设计者胃口太凶,觉得所有的需求都合理,所有的需求都得满足,最后自己却成为了瓶颈;
  3. 给予“能力”设计者足够的思考时间。因为顺利的服务到了第一个业务,会更加有效的帮助“能力”设计者去抽象和思考“能力”;

2. 在基建重构中优化“能力”

“能力”从 0 到 1 的诞生一定是最难的,你可能得挡住一些业务需求开发的任务,或是苦口婆心的向别人述说“能力”的好处,直到他们认可为止。但“能力”的诞生往往只是红军长征的开始,“能力”是需要不停迭代,不停建设的。这些迭代的点或是需要建设的点,到底来自于哪里呢?来自于源源不断应用场景的接入。是时候介绍我们的第二个准则了:只有服务了超过三个业务场景,才是真正被认可的“能力”。这个准则就逼着“能力”的设计者,不停的思考业务的本质,以及抽象“能力”真正的价值。这样的迭代,往往会安排在一些基建的项目中,让“能力”的设计者有明确的目标和使命,去优化自己负责的“能力”。

四、结束语

和一些业内的朋友,或是前来面试的同学交流,也经常会聊到“你负责的是一个 XX 中心,那你知道为什么你们需要有一个 XX 中心吗?”,得到的答案往往是“架构师觉得需要”或是“这不是很正常吗,别的公司也都有”。如果你问我这个问题,这篇文章就是我的答案了。