一张项目时间表，可以很快写满。
第一周准备，第二周执行，第三周完成。每一行都有日期，每一个任务都分了人。看起来，项目已经有了清楚的推进节奏。
往下追问，事情才逐渐具体起来：执行之前需要什么资料？上一环节做到什么程度，下一环节才能开始？谁来判断交付已经完成？如果关键条件没到位，原来的日期还成立么？
这些问题没有答清楚，时间表就容易变成一张愿望清单。日期越来越近，大家都在忙，项目却未必真的往前走了多少。
我觉得，一张能用的时间表，需要把目标日期、推进条件和完成依据放在一起。
日期帮助我们安排工作。条件说明为什么可以进入下一步。证据让大家能够核对，这一步到底完成了没有。
把这三件事连起来，时间表才有了实际的管理作用。
一、先说清“完成”，再给它安排日期
做计划时，很容易先列动作：准备资料、沟通方案、安排测试、推进交付。
这些动作当然需要做，但它们离“完成”还有一层。
“准备资料”完成，指的是文件已经收到了，还是相关人核对过，能够支持下一步判断？“测试完成”，指的是有人点开看过，还是约定的关键流程已经检查，并留下了结果？
同一个任务名称，几个人可能有几种理解。
我的建议是，每个重要节点先写成一句能够检查的话：这一阶段结束时，应该留下什么结果，达到什么条件，由谁确认。
比如，把“完成需求沟通”改成：本阶段的服务范围、必须支持的流程和暂不处理的事项已形成清单，并由约定负责人确认版本。
再把“完成测试”写清楚：按已确认的范围检查关键流程，记录结果和遗留问题，达到事先明确的试用条件，再由核验人确认。
这样一来，日期对应的是一项可以核对的交付，而不只是一次已经发生的动作。
二、把前置条件写出来，项目的先后关系才看得见
一个节点能否推进，往往取决于前面的条件。
有的工作需要先确认范围，有的工作需要先取得资料，有的工作需要资源到位，也有的工作需要一个有权限的人作出决定。
这些关系如果只在几个人脑子里，时间表上就会出现很多“同时进行”。等到真正执行，才发现后面的人一直在等前面的东西。
我会沿着每个重要节点，往前问三句：
- 开始这项工作，需要什么输入？
- 达到这个阶段的完成标准，还缺什么条件？
- 这些输入和条件，由谁提供、由谁核对？
然后把依赖关系画出来。
哪些任务必须先后推进，哪些能够并行，哪些只需要先完成一部分就可以开展，都要分别说明。条件驱动不等于所有工作排成一条长队。 没有依赖的事情可以继续做，受阻的事情要把卡点显出来。
还要分清“手里已有一份材料”和“这份材料能够支持本次工作”。资料的对象、范围、日期和版本对不上，文件再多，也未必补齐了这个条件。
图一表达阶段推进的基本关系。日期持续跟踪，进入下一阶段仍需核对实际条件和交付；具体标准应在相应工作开始前讲清楚。
三、给时间表留三种日期，进度才不会混在一起
日期也有不同含义。我建议至少分开记录三种：
| 日期 | 它回答什么 | 怎样使用 |
|---|---|---|
| 目标日期 | 我们希望什么时候完成？ | 用来组织资源、协调先后和提醒检查 |
| 当前预计日期 | 按现在的条件，预计什么时候能完成？ | 说明估计依据、尚未落实的条件和本次更新原因 |
| 实际完成日期 | 什么时候经核验，确认达到了完成条件？ | 与交付记录、核验结果和确认人对应 |
这三个日期可以相同，也可能逐渐出现差异。差异本身就值得看。
如果当前预计已经晚于目标，负责人要说明是什么条件发生了变化，对后续任务有什么影响，需要谁作决定。只把原日期往后改，问题还留在那里。
实际完成日期也不能只按“文件发出去了”填写。对于需要核验的阶段，提交和确认是两个状态，时间表里要能区分。
外部协作方或其他条件尚未确定时，可以记录有依据的预计范围，写清前提和下一次核对时间。暂时没有判断依据，就明确标为待确认，不能为了让整张表看起来完整，填进一个没有支撑的日期。
已经明确的期限仍然要认真管理。发现赶不上，就及时报告影响，处理资源、范围、沟通和调整事项。“条件未齐”需要对应具体问题和动作，不能一直停留在一句解释上。
四、在关键节点设一个能核对的关卡
每一件小事都层层审批，项目也会变慢。我的想法是，把核验放在那些真正影响下一阶段的节点上。
关卡要检查的内容，可以先用五件事讲清楚：
前置条件、交付结果、核对证据、责任人、核验人。
负责人负责把事情推进，核验人按照事前明确的标准检查。小团队可以采用简洁的安排，但“谁说完成了、依据是什么”仍然要留得下来。
证据也未必是一份厚报告。确认过的范围清单、可复查的测试记录、验收纪要、双方一致的交付版本，都可能是适合某项工作的依据。关键是它能证明什么，是否对应这次的完成标准。
核验本身也要有处理时间。资料提交后，由谁在什么时候检查；发现问题怎样退回；超过约定时间找谁处理，都需要安排。否则，项目可能从“等交付”变成一直“等确认”。
我建议，状态先用普通词标清楚：未开始、进行中、待核验、受阻、已完成。需要暂停的，再记录暂停决定及后续处理。
写“完成了80%”也可以，但要说明百分比对应什么。几个简单任务做完，不意味着最关键的条件已经接近完成。项目负责人需要看见剩下的工作里，哪些会真正挡住下一步。
五、条件没满足，就把缺口、影响和决定分开处理
核验发现问题以后，先别急着重排整张表。
我会先分三种情况看。
第一，缺的是资料或交付。
把缺口写具体，明确谁补、补到什么程度、什么时候再核对。比如缺少测试记录，就补记录；关键流程确实有问题，就先修正交付。提交一份说明，不能替代本来需要完成的工作。
第二，原来的方案或范围需要改变。
先评估改变会影响什么：后续依赖、资源投入、成本、对外安排，哪些需要一起调整。由有权限的负责人确认后，再更新任务、条件和预计日期，同时保留变更前后的关系。
第三，关键条件目前无法满足。
这时需要的是一个明确决定：继续补条件、重新设计路径、暂停，还是停止。不同选择对应不同后果，应当把依据和影响提交给有权限的人确认。
对于不能越过的条件，调整日期和内部表态都不能代替条件本身。对于确实可以调整的工作范围，也要按相应权限确认，重新写清适用的完成标准，不能悄悄把要求降低，再把状态改成“完成”。
有些依赖被卡住，不影响其他工作继续推进。把这部分范围单独识别出来，团队就能够减少无效等待；同时也要防止后续投入建立在尚未确认的关键假设上。
图二给出一种阻塞处理方法。补证、变更和暂停各有入口；更新日期不会自动解除阻塞，变更后的条件仍需核验。
六、用一个预约服务试点，看看时间表怎样变化
下面是专门为解释方法编写的假设情境，不对应真实企业或项目。
一个小团队准备上线预约服务，希望在第三周结束前开展外部试用。
如果时间表只写“第二周开发，第三周上线”，到了第三周，页面已经做完，项目很容易被认为接近完成。
把试用条件展开以后，会看见几件需要核对的事：试用范围是否确认，演示环境是否准备好，预约和取消预约两条关键流程是否达到事先约定的标准，异常情况由谁接收和处理。
检查时发现，取消预约后，时段没有正确释放。这会直接影响其他人继续预约，因此尚未满足原定的外部试用条件。
这时可以形成一组具体动作：
- 开发负责人修正问题并提交新版本。
- 核验人复测相关流程，留下检查结果。
- 项目负责人说明目标日期、当前预计及后续影响。
- 不依赖该问题的试用说明、人员准备等工作继续开展。
如果团队希望先采用更小的试用范围和人工处理办法，就另行评估它的可行性、限制与责任，由有权限的人确认，再按获批的新范围核验。不能只因为日期到了，就默认原来的问题已经被接受。
这个过程里，“开发已经提交”“正在复测”“可以试用”是三种不同状态。把状态与证据分开记录，协作者才知道自己能不能开始下一步。
七、一张阶段验收表，先把这些信息放齐
时间表不用一开始就做得很复杂。先把一个关键阶段写清楚，再逐步连接前后关系。
| 字段 | 建议写法 |
|---|---|
| 阶段结果 | 这一阶段结束时，具体交付什么 |
| 前置条件与依赖 | 需要哪些输入，来自哪个任务或负责人 |
| 完成标准 | 什么情况可以确认完成，哪些条件不能跳过 |
| 核对证据 | 交付物、记录编号、版本及保存位置 |
| 负责人和核验人 | 谁推进，谁核对，谁在超出权限时作决定 |
| 日期记录 | 目标日期、当前预计、核验确认后的实际完成日期 |
| 当前状态与缺口 | 在哪一步，具体还缺什么 |
| 下一动作与复查时间 | 谁做什么，什么时候再次核对 |
| 变更和后续影响 | 调整依据、确认人、受影响任务及通知情况 |
对于还没有明确的事项，就记录待确认内容和负责确认的人。资料不够时先形成缺口，能够补齐后再作判断。
真正有用的进度更新，应该让协作者知道：现在完成到哪了，为什么卡住，下一步由谁做，以及原来的安排需要怎样变化。
结语
我觉得，项目时间表最值得做实的地方，是每一个日期背后的推进依据。
目标要保留，责任要落实，条件发生变化也要及时处理。把前置条件、交付证据和确认过程连起来，项目的先后关系就更容易看清，调整也有了可以讨论的依据。
下一次看时间表时，可以先沿着一个关键节点问：要进入下一步，现在还缺什么？谁来补，谁来确认？
这几个问题答清楚，工作才更容易往前推进。