1、立项的结论,要"落纸"

第 2 课我们算清楚了"值不值得做"。但结论停在脑子里,等于没有结论——半年后没人记得当初为什么做、答应过什么、边界在哪,于是争议、返工、扯皮全来了。

所以立项之后第一件事,是把结论固化成两份东西:

  1. 项目章程(Project Charter):项目的"出生证明",写下被授权的目标、范围、边界和负责人。
  2. 干系人地图(Stakeholder Map):找出所有会被项目影响、或能影响项目的人,弄清谁在乎什么。

一句话:章程管"这件事是什么",干系人地图管"这件事牵扯到谁"。

2、项目章程是什么,不是什么

项目章程是发起人对项目的正式授权文件。它回答:

  • 这个项目为什么存在(目标/价值)
  • 项目负责人是谁、有多大权限
  • 范围边界是什么(做什么、明确不做什么)
  • 主要交付物和成功标准
  • 关键里程碑与预算/资源上限
  • 主要约束、假设与风险

它不是:

  • ❌ 详细的需求文档(那是第 7 课的事)
  • ❌ 详细的项目计划(那是第 5 课的事)
  • ❌ 写给领导看的走过场材料

它的真正用途是"对齐"和"授权":让所有关键角色在开工前,对"我们要去哪、边界在哪"达成同一份理解,并让项目经理有据可依地调动资源。

3、一页章程模板

继续沿用"一页纸"原则:

# 项目章程:<项目名>

## 1. 背景与目标
- 问题/机会:
- 项目目标(一句话):
- 成功标准(可衡量):

## 2. 范围
- 包含(In Scope):
- 不包含(Out of Scope):

## 3. 关键交付物
- 交付物 1:
- 交付物 2:

## 4. 里程碑
| 里程碑 | 目标日期 | 验收标准 |
|--------|----------|----------|
| M1 需求确认 | | |
| M2 原型可用 | | |
| M3 上线 | | |

## 5. 资源与预算
- 人力:
- 预算:
- 关键依赖:

## 6. 约束、假设与风险
- 约束(时间/成本/合规):
- 关键假设:
- 主要风险:

## 7. 授权
- 项目负责人:
- 发起人:
- 决策机制(谁拍板、多久一次):

填这张表时,有两个地方最容易糊弄、也最值钱:

  • "不包含(Out of Scope)" —— 明确写出"不做什么",是防范围蔓延最强的武器(第 4 课细讲)。
  • "关键假设" —— 每个假设都是未来的风险。假设"第三方接口随时可用",就得为它准备预案。

4、干系人:看不见的人,往往决定成败

干系人(Stakeholder) 是"能影响项目、或被项目影响"的所有人,不只是客户和用户。

典型清单:

干系人他们最在乎可能的阻力
发起人/老板收益、按期交付中途抽资源
最终用户好不好用、别添麻烦拒绝改变习惯
业务方流程是否被满足不断加需求
开发团队需求清晰、别老变消极执行
运维好不好部署、出事谁扛拒收"不可运维"的系统
财务/法务/合规成本、数据、License卡在最后一关
其它部门会不会抢资源/影响自己暗地阻挠

最危险的不是反对者,而是"你忘了问的人"。 他们通常会在项目快上线时突然出现,然后一票否决。

5、权力-利益方格:谁要怎么管

管理干系人的经典工具是权力(Power)- 利益(Interest)方格:

          利益 高                  利益 低
        ┌───────────────────┬───────────────────┐
权力 高 │  重点管理          │  保持满意          │
        │  (密切沟通、共创) │  (定期简报即可)   │
        ├───────────────────┼───────────────────┤
权力 低 │  保持知情          │  最小关注          │
        │  (及时同步进展)   │  (礼貌、别失礼)   │
        └───────────────────┴───────────────────┘
  • 权力高 + 利益高:核心玩家,必须密切参与、纳入决策。
  • 权力高 + 利益低:有权但不关心,重点是"别让他们意外",定期简报。
  • 权力低 + 利益高:很关心但没决策权,要及时同步、给他们参与感。
  • 权力低 + 利益低:最低成本维护,别冷落即可。
注意:权力和利益是会变的。项目进入合规审查阶段,法务的地位会突然上升。所以这张图要定期重画。

6、沟通计划:让每个干系人"在对的时候收到对的信息"

识别完干系人,就要回答:谁、什么信息、什么频率、什么形式、由谁负责发?

干系人关心什么频率形式负责人
发起人进度/风险/预算每两周一页简报项目经理
核心团队任务/阻塞每日站会Tech Lead
业务方功能进展/验收每迭代演示产品经理
运维发布计划/变更每次发布前变更单发布负责人

沟通计划不是形式主义。很多"协作问题"本质是沟通问题:信息没到该到的人手里,或者以对方看不懂的方式到达。

7、动手实验 🎯

任务:为你第 2 课写的立项提案,补出"章程 + 干系人地图 + 沟通计划"。

  1. 按第 3 节模板,把立项提案升级成项目章程,务必填满"不包含"和"关键假设"。
  2. 列出至少 6 个干系人,每人写清"最在乎什么"和"可能的阻力"。
  3. 把 6 个人放进权力-利益方格,为四个象限各写一条管理策略。
  4. 做一张最小沟通计划表(4 行就够)。
  5. 自检:有没有哪个人是你一直没想到的? 如果有,把他补上——这往往就是你项目最大的隐藏风险。

8、今天你带走的三句话

  1. 章程是项目的出生证明:写清目标、范围、边界、授权——尤其是"不做什么"。
  2. 最危险的干系人是"你忘了问的人",他们会在一票否决的时刻出现。
  3. 沟通不是通知,而是让每个干系人在对的时间收到对的信息。

下一课,我们把章程里的"范围"真正拆开:怎么把一句"我想要",变成一份能交付、能验收、还能防蔓延的范围定义?

标签: 软件工程, 项目管理, 开发流程

添加新评论