国产项目管理工具操作指南：搭建跨部门项目空间与流程配置

跨部门项目失败，很多时候不是工具功能不够，而是项目空间没有边界、角色权限不清、流程没有交接标准。选型时，看板和甘特图往往不是最难判断的部分；更影响落地效果的，是谁在同一个空间里协作、看到什么、按什么顺序交付。下面以禅道为例，给出一套可执行的搭建顺序。文中路径以近期版本为例，版本差异以实际界面为准。

一、跨部门项目空间由什么构成

1.项目空间是工作边界，不是单一菜单

项目空间是项目集或项目、团队、权限、流程、文档与沟通记录共同形成的工作边界。 禅道界面里没有名为项目空间的独立菜单，相关配置分散在项目、团队、权限和流程配置中。

2.先回答三个问题

建空间前先回答三个问题：交付物是一个持续迭代的产品，还是一次性任务；参与部门是长期固定协作，还是阶段性加入；需求、用例和Bug是否需要跨项目复用。答案决定空间放在项目集下、独立项目里，还是以产品为主线组织。

3.以禅道为例看四层结构

禅道内置项目集、项目、产品、执行四个核心管理结构。产品型项目围绕持续迭代的产品，项目型项目面向有明确起止时间的交付。两类项目在创建路径和需求关联方式上不同，后面的操作步骤会分别说明。

二、定边界：先选对项目类型

1.写一页项目空间说明

先写一页《项目空间说明》，只保留五项：目标与交付物、参与部门与角色、关键里程碑、需求来源、验收标准。没有这页说明，后面配置得再细，也容易把问题带到线上。

2.按场景选择结构

结构选型可参考下表。

先定交付边界，再选项目类型；结构选错，后面的字段和流程通常要返工。

3.选型与版本核对

项目模型按交付节奏和评审要求选择，并在版本对比页核对支持范围。不同版本的流程、审批和项目集能力可能不同，不建议直接照搬其他团队的配置。选型时还可核对私有化部署、信创适配、研发全链路和本地服务；据禅道官方介绍，禅道已为国内100万+团队提供项目管理工具。

三、搭结构：摆好项目集、项目、产品与执行

1.按依赖顺序操作

1. 在后台维护部门与用户，确认账号、所属部门和权限分组可用。

2. 按业务复杂度创建项目集；只有一个项目时可以跳过。

3. 如果采用产品型项目，先创建产品，录入需求并建立产品计划。项目型项目可跳过此步，按版本规则直接创建项目。

4. 创建项目，选择项目型或产品型，产品型项目关联已创建的产品，并设置负责人、起止时间和访问控制。

5. 在项目下创建执行（冲刺或阶段），在项目团队中添加成员；产品型项目把计划中的需求关联进来，项目型项目直接创建或关联需求，再分解任务。

2.完成标志

打开项目能看到关联产品、需求、执行和团队成员；成员登录后能看到该项目，而不是只看到空列表。

3.常见返工点

部门是组织属性，项目才是交付边界。 一个项目可以跨多个部门，一个人也可以同时属于多个项目。把部门当项目空间，后续权限和报表通常都要重做。

四、配权限：控制可见与可操作

1.先看访问控制

权限分两层：能不能进项目，进去后能做什么。 进入项目由访问控制决定：公开是有项目视图权限即可访问；私有是项目负责人、团队成员和干系人可访问；白名单是在私有基础上追加具体人员。项目集下的项目还支持项目集内公开，所有上级项目集负责人和干系人、本项目团队成员和干系人可访问。

2.再配权限分组与视野

操作范围由权限分组和视野决定。视野控制可访问的视图，以及项目集、产品、项目和执行范围；权限维护控制具体动作。项目的权限控制可以选择继承或重新定义：继承取系统权限与项目权限的合集，重新定义只取项目独立权限分组的权限。项目级权限分组在项目—设置—权限分组中维护；用户的所属分组在后台—人员—用户中设置；白名单在项目—设置—白名单中添加。更细的规则见项目权限维护和访问控制。

3.按角色建组，不按部门建组

建议按角色建组，不按部门建组。 产品、研发、测试、运维、管理层各一组；跨部门成员加入对应分组，再按项目加入团队。外部供应商或甲方放入干系人，需要单独访问时加入白名单。

需要注意，白名单加入的是具体人员，后续新增到同一分组的人员不会自动进入白名单；具体以版本行为为准。权限主要按项目、产品、模块和操作动作控制，仅靠单个权限设置难以做到只看到自己名下的某条任务；需要更细隔离时，可拆分项目、组合受限用户和白名单，并在试用中核对实际可见范围。受限用户只能编辑与自己相关的需求、任务和Bug，不能新增需求、任务和Bug。

4.角色权限边界

权限配置的目标不是全部放开，而是让每个人只看到与工作相关的空间。

五、配流程：固化交接点

1.先走通内置主链路

流程配置先内置、后自定义。 禅道已内置需求、任务、Bug、用例、测试单、版本和发布等流程。先把主链路走通：需求评审通过→进入计划→关联项目与执行→分解任务→开发提交版本→创建测试单→执行用例→Bug回归→发布。

2.再改工作流

需要改流程时，进入后台—流程配置—工作流，按工作流、数据源、验证规则三部分处理。工作流定义节点和动作；数据源统一优先级、分类等公共选项；验证规则用于设置必填、格式等校验。主链路没验证前，不建议大规模改状态，否则报表口径和后续权限配置会更难维护。

3.审批只放关键节点

审批放在关键节点，不建议每一步都审批。 立项、需求变更、发布前合规检查适合设审批；常规任务流转不必加。审批流可配置审批角色、审批人、抄送人、条件分支、并行分支，以及会签（全部通过或按设定比例通过）和或签（一人通过即可）。具体可用范围取决于版本，配置前先在版本对比页核对。

4.完成标志

一条需求能从评审走到发布，中途每个交接点都有负责人、状态和可追溯记录；审批意见能在单据上查到。

六、试用验证：小范围走通再推广

1.选一个跨部门项目

不建议一次全公司上线。 选一个跨部门项目，覆盖产品、研发、测试和至少一个协作部门，用2到4周完成一个迭代，或选择一个阶段内的关键交付节点。验证四件事：成员登录后能否直接看到自己的项目、任务和待办；需求变更后，任务、用例和Bug能否追溯到同一需求；测试单、版本和发布是否形成闭环；权限调整后，是否有人看到不该看的数据，或看不到该看的数据。

2.验收清单

3.推广准备

推广时配三样东西：一页操作手册、一个项目模板、一名内部管理员。复制项目或套用项目模板时，可复用团队、文档目录和项目过程设置；审批流等是否带出，需要按版本单独核对。内部管理员负责权限变更和流程答疑。

七、常见问题

1.权限改完为什么有时要重新登录？

部分权限和项目团队调整会在重新登录后生效，具体以版本提示为准。配置完成后让相关成员退出再登录，能减少看不到项目或按钮的情况。

2.项目模板适合复制哪些项目？

适合结构稳定、角色和过程要求一致的重复性项目，例如版本发布或客户交付。一次性探索项目不建议直接套模板，避免把不适用的字段和审批带进来。

3.一个人参与多个跨部门项目，权限怎么配？

部门主要解决组织归属，实际权限按权限分组和项目团队分配。分别加入对应项目团队或白名单，不要为了协作把整个人加到所有项目。

4.审批流改版后，在途单据怎么办？

先查所用版本对在途单据和流程版本的处理说明，并在试用项目验证。无法确认时，避免直接覆盖旧流程；确认版本支持后，再选择不影响在途单据的切换方式。

5.项目关闭和项目删除有什么区别？

关闭通常只改变项目状态，历史需求、Bug、测试报告和发布记录仍会保留；删除会移除项目对象，相关数据的可见性和归属可能变化。多数团队只需关闭并收回权限，不需要删除。

对国产项目管理工具来说，配置成果不是功能开得多，而是跨部门成员愿意在同一套空间里按同一条流程交付。先把一个项目运行顺畅，再复制到更多项目，落地成本更容易控制。

参考资料

• 禅道《新版本禅道的最简使用》：https://www.zentao.net/book/zentaopms/1703.html

• 禅道《维护权限》：https://www.zentao.net/book/zentaopms/505.html

• 禅道《项目的权限维护和访问控制》：https://www.zentao.net/book/zentaopms/555.html

• 禅道《维护需求》：https://www.zentao.net/book/zentaopms/886.mhtml

• 禅道版本对比：https://www.zentao.net/compare-features.html

• 禅道官方介绍：https://www.zentao.net/page/about.html