企业官网建设流程全解析

带了几次项目之后，我越来越觉得“项目管理10大知识领域及5大过程”这套框架不是用来背的，而是用来“校准”的。刚入行的时候，我把49个过程背得滚瓜烂熟，真上了项目还是手忙脚乱。后来才慢慢明白，这两套东西一个管横向的时间推进，一个管纵向的能力覆盖，交叉起来才是一张完整的工作地图。这篇文章把我这些年的实操体会整理出来，重点讲框架怎么用、坑在哪里，适合刚做项目经理的朋友，也适合那些背过框架但一直没有“用起来”的同行一起交流。

1. 究竟是什么让这两套框架如此重要

很多人第一次接触项目管理，最先听到的就是这两组数字：5大过程组和10大知识领域。如果把项目管理者成一次长途驾驶，那过程组就是你要走过的路段——出发、上高速、行驶、随时看仪表盘、最后进服务区停车；知识领域就是车上各个仪表对应的专业能力——油门怎么控制、刹车怎么踩、油量还剩多少、导航怎么规划路线。两者缺一个，车都开不稳。

1.1 两套框架就像坐标系

5大过程组解决的是“项目从生到死要经历哪些阶段”的问题，它是一条时间线；10大知识领域解决的是“每个阶段里项目经理要具备哪些专业能力”的问题，它是一条能力线。两条线交叉，形成了一张网格。

项目启动的时候，你需要制定项目章程，这是整合管理在启动过程组里的过程；规划的时候，你需要创建WBS，这是范围管理在规划过程组里的过程；执行的时候，你要管理团队，这是资源管理在执行过程组里的过程；监控的时候，你要控制进度、控制成本、控制风险；收尾的时候，你要结束项目或阶段，做经验教训总结。

每个具体的动作，都能在这张网格里找到自己的位置。这个“定位”的能力特别重要，因为项目出了问题的时候，你最需要做的不是慌，而是快速判断问题属于哪个知识领域、发生在哪个过程阶段，然后去找对应的解决工具。没有这套框架，你只能凭感觉东撞西撞，运气好能救回来，运气不好整个项目就烂在手里。

1.2 这套框架解决的三个现实痛点

我自己的体会是，这套框架本质上在解决三个特别现实的痛点。

第一个痛点是“边界模糊”。很多项目做到一半，需求越加越多，时间越拖越长，钱越花越超，最后变成一个无底洞。范围管理、进度管理、成本管理就是用来给项目划定边界、建立基线、控制变更的。

第二个痛点是“角色混乱”。项目里经常有人问“这事到底谁负责”“为什么没人告诉我那个决定”“资源被别的项目抢走了怎么办”。干系人管理、沟通管理、资源管理就是用来理顺人和事的关系的。

第三个痛点是“事后救火”。很多事情等到发生才去处理，比如服务器宕机了才想起没有备份，验收前才发现文档缺了一大堆。风险管理、质量管理、采购管理就是用来把这些事前置，让问题在发生之前就被识别和消化掉。

这三个痛点几乎所有项目都会遇到，而这两套框架恰恰就是针对这些问题设计的解题工具箱。理解到这一层，再去看那几十个过程，就不会觉得它们只是纸面文章了。

2. 五大过程组：项目从生到死的横向轨迹

五大过程组是项目管理的骨架，它告诉你在项目生命周期的每一个阶段，你都应该做哪些类型的工作。这里要注意的是，“过程组”不等于“阶段”。阶段是按时间划分的，过程组是可以反复出现的。比如一个迭代开发的项目，一个迭代里可能就会完整地跑一遍规划、执行、监控的循环。

2.1 启动过程组：给项目一个合法身份

启动过程组是整个项目的第一棒，核心任务有两件：一是明确项目目标和关键约束，二是识别主要干系人并获得项目的正式授权。

这里最典型的产物是项目章程。很多内部项目根本不写章程，领导口头说“你去做个系统吧”就开始干了。这样做风险很大，因为没有章程，项目就没有正式身份，没有正式身份，你就没有调配资源的权责。等你要人、要钱、要时间的时候，你会发现谁都可以拒绝你，因为你的项目在制度层面根本不存在。

我见过太多内部项目死于“没有启动这一步”——项目做了一半，业务部门不认了，说“我们当时说的不是这样”，但你拿不出任何成文的东西来证明当初约定的范围。所以哪怕内部小项目，也至少花半天时间写一页纸的项目章程，把目标、范围、关键干系人、初步里程碑和约束条件列清楚，让相关负责人签字确认。这不是形式主义，这是给你的项目买一份“身份保险”。

2.2 规划过程组：花最多精力的一步

规划过程组是整个框架里最庞大的一块，10大知识领域里有超过一半的过程都发生在规划阶段。这是有道理的，因为规划阶段的一个错误，可能到执行阶段要花十倍的代价才能纠正。

规划过程组的核心工作是制定项目管理计划，以及各知识领域的子计划：范围基准、进度基准、成本基准，还有风险登记册、沟通计划、资源计划、采购计划、干系人参与计划等等。这里的重点是，规划不能只有大方向，要具体到可执行的颗粒度，比如WBS要分解到工作包，进度要排到具体的时间节点，风险要列出应对策略。

但我必须提醒一句：不要试图在项目一开始就把所有计划做到完美。规划本身是一个渐进明细的过程，一开始信息不足，计划粗糙一些是正常的，随着项目推进不断细化迭代才是对的。有些新手项目经理花了两个月做一份非常完美的计划，结果一执行就发现现实完全不是那么回事，这种完美主义反而是低效的。好的规划是“足够好的规划”，是能给团队一个清晰的方向和节奏，而不是一份永远不会被看一眼的厚文档。

2.3 执行过程组：项目经理不是干活的人

执行过程组是把计划转化为实际成果的过程，这个阶段会消耗项目的大部分时间和资源。很多人对执行有一个误解，以为项目经理应该冲在最前面，事必躬亲。实际上，项目经理的执行工作不是自己干活，而是带着团队干活——指导、协调、推动、解决障碍。

执行过程组里发生的事情包括：组建和管理团队、开展团队建设活动、执行质量保证、实施风险应对、管理干系人参与、执行采购中的招投标和合同管理等等。项目经理在这个阶段更像是“催化者”，让团队能够高效地把活儿干出来。

我最早带项目的时候特别容易犯一个毛病：看到前端有bug自己上手改，看到后端接口慢自己去调，一天到晚像个救火队员。后来我发现，这样做不仅自己累死，团队也没成长，项目进度反而更慢。正确的做法是，把这些具体的问题交给合适的人，你的工作是搞清楚为什么会出现这些问题、怎么从流程上避免它们再次出现，以及怎么帮团队扫清障碍。

2.4 监控过程组：让偏差暴露在阳光下

监控过程组和执行过程组是并行的，从项目启动以后，监控工作就一直在进行。监控的核心是收集绩效数据，把实际结果和计划基准做对比，发现偏差之后进行分析和调整。

这里不能不提挣值管理。很多项目的周报里写“进度完成80%”，但如果问这个80%是怎么算出来的，很少有人能说清楚。挣值管理用计划价值、挣值和实际成本三个数据算出进度偏差和成本偏差，这样你就知道项目到底是真快了还是假快了，是真省钱了还是假省钱了。

监控过程组还包括变更控制。这不是说所有变更都不能做，而是说变更要经过评估、审批、记录的过程，要搞清楚变更带来的影响是什么、成本增加多少、工期延后多久、风险有没有变化，然后由相关人员做决策。最怕的是口头变更——业务方说“加个小功能而已”，开发就顺手做了，做完才发现不仅占用了时间，还改变了原有的接口逻辑，后期维护成本大增。所有变更都必须落到纸面上，这条纪律不能松。

2.5 收尾过程组：正经地和项目说再见

收尾过程组往往被低估，尤其在很多“上线即结束”的项目里。但收尾绝不是简单的开会庆祝，它包含验收交付、合同收尾、财务结算、文档归档、经验教训总结和资源释放。

我见过一个项目，系统上线半年了，验收报告还没签出来，尾款没收，代码文档散落在各个开发者的电脑里，新来的同事根本不知道系统是怎么搭的。后来那个团队重新做了一轮知识梳理，花了整整两周时间才把文档补齐。这就是不重视收尾的代价——省了收尾那几天，赔上后面几个星期。

收尾阶段还要做一件事：经验教训总结。这个动作看起来虚，实际上很有价值。项目里哪些做法有效、哪些环节出了问题、哪些工具值得继续用、哪些流程需要优化，都值得记录下来。没有这个动作，每个新项目都会重复犯同样的错误，组织的项目管理能力就永远是原地踏步。

3. 十大知识领域逐个拆解：项目经理的纵向能力地图

如果说过程组是项目的骨架，知识领域就是项目经理的肌肉。每一项都对应着一种专业能力，缺了哪一块，项目都会在某个角落里出问题。下面逐个拆解，包括我个人的实操体会。

3.1 项目整合管理：所有工作的中枢

项目整合管理是10个知识领域里最特殊的一个，它是唯一一个覆盖全部5个过程组的知识领域。制定章程、制定项目管理计划、指导和管理项目工作、监控项目工作、实施整体变更控制、结束项目或阶段，这些过程都是从全局视角来协调各个领域的工作。

整合管理的核心是“取与舍”的平衡。范围增加了，进度往往要延后；成本压缩了，质量可能受影响；风险规避了，可能要花更多钱。项目经理就是那个坐在平衡木中间的人，要在各个竞争性需求之间做出取舍，并且保证所有决策都记录在案。

我个人的经验是，整合管理最考验项目经理的判断力和沟通能力。你必须对项目的全貌有清晰的把握，知道每一个领域目前的状况是什么，才能做出合理的整体决策。很多项目经理说自己忙，其实忙的都是具体事务性工作，真正需要思考的整合性问题反而没有时间想。我的建议是，每周至少留出半天时间，不处理具体事务，专门用来思考和梳理项目的整体状况。

3.2 项目范围管理：守住项目的边界

范围管理回答的问题是“项目做什么和不做什么”。它包含规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围这些过程。

范围管理的核心工具是WBS工作分解结构，它的作用是把大的交付物逐层分解成小的、可管理的工作包。一份好的WBS有几个特点：层次清晰、每个工作包都有明确的交付成果、没有遗漏也没有重复。WBS的好处是让所有人都能用同一张图来看项目的全貌和进度。

范围管理最大的敌人是“镀金”和“需求蔓延”。镀金是开发人员自己发挥，觉得“加个这个功能更酷”；需求蔓延是干系人不断提新需求，而项目组没有有效控制。这两种情况都会悄悄扩大项目的实际工作量，最后反映在进度和成本上。要守住范围，除了靠清晰的WBS和范围基准，还要靠一套严格的变更控制流程，让每一次范围变更都被正确地评估和记录。

3.3 项目进度管理：关键路径才是命门

进度管理回答的问题是“项目要多久做完”。它包含规划进度管理、定义活动、排列活动顺序、估算活动持续时间、制定进度计划和控制进度这些过程。

这里最值得深入理解的是关键路径法。一个项目网络图里会有很多条活动路径，其中最长的那条路径就是关键路径，它决定了项目的最早完工时间。关键路径上有任何一个活动延误，整个项目就会延误；反过来，只有压缩关键路径上的活动，才能缩短项目工期。

我刚学进度管理时，觉得排进度就是画一画甘特图。后来才知道，甘特图只是展示工具，真正的核心是活动之间的依赖关系和关键路径。有一次项目延期，我只看甘特图怎么也想不明白为什么明明提前完成了几个任务，总工期还是拖了。后来画了网络图才发现，我提前完成的那几个活动根本不在关键路径上，关键路径上一个活动因为依赖关系被阻塞了，整个项目都被卡住。从那以后，我每次排计划都先把网络图和关键路径画出来，再去画甘特图。

3.4 项目成本管理：从预算到挣值

成本管理回答的问题是“项目要花多少钱”。它包含规划成本管理、估算成本、制定预算和控制成本这些过程。

成本估算有几种常用方法：类比估算、参数估算、自下而上估算和三点估算。类比估算就是拿以往相似项目的成本做参照；参数估算用历史数据和统计关系来推算，比如每平米建造成本乘以面积；自下而上估算先把每个工作包的成本加总再汇总；三点估算则用最乐观、最可能、最悲观三个值来加权平均减少不确定性。

在小项目里，成本管理可以做得轻量一点，先做好预算跟踪表和成本偏差记录就够了。但是项目一旦上规模，就必须引入挣值管理，否则你很难回答“钱花到哪里去了”“花了这么多钱值不值”这类问题。我记得第一次做挣值分析的时候，算出来的三个指标都很难看，但正是因为这组数字，才让我下决心去找成本失控的真正原因。后来我发现大多数成本失控不是花钱太猛，而是范围蔓延和执行效率太低造成的。

3.5 项目质量管理：质量是规划出来的

质量管理包含规划质量管理、管理质量（质量保证）和控制质量（质量控制）这些过程。很多人以为质量管理就是测试、就是质检，其实那只是质量控制的一部分。质量管理的核心思想是：质量是规划出来的，不是检查出来的。

规划质量管理阶段要明确质量标准和验收标准。标准和验收标准不是一回事，标准是行业或组织的技术规范，验收标准是项目内部对这个交付物的具体接受条件。比如一个数据接口，标准可能是响应时间不超过200毫秒，验收标准可能是实际压测结果至少满足这个要求且连续三天无异常。

管理质量是把质量要求落实到执行的过程中，通过做过程审计、制定质量核对单、开展质量改进活动来预防问题。控制质量才是交付前的那道检验关。这个逻辑放在软件开发里就是：先定好测试规范和覆盖率标准，再做代码评审和持续集成检查，最后才是提测和验收。三者缺一环，质量都会失控。很多项目最后阶段天天加班修bug，本质上是前面几个质量环节没有做到位。

3.6 项目资源管理：有人才能成事

资源管理在早期版本里叫人力资源管理，后来扩展为项目资源管理，因为资源的范围不只是人，还有设备、材料、场地等实物资源。但实操中最重要的还是团队资源。

资源管理包含规划资源管理、估算活动资源、获取资源、建设团队、管理团队和控制资源这些过程。这里有三个动作特别值得展开：一是获取资源，你要能要到人、要到设备，这需要提前预估需求并和相关部门的负责人建立好关系；二是建设团队，通过培训、团队建设活动、明确角色和职责来提升团队的凝聚力和战斗力；三是管理团队，跟踪团队成员的绩效、提供反馈、解决冲突。

资源管理里最容易踩的坑是冲突处理不到位。项目团队里意见不合是常态，关键是不要等到矛盾爆发才介入。我的经验是，及早辨别冲突的类型：技术方案之争应该通过数据验证和评审机制解决；资源分配之争需要项目经理做公正的裁决；人与人之间的摩擦可能需要单独谈话甚至调整分工。不处理就是拖累，处理晚了也会影响团队士气。

3.7 项目沟通管理：信息不会自己流动

沟通管理回答的问题是“谁在什么时候需要什么信息，通过什么方式获得”。它包含规划沟通管理、管理沟通和监督沟通这些过程。

很多人觉得沟通就是“发消息”“开会”，但实际上，沟通管理的核心是“匹配”。不同的干系人需要的信息类型、详细程度、频率都不一样。给决策层汇报要的是结论和风险，给业务方交流要的是进度和功能，给团队下达指令要的是任务和截止时间。一份又长又细的技术周报发给全员看，大部分人根本不会看，这就是沟通失败。

沟通的渠道数量可以用一个公式算：n乘以(n-1)除以2。参与干系人越多，沟通渠道越多，信息失真和遗漏的概率也越大。所以好的沟通管理一定包含清晰的沟通计划——什么人参加什么会、多久开一次会、信息通过什么平台分发、紧急信息怎么传递。特别是会议，外行觉得会越多越好，老手都知道，没有明确目和议程的会根本没有必要开。

3.8 项目风险管理：把不确定性变成确定性的应对

风险管理包含规划风险管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对和监督风险这些过程。这个领域最容易犯的错误是把风险登记册当成“作业”——识别了一堆风险写进表格里，然后就再也不看了。

风险管理的价值不在于那张登记册，而在于“风险应对措施被真正执行了”。识别出风险后，要分出高、中、低优先级。高风险要有明确的风险应对策略，比如规避、转移、减轻或接受，并且要有具体负责人和触发条件。风险评估要有“预警信号”，比如“如果第三方接口连续三次延迟超过两小时，就启动备用方案”。

风险分析和应对还有一个特别容易忽略的点：不要把“风险”和“问题”混为一谈。风险是未来可能发生的不确定事件，问题是已经发生的事实。风险需要通过概率和影响来管理，问题则需要立即解决。我见过很多项目把风险登记册写满了，结果里面一半是已经发生的问题，剩下的风险又没有具体的应对措施，这种东西写了等于没写。

3.9 项目采购管理：外力也是力量

采购管理包含规划采购管理、实施采购和控制采购这些过程。简单说，就是从外部获取产品或服务的过程，包括决定外购还是自制、编制采购文件、选择供应商、签订合同、管理供应商绩效、处理合同变更和结束采购。

对大多数人来说，项目里接触采购的机会可能不多，因为很多公司有专门的采购部门。但作为项目经理，你仍然需要承担几个核心职责：定义采购需求、参与供应商评估、管理供应商交付、核对交付物验收。比如你要外包一个组件模块，你需要写的不是“帮我做一个模块”，而是包含功能规格、性能指标、交付标准、验收条件、里程碑节点和合同条款的采购文件包。

采购管理最容易出的问题是合同双方对验收标准理解不一致。甲方觉得“这个界面颜色不对，不通过验收”，乙方觉得“功能都能跑，为什么不行”。要避免这种扯皮，必须在采购文件里把验收标准写得像技术规格书一样具体，每一项都能量化、可验证。项目再急，这一步都不能省。

3.10 项目干系人管理：会做人比会做事重要

干系人管理包含识别干系人、规划干系人参与、管理干系人参与和监督干系人参与这些过程。干系人就是所有影响项目或受项目影响的个人和组织，比如出资方、业务方、使用用户、团队成员、供应商、监管方等等。

干系人管理的工具有一个很有名：权力/利益矩阵。按“权力高低”和“利益大小”把干系人分成四类：高权力高利益的人要重点管理，经常汇报、争取支持；高权力低利益的人要随时告知，让他们保持满意度；低权力高利益的人要让他们参与，及时反馈；低权力低利益的人只要监控即可，不必花太多精力。

很多技术出身的项目经理会本能地排斥这种“处理关系”的工作，觉得“项目做得好就行，不需要搞关系”。但现实是，项目里最大的风险往往不是技术风险，而是干系人对项目的支持发生了变化。我见过不只一次，项目做到一半，某个关键干系人觉得“这个项目不够重要”，撤回了预算或资源，项目直接停摆。所以干系人管理不是走后门，而是项目管理里实打实的专业能力。

4. 两个维度交叉：一张矩阵看懂49个过程

把5大过程组和10大知识领域放在一起，你会得到一个矩阵。这个过程组和知识领域的交叉点上分布着项目管理里最核心的49个过程，这就是整个项目管理知识体系的结构化表达。

4.1 过程组与知识领域的矩阵关系

每个过程组里都会发生多个知识领域的活动。比如规划过程组里，范围管理要创建WBS，进度管理要排列活动顺序和估算持续时间，成本管理要估算成本和制定预算，风险管理要识别风险并做定性定量分析，沟通管理要做沟通规划，干系人管理要做干系人参与规划。

每个知识领域也不是只在一个过程组里出现。比如范围管理，在规划过程组里定义范围、创建WBS，在监控过程组里做确认范围和控制范围。风险管理也一样，规划阶段要识别和分析，执行阶段要实施应对，监控阶段要盯风险变化。

这个矩阵最大的好处是给你一张“检查清单”。你随时可以问自己：当前阶段，哪些过程我做了，哪些还没做？如果漏了某个过程，对应的风险点在哪里？我第一次带项目时就用这个方法做月度自检，发现有好几个风险登记册里的风险因为实施过程没跟上，根本没有被真正应对。从那张矩阵上看，问题一目了然。

4.2 裁剪思想：49个过程不是默认套餐

可能有人会问：“49个过程这么多，每个项目都要做一遍吗？”答案是不用，也不应该。项目管理知识体系指南里反复强调一个词：裁剪。裁剪就是根据项目的特点，选择适用的过程和工具的深度。

小项目可能只需要十几个核心过程就足够了，比如制定章程、制定计划、创建WBS、监控进度和风险、收尾总结。大型复杂项目才需要完整的49个过程，并且每个过程的做法都要更加精细。裁剪的原则是：项目越复杂、风险越高、干系人越多，需要的过程就越多越深；项目越小越简单，过程可以适当精简。

但裁剪和“不做”是两回事。新手容易犯两个极端：一个极端是照搬全部过程，把项目管理做成写文档大赛；另一个极端是只凭感觉做，什么文档都不留。合理的做法是先保证核心过程做扎实，比如范围、进度、风险、沟通这四个领域的基础过程必须有，其他领域按需取舍。随着经验增加，你自然会形成一套自己的裁剪逻辑。

5. 敏捷时代，这套框架还有用吗

现在很多团队在跑敏捷，特别是软件行业，动不动就是Scrum、看板、迭代，有人就会问：“这套传统框架是不是过时了？”这个问题本身问得不太好，因为它把敏捷和传统框架对立起来了。实际情况是，两者并不是非此即彼的关系。

5.1 传统与敏捷并没有本质冲突

敏捷里依然有规划、执行、评审、回顾，只是这个过程循环变了，变成以迭代为单位反复进行的短循环。5大过程组的精神并没有消失，只是打散了放进每个迭代里。10大知识领域的核心关注点也依然存在，只是做法不一样了。

举个例子，范围管理在传统项目里是通过范围说明书和WBS建立的，在敏捷项目里则是通过产品待办列表来管理——待办事项就是动态调整的范围，每次迭代结束时的评审会就是在做确认范围的工作。风险管理在传统项目里靠风险登记册，在敏捷项目里可能变成了迭代规划时对需求进行的持续风险评估。核心逻辑没变，变的是载体和节奏。

更重要的是，传统框架中很多理论依然可以给敏捷团队提供支撑。比如关键路径法的思想在应对跨团队依赖时依然有用；挣值管理的思路在做大型复杂项目的整体绩效评估时依然有参考价值；干系人管理在敏捷环境下同样重要，甚至更复杂，因为敏捷团队的干系人需要更频繁的参与。

5.2 混合模式正在成为主流

实际项目里，纯粹的传统瀑布或者纯粹的敏捷都不太常见了，更多项目采用的是混合模式。比如框架层用预测型管理，定了明确的范围、进度和预算的里程碑计划，但具体执行层放进迭代里，让开发团队按敏捷的方式来跑。或者在传统的大型IT项目里，关键阶段用里程碑评审来把控，但子模块内部用敏捷迭代来交付。

我参与过一个某跨平台系统的项目，就是典型的混合模式：项目层面有严格的阶段评审、变更控制和里程碑计划，但在每个阶段内部，团队按迭代来开发和交付。这种模式的挑战是，项目经理需要同时掌握传统和敏捷两套工具，并且知道在什么场景下使用哪套工具。这不代表传统框架失效，反而说明传统框架提供的整体性思维——从全局来统筹目标、资源和风险——依然有不可替代的价值。

6. 实操中反复踩过的坑：常见问题速查

这部分我从自己的实操经历出发，挑几个高频出现的问题，做成一个快速排查的参考。如果你在项目里也遇到这些情况，可以照着这个思路去检查。

6.1 五个高频问题与排查思路

第一个问题是需求蔓延。症状很好认：项目范围越来越大，干系人不断提新需求，团队加班越来越多。排查思路是先看范围基准是否明确、变更控制流程是否在起作用。如果你发现很多需求没有走变更评审就进了开发，就要回归到范围管理和变更控制的基本流程，让所有需求变更都按流程走。

第二个问题是进度失控。症状是最初说好三个月上线，结果三个月过去了，项目还在开发中。排查思路是看进度计划里有没有关键路径，关键路径上的任务是否被优先保障。很多项目进度失控的原因是时间都花在非关键路径的任务上，关键任务反而被忽略。项目经理要把注意力放在关键路径上，里程碑设置也要围绕关键路径来设计。

第三个问题是会议多但没有决策。症状是每周开好几次会，每场会都很长，但会上没有明确结论，会后也没有行动项。排查思路是看沟通计划里对不同会议的定位是否清晰。会前有议程、会中有决策、会后有会议纪要，这三点缺一个就变成聊天会。如果会议没有明确要解决的决策问题，干脆取消。

第四个问题是风险登记册形同虚设。症状是风险登记册写得满满当当，但风险发生了没人应对，风险登记册成了“安慰文档”。排查思路是先检查风险是否定期评审，是否真正更新状态，风险应对措施是否被纳入执行和监控流程。风险登记册的关键不在于写，而在于用。我给自己定了个规矩：每次项目例会上必须花五分钟过一遍风险清单，没有更新就说明没有执行。

第五个问题是验收和收尾被无限拖延。症状是系统上线了，但验收报告签不下来，文档一直缺，资源也释放不了。排查思路是看验收标准和文档要求是不是在规划阶段就写清楚了。很多项目收尾困难，本质上是验收标准和交付物的定义被推迟到了最后阶段。要想收尾顺利，就要从规划阶段开始，把“什么样的成果算完成”写清楚。

6.2 执行层面的经验补充

除了上面五个问题，还有几个执行层面的小经验值得提一下。

第一，文档要跟着项目走，不要攒到最后补。项目执行过程中顺手写几句的环境信息、接口说明、决策记录，往往比最后专门花两周补出来的文档更有价值。那些“最后再补文档”的项目，最后通常什么都补不出来。

第二，变更审批的记录要完整保留。不管是客户提的、领导提的还是同事提的变更，只要有影响，就要走变更流程并且保留邮件或系统记录。这些东西到项目后期是保护自己的重要依据，否则出了争议就是口说无凭。

第三，每周花一点时间做“整体性自检”。我养成的习惯是每周五下午把项目当前的进度、成本、风险、范围、干系人状态这五个维度快速过一遍，不需要写很长的报告，脑子里有数就行。这套习惯帮我提前发现了很多潜在问题，很多风险在还没有变成问题之前就被处理掉了。

做项目这些年，我越来越觉得，项目管理10大知识领域及5大过程这套框架不是用来考资格认证的死知识，而是一套值得反复对照的实践经验库。拿它当字典用，遇到问题就去查对应的领域，远比把它整本背下来更有价值。我自己第一次带项目时，根本没用完全部过程，一页纸的章程、一张WBS图、一份风险清单、每周一次的进度核对，撑起了整个项目。后来项目越做越大，我才会越来越依赖这套框架来做整体的协调。所以我的建议很朴素：不要想着一口吃成胖子，先挑其中对你当前项目最有用的三五个过程，把它们做到位，再慢慢扩展。每多做一个项目，你对这套框架的理解就会深一层。