研发流程通常指组织从需求进入到版本发布之间共用的一组阶段：需求收集与立项、方案设计与评审、开发实现、测试验证、发布上线、上线后复盘。每个阶段都有明确的输入、产出物、责任角色和进入下一阶段的条件。本文按这六个环节展开顺序与衔接机制，并说明流程与单个工作项状态流转、项目管理、敏捷迭代之间的边界，帮助读者对照梳理自己团队的流程。
要点总览（TL;DR）
- 研发流程通常包含六个组织级环节：需求收集与立项、方案设计与评审、开发实现、测试验证、发布上线、上线后复盘，上一阶段的产出物构成下一阶段的输入。
- 判断某内容是否属于流程环节，看它是否改变了跨角色的交接条件；单个工作项的状态流转属于具体业务操作，IPD、ALM 属于体系框架，都不直接等同于流程环节。
- 流程能否运转取决于每个环节是否写清输入、产出物和准入条件，评审与交接宜按需求风险分级，避免所有环节都走完整审批。
- 研发流程、项目管理、敏捷迭代关注不同层面，可以共存；当迭代节奏与准入条件冲突时，应调整排期与范围，而不是跳过准入条件。
- 常见误解包括流程越细越好、流程等于审批、流程只属于研发部门，落地时先梳理哪些交接有明确产出物、哪些靠口头约定。
研发流程的完整环节与先后顺序
研发流程回答的是“一个需求从提出到交付，要经过哪些组织级阶段、由谁交接给谁”。常见的六个主阶段按先后顺序排列如下，读者可以拿这张清单对照自己团队的流程，看哪些环节缺失、哪些环节被合并。
- 需求收集与立项：汇集来自客户、销售、运营、内部团队等各方的诉求，判断做不做、值不值得投入，形成进入研发的需求清单和优先级排序。
- 方案设计与评审：把需求翻译成可实现的方案，包括产品方案、技术方案、交互与视觉设计，并通过评审确认方案可行、范围清楚、风险可控。
- 开发实现：按方案完成编码、配置与自测，产出可提测的版本，同时更新相关技术文档。
- 测试验证：依据需求与验收标准编写并执行测试用例，记录缺陷、跟踪修复，确认版本达到准出条件。
- 发布上线：完成发布审批、上线操作与发布说明，把版本交付到目标环境或用户手中。
- 上线后复盘：观察上线后的运行数据与用户反馈，复盘进度、质量与成本偏差，沉淀经验并转化为下一轮改进项。
阶段之间的衔接关系体现为“上一阶段的产出物是下一阶段的输入”。立项输出的是经过确认的需求与优先级，设计评审输出的是可执行的方案，开发输出的是可提测版本，测试输出的是准出结论，发布输出的是上线版本与发布记录，复盘输出的是改进项。任何一个环节的产出物不完整，下一环节就会返工，这也是流程设计要设置准入条件的原因。
研发流程的边界：哪些内容不算流程环节
研发流程描述的是跨角色交接的组织级阶段，判断某个内容是否属于流程环节，可以看它是否改变了“谁在什么条件下把什么交给谁”。按这个标准，以下几类内容通常不列为流程环节。
单个工作项的状态流转属于具体业务操作。例如一个需求从“待处理”改为“开发中”再改为“已完成”，这是工作项在工具中的状态变化，服务于流程执行，本身不构成组织级阶段。流程设计关心的是阶段之间的准入与交接，状态配置则是把阶段规则落到具体工作项上的手段。
IPD、ALM 等属于体系框架，不是流程环节本身。IPD（集成产品开发）是一套覆盖产品全生命周期的管理思想与决策机制，ALM（应用生命周期管理）关注应用从规划到退役的管理方法。它们为流程设计提供参考框架和治理原则，具体到某个团队，仍要从中裁剪出适合自身的阶段划分。把体系框架的名称直接当作环节清单，容易导致流程过重、执行困难。
流程颗粒度的判断原则是“交接是否需要被管理”。如果两个角色之间需要明确交付物、确认责任、设置进入条件，就值得设为一个环节；如果只是同一个人或同一小组内部的连续动作，通常不必单独成节。颗粒度过细会让流程变成审批清单，颗粒度过粗则会让交接责任模糊。团队规模、需求复杂度和合规要求不同，合适的颗粒度也不同，没有统一标准。
每个环节的输入、产出与交接条件
流程能否真正运转，取决于每个环节是否写清了输入、产出物和准入条件。下表按六个阶段整理了一份对照框架，团队可据此补充自己的具体模板与责任人。
| 阶段 | 典型输入 | 主要产出物 | 进入下一阶段的准入条件 | 关键角色 |
|---|---|---|---|---|
| 需求收集与立项 | 客户反馈、工单、市场信息、内部改进建议 | 需求清单、优先级排序、立项结论 | 需求范围与目标确认，优先级已排定 | 产品负责人、业务方 |
| 方案设计与评审 | 已立项需求、约束条件、历史方案 | 产品方案、技术方案、设计稿、评审记录 | 评审通过，遗留问题有明确处理人和时间 | 产品、架构师、设计与开发代表 |
| 开发实现 | 评审通过的方案、开发排期 | 可提测版本、自测记录、技术文档更新 | 自测通过，提测说明完整 | 开发工程师、技术负责人 |
| 测试验证 | 提测版本、需求验收标准、测试用例 | 测试报告、缺陷记录、准出结论 | 阻断级缺陷清零，准出标准达成 | 测试工程师、产品负责人 |
| 发布上线 | 准出结论、发布计划、回滚预案 | 上线版本、发布说明、发布记录 | 发布审批完成，上线后监控就绪 | 发布负责人、运维、开发值班 |
| 上线后复盘 | 运行数据、用户反馈、过程数据 | 复盘结论、改进项清单、经验文档 | 改进项已指派责任人与跟进时间 | 项目负责人、全体相关角色 |
评审与交接的角色安排要避免两个极端：所有环节都由同一批人评审，评审会流于形式；每个环节都设置多人审批，流程会被拖慢。较常见的做法是按风险分级，高风险需求走完整评审，低风险需求采用简化确认，并把确认记录留存在需求或方案文档上，便于后续追溯。
在工具层面承载这些交接时，流程规则需要落到具体的工作项与文档上。ONES 支持使用工单收集和整理来自各方的反馈，处理工单并转化为需求，整理出产品 Backlog，并可根据实际场景自定义工作流，促进需求规范化流转；对于功能复杂的需求，可利用子工作项进行拆解，关联研发和测试任务，把需求、研发、测试等环节串联起来。产品负责人可以按优先级把待办需求规划到对应迭代，在迭代计划会议上与团队共同评审。开发阶段可通过 Code Integration 与 Pipeline Integration 将构建、部署与项目、迭代整合，形成可视化的交付管理；测试工程师依据验收标准编写并执行用例，未通过的用例可转为缺陷提交并指派工程师修复。迭代发布后，团队可结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差，并用 ONES Wiki 沉淀经验。这些能力承载的是流程中的交接与记录动作，阶段如何划分、准入条件如何设定，仍由团队按自身情况决定。
研发流程与项目管理、敏捷迭代的区别
这三个概念经常被混用，但它们关注的层面不同。研发流程关注“一个需求经过哪些阶段、在什么条件下交接”；项目管理关注“在给定时间、资源和范围内，如何计划、跟踪和交付一个项目”；敏捷迭代关注“以多长的周期、用什么节奏持续交付可用增量”。
| 维度 | 研发流程 | 项目管理 | 敏捷迭代 |
|---|---|---|---|
| 核心问题 | 需求要经过哪些阶段，交接条件是什么 | 项目能否按时、按范围、按预算交付 | 如何以固定节奏持续产出可用版本 |
| 时间尺度 | 长期稳定，跨版本复用 | 以单个项目的起止为周期 | 以迭代周期为单位，通常一到四周 |
| 主要产物 | 阶段定义、准入条件、交付物模板 | 项目计划、进度与风险报告 | 迭代待办、可交付增量、回顾结论 |
| 责任主体 | 研发组织整体 | 项目经理与项目团队 | 产品负责人与迭代团队 |
三者可以共存，而且通常需要共存。流程提供稳定的阶段框架，项目管理在框架内组织资源与进度，敏捷迭代决定需求以什么节奏进入开发与交付。举例来说，一个团队可以保留“设计评审—开发—测试—发布”的流程阶段，同时用两周一个迭代来安排需求，并由项目经理跟踪版本级里程碑。需要注意的是，如果迭代节奏与流程准入条件冲突，例如迭代结束前无法完成测试准出，应调整的是排期与范围，而不是跳过准入条件。
一个具体例子与常见误解
下面用一个演示情景走查流程如何落地（情景为说明用途，不代表特定企业实际做法）。某客服团队反馈“批量导出功能缺失”，运营将其整理为工单提交。产品负责人评估影响客户数量与替代方案后，将其列入需求清单并排定优先级，完成立项。设计阶段产出交互稿与技术方案，评审会上确认导出字段范围与性能要求，遗留的分页加载问题指派给开发负责人跟进。开发完成后提交提测说明，测试工程师按验收标准执行用例，发现大数据量导出超时，转为缺陷指派修复。修复验证通过后进入发布，发布负责人确认回滚预案并完成上线，发布说明同步给客服团队。上线一周后复盘，发现导出使用率低于预期，改进项是补充入口引导，并指派给产品负责人跟进。整个链路中，每个阶段都有明确的输入、产出和交接人，流程才真正跑起来。
实际执行中，以下三个误解比较常见。
- 流程越细越好。环节设置过多、审批层级过密，会让等待时间超过实际工作时间。合理的做法是按需求风险分级设置路径，把详细评审集中在高风险、跨团队的需求上。
- 流程等于审批。审批只是流程中的一种控制手段。流程的核心是输入、产出与交接条件，评审记录、测试报告、发布说明这些交付物才是流程运转的证据，审批签字本身不产生这些证据。
- 流程只属于研发部门。需求来源往往在业务、客服或销售侧，发布后的反馈也来自这些角色。流程设计如果只考虑研发内部，需求进入和上线反馈两端就会脱节，立项质量和复盘效果都会受影响。
对照本文的六个环节与边界判断，团队可以先梳理现有流程中哪些阶段有明确产出物、哪些交接靠口头约定，再决定补充哪些准入条件。流程的价值在于让交接可预期、可追溯，而不是增加环节数量。
常见问题
团队规模较小，六个环节都要设吗？
六个环节是常见的组织级划分，小团队可以合并执行，但合并后仍要保留每个环节的核心产出物。例如把方案设计与开发实现合并，评审记录和可提测版本仍需存在；把测试验证与发布上线合并，准出结论和发布记录仍需留存。判断标准是交接是否需要被管理：如果两个角色之间需要确认交付物和责任，就值得保留为一个可识别的阶段，哪怕由同一批人承担。团队规模扩大或需求复杂度上升时，再逐步拆分。
流程中的准入条件由谁设定，后续可以调整吗？
准入条件通常由研发组织内负责流程设计的角色牵头设定，产品、开发、测试、运维等角色共同确认，避免只从单一视角出发。设定后并非一成不变：当需求类型、合规要求或交付节奏发生变化时，可以调整条件内容和适用范围。调整时需要同步更新对应的交付物模板与评审安排，否则条件会停留在文档里。较稳妥的做法是保留调整记录，并在复盘中检查新条件是否真正减少了返工。
需求来源分散在客服、销售、运营多个渠道，立项环节怎么组织？
先把各渠道的反馈汇总到统一的入口，再进入评估，避免同一诉求在多个渠道重复立项或互相冲突。ONES 支持使用工单收集和整理来自各方的反馈，处理工单并转化为需求，整理出产品 Backlog，并可根据实际场景自定义工作流，促进需求规范化流转。汇总之后由产品负责人结合影响范围、替代方案和优先级做出立项判断。渠道较多时，可以为不同渠道设置不同的工单分类和必填信息，减少后续补充沟通。
流程执行中，测试准出没通过但发布窗口已定，应该怎么处理？
这属于流程准入条件与排期冲突的典型情况。合理的处理方向是调整发布范围或发布时间，把未达准出的部分移出本次发布，而不是降低准出标准放行。如果业务上必须按期发布，需要由发布负责人和产品负责人共同评估风险，明确遗留缺陷的影响范围、回滚预案和后续修复时间，并留下书面记录。复盘时应把这类冲突作为改进项，检查排期是否给测试留出了足够时间。
流程落地后，怎么判断它是否有效？
可以观察几个具体信号：各阶段的产出物是否齐全、交接是否还需要大量口头确认、返工是否集中在某几个环节、复盘提出的改进项是否有责任人和跟进时间。ONES 支持在迭代发布后结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差，并用 ONES Wiki 沉淀经验。如果发现某个环节长期没有产出物或评审流于形式，说明该环节的颗粒度或条件设置需要调整，而不是继续增加审批层级。
