如果你仔细观察过宋小菜技术同学的日常工作，你就会发现他们很喜欢谈论一个词，那就是“能力”。无论是在系统架构规划的时候、技术方案设计的时候、开发问题探讨的时候甚至PRD评审的时候，“能力”这个词会不停地出现在他们的口中。是什么原因，使得这个词这么频繁的出现在开发小伙伴的交流中呢？
一、什么是“能力”
在详细介绍什么是“能力”之前，先卖个关子，想先给大家介绍另外一个词——VUCA时代（乌卡时代）。
VUCA是四个单词的首字母组成的新词，分别是volatility（易变性）、uncertainty（不确定性）、complexity（复杂性）、ambiguity（模糊性）。VUCA最早出现在军事用语中，但是现在这个词越来越频繁的出现在我们的日常生活中了，原因就是人们发现，这四个词实在是太符合我们现在的社会和时代了。我们的生活、工作、社会以及这个高速发展的时代，不就是充满了易变性、不确定性、复杂性和模糊性吗。
回到技术同学的日常工作中，大家就会惊奇的发现，我们接到的需求、产品方案、视觉稿、运营计划甚至习以为常的框架技术、依赖的服务、使用的中间件工具，不也充满了VUCA的特质吗。所以在这里非常想和技术的同学（特别是处于创业公司，业务正处于高速发展的的公司）说一句，不要再沉迷于“打死不改版PRD”或“再改就杀一个设计师祭天版UI”的骂战或争吵中了。因为当你回过头review的时候就会发现，所有骂战和争吵的结论一定是“该变还是得变”。原因其实很简单，VUCA是我们这个时代所具备的特点，如果我们不去适应他，而是想尽一切办法去抵抗他，这是一件非常不划算的事情，而且往往你的努力会变成徒劳。
介绍了这么多有关VUCA的思考，是时候引出“能力”这个词了。因为我们发现，无论公司的方向变化的有多么快，或是死掉的业务数不胜数，还是创新性的项目一个接一个的诞生，总有一些是相对不变的，并且可以被我们沉淀下来的东西，那就是“能力”。这样介绍，可能还是比较抽象，接下来举两个例子，可能大家就会有些感知了：
1.随着业务发展，公司有越来越多的系统或者应用了，每个系统总是需要有登录流程的。一开始登录流程可能全都是独立的，A系统有一个登录流程（使用邮箱+密码登录），B系统有一个登录流程（使用动态短信登录），C系统有一个登录流程（使用登录名+密码+验证码登录）。这个时候我们就发现“能力“了，登录流程，就是我们需要沉淀的”能力“。因为登录流程是可以被枚举完的，并且某一种登录形态一旦被固化下来了，就可以快速的输出给其他的系统使用（高度复用），如下图所示：
2.业务总是多样和复杂的，X业务中有一个场景需要邮件通知主管审批，Y业务中有一个场景需要短信通知销售某个客户已经下单，Z业务中有一个场景需要push给客户优惠券马上要到期了。这个时候我们又发现“能力“了，消息通知中心，就是我们需要沉淀的”能力“。和第一个例子一样的思考方式，因为通知的途径是固化的，并且某一种消息通知的途径一旦被沉淀下来了，就可以快速的输出给其他的业务场景使用（高度复用），之后这些消息通知的能力，还可以组合使用，如下图所示：
看了上述两个例子的介绍，很多技术的同学会觉得，这些不是很正常吗，在我们的公司里不就是这样设计的吗。举这两个例子，并不是想给各位介绍多么高深的技术方案，而是想把“能力“这个词讲透。因为”能力“的设计更像是一种思维模型，即”将抽象和稳定的向下沉，将多变和不确定的往上浮”。这个思维模型，无论是在接口编写、架构思考、技术方案设计甚至日常的生活工作中，都会起到很大的帮助，并且也是适应VUCA时代的有利技巧。
二、设计“能力”的关键点
2.1 分清“业务”和“能力”
很多刚毕业的同学或是工作经验尚浅的开发同学，在接到一个需求或任务时，往往会犯一个通病，是什么呢？就是不能很好的区分“业务“和”能力“。他们往往”只面向业务编程“，请注意，在这里提到的是”只面向业务编程“，重点是这个”只“字。好多开发同学一边听着产品经理描述需求和功能，一边脑子在飞快运转。需求评审结束，脑海里已经充满了表结构的设计和字段的含义了，要不是还没确定开发分支，都认为自己已经进入开发阶段了。这里有一句玩笑话”没有什么问题，是加一个接口或者加一张表不能解决的，如果有，那就加两个。“讲到这里，是不是会引起很多开发同学的会心一笑，这个阶段估计所有的程序员都经历过。
为什么我将这个问题总结为——不能很好的区分“业务“和”能力“呢。就像刚才提到的，其实关键是因为没有形成那样的思维模型，即”将抽象和稳定的向下沉，将多变和不确定的往上浮”。”业务“拥有的最多标签，就是易变的、模糊的、不确定的，这是”业务“天生就具备的特质。很多时候，运营同学也是边跑边摸索，还一边修正运营的战略战术，这个情况在创业公司中，就更加明显了。这时候如果技术同学在开发过程中不加思考，开发起功能来兵来将挡水来土掩，不停地加表不停地加接口，可想而知，如果长此以往结果将会多么可怕。这也是宋小菜业务高速发展了三年，我们犯过的错误，也给我们带来了长足的思考。举一个我们犯类似错误的例子：
因为业务发展快速，越来越多的角色被纳入到我们的业务链路当中，比如有“交易客户“、”供应商“、”司机”、”囤货商“等等。因为不同的项目组承接了对应的需求开发，所以设计出来的结果可想而知，只能用”非常贴近我们的业务“来形容了。后面遇到了什么问题呢，比如随着业务变化，用户的身份是会多样化的，比如有的用户可能既是”供应商“又是”司机“，有的用户身份既是”供应商“又是”囤货商“等等。这时候问题就来了，“我怎么知道他到底有几个身份呢？”、“有的身份需要能登录系统A，有的身份需要登录系统B和C，有的身份不需要登录我们的系统，到底要怎么控制呢？”
其实在我们系统中出现两三个身份后，按照刚才介绍的思考方式，我们的心中就应该敲响警钟了，是时候是要做“业务”和“能力”的区分了，以便让“能力下沉，业务上浮”。我们根据业务的抽象，沉淀了用户中心的“能力”，其中包括了账户体系、用户体系和身份体系，并以相对抽象的“属性”和“标签”的扩展能力对外输出，以此来支持高速的业务变化。
2.2 不要一开始就谈“能力”
当开发的同学们慢慢理解了“能力”的作用和价值的之后，往往又会带来一个新的问题，那就是一开始就谈“能力”。“能力”并不是空想出来的，他一定是经过了一些业务形态的观察和抽象，才能被沉淀出来的。比如一上来就谈“我们先做一个库存中心，反正我们是电商模式，一定用的到的”、“这个时候就需要一个商品中心了，因为XX公司说他们有，我们业务有很多相似的地方，有个商品中心一定不会错的”等等。像商品中心、库存中心这些核心“能力”，一定不是这样出现的。
切记切记，“能力”不是凭空冥想出来的，也不是靠经验设计出来的。一定是贴合着具体的业务场景，不停的思考和抽象，在合适的实际沉淀下来的。又到了讲述宋小菜惨痛教训的时候了：
宋小菜前两年的业务，物流业务一直处于城际配送，比如从杭州城内的某个地，配送到杭州城内的目标站点。这时候我们做了一个统一的调度物流平台，想将其作为“能力“，输出给宋小菜所有的物流调度业务。现在回过头来看，只能怪当初太年轻了，看的业务太少了。之后我们物流的复杂情况，远远超出了当时的想象，比如我们接入了骨干物流，出现了从上游基地发货的业务；比如城内大车无法通行，必须先由大车倒给多辆小车的业务；比如一辆半挂车，先送杭州再送嘉兴最后送上海的跨城业务。当初设计的物流调度中心，根本承接不了这样多变和复杂的业务场景，而且就现在来看，当时的数据模型抽象都是有问题的。
所以，如果能意识到“能力下沉，业务上浮”这个设计思路，并明白他的价值和威力，只是第一步，千万不要跌入凭空冥想“能力“的坑，这样设计出来的”能力“，往往都只是雾里看花，只是美好的愿景而已。
三、如何建设“能力“
3.1 在项目过程中沉淀“能力”
如果认定了某一个能力特别重要并希望沉淀，那接下来怎么做呢？组一个专门的开发小组闷头苦干，快速产出？这样当然可以，但是从创业公司的经验来看，这样的模式往往并不可取。我们更愿意看到的项目形态是这样的：“能力”从0到1的诞生，一定要紧贴某一个具体的业务J，以优先级最高的功能需求，输出给这个业务J。别的业务Q、业务K知道我们开始诞生0到1的“能力”的时候，一定会向“能力”产出方提出五花八门的需求。这个时候就需要“能力”产出方自己心中有一杆称了，因为现在是“能力”从0到1的诞生的过程，你不可能满足所有的功能特性，你甚至都无法判断那些需求是否合理。所以我们有一个准则：“能力”的从0到1，只为一个业务服务。这样的好处有哪些呢： 1.“能力”必须紧贴某一业务，避免了“能力”设计者雾里看花，以防最后做出来的“能力”连一个场景都服务不到； 2.只服务一个业务场景，也避免了“能力”设计者胃口太凶，觉得所有的需求都合理，所有的需求都得满足，最后自己却成为了瓶颈； 3.给予“能力”设计者足够的思考时间。因为顺利的服务到了第一个业务，会更加有效的帮助“能力”设计者去抽象和思考“能力”；
3.2 在基建重构中优化“能力”
“能力”从0到1的诞生一定是最难的，你可能得挡住一些业务需求开发的任务，或是苦口婆心的向别人述说“能力”的好处，直到他们认可为止。但“能力”的诞生往往只是红军长征的开始，“能力”是需要不停迭代，不停建设的。这些迭代的点或是需要建设的点，到底来自于哪里呢？来自于源源不断应用场景的接入。是时候介绍我们的第二个准则了：只有服务了超过三个业务场景，才是真正被认可的“能力”。这个准则就逼着“能力”的设计者，不停的思考业务的本质，以及抽象“能力”真正的价值。这样的迭代，往往会安排在一些基建的项目中，让“能力”的设计者有明确的目标和使命，去优化自己负责的“能力”。
四、结束语
和一些业内的朋友，或是前来面试的同学交流，也经常会聊到“你负责的是一个XX中心，那你知道为什么你们需要有一个XX中心吗？”，得到的答案往往是“架构师觉得需要”或是“这不是很正常吗，别的公司也都有”。如果你问我这个问题，这篇文章就是我的答案了。
关于如何搭建高效率的生鲜B2B平台，因为包含的内容较多，也很复杂，无法再一篇文章中给大家讲清楚，本篇文章只是抛砖引玉，下面将分为多篇文章从行业现状、业务现状、产品概述、技术团队搭建、服务端技术平台搭建、前端开发等多个维度来讲述，我们将三年多在B2B领域沉淀的核心产品和技术平台公开，希望更多行业的人能深入了解，少走一些弯路，希望对大家有帮助，本系列文章分布如下（会继续更新）：
1、《如何搭建高效率的生鲜 B2B 平台（B2B 技术共享第一篇）》
2、《宋小菜如何切入生鲜 B2B 市场（B2B 技术共享第二篇）》
3、《生鲜 B2B 平台的产品体系如何迭代（B2B 技术共享第三篇）》
4、《生鲜 B2B 如何搭建高效的技术团队（B2B 技术共享第四篇）》
5、《如何从 0 到 1 搭建生鲜 B2B 的技术体系（B2B 技术共享第五篇）》
6、《宋小菜技术如何应对生鲜 B2B 业务的快速变化（B2B 技术共享第六篇）》
7、《生鲜 B2B 技术平台的前端团队该如何搭建（B2B 技术共享第七篇）》
