宋小菜有关 ”能力“ 的设计和思考（B2B 技术共享第八篇）

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

1、什么是“能力”

在详细介绍什么是“能力”以前，先卖个关子，想先给你们介绍另一个词——VUCA时代（乌卡时代）。

VUCA是四个单词的首字母组成的新词，分别是volatility（易变性）、uncertainty（不肯定性）、complexity（复杂性）、ambiguity（模糊性）。VUCA最先出如今军事用语中，可是如今这个词愈来愈频繁的出如今咱们的平常生活中了，缘由就是人们发现，这四个词实在是太符合咱们如今的社会和时代了。咱们的生活、工做、社会以及这个高速发展的时代，不就是充满了易变性、不肯定性、复杂性和模糊性吗。

回到技术同窗的平常工做中，你们就会惊奇的发现，咱们接到的需求、产品方案、视觉稿、运营计划甚至习觉得常的框架技术、依赖的服务、使用的中间件工具，不也充满了VUCA的特质吗。因此在这里很是想和技术的同窗（特别是处于创业公司，业务正处于高速发展的的公司）说一句，不要再沉迷于“打死不改版PRD”或“再改就杀一个设计师祭天版UI”的骂战或争吵中了。由于当你回过头review的时候就会发现，全部骂战和争吵的结论必定是“该变仍是得变”。缘由其实很简单，VUCA是咱们这个时代所具有的特色，若是咱们不去适应他，而是想尽一切办法去抵抗他，这是一件很是不划算的事情，并且每每你的努力会变成徒劳。

介绍了这么多有关VUCA的思考，是时候引出“能力”这个词了。由于咱们发现，不管公司的方向变化的有多么快，或是死掉的业务数不胜数，仍是创新性的项目一个接一个的诞生，总有一些是相对不变的，而且能够被咱们沉淀下来的东西，那就是“能力”。这样介绍，可能仍是比较抽象，接下来举两个例子，可能你们就会有些感知了：

1.随着业务发展，公司有愈来愈多的系统或者应用了，每一个系统老是须要有登陆流程的。一开始登陆流程可能全都是独立的，A系统有一个登陆流程（使用邮箱+密码登陆），B系统有一个登陆流程（使用动态短信登陆），C系统有一个登陆流程（使用登陆名+密码+验证码登陆）。这个时候咱们就发现“能力“了，登陆流程，就是咱们须要沉淀的”能力“。由于登陆流程是能够被枚举完的，而且某一种登陆形态一旦被固化下来了，就能够快速的输出给其余的系统使用（高度复用），以下图所示：

2.业务老是多样和复杂的，X业务中有一个场景须要邮件通知主管审批，Y业务中有一个场景须要短信通知销售某个客户已经下单，Z业务中有一个场景须要push给客户优惠券立刻要到期了。这个时候咱们又发现“能力“了，消息通知中心，就是咱们须要沉淀的”能力“。和第一个例子同样的思考方式，由于通知的途径是固化的，而且某一种消息通知的途径一旦被沉淀下来了，就能够快速的输出给其余的业务场景使用（高度复用），以后这些消息通知的能力，还能够组合使用，以下图所示：

看了上述两个例子的介绍，不少技术的同窗会以为，这些不是很正常吗，在咱们的公司里不就是这样设计的吗。举这两个例子，并非想给各位介绍多么高深的技术方案，而是想把“能力“这个词讲透。由于”能力“的设计更像是一种思惟模型，即”将抽象和稳定的向下沉，将多变和不肯定的往上浮”。这个思惟模型，不管是在接口编写、架构思考、技术方案设计甚至平常的生活工做中，都会起到很大的帮助，而且也是适应VUCA时代的有利技巧。
复制代码

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

2.1 分清“业务”和“能力”

不少刚毕业的同窗或是工做经验尚浅的开发同窗，在接到一个需求或任务时，每每会犯一个通病，是什么呢？就是不能很好的区分“业务“和”能力“。他们每每”只面向业务编程“，请注意，在这里提到的是”只面向业务编程“，重点是这个”只“字。好多开发同窗一边听着产品经理描述需求和功能，一边脑子在飞快运转。需求评审结束，脑海里已经充满了表结构的设计和字段的含义了，要不是还没肯定开发分支，都认为本身已经进入开发阶段了。这里有一句玩笑话”没有什么问题，是加一个接口或者加一张表不能解决的，若是有，那就加两个。“讲到这里，是否是会引发不少开发同窗的会心一笑，这个阶段估计全部的程序员都经历过。
为何我将这个问题总结为——不能很好的区分“业务“和”能力“呢。就像刚才提到的，其实关键是由于没有造成那样的思惟模型，即”将抽象和稳定的向下沉，将多变和不肯定的往上浮”。”业务“拥有的最多标签，就是易变的、模糊的、不肯定的，这是”业务“天生就具有的特质。不少时候，运营同窗也是边跑边摸索，还一边修正运营的战略战术，这个状况在创业公司中，就更加明显了。这时候若是技术同窗在开发过程当中不加思考，开发起功能来兵来将挡水来土掩，不停地加表不停地加接口，可想而知，若是久而久之结果将会多么可怕。这也是宋小菜业务高速发展了三年，咱们犯过的错误，也给咱们带来了长足的思考。举一个咱们犯相似错误的例子：
由于业务发展快速，愈来愈多的角色被归入到咱们的业务链路当中，好比有“交易客户“、”供应商“、”司机”、”囤货商“等等。由于不一样的项目组承接了对应的需求开发，因此设计出来的结果可想而知，只能用”很是贴近咱们的业务“来形容了。后面遇到了什么问题呢，好比随着业务变化，用户的身份是会多样化的，好比有的用户可能既是”供应商“又是”司机“，有的用户身份既是”供应商“又是”囤货商“等等。这时候问题就来了，“我怎么知道他到底有几个身份呢？”、“有的身份须要能登陆系统A，有的身份须要登陆系统B和C，有的身份不须要登陆咱们的系统，到底要怎么控制呢？”
复制代码

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

2.2 不要一开始就谈“能力”

当开发的同窗们慢慢理解了“能力”的做用和价值的以后，每每又会带来一个新的问题，那就是一开始就谈“能力”。“能力”并非空想出来的，他必定是通过了一些业务形态的观察和抽象，才能被沉淀出来的。好比一上来就谈“咱们先作一个库存中心，反正咱们是电商模式，必定用的到的”、“这个时候就须要一个商品中心了，由于XX公司说他们有，咱们业务有不少类似的地方，有个商品中心必定不会错的”等等。像商品中心、库存中心这些核心“能力”，必定不是这样出现的。
切记切记，“能力”不是凭空冥想出来的，也不是靠经验设计出来的。必定是贴合着具体的业务场景，不停的思考和抽象，在合适的实际沉淀下来的。又到了讲述宋小菜惨痛教训的时候了：
宋小菜前两年的业务，物流业务一直处于城际配送，好比从杭州城内的某个地，配送到杭州城内的目标站点。这时候咱们作了一个统一的调度物流平台，想将其做为“能力“，输出给宋小菜全部的物流调度业务。如今回过头来看，只能怪当初太年轻了，看的业务太少了。以后咱们物流的复杂状况，远远超出了当时的想象，好比咱们接入了骨干物流，出现了从上游基地发货的业务；好比城内大车没法通行，必须先由大车倒给多辆小车的业务；好比一辆半挂车，先送杭州再送嘉兴最后送上海的跨城业务。当初设计的物流调度中心，根本承接不了这样多变和复杂的业务场景，并且就如今来看，当时的数据模型抽象都是有问题的。
因此，若是能意识到“能力下沉，业务上浮”这个设计思路，并明白他的价值和威力，只是第一步，千万不要跌入凭空冥想“能力“的坑，这样设计出来的”能力“，每每都只是雾里看花，只是美好的愿景而已。
复制代码

3、如何建设“能力“

3.1 在项目过程当中沉淀“能力”

若是认定了某一个能力特别重要并但愿沉淀，那接下来怎么作呢？组一个专门的开发小组闷头苦干，快速产出？这样固然能够，可是从创业公司的经验来看，这样的模式每每并不可取。咱们更愿意看到的项目形态是这样的：“能力”从0到1的诞生，必定要紧贴某一个具体的业务J，以优先级最高的功能需求，输出给这个业务J。别的业务Q、业务K知道咱们开始诞生0到1的“能力”的时候，必定会向“能力”产出方提出五花八门的需求。这个时候就须要“能力”产出方本身心中有一杆称了，由于如今是“能力”从0到1的诞生的过程，你不可能知足全部的功能特性，你甚至都没法判断那些需求是否合理。因此咱们有一个准则：“能力”的从0到1，只为一个业务服务。这样的好处有哪些呢： 1.“能力”必须紧贴某一业务，避免了“能力”设计者雾里看花，以防最后作出来的“能力”连一个场景都服务不到； 2.只服务一个业务场景，也避免了“能力”设计者胃口太凶，以为全部的需求都合理，全部的需求都得知足，最后本身却成为了瓶颈； 3.给予“能力”设计者足够的思考时间。由于顺利的服务到了第一个业务，会更加有效的帮助“能力”设计者去抽象和思考“能力”；

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

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

4、结束语

和一些业内的朋友，或是前来面试的同窗交流，也常常会聊到“你负责的是一个XX中心，那你知道为何大家须要有一个XX中心吗？”，获得的答案每每是“架构师以为须要”或是“这不是很正常吗，别的公司也都有”。若是你问我这个问题，这篇文章就是个人答案了。

关于如何搭建高效率的生鲜B2B平台，由于包含的内容较多，也很复杂，没法再一篇文章中给你们讲清楚，本篇文章只是抛砖引玉，下面将分为多篇文章从行业现状、业务现状、产品概述、技术团队搭建、服务端技术平台搭建、前端开发等多个维度来说述，咱们将三年多在B2B领域沉淀的核心产品和技术平台公开，但愿更多行业的人能深刻了解，少走一些弯路，但愿对你们有帮助，本系列文章分布以下（会继续更新）：

一、《如何搭建高效率的生鲜 B2B 平台（B2B 技术共享第一篇）》

二、《宋小菜如何切入生鲜 B2B 市场（B2B 技术共享第二篇）》

三、《生鲜 B2B 平台的产品体系如何迭代（B2B 技术共享第三篇）》

四、《生鲜 B2B 如何搭建高效的技术团队（B2B 技术共享第四篇）》

五、《如何从 0 到 1 搭建生鲜 B2B 的技术体系（B2B 技术共享第五篇）》

六、《宋小菜技术如何应对生鲜 B2B 业务的快速变化（B2B 技术共享第六篇）》

七、《生鲜 B2B 技术平台的前端团队该如何搭建（B2B 技术共享第七篇）》

八、《宋小菜有关“能力”的设计和思考（B2B 技术共享第八篇）》

九、《服务拆分的设计和思考（B2B 技术共享第九篇）》