关注微信公众号LeadTech茶馆，第一时间获取后续更新。
面向对象： 非技术背景的新手项目经理、技术转管理的新手项目经理、想要了解项目管理的同学
前言
读书的时候我就想学习一些"除了写代码以外的东西，一种能真正指导开发的东西"，我不知道该叫他什么。
直到在学校的图书馆看到了一本《人月神话》，惊为天人，我才知道我想要的是"软件工程"。
在我看来，项目管理其实就是软件工程的核心体现之一。
但这些年我很少看到不错的相关文章，反而都是些裹脚布一样又臭又长、术语堆砌的文章。
这正因如此，很多人想转管理，但是不知道从何开始，网上的一堆破文章又看不懂。
很多朋友觉得项目经理就是拿个小皮鞭抽各个岗位干活就行了，但其实并不是的。
如果想当一个称职的项目经理，只会催进度肯定是远远不够的。
我虽然从业时间不算太长，但也确实走过技术转管理的路线，也对这方面颇有感兴趣。
也有着软考高级的系统架构设计师、信息系统项目管理师、PMP认证的经验，对技术与管理的体会比较深刻。
所以想着总结一下我的经验看看能否给大家带来帮助。
我是技术出身，技术转管理，需要跨越很多思维上的惯性，以及属于技术人员的那份自傲。
在这些年的工作中，我干过各种各样的活，前后端开发、客户端开发、架构、产品、测试、运维、项目经理，只能说没有一个岗位是容易的，只有资本家才是最该挂在路灯上的。
尤其是你想做一名称职的项目经理，更是一个劳心劳力的活。
我的精力有限，在这篇文章中我准备只写一些基本的、理论上的东西，毕竟项目经理是个很需要结合实际情况的工作。
整篇文章的指导思想主要是 《PMBOK 第六版》 过程组的思想，以及一点点 《PMBOK 第七版》 绩效域 的思想。
**《PMBOK 第八版》**的官方中文版据悉会在 2026 年年中发布，可能会涉及到AI时代一些项目管理新形势的讨论。
后续关于 《PMBOK 第八版》的相关解读，以及如何通过《PMBOK 第七版》指导管理，还有软件项目管理相关的其他知识可以关注我的微信公众号 LeadTech茶馆。
我会在这里发布一些前沿技术解析、管理知识与经验等内容，也欢迎大家评论交流。
接下来的全篇文章，我将以一个我在工作中参加过的案例，对这个项目进行裁剪、隐藏敏感信息，从多个案例一步一步带大家了解项目管理的相关知识。
这其实更像是一本实战手册，不是教科书。
我会用一个个例子，带你一步步走过项目经理的第一天到最后一天的所有关键决策。
你会看到面对具体问题时，项目经理应该怎么做、使用什么样的方法、每一步背后的知识点是什么。
假设背景
项目背景：在线练题 SaaS 平台的对接实施项目为贯穿案例。这是一个中等规模的 B2B SaaS 产品，客户为多家教育机构。
功能模块：需要完成在线练习、绘图做题、草稿管理、VIP 会员、支付购买等核心功能
团队人数： 8 人
预算：180 万元
时间要求：总工期 10 个月，项目目标是让这 5 家教育机构完成对接并上线。
主角设定：你，林枫，一直做了3年后端开发，自学过一些 PMBOK 第六版的知识（项目管理体系知识），从未在真实项目中实践过管理。直到今年年初，被 CTO 赶鸭子上架担任新项目的项目经理（PM）。
本文使用的核心工具：全程使用飞书为例，具体包括：飞书文档、飞书项目、飞书多维表格、飞书日历、飞书群聊。使用其他的如 PingCode、Jira、禅道、Tower、语雀、企业微信等都可以，基本方法都差不多。
工具准备：在开始之前，建议熟悉飞书的基本操作（或者其他管理工具的操作，当然不熟悉也行）
第一章：项目启动
场景1：啊？我？
📅 1月4日，星期一，早上9:15
新年第一个工作周，阳光透过落地窗洒进工位，你刚刚完成一个项目的上线，心情大好，正准备去茶水间倒杯咖啡犒劳自己。
就在这时，产品经理崔超从 CTO 刘文冰的办公室出来，正好看见林枫经过门口。
"林枫，老刘找你。"
"干啥啊？"
"给你个Surprise"
完蛋，不会又是什么棘手的活？
他疑惑地推开 CTO 刘文冰办公室的门。老刘放下手中的文件，示意你坐下，寒暄两句后开口：
"公司最近接了一个新项目……"
"啊。"
"是个在线练题的 SaaS 平台……"
"啊。"
"这个项目暂时还没有合适的项目经理……"
"我妈生孩子了我得回去照顾她有事写信嗷冰哥——"
"你妈都60了上哪生的孩子！"
刘文冰一把拉住起身要走的你："我决定让你担任这个项目的项目经理。"
"啊？我？"你指着自己的脸，一脸难以置信。
刘文冰叹了口气："别紧张，我知道你心里一定在想：''就我一个没能力没资历干啥啥不行吃啥啥不剩的后端开发哪配得上……'"
捏🐴的你是专门来骂我的吗。
"我选你，有多个原因。第一，你技术底子扎实，能和开发团队有效沟通；第二，你逻辑清晰，之前跨部门协作的时候表现不错；第三，你既懂技术又能协调……"
为了让我当项目经理连这种话你也说得出口吗哈吉刘？
"我回去考虑一下吧老大。"
"没问题，三天之内给我答复。"
……
接下来的两天你满脑子都是这件事。
你对技术有自知之明——在这个行业，年龄焦虑一把悬在头顶的尖刀，你早就在想自己的35岁之后该何去何从。
再加上你本身对项目管理也颇有兴趣，私下学过不少相关知识，只是苦于没有实战机会。
既然机会来了……一咬牙一跺脚，索性就拼一把！
📅 1月7日，星期一，早上9:15
你联系了 CTO 刘文冰，表示同意转岗为项目经理。
刘文冰倒是爽快，二话不说给转岗手续开了绿灯。当天，你就拿到了各项函件，正式成为这个项目的 PM（指PjM，项目经理）。
你回到工位，深吸一口气。
根据自己学过的项目管理知识，你知道新官上任第一步，是要写一份**《项目章程》**。
打开飞书文档，敲下第一行字：
"在线练题SaaS平台项目章程"
然后……
就没有然后了。
因为你发现自己什么都不知道。
场景2：我问问你
📅 1月8日，对着文档发呆的第二天
这天，你又在空白文档前坐了半小时。
屏幕上只有孤零零的标题，和一个坚持不懈闪烁的光标，仿佛在无声地嘲笑你。
"不能再这样耗下去了。"你自言自语，"得去找老刘问清楚。"
你梳理了一下思路，先准备好问题，打开 CTO 刘文冰的飞书对话框：
"冰哥，有个15分钟吗？想再请教几个问题。"
3分钟后，CTO 老刘回了："来。"
你立刻起身，生怕再晚点就抓不着他了——毕竟老刘每天神龙见首不见尾的。
你先让刘文冰给你好好讲了一下项目的背景情况，然后问出了你刚刚准备的问题。
问题一：硬性 deadline 是硬性的吗？
"冰哥，这个项目要求 Q1 末首批机构上线。这个 deadline 是定死的，还是可以谈的？"
刘文冰点点头："首批 5 家教育机构 10 月底上线，这是定死的。合同里写得清清楚楚，违约要赔钱。"
你赶紧记下来：10月底前完成首批5家上线，定死。
问题二：预算和人员能保证吗？
"那预算和人员呢？中途会不会被抽走？"
刘文冰翻了翻桌上的文件："预算180万，已经批了。团队8个人，具体人员一会我飞书发给你，已经提前都打过招呼了，2月前全部到位。中途大概也许可能应该不会变。"
你又记下来：180万预算，8人团队，2月到位，相对稳定。
问题三：成功标准是什么？
"最后一个问题——怎么才算成功？"
刘文冰想了想："三个标准。第一，10月底5家教育机构完成对接并上线；第二，系统稳定运行一个月无重大事故；第三，客户满意度调查达到80分以上。"
你认真记下每一条。
问题四：过程中的关键节点有哪些？
"老大，除了最终上线，中间有没有什么必须卡住的检查点？"
"有。6月15日需求冻结，之后原则上不改需求；9月30日集成测试完成，要跑通全流程。这两个节点卡住了，后面的节奏才不会乱。"
你又记下来：6月15日需求冻结，9月30日集成测试完成。
所有问题问完，他长舒一口气。
回到工位，你把这些信息整理了一下，很快就完成了一份像样的《项目章程》。
写完之后，你找到 CTO 刘文冰进行确认。刘文冰检查了一遍，觉得没问题，于是正式签了字。
📚 知识点：项目章程
什么是项目章程（Project Charter）？
项目章程是项目启动阶段的核心产出，是直接记录的领导的想法，也是项目的整体行动方针。
项目章程应该包含哪些内容？
按照 PMBOK 第六版的标准，项目章程通常应包含以下核心要素：
| 要素 | 说明 |
|---|---|
| 项目目的 | 为什么要做这个项目 |
| 可测量的项目目标 | 具体的成功标准 |
| 高层级的需求 | 概括性的需求描述 |
| 项目边界和主要可交付成果 | 做什么、不做什么 |
| 高层级的预算和资源 | 包括团队人员配置 |
| 关键里程碑 | 重要的时间节点 |
| 项目经理的职责和职权 | 明确PM的权力范围 |
| 项目发起人或批准人的职权 | 谁签字谁负责 |
答案就在你刚才问CTO的四个问题里，已经包含了一部分的要素：
flowchart LR
A["问CTO：硬性deadline？"] -->|回答| A1["→ 约束条件：10个月工期，10月底，最多延7天"]
B["问CTO：预算和团队？"] -->|回答| B1["→ 约束条件：180万，8人团队"]
C["问CTO：成功标准是什么？"] -->|回答| C1["→ 项目目标：5家客户接入，平台稳定可用"]
D["问CTO：关键节点有哪些？"] -->|回答| D1["→ 关键里程碑：需求冻结、集成测试、最终上线"]
💡 为什么要先问CTO再写章程？
很多新手PM会犯一个错误：拿到需求就自己写章程，埋头写三天，拿给CTO一看——"什么玩意？你梦到哪句写哪句啊，这不是我想要的"。
正确的顺序是：先问关键问题（场景2），对齐信息，再写章程。
你的这份章程，本质上是把CTO的口头承诺变成了书面记录。
💡 为什么要明确项目经理的职权？
因为没有明确授权，项目经理就是个"光杆司令"——谁都指挥不动。
章程里的职权说明，就是PM的"尚方宝剑"。当林枫需要调动资源、协调冲突时，这句话就是林枫的底气。
💡 为什么要明确团队人员范围？
"8人团队"只是一句话，但"谁负责什么"才决定项目能不能落地。
团队角色和人员范围的明确，为后续制定《项目范围说明书》和《责任分配矩阵》（RAM）奠定基础。
项目章程由谁来签发？
签发可以理解成是谁批准就是谁签发的，一般签发人是项目发起人，在本项目里就是 CTO 刘文冰。
签字的那一刻，章程才正式生效——它意味着"这个项目公司正式批准了，PM有权限调动资源"。
谁有权创建项目章程？
PMBOK告诉我们，项目章程通常由项目发起人或高级管理层创建和签发，但PM可以负责撰写和准备草案。
在实际操作中，PM先起草，CTO签字确认，是最常见的做法。
一份真实的项目章程长什么样？
以下就是你在场景二里拿到CTO确认后，飞书文档里初步形成的项目章程草案：
【在线练题SaaS平台 项目章程（草案）】 签发人：CTO | 日期：1月8日
■ 项目经理任命
- 项目经理：林枫
- 职权说明：项目经理有权调配项目资源、协调跨部门协作、审批项目范围内的变更请求
- 向谁汇报：CTO 刘文冰
■ 团队角色与人员范围
- 项目经理：1人（林枫）
- 产品经理：1人（崔超）
- 技术负责人：1人（王奇）
- 后端开发：2人（张浩、赵明）
- 前端开发：1人（李文静）
- UI设计：1人（周珊）
- 测试：1人（陈光）
- 合计：8人
■ 项目背景与目标 5家教育机构10月底前完成对接并上线，平台核心功能可用，系统稳定运行
■ 关键约束条件
- 总预算：180万元
- 总工期：10个月
- 硬性deadline：10月底（最多延7天）
- 团队规模：8人，2月前到位
■ 关键里程碑
- 6月15日：需求冻结
- 9月30日：集成测试完成
- 10月底：5家客户上线
■ 核心成功标准
- 5家客户成功接入并上线
- 平台稳定运行一个月无重大事故
- 客户满意度调查达到80分以上
■ 高层级需求方向 在线练习、绘图做题、VIP会员、支付等核心模块
■ 备注 详细项目范围将在规划阶段通过需求调研后，由《项目范围说明书》正式定义
为什么要写项目章程？
项目章程可以确定整个项目的大体方向，主要是领导想要的大体方向。如果没有项目章程，林枫等人可能会自己考虑项目方向。
比如你们觉得会员功能很重要，做了几个月中间会员功能有问题请示 CTO，CTO 说："我不道啊？"，这时你们才知道 CTO 想要加强的是题目练习功能，前面的工作都浪费了。
场景3：这就不奇怪了，这就不奇怪了
📅 1月9日，项目章程签字后的第二天
你看着手里签好字的项目章程，心情不错。
"目标有了，约束有了，里程碑有了......"你喃喃自语，"下一个是什么来着？"
你打开你的指导手册《PMBOK 第六版》，翻到"启动过程组"那一章。
一行字映入眼帘：
"识别干系人：识别项目干系人，并记录其利益、参与度、相互依赖性、影响力和影响力。"
你仔细复习一下这一部分，感觉干系人好像就是跟项目有关的人。
"那干系人不就是 CTO 刘文冰、还有团队那些人吗？技术负责人王奇、产品经理崔超、后端开发张浩他们......这有什么好识别的？"
算了，先把书扔一边去，准备先去厕所享受快乐的带薪蹲坑时光。
在厕所辛勤劳作之时，你接到了一个电话。
"喂，请问是在线练题平台的PM吗？"
你看了眼来电显示，是个陌生号码。
"是的，我是。请问您是？"
"我是铁林中学的信息中心主任，姓马。我们是你们的试点机构之一。听说项目要开始了，我们想了解一下进度。"
试点机构？主动打电话来了？
"哦，马主任您好！是这样的，项目刚刚启动，我们预计下个月会开始规划......"
"好的好的，我想问一下，我们学校的网络环境比较特殊，可能需要定制接口，这个能支持吗？"
"定制接口？"你的声音有点紧，"我需要和技术团队确认一下。"
"好的，那我等你们的消息。对了，我们学校后续对接的话，主要是我这边负责技术对接，有什么问题可以直接联系我。"
"好的马主任，有问题我这边会提前跟您沟通。"
电话挂断。
等等……试点机构还有5家。每家都像马主任这样有关心的问题？每家的期望一样吗？
你突然一把抓回你扔到一边的《PMBOK 第六版》，翻到刚才看过那几个大字。
识别干系人。
"这就不奇怪了，这就不奇怪了。"
这5家客户，每家都有自己的诉求、自己的时间表。
你终于意识到，在项目开始之前，你确实要先了解有哪些关注项目的主体。
你新开了一个飞书文档，思索一番后在文档中列出对应的干系人。
内部干系人：
- CTO 刘文冰（项目发起人）
- 产品经理 崔超
- 技术负责人 王奇
- 开发团队（后端开发张浩、赵明，前端开发李文静）
- 测试团队（陈光）
- UI设计师（周珊）
外部干系人：
- 5家教育机构客户
你刚分析完，余光就看见产品经理崔超刚开完会，回到了自己的工位泡了一杯菊花茶。
你想到老崔是老资历了，老到都送走好几个 PM 了，再老点就该你把他送走了，他比较有经验可以帮你看看。
你搬着电脑去崔超的工位请教一番。
"超哥，我列了干系人名单，你帮我看看有没有漏的。"
老崔端起茶杯喝了一口，仅仅扫了一眼你的列表就知道："漏了不少。"
"比如？"
老崔又喝了一口："5家客户，直接对接人是谁？"
老崔双喝了一口："财务，你们的180万预算怎么花的、什么时候付款、谁来审批？"
老崔叒喝了一口："法务，产品涉及支付和用户数据，需要合规审查吧？"
"还有……"老崔看了眼茶杯，"怎么没水了？"
"哎呀你憋喝了超哥，水牛啊你，一会我给你搬一桶回来！"
老崔放下茶杯继续说道："运维部，系统上线后归他们维护，要不要提前打招呼？"
"教育局/监管机构，在线教育有资质要求吗？"
你越听越觉得心里没底。
"谢了老崔，多亏有你了，我之前完全没想过这些......"
崔超拍了拍你肩膀，安慰道：
"那还不赶紧滚去给我打水。"
"……"
📚知识点：识别干系人
**干系人（Stakeholder）**是指可能影响项目、被项目影响，或自认为会被项目影响的个人、群体或组织。
简单来说：所有"在乎"这个项目的人，都是干系人。
💡 为什么要识别干系人？
项目失败的最常见原因之一，就是"做到一半突然冒出来一个人说'这个我没同意啊'"，而这个人又很重要。
识别干系人的目的，不是讨好所有人，而是：提前知道谁在乎，提前知道他们想要什么，提前想好怎么应对。
就像你那通电话——如果马主任没打，那他验收的时候马主任跳出来说"这不是我想要的"，那你就得半夜套他麻袋了。
干系人哪来的？
主要有三类来源：
flowchart TB
A["干系人定义"] --> B["🔍 可能影响项目的人"]
A --> C["📢 被项目影响的人"]
A --> D["🎯 自认为与项目相关的人"]
B --> B1["客户/用户"]
B --> B2["管理层"]
B --> B3["项目团队"]
- 可能影响项目的人：能决定项目生死的人，比如客户决策者、管理层、项目团队
- 被项目影响的人：最终用你产品的人，以及上下游合作方
- 自认为与项目相关的人：这个最容易被忽略——媒体、竞品、甚至只是"听说了这个项目"的外部人员
干系人为什么要分内外部？
因为一旦一个干系人被确定了是内部还是外部，你就能知道对他最基本应对方法。
- 内部干系人你可以"管"——通过会议、汇报来协调；
- 外部干系人你只能"谈"——通过沟通、谈判来管理期望。
很多新手PM只盯着内部，忽略了外部，结果项目上线前监管机构一个电话打过来，发现合规没做到，麻爪了就。
比如简单分一下这个项目的内外干系人就是这样的：
mindmap
root((干系人分类))
内部干系人
高层管理
CEO/CTO
董事会
项目团队
开发
测试
设计
其他部门
财务
法务
HR
外部干系人
客户
决策者
使用者
IT对接人
合作伙伴
供应商
外包团队
监管机构
行业主管部门
数据监管
我该如何识别干系人？
1. 问项目发起人和核心团队
你在场景 3 中，其实在最开始把书扔到旁边之前就已经识别出来一些干系人了。
CTO 刘文冰、技术负责人王奇、产品经理崔超、后端开发张浩……
这些人就是发起人和核心团队。
你以他们为中心，一个一个问他们三个问题，从他们开始向外扩散问更多人：
-
"这个项目上线后，谁会受影响？"
-
"谁会来找我们提需求？"
-
"谁有能力让这个项目做不下去？或者了解一些涉及到让我们做不下去的信息？"
通常来说，项目发起人通常是最清楚"谁关心这个项目"的人。多问几个人，互相印证。
2. 画组织架构图和项目依赖图
- 内部：你的项目涉及哪些部门？财务、法务、运维、客服会不会被波及？
- 外部：你的客户上下游是谁？有没有监管机构需要对接？
3. 假设"最坏情况"
问自己：如果项目失败了，谁会跳出来问候我祖坟？ 骂你最凶的那个人，大概率就是高优先级干系人。
4. 不要忘了"沉默的大多数"
有些人不会主动找你，但你必须主动找他们。比如：
- 最终用户（他们可能不会主动反馈，但他们的使用体验决定产品成败）
- 运维/客服/行政等（他们最清楚系统上线后会遇到什么问题）
我到底该识别些什么？
识别干系人不是列个名单就完了，你得搞清楚每个人的情况，不然表格填满了也是废纸。
以下是你需要了解的核心信息：
| 识别维度 | 你要搞清楚的 |
|---|---|
| 角色与职位 | 他在项目中是什么身份？决策者？执行者？使用者？ |
| 影响力范围 | 他能影响什么？预算？技术选型？验收签字？ |
| 核心期望 | 他最在乎什么？功能？工期？成本？合规？ |
| 当前态度 | 支持你的项目、中立、还是有点抵触？ |
| 沟通偏好 | 喜欢当面聊、发邮件、还是拉群？ |
| 关键介入点 | 他什么时候会介入？验收时？评审时？还是出问题的时候？ |
| 底线与红线 | 什么是他绝对不能接受的？ |
场景4：新机子哇伊兹莫一肚子！
📅 1月16日，星期四，下午3:30，休息区
干系人，哦 ~ 干系人 ~
你还是在对着干系人的破文档思考。
虽然经过产品经理崔超的指导，你已经广泛的识别了干系人，可是每个干系人都对项目有着各自的期望和影响。
你的精力有限，也不能每个干系人都频繁沟通、每个干系人的期望都满足。
"项目经理没干几天，我的头快要裂开了。"
你想不出来办法，去茶水间接了一大杯水，准备去休息区也当会水牛。
刚好几名销售部的同事也在，你坐了过去和他们一起聊聊天。
"诶你听说了吗，数据流动和分类分级产线被监管部门毙掉了。"
"监管部门？"你一楞，你确实识别干系人的时候识别到了他们，但是你没太把他们当回事。
"咋回事，公司内斗吗？数据流动和分类分级产线和监管部没什么利益冲突吧。"
"确实没什么利益纠纷，好像是因为隐私审查没通过，监管部门权利很大的，可以直接判定项目中止。"
听到这些，你陷入了思考。
利益决定了干系人想影响项目的意愿，权力决定了干系人能影响项目的力度。
**利益关系？权力大小？**你或许可以从这两方面具体来考虑怎么管理这些干系人的期望和影响。
你隐约记得 PMBOK 中恰好有这种专门用于考虑干系人期望管理策略的工具。
突然，一道白光闪过脑海。
"新机子哇伊兹莫一肚子！权力-利益矩阵！"
"现在年轻人压力是大，叽里咕噜的开始说胡话了都。"真·水牛老崔端着一壶茶水一边摇头一边从你身旁走过。
你想起PMBOK中恰好有这种专门用于考虑干系人期望管理策略的工具 —— 权力 - 利益矩阵。
你拿出那本厚厚的《PMBOK 第六版》作为指导，对着众多干系人继续整理了起来。
📚知识点：干系人期望管理
权利-利益矩阵 —— 我应该把有限的精力优先放在谁身上？
权力-利益矩阵，它回答了"我应该把有限的精力优先放在谁身上？"这个问题。
它分为四个象限（就是如下图的四块），你需要根据每个干系人的对项目的权力、干系人与项目的利益相关情况，来将其分到四个块的其中一个。
比如这是本项目粗略的权力-利益矩阵：
quadrantChart
title 权力-利益矩阵
x-axis "低利益" --> "高利益"
y-axis "低权力" --> "高权力"
"CTO/发起人": [0.9, 0.95]
"技术负责人": [0.85, 0.9]
"客户决策者": [0.85, 0.7]
"普通开发": [0.7, 0.3]
"财务/法务": [0.3, 0.75]
"普通用户": [0.8, 0.2]
"监管部门": [0.4, 0.85]
| 象限 | 管理策略 | 干系人 |
|---|---|---|
| 高权力-高利益 | 重点管理：密切合作，确保目标一致 | CTO、技术负责人、客户决策者 |
| 高权力-低利益 | 保持满意：定期汇报，满足合理要求 | 财务、法务、监管部门 |
| 低权力-高利益 | 随时告知：保持信息透明 | 团队成员、普通用户 |
| 低权力-低利益 | 监督即可：必要时再沟通 | 其他部门、间接相关方 |
每个象限中的干系人如何应对，是权利-利益矩阵定好了的，就是上表中的管理策略。
对分到对应象限的干系人使用对应的管理策略即可。
这是我常用的沟通频率，仅供参考：
| 干系人类别 | 沟通频率 | 沟通方式 | 沟通内容 |
|---|---|---|---|
| 高权力-高利益 | 每周 | 面对面/视频 | 进展、风险、决策 |
| 高权力-低利益 | 按需/每月 | 邮件/会议 | 关键里程碑汇报 |
| 低权力-高利益 | 每两周 | 群消息/文档 | 进展更新 |
| 低权力-低利益 | 按需 | 邮件抄送 | 必要时通知 |
切记管理策略都是理论，仅供参考，具体操作要根据实际情况来。
别到时候监管部门（高权力、低利益）来了要查你们，你跟他说："你还没到月份呢，等到月我联系你。"
简单说：
- 权力高的人，你惹不起，得重点伺候
- 利益高的人，他们对项目结果很在乎，得让他们满意
四个策略的区别在于：
- "重点管理"要主动出击，定期汇报+主动沟通
- "保持满意"要被动响应，有求必应+主动预警
- "随时告知"要透明公开，建群+发周报+及时响应
- "监督即可"可以放养，偶尔同步即可
处理干系人冲突的技巧
flowchart TD
A["干系人冲突处理"] --> B["🤝 找到共同目标"]
A --> C["⚖️ 评估各方利益"]
A --> D["📋 书面记录分歧"]
A --> E["🔄 寻求折中方案"]
B --> B1["「我们都希望项目成功」"]
C --> C1["核心利益 vs 边缘利益"]
D --> D1["避免后续「我没说过」"]
E --> E1["Win-Win"]
style A fill:#E8F4FD
常见场景的处理方式：
| 场景 | 错误做法 | 正确做法 |
|---|---|---|
| 客户要求提前上线 | 直接答应或直接拒绝 | 评估影响，给出选项 |
| 两个客户需求冲突 | 和稀泥 | 明确优先级，记录决策 |
| 干系人越过PM直接找团队 | 无视或抱怨 | 引导回PM，建立规范 |
| 高层期望远超项目范围 | 硬着头皮答应 | 用矩阵分析，管理期望 |
实际场景中，该和稀泥还是得狠狠的和
场景5：吃你的大姐狗食去吧
📅 1月17日，星期五，中午12:30，食堂
法务赵海在食堂吃饭的时候，一抬眼看见了你也在。
"这么巧。"他跟你打了个招呼。
"是啊"，你端着盘子顺势坐了下来。
巧个鬼。
经过上次产品经理崔超的点拨，你识别出了法务赵海也是重要的干系人之一，所以准备找他沟通一下。
但是赵海一直太忙了，你每次都在工位找不到他。
所以你故意在这蹲点，已经快在这食堂上上下下走出个马拉松了。
"今天咋来食堂吃饭了，你之前不是说这食堂的饭跟狗食似得吗？"你随意的问着。
"最近在减肥，吃那点东西和狗食也差不多了。"
"软件园二期那边有个轻食，听文静说那家还挺好吃的。"
"那我下次去试试，叫啥啊？"
"我也记不太清，好像叫什么什么三姐沙拉，我们这个项目有什么合规的风险吗，但好像分量很小，你可能吃不饱。"
"？"赵海正在往嘴里塞的筷子一顿，"不是你等会，中间是不是插了进去什么奇怪的东西。"
赵海白了你一眼说道："你不会今天是专程来堵我问我合规风险的吧？"
"妹有啊——"你一收脖子，露出尴尬而不失礼的微笑。
"行吧，你算是问对人了。"赵海无奈的说，"你们那个项目的项目章程我在群里看了，确实是有问题。"
你立刻不知道从哪掏出来个电脑开始记录，里面飞书文档都已经建好了。
"你还说你不是专门来堵我的！飞书文档都建好了！"
"现在信息泄露多严重你看看，咱俩说这话飞书自己就捕捉到了，自己建了个文档。"
"你放P！"
法务赵海把最后一口没有蛋的蛋花汤喝完，仔细的和你讲了起来。
"枫，按照《数据安全法》和《个人信息保护法》，你这个在线练题平台，需要注意三件事。"
"第一，用户数据的收集、存储、传输必须符合加密标准。你们用的是云服务，数据安全得确认清楚。"
你记下来：数据加密，云服务商安全认证。
"第二，5家教育机构的数据必须隔离存储，不能混用。这是机构数据的'物理隔离'要求。"
你又记下来：机构数据隔离。
"第三，平台需要做数据安全评估。准备接入数据 API 之前15个工作日要提交评估报告。"
你惊讶的复述了一遍："准备接入数据 API 之前15个工作日？"
"至少。"
"等等，这个时间点是什么时候开始算的？"
赵海看着你："从你们开始开发准备接入那天起算，因为就算是用于测试开发也得先走评估。"
那岂不是说，现在就该开始准备？
赵海似乎看出了你的担忧，拍了拍你最近正在健身且"初具雏形"肱三头肌：
"别慌兄弟，这些都是能做的，只是需要时间和预算。幸好你今天来问了，不然上线前两周突然发现合规没做完，那才叫完蛋。"
"另外，"赵海补充道，"支付模块的合规审查也需要提前介入。建议你们在技术方案评审的时候叫上我。"
技术方案评审？
"好的，到时候一定叫你，太感谢你了，周五晚上请你吃饭。"
"我吃海底捞。"
"你不吃那什么大姐狗食吗！"
"三姐沙拉。"
"这时候记性好了？你不减肥吗！"
"有人请客我减什么肥。"
"……"
📅 1月20日，星期一，早上9:00
你把昨晚整理的合规要点发给了技术负责人王奇：
"王哥，关于数据合规，法务赵海提了几点建议，我整理了一下发你邮箱。另外，赵海说技术方案评审的时候想参与，你看有什么问题吗？"
王奇很快回复：
"收到。我看了下没什么问题，技术评审方案的时候我会提醒一下他。"
你长舒一口气，又解决了一个隐患。
📚知识点：干系人沟通
如何收集干系人的信息。
聊。
张个大嘴就是问。
一对一访谈、吃饭闲聊、打个电话、微信扯闲篇、会前寒暄……都是收集信息的好机会。
"干系人的期望不是猜出来的，是问出来的。"
赵海愿意在食堂告诉你这么多，也和你们在一个相对轻松的环境、轻松的对话有关。
你很聪明的没有在他最忙的这一阶段找他约一个正式会议，而是根据聊的内容的长短、和赵海的同事关系等信息，综合选择了吃饭这个场景。
和干系人打交道，主要有两种方式：
| 类型 | 特点 | 适用场景 |
|---|---|---|
| 正式沟通 | 有组织、有记录、有明确议程 | 重要决策、正式汇报、会议评审 |
| 非正式沟通 | 轻松、自然、灵活 | 日常维护、情报收集、关系建立 |
非正式沟通：润物细无声
场景4中的"食堂蹲点"就是典型的非正式沟通。
常见形式：
- 一起吃饭（食堂、楼下餐厅、甚至叫外卖）
- 走廊偶遇、电梯寒暄
- 微信/飞书私聊
- 咖啡时间、下午茶扯闲篇
正式沟通是"工作"，非正式沟通是"聊天"。
在非正式的沟通中，干系人会更放松，更愿意对你讲述更多的细节。
有的时候也是"人情"，人情到了，信息也就有了。
你问赵海合规风险，他可以回你一句"稍等，我开个会议室给你讲"，也可以在吃饭的时候随口说"对了，你们那个项目有个坑，我提醒你一下"。
正式沟通：该正经时要正经
但有些事情，必须走正式流程：
常见形式：
- 线下会议/视频会议
- 项目启动会、评审会
- 邮件汇报
- 正式的周报/月报
什么情况下用正式沟通？
- 需要留下记录和证据的
- 需要多方确认、形成决议的
- 涉及合同、协议、承诺的
- 正式汇报进度、请求支持的
组合使用：非正式探路，正式收口
我个人常用的最佳实践是这样的：
非正式沟通 → 发现问题/了解期望
↓
正式沟通 → 确认方案/达成共识/形成记录
场景 5 就是这样：你先在食堂"偶遇"赵海，用非正式沟通探到了合规风险；
然后你发邮件整理合规要点，让王奇确认——这就是正式沟通。
💡 小技巧：
- 重要信息：非正式聊完，一定要正式确认一遍，否则他转头可能就不认了
- 敏感话题：先用非正式沟通试探态度，再决定要不要开正式会议
- 维护关系：偶尔一起吃个饭、节假日发个祝福，比每次找人都谈工作强
- 不擅长这个的也不强求，适度即可
- 还是那句话，你的管理专业性更是你的底气，因为你的管理能给很多人带去利益，更重要的是能给领导带去利益
沟通渠道对照表
| 干系人类型 | 推荐沟通方式 |
|---|---|
| 项目发起人/高层 | 正式汇报 + 偶尔私下沟通 |
| 技术负责人 | 日常协作 + 正式技术评审 |
| 法务/财务 | 非正式建立关系 + 正式评审介入 |
| 客户决策者 | 正式会议 + 日常维护 |
| 一线使用者 | 非正式访谈 + 正式需求确认 |
📚知识点：干系人登记册
你通过张个大嘴叭叭问，得到了上述的所有干系人信息。
经过整理之后，你要建立干系人登记册——把信息记录下来，方便后续跟踪。
📝 为什么要建立登记册？
你今天记得CTO想要什么，三个月后双方都有可能就忘了。
等他三个月后问你"当时说好的XX呢？"你回答不上来。
有了干系人登记册，你可以在项目推进过程中时刻注意干系人关注的内容。
同样，当三个月后干系人提出了不同的关注点时，登记册也是你的"证据"。
（干系人不长脑子不记事这种事情真的非常常见，想必上过班的朋友们都遇到过）
以在线练题平台为例，干系人登记册大致长这样：
【在线练题SaaS平台 - 干系人登记册（部分）】
■ 内部干系人
姓名/部门 角色 联系方式 利益影响 期望 管理策略 CTO 刘文冰 项目发起人 飞书 高/高 项目成功，按时交付 重点汇报 技术负责人 王奇 技术决策者 飞书 高/高 架构合理，工期合理 密切合作 产品经理 崔超 需求负责人 飞书 高/高 需求完整，进度顺利 日常沟通 财务部 老张 预算管理 邮箱 中/低 预算合规，账目清晰 按需沟通 法务部 赵海 合规审查 邮箱 中/低 符合法规 提前介入 ■ 外部干系人
机构名称 联系人 联系方式 角色 利益影响 期望 关键时点 管理策略 铁林中学 马主任 微信/电话 IT对接 高/高 9月前上线 开学前 密切合作 金林学院 李院长 电话 决策者 高/高 数据安全 验收时 重点汇报 铁林小学 陈老师 微信 使用者 低/中 操作简单 培训时 随时告知 监管部门 - 邮箱 合规审查 中/低 符合标准 上线前 保持合规
干系人登记册如何一次做到位？
不可能的。
首先很多老项目经理都很难在各种项目中，成功的一次性识别所有干系人。
而且干系人登记册是活的，整个项目过程中要持续更新。
项目中期换领导、新增合作方、团队成员离职、新同事入职……，都会导致干系人的更新。
场景6：开干，我玩的就是真实
📅 1月22日，星期三，下午2:00
项目章程也有了，干系人你已经分析的差不多了，接下来就该正式启动了。
昨天你在飞书日历里预约好了 Kick Off 会议（项目启动会），Kick Off议程文档早就发给了项目的成员。
飞书项目群里也通知了两遍，昨天一遍，距离会议十分钟又一遍。
你站在会议室门口深吸一口气，这是你作为项目经理第一次在众人露面的会议。
"开干！"
项目章程上提到的项目团队的成员和CTO刘文冰都到场了：
-
CTO：1人（刘文冰）
-
项目经理：1人（林枫）
-
产品经理：1人（崔超）
-
技术负责人：1人（王奇）
-
后端开发：2人（张浩、赵明）
-
前端开发：1人（李文静）
-
UI设计：1人（周珊）
-
测试：1人（陈光）
第一部分：CTO 开场（约15分钟）
CTO 刘文冰靠在椅子上，讲了项目背景、目标和以及任命你当项目经理。
你感觉他似乎快要没什么话说了，于是你在适当的时机自然的接过了话头。
第二部分：PM 主持——讲章程和对齐分工（约60分钟）
你站起来，打开飞书文档，翻到项目章程那一页，将项目章程中的细则讲给了大家。
你讲完章程，翻到下一页——这是你提前准备的分工框架表，在飞书文档里用多维表格做的。
"接下来，我们逐条对齐分工。"你说，"我手里有一份基本的分工框架，我来说，大家来确认，如果有异议的话。"
你打开飞书文档，展示了分工框架：
【在线练题SaaS平台 角色分工确认表】 项目负责人：PM林枫 | 日期：1月22日
模块/角色 负责人 关键职责 资源/约束 确认状态 整体项目管理 PM林枫 统筹协调、进度跟踪、风险管控 全职 ⏳ 待确认 产品需求 产品经理崔超 PRD输出、需求澄清、优先级把关 全职 ⏳ 待确认 技术架构 & 数据集成 技术负责人王奇 架构设计、5家机构接口适配、集成方案 全职 ⏳ 待确认 后端开发（核心平台） 后端开发张浩 用户认证、练习模块、VIP/支付逻辑 2月前到岗 ⏳ 待确认 后端开发（辅助中台） 后端开发赵明 书籍扫描、题目导入、题集审查、题目修改 2月前到岗 ⏳ 待确认 前端开发 前端开发李文静 练习界面、绘图做题、VIP展示层 2月前到岗 ⏳ 待确认 UI设计 UI设计周珊 界面设计、交互规范、设计验收 2月前到岗 ⏳ 待确认 测试 测试陈光 测试计划、用例编写、UAT支持 2月前到岗 ⏳ 待确认 质量保障 PM林枫 + 测试陈光 上线checklist、合规验证 — ⏳ 待确认
"我逐条过一遍，"你说，"超哥负责产品需求，PRD他来输出，需求优先级他来把关，这个没问题吧？"
产品经理崔超点头："没问题。"
你在确认状态栏打了一个✅。老崔没问题。
"文静，"你看向李文静，"前端开发这块你负责，2月前到岗没问题吧？"
前端开发李文静说："没问题，年后第一件事就是这个。"
✅。前端李文静。
"周珊，"你看向周珊，"UI设计这边你来，练习界面和绘图做题的交互规范，你和产品经理老崔要对齐一下，2月前到岗没问题吧？"
UI设计周珊说："没问题，我这边主要是看 PRD 输出之后才能开始，所以和老崔的时间节点对齐就行。"
✅。UI设计周珊。
"陈光，测试归你，测试环境和测试计划要提前和产品对齐，有问题吗？"
测试陈光说："有一个：测试环境要提前准备好，不然没法开始。"
"好，这条我记下了，"你当场在飞书文档里补了一条Action Item：
【Action】PM协调测试环境准备，负责人：林枫，截止日期：2月10日
"测试环境的事我来跟进，这条我记下了，会后落实。"
✅。测试陈光。
"继续。张浩、赵明，后端开发归你俩，有问题吗？"
"我没问题，上一个项目已经交付了。"赵明答道。
✅。后端开发赵明。
后端开发张浩："年后第一个月我只能给30%时间，老项目还没收尾。"
你记下来："这条也记下了，会后我和王哥、老崔拉会对齐工期影响。今天先把你的约束确认下来。"
【Action】年后排期对齐，负责人：林枫，截止：2月1日
张浩点头。
然后是技术负责人王奇："王哥，架构设计归你，有问题吗？"
王奇想了想，说："架构没问题，但5家机构的数据集成有三点需要讨论——"
你打断了一下："王哥，这几点我记下来了。详细讨论我们会后单独拉会，今天Kick Off先把分工确认掉，你看行吗？"
王奇顿了一下，点头："行。"
你继续往下过，5分钟后，分工表全部确认完毕。
确认完毕后，你看向 CTO 刘文冰：
"刘总，我暂时就这些了，您还有什么需要交代我们一下的吗。"
第三部分：CTO总结（约 10 分钟）
刘文冰站起来，说了两句："项目重要性大家都清楚。10月底上线，不能拖。后续有问题找林枫，如果有什么困难和问题让林枫来找我。散了。"
会议结束。
📅 1月22日，下午5:00
你回到工位，立刻整理会议纪要，发到项目群里：
【Kick Off 会议纪要】
■ 确认事项
项目章程：已确认
分工框架：已确认
■ Action Item
测试环境准备 | 负责人：林枫 | 截止：2月10日
年后排期对齐会议 | 负责人：林枫 | 截止：2月1日
机构数据集成详细方案 | 负责人：王奇 | 截止：2月5日（会后单独拉会讨论）
■ 待决议事项
- 张浩年后工时约束对整体工期的影响
你@了每个负责人让他们确认文档。
然后你打开和王奇的私聊窗口，发了一条：
"王哥，5家机构集成的事我记下了，明天上午我们拉个会对齐一下，你看行吗？"
王奇回复："行。"
📚知识点：Kick Off——项目启动会
Kick Off 会议（项目启动会）是项目正式启动的标志性事件。
很多人把kick off开成"宣布会"——CTO讲5分钟、PM讲5分钟，然后散了。
这种会开了等于没开，团队成员走出会议室还是不知道自己要干什么。
一个有效的kick off会议，要回答三个问题：
flowchart LR
A[为什么要做？<br/>项目背景与目标] --> B[要做到什么程度？<br/>范围边界与里程碑]
B --> C[谁负责什么？<br/>角色分工与资源承诺]
Kick Off 会议要PM 组织，PM 主持。
这是 PM （Project Manager 项目经理，也就是你，林枫）的责任，不是 CTO 的责任。
| 角色 | 职责 |
|---|---|
| CTO / 项目发起人 | 负责开场——讲清楚上述的三个问题，"谁来负责这个项目"。CTO 不主持会议，主持是 PM 的活。 |
| 项目经理（PM，小林） | 全程主持会议：控制节奏、引导讨论、确保对齐、会议纪要 |
为什么 CTO 不能代替 PM 主持？
CTO 主持的会是"宣布会"——大家听 CTO 讲，听完散会，没有讨论。
PM 主持的会是"对齐会"——因为 PM 是项目的直接负责人，你有动机去推动每个人真正理解和承诺。
谁来参加会议？
- 核心团队成员（产品、后端、前端、测试、数据集成）
- 项目发起人（CTO）：通常需要出席开场 + 关键讨论环节（至少前30分钟）
- 产品经理：全程参与
- 不需要 CTO 全程在场：CTO 的职责是开场 + 拍板关键决策，不是从头盯到尾。PM 需要提前和 CTO 对齐"哪些问题 CTO 需要在场"，哪些问题 PM 自己可以推进
具体操作上：
第一步：会前准备（PM 自己要做的事）
- 用飞书日历预约会议：提前 3 天预约，标题写清楚——比如"在线练题SaaS平台 Kick Off —— 目标对齐 & 分工确认"，而不是单纯写"项目会议"
- 准备会议议程文档：在飞书文档里新建一份 Kick Off 议程，提前发给所有参会人，或者直接发在你们的项目群里
- 和 CTO 提前对齐：CTO 要讲什么、谁来开场、哪些问题 CTO 要在场拍板——这些 PM 要提前和 CTO 沟通好，不能在会场上才问
- 准备分工讨论的框架：提前在飞书文档里列好"角色分工 & 资源承诺"这一节的草稿，方便会上直接引导讨论
Kick Off 会议议程模板（供参考）：
会议名称：在线练题SaaS平台 Kick Off
时间：1月22日 14:00-15:30
参会人：CTO 刘文冰、产品经理崔超、技术负责人王奇、后端开发张浩、前端开发李文静、UI设计周珊、测试陈光、项目经理小林（PM）
议程：
① CTO 开场（14:00-14:15）：项目背景、目标、为什么由小林担任 PM
② PM 主持 - 项目章程讲解（14:15-14:30）：目标、范围、里程碑、约束
③ PM 主持 - 角色分工讨论（14:30-15:00）：各角色分工确认，资源承诺
④ PM 主持 - Q&A 开放讨论（15:00-15:20）：任何疑问当场提出
⑤ CTO 总结 & 收尾（15:20-15:30）：最终确认
会前材料：[飞书文档链接] 会议议程 & 项目章程草稿
第二步：会上主持——PM 怎么主持？
PM 在 Kick Off 会上要做四件事：
- CTO 开场后，PM 接棒：CTO 讲完背景，PM 接着讲项目章程和目标。不要等 CTO 把所有事情都讲完——PM 才是这场会的主角
- 关于这一点，其实无论领导是否知道需要自己开场，他都会先开场说点什么，下意识的就会讲一下背景，因为这样才能彰显自己的权威，并且除了背景也实在没啥可讲的。
- 引导分工讨论，不要只是宣布：每一个角色的职责，都要当场确认——"后端张浩，后端开发这块你负责，你有没有问题？"——这是"引导承诺"，不是"通知"
- 会议上不要展开过于大而长的讨论，而是像上面的案例一样，记录下来会后私下讨论，或者考虑拉一个新会讨论
- 记录每个人的反应和顾虑：谁当场提出了异议，谁有保留意见——这些是 PM 会后要跟进的第一手材料
- 把控节奏：如果讨论偏离议程，PM 要温和但坚定（像日本动漫男主一样）地把话题拉回来
第三步：会后跟进
- 在飞书文档里发会议纪要，包括确认的目标、分工安排、后续行动项（Action Item 都要标注负责人和截止时间）
- 对会上提出的异议和顾虑，PM 私下一一跟进
很多团队反感开会，不是因为会议本身，而是因为开完会没有任何结论。Kick Off 开得好不好，就看团队成员出会场时是不是清楚地知道自己要做什么、谁对他的工作负责。
会前必做的功课：很多技术人员出身的PM容易忽略一点——你不能等kick off会上才开始了解项目。
你需要在会前就搞清楚：这个项目为什么存在？要做到什么程度？资源从哪里来？
会前做好功课，才能在会上有底气主持讨论，而不是被有资历的老东西们牵着鼻子走。
第一章小结
恭喜你，完成了项目经理的第一步，项目启动。
在《PMBOK 第六版》中，定义了 5 大过程组、 10 大知识领域、49大管理过程。
横轴为过程组，纵轴为知识领域，中间表格为管理过程：
| 十大知识领域 | 启动过程组 | 规划过程组 | 执行过程组 | 监控过程组 | 收尾过程组 |
|---|---|---|---|---|---|
| 项目整合管理 | 制定项目章程 | 制定项目管理计划 | 指导与管理项目工作 管理项目知识 | 监控项目工作 实施整体变更控制 | 结束项目或阶段 |
| 项目范围管理 | 规划范围管理 收集需求 定义范围 创建WBS | 确认范围 控制范围 | |||
| 项目进度管理 | 规划进度管理 定义活动 排列活动顺序 估算活动持续时间 制定进度计划 | 控制进度 | |||
| 项目成本管理 | 规划成本管理 估算成本 制定预算 | 控制成本 | |||
| 项目质量管理 | 规划质量管理 | 管理质量 | 控制质量 | ||
| 项目资源管理 | 规划资源管理 估算活动资源 | 获取资源 建设团队 管理团队 | 控制资源 | ||
| 项目沟通管理 | 规划沟通管理 | 管理沟通 | 监督沟通 | ||
| 项目风险管理 | 规划风险管理 识别风险 实施定性风险分析 实施定量风险分析 规划风险应对 | 实施风险应对 | 监督风险 | ||
| 项目采购管理 | 规划采购管理 | 实施采购 | 控制采购 | ||
| 干系人管理 | 识别干系人 | 规划干系人参与 | 管理干系人参与 | 监督干系人参与 |
本章我们主要讲的主要是第一列，启动过程组，包括它下属的**"制定项目章程"和"识别干系人"。**
但你也肯定也发现了，第一章叫做"项目启动"，而不是"启动过程组"。
因为在第一章中我还加入了一些其他部分的内容，比如：
- 干系人沟通策略 - 规划过程组 - 规划沟通管理
- 权力-利益矩阵 - 规划过程组 - 规划相关方
- 项目启动会 - 有说属于启动过程组的、有说属于规划过程组的
项目管理的过程和方法，不是一个固定流程，它是自由的、交叉的。
各个管理过程之间是有交集的，可能是并行的。
要根据你的项目的实际情况进行裁剪和调整。
所以在后面的文章中，我也不会严格按照《PMBOK 第六版》所划分的过程组和知识领域的顺序来讲解。
而是以相对更适合项目的流程和方式来展开后续内容。
第一章知识地图：
flowchart TB
subgraph "启动阶段核心产出"
PC[项目章程<br/>Project Charter]
SR[干系人登记册<br/>Stakeholder Register]
KOC[Kick Off 会议]
end
subgraph "关键工具"
PM[权力-利益矩阵]
RACI[责任分配矩阵]
end
subgraph "沟通方式"
FC[正式沟通<br/>会议/邮件/周报]
IC[非正式沟通<br/>吃饭/私聊/偶遇]
end
PC --> PM
SR --> PM
KOC --> FC
PC --> KOC
SR --> KOC
style PC fill:#87CEEB
style SR fill:#90EE90
style KOC fill:#F0E68C
style PM fill:#DDA0DD
