内容简介：下篇预告
前言
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！ ”，他们可能不知道该怎么做，但是你如果将它分解到“ 用户注册时收集有用的信息，以便将来我们能主动推送新产品， 从而提升产品销量 ”这个级别，团队就能开始讨论为了提升产品销量，注册功能需要收集什么信息，注册功能是不是个有效的办法，还有没有其他更好的方法收集用户信息等等。
对Why的分解降低了团理解用户价值的难度，以及参与改善需求的门槛。
进而减少了对“中间人”--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 没写对
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， 他们最大的问题，可能就剩 忙！忙！忙！ 遇到问题的时候很难抓到人。
接下来的敏捷文档系列文章，就会跟大家聊一下：
敏捷文档怎么写，才能让BA和PO不那么忙，大部分时间能端着咖啡坐在团队边上有问必答。
喜欢这篇文章的你一定还喜欢
关于我
About Me
管婷婷
敏捷｜设计思维｜领导力
关注公众号阅读更多实践
以上所述就是小编给大家介绍的《写好敏捷文档，让需求分析人员（BA）失业》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Masterminds of Programming
Federico Biancuzzi、Chromatic / O'Reilly Media / 2009-03-27 / USD 39.99
Description Masterminds of Programming features exclusive interviews with the creators of several historic and highly influential programming languages. Think along with Adin D. Falkoff (APL), Jame......一起来看看 《Masterminds of Programming》 这本书的介绍吧!
