3. 研发项目类型与项目模板设计

在Jira中落地研发项目管理，第一步不是急着建项目，而是先判断“这个团队、这条产品线、这类需求，应该用哪种项目类型承载”。项目类型决定了工作项层级、看板形态、迭代节奏和度量口径；项目模板则决定了这些配置能否被复制、复用和治理。本节围绕“类型判断—模板设计—复用落地”展开。

一、四类研发项目类型的本质差异

敏捷、看板、瀑布、混合并不是四个并列的“功能选项”，而是四种不同的工作管理假设。敏捷假设需求会持续变化，因此用短迭代和增量交付来吸收不确定性；看板假设工作以持续流动为主，因此用可视化队列和WIP限制来控制节奏；瀑布假设范围相对稳定、阶段依赖强，因此用阶段门和里程碑来管理交付；混合则承认“上游要阶段管控、下游要迭代交付”的现实，把两者拼接起来。

判断时可以用三个问题快速定位：需求变化频率高不高？交付是否必须按阶段验收？团队是否以持续流动而非固定迭代工作？如果需求变化高、按迭代交付，选敏捷；如果需求持续流入、按队列拉动，选看板；如果范围稳定、阶段依赖强，选瀑布；如果上游阶段管控、下游迭代开发，选混合。

二、项目模板不是“复制项目”，而是复制配置基线

很多团队把“模板”理解为复制一个已有项目，结果复制出来的是历史数据、过期成员和临时字段。真正可复用的Jira项目模板，应该只复制四类配置基线：工作项方案、工作流与状态、看板与视图、权限与度量。数据、成员、临时字段一律不进入模板。

以敏捷模板为例，工作项方案固定为“Epic → Story → Subtask”三层，Story 必填“故事点、验收标准、迭代”三个字段；工作流固定为“待办 → 进行中 → 待评审 → 已完成”，其中“待评审 → 已完成”只允许评审人转换；看板固定为 Scrum 板，列映射为“待办 / 进行中 / 待评审 / 已完成”，泳道按 Epic 分组；权限固定为“项目管理员、Scrum Master、开发、测试、干系人”五个角色。这样新建项目时，只需选择模板、绑定团队，即可获得一致的协作基线。

三、模板设计的关键参数与示例

模板设计要落到具体参数上，否则无法执行。下面给出一份可直接参考的模板参数示例（示例参数，非实测结果）：

以看板模板为例，WIP 限制建议按“列”设置：处理中列 WIP 上限设为团队人数 × 1.5，待验证列 WIP 上限设为团队人数 × 0.5。假设团队 6 人，则处理中列上限 9、待验证列上限 3。当某列达到上限时，看板列头会变红，提示先拉动下游而不是继续推入新工作。这个参数不是拍脑袋，而是用“在制品数量”约束流动效率。

四、模板复用与治理

模板建好后，要解决“谁能改、怎么改、改了怎么同步”三个问题。建议把模板分为“基线模板”和“团队变体”两层：基线模板由项目管理办公室（PMO）或Jira管理员维护，团队变体只能改看板列名、泳道和筛选器，不能改工作流和字段必填规则。每次变更走一次轻量评审，记录变更原因和影响范围。

最后，模板的验收标准不是“建得快”，而是“新建项目后，团队无需额外配置即可开始工作，且度量口径与组织一致”。建议每季度做一次模板健康检查：统计各模板的项目数量、字段使用率、工作流转换次数和度量报表覆盖率，淘汰长期无人使用的模板，合并重复模板，保持模板库精简有效。