企业官网建设流程全解析

简介：《禅道使用手册（完整版）》面向项目管理初学者、产品经理、项目经理及开发测试协作成员，系统梳理禅道在项目立项、需求流转、任务分解、缺陷跟踪与团队协作中的操作要点，适合快速上手或统一团队流程时查阅。压缩包内含1个docx文档，约4.02MB，以章节化手册形式呈现，便于按角色检索和打印留存。已有5219人学习下载，具有较高的参考热度。手册从软件介绍、用户角色、登录与基本流程讲起，覆盖个人待办、我的任务与我的BUG、个人档案维护，并延伸至产品经理维护产品、创建评审与变更需求、需求状态阶段、维护模块、建立发布计划与发布，以及项目经理组建团队、确定需求列表、组织任务分解、借助燃尽图查看进展等内容。读者可据此建立角色权限与核心流程的整体认知，并作为团队内部培训与日常操作的对照清单。

1. 一份手册把“需求到 bug”的链路讲透了

接手一个已经跑了半年的项目，最怕的不是代码烂，是流程黑匣子——需求散在群聊记录里，bug 靠口头传，进度靠每天早上站会问一遍。这套禅道使用手册（完整版）就是对着这个场景来的：它按产品经理、项目经理、开发、测试四个角色，把需求怎么建、项目怎么组、任务怎么分、bug 怎么流转、用例怎么管一条线串下来。适合两类人：刚接手禅道配置、需要把权限和模块理顺的负责人，以及团队想落地敏捷协作、但流程还停留在表格加群聊阶段的从业者。手册内容覆盖基本介绍、个人管理、产品经理使用、项目经理使用、开发使用、测试使用六个部分，后面几章我按实际落地顺序把关键节点拆开讲。

2. 禅道的对象模型与角色配置：产品、项目、需求、任务怎么彼此咬合

很多人第一次装完禅道，登录进去发现页面是空的，以为装漏了组件，其实是对象之间还没挂上关系。禅道这套东西的底层逻辑不复杂，但四个核心对象（产品、项目、需求、任务）的归属关系必须先理清，否则后面建什么都是散的。这章先把对象模型和角色边界讲透，再落到模块、计划和待办这些日常操作上。

2.1 四层对象关系决定了你登录后看到什么

产品是需求的容器，项目是任务的容器，需求挂在产品下面，任务挂在项目下面，bug 同时挂产品和项目。这层设计带来的直接结果是：你在“我的地盘”里看到的内容，取决于你被指派了什么，以及你所在的项目关联了哪些需求。一个开发登录后看到“我的任务”里空空如也，往往不是权限没给够，而是项目经理还没把需求关联到项目、也没做任务分解，任务对象压根没生成。

把这张表记住，后面所有操作都是在这五类对象之间拉关系。产品经理建完需求和计划，项目经理把需求拉进项目，再分解成任务指派到人，测试对着版本提 bug，开发解决后流转回测试验证——这条链路走通，禅道才真正转起来。很多团队用不起来，就是因为只建了产品没建项目，或者建了项目没关联需求，对象之间断裂，最后退回群聊里追进度。

另外要提醒一点：产品代号、产品负责人、测试负责人、发布负责人这几个字段在创建产品时就要填对。产品负责人负责整理和解释整个产品的需求，测试负责人决定了默认的 bug 接收人，发布负责人负责创建发布。团队人一多，提交 bug 时不知道该给谁的问题就靠这几个字段兜底。访问控制字段也别忽略，把产品设为私有后，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才能访问，这在多产品并行时能省掉不少权限纠纷。

2.2 五种角色的权限边界：别给开发开产品经理权限

禅道默认的角色有系统管理员、产品经理、项目经理、开发、测试五种。系统管理员管账号和权限分配，产品经理管产品、需求、计划、发布，项目经理管项目、团队、任务分解，开发领任务、建版本、解决 bug，测试提交 bug、建用例、验证关闭。听起来各司其职，但实际配置中最常见的翻车操作是图省事给开发也开了产品经理权限，结果需求被随手改标题、改验收标准，变更记录对不上，评审流程形同虚设。

我的建议是按最小权限分配，开发只给开发权限加项目访问权限，测试只给测试权限加对应产品的访问权限。需求变更必须走变更流程，不能靠“谁能编辑谁就改”来兜底。权限这个东西，配的时候多花十分钟，后面少吵十次架。

2.3 模块维护：需求的分类树要先于需求本身建立

模块相当于对产品需求的分类。维护入口在产品视图下的“模块”菜单，一级一级往下建，左侧的数字用来排序，调整排序字段就能改变模块树里的位置。编辑模块时还可以修改它的上级模块，把建错层级的节点挪回去。

这一步很多人跳过，直接开始提需求，结果需求列表越攒越长，找一个功能点的需求要翻十几页。合格的从业者一般会在产品创建后先把模块树搭到二级或三级，粒度对齐功能模块而不是开发人员分工。模块树建好之后，提需求时选择所属模块，后面按模块出统计报表才有意义。手册里 3.5 节虽然只有一页多，但这步的收益在三个月后需求上两百条时会非常明显。

2.4 个人待办与“我的地盘”四个入口

日常使用频率最高的其实是“我的地盘”这个页面。待办的创建路径是：我的地盘 → 日程 → 添加待办，可以设定起止时间，私人事务勾选私人标记。浏览待办时按日期、类型、待办名称这些标签检索。

更关键的是“我的地盘”下面的四个快捷入口：我的任务、我的 bug、我的需求、我的测试。凡是指派给自己的事项都会出现在这里，每天的工作流其实就一句话——打开我的地盘，把指派给自己的任务、需求、bug 及时处理掉。手册 2.2 节把这条讲得很直白，但实际推行时团队里总有人不看这个页面，习惯等别人在群里喊。我的做法是项目启动会上把这个页面设成浏览器首页，强制养成习惯，两周后基本就离不开了。

“我的档案”页面可以查看和修改个人信息，包括改密码。这个入口不复杂，但新成员入职后第一件事应该是改密码，而不是沿用管理员设置的初始密码。

3. 从需求到任务：产品经理与项目经理的交接链路

产品和项目之间最容易断的环节，就是需求从产品侧交到项目侧的那一步。产品经理建完需求觉得活干完了，项目经理等着需求进项目才能分解任务，两边一卡就是好几天。这章按“创建需求 → 评审 → 变更 → 关联项目 → 分解任务 → 看燃尽图”的顺序把链路走一遍，重点讲清状态字段和阶段字段这两个容易混淆的维度。

3.1 需求创建：标题必填，所属计划和模块可以先空着

创建需求的入口在产品视图右侧的“提需求”菜单。需求标题是必填项，所属计划和模块可以暂时保留为空。评审那一栏有个“不需要评审”的复选框，勾上之后新创建的需求状态直接就是激活的，只有激活状态的需求才能关联到项目中开发。需求还可以设置抄送字段，后续需求变化会通过邮件抄送给相关人员；关键词字段用于检索，功能点多的时候能省不少搜索时间。

新建需求时到底勾不勾“不需要评审”，取决于团队成熟度。产品经理一个人负责、需求来源单一的小团队，勾上能省掉一道流程；多人协作、需求来源杂的团队，建议老老实实走评审，把不成熟的想法先存成草稿，后续再处理。手册 3.2 节给的建议也是这个思路：即使产品完全由一个人负责，也可以把不成熟的想法存为草稿。

3.2 需求变更为什么不能直接编辑标题

禅道专门把“编辑”和“变更”分成了两个动作。编辑操作无法修改需求的标题、描述、验收标准和附件，凡是对这四项的修改都必须走变更流程，变更之后需求状态变为“变更中”。这么设计不是故意麻烦人，是为了留下变更前后的对比记录——需求详情页可以直接看到变更前后的差异，评审者对着差异给结论。

变更需求的评审结果有四个选项：确认通过、撤销变更、有待明确、拒绝。确认通过后需求状态从“已变更”回到“激活中”；撤销变更则取消当前变更并回退到之前的版本；有待明确会把需求打回到变更者头上继续完善；拒绝需要给出原因。变更时系统会列出该需求的影响范围，包括关联的任务、bug 和用例，评审者可以参考这个范围判断影响面。

这里有个容易漏的动作：需求变更被确认之后，研发团队和测试人员需要分别确认需求变动，任务、bug、用例三个地方都要走一遍确认。实际执行中经常是需求改了、任务没同步，开发按旧理解写，测试按旧用例验，最后 bug 提上来发现是需求理解偏差。所以变更流程走完之后，项目经理要盯着任务确认，测试负责人要盯着用例确认，这一步不能省。

3.3 状态字段与阶段字段：两个维度跟踪同一个需求

需求有两个字段在跟踪它的变化，新手最容易混。状态字段描述的是需求的生命周期，总共四种：草稿、激活、已变更、已关闭，对应的流程操作是创建、变更、审核、关闭、激活。阶段字段描述的是激活状态的需求在研发过程中走到哪一步了，包括未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。

这张表建议打印出来贴在工位上。实际排查“为什么需求阶段不动”的问题时，九成情况是任务没分解或者任务状态没更新——阶段字段是跟着任务状态自动推的，不是手工改的。判断一个需求能不能进项目看状态（必须是激活），判断它研发到哪一步看阶段，两个字段各管各的，别混着用。

3.4 项目组建与需求关联：项目不是凭空建的

项目经理建项目之后，第一件事是组建团队，第二件事是确定项目要完成的需求列表。需求关联的入口在项目视图里，关联时只能选激活状态的需求。这里有个前置条件容易被忽略：需求最好先关联到计划，再通过计划关联到项目，这样发布计划和项目执行之间才有对应关系。当然禅道里计划和项目并没有强绑定，一个计划对应一个项目是理想状态，实际情况往往是项目关联的需求大部分来自某个计划，同时夹杂其他计划的部分需求。

关联完需求之后才轮到任务分解。任务分解的粒度按人天控制比较合适，一个任务超过三天就应该拆细，否则燃尽图上看不出进展。指派到人这一步别偷懒，任务不指派就等于没分解，开发登录后“我的任务”里看不到东西，自然也不会去更新状态。

3.5 燃尽图看的是剩余工作量曲线，不是完成百分比

燃尽图的横轴是时间，纵轴是剩余工时，理想线是一条从总工时斜降到零的直线，实际线围绕理想线波动。项目经理每天要做的事其实很简单：看实际线有没有持续偏离理想线。连续几天实际线走平，说明任务状态没更新或者有人卡住了；实际线突然翘上去，说明有新任务插入或者估时被调大。

手册 4.5 节提到用燃尽图了解项目进展，但没展开讲怎么读。我的经验是结合任务列表一起看：燃尽图走平的时候，切到任务列表按状态筛“进行中”且超过三天的任务，一个个问过去，比开站会挨个问效率高得多。另外项目任务的基本报表统计也在项目视图里，按人、按模块、按状态都能出，周报数据从这里取比手工统计靠谱。

4. 开发与测试协同：版本、bug 生命周期与用例管理

开发和测试之间的协作，最怕两件事：开发说“改完了”但测试不知道拿什么版本验，测试提了 bug 但开发找不到复现路径。这章按“建版本 → 申请测试 → 提 bug → 解决 → 验证关闭”的顺序讲，中间穿插视图维护和用例管理，最后补一下文档库的用法。

4.1 创建版本与申请测试：开发提交测试的标准动作

开发完成任务后要做两个动作：创建版本和申请测试。创建版本的入口在项目视图的版本列表，版本号、版本日期、关联的需求和 bug 都要填。申请测试则是把版本提交给测试人员，测试收到之后才开始建测试任务、执行用例。这两个动作顺序不能反，先申请测试后建版本，测试拿到的是一个空版本，没法验。

版本号命名建议跟发布计划对齐，比如计划里定的是某个迭代，版本号就用迭代号加小序号。手册 5.3 和 5.4 节把这两个动作分开讲，实际执行中开发最容易漏的是“关联 bug”——本次版本修复了哪些 bug 要勾上，否则测试验证时不知道哪些 bug 该在这个版本里关闭。

4.2 bug 状态流转：激活、已解决、已关闭、再激活

bug 的生命周期比需求简单，但流转规则要记清。测试提交 bug 后状态是激活；开发解决后改为已解决，同时要填解决方案（比如已修复、设计如此、重复 bug、无法重现等）；测试验证通过后关闭，验证不通过则重新激活，打回给开发。手册 6.4 节专门讲了激活 bug 的操作，实际场景是关闭后的 bug 又复现了，或者开发标记“无法重现”但测试坚持能复现，这时候重新激活并补充复现步骤。

这里有个血泪经验：开发填解决方案时图省事全选“已修复”，测试验证时发现有的其实是“设计如此”，来回扯皮。解决方案字段不是走过场，选“设计如此”的 bug 应该直接关闭并注明原因，选“无法重现”的要附上开发本地的验证环境信息，不然测试没法判断是自己环境问题还是真的没修。

4.3 测试用例与视图维护：让 bug 可检索

测试用例的维护入口在测试视图，创建用例时要选所属模块、关联需求、写前置条件和操作步骤。执行用例时按用例一步步走，发现问题直接从用例页面提交 bug，bug 会自动带上用例关联的需求和模块信息。手册 6.6 到 6.9 节把这条线讲全了：维护用例视图模块、创建用例、管理测试任务、执行用例并提交 bug。

bug 视图模块的维护跟产品模块是两套东西，别混。bug 视图模块是给 bug 分类用的，可以按功能模块建，也可以按严重程度建，看团队习惯。我一般建议按功能模块建，跟产品模块树对齐，这样按模块出 bug 统计报表时能和需求数据对上。手册 6.5 节提到“找到自己需要的 bug”，检索条件就是靠视图模块加状态、指派给这些字段组合出来的。

4.4 文档库的三种类型与使用边界

禅道内置的文档管理分三种库：产品文档库存产品层面的文档，项目文档库存项目过程中的文档，自定义文档库存知识库、管理规范这类内容。文档类型有文件、链接、网页三种，文件类型上传附件，链接类型填网页地址，网页类型直接用富文本编辑器写。

文档库这功能定位是补位——禅道没覆盖到的流程用文档管理兜底。接口文档、部署手册、会议纪要这类东西放进去，比散在共享盘里强。但别指望它替代专业的知识管理工具，检索和版本管理都比较基础，大团队文档量上来之后还是得往外迁。维护分类的入口在文档视图下方，建分类的逻辑跟模块树类似，先建大类再往下分。

5. 踩坑排查：四条高频翻车现场与解决路径

配置和使用过程中有几类问题反复出现，这章按“现象 → 原因 → 解决”的格式记四条，都是实际项目里踩过的。

5.1 现象：需求创建完，项目里关联不到

原因：需求状态不是激活。创建需求时没勾“不需要评审”，需求停在草稿状态；或者走了评审流程但评审结果选了“有待明确”，需求被打回创建者，状态没回到激活。

解决：先看需求详情页的状态字段。草稿状态的走评审，评审结果选“确认通过”；有待明确的补完信息重新提交评审。只有激活状态的需求才能被项目关联，这个前置条件在手册 3.2 节写得很清楚，但实际排查时经常被忽略，以为是权限问题。

5.2 现象：bug 标记已解决后，测试那边找不到验证入口

原因：bug 的指派对象没改回测试人员。开发解决 bug 时只改了状态和解决方案，指派给还是自己，测试在“我的 bug”里看不到这条记录。

解决：解决 bug 时把指派给改成提交该 bug 的测试人员，或者改到测试负责人。团队人少的时候容易漏这步，因为提交人和解决人可能就坐对面，口头说一声就完了，但禅道里的流转记录对不上，后面出报表时数据是断的。建议在项目规范里写死：解决 bug 必须改指派给，状态和指派两个字段一起动。

5.3 现象：燃尽图曲线是平的，或者某天突然断崖式下跌

原因：任务工时没更新。燃尽图读的是任务的剩余工时字段，开发每天更新任务时如果只改状态不改剩余工时，曲线就不动；某天集中补更新，曲线就断崖。这属于玄学问题里比较典型的一类——图本身没坏，是数据源没维护。

解决：把“每天更新任务剩余工时”写进日常规范，项目经理每天下班前扫一眼任务列表，超过两天没更新的任务单独提醒。另外任务分解时估时别拍脑袋，按人天估，超过三天的拆细，估时准了燃尽图才有参考价值。手册 4.5 节讲燃尽图了解进展，前提就是工时数据在持续更新。

5.4 现象：模块删不掉，或者需求分类越理越乱

原因：模块下面还挂着需求或者子模块。禅道的模块删除有前置条件，子节点非空时删不掉父节点；另外需求创建时所属模块选了但后来模块树调整过，需求还挂在老模块上。

解决：调整模块树之前先查一遍每个模块下的需求数量，有需求的模块要么先把需求迁移到新模块，要么保留不删改成“已废弃”标记。模块树的调整频率别太高，一个迭代动一次可以接受，天天动的话需求分类永远理不清。建议在产品创建初期就把模块树定到二级，后面只增不改。

6. 进阶用法：报表统计、路线图与数据规范

禅道用顺之后，提效的抓手主要在报表和路线图上。产品视图下的需求子栏目里有“统计报表”入口，能出三类数据：产品需求数量、模块需求数量、按计划统计的需求分布。这三张表看着简单，但配合模块树用起来很实用——模块需求数量表能看出哪个功能模块的需求最密集，按计划统计能看出每个迭代的负载是否均衡。我一般每个迭代结束导一次，跟燃尽图对照着看，判断下个迭代的容量该定多少。

路线图在产品视图下，由计划和发布组成：绿色部分是已发布的版本，黄绿色部分是未来的计划，点某个发布或计划能下钻看具体的需求信息。给管理层汇报进度时用路线图比列任务清单直观，但前提是计划和发布建得规范，计划不关联需求、发布不关联项目和版本的话，路线图就是空的。手册 3.6 到 3.8 节把计划、发布、路线图的关系讲清楚了：创建发布有两个前提，产品关联过项目、项目创建过版本，这两个前提缺一个发布就建不了。

最后说数据规范，这是用了一年之后回头看最后悔没早做的事。模块命名统一用“一级模块-二级模块”的格式，需求标题统一按“动词+对象+场景”写，bug 标题必须带复现路径的关键词，任务估时统一用人天。这些规范不写进文档就靠口头传，新人进来一批乱一批。我现在接手新项目的习惯是：配置完账号权限后的第一件事，不是建产品，是把模块命名规范和需求标题模板写成文档放进自定义文档库，然后拉着全员过一遍。从那以后我每次开新项目都强制走一遍这个流程，少了这一步，三个月后数据没法看。

希望帮到你。

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