投行IT系统之乌托邦-客户端(客户端项目工作投行产品)

一、客户端的必要性

在金融科技领域，尤其是一级市场，大量的软件产品是以web形式呈现的，这主要是因为以往的投行IT系统主要以处理结构化数据为主，偏重数据的计算与展示，UI交互体验和性能往往不是最主要考虑的因素，但是随着数字化转型的不断深入，提升投行项目组日常工作效率的需求越来越迫切，项目组已经不满足原先的Wind客户端+Excel+Word+各种宏的模式，希望有新的产品进行赋能，这就需要新的软件系统在性能和使用体验上要有明显的提升，近几年一些金融科技公司在客户端方向上进行了很多尝试，包含一些结构化搜索的App，以及一些文档（PDF、图片）处理软件，其中一些在项目组中也有了不错的口碑，解决了部分痛点，但是所有这些产品还是过于松散，尚没有形成体系和标准，下面是需要建设客户端产品的最主要原因：

项目组成员尤其是承做人员由于需要处理大量的文案工作，往往是各种客户端的重度使用者，对word、excel等产品的快捷键非常熟悉，能够快速的完成刷报、格式调整、财务数据计算等工作，甚至可以用宏进一步提升效率，个别项目组还会使用Python处理数据，项目组的工作习惯决定了，他们对产品性能的要求极为苛刻，web端的操作很难达成这种体验，很多金融科技公司在把web类产品落地到中后台有很多成功案例，但是在项目组却很难落地，原因就在于此，就好像你要求一个资深程序员不能用idea或者virual studio写代码，而要去用web ide，痛苦程度可想而知。

项目组的工作地点散落在全国各地，而发行人现场和旅行途中的网络情况好坏不一，很难保障实时在线，同时由于投行对数据安全性的要求，所有数据要集中管理，通常互联网公司经常采用的数据分发方案也不能使用，导致了web服务的可用性更难保证，而项目组在客户现场又要提供高水平的服务水准，这之中存在一定的矛盾，所以web服务无法进入项目组的高频使用场景。

项目组的工作在包含大量的重复劳动同时，还有更多更高水平的创新性工作，如何减少项目组重复劳动的同时，保持项目组工作的创造性，这是一个很重要的问题，所以投行工作平台应该是一个创新的工具，而不是把项目组的工作变成流水线的工具。
web端和客户端的核心产品理念差别就在于此，客户端产品由于能够利用本地的计算资源，倾向于把产品设计成项目组的单兵作战装备，就像项目组思维的外骨骼，根本因素还是人，系统是用来辅助人的工作，项目组可以在客户端中找到各种玩法，而web系统天生的需要标准化，流程化，很难像流水一样顺应项目组的工作需求，当然，这里不是说只要客户端不要web，我们要区分哪些产品适合用web，哪些需要用客户端。

二、客户端如何技术选型

客户端有很多的技术方案，选择哪个确实需要斟酌，这里想写一些自己的想法，仅供参考，首先说结论，投行自己开发产品用JavaFX，金融科技公司要输出产品用Fultter。

QT作为最流行的客户端框架之一，确实要放在第一个说，QT使用C++作为开发语言，有Widget和Quick两种开发模式，Widget相当于传统的窗体开发模式，Quick融合了触摸屏方案，开发方式更趋近于web，用QT开发投行工作平台优势是效率高、能跨平台、未来支持国产化，缺点也很多，例如：C++研发人员成本高，团队培训难度大，更重要的是跨平台调用需要极高的工程化水平，一些轮子比如Apache POI、drools等就不太好使用了，可能要重复造很多轮子，虽然QT有些其他语言的Port，例如QT Jambi、PySide等，当时往往落后于主版本，而且维护不及时，不建议选择，总之，除非实力超强的公司，否则不建议用QT。

微软传统的客户端平台，使用C#开发，在windows平台是比较不错的选择，也有比较完善的P/Invoke跨平台调用方案，看起来不错，但是有几个致命的问题，首先是无法支持跨操作系统，mac、linux或者未来的国产化系统无法使用，其次就是UI渲染框架过于老旧，无法灵活的进行样式调整，直接的结果就是winform程序往往都比较丑，工业风较重，而且资深的C#开发人员一样很难招到，所以不推荐。

作为Winform的继任者出现，使用C#和Xaml语言开发，原生支持MVVM设计模式，UI可以做的很漂亮，但是同样不支持跨平台，只能很惋惜的排除掉。

可以说是最近超火的客户端框架，使用JS开发，开发成本低，由于V8和Node.js的加持，既可以用web端的渲染方式，又能访问操作系统的底层资源，看似很完美，但是也存在很多问题，因为使用web的渲染方式，其实还是存在性能和交互问题，可能有人说vs code也是electron开发的，性能很好，这个时候不要忘了微软自己对框架做了大量的优化工作，而且跨平台调用也不太容易，综合考虑也只能排除掉。

之前的所有缺点都没有，之前的所有优点都支持，唯一不足就是不支持手机客户端，建议选择。

同上，但是支持了客户端，技术很cool，又有google这样的大厂支撑，可以考虑。

三、客户端的产品思考

客户端应该支持三种状态，离线模式、联网模式、连内网VPN模式，不同模式应该能使用不同的功能。

为了应对协同写作以及数据钩稽的场景，应该使用latex派生一种投行专用的文档格式（这个后面具体写），而不是在word或者纯文本之间改来改去。

客户端应该包含web浏览器，可以访问内部系统，同时要支持JS sdk，从web端调用本地资源。

客户端应包含对底稿文件的管理。

客户端应具备RPA功能，以及尽可能多的工具集。

四、总结

这篇文章就写到这，后面的产品思考有些少，因为内容是在太多，后面会成体系的讲一下。