银行业务需求分析模式及路径初探 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

随着近年来各大商业银行信息系统建设的持续推进，IT治理和管理分析水平不断提高，组织成熟度上升，作为整个信息系统建设的上游——需求分析和管理这一环节也取得了长足的进步，但是随着业务的不断发展，由于新的业务品种、新的产品功能的出现以及监管的日益精细化，需求的分析和管理遇到了新的挑战。本文旨在通过梳理目前典型需求的管理的现状，探索改变粗放管理和静态管理的方式，从不连续的阶段管理向全生命周期管理，从分散式管理向集中式管理，从定性管理向定量分析管理(成本和工作量)，从宏观指导到技术分析操作等方面的可能的管理方式。以此为后续的需求编写、规格分析、计划制定、需求规模评估、变更影响评估等方面提供参考依据，并通过建立软件规模评估体系，为外包项目的商务采购提供估价依据。需求分析和管理远期目标更是建立全行需求库，提高需求复用和配置的质量，需求管理流程从非工厂模式向工厂模式方向转变，形成需求立体视图，构建需求提出部门、需求管理和分析部门与需求实施部门的高效合作关系，有力支持业务部门快速推出产品和服务。
一、需求的分析和管理现状梳理
需求的分析和管理遇到的新挑战主要表现在以下几方面。
首先，各大商业银行基本都已经有组织级的项目计划，但是没有与之匹配的企业级年度需求计划，需求在评审、需求说明书编写模板等方面已经有比较完善的流程和电子化管理方法，而且这些方法和项目管理方法已经很好地进行了整合，满足项目实施的生命周期的跟踪等管理要求。但是目前尚缺乏需求跟踪、需求量化评估、需求精细颗粒度管理的成本评估，还没有从需求实体视角下的需求全生命周期管理的完整规范、规格以及需求管理信息化管理工具，无法从需求本身的视角上来审视需求本身进化和各控制节点。其次，从需求全生命周期管理的组织职能配备上来看，还没有需求专业化管理的专人和职能团队配备，需求的管理在职能上分布在不同的项目管理角色中，存在职责定义粗放，参考规范缺乏，或者规范本身有待完善等问题;需求本身也没有进行分层，目前业界理解的Kano模型中的基本需求、满意需求、吸引力需求没有在需求编写中进行识别和区分，从开发层面理解的系统需求和组件需求也没有在后续的分析过程中体现。
再次，从组织过程资产的角度来看，当前大量的需求(含总部历年形成的各种开发类的需求)并没有形成统一规范的需求库，需求质量在形成和积累的过程中没有大幅提高，规范性也没有获得很好的提升，在需求复用、检索、查询以及信息化支持上缺乏与其他系统很好整合的需求管理系统，依然存在大量的手工操作，效率低下，错误率高。从上游的需求提出部门来说，需求编写、形成、涉众分析、需求横向整合、需求和实施部门的有效沟通和效率提升还没有形成有效的共识和工作方法。
最后，从需求工程的结构上看，各行在需求确认(评审)、需求调查(已规划)、需求变更(变更流程已覆盖)、需求定义(需求模板、规格书模板等)已达到了相当的成熟度(见图1绿色边框部分)，但是在需求分析(含定性和定量分析)、需求跟踪(多维度的跟踪矩阵、建立与维护“需求文档-设计文档-代码-测试案例”)方面还比较欠缺，需求是不连续的平面，而不是立体的。

随着各行各项目(群)的推进，目前遇到最为迫切的问题是需求的规模、复杂程度、影响范围、成本估算、厂商报价的合理性等诸多和需求评估相关的问题需要解决，来保障新一代项目的顺利推进。而这些问题的解决都需要一个共同的前提基础，需求必须进行细颗粒度的量化管理，才会形成对计划、预算、商务以及后续组织过程资产的有效支撑。
二、分析模式初探
1.类比法
类比估算方法是一种通用的需求估算方法，这种方法操作起来比较简单，但是适用范围有限，且对估算人员的个人经验有很高的要求，从本质上来说是项目管理理论中的专家评估方法的衍生应用。类比估算方法需要估算的标的需求拥有类似的参照对象，相似度越高，则类比估算的结果越准确。类比方法的理论也有一些进步，例如有人引入欧几里德距离来计算项目的相似度，并且产生了ESTOR、ANGEL、AQUA等估算辅助工具。类比估算法方法操作成本低，参考值更多地参考实际操作的数值，是广泛使用的需求估算方法之一，但是难以通过流程来标准化，存在偏差也难以进行可续的更正，偏差值难以估量，只能事后补救，所以又被称为是“换人拍脑袋”法。估算人员又有不同的个性化的方法，颗粒度理解不一，随意性比较大，有的人自顶向下，有的人自下向上，因为没有模型支持，很容易有遗漏掉的内容，加之不可能存在完全相同的两个参照标的，所以这种估算方法只能作为整体估算中的部分估算的方法。
2.模型法
在软件工程和系统工程中，用例被定义为是一种通过用户定义的外部执行者和系统之间相互交互来实现的业务目标。这里执行者可能是一个实际的操作员，也可能是一个虚拟的操作员，例如一个系统或者就是另外一个用例。由此可见，在实际的业务环境中，用例代表着系统中各相关人员和系统之间行为交互所达成的契约。在不同的条件下，执行者通过发起于系统的交互来获得期望的目标，用例是最直接的、最有效描述目标的方法。每个用例下面可能包含着执行者不同的输入而产生的不同的返回结果的行为序列，所以一个用例可能是包含着多个业务场景的集合。
业务建模的方法(不仅仅先于UML和用例图)是以模型的方式描述业务所设计的对象和要素，以及其属性、行为和彼此关系。业务建模强调以体系的方式理解和构架业务信息系统，通过组织模型、业务流程模型、领域建模等多种模型来度量需求的范围、复杂度、交互、成本、接口关系等难以以单一维度和局部测算与预测的难题。通过模型可以更高效地进行需求的整合、梳理，这既是降低系统描述复杂度的方法，还是进行基于更为直观可见的目标导向的方法。业务建模不仅可以对单业务系统进行建模，也可以多系统建模;既可以进行通用业务模型进行建模，也可以对新业务进行建模。面向对象的用例是最终用户可以看到的结果，通过模型抽象，形成和现实世界的映射，辅助生成需求和需求规格，以需求用例的数量和体积来计算需求所需的成本和工作量。对于用户成熟度不高的银行来说，也可以选择更为传统的面向数据的结构化建模，即跟踪数据的流动、变化和转化，通过数据流图来描述需求，进行有效的输入、输出和文档管理，进行数据的来源和分层加工。特别是对于那些以数据触发的需求，面向数据的结构化行为模型更易进行数据字典管理和数据完整性管理，使用的技术语言更容易被技术部门和项目组理解，例如使用ER图来创建所有重要的数据对象的标识，使用状态图来创建行为模型等。
3.IFPUG功能点法
理论上，IFPUG功能点法最早是由IBM公司在1979年提出。通过功能点继承的方法，从复杂性和特性两个角度来量化需求。这种方法的好处是在需求分析估算之后进行，结果比较准确，容易形成历史收益。这种方法后来被国际功能点组织IFPUG所采用，更适合于管理系统的软件需求工作量估算。从用户需求和逻辑设计的角度出发，对软件规模进行度量，理论上与具体实现的技术语言关系不大，功能点估算可以用于需求文档、涉及文档、源代码、测试案例等软件生命周期的各个阶段。实践上根据方法和变成语言的不同，计算出功能点和代码行。IFPUG的功能点计算方法是目前的主流理论，已经演化出多个版本，例如英国软件度量协会的 Mark IIFPA方法，荷兰功能点用户协会的NEFPUG方法以及通用软件度量协会的COSMIC-FFP方法。功能点估算的步骤如图2所示。

4.CMMI中的思路
其基本思路来自于CMMI中的度量过程域、需求开发过程域、需求管理过程域。其中，度量过程域的目的是指定度量、分析技术、数据搜集、数据储存以及报告与回馈机制，执行数据的搜集、储存、分析及报告，提供客观的结果以便作出有根据的决策，并采取适当的矫正措施。CMMI度量过程域更多地强调从项目这个视角来进行度量。
需求开发过程域的关注点在于产出并分析客户、产品及产品组件的需求，也包括与产品生命周期各阶段 (如验收测试准则)及产品属性 (如安全性、可靠性、与维护能力等) 有关的需要。需求功能的定义，也称为功能分析，与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。在面向对象的软件设计里，它相当于定义所谓的“服务”或“方法”，所有这些最终都要落实到设计文档和开发代码中。从技术规划部门和项目实施部门来说，可以不参与具体的需求开发的工作活动细节，但是需要提出需求开发交付物的标准，即清晰、完整、一致、规范的需求。
需求管理过程域强调的是需求管理过程中的了解需求、取得业务部门对需求的承诺、管理需求变更、维护需求的双向可追溯性以及项目和需求之间的界面与差异。当项目成熟且需求已产生后，全部的项目活动或专业领域将接受需求。须建立准则，以指定需求的适当的接受管道和正式来源。执行需求接受活动时，须与需求提供者一起分析需求，以确保对需求的含义能达成共识。需求必须是表达清晰、完整、一致性保证、可验证、可追溯和可实现的。 需求承诺过程要求在项目进行期间，需求进行渐进开发，尤其是在需求开发过程域和技术解决方案过程域的特定实践的说明中。关于需求变更，CMMI并不拒绝变更，而是合理变更，按照审核流程进行变更，变更的结果须纳入到需求追溯过程。
5.BABOK中的思路
BABOK是国际商业分析协会关于业务分析方面的经典论著。国际商业分析协会本身是一个独立的非营利组织，专门致力于业务分析。BABOK的主要思想来源于基于专职业务分析师这一角色展开的一系列分析方法和活动，值得借鉴的思想举例如下。
(1)业务分析师不是在一个“真空”的环境中工作，而是处在一个复杂的业务环境中，因此特别强调涉众分析与动机分析。
(2)业务分析师与技术开发人员的比例是1：6或者更小。
(3)需求的四个基本组件是：人、信息、流程和规则。
①人是可能包括的机构内部和外部的个人或者部门;
②信息就是数据;
③流程是实施业务的手册、自动执行的活动或者流程;
④规则是业务活动运行需要遵循的业务规定和指导原则，规则环绕着其他三个组件存在。
三、推进路径初探
根据此前的分析，商业银行需求建设战略蓝图应分成三个阶段(如图3所示)。从战术和操作层面，主要工作重点如图4所示，应参考不同的组织成熟度，合理选择突破点和具体落实方向。


最终目标是形成需求量化、可复用的落地操作性方案，建立起组织级的需求库，通过积累各项目工作量与功能点数据样本，提高技术平台维度或业务板块维度的生产效率。
商业银行业务范围和复杂程度的不断提高，不但给业务部门在需求收集和编写方面提出了挑战，也对需求的实施建设部门提出了挑战。需求分析和管理是整个业务需求功能建设过程中的上游环节，从长远来看，企业级的需求库、需求的精细化分析与管理、需求的复用与规格化是大势所趋。笔者通过以上的探讨，希望能起到抛砖引玉之效，以发现更多更好的最佳实践和方法模式，切实提高商业银行需求分析和管理的水平，从而从整体上提高商业银行的竞争力
我也觉得是写的具有总结性和前瞻性，可以参考。
可能受制于篇幅文字所限，不少地方没有展开，有些缺憾。
我不这么认为，技术总说业务方面没有做好需求的规划，问题是很多时候业务发展是迅速，有的时候甚至是不可预测的。即使是内部管理类系统所面对的管理热点的变换速度也是很快，技术总是说要想清楚做好规划再提需求。面对新热点、新业务、新问题，业务人员的认识也是逐步深化和全面的，只能是先能管住哪些就要要求系统实现哪些，变动和重复工作以及无用功肯定会有。但是如果站在技术的角度，要求业务把管理和制度理顺了，不变了再提需求，有的时候新业务都停了，热点也过了。
所以我还是想问，系统的定位何在？如果是为了辅助管理，这事就应该配合业务逐步的完善管理。如果是为了一个达到理念中完美的系统，那么业务只能手工管理这些新业务，新热点，新问题。各位，你们选择哪一边？
以前我作为乙方，也觉得业务这样很烦，怎么不想清楚就提。现在换个角度想，难道因为没有想清楚，我就不去面对这个新问题、新业务么？逼着业务不得不用纸质或EXCEL来进行管理，这是不是也可以视为是开发的不作为或懒政呢？
我觉得应该对于系统需要处理的问题分为两类，一类是常规性的操作（业务系统就是常规业务，管理系统就常规的管理和查询），这部分应该是业务有一个规划，主体架构也应该保证稳定。另一方面，是临时性的问题，如创新业务、新的管理热点。这部分如果在系统设计时有足够的冗余或者前瞻的考虑能够处理或者通过系统配置能够处理，当然是最好的。但是我觉得完全指望在设计层面百分百包容是不现实的，总会有超出预计的新问题。如果我们安慰自己说，哎呀暂时性的问题，系统不需要做回应，业务自己管管，过一阵业务不做了（热点转移了），就过去了，还节省开发资源。因此就采取挡和拖的策略，确实是一个办法。但是有没有更好的方法呢？
所以系统的前瞻性就是一个比较考验功力的地方了，这需要功能设计者对业务实质的深刻理解，需要对金融理论和业务实践的双重把握。
能做到这一点，其实去做金融产品的设计也可以了
所谓前瞻性，不过是根据过往经验的判断。这两年的一些新问题让从业二十多年的老业务专家都要重整思路，这时要求提高设计上的前瞻性，就是一个推辞罢了。