禅道使用手册：需求、任务、Bug全流程闭环与团队协作避坑指南

简介：这份资源是一套禅道项目管理工具的完整使用手册，主要面向项目经理、产品经理、开发人员和测试人员，帮助团队快速上手禅道并规范项目管理流程。手册内容由浅入深，从软件基本介绍、用户角色与最简使用开始，逐步展开个人管理中的待办创建与浏览、关注我的任务和我的BUG、通过档案维护个人信息等操作；同时重点覆盖产品经理维护产品、创建与评审需求、变更需求、需求的状态和阶段，以及项目经理建立项目、组建团队、任务分解、通过燃尽图掌握项目进展等核心功能。文件为单个Word文档，大小约4.02MB，附有完整目录，章节划分清晰，便于按需查阅或打印学习。目前已有5205人学习下载，适合希望系统掌握禅道配置、需求与任务管理，从而提升团队协作效率的读者。

1. 禅道使用手册完整版docx：先想清楚哪类团队需要它

如果你手里正拿着一份《禅道使用手册（完整版）.docx》，说明团队大概率已经受够了需求口头传达、排期全靠问、bug记录散在Excel和聊天记录里的日子。这份手册不是产品文档的堆砌，它按角色把禅道拆成了可操作的动作序列：从个人待办、产品经理提需求，到项目经理建项目、分解任务，再到开发领任务、测试提bug，从头到尾是一条完整闭环。适合刚接手禅道还不知道怎么给团队立规矩的人，也适合已经用起来但流程总有环节打补丁的团队。先把手册里的角色流程看清，再决定要不要把禅道当成团队唯一的进度事实源。

2. 产品经理视角：需求创建、评审变更与状态阶段怎么配合

产品经理在禅道里几乎是一切需求流的源头。产品、需求、计划、发布这几个词看着简单，但真用起来，很多人第一个月就在需求字段和评审状态上翻车。这一章按产品经理日常操作顺序走一遍，重点讲清楚哪些字段能改、哪些必须走流程去改。

2.1 添加产品先于添加需求：代号、负责人与访问控制

用产品经理角色登录禅道，进入产品视图，点击页面右侧“添加产品”链接。如果系统里还没有任何产品，禅道会自动跳到添加页面，新团队第一次进来基本都会走这条路。创建时几个字段值得停下想想，而不是随手填完。

• 产品代号：相当于产品内部的隐喻。禅道自身项目的代号就是 zentao，团队内部讨论时拿代号指代产品，比念全名利索。
• 产品负责人：负责整理和解释整个产品的需求，制定相应的发布计划。这个角色一般是对产品整体方向和优先级说了算的人。
• 测试负责人：建议不要空着。公司人多的时候，测试提交bug不知道该指派给谁，默认给测试负责人兜底，能少很多来回问人的事。
• 发布负责人：主要职责是创建发布，发布动作的权限会收敛到这个人身上。
• 访问控制：默认选私有的话，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队成员能看。如果跨部门协作多，注意别把访问控制设得太死。

产品建完紧接着就是维护产品模块。模块相当于对产品需求的分类，一级级往下维护子模块，左侧数字是排序字段，调整它就能改变模块在模块树里的位置。编辑模块时可以修改它所属的上级模块。模块建得好，后面需求分类、bug归类、用例关联都会省很多力气。

提示：产品代号和模块树是团队内部协作的“公共语言”，上线前花半小时把这两层理清楚，比之后迁移一千条需求划算。

2.2 需求按功能点拆：不要在禅道里粘贴整份需求文档

进入产品视图，点右侧“提需求”，进入新增需求页面。这里最核心的字段是标题，必填。所属计划和所属模块可以暂时留空，等计划和模块信息明确后再补也不迟。

创建需求页面里有几个容易被忽略的选项：是否需要评审、抄送给、关键词。需求审核那块如果勾选“不需要评审”，新创建的需求状态就是“激活中”，而只有激活状态的需求才能关联到项目进行开发。有些团队会把所有需求都先存成草稿再批量评审，这个习惯对新团队反而更稳，等评审流程走熟之后再决定要不要放开。

需求怎么写，我建议按功能点拆。原来需求设计文档里的每一个功能点摘出来，录在禅道里作为一个独立需求。比如一个登录模块，拆出“账号密码登录”“短信验证码登录”“OAuth授权登录”三条需求，后续项目经理分解任务、测试人员写用例、bug回流定位归属，都以这个粒度为准。把整个需求文档一股脑贴进描述里，看起来信息全，实际用起来谁都不会去翻那个长文本。

抄送字段的意义在于需求变化能通过 email 抄送给相关人员。关键需求记得设置关键词，后期检索的时候按关键词一筛就能拉出来，不用在几百条需求里翻。

2.3 评审流程与评审结果：草稿、激活与指回创建者

创建需求时如果不勾“不需要评审”，需求会先落到草稿状态，进入评审流程。评审流程本身不复杂，但每个结果对应的状态变化，很多产品经理第一周就被绕进去了。

评审结果有几种情况：如果选择“确认通过”，需求状态改为“激活中”，之后就能关联到项目里开发。如果选择“有待明确”，需求保持草稿状态，并指派回需求的创建者头上，由创建者继续完善后再次提交评审。如果选择“拒绝”，则需要填写拒绝原因。

评审核对“由谁评审”字段记录的是参与评审的人员名单，输入用户名可以自动筛选。实际项目里评审往往是线下会议，产品经理在会上收起结论、回到禅道里补一条评审记录，把参与人拉上就行。这个动作的意义不是为了走形式，而是让后续项目、测试在需求详情页能看到这条需求已经过了一轮拍板。

提示：评审结果直接影响需求能否进入项目。评审没过就强行去项目里关联需求，禅道里是关联不进去的，白费一轮操作。

2.4 变更与评审：哪些字段必须走变更流程

禅道里需求变更专门有自己的流程。凡是对需求标题、描述、验证标准和附件的修改，都应该走变更流程。很多人在这里踩坑：看到编辑按钮就点，改完再保存，发现标题根本改不掉——编辑操作无法修改这四个字段，这是禅道刻意做的一层保护，变更必须留痕。变更之后需求状态会变成“已变更”，同时禅道会列出该需求的影响范围，评审者可以在变更页面看到改动前后的对比。

变更评审的结果比需求首次评审多了一个选项。确认通过，需求从“已变更”变回“激活中”；撤销变更，取消当前变更并回退到之前的版本；有待明确，需求打回变更者继续完善；拒绝则需要给出拒绝原因。这里提醒一句：如果变更时勾选了“不需要评审”，需求状态会自动变回激活，不会再走评审流程，谨慎使用这个开关。

需求变更被确认之后，真正的验证动作在研发和测试侧：任务确认需求变动、Bug确认需求变动、用例确认需求变动。需求改了一个字段描述，至少要让关联的项目任务、历史bug、测试用例都回过一次神，不然开发按旧描述交付，测试按新用例执行，两边对不上，最后吵到产品经理这里来仲裁。

2.5 需求在什么状态：状态字段与阶段字段的判定逻辑

禅道里需求有两个字段跟踪变化，一个是状态(status)，一个是阶段(stage)。很多团队混淆这两个概念，以为自己看的是同一个东西，其实它们回答的问题完全不同：状态回答“这条需求现在能被编辑/变更/关闭吗”，阶段回答“这条需求在研发流程里走到哪一步了”。

状态字段共有四种：草稿(draft)、激活(active)、已变更(changed)、已关闭(closed)。对应的流程操作有创建、变更、审核、关闭、激活，操作会推动状态迁移。

阶段字段描述的是激活需求在研发过程中所处的阶段，判定规则是禅道根据任务进展自动推导的，少数节点需要产品经理手工确认。我把口径整理成一张表：

注意“测试中”的判定，只要测试没有全部跑完，哪怕开发也还有尾巴没收掉，禅道统一算在“测试中”。不用纠结为什么不单独拆一个“收尾中”，这个阶段的目的是让人一眼看出整体进度，而不是精确到每一天。

2.6 发布计划、版本与路线图：进度对外沟通的出口

发布计划对产品经理的意义有两层。对内，帮助规划产品、制定发布节奏、调整需求优先级；对外，让公司其他部门以及外部客户知道产品进展到什么程度，好做自己的安排。创建路径是：产品视图→计划列表→创建计划→为计划关联需求。创建需求时也可以直接指定所属计划，这里有个细节：已经过期的计划不会列出来，省得选错。

禅道里计划和项目并不是强对应关系。理想状态是一个计划对应一个项目，但现实中通常是，项目关联需求时大部分需求来自一个计划，同时带了其他计划的部分需求。项目经理和产品经理围绕这个关系会反复对话，不要试图用禅道强制计划等于项目，它的设计本身就不支持这个假设。

创建发布有两个硬前提：该产品有关联过项目，且该项目有创建过版本。进入产品视图选发布列表，点“创建发布”，满足条件后即可创建。产品和项目层面最后汇总到路线图：计划加发布组成产品路线图，绿色代表已发布过的版本，黄绿色代表将来的计划，点任意一个发布或计划可以下钻查看具体需求信息。敏态团队的对外周报、对内同步会，截图直接从这个视图拿，比在Excel里画的甘特图真实得多。

3. 项目经理视角：项目建立、任务分解与燃尽图的读法

项目经理在禅道里的工作可以浓缩成一句话：把产品经理排好优先级的需求，变成一组看得见、可追踪、算得出剩余工时的任务。这一章从建项目讲到燃尽图，全程围绕“进度可见”这件事展开。

3.1 项目与产品需求的对接：先建项目，再定需求列表

项目视角的第一个动作是创建项目，然后组建项目团队，再确定项目要完成的需求列表。顺序不能反，团队列表空着就去关联需求，关联完发现人不在项目里，任务派不出去。

需求列表的来源是产品经理维护的“激活中”需求。项目经理进入项目后，从产品需求里勾选本次迭代要做的那一批，关联到项目里。关联时只选激活状态的需求，草稿和已关闭的需求不在可选范围内，这是禅道从流程上强制把关的口子。一个项目做完一批需求，交付、验收、发布，项目生命周期结束。

这里要反复跟团队对齐一个概念：需求归属在产品，任务归属在项目。需求从产品里创建、评审、变更，项目经理把它放进项目后，拆成任务、指派给开发测试去执行。之后需求如果变了，变更流程还是在产品侧发起，项目侧的任务状态跟着联动，两边不是一回事，但互相影响。

3.2 任务分解：把需求拆成可指派的开发任务

需求确定进项目之后，组织进行任务分解。常见做法是项目经理召集项目计划会议，产品经理、开发、测试一起参加，一条需求一条需求往下拆。拆出来的任务要有明确的验收口径，粒度一般控制在人天内，太粗的“实现登录”没法追踪，太细的“修改button样式”又会让任务列表膨胀到没人愿意更新。

禅道里任务常见的字段包括指派给、预计开始/预计完成、预计工时、优先级、类型等。类型上通常会区分设计、开发、测试、文档、研究几类，测试任务和开发任务分开记，后面需求的阶段推导才会准确。任务拆完指派到人，所有人的任务列表就形成了。老团队习惯在任务描述里写清楚验收标准，新人拿到任务不问第二遍：“这个任务做完了是指代码写完，还是指联调通过”。

每天更新任务状态这件事，是后续燃尽图和统计报表的数据地基。任务不更新，管理层看到的任何图表都是假的，这是禅道落地过程里最容易被忽视的环节。

3.3 燃尽图：为什么它总是平的或突然跳高

燃尽图是禅道项目视图里最醒目的图，横轴是迭代时间，纵轴是剩余工时。它的原理很简单：每天汇总所有任务还没消耗完的剩余工时，画一条从左上往右下走、直到归零的曲线。理解这个原理之后，再看那些“翻车”的燃尽图就有了解释。

• 平线：剩余工时连续几天不动。原因几乎只有一个——开发没更新任务。李克特不写剩余工时，曲线当然不可能往下走。这时候去批评人没用，先把每日更新任务变成团队纪律。
• 曲线突然跳高：昨天剩余工时还在下降，今天嗖地涨上去。这通常是中途拆了新任务、把原本粗粒度任务细化后的结果，不代表项目失控，反而是粒度变细的表现。项目经理要能识别这两种情况，不要一看到曲线抬头就紧张。
• 全程贴着横轴走：剩余工时第一天就接近零，后面每天都是平的。这是任务估值严重失真的信号，说明团队在“估太小”。燃尽图画得漂亮不等于项目健康，这个要单独拉出来对。

提示：燃尽图是看趋势的工具，不是算命工具。每天都平线比曲线难看更值得警觉——至少说明任务在流动。

3.4 通过列表和统计报表看进展：项目经理的日常检查项

除了燃尽图，禅道里还有各种列表供项目经理了解项目进展。按需求维度看，能看到每条需求关联的任务完成情况；按指派人维度看，能发现谁手里的任务积压最多；按状态维度看，能快速定位“开始好几天但进度没动”的任务。项目经过一段时间运转，列表中任务数量开始变大，“我的任务”页面会变成团队每天打开最频繁的页面。

统计报表维度上，项目层面可以看任务的基本统计，比如未开始、进行中、已完成的任务数量，累计剩余工时等。产品层面看需求统计，比如已完成需求数、未完成需求数、每个模块的需求分布。这些报表不用每天都翻，项目经理在周会和迭代复盘的时候拉出来对一遍，就足够发现进度风险。报表口径是从任务更新数据算出来的，任务更新质量决定了报表的参考价值，这一点在团队里反复强调都不过分。

4. 开发与测试联动：Bug流转、用例执行和文档管理的接缝

开发和测试在禅道里的协作密度是几个角色中最高的。这一章把开发侧的动作、测试侧的动作，以及双方围绕bug的流转规则串起来。核心就一句话：所有bug的状态变化必须通过禅道完成，不允许口头解决了事。

4.1 开发侧主线：领取任务、更新进度、创建版本、申请测试

开发在禅道里的日常主线是：参加项目计划会议分解任务，领取指派给自己的任务，每天更新任务进度，完成开发后创建版本，申请测试。领取任务后，任务状态从“未开始”变为“进行中”，完成代码开发并自测通过后，更新任务状态、填写实际工时，然后进入版本环节。

创建版本是申请测试的前提，也直接决定后续能否创建发布。版本可以理解为一次可交付的候选形态，禅道里的版本记录包含版本号、关联的需求列表、关联的任务列表。没有版本记录，测试任务就没有执行对象，发布的创建条件也满足不了。

这里补充一个容易被忽略的动作：文档管理。禅道内置了基本的文档管理功能，产品手册、接口文档、会议纪要都可以放在文档库里。禅道没覆盖到的流程，用文档管理来补一层，比把文档发到聊天工具里等过期强得多。

4.2 Bug状态机：提交、解决、验证关闭、激活

测试提交bug后，bug的生命周期在禅道里由几个核心状态组成：激活、已解决、已关闭、重新激活。状态变化必须由对应角色在系统里执行，不能用嘴说。

“确认 bug”这个动作很多新团队不知道。开发拿到一个bug，排查完发现不是bug，可以在解决bug时选择相应原因并说明。测试收到后如果认可，就关闭；不认可，继续激活回来，双方回到同一条记录上讨论，而不是转到大群里各说各话。bug记录的完整历史是禅道最有价值的数据资产之一，迭代复盘时拉出来看，哪些模块bug密度高、哪些原因反复出现，一眼就明白。

4.3 测试侧：用例、任务与bug执行的联动

测试在禅道里的动作从维护bug视图模块开始。所谓bug视图模块，本质上是把bug按产品、按模块组织起来，提交bug时可以直接选到对应的模块，后期按模块统计bug分布就非常方便。模块没维护好，多条bug挂在根目录下，复现、指派人、统计全都受影响。

测试用例侧，进入测试视图，创建测试用例时填写前置条件、操作步骤、预期结果，同时关联到产品模块。用例不是写完就算完，禅道里还提供了测试任务的管理能力：把一个版本的用例集合起来，指定负责人，形成一个测试任务，然后按任务去执行。

执行用例是测试产生价值的真正节点。执行时一条用例一条用例过，执行失败的用例直接关联到bug上提交，bug会自动带上用例的上下文信息，开发在bug详情里就能看到用例编号、步骤和预期结果，省去来回传截图的麻烦。用例写了几百条但没人执行，是测试管理里最亏钱的事，禅道把“执行”和“提交bug”联动在一起，就是在逼这个过程落地。

4.4 文档管理：产品库、项目库和自定义库各归其位

禅道内置了基本的文档管理功能，用来补充没有被流程覆盖的环节。文档库分三类，各有各的位置，不要混着放。

添加文档时选择文件、链接、网页三种类型。文件类型适合上传已有的文档资源；链接类型适合挂外部网页链接；网页类型直接用富文本编辑器写，适合记录会议结论、评审意见这类短文档。

实际使用中我一般建议把“在禅道里写会议纪要”变成团队习惯。评审会、计划会开完，项目经理当场在项目文档库里建一条网页型文档，把结论、待办、负责人写清楚。之后任何人翻项目文档库，都能看到这个项目的决策历史，而不是满世界找聊天记录里的会议结论。

5. 避坑与排查：禅道落地的六个典型翻车场景

禅道本身逻辑并不复杂，但实际落地一个流程，总有环节会在“流程设计”和“人的习惯”之间打架。下面这些坑我从团队实际使用里总结出来，每条都按现象、原因、解决三个层面写，遇到对号入座。

5.1 需求卡在“已变更”，开发却说不知道

现象：需求详情页显示“已变更”，评审也确认通过了，但开发在下一个迭代仍然按旧描述开发。项目经理复盘时发现需求变更记录躺在一个月前。原因：需求变更被确认之后，禅道里还有任务确认需求变动、Bug确认需求变动、用例确认需求变动三个确认环节，团队只走了评审，没有把变更结果通知到关联的任务、bug和用例，开发侧没有收到任何感知。解决：把这三个确认环节写进项目规范，需求变更确认后由项目经理在站会上同步一次，同时要求开发和测试在个人待办里处理“确认需求变动”相关事项。从那之后，每轮变更都强制关联任务和用例。

5.2 燃尽图十天没动，项目经理还在等各种列表

现象：燃尽图从迭代第三天开始就成了一条水平线，项目群里的进度汇报却显示“开发中，一切正常”。原因：开发没有在禅道里更新任务剩余工时，燃尽图的数据源断了，项目经理看到的列表状态全是“进行中”，没有剩余工时变化，图表自然一动不动。解决：把“每天下班前更新任务”立成硬规矩，更新内容包括任务状态和剩余工时。项目经理在每日站会打开“我的任务”页面过一遍，没更新的当场提醒。连续更新两周之后，燃尽图才真正开始反映开发节奏。

5.3 需求勾了“不需要评审”，发布前才发现需求描述有硬伤

现象：产品经理为了赶迭代，创建需求时把“不需要评审”勾上，需求直接进入激活状态。开发做完联调，测试验收时发现需求描述里的字段逻辑有问题，返工一轮，发布延期。原因：评审这个动作本质上是给需求“拍一次板”，跳过评审等于省略拍板，需求描述里的问题要等下游环节来发现。解决：把“不需要评审”的开关权限收敛起来，关键需求强制走评审；确实要走快速通道的，让产品负责人单独确认一次再激活。可以在团队规范里写明，凡涉及数据结构、金额、权限的需求，不允许跳过评审。

5.4 产品设成私有，整个部门只有三个人看得到

现象：新项目上线，其他部门的同事问需求进度时，在禅道里找不到这个产品。原因：创建产品时访问控制选了私有，但产品负责人只理解“私有”是权限更安全，没有意识到支持范围只包含产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队。解决：跨部门协作的产品在创建时选公开或按需配置访问权限；已经创建完的，编辑产品调整访问控制。同时把“谁需要看产品”作为创建产品的必答字段，而不是在权限细节里纠结。

5.5 创建发布按钮没有反应，页面提示条件未满足

现象：产品版本已经完成开发，发布负责人点击“创建发布”却无法创建。原因：创建发布有两个前提，一是该产品关联过项目，二是该项目创建过版本。很多团队测试通过后直接急着建发布标签，项目的版本记录还是空的，被前提条件拦住了。解决：先回项目视图创建版本，再回产品视图的发布列表创建发布。如果版本确实没有创建必要，说明发布这个动作本身也没到时机，正好借这个报错停下来确认流程缺口。

5.6 用编辑改需求标题，发现怎么都保存不了

现象：产品经理想修改需求标题，点编辑后改完点保存，发现标题字段根本不能编辑。原因：禅道把需求的标题、描述、验证标准和附件四类字段设为变更受控字段，修改必须走变更流程，普通编辑操作无法修改这些内容。这是为了保障需求变更全程留痕，不是系统bug。解决：进入需求详情页，执行变更操作，修改标题并填写变更原因，提交评审后再确认。如果只是修内部评论或补充说明，用普通编辑操作处理即可，已经标红的受控字段不要死磕编辑入口。

6. 把禅道用顺手：统计报表、我的地盘与团队事实源

6.1 三张报表要定期看，不要等到复盘才拉

产品视图下有需求的统计报表，按产品、按模块、按计划三种维度统计需求数量，产品经理可以快速看出每个模块的需求密度和进展。项目视图下有项目任务的基本报表，按未开始、进行中、已完成维度统计任务数量和剩余工时。测试视图下的报表则聚焦bug，可以按产品、按模块、按指派者查看bug的分布和严重程度。这三张表分别对应迭代前、迭代中、发布前三个场景：定范围看需求统计，开发过程中盯任务统计，准备发布时看bug收敛情况。

6.2 每天先打开“我的地盘”处理指派给自己的事项

“我的地盘”里有待办、我的任务、我的bug、我的需求、我的测试、我的档案几个入口。我个人的建议是早晨第一次刷新禅道先处理“我的任务”和“我的bug”，把指派给自己的事项当天清掉，再处理待办；私人事务在创建待办时勾选“私人”，起止时间可以暂时不设。改密码在“我的档案”里操作，顺手把个人资料核对一遍。这个习惯持续两周，团队里积压的“半死不活”任务会明显变少。

6.3 把禅道当事实源，而不是补录工具

禅道这套工具能解决问题，前提是所有人把它当成唯一的事实源，当天发生的状态变化当天更新。口头汇报、聊天记录截图不能替代系统里的状态流转。有人配合外部工具拉数据、导出报表，也有人把禅道接到团队的自动化流程里做定时同步，但前提都是禅道里的数据本身可信。这份完整版docx整理好了，建议收进团队文档库或内部知识空间里，开启操作时先按手册把产品和模块搭干净，再让团队分角色走一轮操作，后面自然顺。我从那以后每接手一个新团队，都强制走一遍“先搭产品、再拆模块、再分角色实操”的流程，前两周大家觉得麻烦，两个迭代之后，再没有人问“现在到底做到哪了”——看系统就知道。希望帮到你。

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