有了产品负责人,还需要业务分析师吗?

PO(Product Owner,产品负责人,以下简称PO)作为敏捷转型的实践之一,当前已被业界广为接纳。根据年度敏捷状态报告,大约有一半以上实施敏捷的组织设置了PO,这与当前我们在国内敏捷咨询中感受到的比例相同。

我们已经很少会被问到“需不需要PO”的问题,但却经常被问到“有了PO,我们还需要设置BA(Business Analyst,业务分析师,以下简称BA)吗?如果需要设置BA,那么PO和BA之间该如何合作呢?”

回想我第一次对这个问题的答复,与今天的答复也不尽相同,这次尝试把我的思考总结一下,分享给大家。

“有了PO,还需要BA么?”

首先,得强调一个原则:HAT over ROLE。

“HAT”,顾名思义,同一个人是多顶帽子,可以在需要时临时灵活切换;“ROLE”则是一个职能角色,更像一个长期的、固定的身份标签。

在软件开发这样的强知识工作领域,无论是敏捷开发和精益软件开发的核心原则里,都强调了“混合技能”T-Shape, Poly-skilled)的重要性。软件开发的本质,就是合作创造(“Coorporative Game of Invention and Communication”),需要“Collective Ownerhip”。

过分强调ROLE,有两个危害:1)“一个和尚挑水喝,两个和尚没水喝”,过分强调角色分工导致主动性降低,大部分时候起不到1+1>2的效果;2)团队协调沟通成本变高,响应力降低。

如果确有团队需要的能力,比如“迭代经理(Iteration Manager,简称IM)”,会让团队的某个开发、测试、BA兼IM、或者让团队成员轮流兼任IM,像是临时戴上了“IM HAT”,而并非不是额外引入一个固定的IM ROLE。

如果在ThoughtWorks工作3年以上的人,大多数人在介绍自己的时候,都会提过自己兼做一串串不同HAT的经历。正是这样的“HAT over ROLE”,才让敏捷团队迸发出不一样的活力、创造力、凝聚力,像一个“斗志昂扬的战队”——我们不用担心某个伙伴突然请假,因为大家随时都准备着相互补位。

基于以上的原则,当面对“有了PO,还需要BA么?”这样的问题时,我们可能要去了解下问题的背景:

  1. “我们在业务侧设置了PO,但PO本身还兼有业务的任务,实在太忙了,平时讨论需求都很难,更别说细节的需求澄清了...... 这时我们是否应该有一个'BA'呢?”
  2. “我们这个产品现在已经相当复杂了,开发快20人了,PO现在不仅仅要管需求,还要负责产品规划、运营策略设计、对内对外的干系人沟通、合作伙伴的对接和协调等等,具体需求这些事情实在是管不过来了......这时是不是应该设置一个'BA'啊?”
  3. “我们的团队倒是不大,但是PO过去是业务背景的,技术上不怎么懂,只能做业务需求收集和澄清,业务需求往往是一句话丢过来,开发接到需求都是懵的,中间缺失了'需求翻译'的过程,怎么办?”
  4. “我们对接的是多个业务部门,每个业务部门都指定了一个业务代表做PO,但是需求基本上还是散的,尤其是不同业务部门实际上需求场景差异还挺大的,每个PO也都只代表他们的部门,到我们研发听谁的都不合适,优先级很难定、方案设计也很难做,怎么办?”
  5. “我们的开发团队是外包的,当我们给外包开发沟通了需求后,等做出来总是与我们预期的差异很大,是不是应该设置一个BA啊?”
  6. “我们当前负责的是一个大型改造升级项目,有涉及到多个系统的数据迁移和技术改造工作,并没有一个对口的业务部门负责,所以没有一个指定的PO,这时如果没有BA,项目好难开展啊!”

可能还有其他不同的情形;背景不同,答案可能是不同的,如果有好的补位方式,就不一定非要加角色来解决。如果把上面的问题一一分析来看:

  1. PO在业务侧,忙不过来——这时可能需要技术侧的一个伙伴戴上“BA HAT”,作为PO的代理协助完成PO的职责;
  2. 产品复杂、团队规模太大,PO需要管理更多的规划和运营管理工作,无暇顾及需求分析和管理——在“两个披萨饼大小的敏捷小团队”里,那么从Backlog管理、需求优先级到需求优先级排序、需求拆分、需求澄清、用户故事启动到验收等一系列的实践过程,确实可由PO一人完成;但当实际中产品团队规模变大以后,此时可能需要一个甚至多个BA,来完成需求分析和管理的工作;
  3. PO不能胜任“需求翻译”的工作——这种情形下,解决方式是长期上重视培养提升PO的需求分析能力,短期可以在技术侧有一个伙伴戴上“BA HAT”协助PO进行需求分析;
  4. 有多个业务PO,需求场景很复杂、方案设计很挑战——这时,可能需要一个专职的BA,作为一个Integrator,来统筹完成场景梳理、方案设计和需求拆解,做好需求平衡决策;
  5. 开发外包的,PO和开发团队之间的需求沟通之间出现了GAP——这时,建议在外包团队设置一个“BA”(可以是兼职),能作为PO的Proxy,对需求做及时的梳理、拆解和澄清;
  6. 大型改造升级项目,涉及多个系统,没有PO——这时,如场景4,也是建议设置一个专职的BA,做好跨系统的需求分析和管理;

“我们认可是否设立BA要具体情况具体分析;但在大规模组织里,如果都说让团队自己判断做决定,往往无法落地,怎么办?”

如果是小组织里,比较好办,团队确实可以灵活处理。但如果是大规模的组织,如果组织上缺少一个明确的指导,说让团队自己看情况办,的确可能就“凉拌”了。

规模化的组织,管理是一门艺术,如果规则过于严、过于分工明确,会失去主动性和创造力;如果完全灵活,可能会特别低效。

建议在较大型的组织里,给出一定的原则和指南:

一组简单清晰的原则,需要大家牢记并遵守,如:

  • “建立统一的需求Backlog”;
  • “每个需求的分析从问题场景开始”;
  • “每张需求卡片需要有清晰的验收标准”;
  • ...;

指南和实操建议,让各团队能“对号入座”的同时,又可结合团队的特殊性自主调整,比如以下情形建议团队设立一个BA,可先从团队中找一个了解业务、善于沟通的开发或者测试先兼职然后再视工作负荷需要成为‘专职BA’”:

  • 开发团队的规模超过了2个披萨饼大小;
  • 有多个业务PO或没有PO;
  • 业务场景复杂、方案设计非常挑战;
  • 有PO,但PO或负荷过重、或不具备需求分析能力等

“有了‘BA’,如何保证‘BA’能很好‘补位’呢?”

如果刚戴上“BA HAT”,如何清晰地知道需要做什么呢?其实无论是PO,还是BA,需求分析是核心基础之一。对于新的PO和BA,这里有我们总结的一份“工作基线”,大家可以根据自己组织、团队的情况做适当裁剪:

(表格1 敏捷团队BA参考工作基线)

如果组织中,之前没有成熟的老带新的BA机制,又有比较多的团队需要有人戴上“BA HAT”; 或者大量的PO其实也都比较新,并不知道怎样才算一个“胜任的PO”,建议组织进行针对性的赋能培养,帮助这些伙伴掌握基础实践,快速上手。

“如何判断谁更适合补位,戴上‘BA HAT’呢?”

当组织中有比较多的团队确实上述“需求能力”时,固然可以去外部招聘,但最能解“近渴”的,还是考虑从内部的开发、测试等具有相关技术背景的人来兼职补位。那么,如何来判断谁更适合补位,戴上“BA HAT”呢?下面是一个基础的能力模型及行为映射,可以来作为筛选BA/PO候选人的参考,也可以作为申胜任力判断的基准参考:

(表格2 初阶BA核心能力及行为映射)

此外,在招聘或内部选择合适的BA 潜在候选人时,也可以“看气质”(也就是基础胜任力),这里有一个“BA适应性问卷”,可以帮助组织能快速识别出一些高潜好种子。

Share

5 Comments

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据