前言
Preface
敏
捷文档系列文章已经写完三篇了，它们分别是：
普通项目文档和敏捷项目文档的区别
用户故事中“why”的两个常见错误
写好敏捷文档，让需求分析人员（BA）失业
然而不管文档写的怎么好，也避免不了读者有自己的理解。后期仍然需要辅以其他沟通形式，进一步澄清，统一理解。但当交付团队需要澄清需求的时候，需求分析人员却总是“太忙”，回复缓慢，开会也总是。
上一篇 “写好敏捷文档，让需求分析人员（BA）失业” 的文章里，我们用敏捷文档的设计优势“Fire”掉了大部分平庸的BA，剩下的少部分优秀的BA，和敏捷方法中的客户代言人---PO，构成了我们这篇文章里“需求分析人员”的主体。他们为什么总是不能参加团队的会议，不能立刻回复团队的疑问呢？
我
们先来看一下需求分析人员都在“忙”什么。
假设我们经历了客户访谈阶段，了解了客户需求的大致方向后，需求分析人员写好了200页的需求分析文档。发给交付团队后，交付团队说：
某功能描述太模糊。于是追加3页文档，花费3小时，跟团队确认新增加的部分，根据反馈调整，花费2小时。
分解的时候浮现出新的功能点。于是追加2页文档，花费2小时。
客户某要求对于软件来说不合理。于是结合团队的建议，修改方案，花费5小时，跟客户沟通方案，期间跟客户和团队两头讨价还价，并等待客户回复，花费三周。原文档花费的5小时作废。
实施到一半发现原方案存在重大技术难点，从克服周期和成本考量，建议更换方案。
于是重新修改方案，花费10小时，跟客户沟通方案，跟干系人说明情况，期间跟客户/干系人和团队多头讨价还价，并等待回复，花费一个月。原文档花费的10小时作废。
等等等等。
某天，客户说“我有一个新想法.....”
于是重新修改方案，花费10小时。跟客户沟通方案，跟团队重新沟通，听团队抱怨，团队拿到新需求后又浮现出新功能点，不合理处，技术难点，依赖性等等等等等，反复沟通，讨价还价，最终确认文档，又花费两个月。
由于需求变化，原来20%的需求不再需要，30%的相关需求发生变动，花在原来文档上的80小时作废。
你看，需求分析人员不忙的话，谁忙？
需求分析人员的工作量巨大，主要体现在以下几个方面：
--需求分析文档本身工作量就巨大。
--频繁修改带来新的工作量，并且导致以前投入的工作量价值缩水甚至作废。没错，需求人员的大部分工作，都是浪费掉的。
--由于项目Milestone的压力，需求分析人员撰写文档的时间有限，经常需要在详细度上做取舍。这种取舍会在接下来的交付阶段补回来：需求人员需要大量的参与沟通，并且团队常常在时间压力下按照不完善的文档冒险交付。
普通项目中，人们试图解决这类问题的时候，思路有两个。
一个思路是：合同谈判高于客户合作。
普通项目特别注重签订详细的合同，最好附有客户签字同意的解决方案，以及准确的时间/人力评估，以及变化管理条款。 这么有两个好处：
从道德（改动属于违约责任方）和流程（变化管理流程复杂且明确收费）两个角度提高了客户改动的的成本。
确保不管项目给客户带来的最终价值有多少，我们付出的劳动（包括被客户否定的部分），都能拿到相应的报酬。
另一个思路是：呼吁需求分析人员提高面向客户的沟通能力，从而减少沟通误解带来的改动。同时还呼吁需求分析人员提高技术水平，从而在设计解决方案时就将技术层面的复杂性，团队的局限性等因素纳入考量。而且你还经常能听到呼吁技术人员提高沟通能力。
很多人都说敏捷需要能力强的人才能玩的转，但是在我看来，普通项目对人们能力的要求才更高。
这些思路并不解决根本问题。问题的根本原因是普通项目采用了 “先文档，后沟通” 的需求传递方式----沟通会导致写好的文档发生改动，于是原来的文档工作价值缩水，同时增加了新的修改工作。
先按照需求分析人员的理解来写文档，然后通过反复的跟客户，团队两边沟通和修改，最终得出合适的项目需求文档，这个思路没啥问题，就是太浪费，不环保。
需求人员在普通项目中虽然不停的在忙，但只有20%～50%是被客户最终接受的。其余的“忙”，都是被客户否认掉的，在反复沟通，确认，重做中消耗掉的，并不包含在客户最终接受的“价值”里面（项目越复杂，浪费的越多）。
这部分浪费是必须的，它帮助需求分析人员和团队，甚至客户确认了“什么不是客户想要的”，最后剩下了客户想要的。 但这不意味着我们面对这种浪费可以心安理得。而且，控制它的规模，是我们提高项目资源利用率的关键。
在敏捷方法的十二原则中，第10条是这样写的：
简单--尽最大可能减少不必要工作的艺术，是敏捷的根本。
Simplicity--the art of maximizing the amount of work not done--is essential.
这些“不必要工作”，就包括我们前面提到的，在生产需求文档过程中“浪费”掉的部分。 那么敏捷到底是怎么减少这些工作的呢？
敏捷项目摒弃了“先文档，后沟通”的方式，采用“先沟通，后文档”的方式来避免提前做无用功。
让我们再次搬出敏捷文档的一个重要指导原则--3C原则：
首先在正式沟通前，敏捷并不是一点文档都没有。但是与普通项目的详尽的文档不同，在正式进行讨论之前，敏捷项目的文档以用户故事为主。
根据3C原则，“What”是一个框架性的描述，而“Card”原则限制了What的字数，让你在正式讨论之前只花很有限的时间在需求描述上，避免万一沟通之后发生改动，产生了更多的浪费。
细节的需求文档直到“讨论”发生之后才会产生。Backlog Refinement Meeting，Sprint planning meeting包括其他线下机会，都是需求分析人员和团队面对面讨论细节的时机。 讨论之后落实成Acceptance Criteria(详细的业务需求)和Definition of Done（技术任务）。这就是敏捷文档的“先沟通，后文档”方式。
“先沟通，后文档” 的好处就是，讨论的过程中，会对“需求是什么”，“哪个地方不详细”，“哪个地方逻辑有问题”，“哪个地方技术实施有困难”，“哪种方案更可行”这类问题先取得共识，然后才记录在册。
这样做当然无法完全避免后期的修改，但已经大幅减少了因为阅读理解偏差，以及需求人员缺乏技术背景等原因导致的文档沟通和修改。
同时，对于“业务人员懂技术”，”技术人员懂沟通“的需求也降低了不少。
错误案例
在实践的时候，我观察到两种常见的错误做法，一种是：
需求分析人员写AC，写完之后再与团队讨论解释。
另外一种是：
PO比较忙， 所以AC由团队来写，然后再拿给PO确认。
不管哪一种，都还是停留在“先文档，后沟通”的形式。这种形式下，前期花在文档上的精力越多，沟通后导致文档修改时，造成的浪费和其他影响就越大。
User Story+AC+DoD如果都先写完再进行讨论的话，跟普通项目的需求文档相比，前期工作量的投入几乎是一样的。沟通之后一旦发生修改，浪费的工作量和新增的工作量也不会减少太多。也无法利用“先沟通”来减少需求分析人员“知识片面”导致的文档缺陷。这是有违“把不必要的工作最大化”这门艺术的。
错误案例
我还观察到一个现象，有人抱怨这种先沟通的模式效率低，一方面会议多了，占用工作时间。另一方面，原来可以很快开始的工作，现在不得不先参加一堆讨论，遇上依赖性或模糊不清的地方，还要等待。
但这确实是敏捷的本意，通过面对面沟通这种更有效率的方式，先消除模糊，取得共识，再将共识落实到纸面上，保证你尽可能多做“正确的事”，而不是尽早开始但忙在错误的事情上。
很多员工（包括基层团队领导）未必介意做早错多。
一方面，面对面的，频繁的跟PO，以及某些Stakeholder沟通，超出了很多技术人员的舒适区。所以很多时候是“下意识”的，他们更倾向于躲在文档和邮件的后面，“先文档，后沟通”。
另一方面，大部分人不会因为“忙”但进展缓慢而被问责，因为在项目执行过程中， 责任被稀释在项目的依赖性，关联性和复杂性中， 个人对于自己“瞎忙”而产生的浪费感受不明显。 而且最不济，没有功劳还有苦劳嘛。 但如果看起来开了很多会，只做了一点小工作，就不太符合“勤劳努力”的样子。
想解决这两个问题，需要在组织的考核机制上作出相应的调整，同时配合教练和引导技术。“怎么做”不在我们这篇文章的讨论范围。
除 了用“先沟通，后文档”的方式来减少需求澄清过程中造成的损失外，敏捷文档的设计里面，还有另外一个进一步减少无用功的方法，它隐藏在Product backlog里面。
Product Backlog是一个按优先级排序的列表，并且任务的大小从上至下逐渐变大。
在Product Backlog中， 只有最上面未来1-2个迭代要做的用户故事，推荐分解到颗粒度较小（2-3天工完成或更小），写上AC，并且精确的排序。再远期才会做到的User Story并不推荐写AC, 不做过多的分解。更远的保持Epic 和大Feature状态，更少提前的投入分解，描述，和排序的工作量。（项目越复杂，预分析迭代越少，项目越简单，预分析迭代可以更多）
远期的任务意味着变化的可能性大，尤其是在敏捷方法中，因为每个Sprint结束后都会产出MVP，并跟PO做Showcase，在看到可工作的软件后，会加剧PO对“未开始”的工作进行调整的可能性。这种调整对项目是积极的，但如果人们已经花费了大量的工作在“未开始”的工作上，则会抗拒和反感这种调整----这就是在普通项目中发生的事情。
Product backlog这种设计，避免了他们一次性承担巨大的需求分析和文档撰写工作，并在接下来的时间里持续的反复的沟通，确认，修改。
需求分析人员每次只需要集中精力在未来一两个月的工作上。
并且在Backlog Refinment和Sprint Planning的时候，还有团队的参与，帮助需求分析人员在撰写文档（AC）之前就考虑到各方面的细节。
还有迭代机制，能够频繁的验证需求分析人员的话，是否被团队正确理解。
所以在敏捷项目里，需求分析人员的的责任看似很多，而且要求高，但事实是，这些工作既没有要求一个角色全做，也没要求一次性做完。如果上面提到的设计原理被很好的理解和执行了，在敏捷项目中，需求分析人员的工作不要太轻松，而且你有大把的时间省下来，跟团队畅所欲言的沟通。
错误案例
一个常见的应用错误， 是需求分析人员超前进行需求分析和文档构建。
项目越复杂，意味着信息理解和传递偏差越大，每一个迭代Showcase之后，对未来需求的调整就越大。所以对于具有一定复杂的项目，需求分析人员应该只关注当前迭代之后1-2个迭代可能会做的工作，将更多的精力放在这部分的分析，以及跟团队和干系人保持密切的沟通和确认上面。而不是花精力去分析未来更多迭代的文档。（确定性高的项目则不必完全遵循这种设计）
需求人员应该随着迭代的推进，让未来可能的变化充分释放出来之后，再投入更多精力工作在相对确定的需求上。这样才能变成“把不必要的工作最大话”的艺术家。
错误案例
另一个常见错误，就是把迭代变成了瀑布（Warter Fall）----虽然也遵循迭代，但是进行多个迭代后，才交付一次。
这种方式，对需求分析人员来说，最大的问题是不能通过实验性的方式将Backlog里不贡献价值的需求尽早移除。结果就是需求分析人员还会对这部分需求进行分析和文档化，最后跟客户交付的时候才能获知这部分工作是浪费的。
而且越迟交付可用的产品，就意味着在得到客户反馈之前投入的工作量越大。客户的反馈造成的需求改动，连带影响也越大，剩余的时间则更少，需求分析人员的压力可想而知。
这不都是“瞎忙”吗？
下篇预告
如果你的正确实施了本文提到的各种原理，你的BA和PO的每一份精力也都花在了该花的地方，但是他们仍然很忙，没有时间过多的参与到研发团队的活动中来，该怎么办？下篇文章会介绍另外一个招数---降低业务人员高度参与活动的成本。
喜欢这篇文章的你一定还喜欢
敏捷咨询师VS敏捷教练，雇哪个？
使用Scrum，多久才能看到效果
也谈Scrum Master的职业发展路径
Scrum到底该不该剪裁
Scrum流程团队已经很熟悉了，是否还要继续下去？
关于我
About Me
管婷婷
敏捷｜设计思维｜领导力
关注公众号阅读更多实践
