【心得体悟】我在资产管理公司那些年

公司介绍

之前所在的公司是做金融服务的公司，管理billion级别美金的资产，主要的经营业务可以分为三块：

1. 一块是为大型客户定制的资产管理计划。类似于信托。
2. 一块是提供金融咨询和指导，比如中小规模的银行发展到达瓶颈，这个时候我们的人就会去帮助分析现有的业务结构并给出哪里可以改进的意见。
3. 一块是它自主研发的一个管理账户及资产的综合性平台，面向的是企业。在这个平台上可以做资产管理（Portfolio Management），交易管理（Transaction Management），账户管理（Account Management）等。

其中，最赚钱最稳定的，是第一项，收取佣金，额外收益根据市场表现有一定波动。第二项和第三项一般是捆绑销售的，也就是说我们不仅卖咨询，还卖服务，卖平台。这个的业绩根据销售表现波动较大。有句话借用到这里形容得很好：三年不开张，开张吃三年。

我的项目

这个平台有很多模块（功能）。比如资产管理，在这个页面上你可以看到自己的持仓，并进行调整。当然实际操作起来还是比较复杂的，根据你是什么类型的投资者，会做出一定限制。比如你是保守型的，那么一些高风险的资产就不能买入或者限制在一定比例内。

我在里面开发有关美国税务的模块。合理避税，是每个大公司几乎都会做的事情。比如，将公司注册在一些免税的州。当然，这个操作是属于人工服务，咨询师和公司管理人员关起门来讨论一番，出台一些具体措施。
这个税务模块的主要功能，还是正常地走流程，收集财务信息，给公司报税。

具体的任务，举一个例子来说吧：比如美国最新上台了一个法案，对于某些资产可以进行税务豁免。于是，我们系统就需要跟上政策的脚步，做一个预扣税豁免资产模块（Instrument Exclusion for Backup Withholding）。
解释一下，对于有些税务的缴纳，是预扣税（Backup Withholding）。比如今天我做了一项交易，除了正常的交易费用之外，还会额外交一笔钱，当作预先缴纳的税费。
到了最后每年报税的季节，再具体地算一算钱，多退少补。但是，对于某些资产（Instrument），是不需要预扣税的，即可以被豁免掉（Exclusion）。
那么这些资产，就需要被记录下来，并且被集成到系统中。一来，当交易时，Exclude掉这些Insturment，二来在报税的时候，同样Exclude掉这些Instrument。

具体的实现并不难，一个方面，前端需要新做一个页面，用于录入哪些Instrument需要被加入Exclusion。这里也许有的同学会问：为什么需要专门写一个page来做数据录入？直接让客户把一个list给我们，然后我们在后台插入不就行了吗？
原因是，这跟平台本身的定位有关。因为我们要做的是根据不同客户高度定制化的平台。即每个客户的list可能都不一样，数据库也不一样。所以不能笼统地自己预先配好数据，而是要把功能做好，然后选择权交给客户，从而让他体验到平台强大的功能。
举个类比的例子，比如微信，打开App，每个人都有朋友圈这一页，显示一堆信息流。如果有用户完全不用朋友圈，不想看到这一页，能不能不显示呢？或者，我不想看信息流的形式，而是一个列表的形式，可不可以呢？这里就需要高度定制了。
另一方面，后端需要加入Exclude Instrument计算逻辑。

使用到的技术栈是：Struts + Mastercraft + OracleDB + Weblogic + Jenkins + SonarCube。

我的同事们

俗话说，三人行必有我师，从身边的同事身上，能学习到许多宝贵品质。

首先是我们厉害的PO（Project Owner），她是一个50多岁的白人女性，工作干练，认真负责。每次有新的需求，都会经由她审核，是否合理，是否能集成进我们的平台。最终出来的需求文档非常明确，不会存在模糊不清的地方，照着做即可。
我们能一次次按时交付，和她一开始定需求定的准有很大关系。从她身上我学到了应该重视业务。

然后是上进的Strum Master，他是一个30多岁的白人小哥，他每天组织我们开会统筹项目进度。同时相当于我们组和外界的纽带，如果有需要和其他组协作的地方，他会积极帮助我们沟通。他给人印象最深的是非常有进取心，和他谈话能感受到满满的活力。从他身上我学到了有时候当面交流比邮件交流更有效。

然后是黝黑的印度开发小哥，他话不多，比较资深，一开始税务模块的几个关键部分就是他和PO合作一点点搭建起来的，对我们组的代码架构以及一些坑比较熟悉，属于全栈式人才。从他身上我学到了专注技术，低调做事。

最后是精明的犹太人小哥，他一开始是在银行做交易员，然后跑到我们公司当QA。他很能聊，时不时会给我们讲自己工作外的宏伟创业计划。从他身上我学到了对市场的敏感。

工作时长

关于工作时长，一般来说是955。中间有一小时的吃饭时间。刚进去的时候因为要快速熟悉系统，埋头猛干了3个月，然后就把整套技术栈摸得差不多了。熟悉了之后，工作强度是比较低的。一般5天的工作量，3，4天左右就可以搞定，剩下来的时间自己安排，可以学学习什么的。

不过说真的，在这种低强度的环境下，要坚持高强度学习不是一件容易的事。我习惯是上午干半天活，然后下午看一会技术博客。三点多抬头一看，一个老哥在刷亚马逊，一个老哥在刷机票，一个老哥晃悠晃悠，过来看到我在学习，然后开启嘲讽模式。
这里没有瞧不起其它同事的意思，这些老哥们都是比较nice的人，算是好相处的。这里的氛围就是这样，只要你能按时干完活，其它的没有人管。

但是，也会有真的出线上事故的时候，这个时候就别想着955了，老大会搞一个紧急作战会议室，每小时通报一次问题解决的最新进展。如果你在小组里，那这个时候就要有点眼力劲儿，卯足了劲干，即使和你没啥关系也要摆出一副如临大敌的样子，毕竟要和公司（老板）同进退嘛。

业务为王

最后，最重要的事情要说三遍：懂业务，懂业务，懂业务。这一点在这个项目中倒体现的不多，原因是我们有一个厉害的PO（Project Owner），她会把用户需求掰开了揉碎了再以书面形式写给你，而且几乎没有过需要二次加工的。但是，如果要往上升职，一定是要懂业务的。

从公司组织架构形式上来说，一般都是把一个大的项目切分成很多小块，分到一个个小组手上，然后每个组（长期）负责这个这一块的内容。想要升职，势必要首先对自己的一小块了如指掌，不仅仅是技术，而且是之后可能的（业务）发展方向，然后再慢慢（想办法）接触其他模块，最后才能做到统筹全局。我们的Scrum Master小哥就是这样，一开始只带我们一个组，带得不错，然后慢慢地又带了另外两个组，之后估计有很大可能再往上。

这是管理方向的，至于技术方向走架构师，个人感觉从内部上升的道路是比较难的。一是要慢，一般比走管理慢；二是如果能力到了，考虑跳槽去中小公司做架构可能施展空间更大（从头开始，成长空间大）。
同样地，业务在这里更是必须。因为你需要根据业务做技术选型，最终实现的时候，用什么不用什么，都是拿需求说话的。