背景
新丝路项目由促销、交易团队发起，目标面向底层电商链路引入集团的业务中台，以此增加考拉的整体电商能力，并提高后续的整体开发效率。 从今年3月初开始产品设计，4月底开始正式开发，涉及到供应链、菜鸟、业务中台、考拉四个BG的项目历时半年终于正式发布上线。这是一个及其庞大且复杂的项目，在项目过程中遇到了种种问题值得反思和总结。
关于项目管理
整体项目节奏大概是315~420产品方案和技术方案并行， 420~615 第一阶段迭代， 615~718第二阶段迭代，808上线，903完成灰度。
在这过程中我们考虑到了所有项目做的常规执行动作： 方案评审、代码review、任务分解、两阶段迭代、灰度、日会、周会，但是又感觉每个阶段都没做好。整体项目延期非常严重，且在项目后期只能通过各种加班来解决。回顾下整个项目过程可能需要在几个方面加强：
- 产品方案不详细，遗漏很多大的功能点。其实这样大尺度的重构项目产品方案遗漏是非常正常的事情，所以给我们的经验教训是抓大放小。我们要分两部分的评审，一部分是把全流程串起来，然后再去评审纠结各种细节。
- 技术方案不详细： 显然老生常谈的问题的。技术方案要做多细？ 我们觉得三个图是必要的： 业务架构图、时序图、调用依赖图。 然后必须识别关键性的节点，然后死扣细节。
- 没有迭代起来，所有的压力都会集中在最后即将上线期间： 没迭代起来的原因一是迭代规划不够细，二是依赖链路复杂没法单独提测。比如一期迭代考拉促销、考拉交易、buy2、ump是必须的，然后某个关键性节点的延期导致整体迭代不了。 这时候其实要在方案设计时候考虑到mock接口和mock测试的重要性了。在评估方案时候必须要考虑到到对独立业务域的单独测试情况，不过这个在迁如集团中台后反而加剧了这个问题。
- 关键型的节点成为卡点：项目最关键的两个进度卡点一是交易提测不断延期二是库存虽然上线但是灰度一直在延期。
- 留给灰度的时间太短：因为项目前面延期，导致灰度时间完全不够，原计划只达到原计划灰度量的3%，上线时间又是卡死的。这时候只能扣灰度时间，然后引起的连锁反应是上线质量不高。其实当时灰度决策的时候有非常大的压力。
- 上线质量不高：当然所辛除开预售还不是特别差。在灰度期间遇到的问题多，上线后也陆续收到各种反馈。
没考虑性能问题： 一是在方案设计之初没考虑过性能问题；二是后续项目节奏已经不支持性能压测； 三是和双十一全链路压测一起搞，因为已经上线对上游业务压力非常大 .
导致项目延期然后频繁加班的两个核心原因是：- 跨团队沟通成本过高、
- 关键型链路的阻塞导致整体项目的延期。
一条公里上交通阻塞很大一个原因是因为有车发生了交通事故(关键型节点出问题了)。为了解决这两个问题，这时候就体现出团队的TL或者技术PM的重要性了，首先其必须要有技术决策能力(风险预估)，横向的沟通能力，以及决策的魄力(必须有损上线，有的功能优先级就应该靠后)。 这也说明一个道理为什么负责项目单纯依赖PMO来驱动是非常难的， 而且为什么跨团队的协作这么困然。因为跨越自己的领域给别的领域做决策这是非常困然的事情。
如果要做三件最重要的改进：
- 一定一定要迭代起来： 第一次迭代不成功的时候其实就应该按上线不成功来推进和决策
- mock接口： 接口评审、mock测试， 不过这个在现有的星环架构下比较难
- 评估和关注关键性节点的风险，不要支持通过投更多人的方式来解决进度问题
关于复杂度控制
迁移过程中遇到最大的问题是历史的坑太多：
- 交易有个下单改价接口： 所有权益平台的资格是构建在其上面的，而在权益平台又长了很多业务。然后需求是兄弟们我们不提供下单接口了
- 促销活动+权益经过去年的治理从32变为25，在融合过程中又从25下降到19，但是19对于考拉这样体量的业务来说还是太多
我们知道在商详最多会算多少种价格吗？（会员+非会员）* （预热期+正式期）。 预热期的时候算未来的价格如果正式期有两个活动应该算哪个活动？ 如果有两波预付，一个商品一半sku在第一波中一半sku在第二波中， 我们算未来价格的时候该怎么算？
在面向如此复杂场景的时候，我们在解决方案同时同时也必须反思，是不是我们就不应该支持这样的场景和需求？
很多情况下，我们必须面向领域进行思考和决策：
- 考虑领域的边界是什么： 什么应该进来，什么不应该进来
- 控制领域的复杂度： 什么样的需求应该接，什么样的需求应该拒绝
- 标准对外的接口： 如果我是一坨屎，那么我们也是一坨用袋子装起来的屎
- 学会拒绝和妥协：沟通是平衡的艺术，通过对原则的思考进行合理的拒绝和妥协。这点我自己需要反思，沟通的急躁性太显得自己没段位
- 时不时反思那句话： 架构的艺术就是抽象+约束的。 如果没有抽象那么就没有复用度，如果没有约束，那么系统就会越来越庞大和臃肿
回到考拉问题本身，为什么历史的坑这么多，原因还是没有进行面向领域的思考和实践，昨日之事今日之师，为了给后人少留坑，一定要思考牢记我们在建造一个高楼大厦而不是狗窝。
关于康威定律
“组织架构决定系统架构”。随着工作年限的增加，越来越觉得这句话威力的巨大。怎么理解这句话？
打个非常形象的例子：
- 如果4个业务团队向1个DBA提4个建表需求，很可能这四张表是落在一个数据库实例中的；
- 如果4个业务团队向4个DBA提4个建表需求，那么很可能这4张表是落在4个数据库实例中的。
所以一个组织，不管是一个小团队还是一家公司，战略目标不仅是需要在规划层面，跟多的是在组织设计中给其相应的保障。
回到新丝路项目，核心参与的团队是促销和交易， 其在组织架构中的分工是这样的：
乍看一下这样很合理，分层明确。但是很大的一个问题就是促销和交易这块业务到底是哪个团队的，谁能为这样的业务负责。这是典型的“三个和尚没水喝”。
- 一个在商详预热期未来价格展示不对的问题，到底要商详改、还是促销改还是Ump改？
- 一个限端红包展示的问题，到底需要交易前台支持，还是交易支持还是buy2支持？
现实的结果是：
- 商详： 迁移融合和我有啥关系，你保持接口完全兼容就好了。 别让我有这么多的改动
- 促销: 我夹在中间受气， 一方面原来商详调用不合理qps*10了， 另一方面ump说我的能力就只能是这样的，任何改动优化要这中间层来适配改动
- ump： 为什么你们考拉有这么多定制化的需求？ 有线上问题为什么你们没有测试出来。 我服务的对象很多，都为你们一周发一个版本的你们还要闹怎么样？
这是典型的因为因为屁股的不同，因为思考策略的不一致，必然会导致结果和选择的不同。如何解？
- 纵向划分团队而不是横向划分团队（按业务分工来划分团队，而不是按系统架构来划分团队）
- 从人员的精简作为系统的精简的前提条件。从系统链路上进行思考和划分，而不是点状解决单一团队的问题(从运营->产品->技术这么一条线来，而不是简单调整技术团队)。
所以后续团队职责一个努力演化的方向是这样的：
- 在导购场：特别是商详直接有一个促销的模块，这块模块的内容直接由促销团队负责到底
- 在交易链路应该逐步合并掉前台交易
这样在整个考拉链路上责任的清晰的，在组织架构保证上也是清晰的，那么自然而然后面的系统演化也会是清晰的。
那么中台呢？ 和中台的责任如何清晰？ 这就需要开启另一个沉重的话题了
关于"中台之殇"
这个话题有点沉重，也有点敏感，不过反思的目的不就是为了更好的改进嘛。特别欣赏的还是特斯拉的标语“自我否定、自我超越”。
个人的经历其实要高举“中台牛逼”的旗帜的。 因为本人是业务中台出生，中间有一段经历也是以整体的中台概念来构建整个发票SASS平台。而来考拉后也是极力主导考拉接业务中台的改造，因为我一直坚信一个道理：软件复用度的提升是一个领域的长期架构方向。
整个新丝路对接中台的改造中整体来讲在对于考拉整体能力和稳定性的提升，以及单元人员面积和机器面积的产出确实能带来很大的帮助， 但是由此一起的沟通复杂度的上升以及带来整体效率的降级缺是值得思考的。
前几年中台的概念非常火，甚至很多创业型的公司都会扯中台的概念。之前有个很热门的话题是“中国在IT领域对世界的贡献是什么”，很多美国的技术人员翻了一圈发现只有一个“中台”，虽然大家都不知道中台是什么东西。
在此次新丝路和中台的合作的过程，两个最直观的感受是：
- 屁股决定嘴巴
- 管理闭环的重要性
很多时候如果把一个国家的很小依赖寄托到一群雇佣兵上，那么在很多时候是很难做到决策上的闭环。跨部门的项目也必然会导致各种流程和扯蛋，那句话怎么说来着的： 创立流程的目的肯定不是为了提高效率，而是为了保护自己。
- “管理闭环的重要性”： 关联购卡项目，原计划927上线，后来因为中台的开发节奏原因推迟至1031， 后来因为关键性bug 推迟至1002, 然后1007，然后1010重要上线。 在此过程中最关键性的节点就是中台，而中台又是如此庞大而臃肿。之间因为上线后功能降级和业务对焦道歉的是考拉业务一号位；一次Ump的发版改动 考拉3个团队开发测试通宵开发测试，然后在十一期间我们搞了5次；一方面确实是因为项目有难度，但是另一方面更多感受到的是执行过程中的缓慢和僵硬；而作为项目的一号位，对关键性节点的决策和推动的乏力也是在此项目中最大困扰
- “线上问题改进不及时”： 上线后存在着很多线上问题，考拉侧的同学基本已经定位好原因和问题所在准备好数据，结果以周为单位。好几个不严重的会到一月之上。特别是碰到了双十一大促，那么很多事情就不要想了。 问题的根本原因是业务缺乏对中台线上问题的考核机制，谁嗓门大谁很可能就推动的快。 很多时候一个问题很可能是一非常重要的问题，但是在中台同学眼中也就这么回事了。 其归根结底的原因还是因为大家的屁股不一样，对于业务同学来讲业务挂了那对个人来说必然会有很大的影响，而对中台来讲，你不是我的唯一。天猫比你重要太多了
- “缺乏对外完整的sop”： 是的，中台缺少一份标准的对外服务承若，技术上比如那个接口在什么的的场景下RT是多少，单机能抗多少qps； 线上问题给业务放吱一声的时间是多长； 我们不需要吹中台有多牛的技术架构，只需要真正把业务开发当成你们用户的SOP文档输出和服务体验
- “强大且臃肿”： 必须承认，在电商领域中台有非常强大的能力，但是对其臃肿的现状且对开发用户非常不友好。打开icclient的 IPM配置，需要排包，两位核心同学搞了3天+两个通宵，怨声载道， 发现其包中引入了饿了么的包就算了，你引入众安保险的包是什么鬼；ump有各种配置，为了打开一个配置压测了一晚上，第二天配置关闭了没答复，有线上问题找过去告知因为还有其他配置没打开所以不能打开， 其实对于业务放来说，我不管内部有多少配置，内部有接团队实现，对外需要满足业务的需求
- “超级漫长的发布时长”： 以天为发布时长，以周为发布周期。 推一个考拉侧独有的配置有概率影响全局的所以和发版一个难度。 有一个感慨是 隔离性是中台必要的一个能力，如果没做好那是你的问题，不要把你的问题设置为一个流程来把负担压个业务(很多时候业务为了线上问题咬咬牙打了很多补丁)。
- ’‘对外暴露出了整个团队的职责和功能’： 比如查一个性能问题，涉及到UMP的业务对接团队，券后价团队，稳定性团队； 改一个配置，影响到了券后价、大白、稳定性，然后业务放要把所有的涉及方串联起来，这种串联和推进是非常影响效率和精力的
- “星环是不是kpi的产物？”： 中台的一个核心目标是提高复用度， 但是业务的差异如何保证？有扩展点满足不了怎么办？ UMP的使用成本是否可以降低？业务中台是否是个伪概念？因为业务的复用是很难在bu直接做统一的。是否需要星环这样的统一管理，如果没有kpi， 从设计之初，中台团队为业务团队提供工具和引擎而不是平台，从这样的角度来设计是否会更具备扩展性？中台的能力边界应该在什么地方？ 软件工程上那句著名的话“没有银弹”， 这个其实一直需要长期思考
如何解？ 值得庆幸的是中台的开发都是值得信赖的在可合作性上也非常强，而阿里现在终归还不是那么官僚，所以几个点可以需要后续持续进行：
- 多和中台的开发沟通，了解其内部实现和熟悉链路的人员，很多人忽视在协作过程中软关系的重要性，其实良好的软关系是长期合作的一个重点前提
更希望是中台能把业务开发作为客户来经营和合作，基于这个大前提一下几点会更让效率提升：
- 完整的SOP流程： 包含对接文档，demo, 线上问题流转机制
- 有一个解决方案专家对口业务，其这个域中所有的问题都不用让业务的同学一个链路往下找， 且业务对此解决方案专家有评价或者考核权(管理闭环的重要性)
当然这个文章最重要的是反思，所以很多因为融合带来的好处就不一一总结。反观回来还是一句话，业务中台已经做的足够好了(特别和同行对比哈哈)， 如果让我来做不一定会做的更好。
总结
复习下那句久远的话”有没银弹“， 因为软件工程天然带着四个特质：
- 复杂性 ： 历史的坑太多
- 隐匿性： 靠PRD其实是不靠谱的
- 配合性： 多团队协作的困然
- 易变性： 我们的需求是做成和原来的功能一模一样， 要改动的功能拉扯的时间比较长
大师的意思是无解，咱们好好承受。那我们要做的事情就是在这个焦油坑中打滚和蹒跚前进，在控制复杂度和提高复用度上不断前行。在此过程中牢记那么几句关键的话：
- 架构是抽象+约束
- 流程加入一个节点其复杂度是指数级增长的
- 沟通非常重要
- 决策是一种平衡下的选择
- 管理好自己域的负责度
