BA的广度和深度
2016-09-23 12:40
141 查看
http://insights.thoughtworkers.org/ba-capability-and-development-path-in-thoughtworks/
作者:ThoughtWorks – 亢江妹。未经允许,请勿私自转载。
BA,或者称业务分析师,是企业数字能力和业务能力之间的沟通桥梁。随着企业数字转型的进一步深化,相信对BA这样的技能需求会越来越多,只是未必都用“BA/业务分析师”这样的Title。
ThoughtWorks在创建之初,就有BA这样一个职位。Lupi Messenger是我的一个同事,她是ThoughtWorks的第一批BA,到现在为止做了18年,孙女都已经上小学了,我很仰慕。这二十年间变化很大,需求分析方法从最初的敏捷用户故事,演进到现在精益为基础的需求分析方法,BA的技能要求也在不断变化。整理出一个大家都认可的BA技能图谱,几乎是个不可能的任务——即使仅限ThoughtWorks所要求的BA技能(我在ThoughtWorks是所见的不同时期的BA技能图谱要超过10个)。但所有的表达都是为了交流和学习,不是为了“证明自己是对的”,所以斗胆结合自己的经历,谈谈我心目中ThoughtWorks版的BA技能图谱,并分享一些学习提升的方法。
8人以下的团队 vs. 40个人的团队;
单一的Stakeholder vs. 跨不同业务部门,庞杂的多个Stakeholder;
面对的需求是简单的工具(如订单自动化上传) vs. 一个复杂的产品平台(如一个新的互联网金融平台);
客户/用户对自己的需求有清楚的认知,并能清楚表达 vs. 客户/用户并不知道自己需要什么,或者知道但表达不清楚;
在一个创业团队上线一个产品 vs. 在一个大型企业里推动产品体系改变
能在左边的场景里做到优秀,是否就意味着在右边的场景下就同样能做到优秀呢?相信大家有了自己的答案。在ThoughtWorks这样的专业服务公司里,我这样看BA的技能广度和深度:
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/01-3.png)
图1: 我眼中的ThoughtWorks BA——广度和深度
BA的技能广度(图中绿轴部分):
BA所涉猎的行业和领域,比如银行、保险、电信、医药、能源、农业、教育等等;
这里“涉猎”的含义,不是指简单地知道某个行业是什么;而是指如果突然有一个这个行业的项目,规模大概在8人X3月时,能担负起“把客户/用户需求转换成软件需求的”责任。
BA的技能深度:
在某个行业/领域的视野和眼界(图中蓝轴部分),从小到大,依次是应用/系统, 到产品和流程,到企业战略和愿景,再到行业发展趋势和愿景,反映了在行业领域能够把控的深度。
专业上的杠杆领导力(图中橙轴部分):从个人自己的技能胜任,到使能自己所在团队、所在客户、内部实践社区、甚至外部职业社区的杠杆领导力。举个例子,作为BA可能是软件团队里面最多开会的人——“会议王”,会议引导能力很强。那当所处的场景是,40个不同角色不同背景的人要开会做出重大决策和计划的时候,是否能有效识别、激发其中的一些人作为“协助者”,发挥协力在这个场景下把会议引导地很高效呢?这就体现了杠杆领导力。
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/02-1.png)
图2: 我眼中的ThoughtWorks BA——“生存圈”和“生长圈”
当我们刚入门BA时,相当于是在上图中的原点。图中最内红色的圈是我们的“生存圈”。在“生存圈”中,
我们聚焦的是要交付的应用和系统
我们的核心职责是需求沟通和澄清
我们扮演的“是业务和技术之间的翻译官、解释器”,我们并不被要求去挖掘业务痛点和需求、系统思考全盘分析识别业务优先级,而只是把需求能翻译、解释成技术更理解的语言,帮助需求被实现成为软件功能。
换句话说,在“生存圈”里,是在前面举例的5个左边的场景里,能胜任:
8人以下的团队里,能很好地收集、分解、表达、澄清、验收需求;
单一的Stakeholder的情况下,能很好地与之沟通,把他/她的想法能清晰、准确、有效地传达给技术团队;
面对的需求是做一个简单工具(如订单自动化上传),能清楚地勾勒、描绘用户与之的交互过程、步骤、每一步的输入输出、业务规则,并提供简单的交互设计建议;
客户/用户认知并能清楚表达自己的需求,能有效地捕捉、梳理、表达、管理好他们的需求;
在一个创业团队从0到1开发一个产品,能做用户访谈、理解用户的想法、把软件需求表达给技术团队、并能向用户演示、做用户测试。
跨越生存圈之后,就要在前述的广度和深度上继续拓展、深钻:
拓展行业领域的广度。比如如果已经是熟悉零售,又有银行工作背景,是否可以去拓展下互联网金融领域?
拓展行业领域的深度。比如在保险行业,只是能看到所做的在线自助服务应用;那可不可以拉长视野,在保险企业层面去看如何提升客户体验呢?是否能把自己在线自助保险服务业务上的知识,让全团队各个角色的人、全社区各个角色的人都清楚了解并掌握呢?
收集业务系统需求
业务系统的流程的As-is和To-be分析
识别需求顺序和依赖关系,构建需求全景图
分析和沟通非功能性需求
需求分解,把大的特性(Feature)拆分成粒度合适的用户故事(User Story)
能应用INVEST原则,细化用户故事(User Story)的详细需求
低保真界面原型以沟通和澄清需求
能做功能演示和验收测试
能快速进行行业研究,并提供有价值的行业洞察报告
能和CxO对话,建议和销售战略计划
能完成售前解决方案建议书,或提供战略性的建议
能驱动完成大客户发展规划
能帮助客户规划愿景、目标和路线图
能完成市场、用户、和竞品分析
能规划执行的方案、范围、优先级
能发现、提炼案例并分享给客户和外界
能带领完成用户、市场研究
能完成业务模式的提炼和设计
能带领完成产品路线图的规划
能清楚描述用户体验和产品需求全景
能管理产品需求列表及其优先级
能确定并管理产品需求的优先级
能制定产品交付计划、确定阶段性目标及需求
能确定关键需要跟踪的运营数据、并指导如何用数据验证假设
能跟踪和管理产品交付进度
能管理产品上线
能提供运营建议
能帮助企业进行数据的采集、存储的战略和方案设计
能帮助完成数据如何清洗、规整、质量监控和提升的方案
能指导业务场景的KPI指标设计和跟踪框架
能结合业务场景,指导数据分析的模型,如数据的属性、数据来源、统计角度、频度等
能指导数据的可视化和解释呈现
能使用工具进行数据分析,提供洞察,比如进行探索性分析、预测性分析、假设验证分析等
有效连接业务、用户、和技术,建立一致的沟通语言,填补沟通漏洞
能指导业务需求管理的流程
能进行Stakeholder管理、提升合作关系
能进行范围和优先级管理
能进行关键流程的设计、引导其解决问题流程、决策流程、冲突流程、需求管理流程等
能高效驱动决策形成
能培训和指导团队的问题解决流程和实践
除了以上所说的5个关键能力,系统思考、沟通表达、研究分析和总结、以及敏捷和精益这些软性的技能则是这些技能的基础。综合以上,BA“化繁就简”的技能树如下:
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/03-1.png)
图3: 我眼中的ThoughtWorks BA——“技能树”
这是一个开放的能力框架。时代在变化,BA的能力框架也应该不停地演进,所以我选取了“树”这种表达方式,期望它是“开放”的,可以不断生长的。(或许我明天的想法就会与这个不同?)
首先,通过组织的BA能力模型,识别自己的重点发展方向和若干项能力短板;
从0-4提升、有计划地提升自己的能力。
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/04-1.png)
图4: 能力水平的评估和学习曲线
0 – 没有相关知识
1 – 知道相关知识(常规套路和工具)
2 – 能按常规套路和工具解决问题
3 – 能创造新方法和新工具解决问题
4 – 能教他人方法和工具来解决问题
从0-1这个层次,是不太需要外力的,自己通过搜索相应的资料,能够很快总结出来常规套路和工具。拿梳理需求优先级为例:
阅读5篇以上关于这个主题的比较经典的文章 (如果不知道,可以请别人推荐来源)
自己总结出一些常规的套路和工具 (能从最基本的角度讲清楚What, Why, Who, When, Where, How)。
从1-2这个层次,必须要靠实践,需要通过项目机会来尝试运用所学的基本套路和工具,可能在一开始会走很多弯路,犯错误,但这是学习的必经过程。
从2-3这个层次,则需要很多个项目的经验积累,融会贯通,灵活运用,乃至创造出新的方法和工具。这外力上需要机会,内力上需要持续总结。
从3-4这个层次,则是需要有很强的“发现总结模式”的能力,即使自己没法亲身经历过100个不同的项目,但还是能总结出10种套路和工具,覆盖到其中99个项目,从而能够教会其他人如何解决问题。这个层次更多的是靠内力,持续思考和总结了。
“请问我自己看过关于XX的10篇文章吗?请问我自己看过关于XX的3本书吗?请问我自己从这些文章或书中总结除了一些常用方法和工具吗?我可以从翻译一些文章开始来积累知识吗?”
最有效的学习途径是教他人学习。有项目机会固然可喜,没有项目机会的时候,我也会通过给团队同事做分享、组织内部培训、去给外部社区做工作坊、去实地公益组织探访、尝试去给客户做咨询等,来自己挖掘“问题场景”体验式学习,这些都是非常有效的学习方法。前年在公司做的”团队引导培训“就完全是自己学习、自己开发课程、自己去试讲,然后就得到机会到不同办公室、软件园、客户那里讲,做完之后完全感觉不一样了。
刻意练习。作为BA,我们至少每天可能要开1-2次会,这么多次会,我有没有在每个会议中都总结我可以准备得更好、表达得更好、节奏控制得更好、总结更精准的地方?如果坚持把每次会议都当成会议引导技能提升的练兵场,相信收获会更大。大家可能觉得回顾会议没什么特别,一直使用Well/Less Well/Puzzles这一种方式来做,但是否知道同事Patrick Kua单就回顾会议的方式写了一本书;Paulo Caroli 则专门开了博客专栏来写回顾实践。单一个敏捷回顾就能造就专家,何况我们引导那么多会呢……
思考和总结的习惯。同事王健说过,“不把信息当知识,不把收藏当学习,不把阅读当思考,不把储存当掌握”。做过一次工作坊,就总结下自己做的流程;做过一次售前,就总结下售前的得失;看过几篇银行业务的文章,就写个读书笔记。花多少时间和思考,决定了自己学习的加速度。
提升学习速度。不知道大家是否也有这种感觉,就是时间变化快,几年前学习的一个方法可能现在就不适用了,或者已经演进成新的了。如果读一本书要半年,写个总结要花两个月,我觉得完全满足不了市场变化对我们知识和能力的需求。至少,应该要提升三倍以上的学习速度吧。
作者:ThoughtWorks – 亢江妹。未经允许,请勿私自转载。
BA,或者称业务分析师,是企业数字能力和业务能力之间的沟通桥梁。随着企业数字转型的进一步深化,相信对BA这样的技能需求会越来越多,只是未必都用“BA/业务分析师”这样的Title。
ThoughtWorks在创建之初,就有BA这样一个职位。Lupi Messenger是我的一个同事,她是ThoughtWorks的第一批BA,到现在为止做了18年,孙女都已经上小学了,我很仰慕。这二十年间变化很大,需求分析方法从最初的敏捷用户故事,演进到现在精益为基础的需求分析方法,BA的技能要求也在不断变化。整理出一个大家都认可的BA技能图谱,几乎是个不可能的任务——即使仅限ThoughtWorks所要求的BA技能(我在ThoughtWorks是所见的不同时期的BA技能图谱要超过10个)。但所有的表达都是为了交流和学习,不是为了“证明自己是对的”,所以斗胆结合自己的经历,谈谈我心目中ThoughtWorks版的BA技能图谱,并分享一些学习提升的方法。
BA的广度和深度
“在ThoughtWorks做BA是怎样一种体验”中提到,BA的职责是把业务和用户需求转换为软件需求。即使是这样一个单一职责,也会有不同的场景:8人以下的团队 vs. 40个人的团队;
单一的Stakeholder vs. 跨不同业务部门,庞杂的多个Stakeholder;
面对的需求是简单的工具(如订单自动化上传) vs. 一个复杂的产品平台(如一个新的互联网金融平台);
客户/用户对自己的需求有清楚的认知,并能清楚表达 vs. 客户/用户并不知道自己需要什么,或者知道但表达不清楚;
在一个创业团队上线一个产品 vs. 在一个大型企业里推动产品体系改变
能在左边的场景里做到优秀,是否就意味着在右边的场景下就同样能做到优秀呢?相信大家有了自己的答案。在ThoughtWorks这样的专业服务公司里,我这样看BA的技能广度和深度:
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/01-3.png)
图1: 我眼中的ThoughtWorks BA——广度和深度
BA的技能广度(图中绿轴部分):
BA所涉猎的行业和领域,比如银行、保险、电信、医药、能源、农业、教育等等;
这里“涉猎”的含义,不是指简单地知道某个行业是什么;而是指如果突然有一个这个行业的项目,规模大概在8人X3月时,能担负起“把客户/用户需求转换成软件需求的”责任。
BA的技能深度:
在某个行业/领域的视野和眼界(图中蓝轴部分),从小到大,依次是应用/系统, 到产品和流程,到企业战略和愿景,再到行业发展趋势和愿景,反映了在行业领域能够把控的深度。
专业上的杠杆领导力(图中橙轴部分):从个人自己的技能胜任,到使能自己所在团队、所在客户、内部实践社区、甚至外部职业社区的杠杆领导力。举个例子,作为BA可能是软件团队里面最多开会的人——“会议王”,会议引导能力很强。那当所处的场景是,40个不同角色不同背景的人要开会做出重大决策和计划的时候,是否能有效识别、激发其中的一些人作为“协助者”,发挥协力在这个场景下把会议引导地很高效呢?这就体现了杠杆领导力。
BA的“生存圈”和“生长圈”
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/02-1.png)
图2: 我眼中的ThoughtWorks BA——“生存圈”和“生长圈”
当我们刚入门BA时,相当于是在上图中的原点。图中最内红色的圈是我们的“生存圈”。在“生存圈”中,
我们聚焦的是要交付的应用和系统
我们的核心职责是需求沟通和澄清
我们扮演的“是业务和技术之间的翻译官、解释器”,我们并不被要求去挖掘业务痛点和需求、系统思考全盘分析识别业务优先级,而只是把需求能翻译、解释成技术更理解的语言,帮助需求被实现成为软件功能。
换句话说,在“生存圈”里,是在前面举例的5个左边的场景里,能胜任:
8人以下的团队里,能很好地收集、分解、表达、澄清、验收需求;
单一的Stakeholder的情况下,能很好地与之沟通,把他/她的想法能清晰、准确、有效地传达给技术团队;
面对的需求是做一个简单工具(如订单自动化上传),能清楚地勾勒、描绘用户与之的交互过程、步骤、每一步的输入输出、业务规则,并提供简单的交互设计建议;
客户/用户认知并能清楚表达自己的需求,能有效地捕捉、梳理、表达、管理好他们的需求;
在一个创业团队从0到1开发一个产品,能做用户访谈、理解用户的想法、把软件需求表达给技术团队、并能向用户演示、做用户测试。
跨越生存圈之后,就要在前述的广度和深度上继续拓展、深钻:
拓展行业领域的广度。比如如果已经是熟悉零售,又有银行工作背景,是否可以去拓展下互联网金融领域?
拓展行业领域的深度。比如在保险行业,只是能看到所做的在线自助服务应用;那可不可以拉长视野,在保险企业层面去看如何提升客户体验呢?是否能把自己在线自助保险服务业务上的知识,让全团队各个角色的人、全社区各个角色的人都清楚了解并掌握呢?
BA的技能图谱
BA从“生存圈”到“生长圈”,做到有广度、有深度,成为真正职业的“业务分析师”,我总结有五个方面的关键技能:需求、战略、产品、数据和流程。关键技能1:需求 – “需求沟通和澄清”
也就是BA在“生存圈”的必备技能,分解开来:收集业务系统需求
业务系统的流程的As-is和To-be分析
识别需求顺序和依赖关系,构建需求全景图
分析和沟通非功能性需求
需求分解,把大的特性(Feature)拆分成粒度合适的用户故事(User Story)
能应用INVEST原则,细化用户故事(User Story)的详细需求
低保真界面原型以沟通和澄清需求
能做功能演示和验收测试
关键技能2:战略 – “业务洞察和方案”
这是走出“生存圈”之外的一个重要能力,即有战略视野,真正连接业务、用户和技术,在企业级提供咨询建议。这意味着:能快速进行行业研究,并提供有价值的行业洞察报告
能和CxO对话,建议和销售战略计划
能完成售前解决方案建议书,或提供战略性的建议
能驱动完成大客户发展规划
能帮助客户规划愿景、目标和路线图
能完成市场、用户、和竞品分析
能规划执行的方案、范围、优先级
能发现、提炼案例并分享给客户和外界
关键技能3:产品 – “产品定位和规划”
战略建议到落地层面,往往在于产品的开发和管理——产品机会的发现、启动、从0到1上线、运营增长、并不断演化的过程。具有“产品定位和规划”能力意味着:能带领完成用户、市场研究
能完成业务模式的提炼和设计
能带领完成产品路线图的规划
能清楚描述用户体验和产品需求全景
能管理产品需求列表及其优先级
能确定并管理产品需求的优先级
能制定产品交付计划、确定阶段性目标及需求
能确定关键需要跟踪的运营数据、并指导如何用数据验证假设
能跟踪和管理产品交付进度
能管理产品上线
能提供运营建议
关键技能4:数据 – “数据分析和建议”
对数据的洞察力,将是未来企业的核心竞争力。如果要能为业务提供建议、做产品规划,其基础之一就是要能做数据分析,“懂”数据:能帮助企业进行数据的采集、存储的战略和方案设计
能帮助完成数据如何清洗、规整、质量监控和提升的方案
能指导业务场景的KPI指标设计和跟踪框架
能结合业务场景,指导数据分析的模型,如数据的属性、数据来源、统计角度、频度等
能指导数据的可视化和解释呈现
能使用工具进行数据分析,提供洞察,比如进行探索性分析、预测性分析、假设验证分析等
关键技能5:流程 – “决策引导和沟通”
在我前面举例的场景中,如果去思考右边的5个场景,会发现其中需要的不仅是个人的远见卓识,而是能多大程度上有谋有略地引导一个复杂的团队和组织有效进行决策和沟通,这意味着:有效连接业务、用户、和技术,建立一致的沟通语言,填补沟通漏洞
能指导业务需求管理的流程
能进行Stakeholder管理、提升合作关系
能进行范围和优先级管理
能进行关键流程的设计、引导其解决问题流程、决策流程、冲突流程、需求管理流程等
能高效驱动决策形成
能培训和指导团队的问题解决流程和实践
除了以上所说的5个关键能力,系统思考、沟通表达、研究分析和总结、以及敏捷和精益这些软性的技能则是这些技能的基础。综合以上,BA“化繁就简”的技能树如下:
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/03-1.png)
图3: 我眼中的ThoughtWorks BA——“技能树”
这是一个开放的能力框架。时代在变化,BA的能力框架也应该不停地演进,所以我选取了“树”这种表达方式,期望它是“开放”的,可以不断生长的。(或许我明天的想法就会与这个不同?)
BA技能如何生长?
虽然说,没有一个完美的能力模型,但如果想提升整个组织的BA能力,还是建议组织里要有一个能力框架基线。那么,学习途径就是:首先,通过组织的BA能力模型,识别自己的重点发展方向和若干项能力短板;
从0-4提升、有计划地提升自己的能力。
![](http://insights.thoughtworkers.org/wp-content/uploads/2016/05/04-1.png)
图4: 能力水平的评估和学习曲线
技能提升的方法
对一块技能的掌握程度,有下面几个层次:0 – 没有相关知识
1 – 知道相关知识(常规套路和工具)
2 – 能按常规套路和工具解决问题
3 – 能创造新方法和新工具解决问题
4 – 能教他人方法和工具来解决问题
从0-1这个层次,是不太需要外力的,自己通过搜索相应的资料,能够很快总结出来常规套路和工具。拿梳理需求优先级为例:
阅读5篇以上关于这个主题的比较经典的文章 (如果不知道,可以请别人推荐来源)
自己总结出一些常规的套路和工具 (能从最基本的角度讲清楚What, Why, Who, When, Where, How)。
从1-2这个层次,必须要靠实践,需要通过项目机会来尝试运用所学的基本套路和工具,可能在一开始会走很多弯路,犯错误,但这是学习的必经过程。
从2-3这个层次,则需要很多个项目的经验积累,融会贯通,灵活运用,乃至创造出新的方法和工具。这外力上需要机会,内力上需要持续总结。
从3-4这个层次,则是需要有很强的“发现总结模式”的能力,即使自己没法亲身经历过100个不同的项目,但还是能总结出10种套路和工具,覆盖到其中99个项目,从而能够教会其他人如何解决问题。这个层次更多的是靠内力,持续思考和总结了。
我的一些学习体会
自我驱动 over 外力指导或培训。如果某些时候,觉得自己必须依靠外力培训才能提高,可以问自己这个问题:“请问我自己看过关于XX的10篇文章吗?请问我自己看过关于XX的3本书吗?请问我自己从这些文章或书中总结除了一些常用方法和工具吗?我可以从翻译一些文章开始来积累知识吗?”
最有效的学习途径是教他人学习。有项目机会固然可喜,没有项目机会的时候,我也会通过给团队同事做分享、组织内部培训、去给外部社区做工作坊、去实地公益组织探访、尝试去给客户做咨询等,来自己挖掘“问题场景”体验式学习,这些都是非常有效的学习方法。前年在公司做的”团队引导培训“就完全是自己学习、自己开发课程、自己去试讲,然后就得到机会到不同办公室、软件园、客户那里讲,做完之后完全感觉不一样了。
刻意练习。作为BA,我们至少每天可能要开1-2次会,这么多次会,我有没有在每个会议中都总结我可以准备得更好、表达得更好、节奏控制得更好、总结更精准的地方?如果坚持把每次会议都当成会议引导技能提升的练兵场,相信收获会更大。大家可能觉得回顾会议没什么特别,一直使用Well/Less Well/Puzzles这一种方式来做,但是否知道同事Patrick Kua单就回顾会议的方式写了一本书;Paulo Caroli 则专门开了博客专栏来写回顾实践。单一个敏捷回顾就能造就专家,何况我们引导那么多会呢……
思考和总结的习惯。同事王健说过,“不把信息当知识,不把收藏当学习,不把阅读当思考,不把储存当掌握”。做过一次工作坊,就总结下自己做的流程;做过一次售前,就总结下售前的得失;看过几篇银行业务的文章,就写个读书笔记。花多少时间和思考,决定了自己学习的加速度。
提升学习速度。不知道大家是否也有这种感觉,就是时间变化快,几年前学习的一个方法可能现在就不适用了,或者已经演进成新的了。如果读一本书要半年,写个总结要花两个月,我觉得完全满足不了市场变化对我们知识和能力的需求。至少,应该要提升三倍以上的学习速度吧。
相关文章推荐
- Hibernate集合的二级缓存
- 拼图小游戏
- 正则表达式
- 每个程序员必看:如何在40岁后继续做软件开发?
- 部署Qt程序时plugins相关问题
- 聊聊同步、异步、阻塞与非阻塞
- 全栈工程师学习Linux技术的忠告
- VS2013 编译程序时提示 无法查找或打开 PDB 文件
- 有趣,也言之有物。
- 【CQOI2014】【BZOJ 3506】【JZOJ 3599】排序机械臂
- NOI2010 超级钢琴
- OpenStack Mitaka Nova API 接口扩展之instance_resize
- Effective stl 第24条:当效率至关重要时,请在map::operator[]与map::insert之间谨慎做出选择
- 移动web前端下拉刷新效果
- [置顶] 【LCA】目录
- 1026 程序运行时间
- RelativeLayout的属性使用
- Android不点赞/踩不让提交评论
- Hibernate考试选择题解析
- linux命令行常用光标移动快捷键