写在前面
平台化是我们的目标，那什么是平台化？ 举个跟我们很近的例子，在达达公司还未成立之前，外卖商户如果中午需要配送，只能自己招几个配送员，需要计算自己配送员的工资，怕他们偷懒，要管理他们的绩效......，结果达达公司出现了，现在的商户只需要付运费，而配送员的管理全部交由达达公司，达达公司提供配送服务本质上就是将运力供给这件事情平台化，这个平台只要商户在app上下单，就可以得到优质的服务 。 总结下来，平台化本质上是将零散的需求抽象化成一个提供标准输入（eg. 下单），得到标准输出(eg. 配送服务）的聚合服务。
最初，账户系统仅仅为配送提供一个账户功能，用于记录一个配送员每个月获取的配送员以及商户花费的配送费，如图一
随着需求越来越多，当配送业务有商户支付的需求的时候，这时候账户系统就要去对接并提供收款功能；当财务部的同学觉得登录银行后台上传付款订单是一件非常繁琐并提出需要自动化的时候，账户系统开发代付功能；当内控同学有账务核对需求的时候，账户系统对应开发计费和对账功能，这样的需求数不胜数，我们这个时候的结构如图二
还没有结束，公司的业务越来越好，产品线也越来越多，大家会提各式各样的需求，像图三这样
团队内部讨论的时候，大家有几点感觉:
一直在被业务盯着做功能
有些功能上线后，并不一定被有效使用
有些临时需求太临时，以致于上线后发现会有疏漏
对于团队要做的东西轮廓不是很清楚
团队成就感不足
功能的开发沦为体力上的重复劳动这对工程师来讲，本就不应该；比这更严重的是，大家发现不了自己所做事情具备的价值；团队不知道账户系统到底该做什么？
以上原因催生了账户系统平台化的演变，今年5月份配送和到家的合并，更加坚定了大家这一想法。
我们服务的对象
我们调整思路，确定我们的服务对象是各业务实体，从原来作为配套服务被动接受需求到尝试为各业务实体提供标准化服务，结构如图五：
这样做，好处如下：
团队开始思考我们应该提供什么样的服务
团队开始为各服务添加数据监控并用数据验证结果
避免掉重复造轮子的事情
各模块负责人开始跟外部进行交流，将模块往专业化方向发展
大家在交流的时候很high，现在全团队都知道我们的账户平台的模型会是什么样子。如图六:
下面我重点分享一下我们在账户服务以及管理工具上的实践
在新平台里，账户是交易的基础，一个好的账户服务必须要能够灵活的应对各种场景，我们联想到银行的账户，发现银行的账户有如下特点：
任何个体（人或者公司，当然要符合法规）都可以开户
只需要提供身份证件就可以开立账户
个体间的关系银行不需要维护（比如父子、配偶关系）
我们的账户服务就可以采用银行账户来保证灵活性，我们设立了平台->账户->子账户的层级关系，如图七：
任何业务都是可以来我们这个“银行”开户，我们提供统一的开户、销户、查询接口，账户之间的资金转移可以通过交易服务来进行，这样完成了账户及资金转移的闭环。
一个平台，如果各种业务都需要人工介入，是一个不太优雅的事情，我们提供了一套能够让业务自助接入的管理工具，业务接入的时候，需要完成以下几个操作：
①完成业务注册，获取加密公钥
②配置结算规则
③配置收付款渠道
④配置账户分类
⑤阅读对接文档
⑥进入调试模式，进行调试开发
这个管理工具同时也会提供以下几个主要功能：
查询工具
报表工具
工单系统
我们的目标是通过自助管理工具，不管是财务还是业务接口使用方，都可以一站式解决平台对接、运营管理、财务数据输出等功能。
一个项目并非一开始就需要做平台化，因为这个时候可能你连基本的需求都还未完全弄明白，盲目平台化会导致过度设计，同时设计出来的结果还跟业务不接地气。是否要平台化是一个项目发展到一定时期和规模时必须要问自己的一个问题。目前团队的开发效率是否高效，和兄弟团队合作沟通是否顺畅，项目骨架（即项目应该长成什么样子）是否清晰都是考虑平台化的不同因素。新达达的账户团队未来要走的路还很长，只有更聚焦，更专业的去完善这个平台，才能更快实现“为公司提供最便捷、专业的财务和金融服务”的目标。
联系客服
