写好敏捷文档，让需求分析人员（BA）失业
用户故事中“Why”的两个常见错误
2019年5月30日
DevOps Master与凤凰项目沙盘(DoM, DoP, DoF)敏捷开发运维认证
2019年6月2日前言
Preface
敏捷文档如果维护好了， 即将失业的人群包括BA，或者一些名为PO，本质上是BA或者“PO助手”的那种人，这些人多见于复杂和大型的项目。
我们上一篇文章中提到过，普通项目文档遵循一个从Why 到 What 到How的过程 ：
这种流程的设计是有多个致命问题的。其中一个就是将业务需求（Why）和技术实现（What）分为两个部分，然后由于二者直接沟通有困难，又设计了BA这个角色作为二者之间的桥梁：
BA从事的工作，主要是业务和技术之间的翻译官、解释器。 他们并不被要求去挖掘业务痛点和需求，系统思考全盘分析识别业务优先级，他们的主要职责是理解痛点和需求，并翻译解释成技术人员能理解的语言，帮助需求实现成为软件功能。
如果BA的“翻译工作”没有做好，那么就会出现需求频繁变更，沟通过程反复且进展缓慢，已交付的工作被推翻重做等众多问题。
所以，不管人们是否意识得到，其实整个项目能做到多成功，本质上是在看BA的能力有多强。这是一个风险特别高的设计，首先它过于依赖单个角色。其次能找到一个合格的“翻译官”，比我们想象的要难很多。我们可以看一下BA专业网站batimes.com发布的BA能力列表 ：
1、沟通技能：
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的翻译。但是别忘了，敏捷文档已经将Why分解到很小的颗粒度（一个用户故事的工作量在1天-1周之内）。
如果你告诉IT交付团队，客户的目标是“Make my company great again！”，他们可能不知道该怎么做，但是你如果将它分解到“用户注册时收集有用的信息，以便将来我们能主动推送新产品，从而提升产品销量”这个级别，团队就能开始讨论为了提升产品销量，注册功能需要收集什么信息，注册功能是不是个有效的办法，还有没有其他更好的方法收集用户信息等等。
有了Why做参考，在群策群力制定需求的时候，还会遇到另一个问题，就是团队的参与度问题。
团队习惯了直接被告知“具体做什么功能”，并不习惯基于“Why”来讨论合适的需求的工作方式，所以一开始抱着怀疑和观望的态度，这很正常。另一方面，团队的Leader和BA，在转型初期也未必能提供适合群策群力的环境，例如讨论时能否秉持开放，兼容，说错做错时予以鼓励而非评判等等。尤其以结果为导向的思维占主导时，人们实际操作中对试错的包容度远远没有自己想像的那么高。
团队参与需求细节制定的积极性比较低的时候，领导人员可以参加一些专业引导课程和专业教练课程，就能找到很好的解决方案。
所以让团队参与制定需求细节，并非是一种不负责任的表现，相反是一种释放团队生产力的方法。如果实践的效果不好，则应该检视参考标的“Why”和领导力方向着手，而非单纯认为团队不够成熟，不能承担相应的责任。
另外，在敏捷项目中，迭代（Sprint）可以帮助验证和调整需求，进一步降低对“制定清晰的，准确的，细节的”需求列表的要求。即使团队制定需求细节的效果暂时不好，也能在Sprint Review中尽早得到纠正。并且因为迭代时间短，Sprint Review频繁发生，所以即使团队在需求定义上有错误，也会很快得到纠正，不会错太远。所以将需求细节交给团队，实践起来风险远远比想象的小很多。
不过假如你有幸雇到了一个非常好的BA, 他具有我们前面列举的所有能力，那么使用群策群力的方式制定需求，在效果上和效率上未必就优于依赖BA。 但如果对照那个能力列表，来评估一下我们周围常见的BA，我相信群策群力的效果会超过他们中的大部分人。而且，即使优秀的BA，也仍然需要团队帮助其完善需求。
现在，我们掌握了省掉BA这个角色的秘诀。不过有人会质疑这样能给项目整体带来多大的节省，因为即使省掉了BA，但是敏捷引入了一个新的角色—PO，而且PO似乎也是要求挺高的一个职业。普通项目雇用好的BA困难，但是敏捷项目雇用好的PO也很困难，所以本质上并没有真“省”下什么。
敏捷项目中，PO在面对业务方时需要的技能与对优秀的BA要求是差不多的。但面对技术团队时，PO则不需要像BA那么强的沟通能力。一方面受益于我们前文所说的用户故事的“Why”+3C的设计，另一方面，PO还可以在迭代机制的帮助下，不断的验证和调整需求，纠正自己对产品的理解。
这件事切换到成本角度来看，那就是普通项目中需要雇佣一个高薪的优秀BA才能做的事，在敏捷项目中只需要雇佣一个普通的PO就能做到。
如果你身在敏捷项目之中，但是感觉还是非常依赖项目中资质平平的BA，那么你可能踩了下面这些坑：
Why没写对有两种情况，一种是写成了What，一种是写了自以为是的Why，并没得到客户的确认，具体的例子读者们可以翻一下前文。
第一种情况里，用户故事本质上是已经写好的详细的需求文档，跟普通项目中的需求文档并无区别， 团队的思考和贡献空间有限。第二种情况里，没有得到用户确认的“why”，随时都有可能被推翻，基于这样的Why，不管你用传统项目管理还是敏捷方法，最后都有可能白费精力。
前面的段落里，我们提到了团队并不积极主动参与需求制定的情况。也提到了引导技术是解决问题的方法。事实上Scrum Master的四大基础技能之一便是团队引导术。在引导技术的持续帮助之下，团队才能实现赋能，积极参与到需求细节的制定过程中来。
敏捷并不是改一下职位Title，改一下工作流程，就会自然会发生的事。
最后，有一类BA，不管团队敏捷成熟度达到什么程度，也是不会被Fire掉的。下图为你展示了处于不同能力层级的BA：
能力在红色区域的BA，可以很容易的转型为优秀的PO，并且在迭代机制和团队的辅助下，更能发挥他们的业务专长，给客户带来更大的价值。
能力在绿色区域的BA，就是我们常见的，能力平庸的BA。前面几篇文章提到的精髓您掌握了，雇佣这种BA的钱您就可以省下来了。
能力在黑色区域的BA，即使在普通项目中，也是没有更好的选择时不得不做选择。
