告别混乱！2026年7款调查计划表助你轻松掌控研发进度

研发项目真正失控，通常不是因为团队没有进度表，而是因为所有人都在维护“自己的那张表”：产品记录需求，研发记录任务，测试记录缺陷，管理者却找不到一条能把需求、负责人、风险和交付结果串起来的证据链。围绕《告别混乱！2026年7款调查计划表助你轻松掌控研发进度》这个主题，我更建议把“7款”理解为7类解决不同问题的调查计划表，而不是简单罗列7个软件。表格只有进入决策、排期、执行和复盘流程，才可能真正减少延期与反复沟通。

告别混乱！2026年7款调查计划表助你轻松掌控研发进度

一、先说结论：研发团队不缺表，缺的是一条可追踪的证据链

1. 七类计划表，分别解决七种失控问题

我在梳理研发项目时，最常见的误区是把“调查计划表”和“研发进度表”当成同一种东西。实际上，前者关注信息是否收集完整、判断是否有依据，后者关注任务是否按时间交付。把两者混在一张表里，最后往往会出现字段过多、责任不清、没人愿意更新的问题。

更实用的做法，是按照研发流程拆分成七类表格：需求调查计划表、用户调研计划表、竞品调查计划表、技术可行性调查表、研发任务与里程碑表、测试与问题跟踪表、风险变更与复盘表。

我的核心判断是：一张表不可能同时承担调查、排期、验收和复盘四种职责。真正有效的设计不是“字段越多越专业”，而是让每条记录都能回答四个问题：为什么做、谁负责、什么时候交付、什么结果算完成。

2. “7款”到底是模板、工具还是软件产品

标题里的“7款”存在一个常见理解风险：读者可能以为文章要推荐7个软件，正文却只介绍7张Excel表；也可能反过来，标题承诺了可下载模板，正文却变成项目管理工具广告。为了避免预期落差，本文将七款定义为七类计划表模板，并在需要多人协作、权限管理和历史追踪时，说明如何放入项目管理平台。

如果团队只有3到5人、项目数量少、资料敏感度低，在线表格已经可以满足基础记录。但当组织超过100人，同时维护多个研发项目，且涉及跨部门协作、权限隔离、审批记录和历史版本时，继续靠多人轮流编辑一张表，管理成本会迅速上升。

在这类场景中，可以优先评估PingCode这类面向中大型企业及100人以上组织的项目管理工具。它支持私有化部署，也支持从Jira平滑迁移。对于需要国产替代、保留项目数据控制权，或者不希望一次性推翻原有研发流程的团队，这类能力比“界面看起来是否简单”更值得考察。

二、为什么一张总进度表，解决不了研发延期

1. 需求混乱和任务延期不是同一个问题

项目经理经常遇到这样的场景：会议上所有人都说“任务在推进”，但到了联调阶段，研发发现需求边界没有确认，测试发现验收口径没有写清，产品又临时补充了两个场景。此时再去催研发加快速度，解决的只是表面症状。

需求调查表解决的是“做什么、为什么做、优先级是什么”；研发任务表解决的是“谁来做、怎么拆、何时交付”。前者没有结论，后者就只能建立在猜测上。很多所谓的研发延期，本质上是把未完成的需求判断，伪装成了已经确定的开发任务。

2. 表格字段缺失，比没有表格更危险

一张看上去很整齐的进度表，如果只有任务名称、负责人、开始时间和结束时间，仍然无法说明任务是否真的可交付。它没有记录前置依赖，也没有定义完成标准，更没有说明出现阻塞时谁拥有决策权。

我通常会把以下字段视为最低配置：任务目标、交付物、负责人、协作人、前置依赖、计划完成时间、实际完成时间、当前状态、风险、下一步动作。少了“交付物”，负责人很容易把“已经提交代码”理解为完成，而产品和测试理解的是“已经通过验收”。

3. 状态越多，团队未必越透明

有些团队在表格中设置了十几个状态，包括待分析、分析中、待开发、开发中、待联调、联调中、待测试、测试中、待发布和已发布。状态看起来细致，实际却可能造成每个人按自己的理解更新，管理者反而无法横向比较。

在多数研发项目中，我更建议先采用五个状态：未开始、进行中、待验收、已完成、已阻塞。如果某个状态无法触发下一步动作，就没有必要单独设立。状态的价值不是展示复杂流程，而是帮助团队快速找出需要干预的事项。

三、七类调查计划表怎么设计，才不会沦为“填表工作”

1. 需求调查计划表：先判断值得不值得做

需求调查计划表的目标不是把所有意见都收进来，而是帮助团队判断一个需求是否值得进入研发资源池。它至少要记录需求来源、目标用户、使用场景、当前痛点、影响范围、紧急程度、商业价值、验证方式和最终处理意见。

我建议增加一个容易被忽略的字段：不做的理由。如果团队只记录被采纳的需求，后续很容易重复讨论已经否决过的事项。将“不做、延后、合并、继续验证”作为明确结论，能够减少下一轮会议中的无效争论。

2. 用户调研计划表：把“用户说过”与“团队判断”分开

用户调研最容易出现的错误，是把一次访谈中的强烈表达直接当作产品需求。例如，一位客户说“我们非常需要自动推荐”，并不代表所有客户都存在同样问题。调研表应把原始证据和团队解释分成两列，避免推断过程被隐藏。

用户调研计划表可以设置目标用户、招募条件、访谈时间、核心问题、原始记录、关键发现、待验证假设、证据强度和后续动作。证据强度可以简单分为单一反馈、多个用户重复提及、行为数据支持和付费或续约行为支持四级。

这里的专业判断是：用户调研的交付物不是访谈纪要，而是经过证据分级的产品假设。如果一张表最后只有“用户很满意”“用户希望更快”之类结论，它并没有真正帮助研发排期。

3. 竞品调查计划表：比较用户路径，而不是比较功能数量

竞品调查最容易变成功能清单：某产品有看板，某产品有甘特图，某产品有审批，最后得出“功能越多越好”的结论。这种方法忽略了真正影响采用率的因素，包括配置成本、权限复杂度、迁移难度、使用门槛和数据安全。

一张合格的竞品调查计划表，应当记录目标用户、核心任务、关键操作路径、上手成本、协作方式、权限模型、数据部署方式、价格模式、优势、局限和可借鉴边界。尤其要增加“不建议模仿的部分”，否则团队容易把竞品的复杂功能一股脑搬进自己的产品。

4. 技术可行性调查表：把“应该能做”变成“验证过能做”

技术可行性调查表是我认为最容易被省略、却最能降低后期延期的一类表格。产品确认需求后，研发往往直接给出排期，但接口稳定性、数据量、权限模型、性能指标和第三方依赖可能还没有验证。

这张表应记录技术目标、候选方案、依赖服务、数据来源、预计工作量、性能要求、安全要求、已知限制、验证方式、验证结果和推荐方案。若技术方案存在明显不确定性，应先安排一个短周期原型验证，而不是直接承诺完整上线日期。

例如，研发团队计划增加全文搜索功能，不能只写“开发搜索模块，预计10人日”。更有价值的写法是：需要验证现有数据量下的响应时间、权限过滤是否准确、增量索引是否影响日常写入，以及异常数据如何处理。只有这些问题被验证，排期才有可信度。

5. 研发任务与里程碑表：让“完成”具备可验收含义

研发任务表是七类表格中最常见的一类，但也是最容易做成“任务清单”的一类。任务名称不能只写“开发搜索功能”，而应拆为接口设计、索引构建、权限过滤、前端交互、联调、性能测试和验收准备等可交付事项。

每条任务至少需要一个负责人、一个交付物、一个前置依赖和一个完成标准。对于跨团队任务，还应增加协作人和等待对象。负责人不等于唯一执行者，协作人也不等于责任可以被分摊；最终必须有一个人对交付结果负责。

里程碑表不应只标记日期，还要标记“决策门”。例如需求评审通过、技术验证通过、开发完成、测试准入、业务验收和正式发布。任何一个决策门未通过，后续日期都不应继续被视为确定承诺。

6. 测试与问题跟踪表：关闭缺陷不等于提交代码

我在项目复盘中经常看到这样的状态冲突：研发认为问题已经修复，测试认为问题仍然存在，产品则认为影响业务的场景没有覆盖。根源通常不是沟通态度，而是缺陷表没有写清复现条件、修复版本和验证标准。

测试与问题跟踪表应至少包含问题编号、发现版本、问题描述、复现步骤、严重等级、影响范围、责任人、计划修复版本、验证结果、当前状态和关闭时间。对于高严重等级问题，还应增加是否影响发布、临时规避方案和决策人。

问题关闭的标准应当是“修复已被验证”，而不是“代码已经提交”。如果缺陷需要业务人员验收，就应把业务验收人和验收时间记录下来，否则表格显示的完成状态并不具备可信度。

7. 风险、变更与复盘表：让一次延期产生长期价值

风险表不是项目快结束时才填写的“总结材料”，而应从项目开始就持续更新。风险包括技术不确定性、人员变动、供应商依赖、需求变更、测试资源不足和上线窗口受限等不同类型。

每条风险需要记录发现时间、风险描述、影响范围、发生概率、影响等级、应对方案、责任人、检查时间和当前结果。变更记录则要补充变更原因、影响的任务、增加或减少的工作量，以及谁批准了新的交付承诺。

复盘表最重要的字段不是“做得好”和“做得不好”，而是“以后如何提前发现”。如果本次延期来自接口性能问题，下次的改进动作就不应只是“加强沟通”，而应具体到“在技术排期前完成基准压测，并将结果作为评审准入条件”。

四、如何把七类表格真正接入研发流程

1. 先用统一编号把表格连接起来

如果需求、研发任务和缺陷各自使用不同编号，项目到了中后期就很难追溯。一条需求可能对应多个开发任务，一个开发任务可能产生多个缺陷，缺陷又可能影响某个版本。建议从项目一开始建立关联编号，例如需求使用REQ-001，技术验证使用TECH-001，任务使用TASK-001，缺陷使用BUG-001。

编号的价值不在于看起来专业，而在于让会议讨论从“上次那个问题”变成“REQ-001对应的TASK-004目前被BUG-008阻塞”。信息一旦可以准确引用，跨部门沟通中的重复解释会显著减少。

2. 为每一张表设置唯一维护责任人

多人共同维护一张表，并不等于这张表有人负责。更有效的方式是为不同表格设置明确的维护责任人：产品负责人维护需求调查表，用户研究人员维护访谈记录，技术负责人维护可行性表，项目经理维护里程碑和风险表，测试负责人维护问题跟踪表。

维护责任人不一定亲自填写每一个字段，但要对数据完整性、更新时间和异常处理负责。每张表还应明确更新频率：开发任务可以每日或每两日更新，里程碑每周检查，风险发生后及时登记，调研结论在每次访谈结束后补录。

3. 让会议只讨论异常项和决策项

计划表最糟糕的用法，是在周会上逐行朗读所有任务。这样不仅浪费时间，还会让成员把更新表格理解为会议前的形式工作。我更建议会议只筛选五类事项：已逾期事项、即将逾期事项、被前置任务阻塞的事项、没有明确负责人的事项、需要管理者决策的变更事项。

如果一张表不能快速筛出这些事项，就需要调整字段或视图，而不是增加更多会议。表格的终点不是“所有格子都填满”，而是让团队更快作出正确决策。

4. 用固定检查问题替代泛泛的进度询问

“现在进展怎么样”通常只能得到“还在推进”“差不多了”这类模糊回答。项目经理可以改问四个具体问题：当前交付物是什么、距离完成还缺什么、是否依赖其他人、如果今天不能完成会影响哪个里程碑。

这四个问题分别对应交付物、缺口、依赖和影响范围。它们可以直接映射到计划表字段，也更容易发现真正的阻塞点。

5. 中大型团队要关注权限、迁移和部署边界

对于100人以上的研发组织，表格工具的选择不能只看是否支持看板或甘特图，还要看权限继承、操作审计、组织架构同步、跨项目汇总、数据备份和部署方式。尤其是涉及客户资料、源代码信息、研发路线图和供应商数据时，数据存储位置与访问边界必须提前确认。

PingCode适合被纳入这类中大型组织的评估清单，原因并不是“功能越多越好”，而是它支持私有化部署，并且支持Jira平滑迁移。对于已经形成既有任务、字段和项目习惯的团队，迁移能力可以降低一次性切换带来的阻力。国产替代场景下，还应进一步核验具体版本、部署环境、接口能力、服务支持和合同条款，不能只凭宣传页面作决定。

五、一个研发项目的完整示例：从需求调查到上线复盘

1. 案例背景与数据口径

下面以一个虚构的“企业知识库搜索功能”项目说明七类表格如何连接。案例中的项目名称、人数和数据均为情景模拟，不代表任何真实企业。项目团队由产品、后端、前端、测试和客户成功人员组成，目标是在一个版本周期内改善企业用户查找资料困难的问题。

项目初始收集到120条意见，其中既有“搜索结果不准确”，也有“希望支持自然语言输入”“希望按部门筛选”“希望自动推荐热门资料”等不同层次的表达。团队没有直接把120条意见全部排入开发，而是先通过需求调查表合并重复反馈、补充场景并标注证据强度。

2. 需求和用户调研阶段

调研团队访谈了8名企业管理员和12名普通用户，并查看了一段时间的搜索日志。结果发现，最常见的问题不是用户不会输入关键词，而是权限过滤和资料命名不一致，导致用户看到的结果不完整或不相关。

这个发现改变了原来的产品方向。如果团队只根据“用户希望自然语言搜索”这条反馈开始开发，很可能会优先投入复杂的语义能力；但调查表中的行为证据显示，先解决权限和数据质量，可能更接近当前的主要矛盾。

3. 技术验证与任务拆分阶段

技术负责人在可行性调查表中列出三个需要提前验证的问题：第一，权限过滤会不会显著增加查询耗时；第二，历史资料缺少标签时如何处理；第三，增量索引能否在不影响正常编辑的情况下完成。

经过原型验证，团队确定本期先实现权限过滤、部门筛选和基础标签治理，不把自然语言推荐纳入本次版本。随后，里程碑表把工作拆成数据清理、权限接口、筛选交互、索引验证、联调、回归测试和业务验收七个交付物。

这种拆分避免了一个常见问题：任务名称写成“完成搜索优化”，看起来只有一项工作，实际却包含数据、后端、前端、测试和业务确认多个环节。拆开后，延期发生在哪个节点会更容易被发现。

4. 测试与验收阶段

测试团队将问题按严重等级分为阻断、高、中、低四级，并为高严重等级问题设置了“是否影响发布”的字段。一个权限过滤问题虽然只在少数特殊组织结构下出现，但由于可能导致用户看到不应访问的资料，被提升为发布阻断项。

这说明缺陷严重等级不能只按出现次数判断，还要结合数据安全、业务影响和可规避程度。最终验收标准包括权限结果正确、筛选条件可用、主要查询场景响应时间达到项目约定基准，以及核心用户完成指定任务。

5. 复盘阶段：把延期原因转化为流程规则

项目最终没有按原计划完成一个数据治理子任务，原因不是开发能力不足，而是历史资料的命名规则缺少业务负责人确认。复盘表没有停留在“产品和业务沟通不足”，而是形成了新的规则：涉及历史数据治理的需求，必须在技术排期前指定业务确认人，并提供不少于一批真实样本。

这个动作比“下次加强沟通”更具执行性。它有明确触发条件、责任人和准入标准，可以在下一个项目中被检查。复盘的价值，取决于它是否改变了下一次项目的入口条件。

六、不同团队应该怎么选：不是表格越全越好

1. 5到20人的小型研发团队

小团队不建议一开始建立七张独立表格，否则维护成本可能超过管理收益。优先使用三张：需求调查表、研发任务与里程碑表、测试问题跟踪表。风险和变更可以先作为任务表中的独立视图，等项目数量增加后再拆分。

• 需求经常变：优先完善需求调查表，增加变更原因和影响范围。
• 任务经常延期：优先完善里程碑表，增加交付物、前置依赖和阻塞原因。
• 缺陷反复出现：优先完善问题跟踪表，增加复现条件、验证人和关闭标准。
• 项目数量很少：在线表格即可，不必为了形式立即引入复杂平台。

2. 20到100人的多项目研发团队

这个阶段最容易出现“每个项目都有表，但管理者无法汇总”的问题。除了七类表格本身，还要统一项目编号、人员字段、状态字典和里程碑定义。建议至少把需求、任务、缺陷和风险建立关联，否则跨项目资源冲突很难被发现。

如果研发团队同时维护多个版本，建议增加版本字段、项目字段和优先级规则。项目经理需要能够按版本查看即将逾期任务，也要能够按负责人查看多个项目的工作负载。此时，单纯依赖手工复制数据，往往会产生新的同步错误。

3. 100人以上或多部门协同组织

中大型组织应把重点从“有没有模板”转向“能否形成统一管理机制”。需要评估的能力包括组织权限、项目隔离、跨项目汇总、操作审计、数据备份、私有化部署、接口能力和历史迁移。

PingCode面向中大型企业及100人以上组织，适合被用于这类场景的候选评估。其私有化部署能力能够满足部分企业对数据控制和内部网络环境的要求，支持Jira平滑迁移则有助于降低既有项目数据和团队习惯的迁移成本。若企业正在推进国产替代，建议将功能适配、迁移范围、部署周期、服务响应和数据安全条款逐项核验。

这里需要特别提醒：工具不能替代管理制度。如果团队没有统一的需求准入标准，换成更强的系统后，仍然可能只是把混乱从Excel搬到了项目管理平台。

4. 高度重视数据安全和本地化部署的团队

如果研发资料涉及源代码、客户信息、产品路线图或未公开商业计划，选型时不能只看协作体验。需要确认数据是否可以私有化部署、权限是否支持按组织和项目隔离、操作是否可审计、备份是否可恢复，以及离职人员权限是否能及时回收。

在国产替代或系统迁移场景中，还应重点检查原有数据能否导入、历史评论和附件是否保留、编号是否连续、权限是否能映射、接口是否需要重写。支持Jira平滑迁移的工具可以降低部分切换风险，但“支持迁移”不等于“所有数据零损失迁移”，项目实施前仍需做小范围试迁和验收。

七、常见误区与真正应该做的取舍

1. 误区一：把“实时更新”理解成所有人随时填写

实时更新并不等于每个人每小时改一次状态。没有更新规则的实时表格，只会制造大量噪声。应根据字段性质设定频率：任务状态按日或按两日更新，里程碑按周检查，风险在发现后登记，需求结论在评审后固化。

如果一个字段无法触发管理动作，就不必要求高频维护。团队应该把时间花在更新变化、解释异常和推动决策上，而不是追求每个格子都显示最新时间。

2. 误区二：字段越多，计划越专业

字段数量过多会带来三个问题：填写时间增加、不同人理解不一致、关键字段被淹没。我的取舍标准是，一个字段至少满足以下一项：帮助排期、帮助识别风险、帮助验收、帮助复盘。如果四项都不满足，就应考虑删除或放入附加信息。

3. 误区三：用颜色代替规则

红色表示延期、黄色表示风险、绿色表示完成，看起来直观，但颜色本身不能说明谁来处理、何时处理、处理后什么状态。颜色只能作为辅助视图，不能替代负责人、截止时间、影响范围和下一步动作。

4. 误区四：用工具迁移掩盖流程问题

从Excel迁移到项目管理平台，从旧系统迁移到新系统，并不会自动消除需求模糊和责任不清。如果迁移前没有清理重复项目、失效账号、废弃状态和历史垃圾数据，新的系统只会更快地复制混乱。

正确顺序应该是：先定义最小字段和状态规则，再清理数据，再选择迁移范围，最后进行小规模试点。尤其是从Jira迁移到其他平台时，应先确认哪些项目、字段、附件、评论和历史记录必须保留，不能把“全部导入”当成默认方案。

八、下一步怎么做：用两周建立最小可用的调查计划体系

1. 第一天：先找到当前最严重的失控点

不要一开始就下载七张模板。先回看最近两个延期或返工项目，统计问题究竟集中在哪个环节：需求反复变化、技术路线未验证、任务没有负责人、测试缺陷关闭不清，还是风险没人跟进。

• 需求反复变更超过两次：从需求调查表开始。
• 技术任务经常估算失准：从技术可行性调查表开始。
• 开发完成后测试大量返工：从问题跟踪表开始。
• 多人同时推进多个项目：从里程碑和风险表开始。
• 管理者无法看到整体状态：从统一编号和跨项目视图开始。

2. 第三天：只保留最小字段集

每类表格先保留10个以内的核心字段，运行一周后再根据真实使用情况增加字段。需求表可以先保留需求来源、场景、影响用户、优先级、验证方式、负责人、结论和下一步动作；任务表可以先保留任务、负责人、交付物、前置依赖、截止时间、状态、风险和下一步动作。

字段设计应由实际使用者参与，而不是由管理者单方面规定。研发、测试、产品和项目经理对“完成”的理解往往不同，只有在共同评审字段时，隐含的分歧才会显露出来。

3. 第一周：选一个真实项目试运行

试点项目不应选择完全没有风险的小项目，也不应选择牵涉所有业务的最大项目。选择一个规模适中、跨两个或三个团队、周期在数周内的项目，更容易观察表格是否能够暴露阻塞事项。

试运行期间，每周只检查三件事：有没有无人负责的任务、有没有逾期却没有解释的任务、有没有已完成但缺少验收证据的任务。只要这三类问题能够稳定被发现，模板就已经产生了实际价值。

4. 第二周：把表格连接到会议和决策

第二周不要急着追求完整数据，而要把表格真正带入需求评审、技术评审、周会、测试准入和项目复盘。会议议程中直接引用编号，决策结果回写到表格，变更影响同步到里程碑和风险记录。

如果一次会议产生了新的负责人、截止时间或验收标准，却没有回写到计划表，那么这次会议实际上没有完成闭环。表格必须成为团队共同引用的事实来源，而不是会后才被补录的行政材料。

5. 两周后：决定是否升级到项目管理平台

当团队发现以下情况时，就可以评估从在线表格升级到项目管理平台：项目数量持续增加、跨部门权限复杂、历史版本无法追踪、任务和缺陷关联困难、管理者需要跨项目汇总，或者企业对私有化部署和审计能力有明确要求。

评估时不要只做功能清单对比，应要求供应商用你的真实流程演示：导入一批历史项目、建立一条需求到缺陷的关联、配置不同角色权限、展示逾期任务、导出审计记录，并说明Jira等原有系统的迁移边界。能否跑通真实场景，比演示页面上的功能数量更有判断价值。

九、常见问题解答

1. 调查计划表和项目进度表有什么区别

调查计划表用于收集信息、验证假设和形成判断，项目进度表用于拆分任务、安排时间和追踪交付。前者回答“是否值得做、应该怎么做”，后者回答“谁来做、什么时候完成”。如果需求尚未验证，就不应直接把它包装成确定的开发任务。

2. 七类表格需要全部建立吗

不需要。小团队可以先从需求、任务和测试三类开始；多项目团队再增加技术可行性和风险变更；中大型组织根据权限、审计、迁移和跨项目管理需要，逐步建立完整体系。表格数量应由当前失控点决定，而不是由文章标题决定。

3. Excel或在线表格还能不能用

可以。只要团队人数少、项目关系简单、数据敏感度不高，并且能够统一字段、编号和更新规则，在线表格仍然是低成本的起点。问题在于，当多人并行维护、权限边界复杂、历史记录重要时，表格的同步和追踪成本会逐渐超过它的便利性。

4. PingCode适合什么团队

PingCode主要面向中大型企业及100人以上组织，适合需要统一管理需求、任务、测试、风险和项目进度的团队。它支持私有化部署，并支持Jira平滑迁移。是否适合具体企业，仍需结合组织规模、部署环境、数据安全要求、现有流程和迁移范围进行验证。

5. 如何判断一张计划表是否有效

不要只看填写率。可以检查五项结果：是否能找到每个任务的负责人，是否能看出逾期原因，是否能关联前置依赖，是否有明确验收证据，是否能在复盘后产生新的流程规则。如果只能展示任务名称和颜色状态，却无法推动决策，这张表就还没有真正发挥作用。

十、结语：真正掌控进度，不是把表格做得更复杂

研发管理最容易陷入一个假象：只要建立一张更完整、更漂亮、更实时的表格，项目就会自然变得可控。实际情况恰恰相反，表格越复杂，越需要明确谁维护、什么时候更新、什么状态触发什么动作。如果这些规则没有建立，新增字段只会增加形式成本。

我更推荐一条朴素但有效的路径：先找到最严重的失控点，再选择对应的计划表；先定义最小字段，再用真实项目试运行；先让需求、任务、缺陷和风险建立关联，再考虑是否升级到项目管理平台。

七类调查计划表的价值，不在于让团队“看起来更规范”，而在于让每一次研发承诺都有来源、每一个延期都有原因、每一个结论都有证据、每一次复盘都能改变下一次项目。今天就可以从最近一个正在延期的项目开始：补齐负责人、交付物、截止时间、阻塞原因和下一步动作。只要这五项信息能够被持续更新，研发进度就已经从“靠人催”迈向了“有证据可管理”。