使用手册

1 使用对象

这份手册面向已经进入“研发项目管理”应用、准备开始日常使用的人员，重点帮助大家快速弄清楚先做什么、后做什么，以及不同角色平时主要用哪些内容。

1.1 适用角色

1.1.1 研发负责人 / 技术管理者

主要关注项目整体推进情况、团队工作量、延期原因以及当前有哪些事项还没处理完。

1.1.2 项目经理 / 项目负责人

主要负责统筹任务、需求和缺陷的推进，跟进处理进度，确保项目按计划往前走。

1.1.3 产品或需求相关人员

主要负责提出和跟进需求，确认需求是否已经进入研发处理，以及后续处理到哪一步。

1.1.4 开发 / 测试人员

主要负责处理具体任务、反馈缺陷处理进展、提交研发报告，并登记工作时长。

1.2 不同角色怎么分工

2 使用前准备

正式开始使用前，建议先把几个基础口径定下来。这样后面录入的数据才不会越记越乱。

2.1 先明确本次要管理的范围

先统一这套应用要覆盖哪些研发项目，哪些内容需要放进来管理。根据公开信息，这套模板通常围绕以下几类内容展开：

如果团队一开始就把边界说清楚，后面就不容易出现一部分人记系统、一部分人继续记表格的情况。

2.2 先统一记录口径

建议至少先说清楚下面几件事：

2.3 先明确谁来录入、谁来更新、谁来看结果

这一步很重要。手册里不展开权限配置，但业务上最好先约定好：

3 系统入口与导航

说明：当前文档基于公开页面信息整理，未接入真实应用结构，所以这里不编造具体菜单名、按钮名和页面布局。实际使用时，请以你们当前应用里的真实模块名称为准。

3.1 从哪里进入

进入“研发项目管理”应用后，建议先找到两类内容：

如果你是第一次用，不要一上来先看结果页。更合适的顺序是先把基础事项录入和更新跑顺，再看汇总结果。

3.2 日常最常用的入口

业务人员平时最常进入的，一般是下面这些内容：

3.3 不同角色怎么找入口

4 业务操作流程

这部分建议按实际业务顺序来用，不要东一条西一条分散录。

4.1 主流程一：需求进入研发处理

4.1.1 先记录需求

当业务、产品或相关人员提出新的研发需求时，先把需求录入系统。这样后面的讨论、处理和跟进才有统一入口。

4.1.2 再确认需求是否进入处理

需求录入后，由项目负责人或相关处理人跟进需求状态，确认这条需求是否已经安排处理，避免只提了需求却没有后续动作。

4.1.3 处理过程中持续更新

如果需求已经进入研发处理，相关人员要持续补充处理进展。这样后面查看项目进度时，需求部分不会是空的。

4.2 主流程二：任务分配与执行

4.2.1 先建立任务

项目开始推进后，把需要执行的事项拆成任务录入。任务是日常推进里最常更新的一类内容。

4.2.2 再分配给处理人

项目负责人把任务交给对应人员后，处理人就可以围绕这条任务持续更新进度。

4.2.3 处理过程中持续更新进度

任务不是建完就结束了。处理人要在推进过程中持续更新任务状态，让项目负责人能看见哪些任务在推进、哪些卡住了。

4.2.4 任务推进后回看项目完成情况

任务更新积累起来后，负责人就可以从项目完成情况相关页面回看整体推进结果，而不需要只靠口头同步。

4.3 主流程三：缺陷记录与跟进

4.3.1 发现问题先记缺陷

测试或相关人员发现问题后，先把缺陷录进系统，不要只留在聊天记录里。

4.3.2 再跟进处理情况

缺陷录入后，由相关处理人持续更新处理进展。这样后续查看时，能知道问题是刚发现、处理中，还是已经解决。

4.3.3 缺陷处理后继续留痕

即使问题处理完，也建议把相关处理过程留在系统里。后续复盘时，这些记录会更有用。

4.4 主流程四：过程记录沉淀

4.4.1 处理事项时同步补研发报告

研发报告适合记录阶段进展、处理说明和过程情况。不要等项目快结束了再集中补，不然很多细节会丢。

4.4.2 同步登记工作时长

工作时长建议跟着处理动作一起记。这样后面看团队工作量时，数据会更完整。

4.4.3 过程记录沉淀后再看团队投入

研发报告和工作时长持续沉淀下来后，负责人才能更稳定地查看团队实际投入情况，而不是临时去追问每个人做了多少。

4.5 主流程五：项目结果查看与复盘

4.5.1 查看项目完成情况

项目负责人或研发负责人可以定期看项目完成情况，判断当前推进是否正常。

4.5.2 查看团队工作量

如果想看成员投入是否均衡，可以结合工作时长记录看团队工作量。

4.5.3 查看延期原因

如果项目延期，可以结合研发报告和工作时长等过程记录，回看更具体的延期原因，而不是只看到结果。

5 常见操作说明

5.1 新建一条需求、任务或缺陷时怎么做

建议按这个顺序：

5.2 日常怎么更新进度

日常更新时，重点不是“多写”，而是“持续写”。

建议做法是：

5.3 怎么查看整体情况

如果你是负责人，通常可以从以下几个方向看：

5.4 什么时候补研发报告和工作时长更合适

更建议边处理边补，不建议等到周末或月底集中回填。原因很简单：

5.5 一开始最推荐的使用顺序

如果团队刚开始用，建议先按这个顺序跑：

6 常见问题

6.1 为什么系统里看不到想看的结果

通常不是结果页有问题，而是前面的过程记录还没跑起来。比如任务没持续更新、研发报告没补、工时没登记，结果页自然看不全。

6.2 为什么项目进度看起来不准

常见原因有两个：

先把这两个问题解决，整体进度通常会清楚很多。

6.3 为什么团队工作量看不完整

大多是因为工作时长没有及时登记，或者不同成员登记习惯不一致。建议统一登记规则，并尽量边做边记。

6.4 项目延期后该从哪里回看原因

建议不要只盯结果。更有效的做法是结合研发报告、工作时长和事项推进记录一起看，这样更容易找到具体卡点。

6.5 填错了、记重复了怎么办

优先回到原记录处理，不要为了省事再新建一条相似内容。重复记录一多，后面看进度、看工作量、看延期原因都会受影响。

7 使用建议

7.1 先把主线跑通，再慢慢细化

这套模板更适合先把任务、需求、缺陷、研发报告和工作时长这条主线跑起来。不要一开始就追求非常复杂的管理规则。

7.2 负责人与执行人都要参与更新

如果只有负责人在看、没人持续更新过程数据，这套应用的价值会打折。真正好用的前提，是执行过程有人持续留痕。

7.3 定期看，不要等项目出问题再看

项目完成情况、团队工作量、延期原因这类结果查看内容，更适合定期看。等到延期了再回头补数据，通常已经晚了。