简介：《禅道使用手册（完整版）》面向项目经理、产品经理、开发与测试人员，以及需要落地项目协作流程的团队，围绕项目进度跟踪、需求流转、任务分派与缺陷管理提供系统操作参考。资源包共1个docx文档，约4.02MB，以分章节手册形式组织，便于按角色检索和日常查阅。手册从基本介绍、用户角色、最简使用、登录与基本流程讲起，继而覆盖个人待办、我的任务和我的BUG、个人档案维护；产品经理部分涉及产品维护、需求创建评审与变更、需求状态阶段、产品模块、发布计划与发布、需求统计报表；项目经理部分则包含建立项目、组建团队、确定需求列表、任务分解及燃尽图查看进展。已有5219人学习下载，适合初学者建立禅道全流程认知，也适合团队负责人对照角色权限和项目节点查漏补缺。

1. 拿到这份手册先别急着照做：三个信号说明流程已经漏了

接手一个跑了半年的项目库，最怕看到的不是任务多，而是燃尽图一条直线、需求列表里一半挂着"草稿"、bug 列表里同一个问题被激活了四次。前阵子帮一个团队梳理他们的禅道，翻完配置我发现问题不在工具，而在于没人把《禅道使用手册（完整版）》对着自己的流程从头走过一遍。这份 docx 手册按角色切章——基本介绍与登录、个人管理、产品经理、项目经理、开发、测试，把项目管理、需求评审、bug管理三条主干串成一条线。适合刚接手项目库的管理员、准备从 Excel 和邮件迁移的团队，以及要给新人做入职材料的人。它讲的是操作路径，不讲取舍，取舍得自己补。

2. 角色、权限与主干流程：把线下的协作顺序先搬进系统

很多团队上禅道的第一动作是拉全员开账号，然后所有人看到一样的菜单，结果产品经理去改任务工时，开发顺手把 bug 关了，测试去动需求的验收标准。手册在 1.2 节列了五种角色，但没有告诉你权限该怎么收。我的做法是先按角色建组，再把菜单按组裁剪，最后才加人。顺序反了，后面每加一个人都要单独调权限，收不回来。

2.1 五个角色与菜单边界：权限给多了比给少了更难收

手册里的五种角色是系统管理员、产品人员、项目经理、开发人员、测试人员。字面看很清楚，落到配置上容易糊。我一般按下面这张表来划，重点是最后一列——那些"顺手就做了"的越权动作，才是流程乱掉的起点。

产品新建页面上有三个负责人字段，很多人当摆设填。测试负责人这个字段的实际价值在于：当公司人多、提 bug 的人不知道该指派给谁时，系统有个默认落点；发布负责人决定了谁有权限创建发布，这个动作在项目结束后才会用到，事到临头再补权限很别扭。访问控制那一栏也要想清楚，把产品设成私有时，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队能进，其余人连需求标题都看不到。

我踩过一次坑：为了图快，把研发组和测试组挂在同一个权限组下，结果测试能改任务预计工时，燃尽图的数据被改得对不上。后来把"编辑任务"和"编辑需求"两个权限单独拆开，问题才止住。权限这件事的原则是宁可先窄后宽，宽了再收就得罪人。

2.2 六步主干流程与四个卡点

手册 1.4 节给的主干是六步：产品经理创建产品、创建需求、项目经理创建项目、确定项目要完成的需求、分解任务指派到人、测试人员测试并提交 bug。这六步本身没难度，难的是每一步的前置条件。我把它们整理成一张流程表，卡点就在"前置条件"这一列。

四个卡点值得单独说。第一，需求没激活就关联不到项目里，这是新手最常撞的墙——建需求时勾了"需要评审"，但没人去评，需求永远停在草稿。第二，需求关联进项目后如果不分解任务，需求的阶段会一直停在"已立项"，燃尽图上什么都不会动。第三，开发不创建版本，测试就没法申请测试，bug 的"影响版本"字段只能空着，后面排查回归问题没有参照。第四，创建发布的前提有两条：该产品关联过项目，且该项目创建过版本，缺一条"创建发布"就走不下去。

我一般会在项目启动会上把这张表投出来，逐条确认谁来点第一下。不确认的后果是所有人都以为别人会做。

2.3 四种"最简使用"路径：别一次全开

手册 1.3 节给了四种最简用法，这段内容很多人直接跳过，但它其实是最有价值的选型建议。只做产品管理、只做项目任务管理、只做 bug 管理、个人事务跟踪，四条路对应四种不同的起步痛点。

我的经验是从最痛的那一环切进去，跑两周再扩。一次全开的典型结局是全员培训两小时，然后每个人只用自己那一屏，交叉环节全断。曾经有个团队一口气开了产品、项目、测试三个视图，三个月后我去看，项目里的需求和产品里的需求是两套，bug 全靠群里喊——工具没错，是没人负责把中间的连接动作做掉。

2.4 账号与登录入口：一人一号，离职禁用不删除

手册 1.5 节写的登录路径是从办公门户进，先点协同工作区域的图标，再选关联系统，在里面找到相应入口。这个链路决定了账号必须来自统一身份，别在系统里另建一套。

账号命名我建议用工号或姓名拼音，一人一号。共用账号在项目里是灾难：任务指派给"测试组"，出了事谁也不知道是哪个人验的。人员离职时禁用账号，不要删除。禁用的账号在历史记录里还留着名字，删除之后所有他经手的需求、任务、bug 都会显示异常，追溯链断掉。

密码这块没什么可说的，首次登录强制改，别用默认密码跑一个月。手册在个人档案那一节提到可以自行修改密码，入口在"我的地盘"下的"我的档案"。这个页面同时能改邮箱和联系方式，我一般让团队在入职当天把这些填完，后面通知抄送才有落点。

3. 需求侧实操：产品、模块、评审与变更的状态机

需求是整套流程的源头。需求建得糙，后面项目分解、任务指派、bug 归属全会跟着糙。手册第三章把产品经理的动作拆成维护产品、创建评审需求、变更评审需求、状态与阶段、维护模块、发布计划、发布、路线图、文档、统计报表十块，我按落地顺序重排一遍：先把产品和模块骨架立住，再谈需求怎么写、怎么评、怎么改。

3.1 产品与模块：先立骨架再录需求

新建产品时，产品名称、代号、三个负责人、访问控制是关键字段。产品代号相当于团队对这个产品的内部隐喻，手册举的例子是代码名，作用是让口头沟通有个短称呼，不用每次说全名。访问控制如果选私有，后面新来的开发看不到需求是正常的，得把他加进项目团队才行，这一点要在入职时提前说，否则新人第一天的反馈就是"系统里什么都没有"。

模块维护是产品视图里的一个菜单，一级一级往下建。左侧数字是排序字段，调整它就能改模块在树里的位置；编辑某个模块时还能改它的上级模块。手册没写层级限制，但我一般控制在三层：产品—子系统—功能点。建到第四层、第五层的模块树，提需求时没人愿意一层层点开去选，最后"所属模块"全部留空，按模块统计的报表直接废掉。

模块维护还有一个动作容易被忽略：模块是需求的分类维度，不是组织架构。我见过把模块按部门建的，结果一个需求横跨两个部门就不知道往哪放。正确的做法是按功能边界切，一个模块对应一组能被同一个开发看完的功能点。

3.2 需求录入：按功能点拆，不按文档搬

手册说得很直白：按照功能点的方式写需求，把原来需求设计文档里的每个功能点摘出来，录成一条条独立需求。这一步决定了后面能不能跟踪。一整份文档塞进一个需求里，任务没法拆，进度没法算，bug 也没法归。

需求标题是必填项，所属计划和模块可以暂时留空，但我不建议长期空着，漏填的代价在两个月后显现。录入字段的填法我整理成下面这张表：

"不需要评审"那个复选框要慎用。勾上之后新需求直接是激活状态，可以立刻关联到项目里开发。团队三五个人、产品就一个人负责的时候，勾上没问题，效率优先。超过五个人还在勾，等于把评审环节整个跳过，后面需求变更会非常频繁——因为没有人在一开始把"要不要做"这件事拍死。

3.3 评审的四个结果分支：结论要落到状态上

不勾"不需要评审"的需求，创建后进入评审流程。评审页面上的结果有四个走向，每个走向对应不同的状态和指派，这张映射关系必须记住：

参与评审人那一栏，手册说可以输入用户名自动筛选。我的理解是：它记录的是参与名单，不是审批流。现实中评审往往是一个线下会议，系统里只负责把结论和参会人落下来。所以别指望系统帮你催评审，该开会还得开。

"有待明确"这个分支用得好能省很多事。产品有想法但不成熟时，先建成需求走一次评审，被打回草稿，想法留在了系统里，不会因为聊天记录过期而丢掉。我见过把不成熟想法直接建成激活需求的，结果项目经理解释不了为什么这条需求排不进计划，会上吵起来。

3.4 变更流程与影响范围：编辑改不了的东西才是重点

手册里有一个设计细节值得单独拎出来：编辑操作无法修改需求的标题、描述、验收标准和附件。也就是说，这四个字段一旦定了，想改必须走变更流程。变更之后需求状态变成"已变更"，需要再走一次评审。

变更页面会列出这条需求的影响范围，包括关联的任务、bug 和用例。这块信息是给评审人看的，也是给开发测试做确认用的。评审结果同样有四个分支：确认通过则状态从"已变更"回到"激活"；撤销变更则取消本次修改并回退到之前的版本；有待明确打回到变更者；拒绝要写原因。

变更被确认之后，还有一步三方确认：任务确认需求变动、bug 确认需求变动、用例确认需求变动。这三步不做，后果是开发按新需求改了代码，测试还在按旧用例验，提交的 bug 被判为"设计如此"，来回扯。

我一般会要求变更必须写清楚变更原因，哪怕只有一句话。半年后回头查一条需求为什么从"导出 Excel"变成"导出 CSV"，没有原因记录的只能靠猜。

变更时如果勾了"不需要评审"，状态直接变成激活，跳过评审环节。这个开关在小改动上很省事，但也容易变成绕过评审的后门——凡是涉及验收标准变化的，我都要求必须走评审。

3.5 状态与阶段双字段：一个管生死，一个管进度

需求有两个字段在跟踪它，很多人混着看。状态字段管的是需求本身的生命周期，只有四个值：草稿、激活、已变更、已关闭。对应的操作是创建、变更、审核、关闭、激活。阶段字段管的是激活之后在研发过程中走到哪了，共九个值：未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。

阶段基本是系统自动推的，触发条件如下：

只有"已验收"是手工动作，其余都是被动推导。这就带来一个实用技巧：阶段卡住不动，就是排查入口。需求停在"已立项"，说明任务没分解；停在"开发中"很久，去看是不是有测试任务提前开始了；停在"测试完毕"不动，去找产品经理做验收确认。我排查项目进度问题时，第一眼看的就是需求阶段分布，比看燃尽图快。

4. 项目到缺陷：任务分解、燃尽图、提测与 bug 闭环

产品和需求理顺之后，项目和执行这一层才是日常待得最久的地方。手册第四章和第五章分别写项目经理和开发的动作，第六章写测试，我把它们串成一条线：建项目、组团队、关联需求、分解任务、更新进度、建版本、申请测试、提交和验证 bug。

4.1 建项目、组团队与需求关联

建项目要填名称、起止时间和团队。团队这一栏不只是分配任务用的，它还决定了谁能访问这个项目，以及私有产品的可见范围。项目建好之后，第一件事是组团队，第二件事是关联需求。

关联需求从产品的需求列表里挑，也可以跨计划挑。手册里有一句很实在的话：计划和项目并没有非常强的对应关系。理想状态是一个计划对应一个项目，现实是项目关联的需求大部分来自某个计划，同时又夹带其他计划里的几条。我的做法是不强求一对一，但要求每次关联需求时在项目描述里写清楚这一批需求的来源计划，后面复盘能对上账。

团队组建有个细节：项目团队成员会自动获得该项目的访问权限，但不会自动获得产品里其他内容的权限。所以测试人员在项目里能看到需求，回到产品视图可能看不到全部需求列表，这是权限设计的结果，不是 bug。

4.2 任务分解：一到三天的粒度最稳

任务分解是项目经理最核心的动作，也是最容易做成形式主义的动作。手册说分解后指派到人，但没说分解到什么程度。我的经验是按一到三天能做完来切，超过三天的任务继续拆，小于半天的任务合并。

任务类型一般分为设计、开发、测试、事务和其他。类型不是装饰，它影响需求阶段的推导——只有开发任务和测试任务参与阶段计算。所以把测试工作错标成"事务"，需求的阶段永远推不到"测试中"。

指派到人之后，开发每天要做的事就两件：领取任务、更新任务。更新包括已消耗工时和剩余工时，这两个数字直接喂给燃尽图。手册 5.2 节把它列为开发的标准动作，我在实际推行时会把它压进每日站会：站着说完昨天做了什么，顺手在系统里更新掉，不超过一分钟。

4.3 燃尽图与进度列表：看趋势，不看单点

燃尽图是项目视图里的核心图，横轴时间、纵轴剩余工时。它的价值在于趋势，不在某一天的数字。三种异常形态对应三种问题：

第一种是水平直线。剩余工时一直不降，九成是任务没有更新，不是团队没干活。这种情况先查更新记录，别急着开会问责。第二种是尾部翘起。项目后期剩余工时反而上升，通常是中途加了需求或加了返工任务，去查需求关联记录和 bug 数量。第三种是断崖式下跌。某一天大量任务被批量关闭，要么是集中验收，要么是有人在清理数据，两种情况对进度判断的影响完全相反。

除了燃尽图，项目视图下还有各种列表：任务列表可以按人、按状态、按时间筛；需求列表能看阶段分布；bug 列表能看解决情况；项目进展页面把几个维度拼在一起。我在周会上一般只看三样：燃尽图趋势、激活状态的 bug 数量、卡在"测试完毕"的需求条数。

手册 4.7 节提到项目任务的基本报表统计。报表这个功能，用得好是体检报告，用不好就是数字游戏。我的用法是每周固定看一次工时偏差：预计工时和实际消耗差出 50% 以上的任务，逐条问原因，要么是估得不准，要么是中间被插了别的事，两种原因对应两种改法。

4.4 创建版本、申请测试与 bug 流转

开发写完代码不是直接喊测试，而是先创建版本。版本里关联这次要发布的需求和已修复的 bug，填上版本号和发布日期，然后申请测试。测试接到申请才开始验证。这条链路走顺了，bug 的"影响版本"和"修复版本"两个字段才有数据，后面查回归问题时能定位到具体版本。

bug 提交页面的字段不少，真正影响后续流转的是这几个：

bug 的状态流转是：激活 → 已解决 → 已关闭。开发解决时选一个解决方案，常见的有已解决、设计如此、重复 bug、无法重现、不予解决、延期处理。测试验证通过就关闭，验证不通过就重新激活。手册 6.4 节单独讲了激活 bug，这个动作不是"打回"，而是"这个问题还在"，重新激活时要补充新的重现信息，否则开发只会再回一句"无法重现"。

我在多个团队见过同一个翻车模式：开发解决 bug 时不写解决方案，直接改状态。三个月后统计缺陷原因，全是空白。后来强制要求解决方案必填，数据才有意义。

4.5 测试用例与测试任务：把验证标准固化下来

测试视图下的第一件事是维护 bug 视图模块，这个模块树建议和产品模块保持一致，否则提 bug 时选模块要重新想一遍分类。第二件事是建测试用例，用例包含前置条件、操作步骤、预期结果，写用例的过程其实就是把需求里的验收标准翻译成可执行步骤。

用例建好之后是建测试任务：选一个版本、关联一批用例、指派给测试人员、定起止时间。执行用例时逐条标记通过、失败或阻塞，失败的可以直接转成 bug，用例和 bug 之间建立关联。手册 6.7 到 6.9 节讲的就是这条链。

用例库的价值不在第一次执行，在于回归。版本迭代三次之后，老用例还在，新来的测试不用从头问"这个功能以前怎么验的"。我一般要求核心功能的用例必须沉淀，边缘功能可以只留 bug 记录。

5. 避坑排查：把禅道用成 Excel 的五个翻车现场

工具本身不复杂，复杂的是人和流程的惯性。下面五条是我在不同团队反复见到的翻车现场，每条按现象、原因、解决三段写，能对上号的直接改配置。

5.1 需求全堆在草稿，项目里一条都关联不上

现象：产品视图里需求列表很长，但项目经理打开关联需求页面，可选列表是空的。

原因：建需求时勾了"需要评审"，但评审会一直没开，需求状态停在草稿。只有激活状态的需求才能关联到项目，这是硬规则。

解决：先做一次批量清理，把确实要做的需求集中评审通过；再定规则，评审会固定在每周某一天开，超过三天没人评的需求由产品负责人单独拍板。长期方案是把"需要评审"的适用范围写进团队约定，小改动不评，涉及验收标准变化的必须评。

5.2 燃尽图一条水平线，团队其实天天加班

现象：项目进行到第二周，燃尽图的剩余工时几乎没动，项目经理开始怀疑系统坏了。

原因：任务没有更新工时。开发把任务领了，但已消耗和剩余两项一直没填，燃尽图读的是这两个数字，不是代码提交量。

解决：把任务更新压进每日站会，说完就改，一分钟内完成。项目初期我还会每天抽查一次更新时间，连续三天没更新的任务在群里点一次名，一周后习惯就养成了。这件事没有技术手段能替代，只能靠节奏。

5.3 同一个 bug 被反复激活，开发说无法重现

现象：一条 bug 在激活和已解决之间来回跳了四五次，最后不了了之。

原因：测试重新激活时只改了状态，没补新的信息；开发解决时也没写解决方案和修复版本。双方都在用状态表达情绪，而不是用信息推进问题。

解决：把"重新激活必须补充重现环境或新日志"和"解决时必须选解决方案"写成硬规则。系统层面能做的有限，主要靠评审时抽查看字段完整度。另外，重复 bug 和无法重现这两个解决方案要真的用起来，别所有问题都选"已解决"。

5.4 模块树建了五层，提需求时全部留空

现象：按模块统计的需求分布报表里，"未分类"占了一大半。

原因：模块层级太深，提需求的人不愿意一层层点开找，索性不选。模块本来是分类工具，层级一深就变成了负担。

解决：控制在三层以内，产品—子系统—功能点。已经建深的模块树做一次合并，把使用率低的层级拍平。同时规定所属模块为提需求的必看字段，虽然系统不强制，评审时看到空着就打回。

5.5 产品和项目硬绑一对一，需求一改全线乱

现象：一个产品只建一个项目，项目从年初跑到年尾，需求变更频繁，燃尽图长期失真。

原因：把计划和项目理解成了一回事。手册里说得很清楚，计划和项目没有强对应关系，一个计划可以对应一个项目，但这是理想状态。项目应该按迭代或阶段切，一个产品对应多个项目。

解决：按发布节奏切项目，一个迭代一个项目，周期控制在两到六周。历史项目关闭但不删除，需求和 bug 的关联记录都挂在上面，后面查"这个功能是哪一版做的"能查到。

6. 进阶：用统计报表反查流程漏洞

报表这个功能，多数团队只用来看数量，其实它更适合用来对账。产品视图的需求统计报表提供三个口径：产品需求数量、模块需求数量、按计划统计。我一般把这三个数放在一起看，差额就是流程漏点。产品需求总数减去各模块需求之和，差值就是没填模块的需求；按计划统计的总数对不上产品总数，差值就是没关联计划的需求。这两个数不需要人工盘点，报表一拉就出来。

6.1 三个对账口径

第一个口径是需求状态分布。激活、草稿、已变更、已关闭四个状态的比例，能反映评审流程是否在跑。草稿占比超过三成，说明评审积压。第二个口径是需求阶段分布。大量需求停在"已立项"，说明任务分解动作缺失；停在"测试完毕"，说明验收环节没人管。第三个口径是缺陷重开率。同一批 bug 里被重新激活过的比例，超过两成就要去看解决方案字段的填写质量。

这套对账我一般一个月做一次，十分钟能跑完。它不看个人绩效，只看流程有没有断点，所以在会上拿出来不会引起对抗。

6.2 交接前的自检动作

接手一个新项目库时，我会按固定顺序过一遍：先看需求状态分布，再看阶段分布，然后看模块树层级，最后抽查十条最近关闭的 bug 看字段完整度。这四步走完，基本能判断这个库是被认真用过的，还是只当记事本用的。文档库那一块顺便也看一眼，产品文档库、项目文档库、自定义文档库三类分开建了没有，全堆在默认分类里的，多半也没人维护。

有一个习惯我一直保留：每次版本发布后，把该版本关联的需求、修复的 bug、执行的用例数抄进发布说明里。这件事系统不强制，但它让路线图上的每个点都有据可查。从那以后我每次接手新库，都强制先把这套对账跑一遍再谈优化，不然改的都是表面。希望帮到你。

本文还有配套的精品资源，点击获取