关于证券公司自主研发的几点思考

标签: 证券公司 研发 思考 | 发表时间:2016-08-14 12:00 | 作者:何波
分享到:
出处:http://www.zhihu.com
面向个人的券商的经纪业务与互联网业务并无本质区别
我们可以将券商的经纪业务分为面向中小投资人的服务和面向机构投资人的服务,对于券商来说,经纪业务收入是业务收入的重要组成部分,大部分券商的经纪业务收入超过50%,做的比较均衡的券商比如海通证券,也占有接近40%的比例,由经纪业务而衍生来的财富管理、投资顾问、理财销售收入更是未来很大的增长部分,面向中小投资人的服务来说,这种模式和互联网的模式很类似,本质都是通过软件(pc及移动客户端)服务个人投资者,通过增值服务或直接收费获取收入,只是互联网企业基础服务免费,而我们的基础服务也是收费的。反观互联网企业,大到腾讯、百度、阿里、网易、搜狐、小到创业公司无一例外地都是自主开发面向客户的系统。腾讯、百度、阿里均有几万名开发人员。在证券领域内的东方财富网,也拥有600多开发人员,所有系统均自主开发,在收购同信证券后,组建了200多人的开发团队进行集中交易系统的自主研发。再看国外的互联网企业,facebook、google等无一例外也是如此。为何这些互联网都如此一致的选择自主研发?这是因为唯有自己研发的系统,才能随时响应客户的需求,才能在用户数快速增长的时候,迅速调整架构,适应变化。因为面向用户的软件是一个随着用户需求变化、市场变化而进化的过程,这个进化的过程是一定要把握在自己手里。

比拼研发实力的的机构经纪业务
再看面向机构的经纪业务,这里很重要的一块是面向私募投资人的pb及交易服务,尤其是量化投资的私募。现有的大部分券商给私募客户提供的PB系统,交易通道基本全是采购自第三方,包括恒生、讯投的PB系统、金证顶点的快速订单系统、深交所的OES极速系统等,这必然导致对客户的服务同质化,并且不能根据客户的需求调整、定制。还有一个致命的问题在于,因为不是自主研发的系统,在服务客户的时候,对系统深层次的机理不够熟悉,导致服务也需要联系厂商,这也必然导致服务效率的低下,并且导致客户的不信任感。而要真正服务好私募客户,必须要有全线自主研发系统的决心,从PB到后台的交易系统,要有做脏活累活的决心,为私募投资人打造有竞争优势的交易通道、打造个性化的交易和行情系统、搭建私募云服务、提供有差异化的增值服务,这些都离不开长时间的自主研发,离不开一支具有证券背景的研发团队。

外包的困局
在传统的企业以及券商内,都有一种想法是内部的IT人员做项目过程管理,具体的开发任务交给外包来做。这在需求固定、对用户体验要求不强的内部系统是可以采取这在开发模式。而对面向客户的系统,采取这种模式有百害而无一益。软件产品不是交钥匙工程,是一个不断迭代、不断重构、不断进化的过程,在这个过程中,我方团队不能真正参与代码编写是无法掌握和接手代码的,也就导致重度依赖于外包商。
同时我们要深刻认识到,从软件工程的角度来说,软件行业还远没到达工业自动化的程度,软件开发依然是一个极具技术挑战的工作,软件产品的质量依然极大依赖于代码编写的质量,而代码的质量又依赖于工程师自身的技术水平、团队的磨合程度、对项目的认同程度。而外包团队的开发人员质量是远远落后于互联网企业,对项目的认同也远低于自有开发人员对项目的认同,这导致外包团队产生的代码质量低、扩展性差,也不能形成统一的风格。
打造一支有凝聚力、配合默契的研发团队,对产品的进化有着极其重要的意义,通过企业文化的塑造,让团队认同为之努力的产品,并投入心血与其中,这是产品质量和品质的最大保障。

研发实力及基础组件是公司重要的 值钱的资产
在自主研发的过程中,可以形成大量的可重用的基础组件,也形成针对具体行业的模块和解决方案,比如行情的解析与分发、证券行业的大并发组件、大数据算法组件、以及各种中间件、微服务组件等。这些组件也是公司重要的资产和财富,也是科技类型公司最值钱的资产,所以自主研发过程中创造的源代码是有着非常重要的价值,也需要在研发过程中鼓励技术创新,鼓励技术探索及积累,并最终形成技术壁垒,这在科技行业也是比比皆是的案例,腾讯、百度、阿里均有针对自身行业特性的积累,均有深不可越的技术护城河。华为在这方面也是典型的案例,华为基本法中写明每年收入的10%投入研发,也正是华为多年的坚持研发投入,才成就华为现在的地位。

灵活的薪酬及晋升制度筑巢引凤
曾经有篇文章问:互联网的泡沫什么时候会破灭?我记得在10年前就有观点认为计算机行业开发人员很快要供过于求。然后从现在的发展来看,软件开发人员的增长速度远远跟不上需求的增长。在各行各业互联网+的大潮下,在互联网、移动互联网、物联网、虚拟现实、人工智能等等的蓬勃发展下,软件工程师的需求越来越旺盛。然而,软件行业又是一个需要长久学习的行业,一个成熟的软件工程师至少需要在工作中学习2-3年,优秀的软件工程师更是极度欠缺。因此我们需要充分认识到我们是在和互联网等科技行业抢工程师,而不是和券商抢工程师,所以我们需要有和互联网比有竞争力的薪酬和灵活的晋升机制,需要有类似互联网一样宽松的环境和正向激励政策,筑巢引凤。

来源:知乎 www.zhihu.com
作者: 何波

【知乎日报】千万用户的选择,做朋友圈里的新鲜事分享大牛。 点击下载

相关 [证券公司 研发 思考] 推荐:

关于证券公司自主研发的几点思考

- - 知乎每日精选
面向个人的券商的经纪业务与互联网业务并无本质区别. 反观互联网企业,大到腾讯、百度、阿里、网易、搜狐、小到创业公司无一例外地都是自主开发面向客户的系统. 腾讯、百度、阿里均有几万名开发人员. 在证券领域内的东方财富网,也拥有600多开发人员,所有系统均自主开发,在收购同信证券后,组建了200多人的开发团队进行集中交易系统的自主研发.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

推行TDD的思考

- - 简单文本
目前来看,推行TDD的障碍大约有如下几点:. 分析需求并进行任务分解的能力; 3. 将测试作为开发起点的开发习惯; 4. 开发人员的重构能力,包括如何识别坏味道和如何运用重构手法; 5. 单元测试的基础设施,尤其是测试数据准备;. 开发人员对于软件质量,常常偏重于软件的外部质量,体现在他们的工作效益上,就是被测试人员发现的缺陷数.

对于理财的思考

- - 吹风吹到疯
但是我要说:你若理财,财也未必理你. 我应该算是比较买基金的,大概是04年开始买了,曾经翻番过. 也尝试过炒外汇,那真的是没赚几个钱而花费好多力气,我也买过理财产品,有幸没有亏本已经不错了,也想去尝试炒美股,还好没有花精力进去. 反正这么一圈下来,我的理解就是:不要追请求理财了,先整明白自己要什么吧.

谈CIO思考之重点

- - 人月神话的BLOG
在这里主要针对中大型企业有专门的IT部门和独立开发运维团队的情况,对于这种企业的CIO,核心的一些思考点在哪里,和常规软件企业又有哪些差异. 对于企业IT部门是成本中心,在开源节流上,利润中心的重要性和关注度还是远远高于成本中心,这也是很多企业IT部门往往不受重视的原因,CIO本身也没有太多的决策权,在本身没有太多独立开发能力时候更多仅仅是一个运维中心的角色.