简介这份《禅道使用手册完整版》面向项目经理、产品经理、开发与测试人员以及正在引入项目管理工具的中小团队用于解决项目进度跟踪、任务分配与团队协作中的流程不清晰问题。资源包内共1个docx文档压缩包约4.02MB内容以章节化目录组织便于按角色检索查阅。手册从基本介绍入手涵盖软件定位、用户角色权限、最简使用流程与登录方式随后展开个人管理包括待办的创建与浏览、我的任务与我的BUG的关注处理、个人档案维护再分别针对产品经理与项目经理讲解产品维护、需求创建与评审、需求状态与阶段、产品模块与发布计划以及项目建立、团队组建、需求列表确定、任务分解和燃尽图查看等模块。目前已有5210人学习下载适合希望系统掌握禅道操作、快速搭建团队协作规范并对照实际项目落地执行的读者参考。1. 从一份 docx 手册说起禅道到底该怎么落地很多团队装完禅道第一周热情高涨第二周开始有人绕过系统直接在群里喊“这个 bug 谁改一下”第三周禅道就变成了一个只用来打卡的摆设。问题往往不在工具本身而在于没人把「产品—项目—任务—bug」这条链路真正跑通。我手里这份《禅道使用手册完整版.docx》就是干这个的它把禅道从登录、个人待办到产品经理维护需求、项目经理拆任务、开发领任务建版本、测试提 bug 验证关闭的完整流程按角色拆成了一页页可对照的操作说明。它适合三类人刚接手禅道配置的管理员、被要求“把流程搬到线上”的产品或项目经理、以及每天要在「我的地盘」里清任务和 bug 的开发测试。下面我不复述目录而是按“这份手册能帮你解决什么、怎么照着做、哪里容易翻车”来讲。2. 角色与流程先对齐禅道 Scrum 模型的四个关键对象2.1 五个角色对应的权限边界禅道把权限绑在角色上手册 1.2 节列了系统管理员、产品人员、项目经理、开发人员、测试人员五类。这里最容易踩的坑是很多人以为“角色”只是个头衔实际上它决定了你登录后左侧菜单能看到哪些入口。系统管理员负责添加用户、分配权限他不管具体业务产品人员管产品、需求、计划、发布项目经理管项目、团队、任务分解开发和测试则围绕任务与 bug 转。手册里 1.3 节给了四种“最简使用”路径——只做产品管理、只做项目任务、只做 bug 管理、只做个人事务跟踪。我的建议是小团队别一上来就全流程铺开先选一条最痛的链路通常是 bug 管理跑两周让所有人习惯“有事进系统”再逐步加需求管理和项目任务。权限分配时遵循最小可用原则开发人员不需要“删除需求”的权限测试人员不需要“创建发布”的权限这些在后台权限组里都能按模块勾选。2.2 核心流程的六步闭环手册 1.4 节把基本流程压缩成六步产品经理创建产品→创建需求→项目经理创建项目→确定项目要完成的需求→分解任务指派到人→测试人员测试提交 bug。这六步看着简单但它对应的是禅道底层的数据关联关系需求必须挂在产品下任务必须挂在项目下而项目通过“关联需求”把产品侧的需求拉进来。理解了这个父子关系你就能明白为什么“需求没评审通过就关联不到项目”——因为只有激活状态的需求才能被项目关联。手册里反复强调“只有激活状态的需求才能关联到项目中进行开发”这不是废话是禅道数据模型的硬约束。实际落地时我一般会让产品经理先把一个迭代要做的需求全部评审通过再让项目经理一次性关联避免边关联边评审导致任务列表反复变动。2.3 登录入口与个人工作台手册 1.5 节描述的登录方式是从 OA 系统选择协同工作图标再进关联系统点禅道。这是典型的单点登录集成场景如果你的环境是独立部署禅道直接访问禅道地址用账号密码登录即可。登录后第一站是「我的地盘」手册第二章把这里讲得很细待办、我的任务、我的 bug、我的需求、我的测试、我的档案。这里有个实用习惯——每天上班第一件事不是去项目里翻而是打开「我的地盘」把指派给自己的任务、需求、bug 按截止时间过一遍。手册 2.2 节说得很直白“每天的工作其实也很简单就是将我的地盘中指派给自己的任务、需求或者 bug 及时处理掉就可以了。”待办功能2.1 节适合放那些还没进系统的私人事务或临时事项可以设起止时间也可以勾选“私人事务”不让别人看到。浏览待办时用日期、类型、名称三个标签筛选比一页页翻快得多。3. 产品经理侧需求、计划、发布怎么串成一条线3.1 维护产品与模块分类产品经理登录后进入产品视图右侧“添加产品”是第一步。手册 3.1 节提醒了几个关键字段产品代号相当于内部隐喻比如某产品的代号产品负责人负责整理和解释需求、制定发布计划测试负责人用于“公司人比较多、提交 bug 不知道该给谁”的场景发布负责人主要创建发布。访问控制可以设私有只有产品添加者、负责人、测试负责人、发布负责人以及该产品项目团队才能访问。产品建好后紧接着是维护模块3.5 节模块就是对需求的分类树。操作路径是产品视图→选择产品→点“模块”→一级级维护。左侧数字是排序字段调整它就能改变模块在树里的位置编辑模块时可以修改上级模块相当于把分类挪个位置。我的经验是模块层级别超过三层否则需求挂载时选择成本太高大家就会随便挂甚至不挂统计报表立刻失真。3.2 创建需求与评审流程手册 3.2 节的核心观点是“按照功能点的方式来写需求”把原来需求文档里的每个功能点摘出来作为独立需求录入。创建时标题必填所属计划和模块可暂空关键是那个“不需要评审”复选框勾上新需求直接是激活状态不勾需求进入评审流程。评审结果有确认通过、有待明确、拒绝三种。确认通过→状态变激活→可关联项目有待明确→保持草稿并指派回创建者继续完善拒绝→必须填拒绝原因。评审人员名单在“由谁评审”字段里输入用户名自动筛选线下开完评审会再把参与人记录进去即可。这里有个容易忽略的点需求可以设抄送字段需求变化会通过邮件抄送给相关人员还可以设关键词方便检索。我一般要求产品经理把关键词写成“模块名功能名”的格式后面在需求列表里搜起来命中率最高。3.3 需求变更与影响范围确认需求变更走的是独立流程3.3 节。凡是对标题、描述、验证标准、附件的修改都应该走变更而不是直接编辑——因为编辑操作根本改不了这四项。变更后需求状态变为“变更中”变更页面会列出该需求的影响范围。评审变更时可选确认通过、撤销变更、有待明确、拒绝。确认通过→状态从“已变更”变回“激活中”撤销变更→回退到之前版本有待明确→打回变更者拒绝→填原因。变更确认后研发和测试需要分别确认任务确认需求变动、bug 确认需求变动、用例确认需求变动。这一步在实际执行中经常被跳过导致开发和测试拿着旧理解干活。我的做法是变更评审通过后在项目任务列表里给相关任务加一条备注强制开发点确认否则任务不算完成。3.4 需求状态与阶段的双字段跟踪手册 3.4 节讲得很清楚需求有两个字段状态status和阶段stage。状态四种草稿、激活、已变更、已关闭对应创建、变更、审核、关闭、激活五个操作。阶段描述激活需求在研发过程中的位置未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。阶段是自动推进的没关联项目和计划→未开始关联计划没关联项目→已计划关联项目没分解任务→已立项有开发任务进行中且测试任务未开始→研发中开发任务全完成且测试未开始→研发完毕有测试任务进行中→测试中测试全结束但开发还有未结束→测试中测试和开发都结束→测试完毕验收阶段需要产品经理手工确认关闭原因是“已发布”→阶段为已发布。理解这套自动规则你就能通过阶段字段快速判断一个需求卡在哪一环而不用点进去看任务详情。3.5 计划、发布与路线图发布计划3.6 节对产品经理是规划节奏的工具对其它部门和客户是了解进展的窗口对项目关联需求是筛选依据。创建计划后可以为计划关联需求也可以在添加需求时直接指定计划已过期计划不会列出。计划和项目没有强对应关系理想情况是一个计划对应一个项目但实际中一个项目往往关联多个计划的需求。发布3.7 节有两个前提产品关联过项目、项目创建过版本。创建路径是产品视图→发布列表→创建发布。计划和发布共同组成路线图3.8 节绿色代表已发布版本黄绿色代表将来计划点击可查看具体需求。文档管理3.9 节分产品文档库、项目文档库、自定义文档库三类文档类型有文件、链接、网页三种。需求统计报表3.10 节在产品视图需求子栏目下点“统计报表”可按产品需求数量、模块需求数量、计划三个维度统计。4. 项目与开发测试侧任务分解、版本提交与 bug 闭环4.1 建项目、组团队、关联需求项目经理登录后建项目4.1 节然后组建项目团队4.2 节再确定项目要完成的需求列表4.3 节。这三步的顺序不能乱团队没建好就分解任务指派时找不到人需求没关联就分解任务任务没有来源依据。手册 4.4 节讲任务分解我一般要求项目经理在分解时把任务粒度控制在 4 到 8 小时超过一天的任务继续拆。任务指派到人后开发人员登录就能在「我的地盘」看到。燃尽图4.5 节用来了解项目进展各种列表功能4.6 节和任务报表4.7 节用于日常跟踪。这里有个实操细节燃尽图要好看前提是任务工时估算相对准确如果大家随手填 1 小时实际干一天燃尽图就是一条玄学曲线参考价值归零。4.2 开发领任务、建版本、申请测试开发人员5.1 到 5.4 节参加项目计划会议分解任务然后领取任务并每天更新任务状态和剩余工时。任务完成后创建版本5.3 节版本里关联本次解决的需求和 bug然后申请测试5.4 节。创建版本是发布的前提没有版本就没有发布。我见过不少团队开发完直接在群里喊“测吧”版本号都不建结果测试提的 bug 无法关联到具体版本发布时也找不到对应关系。手册 5.5 节讲解决 bug5.7 节讲确认 bug这两个动作的区别是解决是开发改完代码把 bug 状态改为已解决并指派回测试确认是测试验证通过后关闭。5.6 节的文档管理对开发同样适用项目文档库用来存项目过程中的设计文档和接口说明。4.3 测试提 bug、验证关闭与激活测试人员6.1 到 6.10 节先维护 bug 视图模块6.1 节然后提交 bug6.2 节。提交时必填项包括所属产品、所属模块、影响版本、bug 标题、重现步骤等。验证 bug 后关闭6.3 节如果验证不通过则激活 bug6.4 节打回给开发。6.5 节讲找到自己需要的 bug6.6 到 6.9 节讲测试用例视图维护、创建用例、管理测试任务、执行用例并提交 bug。6.10 节是查看报表统计。测试侧最容易出问题的是 bug 描述质量只写“功能不对”四个字开发得追着问半天。我要求测试提交 bug 时至少包含环境、前置条件、操作步骤、预期结果、实际结果五项截图或日志作为附件上传。这样开发解决效率至少翻倍。5. 避坑与排查禅道落地中最容易翻车的五个地方5.1 需求状态卡在草稿项目关联不到现象项目经理在关联需求时搜不到某条需求。原因该需求创建时没勾“不需要评审”且还没走评审流程状态是草稿。解决让产品经理在需求列表里筛选草稿状态走完评审确认通过状态变激活后即可关联。如果需求已经不需要了直接关闭别留着占列表。5.2 任务分解后燃尽图不更新现象任务明明在推进燃尽图却是一条平线或乱跳。原因开发人员没有每天更新任务的剩余工时或者任务完成后没有及时点“完成”。燃尽图是根据剩余工时总和绘制的数据不更新图就不动。解决把“每天下班前更新任务剩余工时”写进团队约定项目经理每天上午检查一次连续两天不更新的在站会上点名。5.3 bug 解决后测试收不到通知现象开发把 bug 状态改为已解决并指派给测试但测试说没收到。原因禅道默认通过站内信和邮件通知如果邮件服务没配好站内信又没人看就会漏掉。解决检查后台邮件配置是否正常同时要求测试每天至少两次查看「我的地盘」里的“我的 bug”不要只依赖邮件。5.4 版本创建了但发布时找不到现象产品经理创建发布时提示没有可用的版本。原因发布的前提是产品关联过项目且项目创建过版本两个条件缺一不可。如果项目没关联到该产品或者版本建在了别的项目下发布时就找不到。解决先确认项目已关联该产品再确认版本是在该项目下创建的且版本关联了本次要发布的需求和 bug。5.5 模块层级太深导致需求挂载混乱现象统计报表里模块需求数量对不上很多需求挂在根模块或错误模块下。原因模块树层级过多产品经理录入需求时懒得逐级展开直接挂在顶层。解决模块层级控制在三层以内录入需求时强制选择到具体叶子模块定期用统计报表检查模块分布发现异常集中清理。6. 进阶技巧用统计报表和路线图反向验证流程健康度手册 3.10 节提到的需求统计报表很多人只把它当汇报材料其实它是最好的流程体检工具。我一般每周看三个数产品需求数量、模块需求数量、按计划统计的需求分布。如果模块需求数量里“未分类”占比超过 20%说明模块树设计有问题或者录入不规范如果按计划统计里某个计划的需求长期不推进说明计划制定时拍脑袋了。路线图3.8 节同样可以反向验证绿色发布版本如果间隔忽长忽短说明发布节奏不稳定黄绿色计划如果长期不变成绿色说明计划执行有问题。把这些报表和路线图结合起来看比单纯盯燃尽图更能发现流程层面的毛病。另一个进阶用法是文档库的分类维护3.9 节。产品文档库、项目文档库、自定义文档库三类要提前规划好分类不要等文档堆了几百篇再整理。我的习惯是产品文档库按“需求规格、设计说明、用户手册”分项目文档库按“项目计划、会议记录、验收报告”分自定义文档库放公司规范、培训材料。文档类型选“网页”的可以直接用富文本编辑器写选“文件”的上传附件选“链接”的存外部地址。每次项目结项时强制把验收报告归档到项目文档库半年后回头看这就是团队的知识资产。从那以后我每次接手一个新禅道环境都强制走一遍“建产品→提需求→评审→建项目→关联需求→分解任务→建版本→提 bug→解决→验证关闭”的完整链路哪怕用测试数据跑一遍也要确认每个环节的状态流转和通知都正常。流程这东西不自己走一遍永远不知道哪里会卡住。希望帮到你。本文还有配套的精品资源点击获取