评审会中业务方的反馈对我们至关重要，PO 可以根据业务方反馈及时对研发中的产品进行调整，从而做出真正满足业务方需求的产品。当然，如果团队有机会、能力邀请到产品的最终用户，那么效果会更好。然而我们在日常工作中发现，很多团队在开评审会时遇到了不少的麻烦，其中最常见的就是“业务方不愿意来开评审会”。这里我们总结了一些常见的业务方不愿意开评审会的原因，并给出一些通用的解决原则。
01
业务方不理解评审会的作用
没有敏捷经验的业务方，会将评审会当作状态报告会，甚至会对团队让其“给予反馈意见”时大发雷霆，认为团队并没有认真吃透自己的需求，才会在这场会议中再次询问需求是否满足需求。这种观念一旦建立，业务方很容易认为这场会是一场“需求讨论”会议，甚至是一场“验收”会议，他们的配合是“帮助团队”，而不是走向双赢。真正的评审会的目的是在于“给业务方演示已经完成的工作”，并让业务方就已完成的工作，给出反馈，团队根据反馈对产品待办事项列表 PBL 进行调整。反馈无论是正面的还是负面的，都是对已完成的工作进行评价，不涉及对团队的指责。而团队需要根据这些反馈并做出调整，从而做出客户真正需要的交付物，从而达到双赢的目的。这种认知层面的差距，需要团队 Scrum Master 或者 Agile Coach 给业务方适当灌输敏捷基础知识来弥平，可以辅以一些沙盘演练的方式，让业务方深刻认知评审会以及“及时调整(Adaptation)”也会对自己带来好处(确保研发做出来的东西是自己要的)，并愿意与研发团队配合，从而满足双方的利益。
02
研发进度不足，业务方没有兴趣参与
这个情况需要反思研发团队可交付内容的数量。有些时候，研发团队会因为故事拆分、价值流分析不到位，导致虽然根据优先级开发需求(或者用户故事)，但需求的颗粒度较大，或者价值流梳理不够清晰，导致每个迭代开发完成的需求较少，导致业务方认为已完成的工作不具有评审的价值；或者出现多个迭代中无明显的进度产生，而后在某个迭代突然交付了一个巨大的功能，从而形成一种 Water-Scrum-Fall 的交付模式，让业务方产生”敏捷模式就是小瀑布“的错觉，从而内心不认同敏捷。针对这种情况，团队需要加强自己对 MBI、MMF、MVP 等内容的构建，确保每个迭代交付的内容，对业务方来说真正做到可见可用，只有这样才能确保业务方每次来的时候有所收获，而不是将评审会当做例行公事而应付了事。另一种情况是，如果发现团队用尽所有办法，但依然会因为迭代周期较短而无法完成“明显的进度”的话，可以在回顾会中由 SM 将问题引导出，让团队选择是否需要增加迭代长度，以及增加到几周。此处夹带点私货：我个人一向不建议 3 周作为迭代周期，原因是如果你需要与其他团队合作时，3 周的迭代如果要与2 周、4 周这种常见迭代长度的团队对齐时，极有可能变成一场灾难。如果跟你对齐的团队也使用了 3 周，如果你们迭代错开了，结果你懂的😏
03
时间选择不对
理论上来说评审会需要放在迭代完成前的一天或者两天(我个人比较倾向于提前两天，这样我们在本迭代还能及时对业务方提出的反馈进行应对，给业务方一种“积极响应”的观感)。但是有些团队会过分迷信一个“固定的时间”，所以不论青红皂白的把时间固定在某个特定的时间，并拒绝调整评审会召开的时间。然而评审会中最重要的角色是业务方，所有的时间都需要顺着业务方的时间，甚至需要尽早的与业务方确定适当的时间。这看起来有点像之前项目经理 PM 的职责，而有些 SM 或者 PO 在没有干系人管理经验时会忽略此点，从而让业务方根本无法分身参与评审会，也就更谈不上给出恰当的反馈了。因此 SM 需要承担起这个职责，积极在团队内部与业务方之间找寻适当的时间，从而确保迭代内完成的工作得到了演示，同时业务方给予了充分的反馈。
04
邀请的业务方不对
通常情况下，单个团队会面临多个业务方，那么邀请哪些人就成了比较讲究的事情。如果不恰当地邀请业务方，很有可能造成各种问题，比如业务方不满意、评审会流程过长且混乱等问题。原则上我们只需邀请“本次迭代内有需求被完成”的业务方，其余的业务方只需要通过某种方式告知即可(推荐 Email)。但是有时候，根据上述原则选出来业务方依然比较多，此时我们就需要更加细致的处理，真正做到”来开会的都是有必要来的“。我的建议做法是，在评审会开始之前，给所有业务方发送本次评审会的议程，并对本次准备评审的需求进行简单的描述(包括需求来源、需求简述等帮助业务方理解的信息)。当业务方拿到这些内容的时候，就可以自行判断是否需要参加评审会，而不是由 PO 根据自己的理解来邀请。这在一定程度上也增加了业务方的“参与感”，最终选择来的业务方都会因为“我决定来参会”而积极配合。当然你要这么做的前提，是业务方真的认同评审会的重要性并真的愿意参与其中；如果不满足该前提，建议还是将上述发送的内容，亲自面对面给业务方说清楚，然后征求他们的意见。否则，请相信我，你会喜提“评审会参与业务方 0 人斩”的成就。
05
评审过程过分无聊
有些团队为了体现出自己工作的努力，在评审会上事无巨细的将所有工作都进行了展示，从需求开发到 Bug 修复、从更换图片到修改了错别字不一而足。这种情况下，无论哪个业务方都会感觉太无聊。我们做计划是根据优先级，评审会演示的时候也要掌握演示的优先级。对于业务方关注的需求，给予较多的演示，有必要的时候，甚至可以请业务方自己进行操作体验。而针对一些 Bug 修复、错别字修复之类的，只需要在演示的时候，一带而过即可。但请注意，本次迭代交付的所有内容，需要以适当的方式全部提供给业务方，确保业务方有据可查。还有一种让评审会变得无聊的操作，是将评审会拉得过长。虽然 Scrum Guide 中建议评审会的长度为 1 小时/周，但是实践中我们发现有些PO、SM 会在评审会时不去，或者无法控制会议时长，导致会议中的讨论时间过长，非相关人员自然会对此感觉无聊。应对这种情况的最好办法是，SM 需要掌握较为扎实的引导、控场技术，让评审会始终围绕在“反馈”而非“讨论”(当然，适当的讨论是需要的，但是过长的讨论需要规避，除非是当前讨论涉及到在场的大多数人，否则需要极力避免)。尤其是针对反馈的解决方案，千万不要在评审会中进行讨论，而是应该在记录下业务方反馈点后，交由 PO 根据需要，选择适当的时间与业务方沟通。另一种比较讨巧的做法是，在演示的时候，对每个需要演示的需求，不要全部演示完成，而是演示70%-85%左右即可，关注大流程而不是所有细节。如果业务方真的感兴趣，他们会主动问你剩下的没有演示的细节内容，否则这部分未演示的内容也能较为明显地缩短评审会的时长。
06
业务方反馈没有得到适当的回应
好的评审会应该是双向且有追踪的——既不能是团队演示结束就行了，也不能是业务方单方面提出反馈、团队记录就行了。试想如果你是业务方，你在评审会上只能单方面听从研发团队说，自己却无法表达的自己的观点，你是否还愿意参加下一次评审会？更有甚者，你表达了你的反馈，但是团队不给你任何正面反馈，你既不知道自己的反馈有没有被听进去，也不知道自己提的反馈是否能够得到解决、什么时候能够得到解决，下次你是否会继续参加评审会？因此我们需要在保证评审会“演示”的工作之外，还需要针对“反馈”给予恰当的响应，从而让业务方感受到自己的参与感，让其感觉自己的需求得到了满足，或者自己的建议让产品变得更好。这都是让业务方感受到自己价值的重要步骤，毕竟业务方投入的时间，也需要考虑性价比。
总结
我相信业务方不愿意参加评审会的原因五花八门，上述几个原因必然无法覆盖所有内容。如果您还有什么其他原因和解决方案，也欢迎留言告诉我们。
作者：陈连生
