简介禅道使用手册完整版面向项目经理、产品经理、开发与测试人员以及正在导入项目管理流程的团队用于解决禅道功能多、角色权限与协作流程不易系统掌握的问题。整包仅含1个docx文档体积约4.02MB便于直接查阅和随项目分发。手册按角色与场景组织从软件介绍、用户角色、最简使用、登录流程讲起延伸到个人待办管理、我的任务与BUG跟进、个人档案维护再覆盖产品经理维护产品、创建与评审需求、需求变更、需求状态阶段、产品模块与发布计划以及项目经理建立项目、组建团队、任务分解和通过燃尽图查看进展等内容。目录层级完整适合新手按章节入门也方便有经验的成员在需求评审、缺陷跟踪和项目进度复盘时快速定位操作说明。目前已有5219人学习可作为团队内部培训与日常查阅的参考文档。1. 先弄明白一件事禅道到底是个什么软件刚进项目组的新人常有一个困惑需求躺在聊天记录里bug 记在表格里进度靠每天凑到工位旁边问一句“做到哪了”。同一条信息散在四五个地方谁改过、改到第几版全凭记性。你手上这份《禅道使用手册完整版》要收拾的正是这个场面——禅道是一套打开浏览器登录就能用的项目管理软件把产品管理、项目管理、测试管理、文档管理塞进同一个系统里让需求、任务、bug 各自有唯一的一条记录。它适合产品、开发、测试、项目经理凑在一起干活的小团队也适合一个人想把自己的事管起来。零基础不用担心它本质上是几个表格和流程按钮搞懂顺序就会用。2. 为什么要学它三个角色和一条主线流程2.1 没有工具的时候一条需求要经多少道手举个特别日常的场景。某公司的一个小团队要做内部管理系统产品负责人在会上讲了一通想法开发当场记了两笔测试在群里问“那我要测什么”没人回答得上来。两周后功能上线产品说“这不是我要的”开发说“你当时没说清楚”测试说“我压根不知道有这需求”。这不是谁不负责是信息在传递过程中被磨掉了。换个类比做饭。菜谱写在一张纸上买菜清单在手机备忘录里谁负责洗菜靠喊做完发现买错了菜锅已经热了。禅道干的事是把菜谱、采购单、分工表钉在同一块板子上谁动了哪一行都留痕。它不改变你做菜的水平但能让你少返工几次。所以学它的第一个理由不是“公司要求用”而是它会强迫你把模糊的想法写成一条能被别人看懂、能被跟踪到底的记录。这个习惯本身就是项目管理的基本功。2.2 系统里的五种角色各自管什么新手最容易犯的错是用管理员账号进去乱点或者用开发账号去找“添加产品”按钮——找不到就以为软件坏了。禅道按角色划分权限先认清自己是谁再谈会不会用。角色在系统里主要干什么新手第一天要做的事系统管理员添加用户、分配权限一般不需要你管找管理员要账号产品人员维护产品、创建和评审需求、定发布计划认领自己的产品把需求录进去项目经理建项目、组团队、定需求列表、分解任务把需求变任务指到具体的人开发人员领任务、更新进度、创建版本、解决 bug看“我的任务”每天更新一次测试人员提交 bug、验证关闭、维护测试用例认领测试任务按用例执行这五种角色不是职级是干活的视角。小团队里一个人可能同时是产品和项目经理那就在两个视角之间切换着看别指望一个页面把所有事都办完。2.3 一条主线流程从建产品到关 bug手册里给的六步流程是整个系统的骨架值得先背下来产品经理创建产品产品经理创建需求项目经理创建项目项目经理确定项目要做的需求项目经理把需求分解成任务指派到人测试人员测试提交 bug开发解决测试关闭把这条线想象成一条传送带需求是原料项目是车间任务是工序bug 是质检退回的次品。原料没进来车间就是空的任务没指派到人工序就停在那里。很多人用了半年还觉得乱问题往往出在这条线上某一环断了——比如需求建了但没关联到项目任务就永远分解不出来。2.4 只用其中一块也完全可以新手容易有个误解以为上了禅道就得全员全流程跑起来结果第一周就集体翻车最后大家退回聊天记录。手册里明确列了四种“最简使用”的方式我觉得这个思路对新人特别友好只拿它做产品管理需求录进去版本计划排出来只拿它做项目任务管理把手上要干的事拆成任务指派、跟踪只拿它做 bug 管理测试提交、开发解决、测试验证三步闭环只拿它做个人事务跟踪就是下面要讲的待办入门的话建议先挑一块用顺了再往里加。我第一次接触这类系统时贪多一次性把需求和任务全搬进去结果录数据的成本比干活还高两周就放弃了。第二次只做 bug 管理因为痛感最直接反而坚持下来了。3. 第一步怎么迈登录进去先收拾自己的地盘3.1 登录与认路先记住三个地方登录方式每个环境不一样有的团队从内部办公系统点“关联系统”跳进来有的是直接给一个地址。不管哪种进去之后先别急着点功能花五分钟认三块地方第一块是顶部或左侧的一级菜单通常是“我的地盘”“产品”“项目”“测试”“文档”这几个入口它们对应上面说的几种视角。第二块是页面右侧的操作链接比如“添加产品”“提需求”“创建版本”禅道的设计习惯是把新增操作放在列表页右侧找不到按钮时先看右边。第三块是列表上方的筛选条件按状态、按人、按时间过滤用熟了效率差别很大。提示如果某个菜单点进去提示没有权限不是你操作错了是角色权限没配。找管理员而不是反复刷新页面。3.2 创建第一条待办把今天的事写下来这是我在带新人时安排的第一个练习因为它不涉及任何团队协作一个人就能完成失败成本为零。进入“我的地盘”点击“日程”点击添加待办填写名称比如“整理本周需求清单”设定起止时间也可以先空着如果是私事勾选“私人事务”保存每一步在干什么说白一点名称是给未来的自己看的所以要写成“动词 对象”别写“那个事”起止时间是给自己一个截止点不填的话这条待办大概率会躺到月底勾选私人事务是为了让它不出现在团队的工作视图里避免同事看到你“下午三点去取快递”。保存之后回到待办列表可以按日期、类型、名称去筛。这个动作看起来很小但它建立的是“事情要落到一条记录上”的习惯。等你要管的是二十条任务而不是两条待办时这个习惯会救你。3.3 每天上班第一件事看这四块禅道在“我的地盘”里把指派给你的东西单独拎了出来分成我的任务、我的 BUG、我的需求、我的测试。这四块是每日入口不需要记路径打开就能看到。我的任务项目经理分解后指派给你的活看截止日期和当前状态我的 BUG测试提给你、等你修的问题注意严重程度和优先级我的需求需要你评审或确认的需求产品经理会盯着你我的测试分给你的测试任务通常跟着版本走手册里那句话说得挺实在每天的工作其实很简单就是把指派给自己的任务、需求和 bug 及时处理掉。听起来像废话但真正做到的人不多。常见的翻车是任务做完了不更新状态项目经理看板上全是“进行中”只好挨个来问一天的时间就耗在同步信息上了。3.4 我的档案改密码别等到忘了“我的地盘”里还有“我的档案”能看和改自己的个人信息包括改密码。这件事本身没什么技术含量但值得单独提一句入职第一周就把密码改掉并且记在靠谱的地方。带过的新人里至少有两个是在要演示的前十分钟发现登不进去最后只能找管理员重置——本来五分钟能解决的事变成了全组等一个人。4. 需求的完整旅程从一句话到能开发的功能点4.1 先添加产品几个字段别乱填产品是整个系统的起点没有产品需求和计划都无处安放。用产品人员角色登录进入产品视图点右侧“添加产品”。如果系统里一个产品都没有通常会自动跳到添加页。几个字段值得展开说产品代号相当于这个产品的内部简称用英文短词就行比如某内部管理系统可以叫 portal。它主要用在对外的标识上填得短一点以后省事。产品负责人负责整理和解释整个产品需求、制定发布计划的人。这个字段不是挂名需求评审时会找这个人。测试负责人可以指定一个默认的测试负责人。公司人一多提 bug 的时候经常不知道给谁有这个默认值就省了口舌。发布负责人主要职责是创建发布项目收尾时用得上。访问控制可以把产品设成私有只有添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队能访问。新手最容易忽略的是访问控制。默认公开当然方便但如果产品涉及还没对外公布的东西一开始就设私有比事后补救轻松得多。4.2 按功能点写需求一条一条录禅道的需求不是让你上传一篇需求文档而是按功能点拆开一条一条录进去。手册里说得很清楚把原来文档里的每一个功能点摘出来作为一个个独立的功能点。这个设计一开始会让人觉得麻烦但它是后面所有统计、跟踪、关联的基础。操作路径是产品视图 → 右侧“提需求” → 填标题必填→ 所属计划和模块可以先空着 → 需求审核那里按情况选择 → 保存。新增需求时有几个小设置用得上抄送需求有变化会以邮件形式通知到相关人员别小看这个它能省掉无数次“你怎么改了不告诉我”。关键词方便以后按关键词检索需求一多就知道值钱了。不需要审核勾上之后新需求直接是激活状态只有激活状态的需求才能关联到项目里开发。我一般建议新人第一周先勾“不需要审核”把录入的动作练熟等到要正式跑流程了再把这个勾去掉走评审。4.3 需求评审三种结果分别意味着什么大部分情况下需求是要评审的。就算产品只有一个人负责也可以把不成熟的想法先存成草稿过两天再看。评审页面上有三个主要结果含义差别很大确认通过需求状态变成“激活中”可以关联到项目里开发了。有待明确需求保持草稿状态并且被指派回创建者头上让他继续完善。这个选项很实用比直接拒绝温和也比含糊通过负责。拒绝需要填写拒绝原因别偷懒原因写清楚三个月后你自己也会回来看。评审人员那一栏可以输入用户名自动筛选。线下开个评审会线上把参与人记录下来这个组合最省事——会开完了记录也在系统里了。4.4 需求变更为什么不能直接编辑这是新手最容易翻车的地方没有之一。很多人发现需求写错了直接点编辑改掉改完还挺得意。问题是改完之后开发看到的是一份“从来没有变过”的需求之前按老版本写的代码就成了无源之水。禅道的做法是把“编辑”和“变更”分开编辑只能改一些边角信息标题、描述、验收标准、附件这四项改动必须走变更流程。变更之后需求状态变成“变更中”并且系统会列出这个需求的影响范围——关联了哪些任务、哪些 bug、哪些用例一目了然。变更也要评审结果有四种确认通过状态从“已变更”变回“激活中”撤销变更取消这次变更回退到之前的版本有待明确打回给变更的发起人继续完善拒绝同样要填原因变更被确认之后事情还没完。研发团队和测试人员需要去确认这个变动对自己工作的影响任务要确认bug 要确认用例也要确认。这一步很多人跳过结果就是需求改了、任务没改做出来的东西对不上。4.5 状态和阶段两个字段一张表看懂需求身上挂两个字段一个管“生死”一个管“进度”新手经常搞混。状态status只有四种对应五个动作创建、变更、审核、关闭、激活状态含义怎么进入草稿还没评审通过的原始想法创建时选择需要评审激活可以进入开发评审通过或创建时勾了不需要评审已变更正在走变更流程提交变更后已关闭这个需求结束了手动关闭阶段stage描述激活的需求在研发过程中走到哪一步包括未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。它的推进基本是自动的规则可以简化成三句话没关联计划、也没关联项目 → 未开始关联了计划但没进项目 → 已计划进了项目但没分解任务 → 已立项有开发任务在跑 → 开发中开发任务全完、测试没开始 → 开发完毕有测试任务在跑 → 测试中开发和测试都结束 → 测试完毕“已验收”需要产品经理手工确认“已发布”则是在关闭需求时把原因选成“已发布”才会出现。这两个字段看懂之后你看需求列表就能判断出这条需求卡在谁手上。4.6 模块、计划、发布和路线图产品经理的四件配套工具需求录完了还有四样东西要把它们组织起来。模块是对需求的分类一级一级往下维护。左侧的数字用来排序调数字就能调整它在模块树里的位置编辑某个模块时还能改它的上级模块。模块分得好大家对产品的结构就有宏观认识分得乱后面统计报表全是糊涂账。计划是发布节奏的规划。进入产品视图打开计划列表点右侧“创建计划”填完再给计划关联需求。也可以在提需求的时候直接指定计划注意已经过期的计划不会列出来。计划和项目没有强绑定关系理想状态是一个计划对应一个项目现实里通常是一个项目的需求大部分来自某个计划同时夹着别的计划的几条。发布是在项目结束后由产品人员创建的用来告诉其他部门“新版本可以用了”。创建发布有两个前提这个产品关联过项目并且该项目创建过版本。少一个都建不出来这是新手最常问的“为什么按钮点了没反应”。路线图是计划和发布自动组成的绿色代表已经发布过的版本黄绿色代表将来的计划点进去能看到具体的需求。给上级汇报进度的时候这一张图比十页文档管用。5. 建项目、拆任务、提 bug日常怎么跑外加 4 个避坑点5.1 项目经理起手三件事建项目、组团队、定需求项目经理接手之后动作顺序是固定的先建项目再把团队拉进来然后从产品池子里挑出这个项目要做的需求。建项目时填的是项目名称、起止时间、负责人这些基本信息。团队那一步别嫌麻烦把开发和测试都加进去后面分解任务时才能指派到人团队成员没加全你会遇到“搜不到这个人”的尴尬。确定需求列表这一步本质是划范围这个迭代就做这几条其他的下次再说。范围划不清项目就会无限膨胀最后谁都不满意。做完这一步项目里就有了明确的目标清单。5.2 任务分解与燃尽图进度不是问出来的需求确定后要组织大家把需求拆成任务。一个需求可能拆成“设计接口”“写后端逻辑”“写前端页面”“联调”“写用例”几条任务每条指派到一个人估一个工时。拆完之后系统会生成燃尽图。这张图横轴是时间纵轴是剩余工时理想情况下那条线一路往下走到零。实际用起来线不平才是常态但它的价值在于你能看出是哪一天开始掉队的而不是等到交付前一天才发现做不完。除了燃尽图项目里还有各种列表视图可以按人看、按状态看、按截止时间看。手册里提到项目任务的报表统计用来做阶段性复盘挺合适。5.3 开发的四步日常领任务、更新、建版本、申请测试开发人员在一个迭代里的动作可以压缩成四步参加项目计划会议认领分给自己的任务每天更新任务状态和已消耗工时开发完成后创建版本把这一批改动打包申请测试让测试人员开始验证第二步最容易被跳过。很多人觉得“我活干完了再一起更新”结果就是燃尽图一直平着项目经理以为进度停滞。每天花三十秒点一下比你事后解释半小时省事。创建版本这一步也有讲究版本要写清版本号和包含的需求、bug 修复列表测试人员拿到的就是这份清单。版本描述写得含糊测试就只能凭感觉测漏测是必然的。5.4 测试的四步日常提 bug、验证、关闭、激活测试这条线的闭环是四个动作提交 bug时标题写清“在什么条件下做了什么出现了什么结果”描述里附上复现步骤和环境。只写一句“页面报错”开发只能来问你一来一回半天没了。验证 bug是开发修复后测试重新走一遍复现步骤确认问题真的没了。这一步不能只看代码改动得实际点一遍。关闭 bug是验证通过后的收尾。也可以在解决时选择“不予解决”并写明原因但要走评审别自己悄悄关掉。激活 bug用于两种情况验证时发现没修好或者已关闭的 bug 又复现了。这是个体检式的机制别嫌麻烦重新激活比新提一个更有利于追溯。测试这边还有测试用例的维护、测试任务的创建与执行、按用例跑完提交 bug。用例库是团队的资产写一次能用很多次前期投入值得。5.5 发布与路线图项目收尾别漏这一步项目做完不等于事情结束。产品人员要创建发布前提是产品关联过项目、项目创建过版本两个条件都满足发布按钮才有意义。发布一建其他部门就知道可以在新版本上开展工作了路线图上也多一个绿点。很多团队漏掉这一步导致版本发了但没人知道下一次开会又要解释一遍。5.6 四个最容易翻车的地方坑一需求建好了但项目里一条都看不到。现象是项目经理建完项目发现需求列表是空的。原因通常是需求还在草稿状态或者没有关联到这个项目。解决办法是先确认需求状态是“激活”再在项目里手动关联需求列表别指望它自动出现。坑二改了需求标题开发和测试完全不知道。现象是上线后对不上一查发现需求被悄悄改过。原因是直接用了编辑功能。解决办法是把“标题、描述、验收标准、附件”的改动一律走变更流程让系统把影响范围列出来再挨个确认任务、bug 和用例。坑三任务一直显示进行中燃尽图是条直线。现象是快到截止日期了图还不降。原因是大家做完不更新状态或者只更新状态不填工时。解决办法是定个规矩每天下班前花一分钟更新自己名下的任务项目经理每周抽查一次。坑四bug 提了一大堆开发说复现不了。现象是 bug 在测试和开发之间来回踢。原因是描述里只有结论没有步骤。解决办法是提交时强制写三样东西操作步骤、预期结果、实际结果能截图就截图环境信息别省。6. 下一步学什么给零基础的一条上手路线如果现在让你打开系统我建议按这个顺序走一周一个台阶不要贪快第一周只碰“我的地盘”。每天建一两条待办把当天要做的事写进去下班前勾掉。同时把“我的任务”“我的 BUG”这两个列表当首页用。这一周的目标不是学会功能是养成“事情记在系统里”的肌肉记忆。第二周挑一条线走通。如果你偏产品就试着建一个产品、录三条需求、走一次评审如果你偏开发或测试就找一个正在跑的项目领一条任务或者提一个 bug完整走完从提交到关闭的闭环。走通一条比看十遍手册管用。第三周补流程知识。重点关注两个东西需求的状态和阶段、项目的燃尽图。这两个是判断“事情卡在哪”的核心工具。可以拿团队里正在跑的一个真实需求对着状态表推一遍它现在在哪个阶段推对了说明你真懂了。第四周看报表和文档库。需求统计报表能按产品、按模块、按计划三个维度看数量项目那边也有任务统计。文档库分产品文档库、项目文档库、自定义文档库三种文档类型有文件、链接、网页三种把团队散落的知识往里收一收。再往后就是熟练度的问题了用得多自然快。有个小技巧值得单独说善用筛选和关键词。需求、任务、bug 都支持按条件筛录需求时填的关键词这时候就派上用场。同一批数据会筛的人十秒找到不会筛的人翻二十分钟。最后说个我自己的教训。刚带新人的时候我总想一口气把整套流程讲完结果对方听完一脸茫然回去还是用表格。后来我改成只教一个动作今天下班前把你手上的活更新一下状态。就这么一句话坚持两周人自然就开始问“那需求怎么建”“那 bug 怎么提”了。从那以后我每次带人都强制让自己先只讲一个动作等他主动问第二个。希望这个思路也能帮到你别急着把手册从头读到尾先打开系统把今天的一件事记进去。本文还有配套的精品资源点击获取
