中台先把共用能力划出来，别让每个业务各写一套
几条业务线做下来，总会有几件事是每家都要干的，比如发通知、算权限、记流水。各写一套的时候看着快，等要改规矩，就得挨家挨户通知一遍，漏掉一家，那家的数据就和别处对不上。一、先找重复的活
划中台别从架构图起手，先去翻各业务的代码，把重复写了三遍以上的那段圈出来。重复三遍说明需求是稳的，抽出来有人用；只写过一遍的，多半是某条线的特例，硬抽进来反而把大家拖住。审批流里给这类改动留一档轻的通道，只动文案或者补个例子就别走整轮评审，通道太重大家会绕开它，绕开之后记录反而不全。
圈的时候连着经办的人一起问，光看代码看不出哪些地方是为临时活动加的。问清楚了才知道哪段是长久要用的，哪段下个季度就没人碰，后者不值得往中台里搬。排期表上把这块能力归到哪个团队写清楚，后面有人来问改动该找谁，照着表就能答，不必每次在群里从头问一圈，问完还常常得到两个不一样的说法。
二、边界按业务定
能力归谁，按业务归属切比按技术分层切更稳。按技术切容易切出一层谁都不认的中间件，业务方觉得不好用，中台方觉得别人不配合，两边别扭半年也说不清。季度盘点把接入清单和工单数量并排看，接得多说明能力对路，问得多说明哪处没讲明白，两个数字凑一起比单看一个更能看出下一步该做什么。
一条能力只让一个团队签字，签字那个团队既管接口也管排期。两个团队都能改的时候，改冲突了谁也不认账，回头查记录只看得到两笔互相覆盖的提交。成本那一栏别只填机器和人力，把各家接入时花掉的工夫也折进去，摊开看过才知道抽出来到底省了没有，省在哪一段也能说给后来的人听。
三、接口要收口
业务方想要什么就临时开个后门，开到第五个，这套能力就等于没有接口了。所有调用走同一处入口，入口外的私连要清掉，清不掉的登记在册，写明白什么时候收。
收口之后参数别越加越多。加一个参数就多一批组合，组合多到没人能全测一遍，后来改一处就心惊，生怕踩到哪组没人记得的老用法。值班交接的时候把尚未回完的疑问逐条列上，接手的人照着单子往下走，不至于等到第二天才发现有一家还卡在半路没人应，白白多等一个白天。
四、版本往前兼容
中台改接口，不能让所有业务同一天跟着发版。新字段加上去，老调用照旧能跑，等业务各自排期迁完，再把旧的那支慢慢撤掉，撤之前留足提醒。
兼容期写进约定里，别口头说一声就算。口头约定换个人就断，断了之后业务方还在用老写法，某天中台一清理，线上跟着出状况，查半天查到是半年前那句话没人记。复盘会上先把当初为什么抽这块能力的缘由重说一遍，再看眼下的用法还贴不贴那个缘由，跑偏了就早调，比攒到半年后整推重来省得多。
五、谁维护谁负责
能力交出去不等于甩出去，出了疑问得有人接。接的人要能看懂这套能力的来龙去脉，看不懂就只能把问题原样转回业务方，转来转去一天过去，事情还停在原地。
值班表里写清每块能力对应哪个人，写清了半夜出事不用在群里挨个问。人名和模块对得上，故障从发现到有人动手的那段时间才短得下来。新人上手的头一周安排他跟着接一条真实业务，从读说明到跑通例子走完整一遍，卡在哪一步当场记下来，那几处往往就是文档该补的地方。
六、用得上的才算数
中台做成没做成，不看文档写了多少页，看有几条业务真接了、接了之后还在用。接了又悄悄下掉的，多半是能力没对上人家的活，得回头问清楚差在哪。
每季把接入清单拉出来对一遍，长期零调用的模块别硬留着。留着要占机器、要有人值守，还要在每次改动时被顺带回归一遍，成本摊下来比当初不抽还高。归档的时候把接口说明、改动记录和当初的评审结论放在一处，过一年有人翻旧账，顺着目录就能找齐，不用把几个老同事重新拉回来回忆。
把共用能力划出来，图的是改一处能管一片，不是多搭一层让人排队。重复、边界、收口、兼容、维护、清单，六件事理顺，中台才真省事；理不顺，只是把原先各家的乱挪到一个地方集中乱。 每一段都很有分量，认真读完全篇感觉整个人都提升了不少。 虽然篇幅不长，但句句都是重点，简洁又有深度，非常不错。
页:
[1]