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