企业官网建设流程全解析

简介：《禅道使用手册（完整版）》面向使用禅道进行项目管理的产品经理、项目经理、开发与测试人员，也适合刚接触敏捷协作流程的团队作为上手参考。内容围绕项目、需求、任务与Bug的完整管理链路展开，从基本介绍、用户角色、登录与最简流程讲起，逐步覆盖个人待办与“我的任务/我的BUG”、产品维护、需求创建评审与变更、需求状态阶段、发布计划，以及项目团队组建、需求列表确定、任务分解和燃尽图查看等模块，帮助读者理解禅道各角色的日常操作与协作方式。资源包共1个docx文件，约4.02MB，目录层级清晰，便于按章节检索和打印查阅。已有5219人学习，适合需要系统掌握禅道项目管理与Bug跟踪流程的初中级用户对照实践。

1. 先弄明白一件事：禅道到底是个什么东西

团队里最常见的混乱，不是没人干活，而是没人说得清一件事现在到底走到哪一步了：需求在谁手上、任务做没做完、上周报的那个 bug 到底改了没有。禅道就是冲着这件事来的。它是一款基于 Web 的项目管理软件，把产品管理、项目管理、测试管理串在一条线上，核心就三样东西——需求、任务、bug。你不用先懂什么敏捷方法论，登进去照着流程点一遍，就能明白自己手上的活为什么排在这、做完之后该交给谁。

这份手册适合三类人：三五个人、刚开始想规范流程的小团队；被表格和聊天记录追着跑的协调人；还有刚入职、第一次听到「项目管理软件」这四个字就心里发怵的新同事。它不要求你先成为专家，只要求你愿意照着顺序点一遍。

2. 为什么值得花时间学：需求、任务、bug 这三条线怎么串起来

2.1 三个抽屉：需求、任务、bug 各归谁管

我刚接触这类工具时，最大的误解是把它当成一个高级版的待办清单。后来才明白，它其实是三个抽屉，每个抽屉装的东西完全不一样，混着放就会出问题。

需求回答的是「要做什么」。它是产品经理整理出来的功能点，比如「登录页支持手机号验证码」。需求是源头，没有被确认的需求，后面所有的活都名不正言不顺。

任务回答的是「谁在什么时间做哪一块」。项目经理把一条需求拆成若干任务，指派到人身上，每条任务有预计工时、有起止时间。任务是可以被完成的，完成之后要更新状态。

bug 回答的是「做出来的东西和说好的不一样」。测试人员发现功能没按需求实现，就提一个 bug，开发解决，测试验证，验证通过才能关闭。

这三者的区别，用一张表看得更清楚：

新手最常见的翻车方式，是把一个 bug 当成任务建，或者把一条需求拆成二十个任务然后没人跟。抽屉一旦混了，后面所有的报表都是错的。所以入门第一件事，不是学功能，而是先把这三样东西分清。

2.2 五种角色：为什么一个人也可以戴好几顶帽子

手册里列了五种角色：系统管理员、产品经理、项目经理、开发人员、测试人员。听起来像五个部门，其实很多时候就是五顶帽子，小团队里一个人戴两三顶非常正常。

系统管理员管的是人，加账号、分权限，一般不参与具体业务。产品经理管的是「做什么」，维护产品、写需求、评审需求、排发布计划。项目经理管的是「怎么按时做完」，建项目、组团队、把需求拉进项目、拆任务、盯进度。开发和测试就不用多解释了，一个负责做，一个负责挑毛病。

为什么入门要先把角色搞清楚？因为角色决定你登录之后该看哪一屏。产品经理天天待在产品视图里，开发天天待在我的地盘和项目视图里，测试天天待在测试视图里。如果你用开发的账号去找「创建产品」的按钮，翻半天也找不到，不是软件坏了，是那顶帽子不对。

我第一次带新人时犯过一个错：让所有人用管理员账号登录，图省事。结果所有人都能看到所有按钮，所有人都不知道流程该从哪一步走。后来改成一人一个账号、一个角色，反而没人问了。血泪经验就是这句：权限不是限制，是路标。

2.3 从最省力的用法开始：先只用它的一角

手册里有一节叫「最简使用」，写得特别实在，它列了四种用法：只用来做产品管理、只用来做项目任务管理、只用来做 bug 管理、以及个人拿它做事务跟踪。

这句话的分量，新手往往体会不到。很多人一上来就想把整套流程全铺开，需求要评审、任务要拆分、bug 要走完整生命周期、文档要归档，结果第二周就没人填了。因为大家还不会走，就先被要求跑。

入门的话建议先挑一个角落。比如你是一个测试，那就先用它管 bug：提单、指派、解决、验证，四步走顺了，你就理解了状态流转是怎么回事。你是一个产品，那就先把需求录进去，哪怕只有十几条，先把「草稿」和「激活」的区别摸熟。等你对这一角有感觉了，再往外扩。

这个思路和学做菜一样，没人第一天就同时学刀工、火候、摆盘。先炒好一个蛋，比看十本菜谱管用。

2.4 算三笔账：为什么值得花这两个小时

我见过太多团队说「我们用表格挺好的」。表格确实挺好，但它有三笔账是慢慢欠下的，等到发现的时候往往已经很贵了。

第一笔是沟通成本。同一个问题，产品在群里说一遍，项目经理私下问一遍，开发做完又跟测试解释一遍。规则如果不在一个地方写清楚，每多一个人就多一遍沟通。禅道把这些内容固定在同一张单子上，谁点开都看到同样的描述。

第二笔是追溯成本。三个月后客户问「这个功能当时为什么这么改」，如果记录散在聊天记录里，基本等于没有。禅道里的需求变更会留下变更前后的对比，还会列出影响范围——影响哪些任务、哪些 bug、哪些用例。这玩意儿就是后悔药。

第三笔是交接成本。有人离职、有人调岗，新接手的人打开「我的地盘」就能看到自己名下挂着哪些东西，不用挨个去问。这个价值在人员流动的时候最明显。

顺带说一句技术层面的。手册里提到，这套软件基于自己的框架开发，走 MVC 设计模式，还带插件扩展机制。对新手来说这些不用深究，只要知道一件事：它是可以定制的，不是那种你想加个字段都要求人的工具。这点在团队流程慢慢长出来之后会很重要。

花两个小时把基本流程走一遍，本质上是把这三笔账提前还掉一部分。

3. 第一次登录别慌：五分钟摸清「我的地盘」

3.1 登录之后先别点：三分钟认清界面地图

登录方式各团队不太一样，有的从公司内部办公系统里点链接跳进来，有的直接给一个地址。不管哪种，进去之后你会看到一堆菜单，第一反应大概率是「这都什么跟什么」。别急着点，先建立一张地图。

把整个界面想成四张桌子：

• 我的地盘，是你自己的办公桌，只放跟你有关的东西；
• 产品，是货架，摆的是「我们要做什么」；
• 项目，是工地，摆的是「这阵子在干什么」；
• 测试，是质检台，摆的是「做出来的东西有没有毛病」。

除此之外还有文档和后台，前者是资料柜，后者是管理员用的机房，新手前两周基本不用碰。

为什么建议新手第一站去「我的地盘」？因为它只显示指派给你的东西，信息量最小。你在产品视图里看到的是全部需求，几十上百条，容易一上来就被淹。而在我的地盘里，属于你的那几条，就是你这个月真正要关心的。

我建议的操作顺序是：登录 → 点开我的地盘 → 把四个列表都点一遍、看看是空的还是有内容 → 然后退出。第一次就做这一件事，五分钟够了。

提示：如果你登进去发现某个视图完全空白，先别怀疑是账号坏了。大概率是这个产品还没有人建、或者你还没被加进项目团队。这在下面第 5 章会细说。

3.2 待办：把私事和公事放进同一张清单

待办是禅道里最被低估的功能。很多人以为它只能管工作，其实它更像你桌上那张便签纸。

创建待办的路径是这样的：

1. 进入「我的地盘」；
2. 点左侧的「日程」；
3. 点「添加待办」；
4. 填写名称，设定起止时间（也可以先空着）；
5. 如果是私人事务，勾上「私人」；
6. 保存。

步骤不复杂，但有两个细节值得说。

第一个是起止时间。新手常常图快，什么时间都不填。短期看没影响，长期看你就失去了一条时间线——周五想回顾这周干了什么，翻出来一堆没有日期的条目，等于白记。入门的话建议先养成习惯：哪怕只填一个截止日期，也比空着强。

第二个是「私人」这个勾。它不是加密，而是把这条待办从公共视野里收起来，只你自己能看到。为什么要专门提它？因为很多人一开始不敢往里记「下午三点去医院」这种事，觉得项目管理工具记私事很奇怪，结果待办清单就不完整了，用两天就弃了。把公事私事放一张清单，恰恰是它能长期用下去的原因。

浏览待办的时候，页面提供了几个筛选标签：按日期、按类型、按名称检索。别小看这几个标签，条目超过二十条之后，靠眼睛扫是扫不过来的。

3.3 我的地盘：每天上班只做三个动作

如果说整个软件有一个「每日打卡点」，那就是我的地盘。手册里讲得很直白：每天的工作其实很简单，就是把指派给自己的任务、需求、bug 及时处理掉。

勘误一下我自己的理解——这里说的「处理掉」不是「做完」，而是「推进一格」。哪怕你今天只是把一条任务的状态从「未开始」改成「进行中」，也比什么都不动强，因为项目进度是靠这些格子拼出来的。

具体来说，我的地盘里有四个列表值得你每天扫一眼：

我的任务。这是分配到你头上的具体工作。看到任务的第一件事是确认两样：预计工时和截止时间。工时不代表要被考核，它是让项目经理估算进度用的。

我的 bug。指派给你修的缺陷。这里有个细节：bug 通常带有「严重程度」和「优先级」两个字段，前者是技术上的破坏力，后者是业务上要不要先修。两者不一定一致，一个错别字可能优先级很高，因为它出现在首页。

我的需求。指派给你跟进的需求。开发一般不太看这个，产品经理会常来。

我的测试。指派给你执行的测试任务。测试人员的主战场。

每天三个动作，我自己是这么做的：早上打开先扫一遍有没有新指派；中午更新一次自己正在做的东西的状态；下班前把当天该关闭的关掉。加起来一天不超过十分钟，但省下的是每天被人追着问「那个怎么样了」的时间。

3.4 我的档案：改密码这种小事别拖

我的地盘里还有一个页面叫「我的档案」，可以查看和修改个人信息，包括改密码。

这个功能没什么可讲的，但我还是想单独说一句，因为它是新手最容易拖的事。系统给的初始密码往往很难记，很多人就一直用着，等到某天忘了再来找管理员重置，一次性能耽误半小时。

另外，档案里的姓名、邮箱这些信息建议顺手核对一下。有些团队配了邮件通知，邮箱错了就收不到抄送，需求变更、bug 指派全都悄无声息，你会以为自己被团队遗忘了。其实不是玄学，是邮箱填错了。

4. 跑通第一个闭环：从一条需求走到一个已验证的 bug

这一章是整篇最该动手的部分。建议你找一个空环境，或者跟管理员要一个测试用的产品，自己把下面五步从头到尾走一遍。走完这一遍，禅道的八成你就懂了。

手册里给的基本流程是这样的：产品经理创建产品 → 创建需求 → 项目经理创建项目 → 确定项目要做的需求 → 分解任务指派到人 → 测试人员测试并提交 bug。听上去是六步，本质上是一个闭环。

4.1 产品经理：建产品、划模块

第一步是建产品。用产品经理角色登录，进入产品视图，点「添加产品」。如果系统里一个产品都没有，页面会自动跳到添加页，这点设计得挺贴心。

添加的时候有几个字段值得认真填：

产品代号，相当于大家对这个产品的内部昵称。比如一款项目管理软件，代号可能就是它名字的拼音。别嫌麻烦，后面很多地方用代号比用全名快。

产品负责人，负责整理和解释整个产品的需求、制定发布计划。这个字段填错，后面所有需求的默认归属都会错。

测试负责人，可以指定一个默认的接收人。手册里专门说了它的用途：公司人多的时候，提交 bug 不知道该给谁，就会默认落到这个人头上。小团队可以直接填自己。

访问控制，控制谁能看这个产品。可以设成私有，只有产品创建者、产品负责人、测试负责人、发布负责人和该产品的项目团队能访问。这条对做内部项目或者还没公开的新产品很重要。

建完产品，紧接着要划模块。模块相当于给需求分类，把「登录」「支付」「消息」这些分门别类放好，后面需求一多你才知道去哪找。维护模块是一级一级往下建的，左边那列数字是排序，调整它就能调整模块在树里的位置。入门的话，先建三到五个一级模块就够了，别一上来把目录做到四级深，那是给自己挖坑。

4.2 写一条开发看得懂的需求

产品视图右侧有「提需求」入口，点进去就是新增页面。

手册里强调了写需求的方式：按功能点写。简单讲，就是把原来需求文档里的每一个功能点摘出来，一条一条录进去，作为独立条目。不要建一条叫「用户模块」的需求，然后在描述里塞三千字。

一条合格的需求，至少要让开发看完不用来问你这四个问题：做什么、在哪做、做到什么算对、什么时候要。对应的字段大致是标题、描述、验收标准、优先级和计划。

关于评审，有个开关必须讲清楚：新增需求时有个「不需要评审」的复选框。勾上，需求建完直接是激活状态；不勾，需求就要先走评审。只有激活状态的需求才能关联到项目里开发。

我的建议是：新人练手阶段勾上「不需要评审」，先把流程跑通；正式项目里别图省事，该评审就评审。手册里有句话我很认同——即使产品完全由一个人负责，也可以把一些不成熟的想法先存成草稿，后续再处理。评审不是给别人设的门槛，是给自己留的缓冲区。

评审的时候会出现三种结果。选「确认通过」，需求状态变成激活，可以进项目了；选「有待明确」，需求保持草稿状态并退回给创建人继续完善；选「拒绝」，需要写清楚拒绝原因。评审人那栏是参与评审的人员名单，一般是线下开完会，把参加的人记进去。

另外有两个小字段容易被忽略：抄送和关键词。抄送让需求的变化通过邮件同步给相关的人；关键词则是以后检索时的钩子。这两栏填一下，未来的你会感谢现在的你。

4.3 项目经理：建项目、组团队、拉需求、拆任务

轮到项目经理了。手册里这部分目录比较完整，我按新手最容易上手的顺序串一遍。

建项目。在项目视图里找到添加项目的入口，填项目名称、起止时间、负责人。项目是一段时间内的容器，产品是长期存在的，这两者的区别要记住：产品可以有很多个项目，项目做完了就归档，产品还在。

组团队。建完项目要往里加人。加进来的人才能看到这个项目里的任务，不加进来的人在项目视图里就是一片空白——这也是新手最常怀疑「软件坏了」的原因之一。

确定项目要完成的需求列表。这一步是把产品的需求和项目挂上钩，从产品需求里挑出这一次要做的部分，关联到项目。为什么要有这一步？因为产品需求池可能有上百条，一个迭代只做其中十几条，不挑出来，开发就不知道边界在哪。

组织任务分解。把关联进来的需求拆成任务，指派到人，填预计工时。任务拆多细是门手艺，经验做法是拆到「一个人能在一天到三天内做完」的粒度。拆太粗跟没拆一样，拆太细光维护就累死。

看燃尽图。燃尽图是一条往下走的线，横轴是时间，纵轴是剩余工作量。理想情况下它平滑地降到零。如果它一直平着不动，通常不是图画错了，而是没人更新任务状态——这个坑第 5 章会专门讲。

除了燃尽图，项目视图里还有各种列表：按人看、按状态看、按时间看。新手先把「未完成的任务」这个列表用熟，就够了。报表统计那部分等跑完一个完整项目再看，不然一堆数字看不懂反而打击信心。

4.4 开发：领任务、每天更新、建版本、申请测试

开发要做的事，手册里列了六步：参加计划会议分解任务、领取任务并每天更新、创建版本、申请测试、解决 bug、文档管理。

对新手来说，前两步是日常，后两步是节点。

领取任务。在项目任务列表里找到指派给自己的任务，或者干脆在「我的地盘 → 我的任务」里看。领了之后把状态改成进行中。

每天更新。这是最容易被跳过、后果又最严重的一步。更新包含两件事：一是剩余工时，二是状态。今天做了一半，就把剩余工时改成一半；做完了就改成零并标记完成。不更新会怎样？燃尽图不动，项目经理不知道你到底做没做，最后只能挨个来问。这属于典型的「省一分钟，赔十分钟」。

创建版本。开发把一批任务做完，要打一个版本。版本可以理解成「这次交付的东西」，是后面测试和发布的依据。手册里专门提到，创建发布有两个前提：产品关联过项目，且该项目创建过版本。所以版本这步不能省，省了后面发布建不出来。

申请测试。版本建好之后提交给测试，告诉对方这一版包含哪些内容。这一步的价值在于划清边界：从这一刻起，问题算 bug，不算没做完。

4.5 测试：提 bug、开发解决、测试验证关闭

测试这条线是整个闭环里最完整的一段，手册里写得也最细。

先维护 bug 视图模块。这和产品模块是一个思路，给 bug 分类。别跳这步，否则一百个 bug 堆在一个列表里，找都找不到。

提交 bug。提 bug 有几个字段必须认真填：标题要说清在哪、做了什么、出现了什么；重现步骤要一步一行；严重程度和优先级按实际情况选；所属模块和版本别选错。一条好 bug 的标准是——开发照着步骤能做出来一次。做不到，就会被退回来说「无法重现」，一来一回又是半天。

开发解决。开发改完之后把 bug 状态改成已解决，并写清楚解决方案和解决版本。解决版本这个字段别乱填，测试要拿这个版本去验证。

验证并关闭。测试在对应版本上重跑一遍，好了就关闭。没好的话，点「激活」，bug 回到激活状态，重新指派给开发。这个动作叫激活 bug，不是新建一个 bug，两者的区别在于历史记录是否连续。

找到自己需要的 bug。bug 一多就要靠筛选，可以按模块、按版本、按指派给谁、按状态筛。这个技能看着不起眼，实际上决定了你每天要花多少时间在翻页上。

测试用例那部分是这样的：先维护测试用例视图，再创建用例，然后建测试任务把用例组织起来，执行用例的过程中发现问题就直接转成 bug。用例的好处是重复劳动不用重想，一个版本跑一遍，下一版还能跑。

4.6 需求的状态和阶段：为什么它一会儿「激活」一会儿「研发中」

很多人走到这一步会晕：明明是同一条需求，怎么状态变来变去。其实有两条线在同时走，一条叫状态，一条叫阶段。

状态只有四种：草稿、激活、已变更、已关闭。对应五个动作：创建、变更、审核、关闭、激活。草稿是还没定，激活是可以做了，变更中是有人在改它，关闭是结束了。

阶段描述的是激活的需求在研发流程里走到哪了：未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。

阶段的推进是自动的，规则大概是：没关联计划和项目，就是未开始；只关联了计划，是已计划；关联了项目但没拆任务，是已立项；有开发任务在进行、测试还没开始，是研发中；开发全做完、测试没开始，是研发完毕；有测试任务在进行，是测试中；开发和测试都结束，是测试完毕。验收这一步要产品经理手工确认，关闭时如果原因是「已发布」，阶段就变成已发布。

这套规则第一次看会觉得琐碎。但理解了它就理解了禅道为什么能算进度——进度不是谁拍脑袋填的百分比，是这些状态和阶段自己堆出来的。

顺便提一句需求变更。凡是改标题、描述、验收标准、附件，都应该走变更流程，不能直接编辑。走变更的时候系统会列出影响范围，告诉你这条需求牵动了哪些任务、bug、用例。变更提交后状态变成已变更，需要评审；评审通过变回激活，撤销变更就回退到之前的版本。

5. 新手常见问题排查：五个最容易翻车的地方

5.1 需求建好了，项目里就是关联不上

现象：产品视图里明明有那条需求，项目经理在项目里搜不到、选不着。

原因：需求状态不是激活。草稿状态的需求不能关联到项目开发，这是设计上的硬约束——没定下来的东西不该进排期。

解决：回到需求详情，看状态字段。如果是草稿，先走评审把它变成激活；如果创建时勾了「不需要评审」却还是草稿，检查是不是中途被谁退回成有待明确了。另外提醒一句，已过期的计划在关联需求时不会列出来，这也是「明明有却选不到」的常见原因。

5.2 任务明明做完了，燃尽图却纹丝不动

现象：燃尽图是一条平的横线，可团队天天加班。

原因：任务状态没更新，或者只改了状态没改剩余工时。燃尽图算的是剩余工作量，你不填，它就当还没做。

解决：把更新状态当成提交代码一样的规定动作。每天下班前花两分钟，把当天动过的任务改一遍：做完了标完成、剩余工时归零；做了一半就改剩余工时。项目经理在站会上盯着这张图问一句「谁的没更新」，比事后翻工单有效得多。

5.3 bug 解决了，测试又激活，来回拉锯

现象：一个 bug 在开发手里显示已解决，测试验证后打回去，再解决再打回，来回三四次。

原因：多半是解决时没写清楚改了什么、在哪个版本改的。测试拿着旧版本或者不清楚改动点，只能凭感觉验证，验不过就打回。

解决：解决 bug 时把「解决方案」和「解决版本」两个字段写实。解决方案写一句话：改了哪个文件、哪个逻辑、哪种情况不再出现。解决版本选对，测试才知道去哪个版本上验。这两栏空着，来回拉锯就不可避免。

5.4 一个人身兼数职，流程卡在评审那一步

现象：小团队里一个人既是产品又是项目经理，自己建的需求自己评不了，或者干脆没人可指派。

原因：系统默认不允许同一个账号在同一环节既当提交人又当审批人，评审人列表也可能是空的。

解决：小团队不必硬套大流程。练手阶段可以直接勾「不需要评审」，让需求建完即激活；正式跑的时候，找一个同事挂名参与评审，把线下讨论的结论记进去就行。关键是记录留痕，不是走形式。

5.5 文档传了一堆，用的时候一个都找不到

现象：文档视图里附件堆成山，找一份接口说明翻了十分钟。

原因：没有维护分类，所有文件都堆在默认目录下；或者上传时直接传附件，没有建对应的文档条目。

解决：先建分类再传文件。手册里文档库分三种：产品文档库存产品层面的东西，项目文档库存项目过程中的东西，自定义文档库存知识库和规范。三类分开之后，找起来就有路径了。文档本身支持三种类型——文件、链接、网页，规范类的直接写网页型，别什么都传附件。

6. 下一步学什么：从自己会用到带着团队跑起来

走完上面那一遍，你已经能独立完成一次「提需求→拆任务→做开发→报 bug→验证关闭」的闭环了。接下来怎么走，取决于你打算用它做什么。

我给三条路线，你可以照着挑一条先走两个月。

个人效率线最快，两三天就够。角色深耕线慢一些，重点在需求的变更流程和阶段流转——这两块能玩明白，你在团队里就是那个能解释「为什么这条需求显示研发中」的人。团队推动线最难，难的不是功能，是让人愿意填。我的建议是别一上来就要求全员用，先找两三个愿意配合的同事跑一个迭代，把流程跑顺了再扩。

最后给一个具体技巧：把「发布计划」和「路线图」当成你的复盘点。计划和发布组成了产品的路线图，绿色的是已经发过的版本，另一种颜色的是将来的计划。每次迭代结束花十分钟看一眼这张图，你会很直观地看到自己这两个月到底交付了什么。这比任何报表都提神。

我第一次带团队用的时候，图省事跳过了「建版本」这一步，直接让测试验。结果 bug 上写的版本号全是空的，出了问题根本查不到是哪一版引入的，排查的时候跟开盲盒一样。从那以后我每次交付前都强制走一遍「建版本→申请测试」，哪怕只改了两个字。工具的价值不在于功能多，而在于它逼你把该留的痕迹留下。

这份手册按模块整理得很规整，从基本介绍一直排到测试使用的报表统计，章节顺序本身就是一条学习路径。你可以把它当成一本可以边看边点的操作说明书：先照着第 3 章登进去，再回来翻第 4 章跑一遍闭环。希望帮到你。

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