内容简介：不简单的周会与周报，这是你不知道的事
周会周报，看似众所周知，但当PMO把这一话题列入讨论候选列表时，居然获得了大部分项目经理的积极投票，看起来这里头似乎有不简单的疑问和困惑。
周会周报，看似众所周知，但当PMO把这一话题列入讨论候选列表时，居然获得了大部分项目经理的积极投票，看起来这里头似乎有不简单的疑问和困惑。
一、“关于周会”
先来说说周会，通过调查目前项目经理们所处的项目中，毫无例外地拥有各自的周会，但开法略有不同，主要分为三类：
1、“全体类”周会
全体类，就是项目全体人员共同参与，这根据项目大小不同又有差异。技术研发类项目，本身以研发人员为主体，周会以所有人员的状态和项目信息同步为主；也会有部分产品类项目，虽然角色和人数众多，但依然会有全体参与的周会，时间控制在半小时内，以产品和团队的动向同步为主。
2、“组长类”周会
组长类，这也是目前占比最高的周会形式，更多存在于产品类项目中。各组同步状态，同时了解产品最新情况以及讨论重要产品事宜。
3、“三方类”周会
三方类，主要是产品运营市场三方周会，也存在于产品类项目中。因为这三方是产品动向的主要来源，且日常沟通合作中需要协调配合的事项更多，所以也需要定期的讨论决策。
当然，这里没有包括各个职能团队自己的周会，那些主要属于团队管理性质。
二、那如何来开好这看似简单的周会？
首先，要想清楚为什么开周会。要同步状态汇总各团队信息？如果仅仅如此，每个团队罗列自己的事项，互发邮件是不是就行了？显然不够。
我们一定需要通过周会来面对面地感受到项目当前的整体状态、重要问题、接下去的目标以及调整，更需要借此来对项目当前重要问题有一致的认识，有小幅度的讨论，并形成下一步工作事项。
这里，有一些 开好周会的要点：
1、规模和时间控制
人数不超过10-15人，时长不超过1.5小时。更大的规模和更长的时长，一方面是资源的极大浪费，另外一方面会造成讨论无法有效展开。一个包括了20人的超过2小时的周会，是不可想象的效率低下。
2、要不要轮流汇报？
事无巨细的罗列，既乏味又无效。大部分项目整体情况可以通过项目经理事先的收集来直接做整体概述，对于部分方向性或者商务性小组，可以简单汇报主要工作和主要问题。一旦会议陷入了轮流发言的局面，你会发现非发言的与会者很快就会掏出手机开刷。
3、周会上应该讨论什么？
先说哪些不该来周会讨论：
- 急事不适合周会讨论，要第一时间当下拍板！
- 非跨团队的问题不适合周会讨论！
- 纯执行细节问题不适合周会讨论！
- 大方向决策问题不适合周会讨论！
- ……
这样我们就更容易得出结论： 跨团队的，涉及到整体计划性或者协同配合型的问题，或者中期改进型问题，适合放在周会上讨论。 项目经理一方面可以在实现收集整体状态的过程中识别到此类问题，另一方面也需在周会过程中随机应变发起对“火花”型问题点的快速讨论。这样的讨论，不需要在周会时明确所有的细节，但大家有个共识并有个行动落实方向和对应负责人即可。
4、状态同步的维度
大部分情况下，不需要完全按照职能团队来同步，目的不是汇报贡献，而应该按照产品内子项目线的维度来跟进进展，挖掘问题。当然，整体研发情况是一个必有的维度。
5、说话比例
如果一个周会从头到尾是项目经理或者主管在唱独角戏，那就应该反省一下周会的形式和内容了。合适的比例是1:1:1。第一个1指的是会议主持人，往往是项目经理或主管，向大家更新整体状态，并且贯穿整个讨论；第二个1指的是部分需要汇报的与会者发言；第三个1更为重要，是所有与会者参与讨论发言。达到了这样的比例，容易让参会者从信息获取度、决策参与度和专注度上都保持较高的水平。
6、固定时间地点
周会的时间地点需要尽可能的固定，这样会让大家有预期性和节奏感，也能够提高到会率和准时率。为此，会议主持者需要付出不少努力，包括预定会议室、应对突发事件、完善会议规则和通知等。
7、如果我们已经有每日站会了呢？
这个问题更多来自于技术研发型项目，研发日常已经每日同步了，那自然不需要再依靠周会来同步状态。这种情况下，视项目变动情况、团队管理需求，可以将周会提升为主要针对项目概况和团队管理的会议，时间上也可以作进一步压缩。如无此需求，也可以省略周会，但建议保留月会或者双周会，主要用于项目整体情况和调整的事宜。
二、“关于周报”
很惊讶我居然写了那么多关于周会的事儿，原来真的不那么简单……通过统计，发现并不是每个项目经理都在写周报，有两类原因：一是项目本身复杂到项目经理没有能力描绘清楚整个项目各处的完整情况；二是周报约定于周会纪要了，因此省略。
衡量周报有效性的很好判断标准就是，有多少人真的会打开周报来看？又有多少人会认真看周报里的信息？
当然，要警惕周报万能论，不可能依靠周报来沟通具体的待办事项，谁干什么，还是要面对面沟通到位，周报上呈现的更多是让团队“透明”地了解信息，而不是带来任何surprise。
那么，写好周报又有些什么细节呢？
1、周报应该包括什么？
包括整体进展、整体风险、各子线状态、各子线风险。周报应该让大家清楚重要的进展，目标达成情况，风险状态以及应对，总之看完周报，大家应该对项目现状有个清晰的整体认知。
2、篇幅不宜过长
写到进展和问题，都只写要点，不要事无巨细都写，周报不是为了表现工作量，更不是为了刷存在感，只说重点就够了。
3、是否包含产品数据？
产品数据一定是敏感数据，并不适合实时向所有人公开，因此，并不需要在周报里列清数据。但既然现在团队都有KPI指标，那如果要形成最大的团队合力来达成目标，就必须要对KPI有分解有跟踪。所以，周报中可以有一定的数据信息，主要目的是由数据信息指出当前的产品问题和所需的调整事项。与此同时，要把控好周报的分发范围。
4、适当图形化
没有人愿意花十分钟以上来读一份周报，因此我们应该提高信息表达效率，适当将信息图形化，提高周报的阅读效率。
5、控制写周报的时间和复杂度
一份周报的准备时间应该控制在1-2小时以内。如果你的周会纪要本身和周报有了不小的重合，那也确实可以考虑两者合二为一。
三、结论
每每写完了一些细节，我们都需要抬起头来思考一下这些细节背后的意义。我们并不是为了“汇报”而来讨论周会和周报，恰恰是因为这两个环节是非常重要的“沟通平台”架设的部分，既可以给团队提供基本的“信息透明”，又可以有效推动重要问题的思考和讨论，让大家避免一头扎在细节工作中，而忘了抽身审视自己进而持续改进。
作者：曹智清，网易杭研项目管理部总监。曾经感受过IBM的专业严谨，领略过ASK搜索的起起伏伏，体会过创业中的酸甜苦辣。目前致力于在线教育行业的探索，同时关注项目管理在互联网产品全生命周期的应用，专注于敏捷精神的渗透和实践。《网易一千零一夜》主要作者之一。
本文由 @网易杭研项目管理（微信公众号：NetEasePM） 原创发布于人人都是产品经理。未经许可，禁止转载。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Professional JavaScript for Web Developers
Nicholas C. Zakas / Wrox / 2009-1-14 / USD 49.99
This eagerly anticipated update to the breakout book on JavaScript offers you an in-depth look at the numerous advances to the techniques and technology of the JavaScript language. You'll see why Java......一起来看看 《Professional JavaScript for Web Developers》 这本书的介绍吧!
