企业官网建设流程全解析

简介：《禅道使用手册（完整版）》面向项目经理、产品经理、开发与测试人员，以及需要落地项目协作流程的团队，围绕禅道这一Web项目管理工具，梳理从登录、角色权限到项目跟踪、需求与缺陷协同的完整使用路径。压缩包内含1个docx文档，大小约4.02MB，便于直接检索和按章节查阅。手册目录按基本介绍、个人管理、产品经理使用、项目经理使用等模块展开，具体覆盖待办创建与浏览、我的任务与我的BUG、需求创建评审变更及状态阶段、产品模块维护、发布计划与发布建立、燃尽图查看等内容，可帮助读者快速理解不同角色的操作边界与协作节点。已有5219人学习，适合作为团队内部培训资料、禅道实施对照清单或新成员上手参考，也可用于查漏补缺和规范项目管理流程。

1. 拿到这份手册别从第一页读：五个角色对应五条阅读路径

多数人拿到《禅道使用手册（完整版）》就从「1.1 软件介绍」一路往下翻，翻到需求评审那节已经犯困——这份文档是按角色分章的，产品经理的活集中在第 3 章，项目经理在第 4 章，开发第 5 章，测试第 6 章，按页码顺序读等于把四条并行的工作流拧成一根线。它解决的是「禅道到底怎么配、每个角色每天该点哪里」：产品、项目、测试三条主线被拆成可执行动作，从建产品、提需求、评审、变更，到建项目、拆任务、看燃尽图，再到提 Bug、验证、关单，一条不缺。适合刚接手配置的管理员、被要求「下周团队迁到禅道」的项目经理，以及只想搞清楚自己那摊活的开发与测试。读它的重点在于知道哪个字段填错会让后面全乱，而不只是认菜单。

2. 产品线的骨架：产品、模块、计划、发布怎么串成一条线

产品经理那一章看着条目多，实际只有一条主线：产品是容器，需求是内容，模块是分类，计划是节奏，发布是出口。顺序错了，后面每一步都会别扭。举个最常见的返工：先建了项目再回头补产品，结果项目关联需求时发现需求还没评审、状态是草稿，一个都挂不上去。这就是没按主线走的典型代价。

2.1 先定产品再谈需求：产品代号与三个负责人字段

进入产品视图，点右侧「添加产品」。如果系统里一个产品都没有，登录后会自动跳到添加页，这个设计对新人挺友好。表单里有几个字段值得逐个说清楚，因为它们是后面所有通知和权限的落点。

产品代号是团队对这个产品的隐喻，手册里举的例子是禅道自己的代号 zentao。它的作用不是好看，而是让 URL、报表和搜索里有一个稳定的短标识，团队口头沟通时也好念。代号一旦定下来就别改，改一次所有外部引用都得跟着动。

产品负责人负责整理和解释整个产品的需求、制定发布计划，这个人默认会收到需求变更的抄送。测试负责人这个字段经常被忽略，但人一多它就是救命字段：提交 Bug 时如果不指定默认处理人，Bug 会堆在提交者手里没人认领，设了测试负责人至少有个兜底。发布负责人主要负责创建发布，产品线有多个版本并行时，建议指定到具体的人而不是泛指一个组。

访问控制是这一页最容易被随手放过、后面又最常出问题的字段。设成私有之后，只有产品添加者、产品负责人、测试负责人、发布负责人，以及该产品关联项目的团队成员能访问。我一般会建议：内部中台类产品先设私有，把可见范围收紧，等团队稳定了再放开；对外交付类产品反而要早点想清楚谁能看，否则后面补权限会牵动一堆人的视图。

维护模块在产品视图的「模块」菜单里。它是一级一级往下建的，每一级左侧有个数字是排序字段，调整这个数字就能调整模块在树里的位置。编辑模块时可以改它所属的上级模块，这一点在重构需求分类时很有用——不用删了重建，直接改挂载点。模块树的价值在于让需求能被分类检索，产品需求一多，没有模块树的需求列表基本等于不可用。

2.2 需求按功能点拆：评审三岔口与「不需要评审」的适用边界

禅道的需求写法跟传统需求文档不一样，它要求按功能点来写：把原来一份需求设计文档里的每个功能点摘出来，一条一条录进系统，每条成为独立的需求条目。这个约束初看很烦，但它换来的是需求可以被单独排期、单独关联任务、单独跟踪状态。一份二十页的文档挂在一个需求上，进度永远是玄学。

创建需求的入口在产品视图右侧的「提需求」。标题是必填项，所属计划和模块可以先空着。抄送字段填上相关人员后，需求的变化会通过邮件抄送出去，这是禅道里最省事的通知机制之一。关键词字段用来做检索，我一般会要求团队按「端-模块-动作」的格式填，比如「移动端-订单-取消」，后面搜起来很快。

评审那块有个「不需要评审」的复选框。勾上之后，新建需求直接是激活状态；不勾，需求会先进草稿，等评审。手册里给的建议很实在：即使产品完全由一个人负责，也可以把不成熟的想法先存成草稿，后续再处理。所以不要图省事全局勾「不需要评审」，它的适用边界是「这条需求已经想清楚、要立刻进项目」，而不是「我懒得评审」。

评审页面的三个结果对应三条完全不同的路径，这个必须记牢：

「由谁评审」记录的是参与评审的人员名单，输入用户名可以自动筛选。线下开评审会、线上只记录参与人，这是常见做法，不必强求在系统里走投票。

2.3 变更流程与编辑的边界：改标题为什么必须走变更

这一节是我认为整份手册里最该划重点的地方。禅道把「编辑」和「变更」拆成了两个动作：编辑改不了需求的标题、描述、验收标准和附件；凡是对这四项的修改，都必须走变更流程。变更之后需求状态变成「已变更」。

为什么要这么设计？因为需求标题和验收标准是开发写代码、测试写用例的直接依据。允许随手编辑，等于允许有人在不通知任何人的情况下改掉验收标准，然后开发按旧标准做完了、测试按新标准验不过，最后吵起来谁也说不清。变更流程强制留下版本差异和影响范围，这是给团队留的后悔药。

变更页面上会列出该需求的影响范围，包括关联的任务、Bug 和用例。评审变更时有四个选项，走错一个就要回滚：

• 确认通过：状态从「已变更」变为「激活中」，新版本生效
• 撤销变更：取消当前变更，回退到之前的版本
• 有待明确：打回给变更发起人继续完善
• 拒绝：需要给出拒绝原因

变更确认之后还有一步容易被跳过：研发和测试要分别在自己的对象上确认需求变动，也就是任务确认、Bug 确认、用例确认。不做这一步，任务列表里挂的还是旧需求的描述，等于变更只改了一半。我见过团队上线半年后才发现某个需求的验收标准和用例对不上，追下去就是当初变更只走了前半程。

顺带说一句，变更时如果勾了「不需要评审」，需求状态会直接变成激活，不再走评审。这个开关适合紧急修正，但别当成常规路径用。

2.4 状态与阶段两张表：判断需求卡在哪一环

需求有两个字段在跟踪它，很多人只盯着状态，忽略了阶段，结果就是「明明激活了怎么还不开发」这类问题反复出现。

状态字段只有四个值：草稿、激活、已变更、已关闭。对应的流程操作是创建、变更、审核、关闭、激活。状态回答的是「这条需求在流程上合不合法」。

阶段字段回答的是「这条激活的需求在研发里走到哪了」，取值有九个：未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。触发条件手册里写得很细，我整理成对照表，排查时直接对号入座：

注意「已验收」是唯一需要人工操作的阶段，系统不会自动跳。所以如果团队抱怨需求一直停在测试完毕，先去看产品经理有没有点验收，而不是怀疑系统有 Bug。

2.5 模块树到路线图：计划、发布、文档库与统计报表

计划的作用有三层：对产品经理是规划节奏、调需求优先级；对其他部门和外部客户是告知进展；对项目是关联需求的来源。创建路径是产品视图 → 计划列表 → 创建计划，建完之后给计划关联需求。也可以在提需求时直接指定计划，注意已经过期的计划不会出现在下拉里，这是很多人「找不到计划」的原因。

计划和项目之间并没有强对应关系。理想状态是一个计划对应一个项目，实际大部分情况是：项目关联需求时，多数需求来自某一个计划，同时也捎带了其他计划的零星几条。别为了追求一一对应去拆计划，拆完你会发现计划比需求还多。

发布的前提有两个，缺一不可：该产品关联过项目，且该项目创建过版本。这两个条件不满足，「创建发布」点进去也建不成。发布的入口在产品视图的发布列表，创建之后可以告诉相关部门可以在新版本上开展工作。

计划和发布一起组成了产品的路线图。绿色部分是已发布的版本，黄绿色部分是未来的计划，点任一节点能看具体需求。这张图给管理层看比给开发看有用得多，开发更关心自己那几条任务。

文档库分三类：产品文档库存产品层面的产出，项目文档库存项目过程中的文档，自定义文档库适合放知识库和管理规范。文档有三种类型——文件型可以传附件，链接型存网址，网页型直接用富文本编辑器写。维护分类在文档视图下方。产品视图的需求子栏目里还有统计报表，能按产品需求数量、模块需求数量、计划三个维度出数，周会前拉一次够用了。

3. 项目侧落地：从建项目到燃尽图，一条能跑通的链路

项目经理那一章的动作顺序是有讲究的：建项目 → 组建团队 → 确定需求列表 → 分解任务 → 看燃尽图 → 用列表和报表补细节。跳过任何一步，后面的数据都会失真。这一章我按这个顺序走一遍，重点放在「参数怎么填」和「填错会怎样」。

3.1 建项目与组建团队：访问控制先想清楚

建项目时先想清楚项目类型。短期项目有明确起止日期，适合一个迭代或一个交付周期；长期项目适合持续演进的平台型工作；运维类项目则是没有明确结束时间的常态工作。类型选错最直接的影响是燃尽图：短期项目的燃尽图有终点线，长期项目没有，团队看着一条永远不归零的线会麻木。

项目名称建议带上版本或迭代标识，比如「订单系统-2024Q2-迭代3」这种格式，因为项目列表里同名项目一多，选错项目是高频事故。起止日期要填真实日期，别填个一年后，燃尽图的时间轴是按这个算的。

组建团队在产品或项目视图的团队维护页。左边是可用人员列表，右边是团队成员，加入时可以选择角色和可用工时。这里的角色决定了这个人在项目里能做什么操作，可用工时则会影响任务分配时的额度提示。常见做法是把开发和测试都加进来，产品经理是否加入项目团队取决于你们的协作习惯——加进来能看到项目内的任务和 Bug，不加则只能通过产品视图看需求。

访问控制这一栏，我一般会让项目经理在建项目时就定好：谁能进这个项目。私有项目的可见范围跟产品类似，只有项目团队成员、产品负责人等相关角色能看。中途改访问控制比一开始就设好要麻烦得多，因为已经有人基于旧范围建立了工作习惯。

3.2 关联需求：从计划挑需求，别手工一个个加

项目建好后，接着确定项目要完成的需求列表。这一步的关键认知是：需求来自产品，项目只是「领走」一部分。所以关联需求的操作本质是从产品的需求池里勾选，而不是在项目里新建。

常见做法是先按计划筛选。前面建计划时已经把一批需求归到了某个计划下，关联时按计划过滤一遍，勾选整批，比在几百条需求里逐条找要快得多。如果发现某个需求在列表里找不到，先回产品视图确认它的状态：草稿状态的需求关联不上，必须先评审通过变成激活。

关联完成之后，需求阶段会从「已计划」推进到「已立项」，这个变化能在需求的阶段字段里看到。如果关联完还是「已计划」，说明关联没生效，通常是点在错误的项目上或者权限不足。

3.3 任务分解：粒度、预计工时与指派

任务分解是整个项目侧最费手工、也最影响后续数据质量的一步。分解的对象是需求，一条需求下面可以挂多个任务，任务类型分开发和测试。每个任务要填名称、预计工时、优先级、指派给谁。

粒度上，我的经验是单个任务的预计工时控制在 4 到 16 小时之间。超过 16 小时的任务拆不动，说明需求本身还没想清楚；小于 4 小时的任务拆太碎，每天更新工时的开销会超过收益。

预计工时这个字段千万别留空。燃尽图的纵轴是剩余工时总和，任务没有预计工时，等于这个任务在图上不存在，图画出来是平的，看着像进展顺利，实际是黑匣子。指派到人也要认真填，不指派的任务会留在未指派列表里，几天后就没人记得它。

测试任务通常跟开发任务成对出现：开发任务负责实现，测试任务负责验证。手册里提到，需求阶段推进到「开发中」的条件是有开发任务进行中且测试任务都没开始，所以测试任务要先建出来但不启动，这个顺序别搞反。

3.4 燃尽图不动的原因与列表、报表的用法

燃尽图是项目经理最常盯的图，也是最容易被误解的图。它靠的是成员每天更新任务里的小数字段。开发领了任务之后，每天要更新已消耗工时和剩余工时，图才会往下走。这里有个血泪经验：只要有一天大家忘了更新，第二天图就会突然掉一大截，看起来像集中交付，实际是补录。所以日更是制度问题，不是工具问题。

燃尽图不动的三个典型原因，按出现频率排：一是成员根本没更新剩余工时；二是任务没填预计工时，压根不在统计范围内；三是项目起止日期填错，时间轴跟实际迭代对不上。

除了燃尽图，项目视图下的各种列表值得花十分钟配一遍。任务列表可以按指派给我、未完成、逾期等条件筛，保存成常用视图后每天打开就能看到自己该干什么。需求列表按阶段筛选能看到哪些需求卡在已立项没分解任务。Bug 列表按严重程度排能看出质量趋势。报表方面，项目任务的基本统计能给到按人、按类型的工时分布，做复盘时比拍脑袋靠谱。

4. 研发与测试闭环：版本、申请测试、Bug 生命周期与用例

开发和测试那两章是连在一起看的，因为它们共享同一个锚点：版本。开发的最后一步是创建版本并申请测试，测试的第一步是围绕这个版本提 Bug。版本号乱了，整条链路就断了。

4.1 创建版本与申请测试：版本号是整条链路的锚

开发侧的日常动作顺序是：参加项目计划会议分解任务 → 领取任务并每天更新 → 创建版本 → 申请测试 → 解决 Bug → 确认 Bug → 文档管理。

领取任务这一步没什么技巧，重点是每天更新。更新内容包括已消耗工时、剩余工时、任务状态和备注。备注别写「进行中」这种废话，写清楚今天做到哪、卡在哪，后面复盘时这些备注就是最好的过程记录。

创建版本是开发侧最容易被糊弄的一步。版本要关联本次提交的需求和已解决的 Bug，版本号建议跟代码仓库的 tag 保持一致。我见过团队版本号写「测试版1」「测试版2」，两个月后没人能对上哪个版本包含哪些需求，只能翻代码提交记录，那种感觉相当酸爽。

申请测试是把版本推给测试的动作，会生成一个测试单。测试单里带着这个版本关联的需求和 Bug 清单，测试人员从这里开始干活。如果测试人员说「没收到你的申请」，先确认版本有没有关联需求——空版本申请测试，测试那边看到的是空白单子。

解决 Bug 时有个解决方案字段，取值包括已解决、重复、不予解决、设计如此、延期、外部原因。这个字段看着琐碎，实际是质量分析的入口：一个月里「设计如此」占比过高，说明需求描述不清；「重复」过多，说明提 Bug 前没搜。选「已解决」时才需要填解决方案的具体说明和影响版本。

4.2 Bug 生命周期：提交、确认、解决、验证、关闭与激活

一个 Bug 在禅道里的完整路径是：测试提交 → 开发确认 → 开发解决 → 测试验证 → 关闭；验证不通过则激活，回到开发手里。这条路径上每一步都有对应字段，填错就会卡住。

提交 Bug 时要填的字段比想象中多：所属产品、所属模块、影响版本、严重程度、优先级、Bug 类型、指派给谁、抄送、关键词，以及最关键的重现步骤。严重程度和优先级是两个不同维度，严重程度描述破坏力（比如崩溃、数据错误、样式问题），优先级描述修的先后。把两者混为一谈的团队，最后所有 Bug 都是「严重且紧急」，等于没有分级。

重现步骤建议按「前置条件 → 操作步骤 → 预期结果 → 实际结果」四段写。这一步偷懒，开发就得反复问，一来一回浪费的时间远超写清楚的成本。

验证 Bug 时如果通过就关闭，不通过则激活并写清楚为什么没修好。激活这个动作在禅道里是有记录的，能看出一个 Bug 被反复激活了几次，反复激活次数是评估开发质量的硬指标之一。

找自己需要的 Bug 靠视图筛选。测试可以维护自己的 Bug 视图模块，按模块、按指派、按状态组合出常用视图。这个功能用熟了，比在全部 Bug 里翻页快一个数量级。

4.3 测试用例与测试任务：用例库、视图与执行

测试用例部分的结构是：维护测试用例视图 → 创建用例 → 管理测试任务 → 执行用例并提交 Bug → 查看报表统计。

用例视图的维护逻辑跟 Bug 视图类似，按产品、模块组织。创建用例时要填前置条件、操作步骤、预期结果，这几项跟 Bug 的重现步骤结构一致，熟练之后写起来很快。用例的价值不在写完那一刻，而在回归测试时能批量执行。

测试任务的本质是一次测试执行的范围约定：这一轮测哪些用例、在哪个版本上测、谁来测。执行用例时逐条标记通过或失败，失败的可以直接转成 Bug 并自动带上用例信息，这个联动省掉大量复制粘贴。

报表统计里比较有用的是用例执行情况和 Bug 分布。前者能看出测试覆盖率，后者能看出问题集中在哪些模块。周会上拿这两张图说话，比口头描述「这周测了不少」有说服力。

4.4 文档库三类与需求统计报表

文档管理这部分，产品经理章节里讲得比开发章节细。三类文档库的分工前面已经说过，这里补一个实操细节：文档分类是分层维护的，建之前先想好两层结构，比如「产品文档库 → 需求规格 / 接口说明 / 上线方案」，后面往里扔文档时不用每次纠结放哪。文档的三种类型里，网页型最灵活，适合写那些会持续更新的说明；文件型适合归档定稿的交付物；链接型适合指向外部系统。

需求的基本统计报表在产品视图的需求子栏目下，点「统计报表」进入。三个维度分别是产品需求数量、模块需求数量、按计划统计。我一般会在版本发布前拉一次按计划统计，看计划内的需求完成了多少，剩下的能不能赶上，比拍脑袋估靠谱。

5. 避坑与排查：五个把禅道用成 Excel 的翻车现场

工具用得顺不顺，往往不取决于功能多不多，而取决于几个关键开关有没有设对。下面五条是我在不同团队里反复见到的翻车现场，按现象、原因、解决三段写，方便直接对照。

5.1 角色与权限类：看不见、点不动、找不到

现象一：新人登录后一片空白，产品、项目列表都是空的。 原因：产品访问控制设的是私有，新人既不是产品负责人也不是项目团队成员，自然什么都看不到。很多管理员第一反应是「系统坏了」，实际是权限没配。 解决：先在组织管理里确认这个用户属于哪个用户组、有什么权限，再回产品页确认访问控制和项目团队名单。两步都过了还看不见，检查一下这个用户是不是被停用了。

现象二：需求建好了，项目里关联需求时搜不到。 原因：需求还处于草稿状态。禅道的规则是只有激活状态的需求才能关联到项目，草稿需求在关联列表里根本不出现。 解决：回到需求详情走评审，确认通过后状态变激活；或者如果这条需求确实想清楚了，在创建时就勾「不需要评审」。别在关联页面反复刷新，那不是缓存问题。

现象三：提交 Bug 时「指派给」下拉是空的，或者不知道给谁。 原因：产品的测试负责人字段没填，模块也没有指定默认负责人，系统没有兜底对象。 解决：产品维护页把测试负责人补上，人多的团队再给关键模块指定负责人。这是一次性配置，配完以后所有 Bug 都有默认落点。

5.2 流程与状态类：改了没人知道、图不动、发不出去

现象四：需求标题改了一版，开发和测试还在按旧的做。 原因：有人用「编辑」改，但编辑根本改不了标题、描述、验收标准和附件这四项，于是绕过系统在群里吼了一声；或者走了变更流程，但变更评审通过后，任务、Bug、用例三处的「确认需求变动」没人做。 解决：把规则说死——这四项只能走变更流程。变更通过后，要求关联任务、Bug、用例的负责人各点一次确认。这一条如果落不下去，后面所有的需求追溯都是假的。

现象五：燃尽图是一条几乎水平的直线，项目快结束了才突然掉下去。 原因：成员没有每天更新任务的剩余工时，或者任务压根没填预计工时。前者是习惯问题，后者是分解任务时偷懒。 解决：分解任务时强制填预计工时，日更写进站会议程，每天花两分钟更新。补录出来的燃尽图没有任何参考价值，它只会告诉你「昨天大家集体加了个班」。

还有一条边界情况值得单独记：创建发布失败，按钮点进去提示条件不满足。原因只有两个——产品没关联过项目，或项目没创建过版本。按这个顺序往前查，一定能找到断点。

6. 进阶：用字段约束和状态机把流程改成自动化校验

流程跑到稳定期之后，真正决定禅道好不好用的是字段纪律，功能多少反而是次要的。我在几个团队里试下来，最有效的一招是把「哪些字段在哪个阶段必须有什么值」写成一张核对表，每次版本发布前照着跑一遍。这张表不需要任何插件，人工核对十分钟，比事后追责有用得多。

这张表里最容易被跳过的是「需求的验收标准」和「Bug 的影响版本」两项。前者空着，测试写用例只能靠猜；后者空着，一个线上问题出来，没人能说清它是从哪个版本开始存在的。这两项都不需要额外配置，只要在提需求、提 Bug 时多写两行。

再往上一层，可以把几个字段做成检索入口。关键词字段的命名规范一旦统一，比如「端-模块-动作」，搜索就变成了按前缀筛；抄送字段用好了，需求变更、Bug 解决会自动通知到相关人，不用在群里挨个 @。这些都是零成本的自动化。

如果团队有开发能力，常见做法是调禅道开放的 REST 接口把上面那张表跑成脚本，比如拉一遍未关闭的需求列表核对阶段，或者拉一遍 Bug 列表核对影响版本是否为空。接口路径和字段名随版本有差异，写脚本前先拿一条真实数据试通再批量跑，别直接对生产环境做写操作。

# 常见做法：先用只读接口拉一条需求，确认字段名和鉴权方式再写核对逻辑 curl -s -H "Token: ${ZENTAO_TOKEN}" \ "${ZENTAO_BASE}/api.php/v1/products/1/stories?limit=1" \ | python -m json.tool

这段命令只做一件事：拿一条真实的需求记录，看返回结构里状态、阶段、验收标准这几个字段叫什么名字。参数上，Token 从个人档案的接口密钥处获取，产品 ID 换成你自己的，limit 先给 1 避免拉太多。等字段确认了，再把它扩成遍历加条件判断，比凭记忆写字段名靠谱得多。

从那以后我每次接手一个新团队，都会先把这张核对表打印出来贴在显示器边上，第一个迭代结束前强制走一遍，把不满足的项逐条补上。补完那一轮，后面的事基本就顺了。希望帮到你。

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