用过Project做项目计划的人大概率都有过这样的经历刚从Excel跳到Project时第一反应是这不就是个能画甘特图的表格吗真把几十条任务敲进去之后又发现这个工具经常不听话——工期会自动跑偏、资源出现红色小人、领导问进度时根本拿不出一份像样的对比数据。这篇是如何有效使用Project系列的第一篇重点就两件事怎么把一份可执行的进度计划编出来以及怎么在开始执行前把基准Baseline保存好。为什么这两件事要放在一起讲因为没保存基准的计划等于没有锚点的船过两周再打开文件根本说不清当初答应的是什么。这篇内容适合正在用Project做项目排期、却总觉得哪里不对的项目经理、计划工程师和PMO人员也适合刚接手Project、被各种菜单绕晕的新手。1. 先想清楚Project解决的是计划失控问题很多人在Project里碰壁不是因为软件学不会而是没弄明白为什么要用这个工具。我见过不少项目经理拿Project当高级Excel用把任务名、工期、负责人打进去就完事甘特图一拉看着挺像样等开工之后全乱套。乱在哪任务一改后面全不动资源冲突没人发现说要跟踪进度结果拿不出任何可以对比的基线数据。这些问题恰恰是Project存在的原因。1.1 从Excel表格到Project分水岭在哪里Excel做计划有一个本质问题单元格之间没有逻辑关系。你列了需求评审和开发编码两行Excel不知道编码必须等评审结束才能开始更不会因为你调整了评审日期而自动推算后续任务的起止时间。Project的核心是数据模型每个任务都有工期、开始时间、完成时间通过前置任务把任务之间连成网络。一动牵全局这才是进度计划该有的样子。拿一个很常见的场景举例。研发团队排了20个开发任务其中5个要依赖前端接口而前端接口又依赖架构方案的确认。如果这层关系在Project里没有建立一旦架构方案晚一周确认计划文件里看不出任何影响但实际项目已经延期了。Project的意义就是把这个连锁反应在计划阶段提前暴露出来而不是让项目经理靠开会去人肉发现。1.2 Project真正擅长的三件事联动、约束、追踪搞清楚Project的核心能力后面上手会快很多。第一是联动也就是任务之间的依赖关系前置任务一动后续任务的日期全部自动重算。第二是约束它能在计划里固化一些死条件比如会议召开日期不能早于××日、设备到场不能晚于××日让计划不只是流水账。第三是追踪保存基准后Project能自动生成计划 vs 实际的对比数据哪个任务超前、哪个任务滞后、整个项目偏差多少百分比一目了然。这三个能力对应的操作并不复杂但很多教程把它们拆成一节一节单独讲读者学完还是不知道组合起来怎么用。所以这一篇我不按功能菜单走而是按照从零编出一份能落地的计划、然后存好基准这个完整流程来讲每一步都说明为什么这么做。2. 编制进度计划的完整操作链路从WBS到甘特图一套完整的Project编制流程顺序上应该是WBS工作分解结构→任务列表→工期估算→逻辑关系→资源分配→检查调优。很多人习惯一开软件就敲任务跳过了最关键的分解环节后面做出来的计划要么漏项、要么颗粒度不均匀怎么看怎么别扭。2.1 第一步先做任务分解再开软件不要在软件里硬编我见过最有效率的一种做法是在开Project之前先用白板或者Excel把WBS大致画出来。不是说Project不能做WBS而是说在空白界面里直接编任务很容易被软件界面带偏思路从这件事应该怎么拆变成这个表格里应该填什么。这个区别看似细微实际对计划质量影响很大。WBS分解有个很实用的检验标准如果一个任务你无法估计它的工期说明它拆得还不够细。比如写下完成登录模块”你很难说清楚要多久但如果拆成接口联调、前端页面、联调测试、修复Bug每一项就有了估算空间。拆到基本能估算工期这个粒度就够了——没必要把所有任务拆到人天以下拆得太碎会让计划页面变得冗长反而不利于管理。2.2 第二步把WBS翻译成Project任务列表打开Project之后在任务名称列逐条输入这和Excel没多大差别。真正的差别在结构上。选中一个子任务之后工具栏里的降级向右箭头和升级向左箭头按钮会把任务组织成大纲结构。被缩进的任务是子任务上层自动变成汇总任务项目会自动计算其工期、开始时间、完成时间。这里有个新手最容易犯的错汇总任务的工期是自动算出来的不要手动去改。很多人不放心非要在汇总任务上填一个工期结果一保存Project立刻恢复成子任务计算的值文件还会出现计划冲突的小图标。记住这个逻辑——只有最底层的子任务可以手动填工期汇总任务永远是下级任务的自动聚合这也是大纲结构的意义所在。2.3 第三步工期不是拍脑袋是算法和经验博弈的结果工期是Project里最容易误导人的一个数值。默认情况下一个2天的工期指的是两个工作日前提是设置了正确的工作日历不是48小时。新用户最容易踩的坑就是在这里周五给一个任务填了2天工期以为下周一能完成结果Project的计算结果是下周二——因为Project自动把周六周日排除掉了除非你在日历里把周末设置为工作时间。输入工期时在数字后面加上单位会更清楚地表达意图2d天、3w周、12h小时等等。如果双击输入框可以在工期下拉框里选择单位。工期为0的任务会被Project自动识别为里程碑Milestone用菱形符号在甘特图里显示一般用来标记关键节点和交付点——比如产品发布验收会议。关于工期的估算我的经验是区分纯工作时间和日历时间。一个任务从周一到周五做5天日历时间是7天但工期就是5个工作日。这就是为什么有些人建的计划看着头尾隔了两周但实际工作量只有6天——因为中间还有个周末。如果你在跟客户谈交付日期要特别留意这种工作日 vs 日历日的差异避免沟通偏差。2.4 第四步链接逻辑关系让计划活起来这是Project和Excel真正拉开差距的地方。选中两个或多个任务点工具栏的链接按钮Project会在它们之间建立完成-开始FSFinish-to-Start关系也就是前一个任务完成后后一个任务才能开始。不过实际项目里任务关系远不止完成才能开始这一种Project支持四种关系类型简写含义常见场景完成-开始FS前置任务完成后后继任务才能开始编码完成后才能测试开始-开始SS前置任务开始后后继任务可以开始架构设计开始后模块开发可以并行完成-完成FF前置任务完成后后继任务才算完成文档编写完成后评审才能收尾开始-完成SF前置任务开始后后继任务才能算完成极少用一般交接场景双击任务后在弹出的前置任务选项卡里可以填写多个前置任务的ID并选择关系类型。还可以在时间提前量/滞后量列里填写具体数值正数表示滞后比如FS 3d表示前置任务完成3天后再开始后续任务负数表示提前比如FS - 2d表示后续任务可以在前置任务完成前两天开始。这个负数的用法对压缩工期非常有效但需要确认逻辑上真的能重叠实施否则是纸面上的压缩落到现场根本执行不了。链接完成后可以做个简单检查修改其中一个任务的工期看看后续任务是否跟着联动变化。如果变化符合预期说明依赖关系建对了如果日期纹丝不动多半是漏了链接或者任务被设了固定日期约束这一点后面专门讲。2.5 第五步分配资源发现并解决过度分配资源分配这一步很多计划新手会直接跳过理由是人手没有完全定下来。但Project里如果不给任务分配资源就看不到两个核心风险资源过度分配资源被同时安排了超过可用时间的工时和工期仿真给任务分配更多人后工期会缩短多少。在资源工作表视图里录入资源字段包括名称、类型工时/材料/成本、最大单位默认100%表示一个人全职、标准费率等。然后回到甘特图视图在任务对应的资源列里下拉选择该任务的执行人。分配完之后切到资源使用状况视图或者团队计划程序可以一眼看出某个资源在某段时间内被分配了多少工作量。如果出现红色标记或条形图上有红色小人图标说明资源已经过载。这时候有两种调整思路一是延长任务的工期让工作量摊开二是把某些任务移交给其他资源重新平衡负载。Project也提供自动的调配资源功能但算法结果有时候不太符合实际情况我通常手动调整而且建议你也手动确认别全自动。3. 影响计划可执行性的三个隐形开关日历、约束、关键路径任务和依赖关系都建好之后计划看起来像模像样了但真正决定这份计划发出去之后能不能落地执行的反而是三个容易被忽略的设置项目日历、任务约束、关键路径。这几个开关改对了计划才算活了。3.1 项目日历默认配置正是计划的第一个坑Project的默认项目日历是标准日历即周一到周五工作周六周日休息每天工作8小时9:00-18:00。这个默认设置对大部分办公室项目是适用的但对涉及倒班、现场施工、7×24小时运维的项目来说必须提前改。进入项目选项卡 →更改工作时间可以对全局日历进行设置。比如所在公司周五下午提前到17:00下班可以在这里把周五的工作时段改短如果项目组周六要赶工可以把周六标成工作日。修改完成后Project会按照这个日历重新计算所有任务的工期甘特图上的非工作时段也会显示为灰色阴影。这里有个非常常见的坑项目要求是7月到9月期间工作但公司正常的周末和节假日照常放假这时候除了项目日历还要单独设置例外日期。在更改工作时间窗口里选中某一天在右侧工作时段改为非工作时间这个操作可以把法定假日、公司团建日、机房封网日等等全部排除在工作时段之外。否则你会发现自己编制的计划里中秋节那天还在排测试任务这种细节在计划评审会上极其容易出问题。3.2 任务约束比前置任务更隐蔽的计划杀手任务约束Constraint是Project里最容易被误解、也最容易引发排期混乱的功能。默认情况下Project里所有任务的约束类型是越早越好ASAPAs Soon As Possible意思是只要前置任务完成了、日历条件满足了任务越早开始越好。一旦你手动给任务填了日期比如在开始时间里直接输入了一个日期Project会悄悄改变这个任务的约束类型最常见的变成不得早于……开始SNET。你当时可能没意识到自己改了约束但之后调整前置任务时日期怎么拖都不动就是这个约束在背后起作用。这会让Project失去自动推算的能力计划会越来越僵化。Project的主要约束类型和应用场景可以参照这张表约束类型含义使用场景越早越好ASAP只要条件允许任务越早开始越好默认类型绝大部分任务适用越晚越好ALAP只要不推迟项目完成时间任务越晚开始越好某些营销发布场景不想提前上线不得早于……开始SNET任务不能早于指定日期开始有硬性前置条件如政策生效日不得晚于……开始SNLT任务不能晚于指定日期开始有明确外部截止日必须开始于MSO任务必须在那一天开始会议、发布、开庭等硬性时间点必须完成于MFO任务必须在那一天完成法定期限、合同交期最安全的做法是除了真正有硬性日期要求的任务其余任务保持越早越好不动。判断标准就是问自己一句这个任务如果提前一天开始会发生什么如果没什么影响就不该设硬约束让Project按照依赖关系和日历去推算这才是进度计划该有的弹性。在高级选项卡里可以查看和修改任务约束类型和约束日期。平时检查计划时可以插入约束类型列和约束日期列快速扫描全项目是否混进了不该出现的硬约束。3.3 关键路径怎么让Project替你标出动不得的任务关键路径是进度计划里最核心的概念之一——它是项目中最长的依赖链每个任务一拖延整个项目的完成时间就会推迟。Project会自动计算关键路径并且在甘特图中用不同颜色默认是红色标出关键任务。但很多人不知道还要特意打开这个显示开关。在甘特图空白处右键 →条形图样式→文本或者使用格式选项卡里的红/蓝样式可以切换为关键任务显示样式。更常用的一种方法在视图选项卡里选择其他视图→跟踪甘特图这里关键任务显示为红色条形非关键任务为蓝色。之后点击格式选项卡里的关键任务复选框让Project突出显示关键路径。为什么要盯住关键路径因为项目管理的资源应该优先放在关键路径任务上。今天下午2点开进度会之前你可以用筛选器下拉框选关键任务/未完成关键任务一份近期的关键任务清单就出来了这会成为周会通报、资源协调的一手依据。一个小技巧非关键路径上的任务都有总浮动时间Total Slack也就是允许它拖延但不至于影响项目完成日期的缓冲天数。如果某条非关键路径的浮动时间是10天而你安排资源时发现某个任务人手不够可以考虑从这个路径上借资源去支援关键路径这就是进度计划指导资源调度的一个典型方式。4. 保存基准按下按钮前必须完成的几件大事基准Baseline是Project跟踪体系的地基。简单说基准是一整套快照数据记录了计划初始时的任务工期、开始时间、完成时间、工时和成本等指标。保存基准意味着向项目宣告这就是我们答应的计划接下来一切的计划 vs 实际对比都以这份快照为标尺。4.1 基准到底是什么保存之后能干什么我把基准理解为项目计划的0号版本。没有它你只能看到当前计划可能已经被改得面目全非有它你随时可以调出原始计划和最当前的计划对比。Project里通过跟踪甘特图可以直观地看到基准开始时间/完成时间在上方显示为黑色条形当前计划在下方显示为蓝色/红色条形。两者之间的错位就是偏差的视觉化呈现。具体到一个项目日常管理中基准能支撑以下动作一是计算SPI/CPI等挣值管理EVM指标虽然Project需要企业版标准版也提供基础成本和工时比较二是回答我们落后了多少天这个老大难问题三是做工期偏差报告比如有20%的关键任务已经偏离基准超过3天。没有基准这些全是空谈。保存基准还有一个附加作用它给团队一个心理锚点。执行过程中任何人对计划的修改只要拿基准一对比就能看出是计划的变更还是执行的偏离这两件事在项目管理里必须分开处理。4.2 保存基准前的数据体检清单我见过很多心急的PM计划一建完就直接保存基准、生成报告结果发现过了两周要复盘时基准里充满了低级错误。保存基准在Project里是一键的事但这一键按下去之后自动重算和对比就全部基于这份快照了。所以保存之前我建议花二十分钟做一次体检第一检查有没有任务的工期被误填为汇总值。随便点开一个汇总任务看它的工期字段是否是灰色自动计算。如果某个汇总任务显示了一个数值且可以编辑说明它被手动改过这会破坏计划的聚合逻辑必须恢复为自动计算。第二检查里程碑的设置。项目里应该有且仅有几个里程碑对应交付节点。在任务名称列下筛选里程碑任务确认这些节点确实是你计划里真正意义上的关键节点而不是某个普通任务被误标。多也不怕关键是每一个都要能在评审上讲得出这个节点代表什么交付。第三检查所有任务的时间单位是否统一。如果有些任务的工期显示为2天有些显示为16小时并不一定都错但至少要想明白为什么不一样。建议在设置里统一时间显示格式文件→选项→常规→Project视图否则发出去的打印件上领导看到的时间单位不统一忙起来容易产生歧义。第四检查资源分配是否有不合理过载。在资源使用状况视图里拉一个从项目开始到结束的时间段排查红色字母这比事后爆出我同时在三个任务上满负荷要省心太多。第五把状态日期调整到项目实际开始日期。状态日期是Project用来计算进度线Progress Line和状态应用的基础。很多人保存基准时没注意这个设置默认用了当前48小时导致后续跟踪时进度线和状态数据和真实项目不一致。正确做法是项目→项目信息→状态日期把它设置为你计划正式开始的那一天。4.3 基准菜单若隐若现如何正确调出并保存在Function Ribbon上路径是项目选项卡→日程组→设置基准→设置基准和设置中期计划两个选项。中文版中这个是设置基线。注意不同版本的Project菜单可能有一两个字重命名但基本位置都在项目选项卡里。点击设置基准之后默认选择是完整基准作用范围是整个项目或选定任务。第一次保存建议用完整基准整个项目操作最简单结果最可靠。Project会为每个任务写入一组基准开始时间、基准完成时间、基准工期、基准工时、基准成本字段同时在文件属性里记录上次保存基准的时间方便追溯。保存之后要验证一下切换视图到跟踪甘特图可以看到每条任务的上方出现了一条黑色条形基准下方是彩色条形当前计划。如果黑条没出现很可能是当前视图中未显示基准条形可以在格式→条形图样式里勾选基准。如果数据没问题那下一步就是做好文件归档把保存基准前后的日期记录清楚。4.4 基准保存错了怎么回退能回退吗这是被问得最多的问题之一保存完基准发现工期填错了、任务漏了怎么办答案是——基准字段可以被覆盖但没有撤销基准的直接按钮。Project 2010之后的版本中如果你再次打开设置基准窗口会发现一个清空基准Clear Baseline的选项点进去后可以清除整个项目或选中任务的基准数据清除之后再重新保存新的基准。不过在实际工作中我不建议频繁清空并重新保存基准。因为这样做等于告诉所有人当初答应的计划可以随时改项目的严肃性就没了。更合理的做法是如果执行过程中出现重大变更范围变更、工期大幅调整不要覆盖原来那个基准而是再保存第二个基准比如基准2Project允许保存多个基准最多11个从设置为基准对话框里可以切换到不同集合。这种方式保留了历史版本可以呈现原始基准→变更后基准的完整轨迹这才是大项目应有的做法。判断什么时候该更新基准、什么时候不该我的经验是看变更的性质单纯的执行偏差任务比计划晚几天不需要更新基准范围变化或者里程碑调整需要更新基准可以存第二个基准来标记这个转折点。5. 基准存完不等于高枕无忧追踪阶段的常见困惑基准保存好计划阶段才算真正收口。但很多人接下来的困惑是为什么我明明存了基准实际任务都完成了进度数字却对不上为什么完成百分比显示50%甘特图上进度线却显得很奇怪这些坑我一个个说。5.1 为什么状态日期、完成百分比总对不上Project里的完成百分比是根据任务工期和实际开始/实际完成日期自动计算的但它对截至今天完成了多少的敏感度取决于你更新进度的方式。如果你只是手动把某个任务的完成百分比改成50%Project会按照这个比例自动推算相应的实际工期。这个推算是线性的但很多任务实际上是前松后紧或者前紧后松的这就是进度线看起来不真实的原因。更稳妥的更新方式是在任务选项卡里用更新任务按钮填写实际开始日期实际完成日期实际工期/剩余工期。比如一个任务计划5天干了3天后发现还要4天才能完成正确做法是实际工期填3天剩余工期填4天而不是把完成百分比设成某个看起来差不多的数字。只有工期数据准确了Project才能算出靠谱的SPI/CPI和完工估算。另外要养成一个习惯每次更新完进度先看一眼跟踪甘特图里关键任务条形的偏移方向再交叉检查一下当前日期竖线和进度线状态。如果有条件让Project在任务被输入实际完成日期时自动填满完成比例可以省下不少重复操作的时间——这个功能在文件→选项→高级→计算里将新输入的明示任务更新到完成选项。5.2 缺口分析怎么看缺口分析是基准的真正用途。打开跟踪甘特图后同一行任务会出现两组条形黑色是基准彩色是当前计划。直观上条形错位越严重偏差就越大。但很多新手不知道Project还提供了一个更量化的视图在视图选项卡里勾选勾选表中的显示比较基准或者使用项目向导可以直接看到每个任务的基准开始 vs 当前开始的差值天数。更严谨一点的做法是把偏差Variance列调用出来。在甘特图任务表区域右键插入列选择开始时间偏差Start Variance和完成时间偏差Finish Variance正数表示晚于基准负数表示早于基准。这个数据可以直接作为周会材料。如果完成时间偏差超过阈值比如5个工作日就该触发风险升级组织专项讨论而不是等问题积压到月底。5.3 一些实际操作心得做了这些年项目计划我越来越觉得Project只是个放大器——你把规则和逻辑输进去它帮你把计划的质量和偏差看清清楚。但规则和逻辑需要人来定WBS的粒度、工期的准确性、依赖关系的合理性任何一个环节粗糙后面跟踪都是白费。日常使用里我踩过几次比较深的坑提醒你注意一是千万别在Project里用固定日期去钉住任务的开始时间。一钉整个网络逻辑就崩了。如果需要明确外部硬性节点用一个标记为外部依赖的里程碑任务来体现而不是给具体任务加约束。二是版本控制要严格。保存基准后建议立刻把文件另存为项目名称日期BaselineV1副本。之后无论是做方案对比还是应对审计都有据可查。Project自己虽然能存不同基准但整个文件的版本备份依然不能省。三是导出一份给团队看的阅读版。项目成员大多没有Project授权你可以在文件→导出→导出到Excel里生成一份带格式的任务列表发在工作群里。导出之后记得把开始时间完成时间和前置任务这些关键列保留再删掉资源费率和预算字段避免不必要的信息外泄和歧义。四是状态日期和当前日期是两回事。Project里状态日期管的是进度线计算的基准时间当前日期影响的是视图里的红色竖线。如果发现进度线和当前日期总是对不上先回去检查项目信息里的状态日期是不是设到了计划开工日而不是今天。五是在长周期项目里基准不是存一次就一劳永逸的。项目每到一个阶段关口比如需求冻结、设计评审通过如果范围发生了实质性变化可以按前一节讲的方式再存一份新基准并给基准字段注明存储原因。这样项目结束做复盘时你可以讲出整个计划演变的完整故事而不是只有一个孤零零的初期快照。回到我自己团队的使用习惯每个项目开工的第一天我会特意花半小时和核心干系人一起过一遍WBS和依赖关系再花十五分钟检查一遍资源负载和约束类型最后才按下保存基准。这个过程看起来慢但恰恰是它把后续执行期的加班救回来了。Project学会操作只是第一步真正值钱的是你开始相信计划的失控不可怕可怕的是没有基准去度量失控。