企业级需求管理工具调研报告(2020年3月)

企业级需求管理工具选型报告（2020年3月20日）近年来，随着利率市场化、互联网金融的冲击，银行面临市场竞争压力越来越大。

特别是商业银行一方面要面临互联网金融企业（如：支付宝、微信）的市场挤压，必须持续业务创新，推出特色金融服务产品，发挥银行金融科技的优势；另一方面也面临的银行监管越来越严，对产品创新、IT建设与管理、风险控制的合规性要求也越来越高。

因此，面临当前的竞争格局，倒逼各家银行在加快业务创新，加速数字化银行转型升级，加快IT系统建设和新业务快速投产运营。

但现实的情况是，随着软件项目和开发规模急剧扩大，外包大量引入，这种大规模软件开发管理过程，对我行科技部门提出了很大的管理挑战，特别是需求作为开发过程的第一环节显得尤其重要，快速形成高质量需求、精准传递和管理需求，是IT项目成功的最重要条件。

业务人员都希望能够以简便、快速的方式完整、有效表达对IT建设的要求，科技部门人员也希望能够从业务部门获取到尽量真实、完整的业务要求，以指导系统建设不走偏、不变样。

但实际工作过程中，业务部门与科技部门之间，需求传递失真、各说各话的情况很多。

在我行Fintech数字化转型时期，科技开发对需求管理提出了新的要求，作为科技开发首要环节，快速形成高质量需求和高效的需求管理过程，是开发质量和效率双提升的必要条件！由此，改变过去传统的粗放式管理方式向需求精益化管理模式势在必行。

采用科学的需求开发方法和管理过程，对于消除业务部门与科技之间的隔阂、提高业务需求质量、提升IT对于业务的支撑能力，具有重要作用。

那么，选择什么样的管理工具才能合适自己？能帮我们解决什么问题？能帮我提升开发和管理效率吗？平台选择的标准是什么？这是各家银行CIO正在思考的问题。

一、银行业需求管理面临的共性问题当今在需求工程领域以需求为主线、发挥科技对业务的支撑能力方面，发挥着重要作用。

但随着业务的不断发展、创新，业务部门对于应用系统建设及使用的响应效率和支持能力要求越来越高，一方面由于银行业务的复杂性和项目实现的复杂度，需求的复杂度和关联性很强，从需求提出到需求实现的周期较长、路径复杂，使得需求传递、需求变更、需求跟踪非常困难，极易出现失控。

以文档为管理单元的传统方式进行需求的管理，已经无法满足精细化的需求管理要求，日常应用管理实践的一些问题有待尽快解决，典型的主要问题包括但不限于：业务部门总是觉得开发太慢，对科技部门的响应和支持能力不满意。

需求标准不统一，需求文档千人千面，需求质量不稳定，良莠不齐需求来源复杂，需求噪音多，内容交叉严重，内容冲突多管理过程随意，过程无记录，不留痕，无法跟踪，需求内容变更过程、演进过程无法跟踪，需求变更混乱，传递失真，找不到最新版本管理制度（如：质量）永远停留在纸面上，缺乏有效的管理工具，手工处理工作量大、繁杂容易出错，且不可维护，需求管理手段无法落实到到日常行为中，无法有效运用协同困难，职责交叉较多，跨部门、跨领域、跨项目协同困难需求传递链条长，协同效率低，无法精准快速传递到开发团队，总是问题不断，来回折腾，频繁返工需求资产无法沉淀，系统经历多次改造和历年变更后，无法获取最新的完整需求。

二、同业银行需求管理及工具发展趋势鉴于银行企业需求的复杂度，对需求管理带来很大的挑战，各行都在需求管理方法和平台上进行了很多尝试和努力，期望获取得高质量需求、控好需求变更、维护好需求管理秩序。

根据各家银行的管理实践，需求管理工具一般采用以下几种方式：初始级：通过版本管理工具（如：CC/SVN）和变更管理工具（如CQ）实现需求版本的控制，将需求文档放在版本文件库进行统一进行管理，需求变更时通过变更管理工具提请变更单对版本库中的需求进行变更（Check out/in）。

目前大多数科技能力较弱的城商行采用此类方式进行管理。

组织级：通过流程管理工具，以需求作为一个任务表单（附上需求文档），实现需求过程的流转、审批、分配、跟踪管理，再结合配置管理和变更管理工具，进行需求管理流程的串接。

此类管理工具通常采用OA流程管理工具、项目管理工具、开发过程管理工具来实现。

但其本质不是完全意义上的需求管理，只是把需求当作一个需求类任务（不对需求内容进行管理）进行流转跟踪，及时反馈需求类任务的状态而已。

此阶段的管理主要实现将需求流程电子化、线上化。

目前大多数据股份制银行、省农信采用此方式进行管理。

专业级：需求管理另一个方向是面向需求分析人员（BA）、BA团队的需求管理工具，通过BA团队对需求内容进行管理，但此类工具更多的是偏重于需求分析过程和需求关联矩阵分析，需求管理过程和需求传递较弱。

因此，有一些大的国有银行最初采用IBM DOORS、Borland CaliberRM，由需求团队进行企业级需求内容级管理，但由于银行业务本身的复杂性和系统耦合性高，需求内容间的关联是不可枚举的海量关系，且需求变更频繁，造成此种关系不可维护。

因此，退而求次，此类工具不适合进行企业级需求管理，回归到项目级的需求分析阶段BA独立使用的工具。

企业级：利用企业级专业化需求管理工具，将需求方法与编制、需求统筹与管控流程、需求内容级管理、需求资产沉淀与复用进行统一，形成企业级需求全生命周期的内容级管理，其特性包括：1）实现了需求集中受理、统一需求入口和出口通过需求集中受理，解决需求来源多带来的需求重复、交叉、质量等问题，统一了需求标准、提高了需求质量、维护了需求的一致性和权威性。

2）需求内容在线编制与协同为提升需求编制质量和协调效率，实现需求内容的多人在线编制和协同，并实时进行需求内容的质量检查、问题澄清，以及基于局部内容的传递、分享、评论和沟通。

拉近需求人员与研发人员的沟通距离，通过团队协作和互动，快速及时精准传递和反馈需求，提升需求质量和促进需求干系人尽快达成理解一致。

3）由文档级转为内容级需求管控助力IT过程的精益管理，改变传统的需求文档级粗粒度的管理方式，通过需求结构化、条目化技术，自动对需求文档进行自动化拆解，形成需求内容单元（需求条目），将需求管理与跟踪的颗粒度细化到条目级，使得需求内容切分（应用分配）、需求内容质量管控、开发和测试任务的需求分配、投产内容的需求跟踪成为可能。

4）控好需求内容变更，维护好最新需求实现了需求文档级、条目级的需求基线管理，通过需求内容的变更控制手段，如：多人同时在线编制需求、变更需求、变更痕迹及历史管理、变更内容前后比对、需求变更影响分析和自动通知受影响的相关人员，使需求变更过程方便、快捷，且变更过程透明、可回溯。

5）帮助项目团队快速、方便获取最新、最可信的需求为解决需求来源多、需求传递混乱的问题，通过需求集中管理、规范需求受理和传递过程，需求内容质量检查和质量评审等措施，使得需求管理过程规范、透明和可控，同时保证需求质量。

6）推动开发过程的需求协同，避免开发测试返工需求传递由文档级过渡到需求内容级，使需求内容（全部或局部）和需求变更都能快速传递到项目管理、开发、测试和投产过程的各环节对应的任务，使项目组所有成员都在同一份需求内容基础上开展工作，形成以需求为主线的开发联动，自动构建起从业务需求->项目->切分系统->软件需求->开发->测试-投产版本的跟踪脉络，使需求的提出到落地实现过程变得透明。

7）需求资产沉淀，形成企业级的需求统一视图帮助用户按各类管理视角或框架（如：业务框架、应用系统框架、产品框架、组织框架）组织需求资产，通过从各项目需求文档中抽取需求资产，并按管理框架归集和维护需求资产，确保可以从某一管理视角（如：某一系统、业务领域、产品类型等）获取当前最新、最全的需求，以反映当前系统（或业务领域）的最新的需求全貌。

8）实现了需求资产复用通过需求资产，需求分析人员在分析、编制需求时可以快速参考、引用需求资产内容，快速构建并形成新的需求；同时可以支持多人协作并行编制需求，加速需求形成过程。

三、需求管理工具基本情况专业的需求管理工具在过去相当长一段时间内，一直IBM、Borland等国外厂商为主导，虽然Doors、CaliberRM进入国内市场近20年,但从银行客户的实际应用和客户反馈来看，作为银行企业级需求管理工具在国内鲜有成功案例。

当然原因是有多方面的，一方面是产品定位与企业定位不同，比如这类产品更适合BA团队来分析和管理需求，但国内客户要进行企业级需求管理，显然是不匹配；另一方面这类工具也有本土化不足，灵活性不足，且不可定制，且产品升级太慢，技术框架与界面体验太老，完全不适合国内的应用场景。

大有廉颇已老的感叹。

当然近几年国内也涌现了不少致力于需求管理的工具厂商，但分为两大类，第一类是以项目管理、开发管理为切入点，将需求以“任务表单+附件上传”方式进行需求过程的流转管理，当然形成又分为传统流程驱动和需求任务看板两种方式。

但其本质依然是基于“需求表单任务”与“开发测试任务”协同。

因此，此类工具主打到仍然是需求任务流转与协同，基本不涉及需求内容管理。

由于此类涉及的技术门槛较小，使大量国内厂商以项目管理、开发过程管理名头，打上需求管理工具的标签。

类似厂商包括：Teambition、ONES、PowerProject等；第二类厂商是提供需求内容级的专业管理工具，由于业务和技术门槛较高，目前在国内几乎是凤毛麟角，主要代表产品有北京维普时代的Viusal RM和统御至诚的oBridge，实现需求内容级的管理，包括：需求在线编制、需求内容切分、需求传递与在线沟通、需求内容变更、需求内容跟踪、需求内容基线管理等等。

四、常用需求管理工具比对正如前文所述，不同层级的需求管理，其实现的管理思路和采用的工具（或组合）不同。

下面，我们选择此次调研的主流需求管理工具，从功能特性和非功能特性进行横向比对：需求管理平台关键特性比对●:强☉:一般○:弱—:不支持五、工具比对结果为确保工具选型的客观公正性，上述比对数据及评价均来自我们比选团队近一周的实际工具体试用的体验结果，呈现实际情况。

由于评估时间较短，或试用人员自身的认识差距，不排除存在少许偏差或错误。

因此，上述数据只作为我们近期评估结果的数据呈现，不作倾向性评比结论。