前言

项目经理的大部分工作时间，不是在管计划，而是在管沟通。写周报、发邮件、做汇报、开会——这些看似琐碎的事情，做好了能把项目的摩擦成本降到最低，做砸了则每天陷在无穷无尽的对齐和解释中。

一、周报：项目经理最重要的”产品”

周报不是为了交差，而是你的项目管理工具。一封好的周报能同时达到三个目的：沟通进度、暴露风险、推动决策。

周报结构（五段式）

1
2
3
4
5
1. 本周完成（做了什么，有交付物更好）
2. 下周计划（准备做什么）
3. 风险与问题（有什么阻碍，需要谁做什么决策）
4. 变更记录（本周新增/关闭了哪些变更）
5. 关键指标（进度%、预算消耗%、Bug 趋势）

写法要点

不要写流水账。与其写”本周开了 3 次会议，写了 5 个功能”，不如写”本周完成了订单模块开发，自测通过，周五已部署到测试环境”。

风险要说清楚影响和诉求，不是扔一句话就完了。”本周发现第三方推送服务不稳定，可能影响下周的性能测试。已和服务商沟通，预计周四有答复。如果周五前没解决，建议临时切换备用通道，需要王总帮忙拍板。”

结论前置。”进度正常”还是”有延期风险”放在最开头，不用让人读完 500 字才猜到结论。

周报发给谁，发什么版本

接收方 关注点 内容侧重
客户方对接人 有没有延期、什么时候能用、有没有额外费用 进度 + 风险 + 变更
客户方领导 有没有出问题、钱花到哪了 结论 + 关键指标
己方领导 干完了多少、回款了没、资源够不够 进度 + 风险 + 资源需求
己方团队 知道自己做了什么、别人做了什么、下周重点 进度 + 计划 + 风险（内部版）

给不同的人发不同的版本，不要群发同一封。

二、向领导汇报：20 分钟里说清楚项目怎么了

向领导汇报和写周报不同——周报可以慢慢看，汇报只有十几分钟，必须让领导当场听懂。

汇报结构（PREP 法）

1
2
3
4
5
6
7
8
9
Point（结论）: "这个项目目前整体正常，节点可控，有一个风险需要您帮忙决策"

Reason（原因）: "为什么正常？因为……（三个关键数据支撑）"
                 "风险是什么？第三方接口延期，可能影响下月底的里程碑"

Example（举例）: "上一个类似项目遇到同样问题时，我们通过……最终比预期提前
                 一周完成"

Point（重申）: "所以整体可控，只要下周前确认第三方的时间表，我就能重新排期"

几个关键场景的汇报话术

进度延期时：

不要只说”我们延了”，要说”延了多少、为什么延、已经做了什么补救、需要领导做什么”。

1
2
3
"订单模块延期了 5 天。原因是客户上周临时加了两个需求变更（附 CR-045/046）。
已补救措施：我们这周末安排了两个加班冲刺，预计实际影响压缩到 3 天。
需要您支持：下周和客户开会时，帮忙推动他们尽快确认剩余的变更，不要再追加了。"

需要加人时：

1
2
3
"目前进度比计划慢了大约一周。根本原因是两个开发同时兼了另一个项目的活。
如果从下周开始他们能全职回来，节点还是保得住。或者从隔壁组借一个人过来支持两周也行。
您看哪种方案比较好推动？"

三、邮件：三行法则

项目经理每天要写大量邮件。好的邮件让收件人 10 秒看懂、30 秒回复。

三行法则

  • 第一行：这封邮件要干什么（请求、通知还是确认）
  • 第二行：背景和关键信息（最多三句话）
  • 第三行：期望对方做什么、什么时候之前
1
2
3
4
5
6
7
8
主题: 【需确认】XX 项目数据库选型方案 - 请 3 月 15 日前回复

王总好，

两个数据库方案（MySQL 8.0 vs PostgreSQL 15）的对比见附件。
综合考虑你们后续的运维团队经验和适配成本，我们建议用 MySQL。

如果没问题，我们就按这个方案推进；如果有顾虑，明天下午我过来当面沟通也行。

不要这样写邮件

  • 标题写”咨询一个问题”——不知道什么邮件就不得不打开
  • 正文写十行没一句说清楚要对方做什么
  • 抄送一大堆人，收件人不知道该不该自己回
  • 用”尽快回复”，不给具体时间

发送前的自检：如果收件人正在开会，用手机看这封邮件，能不能在 30 秒内理解并做出反应？不能的话就再压缩。

四、会议：少开、短开、有结果地开

站会（每日 15 分钟）

  • 只讲三件事：昨天做了什么、今天准备做什么、有什么阻碍
  • 有人展开了细节 → “这个问题你俩会后单独对”
  • 站会的核心目的不是同步进度（看板就够了），而是暴露阻碍

例会（每周 45 分钟）

  • 铁打的议程：进度 → 风险 → 变更 → 决策 → 下周计划
  • 提前发会议纪要模板，谁更新什么内容会前就填好
  • 开会不是”大家一起看文档”，而是讨论文档里标记出来的争议点

决策会（有准备地开）

  • 一个决策会只解决一个问题。不要列 8 个议题，结果一个都没定下来
  • 提前把方案和选项发给决策人，不要等到会上才第一次展示
  • 会上不讨论新信息，只做决策。如果有人在会上抛出新的因素，延期决策，下次再定

会议的基本纪律

  • 没有议程不开会
  • 没有决策人不做决议
  • 没有会议纪要不散会
  • 超过 45 分钟的会，中间允许有人离开——说明会议时间安排有问题

五、IM 群管理

交付项目的微信群/钉钉群，既是沟通工具也是信息黑洞。

群的使用边界：

  • 公告、通知 → 群里发 + 邮件补（群消息太多容易漏）
  • 紧急问题 → 群里有记录，电话确认
  • 需求讨论 → 群里的讨论不算需求确认，必须落到邮件或文档
  • 闲聊 → 再建一个吃喝群，工作群只谈工作

群消息的处理方式：

每天处理 2-3 次群消息，每次集中回复，不要实时盯着群。真急的事情他们会打电话。

PM 的沟通能力，不是”说话好听”，而是把信息以最小损耗、传递到正确的人、得到正确的反馈。把周报、邮件、汇报这几件事练好，比你学一百个管理模型都管用。