项目进度：状态该在做事的地方更新

先说结论

项目进度之所以总要开会才知道，多半不是没人管，而是进度只有一个版本，且只存在项目经理脑子里。

别人要进度，就得去问他；他忙，就等；等到大家凑齐了，开一次会同步一次。会议在这里承担的是「数据分发」的功能——而数据分发本来不该靠开会。

三个卡点

一、进度靠问，不靠看

客户问、销售问、老板问、财务问——同一个问题被问四遍，答案被口头复述四遍。每一次复述都可能带上一点偏差，越往下传越模糊。同一个毛病在售后环节的代价更大，见售后工单：微信群当工单的三个代价。

二、汇报等于「重写一遍」

到了周一要交进度表，项目经理打开上周的表，逐项回忆这周做了什么，再改一遍。这份表只在下发的那一刻是新的，之后就一直过期。

一份靠人工重写才能更新的表，注定只能定期更新，做不到实时。

三、内部口径与客户口径不一致

内部按工序分：设计、采购、装配、调试；客户按里程碑分：到货、安装、验收。两套口径之间的换算，每次都靠项目经理现场翻译。

于是同一件事，内部说「在做」，客户听成「快好了」，中间差了三周。

为什么加会议解决不了

会议能同步信息，但会议本身也是成本：把十个相关的人凑齐一小时，换来一份一小时后就开始过期的快照。

更麻烦的是，会议只解决「大家知道了」，不解决「系统里有记录了」。开完会，进度仍然只在人的脑子里。

做法：让进度在做事的地方更新，按不同对象输出

1. 先把节点定义统一。 内部工序与客户里程碑的对应关系一次确定，写下来。这一步不需要任何系统，但它决定了后面所有进度是否可信。
2. 状态更新在做事的地方完成。 现场拍张照、群里说一句，进度就更新掉，而不是等回到电脑前重写一遍表。
3. 按对象自动出不同版本。 内部看工序级、客户看里程碑级，同一份数据两种视图，不需要人工翻译。
4. 异常自动提醒内部。 节点延期风险先提醒责任人，而不是等客户发现。

节点与状态用Spell Table承载，流转与提醒走Spell Flow；对外按客户口径播报的做法，交付进度自动同步里有完整说明。

三条不能让步的要求

• 一个项目只有一处状态。 允许两个地方各维护一份进度，比没有进度表更糟——它会让「以哪份为准」变成新的议题。
• 进度变更留痕。 谁在什么时候把哪个节点改了，要能查到。这既是对客户的依据，也是对项目经理的保护。
• 对外口径收口。 给客户看的是里程碑与时间，不是内部工序、人名与成本信息。

常见问题

项目不多，一周开一次会够用吗？

项目少、周期长时开会确实够用。判断标准是：上周有没有人在会前就已经知道延期的。如果延期总是到会上才第一次被说出来，那就是机制问题。

现场人员不愿意更新状态怎么办？

把更新动作压缩到一句话或一张照片，并且让他们看到更新之后确实不用再单独汇报。如果更新状态会省掉一次汇报，它就容易被接受。

客户口径经常变怎么办？

口径变化本身是正常的，要留的是「什么时候改成什么」。映射关系有版本记录，之前的进度对得回去，就不会因为改口径而全部重算。

要不要上一套项目管理系统？

项目数量少、参与人少的时候，一张带权限的表加提醒就够。专门的系统适合项目多、跨部门协作复杂、且需要与成本核算强联动的场景。

资料来源与说明

• 我方项目信息：来自已交付项目，可公开的部分已在正文中链至对应案例页。
• 行业通识：岗位与流程层面的公认常识，不另注来源。
• 判断性表述：我方基于上述资料的综合判断，以「通常」「普遍」表述，不作绝对化断言。