内容简介：下篇预告
前言
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）失业》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
卓有成效的程序员
Neal Ford / 熊节 / 机械工业出版社 / 2009-3 / 45.00元
《卓有成效的程序员》就是讲述如何在开发软件的过程中变得更加高效。同时，《卓有成效的程序员》的讲述将会跨语言和操作系统：很多技巧的讲述都会伴随多种程序语言的例子，并且会跨越三种主要的操作系统，Windows（多个版本），Mac OS X以及 *-nix (Unix或者Linux)。 《卓有成效的程序员》讨论的是程序员个体的生产力，而不是团队的生产力问题，所以它不会涉及方法论（好吧，可能总会在......一起来看看 《卓有成效的程序员》 这本书的介绍吧!
