企业官网建设流程全解析

1. 做计划前先想清楚：Project不是拿来画图的

我见过太多项目经理用Project的方式，是先在Excel里把任务理好，然后跑到Project里一行行敲进去，再把时间拖一拖、甘特条拉一拉，导出一张漂亮的横道图往墙上一贴，就认为“进度计划”做完了。

这是对Project最大的误解。Project的核心不是画图，而是一个“带逻辑关系的时间计算引擎”。你输入的不是一张表格，而是一套逻辑：任务之间怎么衔接、资源能投入多少、日历里哪些天能干活、工期按什么方式计算。Project基于这些信息自动算出每项任务的开始和结束时间，再推导出整个项目的关键路径。换句话说，如果你只是把结束日期手动填进去，那你等于自废武功，把Project用成了一个贵得多的Excel。

所以在打开软件之前，先把三件事想清楚。

第一，项目范围。你的WBS到底要拆到什么层级？拆到工作包还是拆到具体活动？我的建议是拆到“能独立分配责任人、能单独估算工期、能明确交付物”的程度就停手，再往下拆就会变成操作步骤，反而让进度计划失去可读性。举个例子，一个系统集成项目，拆到“完成接口联调”就够了，没必要拆到“打开接口文档、配置服务地址、发送测试报文”这种级别。

第二，里程碑。哪些节点是必须向管理层或客户汇报的硬性节点，例如“需求确认完成”“测试通过”“正式上线”。里程碑用“里程碑任务”表示，工期为零，只标记事件发生的时间点。

第三，黑话要统一。任务名称尽量采用“动词+对象+结果”的写法，比如“完成第二期支付模块开发”，而不是模棱两可的“支付模块”。这样将来查进度、写周报、和干系人沟通时才不会鸡同鸭讲。

想清楚这三点再动手建文件，后面会顺利很多。

2. 编制进度计划：从WBS到资源配置

2.1 项目信息和日历：先把“游戏规则”定下来

新建文件之后，第一件事不是录入任务，而是设置项目信息。点击“项目”选项卡里的“项目信息”，在“开始日期”里填上计划开工的日期，“日程排定方法”选“从项目开始之日起”，完成日期让它自动算。很多时候新手在这里犯的错恰好相反——填的是完成日期，然后让Project倒推开工时间。对大多数真实项目来说，客户给的是“某月某日必须上线”，但你做计划时还是应该从开工日期正推排程，这样才能看清楚按现有资源到底能不能按期完成。如果倒推，你会不自觉地把任务压缩，得出一个理论上成立、现实中根本干不完的虚假计划。

接着是日历。日历决定了项目里“能干活的时间”。Project默认给的是“标准”日历，周一到周五8点到17点工作，中午12点到13点休息。如果你的实际工作节奏是“做五休二”，可以直接用；如果是排班制、夜班制、一周六天，就得新建日历。操作路径：“项目”→“更改工作时间”→“创建新日历”。这里有个非常实用的细节：日历里不仅要把法定节假日标为“非工作时间”，还要把每年固定的检修日、封网日、全员大会这类必然不干活的日子提前标好。不要等进度计划做完再回头改日历，那样所有任务时间全部要重新算一遍，而且很容易出现“明明上周放假，任务却还在推进”的怪象。

日历有三层：项目日历、任务日历、资源日历。如果你给某个任务单独指定了任务日历，那么任务按任务日历计算；你给某个人分配了资源且该资源绑定了专属日历，资源日历会覆盖项目日历。新手建议先只用项目日历，把逻辑搞清楚再逐步引入后两层，否则一旦日期算出来对不上，你自己都说不清是按哪套日历算的。

2.2 任务清单和层级：WBS的结构化落地

在第一列“任务名称”里录入完整WBS，这一步不用管时间。本质是把“干活清单”摆出来，形成树状结构：摘要任务负责汇总，子任务负责具体执行。

录入时建议从上往下按大纲级别写，写完再统一调整缩进。选中目标任务，点“缩进任务”按钮（向右箭头图标），它就变成上一级任务的子任务。缩进之后，左侧会自动出现“摘要任务”行，用粗体显示，它的起止时间是所有子任务中最早的开始时间和最晚的完成时间，工期不是子任务工期的简单求和，而是根据子任务的排布逻辑算出来的。

这里有个关键设定：摘要任务的工期和开始/完成时间不要手动改。手动改摘要任务的日期，Project会弹出提示“该操作将导致任务无法摘要”，这时候你基本已经把一个好端端的逻辑计划搞坏了。正确的做法是只维护最底层子任务，摘要任务全部由系统自动汇总。

还有一个新手容易懵的列——“任务模式”，默认写着“自动计划”或“手动计划”。手动计划的意思是，你填什么时间就是什么时间，Project不帮你算；自动计划的意思是，Project根据依赖关系、日历、资源投入自动推算时间。这两者混在一个计划里，非常容易让逻辑混乱。我建议把全部任务切换到“自动计划”模式。手动模式只适合在思路还没理顺时临时记点子，正式排程必须切到自动计划。

2.3 依赖关系：把任务之间的“顺序逻辑”讲清楚

我见过有人排计划时，任务顺序靠“行号从上到下”来体现，时间则手填。这样一旦某项任务延期，后面所有任务都不会自动跟着延，整个计划很快就失去了参考意义。

真正让Project“活”起来的是前置任务（依赖关系）。双击任务行，在“前置任务”标签页里，把“任务名称”和“类型”选好。Project支持四种依赖类型：

默认是FS，需要延后几天则在“延隔时间”里填。例如“FS+3”表示前置任务完成后3天，后续任务才能开始。

这里我要特别强调一下前置依赖和“硬逻辑”的区别。写代码之前必须先做需求分析，这是硬逻辑，必须设依赖关系；“我想让设计晚两周再开始”，这不是依赖关系，是“限制条件”或资源调配问题，不要靠加依赖实现。新手最常见的操作是把所有任务之间全部用FS串起来，串成一条“一根绳上吊着的计划”。这样做虽然日期会自动联动，但风险是：任何一项延期都会顺延后面所有任务，关键路径上的判断完全失真。正确的思路是只给“逻辑上必须先后发生”的任务建立依赖，能在同一条时间线上并行推进的任务就让它并行。

说到限制条件，默认情况下任务时间是项目自动算的。如果某个任务必须不早于某个时间开始，或者是必须某天开始，可以双击任务→“高级”→“限制类型”，选“不得早于…开始”。但注意，限制条件过多会变成“手写计划”，Project的自动计算能力会被架空，所以能用依赖解决的不要上限制。

2.4 资源分配和工期计算：理解“人”对计划的影响

资源是Project里最容易被忽视又最能体现价值的部分。资源分三类：工时资源（人）、材料资源（钢材、服务器）、成本资源（差旅费）。进度计划里最重要的是工时资源。

选中任务后在“资源名称”列分配人员。默认情况下，一个人分配到一个任务上，投入比例是100%，此时如果一个任务工期10天，一个人干就是10天，两个人分配上去，Project默认会把工期压缩为5天——注意，这是默认的“资源驱动”逻辑。

这里就要讲到Project的三种任务类型，这是许多人从入门到放弃的真正门槛：

固定单位：资源数量固定，加资源会缩短工期，比如“两个人并行搬砖”。 固定工期：工期固定，加资源不会改变工期，比如“混凝土养护28天”，你派一百个人去守着，也不能让养护提前结束。 固定工时：总工作量固定，加人会缩短工期，这类任务的典型是“写标书”，总工作量就那么多，人多就分摊得快。

默认情况下任务类型是“固定单位”，这意味着你往任务上添加资源时，工期会变短。如果你不想让它变短，而是要录入一条“固定工期”的任务，必须在“任务类型”里手动切换，或取消勾选“投入比导向”。这个知识点极其重要——我见过有人分配5个人下去，工期莫名其妙从30天变成了6天，还以为是软件坏了。实际上是任务的默认计算逻辑在起作用。

分配资源时还要关注“最大单位”（资源日历里设置的“可用工作时间占比”，默认100%）。如果某个人同时在多个任务上被分配了超过100%的工作量，Project会在资源名称旁显示红色小人图标，表示“过度分配”。这条信息对排期非常有用：看到红人出现，要么错开时间，要么调整任务顺序，否则计划排出来也是空中楼阁。

还有一个实用经验：工期估算要保留“缓冲”的余地，但不要叫它“Buff”，在Project里给它起名“应急储备”，单独一行任务或者放在关键路径的末尾，并明确写明“不做战斗性使用”。这样做的好处是管理层看到的是真实工期，又不会在排期中把所有任务都排得紧巴巴的。

2.5 关键路径：一眼看出项目“命门”在哪里

在Project里，关键路径是决定整个项目最短完成时间的那一串任务链。项目经理的注意力应该放在关键路径上：这条路径上的任务任何一项延期，项目整体完成时间就延期。

查看方式：把视图切到“跟踪甘特图”，然后在“格式”→“文本样式”里把关键任务高亮显示。或者更简单，在“格式”选项卡下找到“关键任务”复选框，把关键任务显示成红色甘特条。

确认关键路径后要做的不是撒花庆祝，而是检查关键路径是否合理。如果关键路径上全是“文档编写”“材料报审”这类弹性大的事情，说明计划本身的逻辑值得商榷。通常关键路径应该会经过真正的技术硬骨头，比如开发、测试、集成、部署这一串。如果关键路径意外地短或者全落在辅助性任务上，大概率是依赖关系设置出了问题。

3. 保存基准：把“计划”锁定成“参照物”

3.1 为什么必须保存基准

很多团队做了计划后就再也不看原计划了，每周汇报时拿“当前排期”说事，永远“看起来一切正常”。直到有一天项目延期三个月，才发现谁也说不清楚延期到底是从哪一天开始、因什么任务产生的。

保存基准（Baseline）本质上就是“给计划拍一张定格照片”。它把任务的人工时、开始时间、完成时间、成本和工期等关键值保存为一个版本，存到字段里（基线开始时间、基线完成时间、基线工期等），以后算法再变，基准值也不动。之后你在每周更新实际进度时，Project会把你更新后的“当前计划”和保存在基准里的“原计划”并排对比，你就能看到哪些任务延后了、哪些提前了、哪些成本超支了。这套对比逻辑，才是“项目进度控制”的真正抓手。

在企业里，基准还有个管理意义：它是绩效考核和变更控制的依据。客户或老板说“怎么延期了”，你拿基准对比表出来，清清楚楚地告诉他“当初基准计划3月10日生产环境上线，因为硬件采购确认延迟了两周，同时第三方登录接口的联调比预期多了5天，所以总工期延后了”。有数据支撑的延期说明，和一句“进度有点跟不上”是完全不同的职业形象。

3.2 保存基准的操作与时机

保存基准的操作本身极其简单：“项目”选项卡→“设置基准”→“设置基准”，在弹出的窗口里选择“完整项目”或“选定任务”，确定即可。

但真正难的是“什么时候按下去”。我见过有人刚把计划排完就立刻保存基准，过了两天计划调整了一下又重新保存，一周重复操作四五次。基准不是这么用的，基准的保存时机应该是：

计划已经稳定，所有干系人确认过，资源分配已达成一致，项目正式启动之前。从那以后，除非发生重大变更（例如范围调整、里程碑时间变动），否则不要覆盖基准。

如果项目执行中确实发生了必须调整计划的重大变更，也请不要直接覆盖原始基准。正确做法是保存“第2个基准”（Baseline2）、“第3个基准”（Baseline3），保留历史演进轨迹。Project支持多达11个基准（Baseline0到Baseline10），多个基准放在字段里互不干扰。阶段性的里程碑变化可以存“中期计划”（Start/Finish计划字段），但常规的做法是多存一个基准版本。

关于保存范围，分两种情况：首次启动时选择“完整项目”，把整个项目保存下来；如果项目中途新增了阶段任务，只想为新增的部分建立基准，则选中该部分任务，选择“选定任务”。但是要特别注意，“选定任务”模式下，所选任务的摘要行和关联任务不会自动带出基准值，极容易产生“部分任务有基准、部分任务没有基准”的碎片化问题，所以除非你很清楚自己在干什么，否则完整项目仍然是首选。

3.3 更新进度和对比差异：让基准真正发挥价值

保存了基准不执行，等于没保存。执行阶段，每周（或按公司要求的频率）更新一次实际进度，是最起码的职业习惯。

更新进度时注意几个字段：

实际开始时间：任务真正开始干了，才填，别提前填。 实际完成时间：任务真正做完了才填。 完成百分比：这个字段要诚实。我亲眼见过有人项目做到一半，所有任务的完成百分比全是100%，被追问时支支吾吾。完成百分比的基准不是“任务列表里能打勾就算完”，而是“交付物通过验收”。 实际工期：如果一项任务原计划10天，实际上干了14天，要如实填写实际工期。

操作方式有两种：一是在甘特图右侧拖动甘特条；另一种更推荐的方式是在“跟踪”功能区点击“更新任务”，在对话框里填“实际开始”“实际完成”“实际工期”。或者在“任务”选项卡→“标记为完成”/“完成百分比”里快速更新。两种方式结合使用，原则上要采用“实际开始时间+当前日期+完成百分比”的模式，让Project自动计算剩余工期，除非你有明确理由，否则不要手工去改“剩余工期”列——这也是新手挖坑最多的地方。

更新完成后，把视图切成“差异”视图，你会看到表格区域多出两列：“开始时间”和“完成时间”旁边是“基线开始时间”和“基线完成时间”，差距一览无余。摘要任务行同样有差异数据，可以快速看出整个项目相对基准提前或滞后的天数。

另一个很直观的视图是“跟踪甘特图”：甘特条上方的黑色粗条是基准计划，下方彩色条是当前实际进度，两条条错开多少，延期就有多明显。我对团队成员说，“别听口头说进度正常，把跟踪甘特图打开，一条条对清楚”。这种习惯一旦养成，进度水分会少很多。

3.4 保存基准的几个“反直觉”问题

第一，保存基准时，Project会默认把“当前计划”的值复制到基线字段。如果你已经修改过计划（比如延期了），此时保存基准，保存进来的其实是“修改后的值”，而不是最初那份计划的值。所以在基准已存在的情况下，再点“设置基准”时一定要看清：你要覆盖的是Baseline1还是新建Baseline2？要不要把“选定任务”的范围选对？

第二，保存基准和手动计划模式有冲突。如果任务处于手动计划模式，它的时间本来就不是Project算出来的，保存基准会存进一个“你自己拍脑袋定的时间”，将来对比时完全没有逻辑。所以我在2.2里强调的“全部切自动计划”，在保存基准时也是同样的理由。

第三，项目中途加进来的新任务不会自动有基线数据。如果新增任务，必须重新设置基准（选定该任务），或者手动把基线字段填好，否则新增任务的“基线开始时间”是空白，差异视图里会出现一条没有参照的奇异记录。

第四，资源成本信息，如果你在计划里录入了资源费率，保存基准时成本基线也会一并存下。执行过程中一旦发生加班、更换人员、材料涨价，成本差异也会自动浮出水面。这就是为什么我建议从一开始就用资源分配的方式去排任务，而不是把所有人名写在同一个任务的备注里。

4. 常见问题排查与避坑实录

4.1 工期和日期“不听话”怎么整顿

最典型的问题是“我填了开始日期，完成日期怎么不是我想要的？”先确认一下任务模式是不是“自动计划”。很多时候是任务碰巧还是“手动计划”——它只记录了你填的日期，不做任何计算。切换到自动计划再敲一遍结束时间即可恢复计算逻辑。

第二个高频问题：任务明明是10月1日开始，怎么甘特条硬生生落到了10月8日？这要查两个地方：一是日历，你当前用的“项目日历”里10月1日到7日是不是标成了“非工作时间”；二是“任务限制”里有没有拖后腿的限制条件，例如“不得早于…开始”限制会让任务起点被拴住。检查方式：双击任务→“高级”→“限制类型”，把不合理的限制改成“越早越好”（或“尽可能早”）。

第三个问题是“为什么我改了任务的工期，实际完成时间反而不变？”这是因为任务可能被“资源驱动”了：你加资源，工期变短；改工期，资源投入变化。如果你压根不想要这种关联，把工期输入框旁边的计算器图标点开，任务类型选“固定工期”，或取消“投入比导向”，再改，逻辑就按你的想法来了。

4.2 摘要任务日期错乱怎么办

摘要任务经常出现“子任务明明是10月15日到11月10日，摘要却显示10月20日到11月2日”这种离谱情况。先说结论：摘要任务的起止时间是“所有子任务最早开始”和“所有子任务最晚完成”的集合，不是看起来的“算术平均”。

但我发现很多人出问题是出在“子任务根本没有形成有效依赖”，只是凭先后顺序排列在列表里。例如任务A排在表格第二行，任务B排在第三行，但两者之间没有设置前置任务关系。若不设置依赖，Project会默认它们都能在项目开始日并行开工——这便是摘要任务日期比预期跨度大的原因。此时先检查B的前置任务是否为A；如果列表关系太乱，可以用“大纲”视图里的“任务路径”功能，高亮显示选中任务的前导和后继任务，排查逻辑断点比肉眼看甘特图快得多。

另外，摘要任务行上的“手动计划”图标非常常见。我常对用户说：摘要任务永远没必要改成自动计划，因为它本身就是个“计算器”，你手动填日期反而是自找麻烦。

4.3 保存基准时不小心把旧基准覆盖了

这个错误造成的损失相当巨大，而且往往要隔一周才被察觉：计划执行了几周，发现“基线开始时间”全部变了，原计划完全消失。

解决方法是事前防护——永远以“第二个基准”作为新增版本，而不是直接覆盖第1个基准。设置基准窗口里可以选择“基线2、基线3”，下拉列表一目了然。如果你想保险一点，看一眼“设置基准”窗口里当前选中是哪个基准，确认无误再点确定。

万一真的覆盖了，也不是完全没救，但要看你的环境有没有启用“复原”或者Project有没有开启“项目服务器版本控制”。本地文件建议关掉自动保存这个功能吗？非也，反而是建议在操作基准这类“不可逆动作”前，先“文件→另存为”备份一份副本。我在教团队时定下规矩：任何一次保存基准前，必须先把当前文件另存为“项目名_备份_日期.mpp”。这个习惯保证即使误覆盖，也可以从备份文件里找到旧基准，再复制过来还原。

4.4 其他常见小坑清单

5. 从单机操作到项目管理习惯

Project用得好不好，工具掌握程度只占一半，另一半取决于你对“计划—跟踪—纠偏”这件事是否形成纪律。

我在项目里推的节奏是：启动阶段集中一周把WBS、日历、资源、依赖全部排完，评审通过后保存基准；进入执行期后每周五下午固定花半小时更新实际进度，再花十分钟看差异视图，对照基准找偏差；一旦出现偏差，先判断是不是关键路径上的任务——不是关键路径上的偏差，只要不影响后续逻辑，可以记录但不惊慌；是关键路径上的拖延，立刻做“赶工”或“快速跟进”的推演，用Project把加班资源或并行方案模拟一遍再决策。这套循环看起来不复杂，但坚持三个月，项目健康度会明显好于光开会不量化。

还要强调一点：基准和进度计划不是一锤子买卖。大型项目每隔一段时间（比如里程碑结束时）可以做一次“计划重排”，用新基线记录变更后的计划，旧基线保留历史轨迹。这样最终复盘时，你很清楚项目延期总量是多少，其中多少由范围变化引起，多少由执行不力引起，多少由外部依赖延迟引起。没有基线，这些数字永远是一笔糊涂账。

我觉得Project最值得佩服的地方，是它把“计划”这种偏感性的东西硬生生变成了“可计算、可对比、可追责”的对象。工具本身不性感，性感的是用这种确定性的思维方式管理项目中的不确定性。希望这篇文章能帮你建立起一套从排计划到锁基准的标准化动作，少走一些我当年趟过的坑。

下一期我打算专门聊聊进度跟踪和“赶工、快速跟进”这两种纠偏策略在Project里的实现细节，欢迎带着你实际项目中遇到的问题来继续看。