企业官网建设流程全解析

简介：《禅道使用手册（完整版）》以Word文档形式系统梳理禅道项目管理工具的日常操作路径，适合项目经理、产品经理、开发与测试人员以及刚接触禅道、需要快速上手团队协作流程的读者使用。文档围绕基本介绍、个人管理、产品经理使用、项目经理使用等模块展开，覆盖用户角色与登录、待办创建与浏览、我的任务与BUG跟进，以及需求创建评审、变更管理、发布计划、项目团队组建、任务分解和燃尽图查看等关键环节，可作为团队内部培训或流程规范的参考材料。资源包共1个docx文件，大小约4.02MB，目录层级清楚，便于按角色和功能检索。该手册已有5219人学习，内容从基础流程延伸到角色分工与项目跟踪，能帮助读者理解禅道在需求、任务、缺陷和项目进度管理中的实际用法，减少摸索成本。

1. 一份说明书，能不能让全组人第一次用对禅道

刚进项目组的新人常遇到一个场景：导师丢来一个文档，说「先看看这个，熟悉一下我们的项目管理工具」，打开一看，目录从「基本介绍」排到「统计报表」，几十页，头就大了。这份《禅道使用手册（完整版）》讲的就是这样一个东西——禅道是一款基于 Scrum 思想的项目管理软件，把产品管理、项目管理、bug 管理、测试用例管理、文档管理装进同一个网页系统里，让一个团队不用再靠聊天记录和 Excel 表格追进度。

它解决的不是「怎么写代码」，而是「谁在做什么、做到哪一步、出了问题记在哪里」。适合三类人：刚入职要跟着流程走的新人、被安排「你来把项目管理起来」的小团队负责人、以及想弄清需求从提出到关闭整条链路的人。下面按「先认角色、再走流程、最后动手」的顺序，一步步带你上手。

2. 先认清五个角色：禅道里谁在什么时候做什么

打开系统之前，先别急着点按钮。禅道这个软件的设计思路很朴素：不同的人登录进去，看到的东西是不一样的。同一台服务器，产品经理看到的是需求和计划，开发看到的是任务和 bug，测试看到的是用例和缺陷单。理解这一点，后面所有操作都会顺很多。

2.1 五个角色各自的边界，越界就是给自己找麻烦

手册里把用户角色分成五类，我把它翻译成大白话：

• 系统管理员（Admin）：负责建账号、分配权限。他不管业务，只管「谁能进门、进门后能进哪几个房间」。
• 产品经理（product owner）：负责产品本身。建产品、写需求、排计划、做发布。
• 项目经理（Project Manager）：负责把需求变成可执行的任务，协调产品、开发、测试三方把版本做出来。
• 开发人员（developer）：领任务、写代码、建版本、解决 bug。
• 测试人员（QA）：提 bug、验 bug、维护测试用例、执行测试任务。

这里有个新手最容易忽略的点：角色不是职位，是权限包。小团队里一个人可能同时是产品经理和项目经理，甚至开发兼测试。这不违法，但建议你日常操作时用对应的身份登录，或者至少在脑子里分清「我现在是以产品经理的身份在写需求，还是以开发的身份在解决问题」。混着来，数据就会乱。

我第一次接触这类工具的时候，图省事一直用管理员账号干所有事，结果报表里所有操作都记在同一个人头上，出了问题完全没法回溯——这算是血泪经验，后面避坑那章还会细说。

2.2 主流程六步：从建产品到关 bug

手册里给出的基本流程只有六步，值得背下来：

1. 产品经理创建产品。
2. 产品经理创建需求。
3. 项目经理创建项目。
4. 项目经理确定项目要做的需求。
5. 项目经理分解任务，指派到人。
6. 测试人员测试，提交 bug。

这六步是一条主干，剩下的发布、版本、用例、文档、报表，全是挂在这条主干上的枝叶。你可以把它想成一条流水线：产品经理在上游投料（需求），项目经理在中间分料（任务），开发和测试在下游加工和质检（代码和 bug），最后产品经理宣布出厂（发布）。

流程之所以重要，是因为禅道里很多字段是联动的。需求不关联项目，它的阶段就永远停在「未开始」；项目不关联需求，燃尽图就画不出东西；没有创建版本，发布功能直接不让你建。新手觉得「这个按钮点了没反应」，八成是上游有一环没做。

2.3 登录之后先看「我的地盘」，别急着逛菜单

手册里的登录方式是从统一入口进入，选择协同工作里的关联系统，再点禅道图标进去。不同公司的入口长得不一样，你按内部说明走就行，登录成功之后落到哪个页面才是重点。

登录后默认进入的是「我的地盘」。这一块是给个人用的，不是给管理者用的。它包含四块内容：

• 日程/待办：自己给自己记的事，可以设起止时间，私人事务还能勾选「私人」不公开。
• 我的任务：所有指派给你的任务。
• 我的 BUG：所有指派给你的缺陷单。
• 我的需求 / 我的测试：指派给你的需求与测试任务。

手册里有句话我特别认同：使用禅道，每天的工作其实很简单，就是把「我的地盘」里指派给自己的任务、需求、bug 及时处理掉。对新人来说，这就是每天上班打开电脑后的第一个动作，比研究各种报表有用得多。

具体做法是：进入「我的地盘」，再进「日程」，点添加待办，填标题，设定起止时间（不确定就留空），私人事务勾上私人。想找以前的待办，用日期、类型、待办名称这几个标签筛一下就能翻出来。另外「我的档案」里可以看和改自己的个人信息，包括改密码——这个页面看着不起眼，但新人第一次登录后被要求改密码，很多人会在系统设置里翻半天。

提示：待办是「私事本」，任务是「公家活」。别把团队要跟进的活儿只写进自己的待办里，那样别人看不到，也没法统计。

2.4 用「最简使用」降低第一天的心理负担

手册里有一节叫「最简使用」，列了四种最小用法：只用来做产品管理、只用来做项目任务管理、只用来做 bug 管理、只用来做个人事务跟踪。这个设计对新手特别友好——你不需要一次把所有模块都用上。

如果你所在团队只用了 bug 管理，那你的日常就是「提 bug、改 bug、验 bug」三件事；如果团队只做任务管理，那你只需要关心任务列表和燃尽图。先把手上这条线跑顺，再去理解别的模块，比一上来啃完整流程轻松得多。

3. 需求怎么变成任务：产品经理和项目经理的接力

这一章讲的是整条流水线最上游的两段，也是新手最容易看不懂的部分。你不需要成为产品经理，但要能看懂需求和任务之间的关系，否则你在系统里点开一个需求，看到「草稿」「激活」「已变更」这些状态会一头雾水。

3.1 建产品：代号、负责人和访问控制

产品经理登录后进入产品视图，点右侧「添加产品」。如果系统里一个产品都没有，页面会自动跳到新增页。填的时候有几个字段值得说明：

「访问控制」这个字段新人常忽略。手册里写得很清楚：设为私有之后，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才能访问。做内部项目或者还没对外公布的产品时，这一项要记得设，不然全公司都能看见你的半成品。

3.2 提需求与评审：草稿也有存在的价值

建完产品，接下来是提需求。手册强调一个原则：按功能点的方式写需求，也就是把原来需求文档里的每一个功能点摘出来，作为一条独立的需求录进系统。不要整篇文档往一个需求里塞，那样后面没法关联任务、没法单独跟踪进度。

操作路径是：产品经理登录，进入产品视图，点右侧「提需求」，填标题（必填），所属计划和模块可以先留空，然后处理「不需要评审」这个复选框。

这里有个小分歧值得讲清楚。勾上「不需要评审」，新建的需求直接是「激活」状态，可以立刻关联到项目里开发。不勾，需求就是「草稿」，要走评审流程。

很多新人以为「不需要评审」是省事开关，其实它的真实用途是：产品完全由一个人负责、想法已经很成熟时，跳过形式化的评审。手册里那句话说得挺妙——即使产品完全由一个人负责，也可以把一些不成熟的想法存为草稿，后续再处理。换句话说，草稿不是失败状态，是「还没想好」的正常存放处。

评审页面上，结果有几种选法：

• 选「确认通过」，需求状态变成「激活中」，可以关联到项目开发。
• 选「有待明确」，需求保持草稿状态，并指派回创建者头上继续完善。
• 选「拒绝」，必须给出拒绝原因。

另外有两个小字段值得用起来：抄送可以把需求变化通过邮件同步给相关人，关键词方便以后检索。评审本身可以是线下开的会，系统里只需要把参与评审的人员名单记录下来即可。

3.3 需求的两个字段：四种状态与九个阶段

这是整章最需要记牢的地方，因为后面所有的「为什么这个按钮是灰的」都跟它有关。需求有两个字段在跟踪它的变化，一个是状态，一个是阶段。

状态字段只有四种：

对应操作是创建、变更、审核、关闭、激活。

阶段字段描述的是「这条激活的需求在研发过程中走到哪了」，共九个：未开始、已计划、已立项、研发中、研发完毕、测试中、测试完毕、已验收、已发布。

它们之间的推进逻辑，手册写得很细，我挑关键的说：

• 没关联项目也没关联计划 → 未开始。
• 关联了计划但没进项目 → 已计划。
• 进了项目但没分解任务 → 已立项。
• 有开发任务在推进、测试任务还没开始 → 研发中。
• 开发任务全完成、测试还没开始 → 研发完毕。
• 有测试任务在跑 → 测试中。
• 开发和测试全部结束 → 测试完毕。
• 「已验收」需要产品经理手工确认。
• 需求关闭且原因是「已发布」→ 已发布。

看懂这套规则，你就能回答新人最常问的那个问题：「为什么我这条需求一直显示未开始？」——因为它还没被关联进任何一个项目。

3.4 模块、计划、发布、路线图：四件容易混的事

这四个词在新人脑子里经常糊成一团，其实各有分工。

模块是对需求的分类。进产品视图，选中产品，点「模块」菜单，然后一级一级维护，左侧数字是排序值，编辑时可以改上级模块。它的价值在于让大家对产品有宏观认识，也方便按模块筛需求。建议在提需求之前先把模块树搭好，不然需求越堆越多，最后全在「未分类」里。

计划是产品经理用来规划发布节奏的。进产品视图，点「计划列表」，点右侧「创建计划」。建完之后可以给计划关联需求，也可以在提需求时直接指定计划（已经过期的计划不会列出来）。计划对两类人有用：产品经理用它安排优先级，其他部门和外部客户用它了解进展。

发布是项目结束后的动作，用来告诉相关部门「新版本可以用了」。建发布有两个前提条件：该产品关联过项目，且该项目创建过版本。少了任何一个，创建发布都走不通。

路线图不是独立功能，而是计划和发布拼出来的视图。绿色代表已经发布的版本，黄绿色代表将来的计划，点进去能看具体需求。

注意：计划和项目不是一对一关系。手册里说得很实在——如果某个团队计划执行得都很好，一个计划对应一个项目是理想状态；一般情况下，项目关联的需求大部分来自一个计划，同时也掺了其他计划的部分需求。

3.5 建项目、组团队、关联需求、分解任务、看燃尽图

轮到项目经理上场。顺序是：建立项目 → 组建项目团队 → 确定项目要完成的需求列表 → 组织任务分解 → 用燃尽图看进展。

团队这一步别跳过。人没加进项目，任务指派时根本选不到他。需求关联这一步也别省，项目里没有需求，任务分解就没有依据，燃尽图会是一条毫无意义的直线。

任务分解是项目经理最核心的动作：把一条需求拆成若干可执行的任务，指派到人，估算工时。拆得粗，进度就失真；拆得细，管理成本又上去了。入门阶段的判断标准很简单——一个任务最好能在一两天内做完，并且一个人能独立完成。

燃尽图是项目经理每天要瞄一眼的东西。它画的是剩余工作量随时间的变化，理想情况下曲线一路向下，实际情况下它经常先平后陡。看到曲线平了好几天，不要怀疑软件有 bug，先去任务列表里看看是不是没人更新状态。

另外手册提到项目视图里有各种列表和各种统计报表，可以按需查看项目任务的基本报表。入门阶段不用全看，先盯住任务列表和燃尽图这两样，够用了。

4. 一条 bug 的完整来回：开发和测试怎么配合

前面三章讲的都是「计划中的事」，这一章讲「实际发生的事」。需求和任务再漂亮，代码写完照样会出问题，bug 管理就是记录和消化这些问题的机制。这是禅道里使用频率最高的功能，也是最容易用歪的功能。

4.1 开发侧：领任务、更新状态、创建版本、申请测试

开发的日常动作其实就四件：

第一，参加项目计划会议，认领或接受分解出来的任务。手册里写的是「领取任务」，有的团队是项目经理直接指派，形式不同，结果一样——任务落到你头上。

第二，每天更新任务。这一点必须强调。任务状态不更新，燃尽图就是假的，项目经理就是瞎的。更新的内容通常包括已消耗工时和剩余工时，剩余工时归零时任务才算完成。

第三，创建版本。版本可以理解为「一批可以交付测试的代码」的快照。建版本的时候要写清楚版本号、关联的构建内容、要解决哪些需求和 bug。这个动作是后面建发布的前提，也是测试人员知道「该测哪一版」的依据。

第四，申请测试。把建好的版本提交给测试，附上说明：这一版改了什么、重点测哪里。写清楚能省掉大量来回问的时间。

4.2 测试侧：先维护 bug 视图，再提交 bug

测试人员登录后，第一件事是维护 bug 视图模块。视图不是花架子，它是筛选条件。团队人一多，bug 列表几百条，没有视图就只能靠翻页。

提交 bug 的时候，有几项信息必须认真填：

• 标题：一句话说清现象，不要写「有问题」「打不开」这种没法检索的词。
• 严重程度：影响多大，比如崩溃和文案错误不是一个级别。
• 优先级：多急，这个往往由产品经理或项目经理定。
• 复现步骤：一步步写清楚怎么操作能重现。
• 所属模块、影响版本、指派给谁。

复现步骤是新手最容易糊弄的地方，也是后面避坑章要重点讲的地方。写得含糊，开发看不懂，bug 被退回，一来一回两天就没了。

另外手册提到，测试人员也可以维护自己的 bug 视图，找到自己需要关注的 bug。这个习惯值得养成：给自己建几个固定视图，比如「我提的未关闭的」「指派给我待验证的」，每天扫一遍。

4.3 解决、验证、关闭、激活：一条 bug 的四种去向

bug 的状态流转是禅道里最像乒乓球的环节，来回几趟很正常：

1. 测试提交 bug，指派给开发。
2. 开发解决 bug，填写解决方案（比如已修复、设计如此、无法重现、重复 bug 等），指派回测试。
3. 测试验证。修好了就关闭；没修好就激活，重新指派回开发，并补充说明。
4. 如果关闭之后问题又出现，可以再激活。

「激活」这个动作很多人不敢用，觉得驳回别人不好意思。其实它是最正常的质量动作，只要写清楚为什么没通过就行。反过来，开发在解决 bug 时如果认为「设计如此」，也应该在解决方案里说明理由，而不是直接关掉。

4.4 测试用例与测试任务：执行用例时顺手提 bug

比 bug 更靠前的一层是测试用例。手册里的路径是：维护测试用例视图 → 创建测试用例 → 管理测试任务 → 执行用例，执行过程中发现问题就顺手提 bug → 最后看报表统计。

用例的价值在于可重复。一个版本改完，你不用凭记忆想「上次我是怎么测的」，照着用例清单走一遍就行。刚起步的团队不必追求用例覆盖率，先把核心流程写成用例，把最容易出问题的分支补上，就够用了。

测试任务则是把用例组织成一轮执行计划：这一轮测哪些模块、谁负责、什么时候完成。执行时逐条标记通过或失败，失败的直接转成 bug。

4.5 需求变更时，三处都要确认

需求中途改是常态，但改完之后有一件事特别容易漏：任务、bug、用例三方都要确认变更。

手册里明确写了三种确认：任务确认需求变动、bug 确认需求变动、用例确认需求变动。原因很简单——需求一变，原来写的测试用例可能失效，已经提的 bug 可能不成立，正在做的任务可能白做。三处不确认，最后就会出现「按新需求改完了，测试还在按老用例提 bug」这种翻车场面。

4.6 需求变更流程：为什么不能直接编辑

变更需求这件事，禅道专门做了一条流程，而不是让你直接编辑。凡是对需求标题、描述、验证标准、附件的修改，都应该走变更流程，改完之后需求状态变成「已变更」。

关键点在这里：普通编辑操作改不了标题、描述、验收标准和附件。很多人第一次遇到这个限制会骂软件难用，其实这是故意的——这些是需求的「合同条款」，改了必须留痕、必须评审。

变更时可以选「不需要评审」，选了之后需求自动变回激活状态，跳过评审。变更页面还会列出这条需求的影响范围，评审时可以参考。评审结果有四种：确认通过（状态从已变更变回激活中）、撤销变更（回退到上一版本）、有待明确（打回给变更者）、拒绝（需写原因）。

5. 避坑清单：新手用禅道最容易翻车的五个现场

这一章讲的全是别人踩过的坑。每一条按「现象 → 原因 → 解决」写，你对照自己的操作习惯看看有没有中招。

5.1 需求随手改，任务和用例全对不上

现象：开发按新理解做完了，测试说「需求上不是这么写的」，一查需求，描述确实变了，但没人收到通知。

原因：绕过变更流程，直接编辑需求，或者改了但没评审、没让相关人确认。变更流程的意义不只是记录，更是通知机制。

解决：凡是改标题、描述、验收标准、附件，一律走变更流程；变更后在评审页面确认通过的，还要去任务、bug、用例三处确认需求变动。团队里定一条规矩：需求变更当天，负责人在群里同步一句「需求 X 已变更，涉及任务 Y、用例 Z」。

5.2 bug 描述只有一句话，开发直接打回

现象：提了个 bug，标题写「页面打不开」，指派给开发，两小时后被退回来，理由是「无法重现」。

原因：复现步骤缺失。开发在你机器上重现不了，就没法定位问题，退回是最省时间的做法。

解决：提交 bug 时强制自己写清三件事——在哪个页面、做了什么操作序列、看到什么结果、期望看到什么结果。有报错信息就贴报错，有截图就传截图。顺便把影响版本填对，否则开发不知道该去哪个分支查。

5.3 项目建完不关联需求，燃尽图画成一条直线

现象：项目建好了，任务也指派了，燃尽图看着像没开工，项目经理天天问进度。

原因：一是项目没关联需求，二是任务状态没人更新。燃尽图算的是「剩余工作量」，剩余工时没人改，它当然不动。

解决：建完项目先确定需求列表，再拆任务；要求每个人每天下班前更新自己任务的状态和剩余工时。这条规矩不立，任何项目管理工具都是黑匣子。

5.4 一直用管理员账号干日常活

现象：所有操作记录都是同一个人，出问题查不到是谁改的，统计报表也看不出分工。

原因：图省事，或者团队只给了一个通用账号。

解决：每个人用自己的账号。管理员账号只用来建账号、配权限。这不是洁癖，是给自己留后悔药——出了问题能追溯到具体的人和时间点，比事后回忆强一百倍。权限也别一把梭，按角色给，开发和测试能改的东西本来就不一样。

5.5 计划和发布混着用，路线图看不懂

现象：产品视图里计划建了一堆，发布建不出来，提示缺东西。

原因：计划和发布是两回事。计划是「打算什么时候做什么」，发布是「已经做完了什么、可以对外了」。发布还有硬前提：产品关联过项目，且该项目创建过版本。

解决：记住顺序——计划先行、项目执行、版本落地、发布收尾。发布建不出来时，先回头查这两个前提，而不是反复点按钮。另外计划过期之后不会在提需求的计划下拉里出现，别对着列表找半天。

6. 上手之后的下一步：把六个动作练成肌肉记忆

前面的内容读完，你大概知道禅道长什么样了。接下来我给一条具体的练习路径，不用等人教，自己就能走一遍。

第一步，用自己的账号登录，进「我的地盘」，创建一个待办，设个明天下午的截止时间。这一步只是让你熟悉表单。

第二步，找个有权限的产品，进去看一眼需求列表，点开任意一条需求，把它的状态和阶段记下来，然后对照第 3.3 节那张表，想想它为什么停在这一步。这个练习能让你快速读懂整个系统的「时间感」。

第三步，给自己提一条测试需求（标题写「测试用，勿动」），勾上不需要评审，看它从草稿变成激活的全过程，再试着把它关联进项目。做完这一步，你对需求流转就祛魅了。

第四步，找一个已有 bug，点进去看它的复现步骤和状态历史，观察它被激活过几次、每次激活补了什么信息。这是学习怎么写好 bug 最快的方式。

第五步，打开任务列表，找一个已指派给自己的任务，更新一次剩余工时，然后去看燃尽图有没有变化。亲手看到曲线的反应，比看十遍说明都管用。

第六步，翻一翻文档库。手册里写了文档库分三种：产品文档库、项目文档库、自定义文档库。前两种分别存产品层面和项目过程中产生的文档，自定义文档库可以放知识库、管理规范这类东西。文档有文件、链接、网页三种类型，网页型可以直接用富文本写。新团队最该做的一件事，就是把「需求评审纪要」「发布说明」这类东西固定往文档库里放，半年后你会感谢自己。

再说一个具体技巧：给自己建三个固定视图——「我提的未关闭 bug」「指派给我待验证的 bug」「我参与的需求」。每天早上扫一遍这三张清单，比任何提醒都可靠。禅道的视图本质是保存下来的筛选条件，建一次，长期受益。

最后说句实在话。我刚开始用这类工具的时候，最烦的就是「为什么这个按钮是灰的」「为什么这条需求不动」，觉得软件在跟我作对。后来才明白，那些限制几乎都不是 bug，而是在逼你把上游的事做对。从那以后我每次带新人，都强制他先把「建产品、提需求、建项目、关联需求、拆任务、提 bug」这六步亲手走一遍，走完再谈别的功能。这份手册的价值也在这里——它把整条链路都写下来了，你不用靠试错去猜。

希望帮到你，先从创建一个待办开始吧。

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