禅道使用手册实战指南：按角色拆解操作路径与避坑要点

简介：这份《禅道使用手册（完整版）》面向项目经理、产品经理、开发与测试人员，以及初次接触禅道、需要系统掌握项目管理工具操作流程的团队，帮助解决项目进度跟踪、任务分配、需求与缺陷协同管理中的实际问题。资源包共1个docx文档，约4.02MB，内容按角色组织，涵盖基本介绍、个人管理、产品经理使用、项目经理使用等章节，从软件介绍、用户角色、登录与最简流程，到待办创建与浏览、我的任务与我的BUG、需求创建评审与变更、产品模块维护、发布计划与燃尽图等均有展开，目录层级清晰，便于按模块查阅。已有5218人学习下载，适合作为团队内部培训或日常查阅的参考手册，读者可据此快速熟悉禅道各角色的操作路径与协作方式，减少上手成本。

1. 拿到一份禅道手册，先别急着从头读

很多团队装完禅道，第一件事是拉个会，把手册从头到尾过一遍。结果两小时过去，大家记住了“禅道是一款基于 Scrum 的项目管理软件”，回到工位还是不知道明天该点哪里。这份《禅道使用手册（完整版）》的价值不在“读完”，而在“按角色查”——它把产品经理、项目经理、开发、测试四条线的操作路径拆得很细，从建产品、提需求、建项目、分解任务，到提交 bug、验证关闭，每一步都对应到具体菜单和字段。你不需要通读，你需要的是：知道自己这个角色在禅道里每天该动哪几个页面，以及哪些字段填错了后面会连环翻车。这篇笔记就是按这个思路，把手册里的操作路径重新排了一遍，补上手册没写透的参数含义和踩坑点，适合正在落地禅道、或者装了但用不起来的小团队照着复现。

2. 角色与流程对齐：先搞清楚谁在哪个页面干活

禅道最容易让人放弃的地方，不是功能少，而是角色和页面的对应关系没建立起来。手册第 1.2 节列了五类角色：系统管理员、产品人员、项目经理、开发人员、测试人员。但光知道角色名没用，得知道每个角色每天打开禅道第一眼该看哪里。这一章先把流程骨架立住，后面几章再逐个角色拆操作。

2.1 五类角色的权限边界与日常入口

手册里对权限的描述比较简略，只说了系统管理员负责添加用户、分配权限。实际落地时，权限分配是第一个容易埋雷的地方。禅道的权限模型是“角色 + 分组”，新建用户时要选所属分组，分组决定了能看到哪些菜单。常见做法是：系统管理员单独一个账号，不参与日常业务；产品经理给产品视图的全部权限；项目经理给项目视图加部分产品视图只读；开发和测试给“我的地盘”加对应视图的读写权限。

这里有个反直觉的点：开发和测试不需要给“产品视图”的完整权限。手册 5.1 到 5.7 节里，开发要做的领取任务、创建版本、解决 bug、确认 bug，全部可以在“我的地盘”和项目视图里完成。给多了权限，反而容易出现开发直接去改需求描述的翻车情况——需求描述是产品经理的领地，开发改了，测试按旧描述写用例，后面就是一笔糊涂账。

日常入口可以按这个对应关系记：

这张表不是手册原文，是我按手册各章节的操作路径反推出来的。手册是按功能模块组织的，实际用起来是按角色组织的，这个转换不做，团队就会在菜单里迷路。

2.2 从需求到发布的完整链路怎么串

手册 1.4 节给了基本流程：产品经理创建产品 → 创建需求 → 项目经理创建项目 → 确定项目要做的需求 → 分解任务指派到人 → 测试提交 bug。这六步是主干，但中间有几个衔接点手册没强调，恰恰是链路断掉的高发区。

第一个衔接点是“需求必须激活才能关联到项目”。手册 3.2 节写得很清楚：创建需求时如果勾了“不需要评审”，需求状态直接是激活；如果走了评审，评审结果选“确认通过”才变激活。只有激活状态的需求才能关联到项目里开发。很多团队卡在这里，项目经理建完项目发现需求列表是空的，以为是权限问题，其实是需求还躺在草稿状态。

第二个衔接点是“项目关联需求”这个动作。手册 4.3 节叫“确定项目要完成的需求列表”，操作入口在项目视图里。这里要注意，关联需求时是从产品维度选的，一个项目可以关联多个产品的需求，但大部分小团队一个项目对应一个产品，选的时候别漏。

第三个衔接点是“版本”和“发布”的先后。手册 3.7 节明确写了创建发布的两个前提：产品有关联过项目，且该项目创建过版本。版本是开发在 5.3 节创建的，发布是产品经理在 3.7 节创建的。顺序反了，发布页面会提示前提不满足。这个依赖关系建议直接写进团队的新人须知里。

2.3 最简使用的四种裁剪方式

手册 1.3 节提了四种最简使用：只做产品管理、只做项目任务管理、只做 bug 管理、个人事务跟踪。这个设计很务实，因为不是每个团队一上来就能跑全流程。我的建议是按团队成熟度选裁剪方式：

刚起步的两三人小队，直接用“只做 bug 管理”最省事。测试在 6.2 节提交 bug，开发在 5.5 节解决 bug，测试在 6.3 节验证关闭，这条闭环最短，一周就能跑顺。等 bug 流程稳定了，再往上加项目任务管理，让开发在 5.2 节领取任务、每天更新。产品管理那条线（需求、计划、发布）放到最后加，因为它对产品经理的投入要求最高，需求写不细，整条线就是空转。

个人事务跟踪（2.1 节的待办）适合作为过渡期的补充，让每个人先养成“打开禅道看今天要干什么”的习惯，比一上来就推全流程阻力小得多。

3. 产品经理线：需求、计划、发布三件套怎么落地

产品经理是禅道里操作最重、也最容易把数据搞乱的角色。手册第三章从 3.1 到 3.10 节，覆盖了维护产品、创建评审需求、变更评审需求、需求状态阶段、维护模块、建立计划、建立发布、路线图、文档管理、统计报表。这一章挑出其中真正影响后续流程的环节，把字段含义和操作顺序讲透。

3.1 建产品时那几个字段填错会连锁反应

手册 3.1 节列了添加产品时需要注意的字段：产品代号、产品负责人、测试负责人、发布负责人、访问控制。这几个字段不是随便填的，每一个都在后续流程里被引用。

产品代号相当于产品的英文标识，手册举例说禅道自己的代号是 zentao。这个字段一旦定了，后面改起来麻烦，建议用简短的英文或拼音，别用中文。产品负责人是需求的最终解释人，评审需求时默认指派给他。测试负责人决定了提交 bug 时的默认指派人——手册原话是“可以适用于公司人比较多，提交 bug 不知道该给谁的情况”。发布负责人负责创建发布，3.7 节的发布操作默认由他执行。

访问控制这个字段值得单独说。手册提到可以把产品设为私有，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才能访问。小团队一般设成公开，但如果涉及外部客户或者跨部门协作，私有产品能避免无关人员看到需求细节。这里有个坑：设成私有后，新加入项目团队的成员如果没被单独加进访问列表，会看不到产品下的需求，表现是“项目里关联不了需求”，排查时先看访问控制，别急着查权限分组。

3.2 需求按功能点拆，评审流程别省

手册 3.2 节的核心观点是“按照功能点的方式来写需求”，把需求设计文档里的每个功能点摘出来，作为独立需求录入。这个粒度建议严格执行，因为禅道的任务分解、用例管理、bug 关联都是挂在需求上的，需求粒度太粗，后面任务拆不动，用例也写不细。

创建需求时有两个字段要留意。一个是“所属计划和模块”，手册说可以暂时保留为空，但我的经验是模块尽量填，哪怕先建个粗分类。模块在 3.5 节有专门维护流程，它是需求的分类维度，3.10 节的统计报表里“模块需求数量”就是按这个维度出的。另一个是“不需要评审”复选框，勾了需求直接激活，不勾就走评审流程。

评审流程手册 3.2 节给了三种结果：确认通过、有待明确、拒绝。确认通过变激活；有待明确保持草稿并指派回创建者；拒绝要填原因。这里的关键是“有待明确”这个状态的设计意图——它允许不成熟的想法先存着，不阻塞其他需求的推进。很多团队评审时非黑即白，要么通过要么拒绝，其实“有待明确”才是使用频率最高的选项。

需求状态和阶段是两个字段，手册 3.4 节专门讲了。状态有草稿、激活、已变更、已关闭四种；阶段有未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布九种。阶段是自动流转的，规则手册写得很细：没关联计划和项目是未开始，关联计划没关联项目是已计划，关联项目没分解任务是已立项，有开发任务进行中是研发中，开发任务全完成测试没开始是研发完毕，有测试任务进行中是测试中，测试全结束开发没结束还是测试中，都结束是测试完毕。验收阶段要产品经理手工确认。这套自动流转逻辑不用背，但要知道它存在，因为看板上的阶段不对时，八成是任务或测试的状态没更新。

3.3 需求变更走专用流程，别用编辑绕过去

手册 3.3 节有一句话很关键：“编辑操作是无法修改需求的标题、描述、验收标准和附件的。”也就是说，这四个字段要改，必须走变更流程。变更后需求状态变“变更中”，然后走评审，评审结果有确认通过、撤销变更、有待明确、拒绝四种。确认通过变回激活，撤销变更回退到之前版本。

这个设计的意义在于留痕。直接编辑改掉，历史版本就没了，测试按旧描述写的用例对不上，开发按旧描述写的代码也不知道差在哪。变更流程会列出影响范围，手册提到变更时会展示该需求关联的任务、bug、用例，评审者可以参考。变更确认后，研发和测试还要分别确认需求变动，手册 3.3 节第 3 点列了任务确认、Bug 确认、用例确认三个动作。

实操建议：变更评审尽量和线下评审会绑定，会上定完，会后在禅道里记录参与人和结果。手册也说了“一般来讲需求评审可以是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可”。别指望禅道替代沟通，它只是把结论固化下来。

3.4 计划、发布、路线图的依赖关系

手册 3.6 节讲计划，3.7 节讲发布，3.8 节讲路线图。三者的关系是：计划和发布组成路线图，绿色是已发布版本，黄绿色是将来计划。计划的作用是规划发布节奏、调整需求优先级，同时帮助项目关联需求。发布的前提是产品关联过项目且项目创建过版本。

计划关联需求有两个入口：建完计划后在计划里关联，或者提需求时直接指定计划（已过期的计划不会列出）。手册特别说明计划和项目没有强对应关系，一个计划可以对应一个项目，但多数情况是项目关联的需求大部分来自一个计划，同时夹杂其他计划的部分需求。这个灵活性是好事，但也意味着计划不能当项目用，别指望用计划来跟踪执行进度，执行进度看项目视图的燃尽图（4.5 节）。

发布创建后，路线图自动更新。3.10 节的需求统计报表有三个维度：产品需求数量、模块需求数量、按计划统计。这三个报表够用了，不用额外折腾。

4. 项目经理与开发线：任务分解、燃尽图、版本与 bug 闭环

这一章把项目经理和开发的操作用一条线串起来，因为这两者的动作是咬合的：项目经理分解任务，开发领取任务、更新、建版本、申请测试、解 bug。手册第四章和第五章的内容合并看，才能看清任务从创建到关闭的完整生命周期。

4.1 建项目、组团队、定需求列表的顺序

手册 4.1 到 4.3 节给了三步：建立项目、组建团队、确定需求列表。顺序不能乱，因为组建团队时要选人，确定需求列表时要关联产品需求，这两步都依赖项目已经建好。

建项目时手册没展开的字段是项目名称和代号，建议和产品代号保持一致的命名习惯，方便检索。组建团队在 4.2 节，把产品经理、开发、测试都加进去，注意这里加的是团队成员，不是权限分组，两回事。确定需求列表在 4.3 节，从产品维度选已激活的需求关联进来。

这里有个高频问题：项目建好了，需求列表里选不到想要的需求。排查顺序是：先看需求状态是不是激活（草稿和变更中都关联不了），再看产品访问控制有没有把当前用户排除，最后看需求是不是已经关联到别的项目了——一个需求可以关联多个项目，但如果团队约定一个需求只进一个项目，就要注意别重复关联。

4.2 任务分解的粒度与指派规则

手册 4.4 节叫“组织进行任务分解”，这是项目经理最核心的动作。任务挂在需求下面，一个需求可以拆多个任务，每个任务指派到人、估工时。粒度建议控制在半天到两天，太粗了燃尽图看不出进展，太细了管理成本高。

任务分解时容易忽略的是任务类型。禅道的任务有设计、开发、测试、研究等类型，类型影响后续的统计。开发任务和测试任务要分开建，因为需求阶段的自动流转（3.4 节）依赖任务类型来判断“研发中”还是“测试中”。如果测试任务建成了开发类型，需求阶段会一直卡在研发中，看板上就对不上了。

指派规则上，手册 5.2 节说开发“领取任务，并每天更新任务”。实际操作中，项目经理分解时直接指派比让开发自己领更可控，尤其是任务有明确依赖关系时。开发每天更新的是已消耗工时和剩余工时，这两个数字是燃尽图的数据源。

4.3 燃尽图读不懂，先查这三个数据源

手册 4.5 节说“通过燃尽图了解项目的进展”，4.6 节说“通过各种列表了解项目进展”。燃尽图是项目经理最常看的图，但它不准的时候也最让人抓狂。燃尽图的数据来自任务的剩余工时，所以图不对，先查三个地方：

第一，任务有没有每天更新剩余工时。开发不更新，剩余工时不变，燃尽图就是一条平线。第二，任务分解时估的工时是否合理。总工时估少了，燃尽图一开始就在低位，看不出趋势。第三，有没有任务被关闭但没填实际工时。关闭任务时实际工时为 0，剩余工时会突然掉一大截，图会出现断崖。

手册 4.7 节的项目任务基本报表统计可以作为燃尽图的补充，按人、按任务类型出工时分布，排查是谁的工时没填，比盯着燃尽图猜快得多。

4.4 开发建版本、申请测试、解 bug 的动作链

手册第五章从 5.1 到 5.7 节，开发的动作链是：参加计划会议分解任务 → 领取任务每天更新 → 创建版本 → 申请测试 → 解决 bug → 文档管理 → 确认 bug。这条链里，创建版本（5.3 节）和申请测试（5.4 节）是衔接开发和测试的关键。

创建版本时，版本号建议和代码仓库的 tag 对齐，比如 v1.2.0。版本关联的是项目，不是产品，发布时才关联到产品（3.7 节）。申请测试是把版本提交给测试，测试收到后开始执行用例、提 bug。

解决 bug 在 5.5 节，解决时选解决方案（已解决、重复、设计如此、无法重现等），填解决版本。这里有个坑：解决版本填错，测试验证时对不上代码分支，会反复打回。建议解决版本和创建版本用同一套版本号。5.7 节的确认 bug 是开发对测试关闭的 bug 做最后确认，防止测试误关。

4.5 测试侧：bug 视图、用例、测试任务的配合

手册第六章是测试的主场。6.1 节维护 bug 视图模块，6.2 节提交 bug，6.3 节验证关闭，6.4 节激活 bug，6.5 节找自己需要的 bug，6.6 到 6.9 节是用例和测试任务，6.10 节看报表。

提交 bug 时，bug 视图模块（6.1 节）决定了 bug 归到哪个分类，这个分类和产品模块（3.5 节）是两套体系，别混。bug 的严重程度和优先级是两个字段，严重程度是技术影响，优先级是业务紧急度，测试填严重程度，产品经理或项目经理定优先级，分工要明确。

用例管理（6.7 节创建用例、6.9 节执行用例提交 bug）和测试任务（6.8 节管理测试任务）是配套的。测试任务挂在版本上，执行用例时如果失败，直接转成 bug，bug 自动关联用例和需求。这条链路跑顺了，需求、用例、bug 三者是可追溯的，3.3 节需求变更时的影响范围才能列全。

5. 避坑与排查：五个真实会卡住流程的问题

手册是操作说明，不会告诉你哪里会翻车。这一章列五个我在落地时反复遇到的问题，按“现象 → 原因 → 解决”写，都是能直接对照排查的。

5.1 需求关联不到项目

现象：项目经理在项目里关联需求，列表是空的或者缺了某几条。原因：需求状态不是激活（草稿、变更中、已关闭都关联不了），或者产品访问控制把当前用户排除了，或者需求已经关联到别的项目且团队约定不重复关联。解决：先在产品视图确认需求状态，再看产品访问控制列表，最后查需求详情页的关联项目记录。

5.2 燃尽图一条平线

现象：项目跑了一周，燃尽图几乎没下降。原因：开发没有每天更新任务的剩余工时，或者任务分解时没估工时。解决：让开发在“我的任务”里每天更新已消耗和剩余工时，项目经理在 4.7 节的报表里按人查工时填报情况，谁没填一目了然。

5.3 发布创建不了

现象：产品经理点创建发布，提示前提不满足。原因：产品没有关联过项目，或者关联的项目没有创建过版本。解决：按 3.7 节的两个前提倒查，先确认项目存在且关联了需求，再确认开发在 5.3 节创建过版本。顺序不能反。

5.4 需求阶段卡在“研发中”不动

现象：开发任务都完成了，需求阶段还是研发中，没变成研发完毕。原因：测试任务建成了开发类型，或者测试任务还没建。解决：检查任务类型，测试任务必须是测试类型；如果测试任务还没分解，补建测试任务，阶段会自动流转。

5.5 测试验证 bug 后开发又打回

现象：测试关闭 bug，开发确认时打回，来回拉扯。原因：解决版本填错，测试验证的不是开发修复的那个版本；或者 bug 描述不清，开发理解偏了。解决：统一版本号命名规范，解决版本和创建版本对齐；提交 bug 时附上复现步骤和环境信息，6.2 节的描述字段别偷懒。

6. 把手册用成检查清单：我的日常核对习惯

手册读一遍就够，但用起来得有个核对机制。我现在的习惯是把手册里的关键节点抽成一张检查清单，每个迭代开始和结束时各过一遍，比临时翻文档快。

迭代开始时核对四项：产品经理的需求是否都是激活状态且关联了计划；项目经理的项目是否关联了需求并完成了任务分解；任务类型是否开发测试分开；团队成员是否都在项目团队里。迭代结束时核对三项：开发是否创建了版本并申请测试；测试的 bug 是否都验证关闭或激活；产品经理是否基于版本创建了发布。

这套清单不是手册原文，是从 3.4 节的需求阶段流转规则反推的——阶段自动流转的前提是每个环节的数据都填了，缺一环，阶段就卡住。比如“已立项”要求需求关联项目且分解了任务，那迭代开始时就该确认这两件事都做了，而不是等阶段不对了再回头查。

还有一个习惯是每周看一次 3.10 节的需求统计报表和 4.7 节的项目任务报表。需求报表看模块分布，哪个模块需求扎堆，说明那块是重点或者需求拆得不够细；任务报表看工时分布，谁的任务工时异常高，可能是估算不准或者任务粒度太粗。这两个报表不用天天看，每周一次足够发现趋势。

最后说个验证方法：新团队落地禅道，第一周只跑 bug 闭环（6.2 提交、5.5 解决、6.3 验证关闭），第二周加任务领取和更新（5.2 节），第三周加需求评审（3.2 节），第四周加计划和发布（3.6、3.7 节）。每周结束对照手册对应章节检查数据完整性，哪一步的数据填不齐，就停在那一步补，别急着往下推。禅道的流程是环环相扣的，前一环的数据是后一环的输入，跳步的代价是后面所有报表都不准。

从那以后我每次给新团队配禅道，都强制先跑两周纯 bug 闭环，再往上加流程，急不得。希望这份按角色重排的操作路径，能帮你少走几趟菜单迷宫。

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