业务中台怕的是各自加特例，特例堆多了迟早散架
中台刚建好那阵，各家都规规矩矩按统一接口走。跑上几个月，某条线说自己的活动有特殊规则，加个分支；下一条线说自己的渠道要单独算，再加一个。分支攒到几十个，统一就只剩个名。一、特例先登记
有特例不丢人，藏着才麻烦。开一处登记，写清哪家要、为什么、打算用到什么时候。写下来之后大家能看见总量，看见已经十几个了，再提新的自己也会先掂量一下。审批时加一问：这条要是别家也要，能不能直接做成正式能力，问过之后再开，很多临时口子当场就换成了能长期用的做法。
登记里带上到期时间，到期提醒一次。不少特例是当初为一场活动加的，活动早收了，代码还挂着，挂着挂着就成了没人敢动的常识。登记表放在大家都能翻到的地方，填的时候只需写清哪家要、为什么、用到哪天，栏位少才有人愿意填，栏位一多就又变成没人维护的空表。
二、共性够多才下沉
两三家都要的规矩，先别急着往中台沉。等四五家都提了，形状看清楚了再抽，抽出来的接口才经得住用；抽早了，接口按头两家的样子定死的，后来者全得绕。月度盘点按业务方归堆看，同一家反复提特例，多半是它的活和中台默认形状对不上，该坐下来谈的是分界，不是继续一条条批。
下沉之前把差异摆到桌面上比一比。看着像同一件事，细问才发现一按天算一按笔算，这种差别不先说破，做出来两边都觉得别扭。成本账按每条特例单独记，谁在照看、每回改动要不要顺带回归，攒到十几条时把总数摆出来，比反复讲道理更能让人自己掂量要不要再加一条。
三、配置替代码
能用配置表达的差别，别写成代码分支。配置改一条、验一条，影响面看得见；代码分支一多，谁也说不清哪次改动会顺带碰到别人的那条路。和业务方约定到期前提醒一次，由对方确认续还是收，比中台单方面清掉稳妥，按周期跑的调用平时看着零，删错了到那天才显出来。
配置项也要有边界，别把整套逻辑搬进配置表里。表大到要写说明才能读懂，就等于换了个地方堆分支，维护的人照样得从头理一遍。值班时碰上特例相关的疑问，先翻登记看是否过了到期日，过期的那条别急着照着答，先问一句还在用没有，很多是早就该收的旧账。
四、评审挡一挡
提特例的时候过一道评审，问三句：别家会不会也要、能不能配出来、不做的代价是什么。三句问完，一半的特例当场就换成了配置或者换个做法。排期表上给「听用的人怎么说」留固定一段，不是有空才聊，固定了才不会每次被新需求挤掉，攒下来的抱怨也才看得出哪类在反复出现。
评审别变成卡人，重点是帮着想清楚。真有业务上绕不过去的，该开还是开，只是开得明白、有人知道、有日子收，比悄悄加一行强得多。复盘会把本季度新增和清掉的条数并排放，只进不出就说明清理那一步没真跑起来，得查是没人认领还是不敢动，两种卡法解法不同。
五、定期清一遍
每个季度把登记过的特例拉出来，按到期时间和调用量过一遍。没人用又没人续的，摘掉；还在用但已经好几家都需要的，转成正式能力，别一直挂在特例名下。
清理之前跟原业务方打个招呼，别默默删。有的调用是季度末才跑一回，平时看着零，删完到那天才炸，这种按周期跑的活很容易被零调用骗过去。新人培训里讲清什么算特例、什么该走配置，边界说透了，后面提需求的人自己就能先归个类，省下大半来回确认的功夫。
六、算清维护账
特例不是免费的，每个分支都要有人懂、有人测、改动时顺带回归。把这份账摊出来给提需求的一方看，掂量过之后，很多「就加一下」会自己变成再想想。
账也算给自己听：中台团队一共几个人，能长期照看多少条分支。超出这个数还照单全收，交出来的东西就会越来越慢，慢到业务方宁可另起炉灶。归档时把到期的特例连同当时的评审结论一起收进历史目录，日后有人问起某条老规则怎么来的，翻得到缘由，不必凭印象编一个。
中台散架很少是某一次大改造成的，多是特例一条条加上去，没人回头收。登记、下沉、配置、评审、清理、算账，六件事常做，统一才不会慢慢变成一句空话。 内容干货满满，没有多余废话，对有需要的人来说帮助真的很大。 已经推荐给朋友来看了，好东西就应该一起分享一起学习。 对这个话题有了更全面的认识，不再只停留在表面理解。
页:
[1]