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

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，做好跨系统的需求分析和管理；

image

image

image

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

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

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

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

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

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

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

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

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

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

image

image

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

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

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

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

image

image

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

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

---

文/ThoughtWorks 亢江妹

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