专栏首页需求管理企业级需求管理工具选型报告
原创

企业级需求管理工具选型报告

XX银行企业级需求管理工具选型报告

(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团队来分析和管理需求,但国内客户要进行企业级需求管理,既要管需求内容,又要管需求过程,显然是不匹配;另一方面这类国外管理工具也有本土化不足,不符合国内需求管理特点和应用场景,产品对用户成熟度要求太高(理想太丰满,现实很骨感,企业很难实际做到),此外,产品灵活性不足,且不可定制;产品升级太慢,技术框架太老,界面陈旧,用户体验还停留在20年前,特别是在敏捷开发转型浪潮中,完全不适合国内的应用场景和用户习惯。

当然近几年国内也涌现了不少致力于需求管理的工具厂商,但分为两大类,第一类是以项目管理、开发管理为切入点,将需求以“任务表单+附件上传”方式进行需求过程的流转管理,当然形成又分为传统流程驱动和需求任务看板两种方式。但其本质依然是基于“需求表单任务”与“开发测试任务”协同。因此,此类工具主打到仍然是需求任务流转与协同,基本不涉及需求内容管理。由于此类涉及的技术门槛较小,使大量国内厂商以项目管理、开发过程管理名头,打上需求管理工具的标签。类似厂商包括:Teambition、ONES、PowerProject等;第二类厂商是提供需求内容级的专业管理工具,由于业务和技术门槛较高,目前在国内几乎是凤毛麟角,主要代表产品有北京维普时代的Viusal RM和统御至诚的oBridge,实现需求内容级的管理,包括:需求在线编制、需求内容切分、需求传递与在线沟通、需求内容变更、需求内容跟踪、需求内容基线管理等等。

四、 常用需求管理工具比对

正如前文所述,不同层级的需求管理,其实现的管理思路和采用的工具(或组合)不同。下面,我们选择此次调研的主流需求管理工具,从功能特性和非功能特性进行横向比对:

比较项

维普时代 Visual RM

IBM DOORS

统御至诚  oBridge

Borland CaliberRM

平台定位

企业级 内容级 需求全生命周期管理

企业级 内容级 (弱流程管理)

项目级 内容级

项目级 内容级 (不含流程管理)

主要使用场景

需求在线编制与协同 需求统筹与内容切分 需求内容管理与跟踪 需求沟通与分享 需求检查与质量管理 需求变更管理 需求资产与复用

BA需求编制、维护、矩阵跟踪与分析

需求在线编制 需求过程跟踪

BA需求编制、维护、矩阵跟踪与分析

主体使用受众

业务人员、需求分析人员(BA)、需求管理人员、QA、PMO、项目经理、开发测试人员等。

需求分析人员(BA) 需求管理组

需求管理人员 项目经理 开发测试人员

需求分析人员(BA) 需求管理组

架构与 支撑平台

B/S,跨平台,支持Windows、Linux、国产软硬件平台

C/S,仅支持Windows平台

B/S,跨平台,支持Windows、Linux、国产软硬件平台

C/S,仅支持Windows平台

用户使用感受

1.专业的企业级需求管理工具,集需求开发、需求统筹、需求变更、需求跟踪、需求资产为一体。 2.功能较全,国内软件,符合国内使用场景和用户习惯,用户体验也很好。

1.界面及技术框架太老,用户体验差。不支持需求流程管理。 2.Word导入识别不好,导入导出费时费工。需求导入后脱离上原文档,失去需求上下文。 3.使用太复杂,太重,理想化较多,实际很难用起来。 3.不符合国内使用场景,工具使用和维护成本高

1.涉及部分需求内容管理,但更多的是服务于项目管理过程。功能轻量化,比较亲民,用户体验较好。 2.不支持需求文档导入和自动解析,对存量和已有需求文档无法支持入平台。

1.界面及技术框架太老,用户体验差,并有较严重的性能问题。不支持需求流程管理。 2.Word导入识别不好,导入导出费时费工,需求导入后脱离上原文档,失去需求上下文。 3.不符合国内使用场景,工具使用和维护成本高

需求管理平台关键特性比对

●:强  ☉:一般  ○:弱   — :不支持

分类

平台功能特性

维普时代 Visual RM

IBM DOORS

统御至诚 oBridge

Borland CaliberRM

功能特性

需求分级分类

需求动态模板管理

需求文档导入(WORD、WPS)

需求文档自动结构化、条目化解析

需求多人在线协同编辑

需求修订痕迹管理与历史记录

需求离线编辑与同步

需求文档与条目内容同步(保留需求上下文)

需求管控点定义及状态管理

需求内容在线质量评审

需求问题与缺陷管理

需求内容切分,按应用、项目分配

需求内容沟通、评论、分享

需求工作量评估与汇总

需求条目属性管理

需求条目关联管理

需求内容拆分与合并

需求内容按需组合导出

需求文档基线管理

需求条目版本管理

需求条目内容变更比对

需求变更流程

需求变更影响分析

需求间关联分析与跟踪

需求跟踪矩阵

需求基线的管理

需求资产结构模型

需求资产检核、导入

需求资产组合,按WORD文档导出

需求资产基线管理

需求资产视图

需求资产复用

权限控制(文档级)

权限控制(条目级)

需求内容按需组合导出( Export)

非功能特性

需求文档(word)内容导入后结构化解析速度

需求内容全文在线浏览

大型文档(1000页以上)支持程度

支持并发用户数

需求内容导出性能

五、 工具比对结果

为确保工具选型的客观公正性,上述比对数据及评价均来自我们比选团队近一周的实际工具体试用的体验结果,呈现实际情况。由于评估时间较短,或试用人员自身的认识差距,不排除存在少许偏差或错误。因此,上述数据只作为我们近期评估结果的数据呈现,不作倾向性评比结论。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 软件需求分析与管理的十个问题

    首先需求包括了产品需求,用户需求,软件需求。产品需求关注的是产品的标准化和通用化,会对收集到的用户需求进行分类和优化,结合业界标准系统模型进行抽象并通用化。用...

    阿新
  • 软件测试中影响软件需求质量的因素有哪些?

    软件的开发和上线应用,离不开软件测试这一过程,软件测试是分析者用来发现软件缺陷的过程。没有任何软件是完全无缺陷的,测试者的目标是减少在项目中找到的缺陷,并且将质...

    新梦想IT职业教育
  • 需求采集和分析

    产品的需求管理有需求采集、需求分析和需求筛选几个阶段,经过这几个阶段之后才会进入立项的阶段。

    公众号php_pachong
  • 前端进阶之路:如何高质量完成产品需求开发

    本文作者:IMWeb 陈映平 原文出处:IMWeb社区 未经同意,禁止转载 写在前面 作为一个互联网前端老鸟,这么些年下来,做过的项目也不少。从最初的...

    IMWeb前端团队
  • 谈谈需求管理要管哪些?

    由开发方和客户共同对主要需求文档“软件需求规格说明书”进行评审,双方达成共识后作出书面承诺,使需求文档具有商业合同效力。

    公众号php_pachong
  • 从3个方面聊聊,如何正确使用需求池?

    参与到项目中,经常发现项目的需求源源不断,刚做完一堆需求,马上又有新的需求要做,感觉总是做不完,就像一个“无底洞”。实际上,这里涉及到一个需求管理的概念。项目中...

    物流IT圈
  • 前端进阶之路:如何高质量完成产品需求开发

    作为一个互联网前端老鸟,这么些年下来,做过的项目也不少。从最初的我的QQ中心、QQ圈子,到后面的QQ群项目、腾讯课堂。从几个人的项目,到近百号人的项目都经历过。

    IMWeb前端团队
  • 第二课课堂笔记(软件需求分析设计)

    软件开发生命周期 建模方法(开发技术) 开发阶段 开发模式 ---- 1、面向过程(结构化) 2、面相对象 (功能分析) 3、面向数据(信息,概念分析)...

    张俊怡
  • 手机壳干架的软件工程指南

    这里的产品经理,我定义为需求人员。程序员,我定义为设计人员。关于需求和设计,我在《软件方法》第1章中专门阐述(http://www.umlchina.com/b...

    用户6288414
  • [原创]-数据需求的定义

    需求是数仓的核心,无论从广度还是深度的层面上做好需求调研的工作,对数仓的建设百利而无一害

    DataScience

扫码关注云+社区

领取腾讯云代金券