求解：银行系统产品化思路 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

看了一个在IT界混了14年的兄，能够感受到一丝酸楚，辛苦自不必说，收入的增加和飞涨的物价相比较已经感受到不到生活质量的提高。很认同。
但是，我相信每个公司都在寻求产品化的道路？今天打算立这么个帖子，希望有经验的人谈谈自己的想法，看看是否在这个圈子里大家能够真正的把东西做成产品化，进而解放所有在一线予以实施的IT人员，让背井离乡的人能够感受得到一些稳定和价值。
我个人的理解如下：
    产品化涉及如下几个方面：
    第一：资金，因为资金才是根本的，没有钱程序员都在家里那公司得饿死。
    第二：高层次人员的稳定和持续。离开了人什么都做不成，更重要的是有经验的人持续的时间越长对公司的产品发展越有价值。
    第三：系统设计的全面性。设计分多个层面：一个是业务要素全覆盖，业务功能全覆盖，这个各家行可以共同遵循。其次就是自扩展性，即各行差异化的需求可以通过非程序化手段定制，可以是懂业务的咨询人员或者银行的业务人员配置完成。再者系统的自我验证能力要加强，验证结果的展现也要加强。这样系统本身的健壮性和自我复制能力就具备了。
    第四：就是强有力的推进。毕竟功能层面应该是要围绕产品不断的升级，而不是针对一个客户全面的升级，那能够做到这一点的可能还是要有强有力的推进能力，即让客户能够理解并接受你的产品，而这要求系统本身是高于银行的实际，高于银行的实际的最好做法就是定期组织学习各家行的业务管理制度，或者紧跟监管当局理解并转化业务需求，之后形成产品化的思路。
    个人认为，就此思路可能产品化的道路为期不远。希望其他有经验的人士能够做更多的分享。
银行系统也要区分为很多种：渠道类，交易类，管理类，报表分析类。。。。
某些系统比较容易产品化，如渠道类的。
而由于涉及到各行的管理思路、管理水平以及历史现状等因素大不相同，管理类的系统要进行产品化，是比较困难的。个人认为，如果系统产品化，可能有这样一些条件：
1、你的公司足够牛，可以满足大部分客户的业务需求，实际上在管理类的系统中，是很难的。还是存在很多客户化开发工作；
2、你的客户比较弱，而且是建立一个全新的系统体系，不会考虑现在的系统现状。这样的客户还是比较喜欢用产品的，因为他们没有需求，没有历史包袱，也可以说是基于产品的需求来设计他们的管理思路。
呵呵，个人认为，银行业产品化只是业内某些IT技术人员的一个美丽的幻想。除非人民银行能够根据财政部的会计准则推出银行的实施细则（而且要相当细，细到需求级别）。否则，根据企业会计准则那样粗的东西，各个行做出来的系统肯定千奇百怪。
某些与业务无关的综合前置、前端界面开发平台等纯技术类的可能能产品化。
其实产品是可以有的，只不过好的产品可以将客户的差异化需求通过页面配置来完成，无需二次开发。
另外，个人认为客户的差异化需求对广大IT企业甚至是开发人员而言是好事。如果行业被某一个产品垄断并且可以一成不变，其他公司还有什么发展前途，我们这些程序员又去那里吃饭呢？就好像QQ垄断了我们的聊天工具，其他聊天工具发展空间很小很小。
个人观点，大家看了笑笑即可，千万别太认真。
我觉得倒不是重点在页面配置，只要是系统结构稳定合理，功能的新增和修改容易，并且不会影响到系统结构就可以了。主要还是在于系统的规划和消除模块耦合上要做好。
看过一些讲究配置的系统，发现弄这个配置比原来修改程序的做法更复杂更难看，甚至还要在配置里实现表达式计算，这样又何必呢。使用了配置能简化系统的，那就用配置，不能简化的，还是用程序好了。
高内聚，松耦合的设计是每个设计师追求的目标。对问题域的理解程度，决定了对问题域划分的合理性。这种能力是完全可以培养的，面对新的问题多问些“答案似乎很明显”的问题，也许真的可以发现他山之玉。
昨天看了《软件架构师应该知道的97件事》，有位大拿说了句很形象的比喻：开发人员痴迷于复杂的问题，好比飞蛾喜欢扑火。谁能拒绝迅速解决复杂问题带来的快感呢？
讲产品就要讲架构，而一个好的架构怎么得来呢，需要知识的积累，需要实践的积累，需要人员的积累，这些都需要沉淀，而往往公司在沉淀这一块被忽视，没有好的产品沉淀机制和流程，没有好的产品总结归纳机制和流程，很多好的东西一盘散沙，没有形成合力，没人去整这些东西，可能目前很多公司都疲于应付项目实施，大家都很忙是事实，但还是可以做好一些，很多东西追究到最后还是管理上的问题，所以管理上的问题是一个比较大的问题
另外，讲架构，谁能把一个产品的定位、业务流程和管理办法等涉及到有多少可能性列举清楚，谁就有资格来谈架构，所以，对业务的理解也是一个比较大的问题