背景

在Scrum中，Sprint计划会议（简称计划会议）作为一个Sprint的开始，产品负责人（简称PO）要和开发团队一起确立本次Sprint的目标，否则开发团队可能就不知道做什么，进而无法开展Sprint中的活动。

那么如果产品负责人没有参加计划议会应该怎么办呢？

为避免造成歧义，在分析之前需要澄清一下的是，文中所说的产品负责人，主要是指自主研发项目中PO或者非自主研发下的代理PO（非客户人员）。在Scrum指南中虽然没有明确指出产品负责人到应该是谁（客户or供应商），但业界比较认同的是产品负责人是“客户的代表”这种说法，即你公司自己的人作为产品负责人，由于篇幅有限不再赘述。

问题分析

随着国内越来越多的企业开始使用Scrum做为敏捷转型的方法，对于这样的企业来说，可能会对Scrum中产品负责人的职责存在一定程度上的认识偏差。无论是从Scrum指南上来看，还是从其他参考资料（如《Scrum 精髓》）中，原则上是要求产品负责人参加计划会议且准时的。可随着项目的发展壮大，需求分析、干系人数量以及复杂度等都会随之增长，这也就导致了产品负责人的工作量呈几何式的增长。产品负责人没有参加计划会议可能不仅仅是主观认知上的原因也会被一些客观因素所影响。

所以一般来说，导致产品负责人没有参加计划会议的主要原因有：

1. 产品负责人没有明确其职责：主要体现在产品负责人没能清楚或没有重视其在计划会议中的职责而没有参加。

2. 计划会议的召开没有固定性：主要表现在计划会议的召开的时间不固定，存在一定可能上和产品负责人工作计划相冲突而没有参加。

3. 计划会议的效率低、时间长：主要表现在产品负责人的工作量多而复杂的情况下，计划会议开的时间长、效率低，导致产品负责人主观抗拒不愿参加。

4. 没有做好应对突发状况的工作：主要体现在产品负责人因市场变化、客户的要求等外界不确定性所影响等不能参加计划会议。

综上，接下来将会分别对上述分析的4个方面给出解决措施。

解决措施

产品负责人没有明确其职责

Scrum Master，在日常的工作中要做好“政委”工作，将Scrum的思想渗透给Scrum团队中的每一个人。其中，就产品负责人而言，要让他清楚的了解，作为产品负责人在Scrum框架中的作用和职责以及事件参与的重要程度等。对于计划会议来说，原则上是要求产品负责人参加计划会议且准时的，因为产品负责人需要和团队一起确立Sprint目标和范围，否则可能会导致Sprint的无目标或偏离目标而没有达到预期的效果。

计划会议的召开没有固定性

“没有规矩不成方圆”，首先要立规矩（计划）。如，在一个正准备敏捷转型的团队，在其启动会上（或其他践行敏捷之前的活动），就要先立规矩。其中就应包含Sprint的周期，以及什么时间哪些人需要参加哪些Scrum事件等。当然已经运行了一段时间的敏捷团队，也可以重新立规矩，如果没有（需要）的话。对于计划会议而言，需要固定好每一个迭代什么时间开，开多长时间，以及参加的人员。

在日常的工作中，Scrum Master要做好“保姆”的工作，可以在即将要开会前“吼”一嗓子。但我们建议是以会议提醒邮件的方式，目前主流的邮件管理系统（outlook、foxmail），都可以做到“重复周期”的设置，简单又方便的提醒到Scrum团队中的成员。

上述两点，其实说白了，就是要在思想和流程上先僵化，要让每个人（Scrum 团队）都知道在什么时间就做什么事情，保持团队节奏，避免出现团队中的任何人，在开会的时间还不知道要开会的情况。

没有做好应对突发状况的工作

如果产品负责人，遇到突发情况无法参会时，比如需要在客户现场处理相关问题。这就需要产品负责人能确保，产品代办列表中的用户故事的数量，能应对开发团队未来1到2个Sprint的工作（含优先级）。除了数量以外，还要对用户故事的质量有所要求，所谓的质量，不仅要有清晰的描述，还需要有验收标准（AC）。这样就可以很大程度上为产品负责人缺席提供了可能，因为哪怕产品负责人不在，开发团队也知道该做什么，如何去做。当然，这里所提到的是产品负责人分身乏术的问题，如果产品负责人只是在异地，时间上是OK的，那么就需要团队要能具有视频开会的能力和工具，那就必须要求团队提前准备了。

此外，还应该提升开发团队的能力，就如Scrum指南所指出的，开发团队也可以完成产品负责人管理产品代办列表的工作。这就需要开发团队具备自组织的能力（关于自组织能力的建设，请留意之后我们专家团队的FAQ），在我们华为云DevCloud内部，其实也一直贯彻着，人人都是产品经理的理念，做到团队中的每一个人都可以成为产品负责人的backup。

还有一点需要特别注意的，也是比较容易忽略的——产品负责人也是人。产品负责人也会有接孩子、开家长会、度假等工作以外的事情。这也就是传说中的“周末事件”，所以在对Scrum事件的时间安排上，应避免在一周的结束和开始进行（星期一、星期五），以降低关键事件被日常生活中断的概率。所以很多团队会选择星期二、三作为Sprint的开始。如果存在“周末事件”的影响（发生频率较多），那么这也就对应了一开始提到的，如果有需要就重新“立规矩”。

最后还需要考虑到极端情况，就是计划会议产品经理必须参加，这往往是由未来工作调整上的突发性引起的，或其他重要价值的事项。对于这种情况，就可能不得不把会议推迟到产品负责人时间OK的时候了。如果只是延迟了几个小时，那么其实影响并不大，在当天晚些时间开会即可，而且其他会议也不受影响。可如果会议推迟较多，那么很可能就是工作规划上发生巨大变动，这就要视情况而定做调整，甚至取消该Sprint。

计划会议的效率低、时间长

一般来说，计划会议可能会持续开4到8个小时。这对于产品经理来说，无疑是加重了其工作负担，所在一定程度上是不愿意接受这么长时间的会议的，那么就需要在会议上能提升效率。

我们在实际开计划会议的时候，通常将计划会议分为上下半场。大致（不同团队可能有所不同）如下：

这里可以清晰的看到，一个计划会议被分为产品负责人和团队一起参加的，以及开发团队自己参加的两个“会议”。所以实际上产品负责人不用参与完整的计划会议，这就给产品负责人在会议上节省了时间。在这一过程中Scrum Master要能掌控好，避免产品负责人参与到了细节和技术实现上的讨论中。

这里还需要提到的是，计划会议的一个重要输入项，一个有优先级并且合适颗粒度大小用户故事的待办工作列表，而且其中需求细节已经在梳理会上就被开发团队所知晓了。这也要求了产品负责任人要重视用户故事的质量，这实际上也是在帮助自己减轻沟通上的负担，提升效率。更多关于用户故事的编写请参考《“ 用户故事等于需求说明 ”—— 你一定没有写好用户故事》 。

对于只参加半场会议的产品负责人，如果整个流程上控制的好，那么其结果，就是可以提升产品负责人参加会议的可能性和意愿性的。当然，这个上下半场也不是完全绝对没问题的，如在下半场开发团队发现Sprint目标可能会有些变动，那么可以再和产品负责人做轻量级的对其和调整，一般问题不大。

总结

以上关于产品负责人没有参加计划会议的分析，是根据常见的情况所论述的，但肯定不仅于此，因为真正的实际情况永远是变幻莫测的，我们需要一直围绕着敏捷的核心思想开展活动和处理解决问题，在践行的过程中，采取是“先僵化、后优化、再固化”的方针，不断完善和改进我们的流程和思想，进而提升效能和竞争力。

参考资料

《Scrum 指南》

《Scrum 精髓》