企业官网建设流程全解析

需求靠聊天记录确认、Bug靠群截图同步、迭代排期靠直觉拍板——这种画风在中小研发团队里太常见了。我自己前后经历过几支队伍，早期基本都是这个状态。中间也陆续试过不少工具：纯表格管理自由但失控，轻量协作看板能看任务但管不住测试，一些国外商业项目管理工具功能确实全，可对小团队来说授权费用和落地成本都不低。折腾一大圈，最后稳定用下来的反而是一套免费开源的项目研发测试管理工具——禅道。

这篇内容不打算讲系统设置里那些犄角旮旯，而是把禅道最常用的主线给你串起来：安装部署、建产品、录需求、拆任务、跑测试、看报表。适合刚接手研发管理的人、需要把测试流程纳入统一体系的团队，以及正在做工具选型又不想立刻掏钱买商业授权的负责人。读完你能照着我这套路径，在一周内把团队的实际业务搬进系统里跑起来。

1. 先搞清楚禅道到底是什么，它能帮你把哪些事从人肉记忆里捞出来

1.1 产品、研发、测试三方围着同一套数据转

禅道名字里的“禅”和“道”没有玄学含义，核心思路就是把一套完整的研发管理流落到系统里：需求从产品池出来，经过项目排期变成任务，开发完成后进入测试环节，测试发现的缺陷回到开发修复，验证通过后关闭并汇入测试报告。关键是所有角色都在这套系统里操作同一批数据，而不是各用各的表格。

产品经理在系统里维护“产品、需求、计划”，决定下一个版本做什么。项目经理创建“项目、迭代”，把需求分解成任务并排期，盯燃尽图。开发打开“我的任务、我的Bug”界面，开工、完工、自测。测试建用例库、提Bug、执行测试单、出测试报告。数据是同一套，角色不同，看到的入口和操作权限不同。

这个设计最大的价值是“留痕”。一个Bug从激活到已解决再到已关闭，每一步都记录了时间和操作人。出了问题直接拉记录，不用靠回忆去猜“这个Bug谁处理的、为什么当时被驳回”。这正是禅道和那些只能拖拽卡片的任务看板最本质的区别——它覆盖的是“研发+测试”的完整语义，不只是简单的任务卡片。

1.2 开源免费不等于功能阉割，核心链路一个不少

禅道的开源版是免费可用的。不少人对“开源”有两个极端误解：要么担心功能太弱，要么觉得有坑没人管。从我实际使用的体验来看，开源版覆盖了产品、需求、任务、Bug、用例、测试单、测试报告、统计报表、文档库这些核心链路，足够一个中小型团队完整跑起来。

商业版本在界面、资产、客户管理、多项目组合等维度有增强，但对大多数团队来说，那部分属于“有了更好”的锦上添花，不是“入门必需”的雪中送炭。对预算敏感、又希望数据由自己掌控的团队来说，开源版就是第一选择。“免费”不意味着粗糙，只是你需要自己承担部署和维护的那点体力活。

1.3 适合哪类团队？选型前先自我评估

选型这件事，最怕别人推荐什么就无脑用什么。我的经验是选型前先回答三个问题：团队有没有产品、研发、测试三种角色的明确分工？是否需要完整的“需求—任务—缺陷”记录链条？是否需要本地部署或数据自管？三个答案如果都是肯定的，禅道这类一体化开源工具就非常值得试。

这个表格是我实际给团队做选型时常用来对照的。把“想要什么”和“付得起什么”放在一起，比单纯比较功能列表更接近真实决策。

2. 安装部署这条最陡的坡，怎么最快趟过去

2.1 本机试跑阶段：用一键安装包最快

很多人一看“部署”两个字就头大，其实禅道入门阶段的部署是我见过的开源项目里少有的傻瓜级。在Windows机器上，官方提供一键安装包，内置PHP运行环境和数据库，不需要单独安装任何依赖，解压就能跑。

具体步骤：

1. 到官网下载最新版一键安装包，解压到纯英文路径，比如D:\zentao或C:\apps\zentao。路径里尽量避免中文、空格，否则服务脚本在小概率情况下会异常。
2. 双击启动程序，等命令窗口提示服务已启动。
3. 浏览器访问http://127.0.0.1:端口/，端口就是启动窗口里显示的那个。
4. 按安装向导设置管理员账号密码，确认数据库信息，初始化完成。

这段路我实测下来十分钟以内能走完。建议新手先在本机把整套流程玩明白，再谈迁移到服务器。如果本机80端口已经被占用，就在配置里换个端口，不用死磕默认值。

2.2 正式环境：用容器方式部署最省心

本机跑通之后，正式环境我推荐用Linux服务器加容器化部署。好处是环境隔离、升级和回滚方便、数据目录可以持久化到宿主机。基本思路是把容器的数据目录挂到宿主机路径下，后续升级、迁移、备份都围绕这个目录来操作。

一个简化版的部署过程是：先在服务器上安装容器运行时，然后拉取禅道官方镜像，运行容器时指定端口映射和数据目录挂载：

docker run -d \ --name zentao \ -p 8080:80 \ -v /opt/zentao:/app \ --restart always \ zentao

提示：不同大版本的镜像名称、内部目录结构可能有差异，具体以禅道官网发布的镜像说明为准。

跑起来之后，建议通过反向代理配置域名和HTTPS，不要直接把裸端口暴露到公网。这一步不是一两天内必须做的，但从安全和长期维护角度考虑，值得尽早搞定。

2.3 装完别急着拉人进来，先做完两件事

部署完成、能登录之后，有两件事我每次都会立刻做，新手可以直接抄走。

第一，删除或停用演示账号，修改管理员默认密码。拉同事进来之前，安全边界先划好，避免系统带着初始口令暴露在内网里。

第二，配置自动备份。禅道的数据分两处：数据库和附件目录。附件包括需求描述图片、测试截图、项目文档等，丢了很难补。最朴素但也最稳的办法是用系统计划任务每天凌晨备份数据库文件和附件目录，保留最近30天的副本。备份这件事没什么技术含量，但当你误删了一个需求或一批用例时，它就是整个系统里最重要的模块。

3. 建产品、拆需求、派任务：一条研发主线跑通才算入门

3.1 先把产品和需求建起来

进入系统后，第一个动作不是建项目，而是先建“产品”。产品是长期存在的业务载体，比如“模拟项目X-商城Web端”，后续所有需求都在这个产品下累积。产品下可以继续维护产品模块、版本计划、需求池。

产品建好后，在“产品-需求”里录入需求。一份合格的需求不能只写一句话，至少要包含用户场景、业务价值、验收标准。比如“用户下单后可以查看历史订单”，应该补上“在个人中心新增订单列表，展示订单号、金额、状态，支持按时间筛选，字段以数据库订单表为准”。验收标准写得越具体，后面开发和测试就越省力。

新建的需求默认是草稿状态，走完评审、变为激活之后，才能被项目迭代关联。很多人跳掉评审直接干活，短期看是省时间，长期会积累大量“做完发现不是要的那个”的情况。哪怕评审只是口头过一遍，也建议在系统里留一条评审记录，后面追溯需求变更时会非常有用。

3.2 产品、项目、迭代、任务，别被这四个词绕晕

这是入门时最容易被概念卡住的地方。我的理解很简单：产品装需求，项目装迭代，迭代装任务。

产品是长期不变的业务载体。项目是为一个特定目标发起的临时组织，可能是“某商城2.0重构”，也可能是一系列小迭代打包。迭代是项目里的时间盒，通常1到4周一个，团队在迭代内交付一批功能。一个产品可以对应多个项目，一个项目可以有多个迭代，一个迭代又包含多个任务。

举个例子：产品是“模拟项目X”，项目是“模拟项目X三期”，迭代是“三期-迭代1”，这个迭代里关联了“用户登录改造”和“订单列表分页”两个需求，再分别拆成任务分给具体的人。这一层想明白了，后面所有操作都不会迷路。

3.3 任务拆得多细才算合适？我的两条判断标准

任务分解没有标准答案，但有两把尺子我建议直接用：一个任务能不能在1到2天内完成，一个任务有没有可验证的完成结果。满足这两条，粒度就基本到位。比如“开发登录功能”这种任务，明显要拆成“登录接口设计”“前端登录页面”“登录联调与自测”等多个子任务，不然排期和进度根本说不清楚。

每个任务我建议满足三条硬要求：明确指派到某个人，不允许出现“所有人”；填好预计开始日期和截止日期；填写预计工时。前两条保证进度可追踪，第三条保证燃尽图和工时统计有意义。我见过不少团队任务建了一堆，日期和工时全是空的，最后报表成了一张死图。这不是工具的问题，是维护数据这个动作没有跟上。

4. 测试管理不学会白用：用例库、Bug流转和测试报告怎么衔接

4.1 用例库要按产品层级维护，别等项目来了再补

禅道的测试模块里，“用例库”是最容易被低估的存在。很多团队项目上线才想起来建用例，结果只能靠记忆补记录。正确做法是在产品层级维护用例库，按模块或功能点组织，每个用例写明操作步骤、输入数据、预期结果，并尽量关联到对应需求。后续每个迭代都可以复用和扩展这套用例。

用例不是只给测试自己看的。开发提测时要清楚自己写的东西要满足什么预期，项目经理验收时也需要一份可勾选的验证清单。把用例库维护好，等于给团队建立了一份不断累积的质量资产池。前期投入确实有点枯燥，但每多跑一个版本，它的价值就多显现一分。

4.2 Bug流转是一台状态机，谁也别绕过它

禅道的Bug字段不少：标题、所属产品、所属模块、影响版本、严重程度、优先级、指派人、解决方案等。入门阶段不必每条都较真，但有两组概念要先吃透：严重程度和优先级。严重程度描述影响范围，优先级描述处理顺序，两者并不等价。比如“界面按钮颜色不对”，影响范围有限但用户天天看，优先级可能很高；而“数据库偶发超时”，影响严重但发生频率低，优先级可能排在核心功能之后。

Bug的状态流转就是一条闭环链路：

这条链路最怕两件事。一是测试绕过系统，发现的问题直接私聊发给开发，等于在系统外开辟了信息黑洞。二是开发“单向关闭”Bug，写了句“本地没问题”就标记解决，不给测试验证的机会。只要团队约定：所有问题先进系统，所有关闭必须经过测试确认，Bug链路就能站稳。

4.3 测试单和报告：把提测、回归、结项串成证据链

用例库有了，Bug流转正常了，最后要用“测试单”把一次次测试活动串起来。每当一个版本提测，测试人员创建测试单，选择当前版本、关联用例集和测试执行人，然后按用例逐条执行、记录结果。执行过程中发现的异常直接转成Bug，关联到测试单里。

全部用例执行完后，产出测试报告，写明执行用例数量、通过率、未解决Bug数量和是否建议发版。这份报告不是走形式，它是“这个版本能不能上线”的核心依据。有了这套证据链，项目总结会上就不必靠争论来定结论，打开系统看测试单和报告，事实就摆在那里。这也是禅道把“项目研发测试管理”集成到一套系统里的核心价值。

5. 别一上来就改流程：权限、自定义与报表的正确落地顺序

5.1 先用默认流程跑满两个迭代，再谈自定义

禅道的默认流程内置了一套标准研发管理模型：需求评审、任务分解、提测、Bug处理、测试报告。刚接手的团队，我强烈建议先按默认流程原样用起来，不要急着改字段、改状态、改审批链路。很多人想一步到位设计一个“完美流程”，结果连续改了一周分支规则，后续升级排查全是坑。

更好的节奏是：先把默认流程完整跑起来，至少跑两个迭代。在这个周期里，把“哪里不顺手、哪里字段不够、哪里步骤缺失”记录下来。两个迭代结束后，针对真实痛点做最小化调整。流程是长出来的，不是设计出来的。见过太多团队把系统配置改得花团锦簇，真实项目却一次都没完整跑通过，纯属本末倒置。

5.2 权限组怎么分：围绕“谁动谁的数据”划边界

权限设计的原则是：谁产出数据，谁是最终负责人，谁就拥有对应模块的编辑权限。我的习惯是分四类角色：

• 系统管理员：处理全局配置与安全，不改业务数据。
• 产品经理：管理产品、需求、计划与需求评审。
• 项目经理：管理项目、迭代、任务和项目统计。
• 开发与测试：各自处理指派给自己的任务和Bug，测试额外维护用例库和执行测试单。

不要图省事把所有人塞进“项目负责人”角色。权限越清晰，团队越会认真维护自己的数据。反过来，如果谁都能改一切，出了问题第一反应是互相推诿，数据很快也会变脏。权限不是约束，是责任的清晰化。

5.3 报表要看，但要警惕“漂亮数据”

禅道自带一些实用报表：迭代燃尽图、任务完成率、Bug按模块分布和严重程度统计、项目进度概况等。这些报表能让你一眼看出迭代是否健康。但我见过不少团队把报表用于过程汇报，数据源却完全没有维护，结果报表就成了开美颜滤镜。

最典型的是燃尽图。它依赖任务剩余工时和日期字段的持续更新，只要有人两天没更新剩余工时，曲线就会突然跳跃，整个趋势不可信。我的建议是每周至少安排一次统一的“工时回填”时间，所有成员把任务状态和剩余工时一次性更新到位。报表不是给领导看的表演，是给团队自己定位问题的工具。

6. 我实际用下来最想提醒的几个坑

6.1 沟通语言立刻切换到“编号加系统词汇”

系统上线后最大的坑往往不是功能不会用，而是团队仍然在聊天软件里用模糊词沟通：“那个登录的Bug你改一下”“上回说的那个需求呢”。一句“那个”，等于在系统外重新开了一条信息流，数据不回到系统里，统计立刻失真，责任边界也跟着模糊。

我的做法是立规矩：沟通中涉及需求和缺陷，必须带上系统编号，比如“需求 STORY-123”“Bug BUG-456”。这个规矩看起来很机械，但它会让对话强制对齐到系统数据上。坚持两周后，你会发现追踪进度和评理的次数都少了很多。系统里的编号，本质上是团队的共同语言。

6.2 日期字段别闭着眼睛填，它会反过来咬你

排期时随手填一个完成日期，结果当天没做完也不更新，任务还挂着“进行中”。这看着是小事，但三周后打开燃尽图，会发现整段进度都不可信。日期不是给领导看的装饰，是团队给自己的信用记录；燃尽图说谎，排期的威信就没了。

我的维护习惯很固定：创建任务时认真填预计开始和截止日期；每周五做一次集中维护，任务做完就标完成，没做完就更新日期和剩余工时；遇到跨迭代的情况，直接在任务备注里写明原因。这样月底结项时，数据才经得起复盘。这套习惯不需要什么工具技巧，靠的是团队共识。

6.3 通知配置不到位，流程再标准也等于摆设

流程设计得再合理，如果指派了任务却没人知道，一切等于零。入门阶段最值得花时间的通知是邮件：任务被指派、Bug被指到、需求状态变化时，系统自动发邮件给相关人员。很多人一上来就研究各种花哨集成，其实邮件通知跑通以后，团队的响应速度就已经明显不一样了。

注意：没有触达的流程，只是一张好看的流程图；通知不是骚扰，是流程的触达机制。

我的建议很直接：先把邮件配置跑通，确认能正常收到通知，再考虑即时通讯集成这类进阶选项。我见过不少团队把时间花在钻研集成上，结果连最基本的“被指派时收到提醒”都没做到，流程自然变成了空转。

最后聊点个人体会。工具能解决的是可见性问题，解决不了执行力问题。禅道让我最舒服的一点是，它把“产品在做什么、开发做到哪一步、测试卡在什么问题”这件原本要靠开会才能说清的事，变成了打开系统就能看到的实时事实。最初一个月大家都会嫌填需求、填工时、走流程麻烦，可当你第一次在结项会上面对真实数据，能清楚说出每个功能是谁做的、做到什么程度、为什么延期时，就会明白前期那点维护成本换来了什么。我的建议一直很朴素：别想着把流程设计得完美再开始，先用默认流程跑起来，跑两个迭代，再根据团队的胃口慢慢调。工具不是管理本身，但它确实是那双把管理托上台面的手。