写好敏捷文档,让需求分析人员(BA)失业

用户故事中“Why”的两个常见错误
2019年5月30日
DevOps Master与凤凰项目沙盘(DoM, DoP, DoF)敏捷开发运维认证
2019年6月2日

前言

Preface


本篇文章是我的“敏捷文档系列文章”中的第三篇,前面的两篇文章中,我们分别聊了【普通文档和敏捷文档的差别】,以及【用户故事中“Why”的两个常见错误】,事实上如果前两篇文章中提到的要点,能够在项目中得到很好的贯彻,那么就能提高客户满意度,减少很大一部分返工和浪费。

今天我们要聊的内容,可以帮我们进一步减少浪费。想象一下如果你能Fire掉项目中的所有业务需求分析人员(Business Analytics,BA),那么你能为项目节省多少开支?抛开情感因素不谈,这绝对不是一个小数字。我们今天聊的角度,就是看敏捷文档中的一些设计原理,是如何既帮我们省下这笔人员开支,又能大大提高交付效率的。

敏捷文档如果维护好了, 即将失业的人群包括BA,或者一些名为PO,本质上是BA或者“PO助手”的那种人,这些人多见于复杂和大型的项目。

我们上一篇文章中提到过,普通项目文档遵循一个从Why 到 What 到How的过程 :

这个流程如果要工作良好,需要满足一个前提,即要把每一个环节都做正确,那么最终得到的结果才是正确的。

这种流程的设计是有多个致命问题的。其中一个就是将业务需求(Why)和技术实现(What)分为两个部分,然后由于二者直接沟通有困难,又设计了BA这个角色作为二者之间的桥梁:

BA从事的工作,主要是业务和技术之间的翻译官、解释器。 他们并不被要求去挖掘业务痛点和需求,系统思考全盘分析识别业务优先级,他们的主要职责是理解痛点和需求,并翻译解释成技术人员能理解的语言,帮助需求实现成为软件功能。

如果BA的“翻译工作”没有做好,那么就会出现需求频繁变更,沟通过程反复且进展缓慢,已交付的工作被推翻重做等众多问题。

所以,不管人们是否意识得到,其实整个项目能做到多成功,本质上是在看BA的能力有多强。这是一个风险特别高的设计,首先它过于依赖单个角色。其次能找到一个合格的“翻译官”,比我们想象的要难很多。我们可以看一下BA专业网站batimes.com发布的BA能力列表 :

BA能力列表(batimes.com转载)

1、沟通技能:

沟通包括演讲、倾听、书写、展示和记录等等。一个BA的日常工作,不是在捕获信息、分析信息、传播信息,就是在加工信息。你问的问题种类、你问问题的方式、你处理问题的方式,将会定义你在业务分析中的下一步动作。你听到的、你倾听和理解的方式,都形成了你工作的基础。

2、创造力、分析&解决问题的能力:

BA工作中的一半,是定义需求和提出对干系人有价值的建议,想要能够定义问题并且提出解决方案,他们应当有创造力、应当能分析在问题背景下众多的参与者和发挥作用的因素,并且提出具有创造性的解决方案。

3、人际关系技巧:

作为业务干系人和技术团队之间的翻译官,BA除了做到准确传达之外,还需要平衡双方的期待。所以BA需要很多人际关系技巧来使双方最终达成一致。

4、沟通技能:

沟通包括演讲、倾听、书写、展示和记录等等。一个BA的日常工作,不是在捕获信息、分析信息、传播信息,就是在加工信息。你问的问题种类、你问问题的方式、你处理问题的方式,将会定义你在业务分析中的下一步动作。你听到的、你倾听和理解的方式,都形成了你工作的基础。

多年的项目经验告诉我,在普通项目里面,要求BA具有以上能力绝不夸张,甚至是项目顺利进行的基本保障。

但是人才市场上能雇用到具有这种综合素质的人,只能是靠运气。大部分的公司和项目只能将就使用资质平庸的BA,然后挣扎在需求变更和推倒重做的泥淖里——-没错,很多时候需求变更未必是客户的错,客户的“痛点”或“希望获取的价值”在一个阶段内基本是稳定的。 更多的变更原因是“中间人”没有准确理解并传递。

那么敏捷项目是如何打破这种情况的呢?思路很简单,那就是–

普通项目在优化需求的时候也倡导群策群力,然而普通项目和敏捷项目中,为群策群力营造的环境截然不同。

首先,为了营造群群力的条件, 敏捷文档分解的时候,不是对需求进行分解,而是对客户的痛点&希望获取的价值,也就是说“Why”来进行分解:

关于Why的分解方法和常见错误,我们在前两篇文章中详细介绍过了,这里不再赘述。这样的设计,保证了即使在最低级别的需求文档上(用户故事),也能记录最原始的Why。这个Why是来自于客户的,未经BA再翻译的。

首先,这避免了我们从BA那里获取二手Why时被其个人的认知所误导和限制。

其次,用户故事中的Why对所有人可见,研发,测试,支持过程中的所有角色看到的Why是一样的。所以,当我们放开权限,让所有人参与进来讨论最佳需求文档—What时,能保证任何时候大家都是围绕同样的目标进行讨论,这样大大提高了讨论的效率。 而普通项目中,一旦BA不在场澄清的的时候,大家的讨论的时候都是基于自己对目标的理解,经常出现鸡同鸭讲的情况。

最后,根据3C原则,用户故事中的What是一句简单的,具有指导性和框架性的文字而非详细的需求文档(详见系列文章第一篇),需求的细节,是PO和团队,在Planning Meeting,Backlog Refinement Meeting等会议中,通过对话和讨论浮现出来的。3C的设计给群策群力制造了一个更大的可发挥的空间。

而普通项目的文档设计,需要BA设计的越清晰,详细,既能符合客户的要求,又能为团队所理解。这事做好并不容易,即使做好了,由于BA给出的需求文档往往已经非常具体,团队又缺乏Why的参考,即使倡导群策群力,但团队也只能停留在诸如“提交按钮怎么做才能更好看”这样的实施细节上,难以站在用户价值的角度思考和行动。

所以普通项目倡导的群策群力,实际上是被BA能力限制住的群策群力。而敏捷项目的群策群力,则是围绕用户价值的群策群力。后者显然更能发挥团队,干系人的思考和创造能力。

很多人都会质疑一件事,那就是–

使用群策群力来制定需求,是否真的比依赖BA要好?

我在第一篇文章中谈到用户故事的设计就是为了群策群力打基础时,收到了一条留言:

这个留言中提到的“不负责任”,是建立在一个前提上,那就是—团队没办法很好的 理解客户痛点,制定合理需求。

其实类似的提问,我收到过很多次。有些人可能觉得团队在跟客户对话,理解业务需求上先天能力不足,所以离不开BA的翻译。但是别忘了,敏捷文档已经将Why分解到很小的颗粒度(一个用户故事的工作量在1天-1周之内)。

如果你告诉IT交付团队,客户的目标是“Make my company great again!”,他们可能不知道该怎么做,但是你如果将它分解到“用户注册时收集有用的信息,以便将来我们能主动推送新产品,从而提升产品销量”这个级别,团队就能开始讨论为了提升产品销量,注册功能需要收集什么信息,注册功能是不是个有效的办法,还有没有其他更好的方法收集用户信息等等。

进而减少了对“中间人”–BA的依赖。

有了Why做参考,在群策群力制定需求的时候,还会遇到另一个问题,就是团队的参与度问题。

团队习惯了直接被告知“具体做什么功能”,并不习惯基于“Why”来讨论合适的需求的工作方式,所以一开始抱着怀疑和观望的态度,这很正常。另一方面,团队的Leader和BA,在转型初期也未必能提供适合群策群力的环境,例如讨论时能否秉持开放,兼容,说错做错时予以鼓励而非评判等等。尤其以结果为导向的思维占主导时,人们实际操作中对试错的包容度远远没有自己想像的那么高。

团队参与需求细节制定的积极性比较低的时候,领导人员可以参加一些专业引导课程和专业教练课程,就能找到很好的解决方案。

所以让团队参与制定需求细节,并非是一种不负责任的表现,相反是一种释放团队生产力的方法。如果实践的效果不好,则应该检视参考标的“Why”和领导力方向着手,而非单纯认为团队不够成熟,不能承担相应的责任。

另外,在敏捷项目中,迭代(Sprint)可以帮助验证和调整需求,进一步降低对“制定清晰的,准确的,细节的”需求列表的要求。即使团队制定需求细节的效果暂时不好,也能在Sprint Review中尽早得到纠正。并且因为迭代时间短,Sprint Review频繁发生,所以即使团队在需求定义上有错误,也会很快得到纠正,不会错太远。所以将需求细节交给团队,实践起来风险远远比想象的小很多。

不过假如你有幸雇到了一个非常好的BA, 他具有我们前面列举的所有能力,那么使用群策群力的方式制定需求,在效果上和效率上未必就优于依赖BA。 但如果对照那个能力列表,来评估一下我们周围常见的BA,我相信群策群力的效果会超过他们中的大部分人。而且,即使优秀的BA,也仍然需要团队帮助其完善需求。

现在,我们掌握了省掉BA这个角色的秘诀。不过有人会质疑这样能给项目整体带来多大的节省,因为即使省掉了BA,但是敏捷引入了一个新的角色—PO,而且PO似乎也是要求挺高的一个职业。普通项目雇用好的BA困难,但是敏捷项目雇用好的PO也很困难,所以本质上并没有真“省”下什么。

这里我要揭示一个惊天的秘密,其实

敏捷项目对PO的要求,比普通项目对BA的要求要低很多。

因为BA为了做好业务和技术的“翻译官”角色,需要又懂业务,又懂技术,还要擅长文档书写,而且这些技能越强越好。

敏捷项目中,PO在面对业务方时需要的技能与对优秀的BA要求是差不多的。但面对技术团队时,PO则不需要像BA那么强的沟通能力。一方面受益于我们前文所说的用户故事的“Why”+3C的设计,另一方面,PO还可以在迭代机制的帮助下,不断的验证和调整需求,纠正自己对产品的理解。

这件事切换到成本角度来看,那就是普通项目中需要雇佣一个高薪的优秀BA才能做的事,在敏捷项目中只需要雇佣一个普通的PO就能做到。

如果你身在敏捷项目之中,但是感觉还是非常依赖项目中资质平平的BA,那么你可能踩了下面这些坑:

Why没写对有两种情况,一种是写成了What,一种是写了自以为是的Why,并没得到客户的确认,具体的例子读者们可以翻一下前文。

第一种情况里,用户故事本质上是已经写好的详细的需求文档,跟普通项目中的需求文档并无区别, 团队的思考和贡献空间有限。第二种情况里,没有得到用户确认的“why”,随时都有可能被推翻,基于这样的Why,不管你用传统项目管理还是敏捷方法,最后都有可能白费精力。

前面的段落里,我们提到了团队并不积极主动参与需求制定的情况。也提到了引导技术是解决问题的方法。事实上Scrum Master的四大基础技能之一便是团队引导术。在引导技术的持续帮助之下,团队才能实现赋能,积极参与到需求细节的制定过程中来。

敏捷并不是改一下职位Title,改一下工作流程,就会自然会发生的事。

最后,有一类BA,不管团队敏捷成熟度达到什么程度,也是不会被Fire掉的。下图为你展示了处于不同能力层级的BA:

能力在蓝色区域的BA,给项目带来的效率是无法取代的。而且他们不光可以做好BA,在很多其他的职位上也具有竞争力,例如PO,干系人,项目经理,管理人员等等。

能力在红色区域的BA,可以很容易的转型为优秀的PO,并且在迭代机制和团队的辅助下,更能发挥他们的业务专长,给客户带来更大的价值。

能力在绿色区域的BA,就是我们常见的,能力平庸的BA。前面几篇文章提到的精髓您掌握了,雇佣这种BA的钱您就可以省下来了。

能力在黑色区域的BA,即使在普通项目中,也是没有更好的选择时不得不做选择。

如果这片文章的精髓您都实践了,大概能干掉项目里90%的BA。 剩下10%的BA和PO, 他们最大的问题,可能就剩忙!忙!忙!遇到问题的时候很难抓到人。

评论关闭了。