私有化部署项目管理软件新手入门指南：一周跑通需求到交付

私有化部署项目管理软件这件事，卡点通常不在安装。真正麻烦的是装完之后的两周：登录人数从 30 掉到 5，需求还在群里同步，进度还在周会上口头汇报，系统里躺着一批没人维护的空壳任务。

顺序反了是主要原因。不少团队把装完当成终点，装完才开始讨论谁来填、填什么、什么时候算完成。等这些规则谈清楚，最初的热情已经用完了。

这份指南换一个顺序：先把范围压到一个真实项目上，用 7 天跑通一条从需求到交付的完整链路。每天做什么、谁做、做到什么程度算完成，都可以按下面逐条对照。

一周跑通的五个前提

这些事在动手之前定完，后面七天会顺很多。它们不涉及技术细节，但缺一项就会在第三天开始返工。

先定试点项目与负责人

试点的选择决定这一周能不能收住。挑一个两周内本来就要交付、需求数量在 10 条上下、跨部门依赖少的真实项目。不要用演示项目，演示项目没人有压力，跑出来的流程也经不起真实需求验证。

负责人要明确到一个人，并且这个人有权修改流程规则。多个人共同负责，等于没人负责。

部署方式按团队能力选

禅道的安装方式不止一种，官方文档列出过一键安装包、源码包安装、容器化部署，以及智能应用平台的一体化安装模式。选哪种，取决于你团队里有没有人能处理服务器和网络。

下面这张表按上手门槛排列，方便你对照自己的情况做取舍。

门槛只是相对说法，不是绝对判断。首次私有化部署建议从门槛较低的方式开始，先让团队用起来，再谈架构优化。如果只是先验证流程，选禅道开源版做私有化部署就够用；后续需要更细的权限与组织管理，再评估企业版或旗舰版。

环境配置别照搬网上的文章。以官方文档给出的最低配置为起点，生产环境按并发人数和数据量上调。具体版本、端口与硬件要求以官方最新说明为准，不同版本之间会有差异。

环境、依赖与账号先备齐

服务器之外还要准备三样东西：可从内网访问的域名或 IP、用于发送通知的邮箱服务，以及一份账号清单。

账号清单越早整理越好。按姓名、部门、邮箱、角色四列列出试点成员，部署完直接批量建号，不要在系统里一个一个手动加。安装包和相关资料统一从官方渠道获取，下载页面会标注各版本支持的运行环境。

网络访问范围先画清

私有化部署的一个常见误解，是"装在内网就等于安全"。真正要先回答的是：谁能访问、从哪里访问。

• 只允许办公网访问：配置简单，但出差和居家办公的成员用不了
• 需要外网访问：走 VPN，或在网关做反向代理并启用 HTTPS
• 生产网与办公网隔离：提前确认跨网访问策略，别等部署完才发现连不通

把答案写下来，交给负责网络的同事确认。这个决定会影响证书、域名和后续的升级方式。

备份与回退在上线前演练一次

这一条最容易被跳过，也最容易在出问题时让人后悔。

上线前做完三件事：确认备份任务已开启并有明确频率；手动执行一次备份并记下文件位置；在一台非生产机器上尝试恢复一次。恢复没验证过的备份，约等于没有备份。

再约定一条规则：升级版本或调整流程之前先备份。私有化部署的运维责任在企业自己身上，版本升级、数据库变更都要有明确的负责人。

用 7 天跑通需求到交付

把一周拆成四段，每段都有明确产出。下表是整体节奏，后面逐段说明动作和完成信号。

每天在系统上的操作时间控制在 30 分钟以内，超过这个量，通常说明字段或流程设计过重。

第 1–2 天：部署上线，用真实项目搭好结构

部署完成不等于系统可用。按下面的顺序验证：

1. 内网任意一台机器用浏览器打开访问地址，页面完整加载，静态资源正常
2. 管理员登录后能成功新建一个普通成员账号
3. 用新账号登录，能看到自己该看到的项目，看不到不该看到的内容

三条都通过，才算部署完成。只打开了登录页不算。

接着用禅道的四个核心管理结构落地：产品、项目、执行、项目集。第一周的建议是产品承载需求来源，项目承载这一周的交付目标，执行承载迭代，项目集先不启用。等有第二个并行项目时再打开项目集。

权限先只分三类：管理员、项目负责人、普通成员。按部门逐个铺权限的做法，留到试点结束以后再说。

完成信号：试点成员全部登录过一次，并且能看到试点项目。

第 3–4 天：需求进池，再拆成可执行任务

这一步的成败取决于"搬多少"。目标是 8 到 15 条需求，不是把积压半年的需求全导进去。搬得越多，越容易在第一周就放弃。

需求池用来放还没想清楚要不要做的原始需求，确认要做的再流转为正式需求。判断标准可以简化成一句：这条需求如果这一周不做，会不会影响交付。不会的，先留在需求池里。

每条需求至少带五个字段：标题、提出人、期望结果、优先级、验收标准。其中验收标准最值得多花时间。写"完成开发"没有意义，写到可验证才有意义——比如接口联调通过、测试用例全部通过、相关文档同步更新。

需求评审的完成信号是状态推进到已评审，并且每条都有人认领。没人认领的需求，说明它其实不在这一周的范围里。

拆任务时守住两条线：一条需求拆 1 到 3 个任务，单个任务不超过 2 天。任务粒度太粗，进度就看不出来；太细，维护成本会超过收益。每条任务都要有负责人、截止日期和完成标准，这三项缺一个，任务就只是待办事项。任务视图怎么组织，可以参考任务管理的常见做法，但必填字段能少则少，先保留三到五个。

完成信号：打开任意一条需求，下面挂着任务，每个任务都有负责人和截止日期。

第 5–6 天：进度可见，缺陷闭环

这两天要建立的是每天的固定动作。建议每天用 10 到 15 分钟站在看板前过三件事：昨天完成了什么、今天做什么、哪里卡住了。

卡住的事必须登记成条目，写清等谁、等什么、期望什么时候有结果。口头提一句不算，口头信息不会进入系统，第二天也没人追溯。

测试环节的重点不是修得多快，而是让每个缺陷都走完完整路径：提交（附复现步骤和测试环境）、指派、修复、回归验证、关闭。测试发现的缺陷要挂在被验证的需求或任务上，这样交付前能一眼看清这条需求还剩几个未关闭缺陷。缺陷的生命周期可以参考测试管理里的默认流程，也可以在试点结束后按团队习惯调整状态。

完成信号：这几天产生的缺陷全部有提交人、复现信息和当前状态，没有只存在于聊天记录里的缺陷。

第 7 天：交付验收，并判断是否真的跑通

交付当天要产出两样东西：一个可交付的版本，一份需求清单——哪些做完、哪些没做、没做的原因是什么。清单比版本本身更重要，它是下周计划的基础。

判断这一周是否真的跑通，看下面五项。

五项里如果"状态真实"不达标，其他四项的意义都会打折。系统状态和现实不一致时，团队很快就会回到群里同步，工具随之被晾在一边。

四类高频卡点与处理

部署完成但同事打不开

按顺序排查：先从服务器本机访问，确认服务本身正常；再从同一网段的其他机器访问，确认不是单机问题；最后检查防火墙规则和反向代理配置。跨网段或跨区域访问失败，问题通常在网络策略，不在软件本身。

字段太多，没人愿意填

这是第一周常见的失败原因。判断方法很直接：让一位成员实测一遍，从打开任务到填完必填字段并流转状态，如果需要反复停顿、翻资料才能填完，字段就该砍。

每个字段都要能回答三个问题：谁来填、什么时候填、填错了谁会受影响。答不上来的，先删掉。

需求太大，一周拆不完

不要为了凑完整而硬拆。把这条需求放回需求池，换一条更小的进来。第一周的目标是跑通流程，不是清空积压。等团队熟悉了节奏，再处理大需求。

权限开太大或收太紧

开太大，等于放弃了私有化部署在权限控制上的价值；收太紧，成员因为看不到相关信息而绕开系统。试点阶段用最小可用权限，按角色给，不按个人给。等流程稳定后再细化。

一周之后：从试点到常规节奏

第一周结束时，系统的价值只体现在一个项目上。接下来要做的，是把这套节奏固化成习惯。

复盘时看三个问题：哪些字段从来没人看，哪些状态从来没被用过，哪一天大家在系统上的操作时间最长。前两个是该删的，第三个通常指向一处设计过重的流程。

第二个项目开始时，再启用项目集，把两个项目放在一起看资源和冲突。走到这一步，私有化部署项目管理软件才算真正进入团队的日常工作，而不是一个装在内网、偶尔被打开的系统。