为何你的评审会没人来

发布时间:2022-12-05

以下文章来源于敏捷传习录 ,作者陈连生


评审会中业务方的反馈对我们至关重要,PO 可以根据业务方反馈及时对研发中的产品进行调整,从而做出真正满足业务方需求的产品。当然,如果团队有机会、能力邀请到产品的最终用户,那么效果会更好。

然而我们在日常工作中发现,很多团队在开评审会时遇到了不少的麻烦,其中最常见的就是“业务方不愿意来开评审会”。这里我们总结了一些常见的业务方不愿意开评审会的原因,并给出一些通用的解决原则。


01-业务方不理解评审会的作用


没有敏捷经验的业务方,会将评审会当作状态报告会,甚至会对团队让其“给予反馈意见”时大发雷霆,认为团队并没有认真吃透自己的需求,才会在这场会议中再次询问需求是否满足需求。这种观念一旦建立,业务方很容易认为这场会是一场“需求讨论”会议,甚至是一场“验收”会议,他们的配合是“帮助团队”,而不是走向双赢。

真正的评审会的目的是在于“给业务方演示已经完成的工作”,并让业务方就已完成的工作,给出反馈,团队根据反馈对产品待办事项列表 PBL 进行调整。反馈无论是正面的还是负面的,都是对已完成的工作进行评价,不涉及对团队的指责。而团队需要根据这些反馈并做出调整,从而做出客户真正需要的交付物,从而达到双赢的目的。

这种认知层面的差距,需要团队 Scrum Master 或者 Agile Coach 给业务方适当灌输敏捷基础知识来弥平,可以辅以一些沙盘演练的方式,让业务方深刻认知评审会以及“及时调整(Adaptation)”也会对自己带来好处(确保研发做出来的东西是自己要的),并愿意与研发团队配合,从而满足双方的利益。

02-研发进度不足,业务方没有兴趣参与

这个情况需要反思研发团队可交付内容的数量。有些时候,研发团队会因为故事拆分、价值流分析不到位,导致虽然根据优先级开发需求(或者用户故事),但需求的颗粒度较大,或者价值流梳理不够清晰,导致每个迭代开发完成的需求较少,导致业务方认为已完成的工作不具有评审的价值;或者出现多个迭代中无明显的进度产生,而后在某个迭代突然交付了一个巨大的功能,从而形成一种 Water-Scrum-Fall 的交付模式,让业务方产生”敏捷模式就是小瀑布“的错觉,从而内心不认同敏捷。

针对这种情况,团队需要加强自己对 MBI、MMF、MVP 等内容的构建,确保每个迭代交付的内容,对业务方来说真正做到可见可用,只有这样才能确保业务方每次来的时候有所收获,而不是将评审会当做例行公事而应付了事。

另一种情况是,如果发现团队用尽所有办法,但依然会因为迭代周期较短而无法完成“明显的进度”的话,可以在回顾会中由 SM 将问题引导出,让团队选择是否需要增加迭代长度,以及增加到几周。此处夹带点私货:我个人一向不建议 3 周作为迭代周期,原因是如果你需要与其他团队合作时,3 周的迭代如果要与2 周、4 周这种常见迭代长度的团队对齐时,极有可能变成一场灾难。如果跟你对齐的团队也使用了 3 周,如果你们迭代错开了,结果你懂的

Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1