进度跟踪进度日志全流程：跨部门团队实操方法与一文讲清

跨部门项目最常见的进度失真，不是有人故意报喜不报忧，而是“完成”在不同团队口中不是同一件事：研发说代码已提交，测试说还没拿到可测版本，业务说验收条件仍在变。进度日志如果只记录百分比，往往到计划交付日前才暴露依赖断点。真正有效的进度跟踪，不是每天催问“做完了吗”，而是让每条关键工作都能回答：承诺是什么、证据在哪里、谁在等待谁、偏差如何处理。

一、先讲核心结论：进度日志不是日报，而是项目的决策记录

1. 先把“进度”拆成可验证的状态

我判断一份进度日志是否有用，通常不先看它写得是否完整，而是抽查三条记录：能否找到交付物，能否看出下一步，能否判断需要谁作出决定。如果三者都找不到，这份日志更像工作汇报，不是进度控制工具。

跨部门协作中，“完成 80%”很难用于决策。它可能代表代码已完成、剩下联调；也可能代表需求大致明确、剩下大量待确认事项。更可靠的记录方式，是把状态写成可核验的事实，例如“接口字段已冻结，测试环境部署成功，仍有两个异常场景待产品确认”。

核心结论：进度日志的最小有效单位不是“人做了什么”，而是“一个可验收的工作项在什么条件下发生了什么变化”。记录围绕交付物、依赖、风险和行动展开，才能让项目管理者尽早发现偏差，而不是在节点会上重新拼凑事实。

2. 用四个问题判断日志是否能支撑行动

• 承诺是否清楚：本阶段要交付什么，验收条件是什么，谁对结果负责？
• 状态是否可证：当前状态由文档、系统记录、测试结果或业务确认支持，还是只靠口头判断？
• 偏差是否可解释：计划与实际为何不同，差异影响哪个里程碑，是否存在未决依赖？
• 下一步是否明确：谁在什么时间前采取什么动作，动作完成后由谁确认？

如果一条记录只能回答“今天做了什么”，不能回答“项目因此改变了什么”，它对项目推进的价值就有限。日报可以记录活动，进度日志必须记录状态变化和决策依据。

3. 先约定统一的状态语言

团队常把“进行中”“基本完成”“待联调”当作状态，但这些词没有统一口径时，跨部门讨论会不断发生翻译成本。建议至少定义未开始、进行中、待外部输入、待验收、已完成、已阻塞六类状态，并为每一类写清进入条件。

这些状态不是为了把所有工作硬塞进流程，而是为了让“等待”与“执行”分开。项目负责人看到“待外部输入”时，应立即判断依赖是否有负责人、时限和升级路径，而不是把它误当成普通的进行中工作。

二、背景和真实场景：跨部门项目为何容易“看起来正常”

1. 交付链条长，状态在交接点丢失

以一个包含产品、研发、测试、运营和采购的上线项目为例，产品提交需求后，研发需要确认接口与范围，测试需要准备数据和环境，运营需要审核话术，采购可能还在等待供应商交付。每个团队各自完成局部工作，并不意味着整个交付链条已经向前移动。

最危险的地方通常是交接点。研发认为“已提测”就是完成，测试认为“环境可用且需求冻结”才算开始；运营认为“收到最终功能说明”才可以准备公告。日志若只登记每个团队的任务完成率，就容易出现所有部门都报进展、关键路径却没有推进的情况。

我会把交接信息单独写清：输入是什么、由谁提供、接收方何时确认、未确认会影响什么。这样做看似增加了几行记录，实际上减少了反复开会确认“现在卡在哪”的时间。

2. 汇报频率不等于控制能力

每日更新并不自动带来更好的项目控制。对于变化很少、周期较长的工作，每天重复填写“持续推进”只会增加维护成本；对于上线前的联调和验收，即使每天只更新一次，也可能错过需要当日处理的阻塞。

更新频率应跟风险和变化速度匹配，而不是机械地定成每天或每周。若某工作项处于关键路径、依赖多人确认，或者偏差会在几个工作日内传导到里程碑，就需要更密集地更新；稳定且独立的工作，则可以按阶段更新。

3. 日志的读者不只有项目经理

团队成员想知道自己下一步做什么；部门负责人关心资源冲突和交付风险；高层关心里程碑、范围和决策；客户或业务方关注承诺是否改变。把所有人塞进同一张长表，结果常常是字段很多、没人愿意读。

我的做法是保留一份事实源，再按角色呈现不同视图。事实源保存工作项、状态变化、证据、责任人和更新时间；项目视图呈现关键路径和风险；管理视图只呈现需要决策的偏差；执行视图则关注待办和依赖。同一事实可以有不同视图，但不能有多套互相冲突的事实。

4. 从轻量表格到协作平台，关键在于规模和治理

十几人的短周期项目，使用共享表格可能足够；当项目扩展到多个部门、多个产品线，或组织中有 100 人以上参与协作时，权限、历史变更、跨项目依赖和指标口径会变得更重要。此时，某项目管理平台可以承载工作项、状态流转、讨论、版本和报表，但工具不能替代规则。

例如，组织选择 PingCode 时，应把它看作协作基础设施的一部分，而不是“启用后自动透明”的解决方案。对于中大型企业和 100 人以上组织，评估重点通常包括团队规模下的流程治理、权限边界、部署方式、历史数据迁移和跨团队视图。若涉及数据合规，可核实私有化部署的具体方案、运维责任和升级机制；若从 Jira 迁移，也应先对工作项类型、字段、权限、附件和历史记录做映射验证，而不是只确认能否导入数据。

是否适合，仍需以实际需求、合同条款和验证结果为准。

三、常见误区：为什么日志越写越多，项目反而越不透明

1. 把百分比当成客观进度

“完成 90%”听起来精确，实际往往缺乏可复核口径。一个界面开发任务可能剩下 10% 的异常处理，却占掉大部分联调时间；一个审批流程可能前期完成了大部分材料，最后仍卡在关键决策人确认。

百分比可以用于工作量粗估，但不应单独作为项目健康度。若团队确实需要百分比，应先定义计算依据，例如按可验收子项数量、工时估算或已通过检查点计算，并标注方法。不同工作项的百分比不能未经说明直接相加，得出项目整体完成率。

2. 把“没有更新”解释成“没有问题”

未更新不是绿色状态，而是未知状态。负责人忙于执行、忘记更新，和工作顺利推进，在日志里看起来可能完全一样。项目管理者若默认“没消息就是正常”，就会把数据缺口误当成健康信号。

我建议把“最后更新时间”作为风险判断的一部分。关键路径工作项超过约定时限未更新，应触发提醒或核实；但提醒不等于直接判定延期。系统或模板可以标记“需确认”，由负责人补充事实后再确定状态。

3. 把风险写成模糊名词

“存在资源风险”“沟通风险较高”“可能延期”都不能直接指导行动。风险至少要写出触发条件、可能影响和应对动作。例如：“若周三前未拿到供应商测试凭证，联调将推迟两个工作日；采购负责人周二下班前确认交付时间，若无法确认则启用备用接口。”

如果影响尚不能量化，也应说明判断依据和下一次评估时间。与其假装知道精确延期天数，不如明确不确定性来自哪里、需要什么信息才能缩小判断范围。

4. 把会议纪要复制进进度日志

会议讨论很重要，但并非每句话都应进入日志。把整段讨论原样搬进去，会让关键状态淹没在上下文里，也容易出现记录很长、责任不清的情况。

建议将会议结论拆成三类：状态变化、待办行动、正式决策。背景讨论和争议过程可以链接到会议记录；日志保留结论、责任人、截止时间和影响范围。这样既保留追溯性，又避免把进度页做成聊天记录仓库。

5. 只统计完成项，不看未完成项的年龄

完成数量增长不一定代表流程变快。若一批待验收工作在队列里停留两周，新增完成项可能只是掩盖了验收瓶颈。项目管理者需要观察未完成工作项的停留时间、阻塞时长和重开比例。

尤其要关注“长期进行中”的项目项。连续多周处于进行中，往往说明任务切分过大、验收条件不清，或负责人同时承担太多工作。与其增加催办频率，不如拆小工作项或移除依赖。

四、专业判断逻辑：怎样判断偏差、风险与更新频率

1. 先看承诺基线，再看当前状态

没有基线，就无法区分“变化”与“正常波动”。基线至少要包括计划交付日期、范围、关键验收条件、主要依赖和负责角色。基线不必复杂，但变更必须留下记录：谁提出、为什么改变、影响了什么、由谁批准。

计划经常变动时，不要偷偷覆盖旧日期。保留原计划、当前预测和变更原因，可以判断团队是在合理调整，还是反复通过改日期掩盖执行偏差。关键不是永远不改计划，而是让计划变化可解释、可追溯。

2. 将偏差分成四种，不要一律归咎于执行慢

同样是延期一天，原因不同，处理动作可能完全相反。产能不足时加会并不能增加产能；范围持续扩张时单纯催开发可能制造返工；质量问题未解决时强行标记完成，则会把风险推到更昂贵的后续阶段。

3. 风险优先级要看影响、临近程度和可逆性

我通常用三个问题给风险排序：若发生，会影响哪个里程碑或业务结果？距离触发点还有多久？现在采取行动能否避免或降低损失？一个影响大、触发时间近、可通过当前行动缓解的风险，应先于影响小、时间远且已有备用方案的风险处理。

不必为每个项目建立复杂评分模型。团队可以使用高、中、低三级，但必须写出判断依据。若风险等级连续多周不变，却没有行动或复核时间，等级就失去管理意义。

4. 更新频率应由信号触发，而不是由日历决定

正常执行阶段可以按周更新；关键路径接近里程碑时提高到每日或每两日；一旦发生阻塞、范围变化、验收失败或预测日期变化，应立即更新，不等到例行汇报。这样既能避免无效填报，也不会让高风险事项滞后一周才被发现。

可以把触发规则写进项目约定：关键工作项超过两个工作日未更新，标记待确认；阻塞超过一个工作日，通知项目负责人；预测交付日期晚于基线，要求说明影响和决策选项。阈值需按项目节奏调整，不应拿一套规则套所有团队。

五、实操案例：从一份“全绿日报”找出真正的交付风险

1. 案例边界与样本说明

以下是匿名化的情景复盘，用于展示分析方法，不代表特定企业真实绩效，也不应当被当作行业基准。项目设定为一个需要产品、研发、测试、运营和供应商协作的功能上线，原计划六周完成，项目组约 30 人，关键链路包括需求冻结、接口交付、环境准备、联调、验收和发布。

项目每周汇报时，团队曾连续两周报告“整体进度约 75%，暂无重大风险”。但项目负责人检查日志后发现：研发记录了“接口已完成”，测试记录仍显示“等待接口样例”；运营已经开始准备上线材料，却没有最终验收日期；供应商只口头承诺交付时间，没有书面确认。

问题并非谁在说谎，而是团队用不同的完成定义、不同的信息来源和不同的更新节奏描述同一条链路。项目看板上的绿色状态反映的是各团队对局部任务的判断，不是端到端交付能力。

2. 把口头状态重写为可验证记录

项目负责人先不讨论“谁报错了”，而是将三条关键工作项重新核验。接口交付需要有接口文档、样例数据和研发确认；测试启动需要环境可用、账号权限生效和验收条件稳定；上线材料需要确认功能范围、发布时间和业务负责人。

原来一行“接口完成”的记录被改成：“接口文档已提交，测试环境尚未验证，样例数据缺两个边界场景；研发负责人周二 16:00 前补齐，测试负责人收到后确认可测；若周三中午前未通过，联调里程碑预测顺延两天。”这条记录没有增加多少文字，却把证据、责任、时限和影响说清楚了。

3. 用依赖关系代替部门完成率

接下来，项目组将主要节点按先后关系排列：需求冻结后接口才能稳定，接口和环境就绪后才能联调，联调结果通过后测试才能完成验收，验收日期确认后运营才能锁定发布材料。团队发现，真正决定发布日期的并不是单个部门的任务完成率，而是这条依赖链上的最迟完成项。

这也是跨部门项目中一个容易被忽略的判断：每个部门都很忙，不等于项目正在向交付靠近。若多个团队同时开启大量任务，但关键输入尚未具备，工作量会增加，等待和返工也可能同步上升。

4. 用决策选项代替单一的“会延期”结论

项目组把风险上报时，提供了三个选择：保留完整范围并将发布预测顺延两天；如期发布但暂缓一个非关键功能；增加一名熟悉接口的工程师参与联调，但需要确认其从其他工作中释放的时间。管理者因此能够讨论成本、范围和时间的取舍，而不是只收到“有风险，请支持”的模糊请求。

模拟复盘中，项目最终选择暂缓非关键功能，并把测试环境准备提前到下一阶段的计划检查点。这个结果不能证明某种方法必然减少延期，但说明日志的价值不只在于发现问题，还在于把问题转换成可比较的决策选项。

5. 复盘要问流程为何失效，而不只问谁没更新

项目结束后，团队检查了四件事：完成定义是否统一、关键依赖是否有负责人、风险是否在触发前被升级、预测变化是否保留历史记录。复盘重点不是给日志填写者打分，而是找出为什么信息直到临近联调才被拼起来。

若问题来自模板没有“等待对象”字段，应改模板；若责任人不知道何时必须更新，应调整协作约定；若负责人有信息但没有决策权限，应设计升级机制。把所有问题都归为“大家要提高意识”，通常意味着流程没有真正改进。

六、进度日志全流程：从计划建立到复盘沉淀

1. 启动前：定义记录对象和基线

开始记录之前，先决定日志的最小单位。通常以可交付工作项为宜，避免以“某部门本周工作”这种过大的对象作为记录单位。每个工作项至少有唯一名称、负责人、验收条件、计划日期、依赖项和状态。

• 把业务目标拆成阶段交付物，而不是只按部门罗列任务。
• 明确范围边界和验收人，未确定的内容标记为待确认。
• 记录计划日期、关键依赖和风险触发条件。
• 确认谁可以更改基线，变更需要留下什么依据。
• 约定不同状态的进入与退出条件。

工作项拆分不必追求越细越好。若一项工作预计持续数周、中间没有可检查的阶段成果，就应该拆分；若拆分后每项都只是几小时的琐事，且没有独立验收价值，则会造成维护负担。

2. 执行中：记录状态变化，不抄写全天活动

每次更新只需说明自上次记录以来发生了什么变化：交付物提交、验收通过、依赖到达、风险触发、日期预测变化或阻塞解除。没有变化时，可以保留原状态，但应按约定确认信息仍然有效，避免长期没有更新被误读为正常。

对于关键工作项，建议把证据链接放在日志附近，例如需求版本、测试结果、审批记录或交付文件。链接的作用不是增加形式，而是让审核者可以从“状态描述”快速追到“判断依据”。敏感信息应遵守组织权限规则，不能为了透明而扩大不必要的访问范围。

3. 发现偏差：先核实事实，再讨论责任

当预测日期变化或工作项停滞时，项目负责人应先确认三个事实：当前交付物在哪里、下一步依赖谁、原计划和当前预测差多少。只有事实明确之后，才讨论是否需要加资源、调整范围或改变顺序。

如果原因仍不明，应在日志中如实标记“待核实”，同时指定核实人和截止时间。把未知情况写成确定结论会误导决策；完全不记录未知情况，则会让管理者错过补充信息的窗口。

4. 需要升级时：把问题包装成决策，而不是求救

升级信息至少包含问题、影响、可选方案、建议选项和决策期限。比如：“供应商接口预计晚三天，若按原范围执行将影响联调；方案一是推迟发布，方案二是先上线不依赖接口的功能，方案三是安排备用方案但增加约两个人日工作量。建议采用方案二，请周三中午前确认。”

这类记录让决策者知道自己需要决定什么，也让项目组知道决策未完成时采取什么临时措施。升级不是把责任向上推，而是把超出团队权限的选择及时送到有权作出取舍的人手中。

5. 里程碑结束后：关闭状态并沉淀可复用信息

阶段结束时，应确认交付物是否验收、未完成项是否转入下一阶段、风险是否关闭或继续跟踪。不能因为项目进入下个阶段，就把未完成工作从视图里消失；未完成项要保留责任人、影响和新的时限。

复盘只保留有改进价值的结论。比如接口交付缺少样例、测试环境准备晚于联调启动、验收人没有提前排期。这些结论要转成模板、检查点或规则；只写“加强沟通”“提高责任心”，无法指导下一次协作。

七、不同情况下的行动建议：让记录服务于当下的项目状态

1. 项目刚启动：先少字段，建立稳定习惯

新团队不要一开始就设计十几种状态和大量必填字段。先让成员稳定填写交付物、负责人、状态、计划日期、依赖、最新证据、下一步和风险。运行两到三周后，再根据实际决策需要增加字段。

启动阶段最重要的是统一词义和责任边界。若成员不知道什么叫“已完成”，系统字段再完整也只是把分歧固化。项目负责人可以选取五个真实工作项做校准，让不同团队分别判断状态，再讨论定义差异。

2. 项目依赖多：把等待对象和最迟输入时间单列

依赖复杂时，普通任务列表不够用。每个依赖都需要提供方、接收方、所需内容、最迟输入时间、确认方式和替代方案。若一个工作项依赖多个团队，应标注哪个依赖在关键路径上，而不是只写“等待其他部门”。

项目负责人还应检查依赖是否形成闭环：请求是否送达、对方是否接受、输入是否满足使用条件。口头承诺不等于依赖已解决，文件收到也不一定意味着内容可用。

3. 项目临近上线：优先管理变化和验收队列

临近上线时，重点不应只是“今天又完成了多少项”，而是新增变更、未验收交付、严重缺陷、回归结果和发布条件。此阶段变更会迅速影响测试与运营安排，任何范围变化都应说明是否进入当前版本。

把待验收工作集中呈现，明确验收人和反馈时限。若验收排队，应调整交付批次或提前安排验收资源，而不是让所有工作都在最后一天集中提交。

4. 管理层需要周报：只呈现需要关注的变化

管理层视图不应复制所有执行日志。建议只列本周里程碑变化、预测日期变化、最高优先级风险、需决策事项和资源冲突。稳定且无异常的工作可以汇总，不必把每个细节都推到高层。

当管理层看到大量红色事项却没有明确请求，容易形成“问题很多但无从处理”的局面。每个升级项应写清谁能决策、最晚何时决策、延迟决策的后果是什么。

5. 多项目并行：从工作项数据转向容量和冲突管理

多个项目争用同一批关键人员时，单个项目的日志看不出整体过载。需要在组合视图中观察关键岗位的排队工作、优先级冲突和承诺日期重叠。此时应避免用“每个项目都绿色”的局部状态推断组织有足够产能。

跨项目治理通常需要更稳定的数据模型、权限管理和历史追踪。中大型组织可以评估某项目管理工具或某项目管理平台是否支持统一工作项、项目间依赖、角色权限、审计记录及所需部署方式。若考虑 PingCode，应在真实流程中验证团队视图、数据管理要求和迁移路径，并针对 Jira 平滑迁移做字段映射、权限校验和历史数据抽样验收；“支持迁移”不等于所有旧流程无需调整，也不等于自动满足每个组织的合规要求。

八、不同情况下的取舍：完整、及时、轻量不能同时无限增加

1. 更新频率与维护成本的取舍

每日更新适合变化快、影响大的关键工作项，但会增加执行者维护负担；每周更新更轻量，却可能延迟发现阻塞。合理做法不是给整个项目规定唯一频率，而是按工作项重要性分层：关键路径高频、一般任务常规、稳定事项按节点核验。

2. 细粒度与可读性的取舍

任务拆得太粗，问题隐藏在“进行中”里；拆得太细，团队花大量时间维护琐碎记录。一个实用判断是：这项工作是否能独立验收，是否有明确负责人，是否可能独立影响里程碑。若三项均是否定，通常不需要单独成为进度日志的主体。

3. 透明度与信息权限的取舍

跨部门透明不等于所有人查看所有内容。人员信息、商业资料、客户数据和安全事项可能有访问限制。日志应让相关角色看到推进工作所需的信息，同时遵守最小权限原则。敏感内容可以通过受控链接引用，不应把不必要的细节复制到开放页面。

4. 工具自动化与人工判断的取舍

自动化适合提醒逾期、汇总状态、记录变更、展示依赖和生成周期统计；但自动化无法可靠判断一段模糊描述是否意味着真实阻塞，也无法替代管理者权衡范围与日期。对于复杂风险，系统可以提示“预测日期变化”或“长时间未更新”，由负责人核实后作出判断。

选工具时应先验证核心流程，再讨论界面和功能数量。最小验证场景包括：创建跨部门工作项、更新状态、追踪依赖、保留历史、做权限隔离、生成管理视图和导出必要数据。若要私有化部署、迁移历史系统或进行国产替代评估，还应核实部署架构、升级流程、数据迁移范围、接口能力、运维责任和供应商服务边界，并以试点结果而非宣传描述作为判断依据。

九、落地模板与检查清单：让团队从下一次更新开始改进

1. 一条进度日志至少写清八项信息

以下字段足以覆盖多数跨部门项目的核心追踪需求。若组织已有系统，可映射到现有字段；若使用共享文档，也可以从这份清单开始，不必一次性建立复杂流程。

• 工作项：要交付的具体结果，而不是笼统活动。
• 负责人：对下一步推进负责的角色，必要时标明协作方。
• 当前状态：按团队统一定义选择，不用模糊词替代。
• 计划基线：原计划日期及已批准的变更。
• 当前预测：基于现有信息估计的完成日期。
• 证据或链接：可用于核实状态的交付物、结果或确认记录。
• 依赖与风险：等待对象、触发条件、影响范围和缓解方式。
• 下一步行动：责任人、截止时间和完成后的确认方式。

2. 用一条记录模板减少模糊表达

模板不应该变成每个人都机械填满的表单。团队可根据实际场景调整，但要保留事实、影响和行动这三层信息。下面的模板可直接用于项目复盘或周度更新。

工作项：
负责人：

当前状态：

本次状态变化：

验收条件：

计划完成日期：

当前预测日期：

证据或交付物链接：

依赖对象及最迟输入时间：

风险与对里程碑的影响：

下一步行动：

行动负责人及截止时间：

需要的决策或支持：

3. 每周用十分钟做一次日志质量抽查

项目负责人不必逐条重写团队记录，可以每周随机抽查关键路径、最长停留和最近变更的工作项。抽查时问：能不能找到证据？下一步是谁负责？日期变化有依据吗？等待是否已通知对方？若连续几次回答都是否定的，问题通常在流程定义或责任机制，而不只是个人填写习惯。

（1）抽查关键路径

确认最影响里程碑的工作项是否有当前预测、依赖和风险行动。关键路径上若存在未核实信息，应明确补充责任人和时限。

（2）抽查长期停留项

检查停留超过团队约定时限的事项，判断应拆分、升级、等待外部输入，还是调整优先级。不要仅靠批量提醒来解决长期滞留。

（3）抽查变更历史

核对日期、范围和状态变化是否保留原因。若计划已多次移动但没有变更依据，应重新建立可信的预测基线，而不是继续沿用已经失真的计划。

4. 用少量指标观察机制是否在改善

指标应帮助团队提出问题，而不是制造新的填报任务。建议先观察四类指标：关键工作项更新及时率、阻塞平均处理时长、待验收工作项停留时间、预测日期变更次数。每个指标都需要明确分母、统计周期和适用范围，否则不同项目之间容易被错误比较。

例如，“更新及时率”可以定义为在约定窗口内更新的关键工作项数量除以应更新数量；“阻塞处理时长”可以从状态进入已阻塞开始，计算到阻塞解除或决策完成。指标连续两三个周期变化后，再判断机制是否有效，不要因为单周波动就立即改流程。

十、最后的判断：让日志记录变化，让团队处理变化

1. 从一个关键项目开始，不要先推广全组织

选择一个跨部门依赖明显、周期适中、愿意复盘的项目试点。先统一状态定义、工作项拆分和更新触发条件，再观察两到四周。试点的目标不是证明某个工具正确，而是找出哪些信息缺失会导致项目迟决策、重复确认或返工。

2. 用问题变化评估价值，而不是用填报量评估价值

如果日志上线后，团队只是多填了字段，却仍要靠会议临时拼进度，说明事实源没有建立；如果阻塞更早暴露、依赖责任更清楚、管理层能更快作出范围或资源取舍，才说明记录机制开始产生价值。填报完成率只是过程信号，不是交付结果。

3. 把日志当作团队共同维护的决策记忆

最值得保留的不是“某人某天做了什么”，而是项目何时发现风险、依据什么调整预测、做了什么取舍、结果如何。这样的记录能帮助团队在下一次相似项目中少踩坑，也能在人员变动时保留必要的上下文。

我的最终判断是：好的进度日志不会让所有项目都变成绿色，它会让红色更早出现、原因更容易验证、选择更容易比较。下一步可以先拿一个正在进行的跨部门项目，抽查关键路径上的五条工作项；如果其中两条无法回答“证据在哪里、谁在等待谁、下一步何时完成”，就从这五条开始重写记录，再决定是否扩展到整个项目。