企业官网建设流程全解析

简介：禅道使用手册（完整版）是一份面向项目经理、产品经理、开发及测试人员的系统性操作文档，适用于落地禅道时的项目创建、任务分配、需求评审和缺陷跟踪。资源为单份Word文档，共1个docx文件，压缩包仅4.02MB，下载后按目录即可查阅，轻量且便于随时搜索。内容涵盖基本介绍、用户角色与登录、个人待办、我的任务/我的Bug管理等基础操作，同时完整展开产品经理视角的产品维护、需求创建与评审、需求变更与状态管理，以及项目经理视角的建立项目、组建团队、任务分解和燃尽图掌握项目进展等核心流程，结构清晰，适合从入门到进阶逐步学习，也可在遇到具体环节时直接定位对应章节。该资源已有5205人学习浏览，可帮助项目团队减少上手踩坑时间，更规范地把禅道融入日常研发与项目管理。

1. 禅道使用手册在解决什么：从“需求在群里”到“需求有编号”

团队规模一大，需求管理最容易翻车。产品说“这个需求大概就这样改一下”，开发听了点头，测试按自己的理解写用例，上线时才发现三个人理解的是三个版本。禅道使用手册要解决的，正是从“需求靠群里聊天记录传递”到“每个需求有编号、有状态、有负责人”的转变过程。它把产品、项目、迭代、任务、Bug全部收进一套可追踪的流程里，适合几十人规模、已经在用或准备引入禅道的团队。如果你正负责推进这套工具的落地，下面这些部署、配置和踩坑经验可以直接照着用。

2. 禅道部署与初始化：内网安装包到第一个项目跑通的全过程

很多人会卡在第一步：禅道到底该用哪种部署方式。坊间教程很多，推荐 Docker 的有，推荐源码包的有，推荐一键安装包的也有，但选型不看你喜欢什么，看你的团队有没有运维资源、服务器在哪、数据要放哪。这一章把部署选型和初始化一次讲透。

2.1 部署方式选型：一键安装包、源码包、容器镜像该选谁

先看三种常见方式的适用边界，我整理了一张选型表，照着选比听别人建议靠谱：

我一般会建议：小于 50 人、没有专职运维的团队，直接选一键安装包。它把 Web 服务、PHP 解释器、MySQL 数据库全部打进一个目录，解压就能跑，后续升级也走官方脚本，风险最小。已经有 K8s 或者 Docker Compose 规范的团队，才值得考虑容器方式，因为数据卷、备份、网络方案都要自己补，前期的坑不少。源码包部署，除非公司安全部门明确要求逐版本审计依赖，否则不建议自己给自己找事。

版本选择上，有一个血泪经验值得记下：不要一上来就追最新版。禅道的数据结构跨版本偶尔有调整，新版本发布后的前一个半月，社区里往往能搜到一批更新报告；选上一个稳定大版本的最新补丁号，比尝鲜新版稳妥得多。部署前先确认服务器时间同步正常，否则后续登录和操作记录的时间线会乱掉。

2.2 内网部署的最小步骤：解压、启动、初始化一套走完

以 Linux 一键安装包为例，最小可运行步骤只要三步。下载安装包这一步，从禅道官网拿对应架构的 tar 包，_x64 后缀对应主流服务器，ARM 架构的机器要单独选 ARM 包。

# 1. 解压禅道 Linux 一键安装包到指定目录，这里以 /opt 为例 tar -zxvf zentao_xxx_linux_x64.tar.gz -C /opt # 2. 进入解压后的目录，zbox 是禅道自带的集成服务脚本 cd /opt/zbox # 3. 启动服务，默认占用 80（Apache）和 3306（MySQL）端口 ./zbox start # 4. 检查运行状态，看到 Apache 和 MySQL 都处于 running 再继续 ./zbox status

步骤说明：第一条命令把整个运行环境解压到 /opt，目录结构里 zbox 目录就是服务控制中心；第二步和第三步启动的是禅道自带的 Web 服务和数据库，不依赖服务器上已有的 Nginx、MySQL，这也是为什么一键包适合没有运维的团队；第四步是确认状态，有些服务器上 80 端口被系统自带的 Nginx 或 Apache 占住，zbox 启动会失败，这时两个选择——停掉系统自带服务再启动 zbox，或者按官方文档给 zbox 换一个端口。

内网搭建的场景，这一步经常遇到端口冲突。我见过最典型的翻车是服务器上已经跑了 Nginx 站点，zbox 起不来，有人直接把 Nginx 停了，结果其他业务也跟着挂。稳妥的做法是给禅道换端口，比如换成 8080，然后在内网防火墙放开这个端口。换完端口后，日志文件里搜listen能找到实际生效的监听地址，确认监听的是 0.0.0.0 而不是 127.0.0.1，否则同事访问不到。

服务起来后，浏览器访问http://服务器内网IP:端口，会进入安装向导。安装向导要求设置数据库连接信息和管理员账号，这里注意：数据库密码不要留空，管理员账号不要用 admin/admin 这类默认口令；安装界面里填的数据库库名、账号、密码会自动写到禅道的配置文件里，填错只能改配置文件重新来，没有后悔药。

2.3 组织架构与项目初始化：产品、项目、执行三层要一次建对

禅道里最容易被忽视的是“产品-项目-执行”三层结构，很多人第一次用会问：产品和项目有什么区别，为什么不能直接建一个项目往里扔需求？

三者的关系是这样：产品是需求池，是长期存在的；项目是围绕一个或几个产品组织的一次性交付周期；执行（在敏捷项目里叫迭代，在瀑布项目里叫阶段）是项目下面具体排任务的单元。需求先提到产品里，经过评审后关联到项目的执行下，再拆成任务派给开发。这个链条一开始建反了，后面所有报表都会乱。

初始化时建议按这个顺序操作：

1. 在产品页面创建产品，产品负责人选产品经理，访问控制选默认即可。
2. 在项目页面创建项目，项目类型按团队实际节奏选敏捷或瀑布；如果团队已经在按两周一个迭代跑，选敏捷，执行就是迭代；如果还是按阶段推进，选瀑布。
3. 在项目中关联产品，这样产品里的需求才能进入项目的迭代。
4. 在项目的成员列表里添加开发、测试、项目经理，注意这里每个项目都要单独加人，没有全局自动继承。

参数设置上，有一个字段值得单独拿出来说：项目关联产品时，有个“项目关联的需求状态范围”选项，默认可能只关联激活状态的需求。如果团队希望把草稿需求也拉进项目排期讨论，要在这里放宽范围，否则产品在需求池里提了草稿，项目里根本看不到。

另外，内网搭建的团队注意一个细节：禅道默认的管理员账号在安装完成后应该尽快在后台“权限”里拆分成多个账号，按角色分配权限。不要所有人都用管理员账号登录，后面操作日志没法追溯，这一点到第 4 章的权限避坑里还会再展开。

3. 需求、任务、Bug 三条主线的流转规则与字段参数

禅道使用手册里最核心的内容就是这三种对象的流转规则。需求、任务、Bug 各自有生命周期，状态之间怎么跳、字段要怎么填，直接决定团队能不能坚持下去。

3.1 需求生命周期：评审开关决定了需求能不能直接开工

需求在禅道里有完整的生命周期：草稿、激活、已变更、已测试、已交付、已关闭。大多数团队只用到其中两三个状态，但没有理解“草稿到激活”这个节点的重要性。

创建需求时，有一个关键选项是“是否需要评审”。选“不需要评审”，需求保存后直接进入激活状态，开发立刻可以看到并开始排期；选“需要评审”，需求保持在草稿状态，产品经理确认后进入评审流程，评审通过才激活。我见过团队为了省事把所有需求都设成免评审，结果是需求描述里只写一句“参考旧系统”，开发排期时全靠猜，评审成本从需求阶段挪到了开发阶段，翻车概率更高。

建议的设置方式是：产品经理创建的需求一律走评审，由项目经理或技术负责人确认范围；其他角色创建的需求默认免评审，但需要在描述里写清楚背景和验收标准。这里分享一个字段填写的细节：需求描述里的“验收标准”不要和“需求背景”混在一个自然段里，单独列成条目。禅道需求详情页支持富文本列表，验收标准越结构化，测试在写用例时越不会漏场景。

需求激活后还有一个状态容易踩坑：“已变更”。当需求被修改并重新评审后，状态会从激活变为已变更，开发任务里如果没有对应记录，很容易出现代码按旧需求写了一半、新需求已经变更的情况。处理办法是要求项目经理在每周迭代计划会上同步一次所有“已变更”状态的需求，评估变更对排期的影响，再决定是继续开发还是调整计划。

3.2 任务的分解与工时字段：别把“预计剩余”填成“已经花掉”

禅道里任务挂在执行（迭代）下面，有类型和状态两个维度。类型一般有设计、开发、测试、研究等；状态有未开始、进行中、已完成、已关闭。大部分团队真正用不好的不是状态，而是工时字段。

每个任务有三个工时字段：预计工时、消耗工时、剩余工时。很多人把“剩余工时”填成了“这个任务总共要多少工时”，还有人把“剩余工时”填成“已经花掉的工时”，这会让迭代燃尽图完全失真，曲线变成一条没有规律的折线。我的做法是在项目启动时给团队做一次 10 分钟的字段口径说明：预计工时是接任务时的初始估算；消耗工时是每天实际投入的累计值；剩余工时是当前这一刻起、到任务完成还需要的小时数，这个数值每天更新，趋势才对。

任务拆分的粒度同样影响数据质量。一个开发任务如果超过 3 个工作日，就应该拆成设计、开发、联调多个子任务；如果拆完还是超过 3 天，说明任务本身定义得太大，要继续拆。拆到 0.5 到 3 天一个任务，每日站会更新剩余工时才有意义。任务字段里还有一个容易被忽略的“指派给”，任务创建后默认指派给当前用户，但很多团队建完任务忘了改指派人，导致任务列表里一堆“由本人负责”的未完成任务，项目经理看板根本看不出真实负载。

3.3 Bug 流转与严重程度：为什么严重级别不能全选“一般”

Bug 的生命周期相对清晰：激活 → 已解决 → 已确认 → 已关闭。提交 Bug 时，字段里有严重程度（1 到 4 级）和优先级（1 到 3 级）两个容易混淆的概念。严重程度描述的是影响范围，优先级描述的是修复顺序；一个严重程度为 3 的文案错别字，如果正好卡在发版通知里，优先级可以很高；一个严重程度为 1 的系统崩溃，但如果只发生在十年前的老浏览器上，优先级反而可能排到后面。

实际使用中，测试人员倾向于把所有 Bug 的严重程度都选“一般”，因为每一条 Bug 看起来都重要。这会导致项目经理排修复计划时没办法排序，只能逐个点开详情看内容。解决方法是限定严重程度的使用规则：1 级留给系统完全不可用或核心流程崩溃；2 级留给主要功能有缺陷、但有临时绕行方案；3 级给一般功能问题；4 级给界面文案、样式等优化项。测试提交时不允许选“默认值”，必须逐条明确。

Bug 和产品、需求的关联也建议约定好。和某个需求相关的 Bug，应在详情页里关联对应的需求 ID；和某个迭代版本相关的 Bug，应确认其所属产品是否和项目关联一致。做这一步的意义是报表统计——后期想查“哪个模块的 Bug 最多”“哪个需求的 Bug 集中爆发”，靠的就是这些关联字段。省掉关联，等于放弃了禅道最有价值的统计分析能力。

4. 禅道使用中的 5 个翻车现场与排查：邮件、报表、流程三块重灾区

用了半年禅道的团队，多多少少会遇到下面几个问题。这里按“现象 → 原因 → 解决”写，每一条都是实际维护中的高频场景，对照排查能省不少时间。

4.1 邮件通知全部失效：25 端口被封之后怎么办

现象：后台配置了 SMTP 发信参数，测试邮件能发出去，但成员收不到任务指派通知、需求变更通知。

原因：很多服务器对外的 25 端口被运营商或安全组限制，测试发信走的是本机回环，真实外发时连接被中断。内网搭建的禅道服务器更容易中招，因为内网环境通常没有邮件中继，直接走公网 SMTP 容易被限。

解决：禅道后台的消息通知里，把 SMTP 端口改成 465（SSL）或 587（TLS），并在邮箱服务商处开启对应授权码；同时确认发件邮箱的域、账号、密码正确。如果公司有 Exchange 或内网邮件服务，优先配置内网发信地址，避免流量出网。实在没有邮件服务，可以改用后台“通知”里的 Webhook 方式，把任务指派消息推到团队群机器人。

4.2 自定义工作流删了默认状态：历史需求找不到出口

现象：管理员觉得默认的“已解决”“已关闭”状态名称不好理解，在后台把状态名改了，或者删掉了某个默认状态，几天后发现这个产品下的所有需求都卡在“激活”，无法流转。

原因：禅道支持工作流自定义，但它不建议删除内置状态。内置状态的名称和流程里的判断逻辑是绑定的，删掉或改名后，历史数据以及报表统计口径都会出问题。

解决：进入后台工作流设置，检查被删除或改名的状态，恢复默认状态名；如果要增加团队自己的状态（比如“待验收”），用“新增状态”而不是“修改内置状态”的方式实现；改完状态后，在需求列表页筛选一次历史数据，确认所有需求的状态都有对应出口。

4.3 报表工时对不上：预计、消耗、剩余三个字段的口径混淆

现象：迭代看板上的剩余工时曲线忽高忽低，周五还显示剩余 80 小时，周一变成 120 小时，燃尽图完全没法解释。

原因：成员把“剩余工时”理解成“任务总共需要的工时”，每天更新时直接把初始值填了一遍；也有人把“消耗工时”和“剩余工时”填反了。

解决：在项目页面的“团队”中，给每个角色配置工时字段的可见性和必填性，开发只需要每天更新“消耗工时”和“剩余工时”；每周五例会前，项目经理用报表里的“工时统计”筛一次数据，把剩余工时超过 40 小时的任务打回给对应成员重新估算。口径统一两次迭代后，燃尽图基本就能看出规律了。

4.4 内网断电之后数据库损坏：备份周期没设等于裸奔

现象：机房一次意外断电，重启后登录禅道白屏，页面提示数据库连接失败，检查 MySQL 日志看到表损坏。

原因：MySQL 在非正常关机下缓冲区数据没有落盘，导致索引或表文件损坏。内网搭建的服务器往往没有 UPS，断电概率更高，而多数团队部署完根本不会打开备份功能。

解决：进入后台“系统 → 数据备份”，开启自动备份，周期设为每天一次，保留最近 7 天的备份；备份文件存储在服务器的数据目录里，建议再写一个定时任务把备份文件同步到另一台机器。遇到数据库连不上的情况，不要反复重启，先尝试从最近一次备份恢复，恢复后检查那一天的动态记录，确认数据缺口。

4.5 人人都是管理员：权限分配太省事带来的数据风险

现象：为了让开发能自己建任务、关 Bug，直接给整个项目组分配了“管理员”角色，结果有人不小心关闭了整个执行下的所有历史任务，还有些人删掉了旧的迭代记录。

原因：禅道的权限模型是分层的，后台有产品、项目、执行（迭代）、产品模块多个层面的角色。“管理员”的含义是某个范围内的全权管理，而不是“能干活的人”。

解决：后台“权限”里按角色分配权限模板——产品经理给产品相关权限，项目经理给项目和执行的关联权限，开发和测试只给任务和 Bug 的编辑权限；每个项目单独配置项目成员和项目管理员，不要把后台管理权限放给普通成员。刚开始配权限会花十几分钟，但相比数据被误删后的一周返工，这点时间很值。

5. 每周花 30 分钟的禅道健康度检查：三个必看指标和一个汇报动作

禅道部署了、团队用了，不代表项目健康。我习惯每周花半小时做一次数据巡检，发现苗头尽早干预。下面是三个常用指标，配合禅道自带统计功能就能查。

第一个指标看需求池是不是在膨胀。需求激活后长期没有进入迭代，说明产品经理在持续提需求，但项目经理和开发没有把优先级对齐。第二个指标看出排期真实性，如果逾期任务超过三成，多半是任务拆得太大或者剩余工时没更新。第三个指标看测试和开发协作效率，Bug 平均修复时长一旦超过 5 天，说明流程中的某个环节在积压，通常是测试环境部署慢或者开发在忙新功能顾不上修。

具体操作是：登录禅道进入“产品 → 需求统计”和“项目 → 统计”页面，把两个页面的报表截图存一下；再进“测试 → Bug 统计”，按严重程度查一下最近两周的解决时长分布。全部过程不到 20 分钟，剩下的时间花在判断要不要调整。

每周的项目例会，我建议把禅道统计页共享到屏幕上，不用做 PPT，实时点开“项目视图 → 执行 → 看板”，对照迭代燃尽图过一遍：已完成的任务是否匹配当初承诺的需求范围，剩余工时趋势是否往下走，挂起任务有没有超过三天。让禅道里的数据和会议讨论对齐，团队成员会慢慢形成习惯——每天下班前花两分钟更新剩余工时和任务进度，因为它会被真实地讨论，而不是填完就没人看。禅道也提供了 AI 协作相关的 MCP 接口方向，适合基础流程稳定后做拓展；但我的经验是，先把数据喂准再谈自动化，数据不准，再多接口都白搭。希望今天这篇手册，能帮你少踩几个我当年踩过的坑。

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