BA的广度和深度

作者: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的技能广度和深度:

01

图1: 我眼中的ThoughtWorks BA——广度和深度

BA的技能广度(图中绿轴部分)

  • BA所涉猎的行业和领域,比如银行、保险、电信、医药、能源、农业、教育等等;
  • 这里“涉猎”的含义,不是指简单地知道某个行业是什么;而是指如果突然有一个这个行业的项目,规模大概在8人X3月时,能担负起“把客户/用户需求转换成软件需求的”责任。

BA的技能深度:

  • 在某个行业/领域的视野和眼界(图中蓝轴部分),从小到大,依次是应用/系统, 到产品和流程,到企业战略和愿景,再到行业发展趋势和愿景,反映了在行业领域能够把控的深度。
  • 专业上的杠杆领导力(图中橙轴部分):从个人自己的技能胜任,到使能自己所在团队、所在客户、内部实践社区、甚至外部职业社区的杠杆领导力。举个例子,作为BA可能是软件团队里面最多开会的人——“会议王”,会议引导能力很强。那当所处的场景是,40个不同角色不同背景的人要开会做出重大决策和计划的时候,是否能有效识别、激发其中的一些人作为“协助者”,发挥协力在这个场景下把会议引导地很高效呢?这就体现了杠杆领导力。

BA的“生存圈”和“生长圈”

02

图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“化繁就简”的技能树如下:

03

图3: 我眼中的ThoughtWorks BA——“技能树”

这是一个开放的能力框架。时代在变化,BA的能力框架也应该不停地演进,所以我选取了“树”这种表达方式,期望它“开放”的,可以不断生长的。(或许我明天的想法就会与这个不同?)

BA技能如何生长?

虽然说,没有一个完美的能力模型,但如果想提升整个组织的BA能力,还是建议组织里要有一个能力框架基线。那么,学习途径就是:

  • 首先,通过组织的BA能力模型,识别自己的重点发展方向和若干项能力短板;
  • 从0-4提升、有计划地提升自己的能力。

04

图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 则专门开了博客专栏来写回顾实践。单一个敏捷回顾就能造就专家,何况我们引导那么多会呢……
  • 思考和总结的习惯。同事王健说过,“不把信息当知识,不把收藏当学习,不把阅读当思考,不把储存当掌握”。做过一次工作坊,就总结下自己做的流程;做过一次售前,就总结下售前的得失;看过几篇银行业务的文章,就写个读书笔记。花多少时间和思考,决定了自己学习的加速度。
  • 提升学习速度。不知道大家是否也有这种感觉,就是时间变化快,几年前学习的一个方法可能现在就不适用了,或者已经演进成新的了。如果读一本书要半年,写个总结要花两个月,我觉得完全满足不了市场变化对我们知识和能力的需求。至少,应该要提升三倍以上的学习速度吧。

以上仅是我的个人观点,10个ThoughtWorker心目中可能有10个不同的理想BA画像。“观点就是用来批判的”,所以欢迎大家的各种批评,以及赞扬(如果有的话)。最后,学习快乐! 祝大家都能早日点亮技能图谱上的各颗星星,有广度,有深度!

Share

大象转身,一蹶不振还是华丽重生?

以社交媒体、移动、客户数据洞察、物联网(Internet of Things)为代表的数字技术正在革新商业生态圈。数字化风暴极速冲击着金融行业,第三方支付、P2P网贷、众筹融资、电商小贷、虚拟货币、金融网销、垂直金融搜索入口、理财工具和服务、金融咨询和法务援助等等创新金融模式,极大地颠覆着金融生态。来自花旗银行的报告称 ,以金融科技驱动的这些新型金融业务已经把传统金融业务逼上了绝路,以美国市场为例,到2023年,新型金融科技的收入将占到17%;在中国,当前支付宝的支付量已经超过了工商银行和招商银行信用卡交易量的总和。将对于传统金融企业来说,数字化转型、投资金融科技是必然、唯一的选择。

数字化转型是传统金融企业的共识,但转型路线却不同,大致呈现出三种模式:

  1. 在组织外部设立单独运营实体。运用资本优势和资源优势,通过战略投资,开发新的目标客群或细分客群,以全新「互联网商业模式」运营。新旧模式并行不悖,两条腿走路。典型的案例如「众安在线」之于平安。
  2. 在组织内部建立「数字特区」。企业内部对子公司或部门充分授权,允许各自创新经营模式和方法,相互竞争,倒逼整个企业走向「数字化」。这好比平安集团下的陆金所之于平安银行。
  3. 全面转型,让所有流程、产品与服务立即实现数字化。立足既有商业模式和业务运营优势,建立数字化渠道、提升数字化能力,在组织结构、企业文化、数字化技术、产品创新、运营模式做全面转型,成为全面「数字化」企业。

通常认为,全面转型最难,会遭遇到组织文化、业务运营、产品和技术等多方面的冲突和挑战,如同大象转身,或一蹶不振,或华丽重生。过去十年间,我们有幸见证了一家国外某传统大型金融企业的转型历程。他们有着怎样的经历?有什么样的经验和教训?同为大型传统企业,我们可以从中学到什么?

转型企业背景

该企业是某国家最大金融保险集团,转型之前兼并购买了众多市场竞争者,总资产约1000亿美元,业务涉及银行、保险、制造维修等领域,旗下拥有银行、一般保险、寿险等业务线和20多个市场品牌。

转型前的2006年,企业面临前所未有的挑战:

  • 组织机构庞杂,业务冗余,效率低下。因为兼并购买了多个市场竞争者,造成组织结构过于庞杂、文化不统一、业务冗余、运营成本持续攀升。如同老爷车,干着急就是挪不动。
  • 市场竞争白热化,第一的位置受到威胁。身处开放性的金融市场,有来自海外的竞争者和本土的跨界竞争者,过分依赖少量客户,业务上保险强银行弱,而排在第2、第3的竞争对手有很强的银行业务能力,导致第一的地位岌岌可危。作为上市公司,兼并购买其他小型保险竞争者也是无奈之举。
  • 产品创新乏力,缺乏新的业务增长点;传统行业的思维和开发方式无法适应市场变化。
  • 人员成长遇到瓶颈,复杂的组织结构、管理模式导致人才流失严重,企业缺乏活力。

企业遭遇发展瓶颈,必须转型,怎么办?

数字技术的兴起对于当时这只大象,与其说是「风暴」,不如说成了「救命稻草」。相对于互联网金融企业,该传统金融企业也具有它自己的优势:占据行业领头位置,熟悉行业规则;过去多年运作积累的风控能力和技术能力;相对庞大的存量客户资源;多年积累的业务运作能力;专业的人才储备和社会公信力。另外,还有锐意进取的领导层和协作型的企业文化。

挑战和问题集中到三个方面:如何打造数字化基础架构和能力?如何与客户建立起紧密联系?如何提供个性化、差异化的体验和服务?从集团CEO到业务CEO到CIO,共同构建了围绕这三个核心问题的转型愿景:

emagazine pics-05

图1. 企业转型愿景

愿景只是美好的表象,执行落地才是硬道理。愿景需要转化为具体的执行战略。该企业做了如下跨度超过十年的的转型路线图:

emagazine pics-07

图2. 企业转型战略

该企业开始了为期十年的改革和持续改进,每一个阶段重点解决一个问题:

  • 第一阶段:聚焦于敏捷组织转型改革企业组织结构和文化,为组织赋能。企业最重要的活力源泉在于人才,传统臃肿的组织结构和文化严重地束缚了人才的活力,所以率先要先改革组织结构和文化,恢复组织机能;
  • 第二阶段:聚焦于IT系统和业务流程简化,释放组织潜能,向「客户」为中心转移;
  • 第三阶段:聚焦于技术战略,构建多元化数字渠道,提升用户体验。

艰难而漫长的转型历程

第1阶段:敏捷组织转型 2006-2011

企业做转型,组织文化必须先行,该企业的领导深谙其道。转型战略的第一步,即从敏捷组织转型开始。通过与全球顶尖的敏捷组织转型厂商合作,该组织实行了如下举措:

  • 运营合一化。所有业务不管原来归属于哪个公司,统一按照业务线重组,每一条业务线的不同品牌的产品采用同一套管理团队和管理制度;
  • 组织统一化。原有不同公司的IT部门、客服部门等全部合并重组,成为统一的IT服务组织、客户服务组织等;
  • 企业同一化。整个企业,不管历史上归属于哪个品牌哪个公司,全部同一战略,同一文化,同一步调。
  • 进行组织改革,实施「敏捷组织转型」。先从IT部门开始,引入全球顶尖的合作伙伴,全面进行敏捷转型,贯彻敏捷文化、管理实践和工程实践;然后再由IT部门,扩展到业务部门,打造「以人为中心」、协同的工作文化,同时提升个体的适应变化的能力。

在这五年的敏捷组织转型过程中,80%的员工接受了敏捷培训、每一个业务、IT团队都能够运营敏捷实践来提升响应市场变化的速度。更让领导层没有想到的是,此项变革不仅让组织产生活力,而且直接因为消除浪费而降低了运营成本:据集团年报数据,因为敏捷组织转型每年结余2亿左右。这坚定了领导层战略转型的信心。

第2阶段:遗留系统优化 2011-2014

很多传统金融企业在转型时,往往会从「客户端」出发,比如先做移动应用寻求产品销售、利用社交媒体做数字化营销。该企业在这一阶段内部也形成了很大分歧。中间也是一波三折。最终,强有力的领导层决定从企业「中端」和「后端」开始,先进行IT系统和业务流程简化,在此基础上再加大消费者端的数字化。

  • 简化后台系统。启动持续3年大型后台系统简化项目集,比如其中的一个核心业务系统14个后台系统简化到1个;整合组织内部运营系统,如财务、人事、客户关系系统(CRM)、核心精算系统、计费系统,以简化流程、减少浪费。
  • 统一数字渠道。
    • 整合所有业务和客户数据。所有业务和客户数据迁移到统一整合的数据存储后台,清理了重复数据,也可以准确鉴别客户信息,实时获取客户购买集团下所有产品,为进一步使能数据能力打下基础。
    • 统一业务流程。在统一数据和业务交易平台的基础上,统一所有品牌的销售、风控、和服务流程,同一呼叫中心的服务可以在多品牌中复用(比如客户修改地址,多个产品的地址可以同时修改好)。这样,每一次合并一个品牌到统一流程里,就会同时关掉原有品牌下的若干呼叫中心,极大地节省了成本,提升了运营效率。
    • 整合业务数字化渠道,统一构建核心在线平台。不追求在线平台中产品和功能的丰富性,而是让20多个不同品牌能用同一在线平台,然后逐步丰富产品线和功能。

后来在回顾这段历程时,我们才意识先从「中端和后端」开始加强数字化是明智的:如果客户数据都不统一、后台流程落后冗余复杂的情况下,精准数字化营销、在线体验是不可能提升的。这一阶段的转型,据企业年报中的数据,我们看到给企业带来的转变是:

  • 转型第1年收益4百万美元;
  • 每年IT成本节约2.2亿美元;
  • 产品上线周期减少了40%;
  • 综合线上营收占比提升到了75%;
  • 单个线上用户价值提升了3倍;
  • 线上渠道销售转换率提升了5倍。

第3阶段:数字渠道差异化 2014-2016

有了组织文化做基础,统一的IT系统和业务流程做保障,接下来的这个阶段,就是革新技术战略,构建多元化数字渠道,提升用户体验,向真正「互联网化」的转型愿景迈进。

emagazine pics-06

图3. 全渠道经营模式

emagazine pics-08

图4. 差异化和个性化业务服务

  • 革新技术战略: 与最领先的云厂商合作,承担行业领军地位,推动建立金融行业云架构行业监管和规范;进一步提升IT运营能力,跟踪用户线上行为足迹,在更精准的时机接触客户,提高转化率;
  • 多元化数字渠道建设,保险业务线上线下业务完全整合,形成「全渠道」经营模式。线上线下的整合其实更是一场组织变革。企业的领导层决心非常强,就是要「弱化渠道」,改革业务组织结构和绩效考核方式,按业务线来综合线上线下业绩综合考核。每个业务线的品牌迁移到新的在线平台中,就会关停原有品牌的若干电话呼叫中心,这在项目启动之始就会纳入计划,保证执行。
  • 个性化用户体验,差异化业务服务。以用户数据分析为基础,找出目标用户群,进行用户访谈,验证需求,通过体验设计来推出创新产品已经成为大家可以相对熟练应用的工作模式。在线上跟踪用户行为数据,提供基于位置或是相似度的商品、服务网点、理赔中心推荐,提供以用户为中心的自主服务为增强客户粘性,在枯燥的用户投资管理中,加入游戏化成分等。

这一段历程相对于前两个阶段,要顺利一些,因为经过多年的敏捷组织转型、精益创业和体验设计的思维已经深化到组织基因中。虽然这个阶段目标还未达成,但对比十年前企业转型前的状态,企业无疑更加在线化、数据化:

  • 从政治复杂、效率低下、自主能动性差,变革为拥抱变化、拥抱创新的组织;
  • 从陈旧落后、不可用、 风险性高的IT环境,变革为以自主云平台为基础的安全弹性的IT环境;
  • 从复杂、低效、落后的IT系统,到简化易用统一的技术平台;
  • 从破碎、分散的数据碎片,到整合智能的大数据分析支撑;
  • 从标准化、单一化的业务服务,到个性化、差异化的服务;
  • 从单触点与用户孤立连接,到多触点与用户紧密连接。

「大象转身」的启示

从2006到2016,可谓「十年磨一剑」,而且转型的路途仍在继续甚至步调更快。但欣喜的是,它给业界提供了「大象也能转身」的参考案例。每一个大象都是不同的,转型之路也必然不同。如果说有启示,借用该企业CIO的话,即:

  • 企业全面转型必须系统的战略规划,而不是在单点上应用技术就能奏效;
  • 转型需要坚定的领导力和执行力,十年如一日,保持战略的连贯性和执行力度;
  • 组织结构和文化是企业释放潜能的本源,变革必须以敏捷组织转型为基石;
  • 全球顶尖合作厂商能力注入,是激发企业活力、刺激企业变革的关键举措;
  • 「技术即业务」,要做技术的先驱者,主动变身成技术公司,以技术推进业务创新。
Share

业务分析实践:10个常见问题

在敏捷社区里, 下面这10个关于业务分析的问题会经常被人问及。我也一直在思考这些问题,结合过去8年来的敏捷项目上的经验,试着做个简单的解答,希望能给大家以启发。

1.进入到迭代的用户故事,到底拆到多大尺寸为好?

我会尽可能让拆分出来的卡,3天左右能够开发完成(无论是否结对)。比这个尺寸大的卡,因为请假、周末等中断会导致更多的背景重建时间,而且会让开发易产生“疲劳感”;比这个尺寸小的卡,卡片管理的边际成本会比较高。

2.在迭代计划时,是否重新评估并调整用户故事的点数?

我会尽一切可能不去讨论、调整卡的点数,而且会尽可能防止团队这样做。经验告诉我,这完全在浪费时间。当项目进入交付阶段后,只要业务需求范围没有变化,就不应该出现点数变动。

3.临时拆分出的技术任务卡和迭代中发现的缺陷卡,要不要给点数?

不给。同上,只要业务需求范围没有变化,就不应该出现点数变动。

4.不同的卡中,验收标准可以有重复吗?比如我们有按关键字、名称、地址来搜索客户的功能,搜索结果的页面都要分页。现在我们每个卡中都有分页相关的验收标准。

不要有重复。我们知道测试用例讲究“相互独立,完全穷尽”,这同样适用于需求。所有卡片上的验收标准,组合起来应该不多不少刚好等于整个项目的需求范围。好比图A。当有不同卡片的验收标准重复,不完全独立,就像是图B,导致额外的重复成本;当所有卡上的验收标准组合起来,不能覆盖到整个项目的需求范围,就是有需求遗漏,好比图C。

 

图C

 

对于这个问题中的例子,我的做法是把搜索结果的分页显示拆分成一个独立的卡,然后在每一个搜索卡中,加一个标注说,搜索结果需要分页,并关联到这个分页卡。

还有例子的“跨功能性需求”(Cross Functional Requirements)。比如做UI的卡,都需要遵循统一的VI标准,比如用什么样的按钮、什么样的字体、颜色风格等,我一般会创建一个共享页面,来描述这个所有UI卡都要遵循的UI标准,然后在每个UI卡,标注说UI细节请参照共享页上的UI标准。

另外一个典型例子是做API项目。不同的API接口也都需要共同遵循一个技术标准,这个也不用在每个卡上重复去写,也是建一个共享页面来描述这个标准,其他卡来引用这个页面。

5.迭代计划或迭代汇报时,大家总是对着“点数”斤斤计较,客户希望加几个点,团队希望少做几个点,于是讨论焦点就变成和客户争执某个卡到底应该是2个点还是5个点,怎么办?

首先深表同情 – 但这是一开始犯下的错,估计纠正起来需要花不少精力。我的做法是,从迭代0开始,就引导客户“轻视”点数。做法是:

  • 做计划的时候,要对照着故事墙(或“业务全景图”),来列出迭代要完成的功能目标,强调为什么要完成这些目标,否则对整个交付计划的影响,在最后的10%的垃圾时间,顺带提下计划的点数是多少,想争论点数,啊没时间了!所以shut up。
  • 做汇报的时候,同样,强调完成了什么样的功能目标,有没有里程碑完成,利用故事墙(“业务全景图”)展示整体进度;当前核心的Blocker和Issue是什么,有什么行动来解决,然后再顺带提下原计划多少点数,完成了多少点数。如下图:

X review
总之,引导客户和整个团队,去看到整体需求完成情况,点数信息做参考,而不是围着点数转。

6.在项目快速启动(Inception)时,得到的“RAIDs” (分别代表Risk, Assumptions, Issues, Dependencies),在交付期间到底还有没有用?

大有用处。如目前的项目,我70%的精力其实都是在花在“RAIDs”上。其实在交付过程中,分析常规性需求是相对简单的;给交付带来困难和挑战的往往是这些RAIDs。分析、理解、跟踪、提前采取措施消除其影响,就会有效避免需求蔓延、提前化解“大老虎”危险需求、及时调整好客户期望,避免大的矛盾发生。每一个项目,我会去建立一个共享页面,列出所有的假设、风险、问题和依赖;提前1-2个迭代去分析这个列表:

  • 假设:有哪些假设现在就能确认是对的?有哪些假设是错的?错的假设意味着演变成了一个问题,需要移到问题列表上;迟迟无法验证的假设,请从假设列表移到风险列表。
  • 风险:如果发生了,会影响需求范围吗?有哪些备选方案?需要提前做什么准备?如果已发生,需要转移到问题列表。
  • 问题:所有的问题在创建之前,其实应该已经跟客户沟通过,不应该有意外;跟踪更多是报告状态,追着相关的人完成。
  • 依赖:跟外部接口人做好沟通了吗?最好/最差情况什么时候能解除依赖?

这些都是与需求紧密相关的,不能甩手扔给PM。在每一个迭代汇报或演示时,除了汇报进度,更要汇报RAIDs的最新状态;需要领导注意的高亮出来,经验证明这种场合消除问题会很有效。

7.BA(Business Analyst,也即业务分析师,是敏捷团队中的必要角色,下同)经常需要跟踪依赖和一些待处理的问题,这些需不需要可视化在故事墙/看板上?

要。这些可能会成为阻碍(blocker),我一定都会让它们可视化在墙上,这样客户、团队中的每个人每天可以看到。一块干净的玻璃,如果上面有一块明显的污垢,人天性里都回有擦除它的欲望。放在墙上,是同样道理。只不过这类卡片不应该有点数,或者点数为0。

8.在项目快速启动(Inception)时,我们已经找出了MVP,并确定为第一次发布的需求范围,且交付时间很紧张只有3个月。在交付过程中,有一个客户提出方向可能不对,建议重新发散想法确定需求,要不要这样做?

不要。对于绝大多数组织来说,尤其大型组织,所谓创新难有一个主要因素是“执行乏力”。从产品概念产生到第一个雏形上市,这是一个“快速试错”的过程;越试得快,离“正确”的目标就越近;即使第一次方向针对选错了,完整地收尾才能真正学习到“错误”在哪里。反复犹疑,只能让“不确定”越来越多,越不知道该怎么做。我自己的经验,一旦进入交付,尤其是短期极速交付,就是要尽一切努力帮助客户收敛,收敛,收敛。所以当我们去跟客户沟通需求时,不是真正地让他来告诉我们做什么,怎么做;而是“诱导”他同意按照我们想好的“性价比”最高的方式做。

9.客户提出了一些新需求,我做了足够扎实的分析,排了个优先级,想让客户放弃一些低优先级的需求,可无论我怎么说,客户都说这个优先级都是一样的,必须得做?

先暂时放下这个“事”,下点功夫在“人的需求”上面,挖掘下想客户最真实的个人诉求是什么?《商战往事》有段话我印象非常深刻“项目需求在内外部运作中、竞争中会源源不断地给个人需求提供机会,而个人需求在这个基础上,还包括内外部环境变革中源源不断地给项目需求制造动机,一个问题,一个概念,一个挫折,一种情绪,都会改变需求…”, 所以要追根溯源,才有可能解开谜结。

10.我好像绝大多数时间都在写卡,都没时间去想产品和业务,更别说去写总结和分享了。作为BA,该怎么分配自己的时间和精力?

刚才说的,项目中的时间,60%用于跟踪和管理RAIDs;15-20%时间来分析卡的细节并写出来;15-20%的时间做需求确认(做预验收和给客户演示)。这样自己与客户间的对话尽可能保持在骨干需求级别; 而不仅仅是需求的细节,这样才能把控需求大局。如果需求分析透了,写卡这件事其实比较简单,我会让我们团队的Dev/QA自己去写,我来审核。另外我一定会给自己找出额外的时间,用于学习了解相关产品行业、总结等。“磨刀不误砍柴工”,有时新的解决业务问题的思路、新的工具会让你“事半功倍”。

“敏捷无定式”, 这些答案仅是个人项目中的经验,可能不适用于所有的企业、项目和团队,有启发、能带来思考就好。

Share

构建“Big Picture”的四幅图板

我们常常说“要有Big Picture”,那么究竟什么是“Big Picture”呢?

假设你在项目组X工作了差不多有三个月了。设想有以下几个场景:

场景1:CLT本周刚好在这开会。厨房偶遇松哥,松哥问:“听说你在X组?是个美国的医疗知识方面的公司对吧?这个客户什么情况,咱们现在具体做什么呢?”松哥5分钟去继续CLT的会。你如何能在5分钟简明扼要地把这个客户的情况说清楚?

场景2:你受邀参加了一个外部大会,在活动间隙,有一些人听说你在ThoughtWorks做一个XX产品,表示出了兴趣。你如何介绍这个产品,进一步勾起他们的兴趣?

场景3:有一个新成员刚加入项目,需要请你把项目的情况花个15-20分钟给他简要地介绍一下。

场景4:在一个客户会议中,突然客户老板点你的名说,“XX,请问你能简要地给新加入我们业务部门的约翰先生介绍下我们目前产品和当前进度吧?”

这四个场景,分别是从客户、项目、产品、需求全景的角度在发问,刚好形成了“Big Picure”的一个基本框架。作为软件项目组的一员,所谓“Big Picture”就是对客户、产品、项目、需求有一个简洁明了的认识,脑子里对这四块有一个清晰的蓝图。“Big Picture”不是看不见摸不着的,下面就将给大家介绍四幅图板,帮助你让“Big Picture”现形。

1. “Big Picture”之客户——客户图板

场景1看似个很简单的问题,不就是介绍客户吗,但只要经历过的人知道,要三言两语介绍出关键点,是需要功力的。那么多信息,说什么?用什么词说?按什么顺序说?这里给出一个基本招式——“客户图板”:

01

在这一客户图板中,有6个关键区域,提出了6个关于客户的关键问题:

  • 客户是谁?一句话来介绍客户,通用句式“XX[概括市场地位的形容词][核心业务和服务]公司”。以介绍我们公司为例,比如“ThoughtWorks是一家全球领先的软件开发与咨询服务公司”。
  • 客户的核心产品和服务。客户有哪些核心产品和服务(尤其是市场上有知名度的、有特色、值得一提的)。
  • 客户当前的市场地位如何?用一些让人一听就明白的数据指标,比如介绍顺丰,“顺丰速运目前总市场份额占第二,高端速递排名第一……”;也可以加上主要竞争对手。
  • 客户的愿景、目标?一句话来描述客户在长期的发展愿景。知名企业一般主页、网上新闻一搜都能搜到。
  • 客户当前面临的问题和挑战?现状与愿景之间的差距。
  • 客户的战略和机会?我们(ThoughtWorks)帮客户做什么?客户自己实现愿景的战略思路是什么?落脚到客户对我们的诉求,为什么跟我们合作,想从我们这里得到什么?

把这些问题的答案概括凝练成简洁的关键词、关键点,可视化在一幅图板上,尽可能让所有人(甚至包括客户)时时刻刻都能看到;任何人如果发现上面的信息不准确,就可以触发讨论,因而保证大家看着同一张板子,在同一个Page。

2. “Big Picture”之产品——精益画布

我们目前不管是哪个组,实际上都在某个产品上工作,只不过是2B和2C的差别而已。从产品角度来说,把握Big Picture,第一能概括产品的“魂”的当属精益画布(Lean Canvas)。这已经算是大家非常熟悉的工具,所以废话不多说,直接上示例:

02

  • 关于使用这一图板,大家可能常有的疑问是说:“这不是在产品创意之初才使用的工具吗?我现在都是在维护产品了,做这个是不是没有用处?”

记得之前Dai Zhang 分享过一个经历,是说咱们到客户现场做启动项目,其中一个环节是进行一个商业模式画布的讨论,客户说“你们觉得这商业模式是在这里讨论出来的吗?…” 使用工具的目的是验证我们的思考,工具本身并不能产生好产品创意。从验证和分析的角度来说,在产品生命周期的任一阶段,都适用。更重要的是,在涉及到客户、用户、客户的不同部门、甚至客户的客户、以及合作伙伴如我们自己这么多人合作的团队里,我们往往以为“我们对产品的方向的理解是完全一致的”,很不幸这是错觉。我们需要一块把各自脑子里的假设可视化出来的图板,迫使大家去思考、去争论,达成真正的一致。况且还有一些组,因为种种原因,在产品构建之初就没有形成这样一幅板子、也没用精益产品这样的方式思考过。在任何时间点,我们都可以用这样的思维来重新审视我们正在做的产品,指导我们的决策。我就曾经利用这个图板来帮助砍需求。我们所做的产品是服务于呼叫中心的CRM产品,因为所有的呼叫中心人员都要访问这个系统,所有曾有客户各个业务部门需要再这个系统上添加保单特殊处理流程。当摆个图板架构明确出这个产品的“界限”在哪里的时候,客户就自觉把那块需求放成低优先级了。

  • 可能还有的人会问:“我们不太方便于让客户参与进来,但光凭我们,想破了脑袋也填不出来这个怎么办?”

这类图板更多是一个分析和思考工具;思考的过程比结果更重要。所以只要团队(哪怕只有我们没有客户)开始在用这种方式思考、在不停讨论,就是在进步。当找不出答案的时候,我们就会去做更多地调查挖掘这产品的来龙去脉;做更多地研究,国内有没有类似的产品,是怎么回事?在这过程中得到的收获会非常大。

退一步,如果实在想不出来,不放大胆推断和假设,然后再在后续工作中验证自己的推荐和假设是否正确;不要怕图板展示出来别人笑话,别人觉得“不对”才会激发讨论,大家从而找到更为“正确、一致”的理解。这才是图板真正的意义所在。

3. “Big Picture”之项目——项目图板

无论是什么样的产品,要真正落地,就必须受到钱、时间、资源的限制,所以还是会以“项目形态”进行管理。那么获得项目全景也成了Big Picture的一个重要部分。回到最开始提到的场景3,如何向先加入的新人,简要地说清楚项目的轮廓呢?

  • 客户为什么要做这个项目?简单列出项目要解决的问题和业务价值。
  • 这个项目的成功标准是什么?列出项目成功的衡量指标。比如预期每月新增客户10%等。
  • 项目的方案是(综合业务和技术)?简要的方案,不需要列任何细节
  • 项目主要需要完成什么/大致范围?非常粗粒度地列出哪些是明确必须做的;哪些是范围之外的;哪些待定的。
  • 项目的决策优先级如何?质量、时间、预算、范围、体验等当这些因素冲突时,舍谁保谁?
  • 客户的负责人是谁?相关的重要干系人?不要让这些关键人物名单只藏在PM的脑子或记事本里,人人都清楚,有这根弦。
  • 项目的里程碑计划如何?注意是里程碑计划,体现关键时间点和目标信息,而不是发布计划(每个迭代做哪些需求)。
  • 主要风险、假设、问题和依赖?

上工具“项目图板”:

03

同样的,如果不是格外敏感的话,做个物理图板放在工作区,最好人人抬头都能看得见;并及时维护,保持信息的准确性。

4. “Big Picture”之需求——需求全景图板

在构建产品的过程中,所谓目标的完成、价值的实现,最直接可以看到的就是需求全景,以及针对全景的进度。前面精益画布和项目图板都有所涉及,但粒度上还不能达到“一览需求全貌”的效果,所有还需另外的需求全景图板。构建需求全景图板的工具有很多,比如故事墙、比如用例全景图、产品功能图谱,只要能全面、完整地表达出产品需求就可以。

下面直接给两个示例:第一个按故事墙;第二个按功能组织。

0405

除了提供需求全景之外,这个图板还有以下几个好处:

  • 可以在图上标记哪些需求完成,直接提供了一个可视化的“进展”图;
  • 建立了需求之间的有机联系,久而久之,大家闭上眼,不用参考这个,就能勾勒出需求的内容
  • 可以作为自动化验收测试或回归测试的重要参考
  • 当用户想加“不重要”的需求的时候,可以带着客户在这板子上过一遍,让他自己发现新的这个不那么重要、或者换个其他不那么重要的下来。

最后

借助客户图板、精益画布、项目图板、需求全景这四个工具,怎么应对最开始的四个场景,相信大家已有答案。

这四幅图板,提供了从客户业务、产品、项目、需求四个角度的全景蓝图,让所有人“On the same Board, on the same page”; 随时有这样的“Big Picture”做背景参考,日常遇到的种种针对于某个细节的难题或纠结,也会迎刃而解或直接消失遁形,“胸中有丘壑,叶纳百万兵”。

Share

在ThoughtWorks做BA是怎样一种体验?

BA,英文全称Business Analyst,也称业务分析师,或需求分析师。Linkedin上BA相关的职位不到产品经理或项目经理的四分之一。到本土的拉勾网、智联招聘等网站上,BA的职位就更少了。那么,

  • BA究竟做什么,有没有必要设置BA这一岗位呢?
  • BA具体会做哪些工作?一天会是什么样?
  • BA有哪些能力要求?BA的职业发展如何?

下面我仅就个人在ThoughtWorks的经历做些分享,可能不能代表所有BA,给大家一点参考。

 

BA做什么?为什么需要BA?

BA顾名思义,就是做业务分析。具体说来,就是能够把业务需求和用户需求转化为软件需求,保证最终的软件能满足用户需求,并带来业务价值。举个例子,

01

在软件开发过程中,大家都知道,需求信息要在很多角色中流转。没有BA的团队,需求大概是这样传递的:

02

大家知道,信息每传递一次就会衰减;况且在图上的每一个节点上,往往不是一个人,多人参与更容易失真。根据《组织行为学》中的相关数据,这样跨五层的传递,大约60%左右的信息能被完整无误地传递了。

而有BA的团队,需求则是这样传递的:

03

BA和每个角色都保持无缝的沟通,尽量在每一个节点向前验证需求,保证沟通的每个环节都是闭环,最大程度地减少需求失真。

目前在ThoughtWorks,90%的团队都会配置专职的BA, 只有少量规模很小的团队(如人数<=5个人),则会由其他角色兼任。

 

BA的一天,大概什么样?

如前所说,BA的工作主要围绕需求来展开。在ThoughtWorks的敏捷团队里,使用User Story(用户故事)来表达需求,所以具体的工作就是用户故事的发现、捕捉、拆分、设计、定义、Kick-off、预验收、演示和验收、上线及反馈等,这个过程中会与客户、用户、设计师、开发和测试沟通协作,确保大家做的是有价值的需求,并且对需求的细节有一致的理解。比如我现在的一天:

  1. 早上8:50到公司,看邮件,理一下今天的todo-list, 可能包括如下项(我当前这个组很特殊,会同时负责2个项目
  • 准备项目A在下周一的Showcase
  • 项目B下个迭代的故事卡 – 需要与另外一个BA再过一遍,确保卡上的细节准确无误
  • 项目A的两个故事卡Kick-off
  • 到客服中心去做用户访谈
  • 跟踪下昨天测试报告的外部服务接口好没好
  • 需要与设计师碰一下,把项目B涉及的UI改版的需求再梳理一下
  • ……
  1. 9:15和客户、团队一起站会
  • 更新自己负责的项目需求状态和变更信息
  • 认真听其他人的更新,及时发现有没有需要自己要澄清或跟踪的需求问题
  1. 9:30-9:45 给组里的新同事解答业务相关的疑问
  2. 9:45-10:15 处理一下紧急的客户邮件
  3. 10:15-11:00 与其他BA过项目B下个迭代的卡;
  4. 11:00-12:00 主持迭代计划会议 (怎么做,昨天已准备好)
  5. 12:00-13:00  午饭+休息,刷朋友圈
  6. 13:00-13:40  约到开发、测试,一起kick-off项目A的两张卡
  7. 13:40-16:00  出发去客服中心,用户观察和访谈
  8. 16:00-17:30  准备项目A的showcase讲稿,拉测试做一遍演练、检查外部服务接口是否好了
  9. 17:30 迭代计划会时发现了两个需求问题,发邮件跟客户确认一下
  10. 18:00 查看早上整理的todo-list,还好高优先级已经处理完

 

在ThoughtWorks做BA,跟在其他公司做BA有什么区别呢?

04

我之前也在一家通信企业工作过,属于PM兼BA的角色,对比下来,觉得区别主要在下面几个方面吧:

  • 在TW,我最常用到的工具是白板,PPT,卡片,便利贴;以前最常用的是Word和Visio。
  • 在TW,墙上贴得花花绿绿的,各种需求相关信息,开发测试问到需求,我也是随时随地都能解释;以前都是要翻出需求规格明书,对照着看,才能知道到底做什么。
  • 以前,基本上是做系统分析,到我手上的都是功能需求,有时候明知道做好了没有用户真正用这个功能,还是硬着头皮对照需求规格说明书逐条实现;现在在TW,会真正关注业务问题,用户场景,基本每一条在我手上经过的需求,知道它为什么要做,有什么价值。
  • 以前,几乎从来看不到客户,也不知道用户行为是什么样的;现在几乎天天跟客户打交道(只不过有时是在视频里),还有机会做真正的用户观摩和访谈、用户测试。
  • 以前,一年几乎只能看到1-2次产品上线;现在在这个组,每月都要有很多次产品上线,时不时能得到客户发的巧克力,T恤衫,还是挺受鼓舞的。

 

BA的职业发展怎么样?目前ThoughtWorks中的BA是不是仅能在内部发展?

以我自己的经验来看,BA是个综合技能要求很高的岗位,需求大局到细节的把控、提供业务方案建议、引导决策等等,尤其是大型的产品团队中,更需要综合的影响力和领导力。

之前的BA同事离开ThoughtWorks之后, 有的去做了产品经理,有的去做了数据分析,到其他大型公司里面做BA教练,还有的去创业等等。

在ThoughtWorks内部,有的BA想精专在某一产品领域,比如O2O, P2P还有金数据,实际上承担产品经理的职责,做需求分析的同时,还做售前、看市场和运营;有的则深钻某一个行业,去更多地做业务咨询、解决方案设计、数据分析师等。也有一部分,因为综合影响力和领导力得到了极大的锻炼,横向发展成为管理人员,比如目前我们的全球CEO办公室负责人,我所在组的大客户经理等。

ThoughtWorks是一个人才观非常开放的公司,在内部会鼓励大家“不设限”,主动去尝试很多不同的工作,创造新的“岗位”。

 

在ThoughtWorks做BA,觉得最好的一面和最坏的一面是什么?

最好的一面,是可以接触到各种类型、各种行业的客户,每次都能发现新鲜东西去学习去尝试;最差的一面,其实也是这个,因为有时候要短时间学习很多技能,压力很大。当客户老板说“五分钟之内把图画好”,我们说“好”的那一刻,万分紧张和忐忑;最终把事搞定之后,又是酣畅淋漓,痛与乐并存吧。

 

去TW做BA有什么具体要求呢?

还真没有硬要求,不讲专业,不需资历,也不需软件背景。大致说来,有这四点:

  • 有需求转换的能力
  • 逻辑思维好,清晰有条理
  • 沟通好,复杂的事情也能三言两语说清楚
  • 爱挑战,爱学习

还有的一些不是必须的,但如果能做到,就是加分项了:

  • 喜欢琢磨研究行业市场
  • 善于图形化表达信息
  • 懂敏捷和精益

 

以前没做过BA,但想试试,有书推荐吗

 

最后,以我们内部训练营的BA宣言结尾:

“Skill-set over Role; BA is Business Analysis rather than Business Analyst

角色不重要,真正有两把刷子才重要。大家共同学习,多多增长技能,才是重点。

Share