项目表上每个任务都有日期，却没有写清谁等谁。前一项晚三天，后面仍按旧日程显示，计划看着完整，实际已经无法执行。甘特图的关键是任务依赖，不只是把一排单元格填色。
先列一条可以解释的交付链
在XunL 甘特图在线制作中，用PlantUML描述项目开始、任务工期与前后关系。比如教学项目可设打样、客户确认、生产、检验和出运，先明确哪些必须等待前项结束，哪些可以并行。
设想打样十个工作日、确认三个工作日、生产二十五个工作日、检验两个工作日，顺序执行的名义工期合计四十个工作日。它不是四十个自然日，更不是对真实订单的承诺，还要考虑项目日历、资源与实际等待。
日期为什么会与简单相加不同
工具允许关闭周六、周日，也可明确写入某段节假日，例如 saturday are closed 与 sunday are closed。项目使用什么日历，应先与团队确认，再配置；不能把另一国家或另一工厂的休息规则直接套过来。
任务依赖表达清楚后，修改前项工期可让后项顺延。若仍有一项固定日期不随关系变化，要核实它是硬约束还是遗漏依赖。自动排期没有替你确认供应商产能、客户反馈速度与运输可用性，这些条件仍需人工管理。
可以把出运等关键交付点设为里程碑，但里程碑只是计划节点。订舱确认、检验通过和货物交接分别需要证据，不能因为图上出现菱形就当作已经达成。
进度百分比，要有可解释的依据
代码可标记任务完成比例，例如 [打样] is 60% completed。这适合表达团队确认的进度，不应只按时间过去多少自动填写。样品尚未验证，即使工时已经用完，也不能简单写成百分之百完成。
延期时先看哪项真实阻塞，以及它是否影响后续交付。前后相连的链有可能决定总时长，但复杂项目还要考虑并行和资源，不能仅凭条形长度就断言已经完成完整关键路径分析。
计划图和执行记录一起更新
渲染代码会发到本站服务器沙箱处理，提交前移除不适合分享的客户与内部资料。图生成后检查日期、中文、里程碑与任务先后，导出SVG或PNG，再在最终文档中核对显示。
保留源代码与版本说明，记录本次改动因何发生、实际影响哪几个节点。对外交流时明确这是计划还是实际状态，避免把自动顺延后的日期当作供应链已经确认的交期。
任务过多时，可将总览与分阶段计划分开。总览突出交付点，阶段图保留执行细节，并给负责人对应清单。让图能支持会议讨论，比把所有事项塞到一张不可读长图里更有用。
工期改了，为什么出运日不一定能按图落实？
图只按输入关系计算，资源、审批、物流与外部确认仍可能约束执行。调整日期后还要重新协调这些条件，不能只发一张新图。
能直接替代项目管理系统吗？
它适合表达与维护计划，不自动承担任务通知、实际工时和证据归档。若需要持续协作，应与团队既有任务流程结合使用。
个人微信：ssevening
