BA都在忙些啥 – 写给新人的BA工作说明书

BA全称Business Analyst，即业务分析师。经常会被别人问起，“BA平时究竟都在做些什么呀”？

在一个不熟习的人眼里，BA的工作看起来就是不停的沟通、写写客户故事、主持一下会议什么的。最风光可能是在showcase（产品展现会议）的时候，产品受到了客户和用户的一定；最落魄可能是在IPM（迭代计划会议）的时候，被开发们不停地挑战需求的正当性和完整性。除此之外，有时BA自己也感觉忙忙碌碌、但却又不知道在忙些什么。

有文章详情了在ThoughtWorks做BA是怎么一种体验，也有新BA分享她的ThoughtWorks BA初体验。

接下来，我想从一个“老BA”的视角，分享一下在一个软件交付项目中BA究竟都会做些什么？

BA的工作因产品所处的阶段不同而略有不同

image

首先要说的是，本文主要说的是BA在产品Delivery阶段需要做的事情。项目从前期的探究发现（Discovery）——定义要处理的问题和原型方案，到启动（Inception）——对产品定位、MVP范围、迭代计划达成一致，再到进入开发（Delivery）——完成产品的第一个MVP版本，最后通过产品经营收集反馈，迭代地进行产品演进（Evolution）。在这一系列环节中，BA做的事情不尽相同，各有各的侧重点。

Discovery中的BA：负责行业研究，企业业务的快速梳理，并和客户体验设计师（UX）一起通过客户访谈、现场调查等方式收集需求，定位问题并形成粗粒度的处理方案。

Inception中的BA：在梳理业务需求的同时能够对方案进行收敛，定义MVP和产品路线图，并配合开发进行工作量估算和给出具体的发布计划。

Delivery中的BA：将粗粒度的方案进一步细化，并将需求沟通给整个交付团队，保证需求可以正确地交付。假如有新的需求涌现出来，也需要按照Discovery和inception阶段中的方法来进行分析和交付。

Evolution中的BA：在产品上线后收集线上客户的反馈，参加产品经营和持续演进。

其中，Delivery环节往往是时间最久、精力耗费最多的一个环节，也往往是一个新BA起步的地方。所以接下来主要关注在这个环节。

BA都有哪几个方面的工作？

作为连接业务和开发的桥梁，BA的主要工作可以分成三个部分：第一部分是围绕需求开展的，涉及需求生命周期的各个环节。第二部分是围绕交付开展，包括确保需求在各个角色之间的流动过程中不失真，确保需求被正确地开发出来。第三部分是少量“杂事”。项目中大大小小的事情往往都需要BA的照料，只需能够推动整个项目按正确的方式做事，那就义不容辞地归入自己的工作范围。

所以简单来说，BA的工作就是确保整个团队做正确的事，以及正确地做事。

详细来说，包括以下：

image

需求发现、收集和方案提议

尽管在产品开发之前会有一个产品定位和业务全景图，但是任何产品在进入开发之后肯定还是会源源不断地涌现出新的需求。这些需求或者来自各个层面的反馈，或者来自用户领导，或者来自用户其余的业务部门，或者来自我们的主动挖掘。持续不断地发现、接受和解决这些新需求是BA的一个工作常态。

比方，一个汽车行业的用户，兄弟业务部门提出需求：希望我们的产品可以支持他们的汽车售后保修业务。对于用户而言，需要思考要不要接下这个需求？

1. 大致要做什么功能？对现在的产品定位、业务流程和价值有什么影响。
2. 假如要做的话，需要多少人天，对预算有什么影响？

对于BA而言，接下来要做的就是答复上面的问题，把信息提供给用户辅助他们做决策。

可是需求太粗略了，怎样办呢？于是，BA计划了一次客户走访，搞清现在的业务流程和痛点。搞明白其余业务部门提的需求究竟是在说什么，是不是真实的需求，有没有什么坑。接着，根据走访的结果梳理需求，而后和UX一起探讨粗粒度的业务方案，这个过程跟Inception很像。

接着拿着这个方案跟用户大致过一下，没有什么问题的话就叫上开发一起估算工作量，这时候估算只是粗略的，可能以20人天为一个单位。有了大致的方案、低保真的原型图和粗略的工作量估算，即可以把这些整理一下汇报给用户了。

最终的结果可能是一个做或者者不做的决定，以及对应的排期计划。有了这些，那么这块BA的工作就算告一段落了。一般一个100人天+的大块新需求分析下来，可能至少需要1~2周的时间。注意你还有日常的交付要做，这些只能抽时间精力来搞。

这一块的工作对于BA往往比较有挑战，尽管有可能并不会进入后续的交付，但却是表现BA核心价值的一部分工作。

需求分析与方案落地

一个大块的新需求有了方案之后，接下来就是把它细化，而后拆成客户故事并写出验收条件。这就是BA的基本功了。

从这时开始，思考粒度会从粗到细迅速下降。BA会和UX一起探讨：页面上具体该有什么信息呈现，有什么样的功能按键，交互和体验是怎么的。会针对各种细节争论不休，就为了呈现最好的客户体验。

而后就是把脑子里的想法写出来啦。按照客户故事的格式，思考怎样写可以让开发和业务部门都能看的明白清晰。写的过程中还可能会有新的想法出来，而后又跑去跟UX或者者Dev探讨。

最终这一部分工作的产出就是拆分后的客户故事列表，以及已经填充好内容的客户故事。

假如肯定要说BA的核心职责，那这部分应该算得上。又快又好的把这部分工作完成，而后腾出精力去做其余的事情。不要满足于停留在这里，毕竟这只是BA的基本功。

需求和方案对齐

image

由于Thoughtworks是一家专业服务公司，也就是说我们为用户提供处理方案。基于这样的合作模式，意味着BA需要将自己设计的方案和用户进行沟通，确保大家对于需求以及对应的方案有一致的了解。

为了这个目的，理想的方式是和用户一起工作。添加用户的参加感，让他们也参加到自己的产品设计过程中去。这样就不用花费过多的精力去跟用户同步方案，而后来来回回的修改、汇报。但鉴于每个项目用户的情况不同，有时候BA可能需要专门安排少量Story Review或者者Solution Review的会议来跟用户过方案。

这块的工作其实很考验BA的软技能，由于在这个过程中往往充满了各种意见上的冲突。怎样样能把自己的想法有条理地表达出来，怎样样能管理好用户的期望，怎样样去应对用户的质疑都是一门学识。

需求沟通与交付

假如用户拍了板，那么接下来即可以进入开发了。BA工作中的沟通部分从主外变成了主内。也就是说，外部跟用户之间已经达成了一致，接下来主要是把需求和方案精确地传达给交付团队，而后保证客户故事可以被精确的开发出来。BA主要做的事包括，制定迭代计划、主持IPM、参加Story Kickoff和Desk Check、组织Showcase、追踪迭代速率，以及随时澄清Dev，QA提出的各种问题。

别看这个过程貌似简单，却可能会有很多预料之外的情况发生。假如前面的工作做得好，这里可能会比较顺利，否则很多问题都会在这时候暴露出来，让BA疲于应付。比方：

1. 开发说这个客户故事卡的功能比想象中的复杂，可能做不完了。
2. 有些新功能与旧功能有冲突，事先没有想到。
3. 正在开发的过程中，用户提出了一个新的需求。
4. Desk Check的时候发现功能实现与设计的有出入。

等等。

理想情况下，在保证效果的同时，这部分工作所花的时间和精力越少越好。假如主要精力都花在了这上面，就要思考是不是哪些环节出了问题。

第三方集成支持

对于大用户而言，很少有不涉及集成的项目。有些项目，集成是一个大部头。以我上一个项目为例，涉及到的集成系统有将近10个。BA有时会花大量的时间在探讨集成方案、梳理接口字段、制定集成计划上。

BA也要关心集成么？当然。集成也事关业务场景、数据流。这些接口在什么业务场景下被调用，我们需要发什么样的数据给第三方，需要从第三方拿什么样的数据。从索要第三方的数据样例文件，到一个一个地分析这些字段的业务价值以判断哪些可以为我所用，再到撰写需求文档给第三方，这些都需要BA的参加。

而且集成最大的精力消耗在于沟通和谈判。比方，按对齐的接口文档开发，却发现第三方的实现没有按照文档来；单方面的接口变动没有事先通知；接口传的数据有误，污染了自身系统的数据，等等。

集成可能是BA最不喜欢参加的事情了。

image

上线和线上支持

假如以上的工作都顺利扛过来了，那么恭喜你，产品终于可以上线了。

这部分的工作包括上线过程的准备和上线之后的支持。比方写一大推的文档：客户手册，发布版本说明书等等。而后是密集的showcase, 毕竟新产品要上线，各个干系人都闻讯而来。某个用户方的大老板来了要show一下，客户代表来了要show一下，其余部门的人来了也要show一下。

千辛万苦终于上了线，接下来还要面对一大堆的线上问题。一般会有一、二、三线的产品支持团队，帮助将少量简单的问题进行过滤。但最终到BA这里的问题也不在少数。

除此之外，BA可能还会需要思考如何收集反馈进行产品演进。比方，用少量客户行为检测工具对产品埋点，追踪客户使用产品的情况。或者者有计划地安排少量客户走访来收集反馈。还要对各个渠道收集到的反馈进行整合，划分优先级，排进计划。

新人培养

对于一个项目制的公司来说，一个项目团队在稳固运行一段时间后就要开始考虑人员更替的问题。保持适度的人员更替率是一个团队健康的体现。不仅对于个人还是对于团队而言都是好的。

在人员更替的过程中，知识传递和能力培养是必不可少的。

一个新人上项目，不管什么角色，BA都要给他们讲解行业背景，业务知识，当前产品的功能板块，未来产品的走向等等。假如新加入的是一个BA，项目上的老BA还需要承担起Buddy的职责，负责BA的能力成长。除了日常项目上的事情，可能还需要计划少量针对性的讲授和练习，利用工作之余展开session。而作为新BA，也要投入巨大的精力快速理解业务上下文，在面临日常项目上的挑战之外，还得抽时间给自己充电。

一个交付压力比较大的项目，往往会疏于人员培养，平时项目上的事都忙不过来哪还有时间去带新人呀。这样的局面往往造成老人们越来越忙，承担越来越多的上下文，变得越来越重要，也越来越不可替换。最终老人们抱怨在项目上做的太久却下不了项目，新人们抱怨没有人带自己，帮不上忙。所以，带新人是一个一劳永逸的事情，每个项目上的BA都应该做好带新人的准备。

项目管理

BA最后的一块工作就是项目管理。ThoughtWorks是敏捷的倡导者，所有的团队也都是敏捷团队，它们是自组织跨职能的。所以，有很多团队并没有项目经理这样的角色。项目经理的职责被分散到整个团队身上，由整个团队共同承担。

而BA因为本身工作职责的起因，具备更大的视野，离用户更近，天然地具备承担项目管理的优势。所以，也应更加义不容辞的承担起部分项目管理的职责。

需求变更的解决，迭代计划的指定，用户关系的管理，还有组织日常大大小小的会都可以BA来做。

BA也会扮演起敏捷管理教练的角色，对于敏捷实践进行裁剪找到最适合这个项目的实践。引导团队成员如何正确的站会、IPM、DeskCheck、Retro。及时指出团队日常实践中的问题，慢慢的形成团队自己的敏捷文化。

BA的工作因项目的不同而略有不同

以上大约是BA在产品Delivery阶段的工作内容全景。

以我上一个项目为例，BA工作的各个部分精力分配大约如下：

image

不要担心，并不是在所有的项目中BA都要做这么多的事情。每个项目由于所处阶段，用户合作方式，团队组成方式的不同，BA的工作侧重点也不同。

比方，对于离岸交付类型的项目，用户和交付团队分处两地。这样在需求和方案对齐方面花费的精力就会更多。反之，对于在岸项目，交付团队在用户现场工作，那么这部分的工作就相对少少量。

对于Time & Material，也就是按人天收费的项目。因为项目风险主要落在甲方，所以为了减少风险，用户往往会把需求把控的比较严格，攥在自己手里，给予我们BA的分析空间不大。因而，这种项目的需求发现和收集部分的工作就会比较少，主要精力在需求分析和方案落地方面。因为一般这种项目乙方不会配备专门的项目经理，所以BA也会兼职来做项目管理的事情。而对于Fix Bid，也就是一口价收费的项目，项目风险落在乙方。所以我们会配备自己的项目经理，并且对需求和产品的把控度更大。这样，需求发现和收集部分的工作就会很多，而项目管理的事情也可以有项目经理承担起来。

还有对于比方3-4个月的短期项目，没有换人的需要，BA自然也就没有带新人的工作了。而对于某些超过一年的长期项目，BA就需要花一部分精力在带新人上。

写在最后

在ThoughtWorks与其说BA是一个职位，不如说是一系列职责的集合。在这里，没人会清晰的告诉你肯定要做什么，或者者不能做什么。

对于一个敏捷团队，与众不同的一点在于，BA要做的工作不是写在Job Description上的，而是需要自己去定义的。所以刚上项目的新BA可能会感到些许迷茫，不知道自己该做什么，不知道自己与其余角色的分工是怎样样的，不知道该如何与其余人合作。我常常会告诉新人，上项目后的第一件事就是找出自己在这个团队中的定位，明白自己能够或者者应该提供什么样的价值。同样是BA，每一个项目中的定位都会与以往不同，相应的工作内容也不尽相同。

怎样去找定位呢？不妨和项目里的BA，PM或者者TL聊一聊：

1. 说说你对这个项目的期望，你希望从这个项目中取得什么？得到哪方面的成长？希望这个项目提供给你哪方面的机会？
2. 让PM、TL、BA说说团队对你的期望是什么？希望你承担什么样的职责，做出什么样的贡献。

两边对齐的期望即是BA的定位。

其实，BA的工作没有说明书，也不必照本宣科地工作。可以做的事情可能非常的多，但应找准重点并适当地分配自己的精力，以免陷入忙碌的当下，迷失了方向。

名词解释：

BA：业务分析师

UX：客户体验设计师

Dev：程序员

User Story： 客户故事，敏捷中用以表述一小块产品特性和客户价值的载体。

IPM：迭代计划会议，在每个迭代开始之前举行的团队会议，用来澄清下个迭代的开发任务和规划下个迭代的工作范围。

Story Kick-off: 客户故事卡“开卡”，在进行每个客户故事的开发之前，由BA、DEV、UX、QA等相关人员一起参加的活动，以便澄清将要开发的需求内容和范围。

Story Desk Check: 客户故事卡快速验收，在客户故事开发完成之后，由BA、DEV、UX、QA等相关人员一起参加的活动，以便快速验证开发的功能能否符合需求。

Showcase: 产品展现会议，在一个开发迭代完成之后，对该迭代的产品功能进行展现。

Retro: 回顾会议，在一个迭代完成之后，对该迭代中团队的各个方面进行回顾，提出建议以便持续改进。

文/ThoughtWorks汪泽远

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见

上一篇 目录 已是最后