★ FEATURED ARTICLE 做项目管理这些年被问得最多的一个问题就是任务清单列得清清楚楚为什么一到交付节点还是全线崩盘我的回答通常很直接——你手里那份是清单不是计划。清单只回答有哪些事要做而甘特图项目管理回答的是另一组更要命的问题哪件事必须先做、谁来做、要做多久、它卡住会连带谁一起卡住、留了多少余量给意外。甘特图Gantt Chart本质上就是把这些答案压进一张二维图里横轴是时间纵轴是任务条形的长度代表工期条形之间的连线代表依赖关系菱形代表里程碑。它不新鲜上世纪就有了但到今天依然是排期类工作最通用的语言。这篇文章面向的是真正要落地的人带三五人小团队的技术负责人、要协调多个部门的项目协调员、接了外包交付单的独立开发者以及刚接手排期工作、看别人甘特图一头雾水的新人。我会用一个完整的虚构案例把从任务拆解、工期估算、依赖设置、关键路径计算到周报更新、跳票重排的全过程走一遍中间穿插我自己踩过的坑和那些文档里不会写的细节。1. 先把甘特图这件事想清楚它到底解决什么问题1.1 甘特图的本质是把时间当资源来分配很多人对甘特图的理解停留在一张横条图画出来给领导看看进度这是把它当装饰品。它真正的价值在于把时间显性化成一种可分配、可消耗、可超支的资源。你手里有8个人、10周这就是你的资源池每一条任务条都是从池子里切走的一块切多了就必然有人同时被切两刀切少了就是拖延。我一直用一个生活类比来解释甘特图很像装修队贴在墙上的施工排期表。水电工什么时候进场、泥瓦工什么时候能接上、木工的门套要等墙面干透才能装这些先后顺序不能乱乱了就要返工。装修队靠老师傅的经验在脑子里排项目团队人一多、事一杂脑子里装不下就得落到图上。图的作用不是好看是让所有人对什么时候该谁上场有同一个认知。从这个角度讲一张合格的甘特图必须同时承载三层信息缺一层就会出问题任务层要做哪些事、编码怎么排、每件事的颗粒度多大、验收标准是什么时间层每件事的起止日期、任务之间的依赖关系、里程碑节点、以及一份锁定的基线责任层每件事的唯一责任人、协助人、该责任人在某段时间的负荷是否超过100%。我见过大量失败的排期问题几乎都出在只有前两层。图排得漂漂亮亮时间线严丝合缝但没写谁负责或者写了三个人的名字结果就是人人有责等于无人负责。任务条一旦没有明确的主人延期时就只能开会互相看一眼。1.2 什么样的项目适合甘特图什么样的不适合甘特图有个隐含前提计划是相对可知的。它假设你能在开工前把任务拆到可执行的粒度并且大致估出工期。这个前提成立时它极其高效前提不成立时它会变成一份精致的幻觉。适合的场景特征比较明显任务边界清晰、依赖关系明确、周期在几周到几个月之间、需要多人或多部门协同。比如硬件样机交付、展会筹备、课程上线、门店开业、系统迁移、内容专题的整月排期。这类工作有明确的交付物谁先谁后基本能说清甘特图能发挥最大价值。不适合的场景也要认清。第一类是探索型工作比如全新算法的可行性验证你根本不知道下一步会遇到什么把三个月拆成30个任务条纯属自欺。这类工作更该用里程碑短周期滚动排期只锁定最近两周的细节远处只放阶段目标。第二类是救火型运维故障来了就得上排期没有意义适合用看板管理流动。第三类是极短任务半天以内能做完的事画成条形反而增加维护成本直接列清单更省事。注意判断标准不是项目大小而是不确定性高低。不确定性高的项目不是不能画甘特图而是只能画粗粒度的骨架图细节部分留给滚动计划。1.3 为什么很多团队的甘特图画完就没人看这是我最常被问到的问题答案通常有三个。一是图是项目经理的图不是团队的图——任务名用的是内部黑话责任人写的是岗位而不是人名一线执行的人看不懂也不认账。二是图从来不改画完贴在共享盘里两周后现实早就跑偏了大家自然不再相信它。三是图里没有决策信息只有一堆横条看不出哪条最关键、哪条快炸了。要让图活下来得让它承担沟通功能而不只是记录功能。我的做法是每次周会只放一张精简视图上面只保留三类信息整体完成比例、关键路径上的任务状态、本周有风险的任务。其他的细节想看自己去翻全图。图一旦能在一分钟内回答我们现在到哪了、卡在哪、下周要盯什么它就有了被持续维护的理由。2. 案例背景与整体设计思路拆解2.1 案例设定一个虚构的软硬件结合交付项目为了让后面的计算和操作有落脚点我设一个虚构案例某硬件研发小组要交付一款小型智能终端的工程样机团队8人周期10周预算有限需要向内部评审会交付样机、测试报告、物料清单和工艺文件四类成果。项目启动日统一记为D0后面所有日期都用第几天表示避免具体日期带来歧义。项目的主要阶段大致是这样需求冻结、结构与硬件方案设计、结构件打样、样机装配、软硬件联调、可靠性测试、文档整理与交付。听起来线性实际上固件开发和硬件设计是并行的联调又要等两边都收敛。这种主干清晰、局部并行的结构正是甘特图最擅长表达的场景。我特意把这个案例设计成20到30条任务的规模。这个规模有个好处任务多到靠脑子记不住必须画图又没多到需要专门的排期软件才能管理用电子表格也能扛。对大多数中小团队来说这个区间最有代表性。2.2 拆解思路从交付物倒推任务而不是从人倒推任务新手最容易犯的错误是按人头分活。打开表格先写八个人名然后每人名下面挂几件事最后一拼发现时间对不上、依赖理不清、有人闲死有人忙死。这种拆法的问题在于它组织的是人的工作而不是项目的产出。正确的方向是从交付物倒推。先问评审会要看什么答案是四样东西——能开机的样机、一份可靠性测试报告、一份冻结的物料清单、一份可交给产线的工艺文件。然后对每样东西继续问要做出它必须先有什么样机要有装配好的结构件和烧好固件的板子结构件要先有3D图纸才能打样板子要先有选型和原理图确认才能投板。这样一层层往下问任务自然就长出来了而且每条任务都天然带着为什么存在的理由。这个倒推过程产出的结构就是WBS工作分解结构。它的好处是完整性有保障——每个任务都能向上追溯到某个交付物不会出现这件事为什么要做的尴尬。我通常会在表格里单独留一列对应交付物逼自己填填不出来的任务要么删掉要么说明它是纯支撑性工作。2.3 方案选型电子表格、专业排期软件、在线协作平台怎么取舍工具选择上我踩过两个极端。早年迷信专业软件给一个只有12条任务的小项目上了重型工具结果团队没人愿意打开最后还是回到表格。后来矫枉过正什么项目都用表格做到60多条任务、跨4个部门时依赖关系全靠手工维护改一个日期要连带改十几行错一次就全乱。我的经验是按规模和信息复杂度分档下面这张表是这几年沉淀下来的判断依据判断维度电子表格专业排期软件在线协作平台依赖自动重算需要手写公式勉强能做原生支持改一处全图联动多数支持能力中等基线对比手工另存一份快照原生支持多基线部分支持多人同时编辑冲突较多需约定时段通常一般强学习成本几乎为零需要半天到两天低适合规模30条任务以内、2到3人并行50条以上、多部门协作20到50条、执行层为主关键路径识别手工计算自动标红多数不直观结论比较务实10周、8人、25条左右任务的项目电子表格加一个在线协作平台做状态同步就够了。真正需要专业软件的门槛我自己的判断是任务超过50条、并行责任人超过5个、或者甲方要求提供基线偏差报告。这时候手工维护的成本已经超过学习成本就该换工具了。提示工具切换的成本不只是学习还有历史数据的迁移。中途换工具是排期管理的大忌尽量在项目启动前定好一个项目周期内不要换。2.4 排期骨架日历、粒度、编码规则的前置约定在动手录第一条任务之前有四件事必须先约定好否则后面全是返工。工作日历。要明确一周几个工作日、有没有固定休息日、团队是否有人跨时区。这个设定的影响比想象中大同样10个工作日的工期按五天工作制和六天工作制排出来差两天累积到全项目就是一周以上的偏差。案例里我按五天工作制排节假日单独标记为不排期日。任务粒度。我定的规则是最细到半天最长不超过10个工作日。超过10天的任务必须拆因为长任务在图上是一根没法判断进度的长条做到第8天你都不知道它到底完成了六成还是三成。短于半天的任务合并到相邻任务里否则图会被琐事淹没。编码规则。用阶段号.任务号的层级编码比如3.2表示第三阶段的第二个任务3.2.1表示它的子任务。编码的好处是讨论时可以直接引用3.2那条打样任务比那个结构件打样的活儿精确得多开会效率能提升一截。更新节奏。固定每周同一时间更新一次比如周五下午。不定时更新会导致两个问题一是数据口径混乱有人按周三的状态报有人按周五的报二是大家疲于应付随时变化的需求。固定节奏反而让更新变成习惯。3. 核心细节解析任务分解、依赖关系与估算3.1 WBS分解的四个硬标准任务拆得好不好直接决定后面所有工作是否成立。我判断一条任务是否合格看四条标准缺一条就打回去重写。第一必须是可交付的。任务名要用动词对象成果的结构比如完成结构件3D图纸并冻结版本而不是结构设计。前者有明确的结束状态后者是个模糊的活动范围做三天算设计做十天也算设计没法判断完成没完成。第二必须可验收。要能回答凭什么说它做完了。是图纸通过评审还是样件尺寸检测合格还是报告签字确认。没有验收判据的任务最后一定扯皮。第三单一责任人。每条任务只能有一个A负责人其他人一律放协助列。这一条最容易被违反因为大家都想共同负责。但共同负责在实际执行中等同于没人负责延期时第一句话就是我以为他在跟。第四颗粒度合适。2到5个工作日是最舒服的区间最长不超过10天。太粗无法跟踪太细维护成本高。下面是我常用的正反例对照团队新人培训时直接给这张表不合格写法问题合格写法硬件设计无交付物、无边界完成主板原理图设计并通过内部评审联调太粗可能持续两周完成固件与传感器的通信联调误码率低于阈值开会讨论方案不是交付物输出方案选型对比表并完成决策记录跟进供应商无验收判据取得供应商打样交期书面确认并录入排期3.2 四种依赖关系与提前量、滞后量的用法甘特图里任务之间的连线不是装饰它决定了改一个日期会连带改多少行。标准依赖有四种实际项目里用得最多的是前两种。**完成-开始FS**是最常见的前一个做完后一个才能开始。打样完成才能装配这就是FS。开始-开始SS前一个开始后后一个才能开始两者可以并行。固件开发和硬件调试就常是这种关系硬件平台一搭起来固件就能同步开工。完成-完成FF前一个完成时后一个也必须完成多用于必须同步收尾的场景。**开始-完成SF**用得极少一般只在交接班场景出现。比依赖类型更容易被忽略的是提前量和滞后量。提前量是允许后置任务提前启动的时间比如固件开发可以在需求冻结后第2天就启动写成SS加2天提前量。滞后量是强制等待比如结构件打样完成后要放置48小时做应力释放才能进入装配这就是FS加2天滞后。这两个参数是排期的精细调节阀用好了能让计划贴合现实用不好会制造假象。我见过最典型的误用是为了让计划日期好看给一堆本该串行的任务硬加提前量图上是并行了实际执行时两拨人抢同一台设备谁都推不动。注意提前量不是我希望它早点开始而是客观上它确实可以早点开始且不会造成返工。加之前先问一句如果前置任务的结果变了后置任务已经做的那部分要不要重做要重做就别加。3.3 工期估算三点估算与缓冲的加法工期估算最忌讳拍脑袋报一个差不多。人天生乐观尤其是对自己熟悉的活容易按最顺利的情况估。我的做法是三点估算对每个关键任务问三个数最顺利要多久O、正常情况要多久M、最糟情况要多久P。然后按(O 4M P) / 6算期望工期按(P - O) / 6算标准差用来衡量这条估算的不确定程度。拿案例里的结构件打样举例顺利的话5天正常7天遇到模具返修最糟15天。期望工期是 (5 28 15) / 6 8天标准差约1.67天。这个数字的含义是这条任务有较大概率落在6.3到9.7天之间。标准差越大说明这条任务的变数越多越应该在排期时留缓冲。缓冲怎么加我用两套并行的办法。关键路径上的任务用根方差法把关键路径上各任务的标准差平方求和再开方得到整条链路的综合标准差取一到两倍作为项目缓冲放在末尾。非关键任务统一按期望工期的20%加在任务自身后面作为保护带。任务OMP期望工期标准差结构件打样571581.67主板投板68148.71.33可靠性测试67127.71.0联调35115.71.33缓冲不是藏着掖着的私房钱最好在图上单独列一行项目缓冲明确告诉大家这段时间是用来吸收意外的不是可以提前挥霍的余量。我见过团队把缓冲当福利提前几天完成就顺手把缓冲吃掉真出问题时一点余地都没有。3.4 关键路径怎么找、浮动时间怎么算关键路径是整张图里最长的那条链路它决定了项目最短能多久完成路径上任何一条任务延期整个项目就延期。找它的方法不复杂正向推一遍最早开始和最早完成反向推一遍最晚开始和最晚完成两者之差就是浮动时间浮动为零的链路就是关键路径。拿案例的主干来算。需求冻结3天紧接结构设计5天然后是结构件打样8天、样机装配3天、软硬件联调5天、可靠性测试7天、文档交付2天。这条链加起来是33天。另外固件开发10天在需求冻结后第2天启动也就是第2天到第12天硬件选型4天在需求冻结后启动第3天到第7天。正向推算下来联调最早在第19天开始因为要等装配完成第19天和固件完成第12天两个条件都满足取晚的那个。所以联调的浮动取决于固件固件最晚必须在第19天前完成它的最晚开始是第9天最早开始是第2天浮动7天。硬件选型的后继是装配装配最早第16天开始所以硬件选型最晚第16天完成最晚开始第12天最早第3天浮动9天。结论很清楚需求冻结、结构设计、打样、装配、联调、测试、文档这条链浮动为零是关键路径固件开发和硬件选型各有7天和9天余量。这意味着如果固件延期超过7天关键路径就会转移固件变成新的瓶颈。这个判断在周会上非常有用可以提前一周预警而不是等到联调当天才发现固件没好。3.5 资源负荷与并行任务的冲突处理关键路径只管时间不管人。一张图上所有任务都不冲突但八个人的名字反复出现在同一天这种图是假的。所以排完时间必须做一次资源负荷检查按周统计每个人的投入天数超过5天就是超载。案例里有个典型冲突第2周结构工程师同时被安排结构设计、选型评审和一份图纸规范整理三项加起来需要6.5天负荷130%。处理方式有四种我一般按顺序试一是延后非关键任务。那份图纸规范整理浮动时间充足直接推到第4周负荷立刻降到90%。这是成本最低的做法优先用。二是拆分任务。把结构设计拆成主体框架和细节特征两段前段放在第2周后段放到第3周让负荷曲线摊平。三是换人。把评审这类不需要原作者深度参与的事转给另一位工程师但要注意交接成本别为了降负荷制造新的沟通开销。四是接受超载并压缩范围。实在没人时只能承认这一周要加班但要在图上标红让所有人知道这是有代价的选择而不是默认安排。3.6 里程碑与阶段门的设计要点里程碑是零工期的检查点图上通常画成菱形。它和任务的区别是任务消耗时间里程碑只标记状态。很多人把里程碑当任务排给它三天工期这就失去了意义。比里程碑更重要的是阶段门。阶段门是带准入准出条件的检查点比如打样投料前这道门准入条件是物料清单冻结、供应商交期确认、图纸版本锁定三条全满足才能过。阶段门的作用是把返工成本挡在门外——打样前发现图纸错了改图只要一天打样后发现重来要两周。里程碑的设置频率我建议一到两周一个太少起不到检查作用太多会让团队疲于应付评审。数量上一个10周项目设5到7个比较合适且每个里程碑都要能回答过了这个点什么变得不可逆了。4. 实操过程从零把这张甘特图搭起来4.1 第一步搭表头与字段设计动手前先把表格结构定死。我的标准字段是这样一组多一个嫌累赘少一个后面要补字段作用填写要点编号唯一标识从1开始递增删除任务后不复用WBS编码层级关系阶段号.任务号如3.2.1任务名称执行内容动词对象成果对应交付物追溯依据填不出说明任务可删责任人唯一A只能填一个人名协助人支持角色可多人逗号分隔工期工作日天数不含休息日计划开始日期由依赖推算不手填计划完成日期开始加工期减一前置任务依赖来源填编号多個用逗号依赖类型FS/SS等默认FS浮动时间余量计算得出基线完成锁定日期定稿后不再改完成比例进度按工作量填验收标准完成判据一句话说清表头定好后建议把计划开始计划完成浮动时间三列设为公式列不让任何人手工填。手工填日期是排期混乱的头号来源只要有人手动改过一次整张图的逻辑就断了。4.2 第二步录入任务与建立层级录入顺序很关键我习惯按阶段成批录入一个阶段录完立刻检查一遍再录下一个。案例里分六个阶段需求与方案、结构与硬件设计、打样与采购、装配、联调与测试、文档与交付。任务名统一按动词对象成果写比如冻结需求基线并输出需求规格说明书完成主板原理图并通过内部评审取得三家供应商打样报价并选定一家。写完通读一遍如果某条任务读完不知道交付什么立刻重写。层级用WBS编码体现同时在表格里用缩进或阶段列做视觉分组。分组的意义在于折叠汇报时把细节折叠起来只看阶段讨论时展开到具体任务一张表两种用法。录完后做一次完整性检查问三个问题每个交付物都有任务覆盖吗每条任务都有唯一责任人吗有没有任务既不属于任何交付物也不支撑任何阶段第三个问题最容易被忽略答案往往是有几个会要开有几份周报要写这些支撑性工作可以单列一个项目管理阶段但不要混进交付链路里。4.3 第三步设置依赖关系与自动排期公式依赖录入的规则是只录真实的、硬性的依赖不要把所有任务都串起来。串得越死后面调整越困难。判断标准是前置任务的结果如果变了后置任务要不要返工要返工才连FS。电子表格里做自动排期核心是两条公式逻辑任务最早开始日 MAX(所有前置任务的完成日) 1 个工作日 任务最早完成日 从开始日往后推 (工期 - 1) 个工作日写公式时要注意三点。一是周末和节假日要跳过用工作日推算不能用简单的日期加天数。二是同一任务有多个前置时要用取最大值的逻辑不能只取第一个。三是依赖类型不同的任务要单独处理SS类型的前置取的是开始日而不是完成日。录完依赖后做一次成环检查。所谓成环就是A等B、B等C、C又等A图上表现为箭头绕成一个圈。这种结构会让自动排期直接报错或者算出荒唐的日期。检查方法很简单把所有依赖按编号排序逐个往下追如果追下去出现了前面已经出现过的编号就说明有环。4.4 第四步把计划日期锁定为基线这一步是整张图的分水岭也是最多人跳过的一步。基线就是你跟各方确认过的承诺版本锁定后不再修改。之后所有变更都改当前计划列基线原封不动这样任何时候都能算出偏差当前完成日减基线完成日正数是延期负数是提前。没有基线的排期汇报时会变成自说自话。领导问这个任务是不是延了你只能凭印象说好像延了两天因为计划日期早就被你自己改过好几轮了没有参照物。基线的锁定时机也有讲究。不是在项目启动会上锁而是在需求确认、资源到位、依赖关系验证完之后锁通常是启动后第三到第五天。太早锁方案还在变锁了也没意义太晚锁前期工作没有参照。提示基线至少保留两份一份是初始基线一份是重大变更后经批准的新基线。中间的小调整不要每次都新建基线否则基线会失去严肃性。4.5 第五步做可视化与分层视图甘特图的可视化不是把表格涂成彩色而是为不同读者准备不同视图。我通常做三个。总览视图给管理层看只显示阶段级任务条、里程碑和关键路径标红一屏能看完回答整体到哪了。执行视图给团队看展开到每条任务标出责任人、当前状态、本周到期项回答我今天该干什么。资源视图给自己看按人按周统计负荷用颜色深浅表示忙闲回答谁快撑不住了。可视化的三个技术要点任务条的长度严格对应工期不要为了美观拉伸依赖箭头只画相邻依赖跨阶段的长箭头会让图变成蜘蛛网关键路径用统一颜色标出别用太多颜色超过五种颜色读者就分不清重点了。4.6 第六步进度更新与偏差计算更新进度时最常见的错误是填模糊百分比比如50%、80%。这个数字既无法验证也无法用于推算剩余工期。我要求团队用两种方式之一完成工作量占比或者剩余工期法——直接报还需要几天。后者更准因为它强迫执行人重新估一遍剩余工作而不是凭感觉给个数字。偏差计算我用两个指标都不用太复杂时间偏差 当前预计完成日 - 基线完成日 进度偏差率 已完成任务数 / 计划应完成任务数 - 1第一个指标看单条任务第二个看整体趋势。如果连续两周进度偏差率都是负的说明不是个别任务的问题而是整体估算或资源配置出了系统性偏差该动大手术了。周报模板我固定三行结论本周完成了什么、下周要盯什么、有什么需要决策。前两行是陈述第三行是关键——大部分周报只报进度不报问题等于把风险留到爆发那天。5. 常见问题与排查技巧实录5.1 常见问题速查表排期出问题时症状往往相似但根因差别很大。下面这张表是我这些年积累的排查清单遇到问题先对照着定位。症状可能根因排查动作处理方式任务条重叠但没人认领责任人字段为空或多填逐行检查责任人列补唯一责任人其余转协助自动排期报错依赖成环按编号追依赖链断开环上最弱的一条依赖关键路径天天变依赖设置过密或过松检查是否有大量非必要FS删除弱依赖保留硬依赖进度显示90%但交不出来百分比凭感觉填改为剩余工期法重估剩余工作必要时拆任务图没人看视图太复杂或从不更新询问团队最近一次看是什么时候精简视图固定更新节奏工期总是不够估算偏乐观无缓冲抽查三条任务的O/M/P引入三点估算和缓冲行跨部门任务长期卡住外部依赖没进图检查是否有等审批等排产类任务把等待时间显性化为任务条5.2 三个最容易被忽略的坑第一个坑是假并行。图上两条任务时间重叠看起来并行推进效率很高实际上两条任务压在同一个人身上或者抢同一台设备。排查方法很简单做一次按人按周的负荷汇总超过5天的一律标红。我见过一个项目图上并行度高达70%实际执行时因为共用一台测试设备所有并行都退化成串行最终延期三周。设备、场地、审批人这些隐性资源都要当成约束条件算进去。第二个坑是隐性依赖。文档评审、领导审批、供应商排产、样品邮寄这些环节在技术上不算任务但实实在在消耗时间而且经常是最大变量。我的处理办法是把它们显性化写不成任务的就写成带滞后量的依赖比如打样完成FS装配滞后3天物流。宁可图难看一点也别让等待时间藏在空气里。第三个坑是关键资源被非关键任务占用。结构工程师是关键路径上的人却被拉去处理一个浮动时间充足的杂事结果关键路径断了。这类问题靠人盯很难避免得靠机制排期时给关键路径上的责任人加标记任何非关键任务占用他们时间都要走一次确认。5.3 进度跳票之后怎么重排跳票是常态重要的是跳了之后怎么办。我按四档处理成本从低到高。第一档赶工。给关键路径上的任务加人或加班。要注意加人不是万能的沟通成本会随人数上升两个熟手配一个新手的效率可能还不如一个熟手。赶工只对可以拆分且沟通成本低的任务有效比如打样、测试这类体力活。第二档快速跟进。把原本串行的任务改成并行比如把FS改成SS加提前量。代价是返工风险上升必须只用在返工成本可控的环节。设计还没定稿就开模返工成本极高这种就不能跟进。第三档缩减范围。这是最有效也最少人敢提的办法。把非核心功能推到下一期或者把全量测试改成抽样测试。范围一动工期立刻松动但需要有人拍板通常是产品负责人或甲方。第四档换资源。外包、借调、换供应商。成本最高启动周期也最长一般作为兜底方案。决策时我一般画个简单的矩阵横轴是延期天数纵轴是可用预算四个象限对应不同策略。延期一天以内赶工解决三到五天快速跟进加部分范围调整超过一周必须动范围或资源光靠前两档撑不住。6. 我实际维护排期时的节奏与几条经验6.1 每周十五分钟的更新流程排期最怕的是维护成本太高高到没人愿意做。我把每周更新压缩成五步熟练后十五分钟能完成。第一步更新完成状态。只改三种值未开始、进行中、已完成进行中的填剩余天数。第二步重算剩余工期把剩余天数填回去让公式自动推新的完成日。第三步看关键路径有没有变。如果原来浮动时间充足的任务变成了零浮动说明瓶颈转移了要立刻调整关注点。第四步看资源负荷有没有人下周超过5天。第五步写三行结论发出去。这个流程的关键是只改数据不改结构。结构变更加任务、删任务、改依赖单独拿出来攒到每两周一次集中处理避免每周都在动骨架。6.2 几条长期有效的习惯任务名一定写交付物。这条我重复了无数遍因为它能挡掉一半的沟通成本。看到完成XX图纸并冻结谁都知道做到什么程度算完看到推进XX工作谁都不知道。计划一周只改一次。频繁改动会让团队失去对计划的信任也会让基线失去意义。紧急变更走单独通道但要留痕注明谁在什么时候因为什么改的。把风险写成任务。识别出的风险不要只写在风险登记表里能落地的都变成带日期的任务条比如完成备用供应商询价放在第4周。风险一旦有了日期就会被真正处理。给所有外部依赖设提前提醒。等审批、等样品、等排产这类事最好在计划到期前三天就设一个提醒任务别等日期到了才发现对方还没动。最后一个习惯每完成一个项目把实际工期和当初估算的对比一遍记录下来。三次之后你对自己的估算偏差就有数了下次排期时心里那杆秤会准很多。估算能力不是天生的是靠这种复盘一点点校准出来的比任何方法论都管用。
阅读完成 · 觉得有帮助？
