禅道项目管理实战：角色流程与避坑指南

简介：这份《禅道使用手册（完整版）》面向项目经理、产品经理、开发与测试人员，以及初次接触禅道、需要系统掌握项目管理工具操作流程的团队，帮助解决项目进度跟踪、任务分配、需求与缺陷协同管理中的实际问题。资源包共1个docx文件，约4.02MB，内容按角色组织，涵盖基本介绍、个人管理、产品经理使用、项目经理使用等章节，并延伸至需求状态与阶段、产品模块维护、发布计划与发布、燃尽图进展跟踪及需求统计报表等模块，目录层级清晰，便于按角色检索。已有5218人学习下载，说明其在项目管理入门与团队落地场景中具有较高参考价值。读者可借助这份手册快速理解禅道的最简使用与基本流程，掌握待办管理、我的任务与我的BUG关注、需求创建评审与变更、项目团队组建和任务分解等操作要点，适合作为团队内部培训或日常查阅的配套文档。

1. 拿到一份禅道手册，先别急着从头翻

很多团队装完禅道，第一件事是拉个会，把手册从头念一遍。念完散会，第二天该乱还是乱：需求挂在草稿里没人管，任务分解到一半停了，测试提的 bug 开发说没收到。问题不在工具，在于没人把「角色—动作—状态流转」这条线串起来。这份《禅道使用手册（完整版）》的价值，恰恰是把产品经理、项目经理、开发、测试四类角色在禅道里的动作拆成了可照做的步骤，从建产品、提需求、立项分解任务，到提 bug、验证关闭，一条链走完。它适合正在落地项目管理流程的中小研发团队，也适合刚接手禅道配置、需要快速摸清「谁在哪个页面干什么」的从业者。下面我按手册的骨架，把能直接抄的部分和容易翻车的地方拆开讲。

2. 角色与主流程：先把四类人的动作对齐

2.1 五个角色各自管什么

手册把系统里的角色分成系统管理员、产品人员、项目经理、开发、测试五类，这个划分不是摆设，它直接决定了每个人登录后该看哪个视图。系统管理员管账号和权限，产品人员管产品、需求、计划、发布，项目经理管项目、团队、任务分解，开发和测试围绕任务与 bug 转。实际落地时最常见的错配，是让产品经理去建项目、让项目经理去提需求，结果需求状态和项目阶段对不上，燃尽图画出来是平的。

我一般建议在开账号之前先画一张角色对照表，把「谁负责创建、谁负责评审、谁负责执行」写死，再往禅道里灌人。手册里 1.2 节列的角色职责可以直接拿来当这张表的底稿。

2.2 六步主流程与状态联动

手册 1.4 节给的基本流程是：产品经理创建产品 → 创建需求 → 项目经理创建项目 → 确定项目要做的需求 → 分解任务指派到人 → 测试提交 bug。这六步看着简单，真正的约束在状态上：只有「激活」状态的需求才能关联到项目里开发，草稿状态的需求在项目关联需求的下拉里根本不会出现。所以流程能不能跑通，取决于需求评审那一步有没有做。

下面这段是我常用的检查脚本思路，用禅道开放 API 拉一遍需求状态分布，确认没有大量需求卡在草稿：

# 拉取某产品下的需求列表，按状态统计（需替换 host、账号、产品ID） curl -s -c /tmp/zt.cookie -d "account=admin&password=你的密码" \ "http://你的禅道地址/index.php?m=user&f=login" > /dev/null curl -s -b /tmp/zt.cookie \ "http://你的禅道地址/index.php?m=product&f=browse&productID=1&branch=0&browseType=all&param=0&orderBy=id_desc&recTotal=0&recPerPage=200&pageID=1" \ | grep -o 'status-[a-z]*' | sort | uniq -c

这段命令先登录拿 cookie，再请求产品需求列表页，最后用 grep 抓状态样式类名做计数。参数里productID换成你的产品 ID，recPerPage调大一点避免分页漏数。它不精确，但能快速看出「草稿」占比是不是异常高——如果一半需求是草稿，说明评审环节被跳过了，后面项目关联需求时必然缺料。

2.3 最简使用的四种裁剪

手册 1.3 节提到四种最简用法：只做产品管理、只做项目任务管理、只做 bug 管理、只做个人事务跟踪。这一点很实用，很多团队一上来就全模块铺开，结果没人维护，数据烂掉。我的经验是先选一种跑两周，比如先只把 bug 流程跑顺：测试提 bug、开发解决、测试验证关闭，三个动作闭环了，再往上加需求和项目。手册里 6.2 到 6.4 节正好是这条最小闭环的操作说明，拿来当第一阶段的落地范围刚好。

3. 产品侧落地：需求、模块、计划、发布怎么串

3.1 建产品时那几个字段别乱填

手册 3.1 节讲添加产品，重点在几个字段的语义：产品代号是团队对产品的隐喻，产品负责人负责整理和解释需求、制定发布计划，测试负责人用于人多时默认指派 bug，发布负责人负责创建发布，访问控制可以把产品设为私有。这里最容易踩的是「访问控制」——设成私有后，只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品关联的项目团队能访问，其他人打开就是空白。有团队建完产品发现开发看不到需求，排查半天以为是权限 bug，其实是私有产品没把开发加进项目团队。

3.2 需求按功能点拆，评审决定能不能进项目

手册明确要求「按照功能点的方式来写需求」，把需求文档里的每个功能点摘出来单独录入。创建需求时标题必填，所属计划和模块可以先空着，关键是「不需要评审」这个复选框：勾上，需求直接是激活状态；不勾，走评审流程，评审通过才变激活。手册 3.2 节的评审结果有确认通过、有待明确、拒绝三种，对应状态分别是激活、打回创建者继续完善、关闭并记录原因。

变更需求走的是另一条路。手册 3.3 节强调，标题、描述、验证标准、附件的修改都必须走变更流程，普通「编辑」操作改不了这几项。变更后状态变「变更中」，评审通过才回到激活。变更页面会列出影响范围，评审者据此判断。这里有个细节值得记：变更时如果勾了「不需要评审」，状态直接回激活，省一道流程，但也就失去了变更留痕的评审记录，团队规范严的话别开这个口子。

3.3 需求状态与阶段是两个字段

手册 3.4 节把这件事讲得比较透，值得单独拎出来。状态字段只有四种：草稿、激活、已变更、已关闭，对应创建、变更、审核、关闭、激活几个操作。阶段字段描述激活需求在研发中的位置，共九种：未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。阶段的推进是自动的，规则大致如下：

这张表是排查「需求阶段不动」的第一手依据。阶段卡在「已立项」不动，八成是任务没分解；卡在「研发完毕」不动，去看测试任务有没有建。

3.4 模块、计划、发布三件套

模块是对需求的分类，手册 3.5 节说维护模块要一级级来，左侧数字是排序字段，编辑时可以改上级模块。计划是产品经理规划发布节奏的工具，创建计划后可以关联需求，也可以在提需求时直接指定计划（过期计划不会列出）。发布有两个前提：产品关联过项目、项目创建过版本，缺一个都建不了发布。手册 3.6 节还点明计划和项目没有强对应关系，一个计划可能对应一个项目，也可能项目关联的需求来自多个计划——这点在跨版本迭代的团队里很常见，别硬凑一对一。

路线图由计划和发布组成，绿色是已发布版本，黄绿色是未来计划，点进去能看具体需求。需求统计报表在产品视图的需求子栏目下，支持按产品、按模块、按计划三种口径统计数量。这三样加起来，基本能回答「这个版本要做什么、做到哪了、发了多少」三个问题。

4. 项目与执行侧：任务分解、燃尽图与 bug 闭环

4.1 建项目、组团队、定需求列表

项目经理的动作从建项目开始，然后组建团队，再确定项目要完成的需求列表。手册 4.3 节这一步的前提是需求已经激活，否则关联不上。团队组建决定了谁能被指派任务、谁能看到私有产品，所以顺序不能反：先建项目、加团队，再关联需求、分解任务。

4.2 任务分解到人，燃尽图才有意义

手册 4.4 节的任务分解是整个流程里最容易被敷衍的一步。任务不分解，需求阶段停在「已立项」，燃尽图画出来是一条平线，项目经理拿着图开会只能干瞪眼。分解的粒度我一般按「一个人两天内能完成」来切，每个任务有预计工时、指派到人、有起止时间。手册 4.5 节用燃尽图看进展，4.6 节用各种列表看进展，4.7 节是项目任务的报表统计——这三样是项目经理的日常看板，但前提都是任务数据是真实的。

下面这段是批量检查「有需求但无任务」的排查思路，用页面抓取做粗筛：

import re, requests s = requests.Session() # 登录，替换为你的地址与账号 s.post("http://你的禅道地址/index.php?m=user&f=login", data={"account": "admin", "password": "你的密码"}) # 拉项目需求列表 html = s.get("http://你的禅道地址/index.php?m=project&f=story&projectID=1").text # 抓需求链接与任务数标记，具体 class 以你版本页面为准 stories = re.findall(r'storyID=(\d+)[^>]*>.*?</a>', html, re.S) print("需求条数:", len(stories)) # 逐条打开详情，检查任务页签是否为空 for sid in stories[:20]: detail = s.get(f"http://你的禅道地址/index.php?m=story&f=view&storyID={sid}").text if "暂无任务" in detail or "no task" in detail.lower(): print("无任务需求:", sid)

逻辑是先登录维持会话，再抓项目需求列表，逐条打开详情页找「暂无任务」标记。projectID换成你的项目 ID，stories[:20]是抽样上限，避免请求过多。这段脚本依赖页面文案，禅道版本不同文案可能变，跑之前先手动打开一个需求详情确认关键字。它的用途不是替代人工，而是在迭代中期快速定位「需求挂着但没人干活」的漏网之鱼。

4.3 开发的动作：领任务、建版本、申请测试、解 bug

开发侧手册 5.1 到 5.7 节的动作链是：参加计划会议分解任务 → 领取任务并每天更新 → 创建版本 → 申请测试 → 解决 bug → 文档管理 → 确认 bug。其中「每天更新任务」是燃尽图数据质量的命门，任务剩余工时不变，图就不动。创建版本是发布的前提之一，申请测试是把版本交给测试的信号，解决 bug 时填的解决方案会决定测试验证时的操作路径。

4.4 测试的动作：提 bug、验证、激活、管用例

测试侧手册 6.1 到 6.10 节覆盖维护 bug 视图模块、提交 bug、验证关闭、激活 bug、查找 bug、维护用例视图、创建用例、管理测试任务、执行用例并提交 bug、查看报表。这里的关键闭环是：提交 → 开发解决 → 验证通过关闭，或验证不通过激活。激活 bug 时一定要写清楚复现步骤和实际结果，否则开发二次解决还是猜。用例和 bug 的关联也别省，执行用例失败直接转 bug，回溯时能对上号。

5. 避坑排查：五个真实翻车点

5.1 需求在项目里关联不到

现象：项目经理在项目里关联需求，下拉列表是空的或者少了一大半。原因：需求还是草稿状态，没走评审；或者需求关联的计划已过期。解决：先在产品视图确认需求状态是「激活」，再检查计划是否过期，过期计划不会在提需求时列出，但已关联的需求不受影响。

5.2 开发看不到私有产品

现象：产品设了私有访问控制，开发登录后产品列表空白。原因：私有产品的可见范围是产品添加者、产品负责人、测试负责人、发布负责人加项目团队，开发不在项目团队里就看不到。解决：把开发加进对应项目团队，或者评估后把产品访问控制改为公开。

5.3 燃尽图一条平线

现象：项目跑了一周，燃尽图几乎不动。原因：任务没分解，或者分解了但没人更新剩余工时。解决：先补任务分解，再在每日站会后要求每人更新任务剩余工时，项目经理每周抽查一次任务更新率。

5.4 改了需求描述却没留变更记录

现象：需求描述被直接改掉，评审记录里找不到变更痕迹。原因：用了普通「编辑」而不是「变更」流程，编辑操作本来就改不了标题、描述、验证标准和附件。解决：培训时明确这几项必须走变更，变更时按需选择是否评审，团队规范严的不要勾「不需要评审」。

5.5 建不了发布

现象：点创建发布提示条件不满足。原因：发布要求产品关联过项目、且该项目创建过版本，两个前提缺一不可。解决：先确认项目里已创建版本，再回产品视图建发布；如果项目还没建版本，让开发走一遍创建版本流程。

6. 把手册用成检查清单：我的日常核对习惯

手册读一遍容易，用起来难。我的做法是把手册里的关键节点抽成一张每周核对清单，而不是每次翻文档找章节。具体是四列：角色、动作、对应手册章节、本周是否完成。产品经理那列盯「需求是否全部激活、计划是否关联需求」，项目经理那列盯「任务分解率、燃尽图是否更新」，开发那列盯「任务剩余工时是否每日更新、版本是否创建」，测试那列盯「bug 是否在 48 小时内验证」。

核对时我会用前面那两段脚本做粗筛，再人工看几个样本。脚本只负责把异常条目捞出来，判断还得靠人。比如「无任务需求」捞出来十条，可能八条是刚提的还没到分解环节，只有两条是真漏了，这个区分脚本做不了。

还有一个习惯是版本升级或换环境后，先跑一遍最小闭环：建一个测试产品、提一条需求、建一个项目、关联需求、分解一个任务、提一个 bug、解决、验证关闭。整条链走通再让团队进来用。这套动作对应手册 1.4 节的主流程，十分钟能跑完，但能提前暴露权限、状态、字段配置的问题，比等团队用出问题再排查省事得多。

从那以后我每次接手一个新禅道环境，都强制先走一遍这条最小闭环再开账号，翻车的次数明显少了。希望帮到你。

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