禅道项目管理落地指南：角色流程对齐与避坑排查

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

1. 拿到一份 40 多页的禅道手册，先别急着从头翻

很多团队装完禅道，第一件事是拉个会，把这份《禅道使用手册（完整版）.docx》投到屏幕上，从“1.1 软件介绍”开始念。念到“需求的状态和阶段”那一页，会议室里已经有人开始刷手机了。问题不在手册写得差，而在于它按“角色”组织内容，产品经理看第三章、项目经理看第四章、开发看第五章，可真实项目里一个人往往身兼数职，按角色切开的文档反而让人找不到自己那条主线。

这份手册的价值，是它把禅道这套基于 Scrum 的项目管理软件从“产品—需求—项目—任务—版本—Bug—发布”的完整链路摊开讲了一遍，并且给了每个角色的最小操作集。它适合三类人：刚接手禅道配置的系统管理员、被要求“把流程跑起来”的项目负责人，以及每天要在“我的地盘”里清任务、清 Bug 的一线开发和测试。下面我不复述目录，而是按“怎么把手册里的流程真正落地”来拆，顺带把手册没写透的参数和坑补上。

2. 角色与流程对齐：先想清楚谁在哪个环节签字

禅道最容易翻车的地方，不是功能不会点，而是角色和流程对不上。手册 1.2 节列了五种角色：系统管理员、产品人员、项目经理、开发、测试。听起来清楚，实际配权限时经常出现“产品经理建了项目、项目经理改不了需求”这种拧巴局面。原因在于禅道的权限是按“视图 + 操作”细粒度控制的，角色只是权限组的名字，不是硬约束。

2.1 五种角色在一条需求上的交接点

把手册 1.4 节的基本流程拆开看，一条需求从生到死会经过这些手：

这张表是我建议每个团队在导入手册前先对着填一遍的东西。手册里每个角色的章节是分开写的，但真实交接发生在表格的“交接产物”那一列。哪一格填不出来，说明那个环节的权限或字段没配好。

2.2 用“最简使用”反推权限配置

手册 1.3 节给了四种最简用法：只做产品管理、只做项目任务、只做 Bug 管理、只做个人事务。这四种用法对应的权限组差别很大。比如只做 Bug 管理的团队，产品人员和项目经理的权限可以收得很紧，但测试人员必须有“提交 Bug、验证 Bug、激活 Bug”三个操作，开发必须有“解决 Bug、确认 Bug”两个操作。

我一般的做法是先按最简用法建一个权限组，跑一周，再往里加。具体到操作层面，系统管理员在“后台 → 权限”里按下面这个思路配：

# 这不是禅道命令，是配置权限时的检查清单，逐条对照后台权限分组 # 1. 产品组：产品-需求-提需求/变更/评审；产品-计划-创建；产品-发布-创建 # 2. 项目组：项目-任务-分解/指派；项目-团队-管理；项目-版本-创建 # 3. 测试组：测试-Bug-提交/验证/激活；测试-用例-创建/执行；测试-测试单-创建 # 4. 开发组：我的-任务-开始/完成；测试-Bug-解决/确认；项目-版本-提交测试

这段清单的逻辑是：每个组只给它那条主线上必须点的按钮，跨组的操作（比如开发去改需求）一律不给。参数上要注意，禅道的权限是“组 + 用户”叠加的，一个用户如果在多个组里，权限取并集，所以别把人随手塞进“管理员组”，否则前面收得再紧也白搭。手册没强调这一点，但这是权限配歪的头号原因。

2.3 登录入口与“关联系统”的坑

手册 1.5 节写的是先登 OA，再从“协同工作 → 关联系统”进禅道。这是很多公司把禅道挂在统一门户下的常见做法。这里有个容易忽略的点：从门户跳转进来时，禅道拿到的是门户传过来的身份，如果门户和禅道的用户账号没对齐，会出现“登进去了但我的地盘是空的”。排查顺序是先在禅道后台看用户列表里有没有这个账号，再看门户传的用户名和禅道登录名是否完全一致（大小写、前后空格都算）。手册只写了“点击就进入了禅道系统”，没写对不齐怎么办，这一步在实际部署里踩的人不少。

3. 产品经理那条线：需求状态机是整套流程的地基

手册第三章是全书最厚的一章，核心其实就一件事：需求的状态和阶段怎么流转。3.4 节把状态分成草稿、激活、已变更、已关闭四种，阶段分成未开始到已发布九种。很多人看这段觉得是概念，实际它是后面项目关联需求、任务分解、报表统计全部能对上的前提。状态机没跑对，燃尽图和需求统计报表就是一堆对不上的数。

3.1 创建需求时“不需要评审”到底该不该勾

手册 3.2 节说，勾了“不需要评审”，新需求直接是激活状态；不勾，就走评审流程。我的经验是：小团队、产品负责人只有一个、需求来源单一的时候，可以勾；一旦有多个需求提出方，或者需求要跨部门确认，就别勾。原因很直接——草稿状态的需求不能关联到项目，但它是唯一能承载“还没想清楚的想法”的状态。手册里那句“即使产品完全有一个人负责，也可以将一些不成熟的想法存为草稿”，说的就是这个用法。

评审结果有三个分支，对应状态变化要记牢：

• 确认通过 → 状态变“激活”，可以关联项目
• 有待明确 → 保持“草稿”，指派回创建者
• 拒绝 → 给出拒绝原因，需求关闭

这里有个参数细节：评审时“由谁评审”字段是记录参与人名单的，可以输用户名自动筛选。手册说“一般来讲需求评审可以是一个线下的评审会议，在禅道里记录下参与需求评审的人员即可”，这句话的意思是禅道不强制线上评审，但名单要留痕，后面追责和回溯全靠它。

3.2 变更需求为什么必须走变更流程而不是编辑

手册 3.3 节有一句很关键的话：编辑操作无法修改需求的标题、描述、验收标准和附件。也就是说，这四个字段一旦定了，要改只能走“变更”。变更后状态变“变更中”，再走一次评审，通过才回到“激活”。这个设计的意义是留下变更前后的对比，评审页面能直接看到 diff。

变更评审的四个结果要分清：

变更被确认后，手册特别提到研发团队和测试人员要“确认需求变更”，分别落在任务、Bug、用例三个地方。这一步很多人跳过，结果是任务还按老需求做、用例还按老标准测。我的做法是把“确认变更”当成一个检查项写进迭代启动会，谁的任务受影响谁当场点确认，不点的不许开工。

3.3 需求阶段字段是怎么被自动推着走的

3.4 节对阶段字段的描述值得逐条对照，因为它不是手动填的，是系统根据关联关系自动算的：

• 没关联项目也没关联计划 → 未开始
• 关联了计划、没关联项目 → 已计划
• 关联了项目、没分解任务 → 已立项
• 有开发任务进行中、测试任务没开始 → 研发中
• 开发任务全完成、测试没开始 → 研发完毕
• 有测试任务进行中 → 测试中
• 测试全结束但开发还有没结束的 → 仍是测试中
• 开发和测试都结束 → 测试完毕
• 验收 → 产品经理手工确认
• 关闭且原因是“已发布” → 已发布

这张映射表是排查“为什么需求阶段不对”的唯一依据。阶段卡在“已立项”不动，八成是任务没分解；卡在“测试中”下不来，去看是不是还有开发任务没关。手册把这些规则写出来了，但没告诉你它是排查工具，我把它贴在项目看板旁边，比任何培训都管用。

3.4 模块、计划、发布三者的关系别搞混

3.5 到 3.7 节讲模块、计划、发布。模块是需求的分类树，维护时注意左侧数字是排序字段，调整它就能改模块在树里的位置，编辑时还能改上级模块——这意味着模块树是可以重排的，别建完就不敢动。计划是产品层面的发布节奏，发布是项目结束后的成果宣告。手册 3.6 节有一句大实话：计划和项目没有非常强的对应关系，理想状态是一个计划对一个项目，实际大部分需求关联自一个计划、同时掺了其他计划的部分需求。所以别为了“计划项目一一对应”去硬拆，那是给自己找事。

创建发布有两个硬前提：产品关联过项目、项目创建过版本。缺一个，发布页面就建不出来。这个前置条件手册写得很清楚，但实际最常见的报错是“项目建了但没建版本”，开发提测那步跳过了，发布自然卡住。

4. 项目经理与开发测试：任务、版本、Bug 的闭环怎么跑通

手册第四章和第五章、第六章分别讲项目经理、开发、测试。这三章连起来看，其实是一条闭环：项目经理分解任务 → 开发领任务做、建版本提测 → 测试提 Bug → 开发解决 → 测试验证关闭。闭环里任何一环断掉，燃尽图就会失真，Bug 就会堆积。

4.1 任务分解到什么粒度才算合格

手册 4.4 节讲任务分解，4.5 节讲燃尽图。这两节要一起看：燃尽图是按任务的预计工时和剩余工时画的，任务粒度太粗，燃尽图就是一条锯齿；太细，每天更新工时变成负担。我的经验粒度是单个任务 4 到 16 小时，超过 16 小时继续拆，低于 4 小时合并。分解时“指派到人”必须填，不填的任务不会出现在任何人的“我的任务”里，等于没派。

开发侧 5.2 节说“领取任务，并每天更新任务”，更新的是剩余工时。这里有个血泪经验：剩余工时别每天填 0 再填回原值，燃尽图会画出假的陡降。正确做法是每天下班前按实际剩余填，哪怕只减了 1 小时。

4.2 创建版本和申请测试的字段含义

5.3 节创建版本、5.4 节申请测试。版本是提测的载体，创建版本时要选关联的需求和 Bug，这一步决定了测试单里能看到什么。申请测试时选测试单、选负责人，测试人员才会在自己的“我的测试”里看到。

# 提测前的自检清单（对应手册 5.3、5.4 两节的操作顺序） # 1. 版本号与发布计划对齐，别用 build-001 这种随手编号 # 2. 关联需求：本次迭代激活状态且已开发完毕的需求全部勾上 # 3. 关联 Bug：本次修复的 Bug 勾上，未修复的别勾 # 4. 申请测试：指定测试负责人，备注里写清测试范围和已知风险

这段清单的逻辑是让版本成为“可追溯的交付物”。参数上，版本号建议跟发布计划挂钩，比如计划叫“V2.3 迭代”，版本就叫“V2.3-build1”，后面建发布时一眼能对上。手册没规定命名，但命名乱了，发布环节关联版本时会选错。

4.3 Bug 生命周期：提交、解决、验证、激活

第六章把 Bug 的完整生命周期讲全了。6.2 提交、6.3 验证关闭、6.4 激活、6.5 找到自己的 Bug。这里的状态流转是：激活 → 已解决 → 已关闭，关闭后发现复现就“激活”回激活状态。手册 5.5 节开发“解决 Bug”、5.7 节开发“确认 Bug”，确认的是需求变更对 Bug 的影响，别和解决 Bug 搞混。

测试侧 6.1 节“维护 Bug 视图模块”容易被忽略。Bug 视图模块是给 Bug 分类用的，和产品模块是两套东西。建 Bug 视图模块的好处是 6.10 节的报表统计能按模块出数，不建的话所有 Bug 挤在默认分类里，统计出来没有分析价值。

4.4 用例和测试单的配合

6.6 到 6.9 节讲用例视图、创建用例、管理测试任务、执行用例提交 Bug。用例执行时提交的 Bug 会自动带上用例关联，这是后面做“用例有效性统计”的基础。手册 6.8 节“管理测试任务”实际就是建测试单，测试单关联版本，执行用例时按测试单走。我的习惯是每个版本一个测试单，别把多个版本的用例混在一个测试单里，否则执行进度没法按版本看。

5. 避坑排查：这五处最容易让流程空转

手册是按功能写的，不会告诉你哪里会卡。下面五条是我在不同团队里反复见到的，按“现象 → 原因 → 解决”记。

现象一：需求建好了，项目里关联不到。原因：需求还是草稿状态，草稿不能关联项目。解决：走完评审让状态变激活，或者创建时勾“不需要评审”。排查时直接看需求详情页的状态字段。

现象二：燃尽图一条直线不动。原因：任务分解后没人更新剩余工时，或者任务没指派到人。解决：要求开发每天下班前更新剩余工时；项目经理每周检查一次“未指派任务”列表，发现就补派。

现象三：测试提了 Bug，开发说看不到。原因：Bug 指派给了错误的账号，或者开发没有“我的 Bug”视图权限。解决：先看 Bug 详情页的指派对象，再看后台该开发所在权限组有没有测试-Bug 的查看权限。手册 2.2.2 节“我的 BUG”能看到的范围就是权限范围。

现象四：发布建不出来。原因：产品没关联项目，或项目没建版本。解决：按手册 3.7 节的两个前提逐条查，先补版本再建发布。这个顺序不能反。

现象五：需求变更后，任务和用例还是老内容。原因：变更评审通过后，研发和测试没做“确认需求变更”。解决：把确认动作写进迭代流程，任务、Bug、用例三处都要点确认，手册 3.3 节第三小节专门讲了这个。

提示：这五条里前四条都能在禅道页面里直接看到状态字段定位，第五条是流程问题，只能靠制度约束，工具帮不了。

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

手册最后停在需求统计报表，但真正让这套流程稳住的，是把手册里的状态规则变成一张每天能核对的表。我现在的习惯是每周一花十分钟，按下面这张表过一遍，比读任何文档都快。

这张表不是手册里的，是从手册 3.4 节的状态映射和 4.5 节的燃尽图逻辑反推出来的。它的好处是把“流程有没有空转”变成可数的数字，而不是靠感觉。参数上唯一要调的是“两周”这个阈值，团队节奏快就缩到一周，慢就放到一个月，但一定要有个数，没数的检查等于没检查。

还有一个技巧：手册 3.10 节的需求统计报表支持按产品、按模块、按计划三种维度出数。我一般每月导一次按模块的需求数量，和 Bug 视图模块的 Bug 数量并排看，哪个模块需求多、Bug 也多，下个迭代就重点盯它。这个用法手册没写，但它是把两份报表串起来的最省事方式。

从那以后我每次接手一个新团队的禅道配置，都强制先跑一遍第 2 章那张角色交接表和第 6 章这张核对表，两张表填不满的地方，就是手册里那些“看起来懂了、实际没配”的环节。希望帮到你。

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