【精选】我眼中BA(业务需求分析师)的技能广度和深度.pdf

我眼中BA （业务需求分析师 ）的技能广度和深度 BA ，或者称业务分析师 ，是企业数字能力和业务能力之间的沟 桥梁。随着企业数字转型的 进一步深化 ，相信对BA这样的技能需求会越来越多 ，只是未必都用“BA/业务分析师”这样 的T it le。 T ho ught Wo rks在创建之初 ，就有BA这样一个职位。Lupi Messenger是我的一个同事 ，她 是T ho ught Wo rks的第一批BA ，到现在为止做了18年 ，孙女都已经上小学了 ，我很仰慕。这二十年 间变化很大 ，需求分析方法从最初的敏捷用户故事 ，演进到现在精益为基础的需求分析方法 ，BA 的 技能要求也在不断变化。整理出一个大家都认可的BA技能图谱 ，几乎是个不可能的任务——即使仅 限T ho ught Wo rks所要求的BA技能 （我在T ho ught Wo rks是所见的不同时期的BA技能图谱要超 过10个 ）。但所有的表达都是为了交流和学习 ，不是为了“证明自己是对的” ，所以斗胆结合自己的 经历 ，谈谈我心目中T ho ught Wo rks版的BA技能图谱 ，并分享一些学习提升的方法。 BA 的广度和深度“在T ho ught Wo rks做BA是怎样一种体验”中提到 ，BA 的职责是把业务和用户需求 转换为软件需求。即使是这样一个单一职责 ，也会有不同的场景 ： 8人以下的团队 vs. 4 0个人的团队; 单一的 t akeho lder vs. 跨不同业务部门 ，庞杂的多个 t akeho lder ； 面对的需求是简单的工具(如订单自动化上传) vs. 一个复杂的产品平台 （如一个新的互联网金 融平台 ）； 客户/用户对自己的需求有清楚的认知 ，并能清楚表达 vs. 客户/用户并不知道自己需要什么 ， 或者知道但表达不清楚 ； 在一个创业团队上线一个产品 vs. 在一个大型企业里推动产品体系改变 能在左边的场景里做到优秀 ，是否就意味着在右边的场景下就同样能做到优秀呢 ？相信大家有了自 己的答案。在T ho ught Wo rks这样的专业服务公司里 ，我这样看BA 的技能广度和深度 ： 图1 ： 我眼中的T ho ught Wo rks BA——广度和深度 BA 的技能广度 （图中绿轴部分 ） BA所涉猎的行业和领域 ，比如银行、保险、电信、医药、能源、农业、教育等等 ； 这里“涉猎”的含义 ，不是指简单地知道某个行业是什么 ；而是指如果突然有一个这个行业的项目 ， 规模大概在8人X 3月时 ，能担负起“把客户/用户需求转换成软件需求的”责任。 BA 的技能深度 在某个行业/领域的视野和眼界(图中蓝轴部分) ，从小到大 ，依次是应用/系统, 到产品和流程 ，到企 业战略和愿景 ，再到行业发展趋势和愿景 ，反映了在行业领域能够把控的深度。 专业上的杠杆领导力(图中橙轴部分) ：从个人自己的技能胜任 ，到使能自己所在团队、所在客户、内 部实践社区、甚至外部职业社区的杠杆领导力。举个例子 ，作为BA可能是软件团队里面最多开会的 人——“会议王” ，会议引导能力很强。那当所处的场景是 ，4 0个不同角色不同背景的人要开会做出 重大决策和计划的时候 ，是否能有效识别、激发其中的一些人作为“协助者” ，发挥协力在这个场景 下把会议引导地很高效呢 ？这就体现了杠杆领导力。 BA 的“生存圈”和“生长圈” 图2 ： 我眼中的T ho ught Wo rks BA——“生存圈”和“生长圈” 当我们刚入门BA 时 ，相当于是在上图中的原点。图中最内红色的圈是我们的“生存圈”。在“生 存圈”中 ，我们聚焦的是要交付的应用和系统。我们的核心职责是需求沟 和澄清 ；我们扮演的“是 业务和技术之间的翻译官、解释器” ，我们并不被要求去挖掘业务痛点和需求、系统思考全盘分析识 别业务优先级 ，而只是把需求能翻译、解释成技术更理解的语言 ，帮助需求被实现成为软件功能。 换句话说 ，在“生存圈”里 ，是在前面举例的5个左边的场景里 ，能胜任 ： 8人以下的团队里 ，能很好地收集、分解、表达、澄清、验收需求; 单一的 t akeho lder的情况下 ，能很好地与之沟 ，把他/她的想法能清晰、准确、有效地传达给技 术团队 ； 面对的需求是做一个简单工具(如订单自动化上传) ，能清楚地勾勒、描绘用户与之的交互过程、 步骤、每一步的输入输出、业务规则 ，并提供简单的交互设计建议 ； 客户/用户认知并能清楚表达自己的需求