简介：这份《禅道使用手册（完整版）》面向项目经理、产品经理、开发与测试人员，以及正在引入项目管理工具的中小团队，用于解决项目进度跟踪、任务分配与团队协作中的流程不清晰问题。资源包内共1个docx文档，压缩包约4.02MB，内容以章节化目录组织，便于按角色检索查阅。手册从基本介绍入手，涵盖软件定位、用户角色权限、最简使用流程与登录方式；随后展开个人管理，包括待办的创建与浏览、我的任务与我的BUG的关注处理、个人档案维护；再分别针对产品经理与项目经理，讲解产品维护、需求创建与评审、需求状态与阶段、产品模块与发布计划，以及项目建立、团队组建、需求列表确定、任务分解和燃尽图查看等模块。目前已有5210人学习下载，适合希望系统掌握禅道操作、快速搭建团队协作规范并对照实际项目落地执行的读者参考。
1. 从一份 docx 手册说起：禅道到底该怎么落地
很多团队装完禅道，第一周热情高涨，第二周开始有人绕过系统直接在群里喊“这个 bug 谁改一下”，第三周禅道就变成了一个只用来打卡的摆设。问题往往不在工具本身，而在于没人把「产品—项目—任务—bug」这条链路真正跑通。我手里这份《禅道使用手册（完整版）.docx》就是干这个的：它把禅道从登录、个人待办，到产品经理维护需求、项目经理拆任务、开发领任务建版本、测试提 bug 验证关闭的完整流程，按角色拆成了一页页可对照的操作说明。它适合三类人：刚接手禅道配置的管理员、被要求“把流程搬到线上”的产品或项目经理、以及每天要在「我的地盘」里清任务和 bug 的开发测试。下面我不复述目录，而是按“这份手册能帮你解决什么、怎么照着做、哪里容易翻车”来讲。
2. 角色与流程先对齐：禅道 Scrum 模型的四个关键对象
2.1 五个角色对应的权限边界
禅道把权限绑在角色上，手册 1.2 节列了系统管理员、产品人员、项目经理、开发人员、测试人员五类。这里最容易踩的坑是：很多人以为“角色”只是个头衔，实际上它决定了你登录后左侧菜单能看到哪些入口。系统管理员负责添加用户、分配权限，他不管具体业务；产品人员管产品、需求、计划、发布；项目经理管项目、团队、任务分解；开发和测试则围绕任务与 bug 转。手册里 1.3 节给了四种“最简使用”路径——只做产品管理、只做项目任务、只做 bug 管理、只做个人事务跟踪。我的建议是：小团队别一上来就全流程铺开，先选一条最痛的链路（通常是 bug 管理）跑两周，让所有人习惯“有事进系统”，再逐步加需求管理和项目任务。权限分配时遵循最小可用原则，开发人员不需要“删除需求”的权限，测试人员不需要“创建发布”的权限，这些在后台权限组里都能按模块勾选。
2.2 核心流程的六步闭环
手册 1.4 节把基本流程压缩成六步：产品经理创建产品→创建需求→项目经理创建项目→确定项目要完成的需求→分解任务指派到人→测试人员测试提交 bug。这六步看着简单，但它对应的是禅道底层的数据关联关系：需求必须挂在产品下，任务必须挂在项目下，而项目通过“关联需求”把产品侧的需求拉进来。理解了这个父子关系，你就能明白为什么“需求没评审通过就关联不到项目”——因为只有激活状态的需求才能被项目关联。手册里反复强调“只有激活状态的需求才能关联到项目中，进行开发”，这不是废话，是禅道数据模型的硬约束。实际落地时，我一般会让产品经理先把一个迭代要做的需求全部评审通过，再让项目经理一次性关联，避免边关联边评审导致任务列表反复变动。
2.3 登录入口与个人工作台
手册 1.5 节描述的登录方式是从 OA 系统选择协同工作图标，再进关联系统点禅道。这是典型的单点登录集成场景，如果你的环境是独立部署禅道，直接访问禅道地址用账号密码登录即可。登录后第一站是「我的地盘」，手册第二章把这里讲得很细：待办、我的任务、我的 bug、我的需求、我的测试、我的档案。这里有个实用习惯——每天上班第一件事不是去项目里翻，而是打开「我的地盘」，把指派给自己的任务、需求、bug 按截止时间过一遍。手册 2.2 节说得很直白：“每天的工作其实也很简单，就是将我的地盘中指派给自己的任务、需求或者 bug 及时处理掉就可以了。”待办功能（2.1 节）适合放那些还没进系统的私人事务或临时事项，可以设起止时间，也可以勾选“私人事务”不让别人看到。浏览待办时用日期、类型、名称三个标签筛选，比一页页翻快得多。
3. 产品经理侧：需求、计划、发布怎么串成一条线
3.1 维护产品与模块分类
产品经理登录后进入产品视图，右侧“添加产品”是第一步。手册 3.1 节提醒了几个关键字段：产品代号相当于内部隐喻（比如某产品的代号），产品负责人负责整理和解释需求、制定发布计划，测试负责人用于“公司人比较多、提交 bug 不知道该给谁”的场景，发布负责人主要创建发布。访问控制可以设私有，只有产品添加者、负责人、测试负责人、发布负责人以及该产品项目团队才能访问。产品建好后紧接着是维护模块（3.5 节），模块就是对需求的分类树。操作路径是：产品视图→选择产品→点“模块”→一级级维护。左侧数字是排序字段，调整它就能改变模块在树里的位置；编辑模块时可以修改上级模块，相当于把分类挪个位置。我的经验是模块层级别超过三层，否则需求挂载时选择成本太高，大家就会随便挂甚至不挂，统计报表立刻失真。
3.2 创建需求与评审流程
手册 3.2 节的核心观点是“按照功能点的方式来写需求”，把原来需求文档里的每个功能点摘出来，作为独立需求录入。创建时标题必填，所属计划和模块可暂空，关键是那个“不需要评审”复选框：勾上，新需求直接是激活状态；不勾，需求进入评审流程。评审结果有确认通过、有待明确、拒绝三种。确认通过→状态变激活→可关联项目；有待明确→保持草稿并指派回创建者继续完善；拒绝→必须填拒绝原因。评审人员名单在“由谁评审”字段里输入用户名自动筛选，线下开完评审会再把参与人记录进去即可。这里有个容易忽略的点：需求可以设抄送字段，需求变化会通过邮件抄送给相关人员；还可以设关键词方便检索。我一般要求产品经理把关键词写成“模块名+功能名”的格式，后面在需求列表里搜起来命中率最高。
3.3 需求变更与影响范围确认
需求变更走的是独立流程（3.3 节）。凡是对标题、描述、验证标准、附件的修改，都应该走变更而不是直接编辑——因为编辑操作根本改不了这四项。变更后需求状态变为“变更中”，变更页面会列出该需求的影响范围。评审变更时可选确认通过、撤销变更、有待明确、拒绝。确认通过→状态从“已变更”变回“激活中”；撤销变更→回退到之前版本；有待明确→打回变更者；拒绝→填原因。变更确认后，研发和测试需要分别确认：任务确认需求变动、bug 确认需求变动、用例确认需求变动。这一步在实际执行中经常被跳过，导致开发和测试拿着旧理解干活。我的做法是：变更评审通过后，在项目任务列表里给相关任务加一条备注，强制开发点确认，否则任务不算完成。
3.4 需求状态与阶段的双字段跟踪
手册 3.4 节讲得很清楚，需求有两个字段：状态（status）和阶段（stage）。状态四种：草稿、激活、已变更、已关闭，对应创建、变更、审核、关闭、激活五个操作。阶段描述激活需求在研发过程中的位置：未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。阶段是自动推进的：没关联项目和计划→未开始；关联计划没关联项目→已计划；关联项目没分解任务→已立项；有开发任务进行中且测试任务未开始→研发中；开发任务全完成且测试未开始→研发完毕；有测试任务进行中→测试中；测试全结束但开发还有未结束→测试中；测试和开发都结束→测试完毕；验收阶段需要产品经理手工确认；关闭原因是“已发布”→阶段为已发布。理解这套自动规则，你就能通过阶段字段快速判断一个需求卡在哪一环，而不用点进去看任务详情。
3.5 计划、发布与路线图
发布计划（3.6 节）对产品经理是规划节奏的工具，对其它部门和客户是了解进展的窗口，对项目关联需求是筛选依据。创建计划后可以为计划关联需求，也可以在添加需求时直接指定计划（已过期计划不会列出）。计划和项目没有强对应关系，理想情况是一个计划对应一个项目，但实际中一个项目往往关联多个计划的需求。发布（3.7 节）有两个前提：产品关联过项目、项目创建过版本。创建路径是产品视图→发布列表→创建发布。计划和发布共同组成路线图（3.8 节），绿色代表已发布版本，黄绿色代表将来计划，点击可查看具体需求。文档管理（3.9 节）分产品文档库、项目文档库、自定义文档库三类，文档类型有文件、链接、网页三种。需求统计报表（3.10 节）在产品视图需求子栏目下点“统计报表”，可按产品需求数量、模块需求数量、计划三个维度统计。
4. 项目与开发测试侧：任务分解、版本提交与 bug 闭环
4.1 建项目、组团队、关联需求
项目经理登录后建项目（4.1 节），然后组建项目团队（4.2 节），再确定项目要完成的需求列表（4.3 节）。这三步的顺序不能乱：团队没建好就分解任务，指派时找不到人；需求没关联就分解任务，任务没有来源依据。手册 4.4 节讲任务分解，我一般要求项目经理在分解时把任务粒度控制在 4 到 8 小时，超过一天的任务继续拆。任务指派到人后，开发人员登录就能在「我的地盘」看到。燃尽图（4.5 节）用来了解项目进展，各种列表功能（4.6 节）和任务报表（4.7 节）用于日常跟踪。这里有个实操细节：燃尽图要好看，前提是任务工时估算相对准确，如果大家随手填 1 小时实际干一天，燃尽图就是一条玄学曲线，参考价值归零。
4.2 开发领任务、建版本、申请测试
开发人员（5.1 到 5.4 节）参加项目计划会议分解任务，然后领取任务并每天更新任务状态和剩余工时。任务完成后创建版本（5.3 节），版本里关联本次解决的需求和 bug，然后申请测试（5.4 节）。创建版本是发布的前提，没有版本就没有发布。我见过不少团队开发完直接在群里喊“测吧”，版本号都不建，结果测试提的 bug 无法关联到具体版本，发布时也找不到对应关系。手册 5.5 节讲解决 bug，5.7 节讲确认 bug，这两个动作的区别是：解决是开发改完代码把 bug 状态改为已解决并指派回测试，确认是测试验证通过后关闭。5.6 节的文档管理对开发同样适用，项目文档库用来存项目过程中的设计文档和接口说明。
4.3 测试提 bug、验证关闭与激活
测试人员（6.1 到 6.10 节）先维护 bug 视图模块（6.1 节），然后提交 bug（6.2 节）。提交时必填项包括所属产品、所属模块、影响版本、bug 标题、重现步骤等。验证 bug 后关闭（6.3 节），如果验证不通过则激活 bug（6.4 节）打回给开发。6.5 节讲找到自己需要的 bug，6.6 到 6.9 节讲测试用例视图维护、创建用例、管理测试任务、执行用例并提交 bug。6.10 节是查看报表统计。测试侧最容易出问题的是 bug 描述质量：只写“功能不对”四个字，开发得追着问半天。我要求测试提交 bug 时至少包含环境、前置条件、操作步骤、预期结果、实际结果五项，截图或日志作为附件上传。这样开发解决效率至少翻倍。
5. 避坑与排查：禅道落地中最容易翻车的五个地方
5.1 需求状态卡在草稿，项目关联不到
现象：项目经理在关联需求时搜不到某条需求。原因：该需求创建时没勾“不需要评审”，且还没走评审流程，状态是草稿。解决：让产品经理在需求列表里筛选草稿状态，走完评审确认通过，状态变激活后即可关联。如果需求已经不需要了，直接关闭，别留着占列表。
5.2 任务分解后燃尽图不更新
现象：任务明明在推进，燃尽图却是一条平线或乱跳。原因：开发人员没有每天更新任务的剩余工时，或者任务完成后没有及时点“完成”。燃尽图是根据剩余工时总和绘制的，数据不更新图就不动。解决：把“每天下班前更新任务剩余工时”写进团队约定，项目经理每天上午检查一次，连续两天不更新的在站会上点名。
5.3 bug 解决后测试收不到通知
现象：开发把 bug 状态改为已解决并指派给测试，但测试说没收到。原因：禅道默认通过站内信和邮件通知，如果邮件服务没配好，站内信又没人看，就会漏掉。解决：检查后台邮件配置是否正常，同时要求测试每天至少两次查看「我的地盘」里的“我的 bug”，不要只依赖邮件。
5.4 版本创建了但发布时找不到
现象：产品经理创建发布时提示没有可用的版本。原因：发布的前提是产品关联过项目且项目创建过版本，两个条件缺一不可。如果项目没关联到该产品，或者版本建在了别的项目下，发布时就找不到。解决：先确认项目已关联该产品，再确认版本是在该项目下创建的，且版本关联了本次要发布的需求和 bug。
5.5 模块层级太深导致需求挂载混乱
现象：统计报表里模块需求数量对不上，很多需求挂在根模块或错误模块下。原因：模块树层级过多，产品经理录入需求时懒得逐级展开，直接挂在顶层。解决：模块层级控制在三层以内，录入需求时强制选择到具体叶子模块，定期用统计报表检查模块分布，发现异常集中清理。
6. 进阶技巧：用统计报表和路线图反向验证流程健康度
手册 3.10 节提到的需求统计报表，很多人只把它当汇报材料，其实它是最好的流程体检工具。我一般每周看三个数：产品需求数量、模块需求数量、按计划统计的需求分布。如果模块需求数量里“未分类”占比超过 20%，说明模块树设计有问题或者录入不规范；如果按计划统计里某个计划的需求长期不推进，说明计划制定时拍脑袋了。路线图（3.8 节）同样可以反向验证：绿色发布版本如果间隔忽长忽短，说明发布节奏不稳定；黄绿色计划如果长期不变成绿色，说明计划执行有问题。把这些报表和路线图结合起来看，比单纯盯燃尽图更能发现流程层面的毛病。
另一个进阶用法是文档库的分类维护（3.9 节）。产品文档库、项目文档库、自定义文档库三类要提前规划好分类，不要等文档堆了几百篇再整理。我的习惯是：产品文档库按“需求规格、设计说明、用户手册”分；项目文档库按“项目计划、会议记录、验收报告”分；自定义文档库放公司规范、培训材料。文档类型选“网页”的可以直接用富文本编辑器写，选“文件”的上传附件，选“链接”的存外部地址。每次项目结项时强制把验收报告归档到项目文档库，半年后回头看，这就是团队的知识资产。
从那以后我每次接手一个新禅道环境，都强制走一遍“建产品→提需求→评审→建项目→关联需求→分解任务→建版本→提 bug→解决→验证关闭”的完整链路，哪怕用测试数据跑一遍，也要确认每个环节的状态流转和通知都正常。流程这东西，不自己走一遍，永远不知道哪里会卡住。希望帮到你。
本文还有配套的精品资源，点击获取
