敏捷是一种态度:敏捷建模带来敏捷需求
目 录
01 缘起
02 敏捷需求5W1H的思考
03 关于敏捷需求体系的一些思考
04 写在敏捷需求后的话
01
缘起
对研发效能提升的研究,是近年来各家企业技术部门一直在研究的课题。早期,针对敏捷开发的实践,让大多技术管理者尝到了甜头,不再拘泥于三月两月一次发版,有些创新类研发项目已经可以做到一月半月乃至以周为单位进行投产。高效的科技运营促进了业务高增长,也增强了企业核心竞争力。
但对于诸如核心系统,一些一级/重要/大的系统建设,就算可以敏捷开发,但在需求侧,还未全部敏捷起来,很多企业还在走业务需求、软件需求的需求阶段成熟推进路子,这大大提高了需求工期在整个研发中的比重,不利于研发效能的提升,更谈不上敏捷研发了。
针对整个研发生命周期的考量,相对于开发侧的敏捷,需求侧的敏捷一直以来都很薄弱,虽然有些诸如创新类项目那种低量级的小需求,缩短了整个迭代周期,但这种追求速度,未进行规范导致的需求质量不高,需求资产未得到复用,特别是对高量级的项目需求,还很难敏捷起来。
也就是说,只有敏捷开发是不够的,还需要有敏捷需求。所谓兵贵神速,研发要想在效能上有所提升,其中需求的敏捷势在必行。
02
敏捷需求5W1H的思考
我们采用5W1H方法来全面阐述敏捷需求。
图1:敏捷需求的5W1H
2.1 什么是敏捷需求?
“敏捷”这个词,字面上的意思是灵敏快捷,通俗地理解就是简便有效,灵活快速。那么“敏捷需求”的意思,简单理解就是使需求工作简便有效,灵活快速起来。
从需求工期上来看,简便有效、灵活快速的需求工作,可大大缩短了预期的需求工期。例如原来半年的需求工期,采用了敏捷需求,在同等条件下,如需求人员数量和能力等都不变的情况下,需求工期预计可缩短为3个月,那么这个项目需求就敏捷起来了。
同样,与敏捷开发下的小量级需求工作不同,敏捷需求在保证规范、有质量的需求工作上,相对于非敏捷的传统需求工作来说的,做到了需求工作小步快跑。
这样看来,“敏捷需求”是在保证规范、有质量的需求工作上,通过简便有效,灵活快速的方法,实现了需求工作小步快跑。
图2:敏捷需求全过程
敏捷需求覆盖全部业务需求和软件需求,涵盖了部分架构设计;通过建模的方式简便有效易于结构化,模型化的方法易于灵活快速无缝贯穿需求全过程。
2.2 需求为什么要敏捷?
从研发生命周期管理来看,开发侧有敏捷开发,测试侧有自动化测试,投产侧有一键部署能力,运维侧有自动化运维,也就最前面的需求侧能力还未提升。加强需求侧能力建设,是推动整个研发敏捷能力不可或缺的一环,那么敏捷需求就成为了不二的选择。
从市场竞争,业务要求及系统不断更新迭代上来看,再遵从原来按部就班地走咨询立项、业需立项、软需立项的建设路子,只会延缓整个企业数字化转型的进程,特别是中小企业/银行,更加拖不起、等不起。唯有敏捷,方可闯出一条出路,再实现弯道超车并无不可。
从需求本身工作来说,需求交付开发的过程是存在断层的。需求的产物有流程图、界面原型、需求规格说明书等,这些需求产物交付给架构设计人员、技术开发人员,只是实现了逻辑的连贯,未能实现物理的连贯,也就是说需求产出的是把业务可理解的语言转化为技术可理解的语言,技术再根据这些语言,通过代码的形式转变为计算书可执行的程序。技术语言与代码程序之间是断层的,不可持续,这样需求就无法敏捷起来。
图3:敏捷需求工作流程
而敏捷需求不但追求逻辑连贯,需求规范有质量,也追求物理连贯,需求产物的技术语言可以直接转化为代码程序。这其中的抓手就是界面原型与前端页面代码之间的一体转化。
2.3 需求怎么样才能敏捷?
大凡工作敏捷化,都是追求化繁为简。需求敏捷化的追求也是一样,通过敏捷建模(即构建模型)的方式,来实现需求敏捷。
图4:敏捷建模
需求模型化工作分业务建模、流程建模、表单建模、规则建模和数据建模5个不断深入细化的环节。具体如下:
1) 业务建模
业务建模,也叫构建业务模型,可通过领域五级建模方法,从领域、阶段、活动、任务、步骤五个层面进行拆解细化,把整个业务逻辑刻画出来。
业务建模输出的有:概念模型ER图、业务目录、业务实体等。
2) 流程建模
流程建模,也叫构建流程模型,是在业务建模的基础上,通过L3流程建模方法,识别并定义各主分支流程名称,参与流程的角色及权限,流转的节点及流转规则等;
流程建模输出的有:逻辑流程模型图、流程功能、流程实体等。
3) 表单建模
表单建模,也叫构建表单模型,是在业务目录及流程功能基础上,定义表单模型页面字段要素及要素规则等。表单建模原则遵循业务合理性、用户最佳体验以及数据标准等。
表单建模输出的有:逻辑模型界面原型、输入输出要素(字段及字段规则等)、表单实体等。
4) 规则建模
规则建模,也叫构建规则模型,是在业务建模、流程建模、表单建模的基础上,识别并定义出业务功能规则描述、非功能规则描述等;
规则建模输出的有:逻辑规则模型、规则实体等。
5) 数据建模
数据建模,也叫构建数据模型,是在流程建模、表单建模、规则建模的逻辑模型基础上,定义数据物理模型及数据实体等;
数据建模输出的有:数据模型如数据库表、数据结构、数据实体等。
综合以上敏捷建模五步方法,需求分析人员构建业务模型、流程模型、表单模型和规则模型,架构设计人员构建数据模型。
需求规范、有序、有效、有质地把从不成熟需求转变为成熟需求,不稳定需求转变为稳定需求,沉淀实体资产,提升需求质量,降低需求缺陷。
与纯需求规格文档相比,特别是页数在1000页以上的项目需求文档维护工作来说,对文档规范强迫症犯者来说是福音,不用再花精力在文档编号规范、格式规范、形式规范、图文规范等上面,遇到能够一步自动规范还好说,不能一步自动规范就得手动规范调整时那种无效工作带来的无力感。
拿需求文档修改工作量来说是比较枯燥繁重的。遇到一个字段要素的更改,原型改一次,文档里的要素改一次,业务规则描述也可能要改一次,特别是上下文出处较多,还不能用全部替换来修订的,特别麻烦,需求规格文档编辑工作占到全部需求工作没有三分之二,也有二分之一。采用敏捷建模方法,省去了大量文档编辑工作量,同时能够实现以下能力:
I. 通过Jason入库,可支持需求原型直接转化为前端页面;
需求人员绘制的原型界面,评审通过后可通过Jason入库,自动生成为前端页面。
II. 通过规格配置,可自动生成需求规格文档;
需求人员构建的流程模型、表单模型、规则模型等,评审通过后,可自动生成配置好的需求规格文档。
III. 通过规格配置,可自动生成测试用例;
需求人员构建的流程模型、表单模型、规则模型等,评审通过后,可自动生成测试用例,便于开发人员进行单元测试,SAT人员进行测试,UAT人员进行验收。
有以上建模能力,不但实现需求态敏捷,也带动设计态、开发态、测试态的敏捷。
2.4 谁的需求敏捷了?
整个研发生命周期中,从业需、软需、设计、开发、测试、投产、运维中,参与研发的角色有很多,诸如业务人员、业务需求分析人员、软件需求分析人员、架构设计人员、前端开发人员、后端开发人员、SAT测试人员、UAT测试人员、运维人员、项目经理、技术经理、质量经理、业务主管、需求主管、架构师、开发主管、SAT/UAT测试主管、专家/评审人员等。
建立了以需求原型界面为抓手,全体研发人员都可以直观、快速地从了解需求、理解需求到熟悉需求的一个过程。其中,业务需求分析人员、软件需求分析人员和架构设计人员的建模能力要求如下:
业务需求分析人员,需要具备业务建模、流程建模等能力;
软件需求分析人员,需要具备流程建模、表单建模和规则建模等能力;
架构设计人员,需要具备数据建模等架构设计能力;
业务需求分析人员对业务的理解无法达到100%,再加上信息传递过程中的失真,软件需求分析人员对业务的理解很难超过业务需求分析人员。同样的架构设计人员对业务的理解不会超过需求分析人员,也就是说在整个研发链路上,越后面的人对业务的理解越弱,到了业务测试人员进行验收时,就会导致很多需求缺陷的存在,以及不可避免的出现大量需求变更,给研发交付/上线/投产带来不可预估的项目风险。
还有需求分析人员,重功能实现,轻用户体验的现象会大为改观。有了比较直观快速,亦或为所见即所得的敏捷建模,需求分析人员有了多余的时间来增强用户体验的改进。
而敏捷需求采用敏捷建模方法,可以很好地把研发链路上各个角色都统一在敏捷建模上面,以原型为抓手,兼容流程、规则、数据等模型,以及需求全过程管理中的缺陷/问题/解决方案、进度/评审/验收、讨论/评论/评价等一站式一体化呈现,大大提高了需求的质量管理、审批管理、资产管理等能力。
2.5 需求敏捷能多久?
采用敏捷需求的敏捷建模方法,提升了企业级/组织级/项目级的需求能力,而需求能力的提升,一是提高了需求的产量和质量,一是缩短了需求的工期。
一个故事点的平均需求工作量评估上,原来要10人天完成的工作量,采用敏捷建模方法后,随着需求模型化能力的成长成熟,只需要4-5人天即可完成。这里面大大节约了文档编辑的工作量。
敏捷需求能力见长,则需求产量和质量也见长,需求工期见短。同理,敏捷需求能力回退,则需求产品和质量也会回落,需求工期也会变长。这些不是简简单单靠压迫外包供应商所能管控的,而且研发能力不会完全依赖于外包,一旦被外包裹挟带来的必然是局面的被动。同样,具备需求敏捷的能力,在于外包供应商合作谈判中将获得优势。
需求敏捷是长期坚持、持续协同的工作。
2.6 需求敏捷在哪里?
1) 需求能力有所提升
敏捷需求更关注需求人员能力建设,原先需求人员需要具备需求分析能力,敏捷需求建设下,需求人员需要具备需求设计能力。
需求分析能力,注重业务语言的理解和熟悉,并转化技术语言的能力,无法超越业务。
需求设计能力,弱化业务语言转化技术语言的能力,注重对业务本质的理解并超越业务。
例如最近的个人养老金账户产品需求,需求分析人员根据业务人员设计的产品进行分析并落地实施,而需求设计人员在依据业务人员设计的产品上,结合需求资产,比如渠道需求资产,原来产品需求里只有一个通过二维码来打开手机银行APP的渠道路径,需求设计人员针对无APP用户的个人养老金账户无法覆盖的缺陷,可以根据各个渠道路径的选择,可以增加从二维码/微信公众号/微信小程序/支付宝生活号/...快速引流至H5开户页面,来避免需要下载手机银行APP,并注册用户的麻烦而退却的流量流失。
故而具备需求设计能力的需求人员,可以是业务产品经理优秀的助手,利用自己熟悉的需求资产支持业务产品设计的实现。
需求能力的敏捷,不但更多覆盖了业务侧能力,如引流设计;而且也更多扩展了需求侧能力,比如用户体验、需求质量、需求工期等;还更多辐射了设计侧、开发侧、测试侧的能力提升。
2) 需求工期有所缩短
对于低量级的小需求,在保持需求快速迭代的能力上更规范、更直观,随着需求资产的复用率提高,原来一个2周的迭代版本能够实现5个功能点的部署,需求模型化的敏捷能力,一个2周的迭代版本可实现10个功能点的部署。
对于高量级的项目需求,随着需求文档编写工作的弱化,需求工期可大大缩短,工期缩短比例在30%-50%之间。
依据需求工期缩短比例的多寡,我们可以针对敏捷需求能力成熟度进行量化评估,以高量级的项目需求为例,比如零售信贷升级改造项目,未采用敏捷需求建模方法,预估10人6月(60人月)完成,设定为敏捷能力1.0计,采用敏捷需求建模方法后,若同样10人且只需要3月(30人月)完成,敏捷能力提升了50%,那么敏捷能力即为2.0。依次类推,当一个企业项目研发的需求敏捷度,是衡量一个企业项目研发的需求敏捷能力的指标。
3) 需求质量有所提高
敏捷需求所带来的质量的改变,原先项目都以需求文档记载为准绳,业务、需求、设计、开发、测试乃至运维,不论遇到问题还是缺陷都是先看文档,再看各自的理解是否存在偏差,若是需求文档表述有歧义,很容易造成人员在需求理解上失真,这样的需求质量无法监测,也无从考核,需求质量靠主观判断,不能带来客观的评估和评价。
而敏捷需求模型化后,业务、需求、设计、开发、测试、运维等,遇到问题或缺陷,直接在原型界面上表示出来,规则区域内记录了业务规则描述,以及进度和验收;问题/缺陷区里记录来自不同角色提出的各种需求问题以及针对问题的答疑或解决方案;审批/评论区里记录了来自评委的审批意见或其他人员的评论意见等,可以直观地展现需求的成熟度。这样项目全体人员,乃至外部专家都可以直观针对需求故事点提出各种有助于需求质量提升的任何意见,同时在UAT测试阶段可避免大量的需求变更出现,并有效降低需求缺陷的存在,至少在规则描述里,针对有歧义的文字,可以直接提出意见。这些措施都集中在一个原型页面上,而不是需求文档里。
4) 需求资产有所效益
需求模型化,带来了需求结构化。需求结构化,沉淀为需求资产。
五步敏捷建模方法,每一步都可以进行模型化、结构化,并产出相应类型的需求资产。
业务建模,产出业务模型,为业务架构中的概念模型资产,含业务实体。而业务实体作为业务目录类需求资产的唯一标识,可以被有效,不限次的复用。例如客户信息模型中的地址业务实体。
流程建模,产出流程模型,为逻辑流程模型资产,含流程实体。同样流程实体作为流程类需求资产的唯一标识,可以被有效,且不限次的复用。例如法律审查流程实体,既可以被零售信贷流程所调用,也可以被对公信贷所调用,还可以被采购流程等涉及企业合同的各个使用场景所复用。
表单建模,产出表单模型,为逻辑表单模型资产,含表单实体。在原型设计时,一些通用表单,如附件、地址、列表、表套表等组件资产,既可以页面级进行封装发布,也可以组件级进行封装发布。
规则建模,产出规则模型,为逻辑规则模型资产,含规则实体。用户在编写业务规则描述时,可以智能列出可复用的同类规则实体。比如约束条件的语句描述,可以列出一些标准的约束条件规则语句描述文本进行参考。
数据建模,产出数据模型,为物理模型资产,含数据实体。依据Jason入库,可自动建表,并克隆表单与数据的虚拟关联为实质关联,可自动生成前后端连接接口。
敏捷需求建模可产出大量不同类型的需求资产,进行可变和不可变封装之后,可形成通用的公共组件级资产。大量的公共需求资产的无限复用,带来的效益是可观的,不但节省了时间成本,丰富了知识储备,增加了需求工作产量和质量,避免了需求重复工作。
03
关于敏捷需求体系的
一些思考
敏捷需求体系,是对传统的研发生命周期的一次升级探索,既落地了咨询规划成果,快速驱动需求敏捷建设,同时直通设计、开发、测试。
建立有敏捷制度、敏捷组织、敏捷流程、敏捷文化等敏捷保障体系,以业务建模、流程建模、表单建模、规则建模、数据建模等敏捷建模方法为核心动力,驱动业务需求、技术需求、运维需求、数据需求等需求来源快速落地,提供需求进度、需求质量等需求管理一站式服务,提供需求结构化、组件化等需求资产一体化运营,是构建敏捷需求体系大航船在蓝海敏捷航行的整体框架。
图5:敏捷需求体系整体框架
04
写在敏捷需求后的话
敏捷是一种态度,也是一种追求。
大多数需求工作者们,不论是需求工程师、还是需求分析师、亦或是需求管控者;不论其前身是做过业务营销的人,业务管理的人,还是写过代码的开发工程师,管过项目的项目经理,做过测试的测试工程师,还是一毕业就进入需分这个岗位的人等;不论是在互联网公司从事BA、还是在银行从事产品经理的人,都或多或少使用过各种分析工具。
从用Excel、photoshop到Axure等原型设计工具,viso、wps流程等流程设计工具,xmind脑图工具,word文档编辑工具,以及一些诸如版本管理svn,协同办公工具等等,工具有很多,但是这些工具都很分散,相互之间的数据未能打通,无法实现共享。
那么集成这些工具,或者集成这些工具能力,打造成企业级建模工具,帮助企业各个岗位都能够使用,并且相互之间可以无缝对接,是具备敏捷工作的一个充分条件。
普元建立连接的思想,针对企业在各个层面,各个环节,各种维度的断层不连贯现象,建立其上下、内外、前后的全方位立体连接,帮助各个行业各大中小型企业在数字化转型方面获得成功,提供工具支撑。
普元的企业级敏捷建模工具,基于建立连接的思想应运而出。
敏捷建模工具首先集成了这些工具能力,其次植入了低开的技术底座,通过需求结构化、组件化实现了需求资产从沉淀、加工、发布到优化的一体化资产运营。
关于作者:胜棋,普元银行业务资深咨询顾问,从事银行一线营销工作有8年,银行二线研发服务工作有10年。熟悉银行信用卡、信贷、风控等方面工作,擅长IT需求、IT产品、IT咨询、IT售前等研发工作,主导或参与大中型银行业务类、数据类项目建设经验,并落地了一些涉及银行前中后台的研究成果。
上一篇: 射雕英雄传谢彬位置与答案分享
下一篇: 品牌能否成为公司的竞争优势?
推荐阅读
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
敏捷是一种态度:敏捷建模带来敏捷需求