敏捷团队怎么做，能让你的PO随叫随到--敏捷教练管婷婷

2019-07-22 本文已影响1人管婷婷Lisa

你能在这篇文章里找到这些问题的答案：

Product Owner 太忙不参加Sprint Planning meeting怎么办？

Sprint Planning meeting总超时怎么办？

Product Owner 跟团队在不同时区，如何让他更“Available to team”（能够被团队找到）？

敏捷开发相关书籍中指出，Product Owner 应该深度参与团队的工作。除了必须参加Sprint Planning meeting，Sprint Showcase meeting，并定期主持Backlog Refinement meeting之外，在整个迭代的过程中都要“Available to Team”（能够被团队找到）。

这样做自然是好的。这意味着团队可以随时找PO沟通需求细节，第一时间了解需求变化，尽早检查交付成果是否正确。与PO的沟通复杂程度和沟通成本降低，等待确认的时间减少，返工浪费减少，工作流更加顺畅，团队挫折感减少，效率提升，项目ROI提升等等等等等等。

但是在实际操作中，这几乎是不可能的事情。随着项目的规模增长，需求分析的工作量，干系人的数量及干系人关系的复杂度都会增长，导致PO的工作量呈几何形上升，PO对团队的“Availablity”越来越低。

Scrum方法之所以能流行，就是因为它在很多细节上的设计能够解决这个世纪难题。在我前面发布的几篇解构“敏捷文档怎么写”的文章里面：

“普通文档和敏捷文档的差别”以及“用户故事中‘why’的两个常见错误”中提到的敏捷方法设计细节，可以帮助PO和团队更容易的沟通彼此的想法，减少沟通的时间，降低沟通误解率。

“写好敏捷文档，让需求分析人员（BA）失业” 中提到的设计细节，能减少PO书写需求文档的工作量，让需求文档的描述更加准确。

“这么写敏捷文档，让BA/PO不再‘瞎’忙！”中提到的设计细节，则会通过实验性的方式尽早暴露一些对客户没有价值的需求，并移除他们，节省PO在需求沟通，分析，文档书写方面的精力。

如果上面这些细节在敏捷实施的过程中得到了很好的执行，那么PO的工作量能至少减少50%。这50%并不是提升PO效率而得来的，而是将工作流程和沟通方式中的浪费消除掉，从而节省出来的。我们把PO从这些不贡献价值的工作中解救出来，他自然就可以更有时间对团队“Available”。

很多团队在实施Scrum的时候，只注意到了宏观的流程及会议，并没有注意到Scrum对每个事件如何执行都设计有非常详尽的细节，每一个细节的背后，都对应要解决的IT项目团队中常见的问题。而这些细节在执行过程中的彰显，才是让Scrum真正发挥威力的关键所在。

除了做好上面这些事，来让PO“闲”一点，能够有更多的时间聚焦到配合团队上来之外，还有一个大招，是我在教练团队的时候经常鼓励他们使用的。这个大招就是---

对别人有所要求并且希望对方响应的时候，除了主动开口之外，还要降低别人响应你的成本。

当你要求别人做一件对他来讲很困难的事情，和要求他做一件对他来讲很简单的事情，哪一种更可能获得对方的响应呢？答案显然是后者。

在阅读Scrum Guide的时候, 你可能会发现，Sprint Planning 其实是分两个阶段的。第一个阶段参与人是团队和PO，主要完成这么几件事：

选择适当数量的User Story，确定Sprint的工作范围

PO与团队围绕被选择的User Story进行讨论，并确定每个Story的Aacceptance criteria。

第二个阶段是团队自己开，主要完成这么几件事：

确定用户故事的DoD

将Story分解成Task并录入系统或者set up物理看板。

团队成员初步认领一下任务

这两个阶段用时差不多，PO只需要参加第一个阶段。一个Sprint如果是2周，建议Sprint planning 不超过1小时，那么PO实际参与会议时间只需要30分钟。

对于一个非常繁忙的PO，如果你邀请他参加1个小时的会议（甚至还经常超时），那么他参与的可能性是会大大降低的。但是如果你只要求他bi-weekly的参与30分钟的会议，那么他准时出现的可能性则会大大提高。

我们把需要PO参与和贡献的部分集中在前30分钟（甚至更短）解决，从而减少他参与的时间成本，这就是一种“降低对方的响应成本”的设计。

这种降低别人响应成本的方法，不仅仅可以用在planning meeting上，也可以应用于其他任何的，你需要PO参与的会议上。甚至可以扩展到其他跟PO的合作活动上。所以读者们可以思考一个问题：

在你平时的工作中，你希望你团队的PO做哪些改变？你怎么帮助PO降低他做这些改变的成本？

错误案例

对于一个为期两周的迭代，如果你经常性的需要你的PO在planning meeting呆了超过30分钟，那么你可能犯了下面这些错误：

1：需求细节需要太多澄清。

一个为期两周的迭代，理论上不会包含太多的业务需求。但如果花了大量的讨论来澄清需求的细节，那往往是由于User Story的颗粒度太大（例如单个user story工期超过4天），并没有在Planning会议前进行适当的分解的缘故。

用户故事在分解的过程中，功能之间的关联性，隐藏的需求和风险等等都会暴露出来。如果没有提前进行适度的分解，那么这些问题都会暴露在Planning meeting 上，并需要立刻讨论，于是会议就会超时。对所有参加会议的人，包括PO，都是一个巨大的负担-----人们会感觉浪费了太多的时间在开会上。

Sprint planning会议的一个重要输入就是“健康”的User Story。“健康”的内容包括：

未来一到两个迭代可能会做到的User Story具备合适大小的颗粒度。

--“Why”部分的描述清晰准确。

--用户故事已经已经按照优先级进行排序。

准备健康的backlog是线下PO 和团队共同持续协作的事情。而不应该是在Planning meeting上解决。

2: PO过度参与了“如何做”的讨论

PO 应该更关注业务上的”做什么”。但很多企业中，敏捷转型前，PO是在内部担任偏“BA”或者“项目管理”的岗位上，习惯日常参与讨论技术和实施细节，甚至参与决定团队分工，敏捷转型后这种行为肯定是错误的。

PO如果过多参与技术细节讨论，那么就压缩了团队在技术实施上的主动空间，降低了群策群力的效果，还会让产品的优秀程度更受限于PO个人的历史经验，从长远来看不利于团队能力的成长。

另外PO的精力是有限的，我们希望他把有限的精力放在深入了解客户需求，构建产品愿景上，而不是focus在技术实施细节上。

避开了上面两个常见的问题，你就会拥有一个特别高效率的Planning Meeting，而且大家的参与度也会越来越高。

很多人其实喜欢特别长的Planning meeting，因为如果PO的availability低，那么好不容易抓到他一次，就应该拖着他把问题充分讨论出来。我们先不谈这种“充分讨论”是否也有“过度计划”的嫌疑。别忘了PO也是人，如果一个事情对他来讲负担太重，那么可持续性就降低，负担重到一定程度，你就会发现他经常说：太忙了没法参加，发邮件吧。

除了我们上面所说的问题，在许多外企中，交付团队和PO处于不同时区也非常影响PO对团队的“Availability”。

虽然现在已经有了很多远程协作的工具帮助二者提高合作效率，但是根据我的观察，如果双方所在时区相差超过6小时，双方的沟通就较难在当天获得回复，PO参加团队的会议难度也会更大。

这种情况下，PO的 “Availability低” 首先是一个不得不接受的客观现实。而团队与PO更依赖文字（文档，邮件）沟通和确认。那么我们开头几篇文章中提到的敏捷文档设计细节应该被更严格的遵守，从而提高文档沟通的效率。

另外一个可以尝试的方法是，尝试“采取更短的迭代周期”。随着沟通的成本被时差等综合因素推至一个相当高的程度，PO和团队都会更倾向于一次性计划更多的，更长周期的任务。这样做带来的潜在风险和瀑布开发的风险一样。

面对此种情形，团队应该在长周期内继续使用迭代，而且要选择更短的迭代周期（1周），一次交付更少的MVP。Sprint planning和其他的Scrum会议都由团队自己参与并主持， PO只需要在Showcase meeting中出现一下，根据MVP给出反馈即可，此时showcase meeting即取代了常见的weekly status check会议。这样PO的参会成本降到极低，但是团队仍然能尽早的获取有价值的反馈。