禅道入门指南：从零开始掌握项目管理与敏捷开发

简介：这份《禅道使用手册（完整版）》面向项目经理、产品经理、开发与测试人员，以及初次接触禅道、需要系统掌握项目管理工具操作流程的团队，帮助解决项目进度跟踪、任务分配、需求与缺陷协同管理中的实际问题。资源包共1个docx文件，约4.02MB，内容按角色组织，涵盖基本介绍、个人管理、产品经理使用、项目经理使用等章节，从软件介绍、用户角色、登录与最简流程，到待办创建与浏览、我的任务与我的BUG、需求创建评审与变更、产品模块维护、发布计划与燃尽图等均有展开，目录层级清晰，便于按角色检索。已有5218人学习下载，适合作为团队内部培训或日常查阅的参考文档，帮助读者快速理解禅道各角色的职责边界与操作要点，减少上手摸索成本。

1. 第一次打开禅道，先弄明白它到底在管什么

很多新手第一次听到“禅道”这个名字，脑子里冒出来的是一堆问号：它是个网站？是个软件？还是某种管理理论？其实你可以把它想象成一块团队共用的白板——产品经理把想法贴上去，项目经理把想法拆成一件件小事，开发认领后动手做，测试做完再回头检查有没有漏。区别在于，这块白板是电子的，谁改了什么、什么时候改的、改完有没有人验收，全都留痕，不会像口头交代那样说完就忘。

禅道就是这样一个基于 Web 的项目管理工具，把产品管理、项目管理、测试管理、文档管理揉在一个系统里。它背后遵循的是 Scrum 那套敏捷开发思路，但你不必先把 Scrum 啃透才能用——手册里专门写了“最简使用”，哪怕你只想拿它记待办、管 bug，也能跑起来。这篇入门就是带零基础的人从“这是啥”走到“第一个待办怎么建、第一个 bug 怎么提”，不堆术语，只讲够用的部分。

2. 为什么值得花半小时学它：先看清角色和流程

2.1 一个系统里住着五种人，各干各的活

禅道把使用者分成几类角色，你登录后看到什么菜单、能点什么按钮，基本由角色决定。系统管理员负责加人、分权限，相当于开门的人；产品经理管产品、写需求，决定“做什么”；项目经理建项目、拆任务、盯进度，决定“谁来做、什么时候做完”；开发人员领任务、写代码、创建版本；测试人员提 bug、验 bug、管测试用例。新手最容易犯的迷糊是拿管理员账号到处点，结果发现很多按钮是灰的——不是系统坏了，是当前角色没这个权限。

入门阶段你不需要把五种角色全体验一遍。建议先想清楚自己在团队里站哪个位置，然后只盯自己那一摊。比如你是开发，就重点看“我的任务”和“我的 BUG”；你是产品，就先摸清“提需求”和“建计划”。手册按角色分章，正是这个道理。

2.2 核心流程就六步，背下来不亏

手册里把基本流程压缩成六步：产品经理创建产品 → 创建需求 → 项目经理创建项目 → 确定项目要做哪些需求 → 分解任务并指派到人 → 测试人员测试并提交 bug。这六步是一条主线，后面所有功能都是挂在这条线上的枝叶。

我第一次接触时觉得“创建产品”这一步很虚——不就是起个名字吗？后来才明白，产品是需求的容器，没有产品，需求没地方挂；需求又是项目的输入，项目不关联需求，任务就失去了来源。所以哪怕你只想试试水，也建议按这个顺序走一遍，别跳步。跳步的后果是后面建项目时发现“可选需求”列表是空的，又得回头补。

2.3 最简使用：只用一个功能也算入门

手册特意列了四种“最简使用”场景：只做产品管理、只做项目任务管理、只做 bug 管理、只做个人事务跟踪。这个设计对新手很友好——你不需要一上来就把整套流程跑通。如果你只是想找个地方记每天要做的事，直接进“我的地盘 → 日程 → 添加待办”就行，起止时间可以不填，私人事务勾一下，别人看不到。

我建议零基础的人第一周就这么干：先拿待办功能练手，熟悉界面和操作节奏，等不怵了再去碰需求、项目这些重一点的概念。工具是拿来用的，不是拿来供着的，先用起来比先学全更重要。

3. 第一步怎么迈：从登录到建出第一条待办

3.1 登录入口和第一眼界面

手册里写的登录路径是：先登 OA 系统，在协同工作里找“关联系统”，再点禅道。不同公司的入口可能不一样，有的直接给禅道地址，有的嵌在门户里。你拿到入口后，用管理员分配的用户名和密码登录即可。第一次进去别急着点，先看左上角或顶部导航——通常会有“我的地盘”“产品”“项目”“测试”“文档”几个大区，这就是禅道的地图。

提示：如果登录后页面报错或一直转圈，先确认账号是否被分配了对应产品的访问权限。禅道的访问控制可以按产品设私有，没权限的人点进去就是空白。

3.2 建第一条待办：四步落地的操作

待办是最轻量的功能，适合作为第一个动手练习。路径是“我的地盘 → 日程 → 添加待办”。下面用文字把每一步拆开，你照着点就行：

1. 登录后点顶部“我的地盘”。
2. 左侧或页内找到“日程”，点进去。
3. 点“添加待办”按钮。
4. 填标题（必填），起止时间可填可不填，私人事务按需勾选，保存。

保存后回到日程列表，你能看到刚建的待办。列表上方有日期、类型、名称等筛选标签，待办多了以后靠它们检索。这一步的意义不在于待办本身多有用，而在于让你熟悉“进入模块 → 点添加 → 填表单 → 保存 → 回列表查看”这个禅道里反复出现的操作循环。后面建需求、建项目、提 bug，全是同一个节奏。

3.3 把“我的地盘”当成每天的第一个页面

手册里有一句话很实在：每天的工作其实很简单，就是把“我的地盘”里指派给自己的任务、需求、bug 及时处理掉。我的地盘下有“我的任务”“我的 BUG”“我的需求”“我的测试”几个快捷入口，凡是指派到你头上的事项都会出现在这里。

新手容易忽略的是“我的档案”页面，那里可以改个人信息和密码。别等到密码忘了才去找入口。建议登录后第一件事就是把档案页翻一遍，看看哪些字段能改、哪些是管理员锁定的，心里有个数。

4. 产品经理那条线：需求怎么从想法变成可开发的东西

4.1 先建产品，再谈需求

产品经理角色的起点是“产品视图 → 添加产品”。填产品名时有个字段叫“产品代号”，手册把它解释为“大家对这个产品的一个隐喻”，比如某个项目管理软件的代号是 zentao。代号不是必填的硬性要求，但团队里有个短代号，沟通时省事。

添加产品时还有几个关键字段：产品负责人负责整理和解释需求、制定发布计划；测试负责人可以设默认值，避免人多了提交 bug 不知道给谁；发布负责人主要管创建发布；访问控制可以设私有，只有产品添加者、负责人、测试负责人、发布负责人和项目团队能进。新手常犯的错是把访问控制设成私有后又抱怨同事看不到——先想清楚这个产品要给谁看，再决定开不开放。

4.2 需求按功能点写，一条一条录

手册强调“按照功能点的方式来写需求”，意思是别把一整份需求文档塞进一个条目，而是把每个功能点摘出来单独录。这样做的好处是后面关联项目、拆任务、提 bug 时都能精确挂到某一条需求上。

创建需求的路径是产品视图右侧“提需求”。标题必填，所属计划和模块可以先空着。表单里有个“不需要评审”复选框：勾上，新需求直接是激活状态，能立刻关联到项目；不勾，需求进评审流程。大部分团队是需要评审的，哪怕产品只有一个人负责，也可以先把不成熟的想法存成草稿，回头再处理。

评审结果有三种走向：确认通过，需求变激活；有待明确，打回创建者继续完善，保持草稿状态；拒绝，需要填拒绝原因。评审人名单可以输入用户名筛选，线下开完评审会再回系统里记录参与人，这个顺序比较顺。

4.3 需求变更要走变更流程，别直接编辑

这是新手最容易翻车的地方之一。手册明确写了：编辑操作无法修改需求的标题、描述、验收标准和附件。要改这些，必须走“变更”流程。变更后需求状态变成“变更中”，系统会列出该需求的影响范围，评审通过后才回到激活。

变更评审的结果有四种：确认通过、撤销变更、有待明确、拒绝。撤销变更会回退到之前的版本，相当于给了你一颗后悔药。变更被确认后，研发和测试还要分别确认需求变动——任务、bug、用例三个地方都要过一遍。听起来繁琐，但正是这套留痕机制，让“谁在什么时候把需求改成了什么样”有据可查。

4.4 状态和阶段是两个字段，别混着看

需求有状态和阶段两个字段。状态四种：草稿、激活、已变更、已关闭，对应创建、变更、审核、关闭、激活几个操作。阶段描述的是激活后的需求走到哪一步了：未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。

判断逻辑大致是：没关联计划和项目就是未开始；只关联计划是已计划；关联项目但没拆任务是已立项；有开发任务进行中且测试没开始是研发中；开发任务全完且测试没开始是研发完毕；有测试任务进行中是测试中；测试全完但开发没完也算测试中；两边都完是测试完毕；验收要产品经理手工确认；关闭原因是已发布则阶段为已发布。这张对照表建议打印出来贴显示器边上，比反复翻手册快。

5. 项目经理和开发测试那条线：任务、版本、bug 怎么串起来

5.1 建项目、组团队、挂需求、拆任务

项目经理的活从“建立项目”开始，然后组建团队、确定项目要完成的需求列表、组织任务分解。需求列表是从产品那边关联过来的，所以前面产品经理没建需求，这里就会卡住。任务分解时指派到人，开发登录后就能在“我的任务”里看到。

进度怎么看？手册给了两个抓手：燃尽图和各类列表。燃尽图直观展示剩余工作量随时间的变化，列表则能按人、按状态筛。新手项目经理容易只看燃尽图不看列表，结果图很漂亮但某个人的任务堆成山——图是趋势，列表是明细，两个一起看才靠谱。

5.2 开发：领任务、更新、创建版本、申请测试

开发人员的日常循环是：参加计划会议分解任务 → 领取任务并每天更新 → 创建版本 → 申请测试 → 解决 bug → 确认 bug。每天更新任务这一步别偷懒，进度不是给领导看的，是让团队知道你这块卡没卡。

创建版本是开发和测试之间的交接点。版本建好才能申请测试，测试才有东西可测。bug 解决后开发要确认，测试再验证关闭。手册里还提到文档管理，开发过程中产生的文档可以归到项目文档库，别散落在聊天记录里。

5.3 测试：提 bug、验 bug、管用例

测试人员的入口是 bug 视图和测试用例视图。提交 bug 时把复现步骤、期望结果、实际结果写清楚，这是给开发省时间，也是给自己省返工。验证通过就关闭，不通过就激活退回。测试用例可以按模块维护，执行用例时发现问题直接转成 bug。

bug 也有状态流转：提交后是激活，开发解决后变已解决，测试验证通过关闭，验证不通过重新激活。这套流转和需求的状态机是同一个设计思路——每一步都有记录，谁也别想赖账。

6. 新手避坑清单：这五个坑我替你踩过了

6.1 坑一：拿管理员账号当日常账号用

现象：菜单一大堆，点哪个都怕点错，或者误改了别人的权限。原因：管理员权限太大，不适合日常操作。解决：让管理员给你建一个对应角色的普通账号，日常用普通账号，管理员账号只在配权限时用。

6.2 坑二：需求直接编辑而不是走变更

现象：改完需求发现历史记录没了，或者开发说“我不知道你改了验收标准”。原因：编辑绕过了变更流程，影响范围没通知到。解决：凡是改标题、描述、验收标准、附件，一律走“变更”，让系统把影响范围列出来。

6.3 坑三：建了项目才发现没关联需求

现象：项目里任务建不了，或者建了任务不知道对应哪条需求。原因：跳过了“确定项目要完成的需求列表”这一步。解决：建项目后先挂需求，再拆任务；产品那边需求没评审通过之前，别急着往项目里塞。

6.4 坑四：待办不设起止时间，最后全堆在一起

现象：日程列表里几十条待办，分不清哪条今天必须做。原因：创建时图省事没填时间。解决：至少给有截止压力的事项填上起止时间，私人事务可以放宽，工作事项别偷这个懒。

6.5 坑五：bug 描述只写“有问题”

现象：开发来回问“哪里有问题、怎么复现”，一个 bug 来回好几轮。原因：提交时没写复现步骤和期望结果。解决：提 bug 时按“操作步骤 → 期望结果 → 实际结果”三段写，能截图就截图，一次写清楚比来回问五遍省时间。

7. 下一步学什么：按角色选一条线往下走

入门之后别贪多，按你的角色挑一条线继续。产品方向就深挖需求评审和发布计划，把“计划 → 需求 → 发布”这条链走顺；项目方向重点练任务分解和燃尽图解读，学会从列表里看出谁快谁慢；开发方向把“领任务 → 建版本 → 解 bug”循环跑熟；测试方向先把用例管理和 bug 生命周期吃透。下面这张表可以帮你对号入座：

如果你暂时没有明确角色，就用“最简使用”里的个人事务跟踪练手：每天建两三条待办，周末回看哪些完成了、哪些拖了，顺便熟悉筛选标签。等团队真用起来，你已经不怵界面了。

我第一次带新人用这类工具时，犯过一个很蠢的错：上来就让人把整套流程跑一遍，结果对方卡在“需求评审”那步就放弃了。后来我改成先让对方建三条待办、提一个假 bug 玩一玩，等操作手感有了再讲流程，接受度高得多。从那以后我每次带新人，都强制先走一遍“待办 → bug → 任务”这条最小闭环，再谈角色和流程。希望这份手册也能帮你迈出第一步，别怕点错，禅道里大部分操作都有记录，真改坏了也有迹可循。

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