本文提供一份虚构团队的研发流程填写样例，覆盖从需求受理到发布复盘的组织共用流程，逐项说明阶段、角色、交付物与准入条件怎么填。读者可参照它整理自己团队的流程文档，再按规模与交付节奏改写；文中情景均为示例，不代表真实客户案例或实测结论。
要点总览（TL;DR）
- 一份可用的研发流程示例应覆盖需求受理、方案评审、开发与联调、测试验收、发布、复盘六个阶段，每个阶段写清输入、关键动作、交付物、责任角色和退出条件。
- 样例中的评审结论分为通过、有条件通过、退回三种，退回时须写明原因和补充要求，有条件通过的条件项要指定责任人和完成时间。
- 把样例改成自用流程时，先定阶段边界再填字段，用真实项目回放校验，并约定流程文档的维护人与版本记录方式。
- 这份样例适合需求来源相对稳定、发布节奏规律的产品研发团队；强合规、外包协作、多产品线并行等情形需要补充记录要求、外部接口角色或产品线差异说明。
- 文中情景为虚构示例，用于演示填写方式，不构成真实客户案例或实测结论。
示例要解决什么：一份研发流程样例的目标与假设
这份样例的目标，是把团队里“大家大概知道怎么做”的口头流程，写成一份可执行、可评审的阶段流程文档。可执行意味着每个阶段都有明确的输入、动作、交付物和退出条件，接手的人照着做就能推进；可评审意味着评审者能对照文档判断某个阶段是否达到准入要求，而不是凭印象放行。
为了让样例具体可读，设定一个虚构情景：一个约二十人的产品研发团队，同时维护一个已有产品和开发一个新模块，每两周发布一次，需求来源包括内部规划和外部反馈。团队已有基本的项目管理工具，但流程主要靠口头约定，评审时松时紧，发布后问题回溯困难。这个设定仅用于演示填写方式，不对应任何真实组织。
样例覆盖的范围是组织层面的共用流程：从需求被正式受理，到方案评审、开发与联调、测试验收、发布，再到发布后的复盘。它回答的是“一件事从进入到结束，经过哪些关口、由谁负责、交什么、什么条件下才能往下走”。单条工作项的状态如何设置、状态字段怎么配置，属于工具操作层面，本文不展开；IPD、ASPICE 等现成体系框架的选型与对比，也不在本文范围内。读者需要的是先有一份能落地的流程骨架，体系框架的取舍可以另行评估。
完整示例：从需求受理到发布复盘的研发流程填写样例
下面这份样例按六个阶段填写，每个阶段都给出输入、关键动作、交付物、责任角色和退出条件。阶段之间是串行推进关系，评审不通过时退回上一阶段，退回规则在阶段说明之后单独列出。
阶段一：需求受理
输入是需求来源材料，包括内部规划条目、外部反馈记录或业务方提出的变更请求。关键动作是需求初审：判断需求是否属于本团队范围、是否与现有规划重复、信息是否足以进入评估。交付物是一份填写完整的需求说明，包含背景、目标用户、期望结果和初步优先级。责任角色是产品负责人，业务方配合补充信息。退出条件是需求说明通过初审并被纳入待评估清单，信息缺失的需求退回提出方补充。
阶段二：方案评审
输入是已受理的需求说明。关键动作包括技术方案设计和评审会：技术负责人给出实现思路、影响范围、依赖项和粗略工作量，产品负责人确认方案是否覆盖需求目标，测试角色提前判断可测性。交付物是方案文档和评审结论记录，结论分为通过、有条件通过、退回三种。责任角色是技术负责人主笔，产品负责人和测试负责人参与评审。退出条件是评审结论为通过或有条件通过，且条件项已明确责任人和完成时间。
阶段三：开发与联调
输入是评审通过的方案文档。关键动作是任务拆分、编码、自测和联调：开发人员按方案拆分任务并逐项完成，涉及多模块或外部接口的部分安排联调，联调中发现的问题记录在对应任务下。交付物是可运行的代码、自测记录和联调结论。责任角色是开发负责人，接口相关方配合联调。退出条件是开发任务全部完成、自测通过、联调无阻塞问题，代码进入待测状态。
阶段四：测试验收
输入是待测版本和方案文档中的验收要点。关键动作是测试用例执行、缺陷跟踪和验收确认：测试人员按用例验证功能与回归范围，缺陷按严重程度分级处理，产品负责人对照需求说明做验收。交付物是测试报告、缺陷清单和验收结论。责任角色是测试负责人，产品负责人做验收确认。退出条件是阻塞级和严重级缺陷清零，验收结论为通过；未达标则退回开发与联调阶段。
阶段五：发布
输入是验收通过的版本和发布计划。关键动作包括发布前检查、发布执行和发布后观察：确认发布范围、回滚方案和通知对象，按计划执行发布，发布后一段时间内观察关键指标和用户反馈。交付物是发布记录，包含版本号、发布时间、发布内容和回滚预案。责任角色是发布负责人，开发和测试角色待命支持。退出条件是发布完成且观察期内无重大异常；出现重大异常时按回滚预案处理并转入复盘。
阶段六：复盘
输入是本次发布的完整记录，包括需求、方案、测试报告和发布记录。关键动作是回顾目标与实际结果的差异，识别流程中卡住的环节，形成改进项并指定责任人。交付物是复盘记录和改进项清单。责任角色是团队负责人主持，各阶段责任人参与。退出条件是改进项已分配责任人和目标时间，纳入下一周期跟踪。
评审与退回规则示例
退回规则需要写清楚“谁有权退回、退回到哪、需要补什么”。样例中的做法是：方案评审不通过时退回需求受理，由产品负责人补充需求说明后重新提交；测试验收不通过时退回开发与联调，缺陷修复后重新进入测试；发布后发现重大问题时，先执行回滚，再进入复盘，复盘结论可能触发需求或方案的重新评估。每次退回都要求在对应记录中写明退回原因和补充要求，避免同一问题反复往返。
流程总表
| 阶段 | 责任角色 | 主要交付物 | 准入（退出）条件 |
|---|---|---|---|
| 需求受理 | 产品负责人 | 需求说明 | 信息完整，纳入待评估清单 |
| 方案评审 | 技术负责人 | 方案文档、评审结论 | 结论为通过或有条件通过，条件项有责任人和时间 |
| 开发与联调 | 开发负责人 | 代码、自测记录、联调结论 | 任务完成，自测通过，联调无阻塞问题 |
| 测试验收 | 测试负责人 | 测试报告、缺陷清单、验收结论 | 阻塞级与严重级缺陷清零，验收通过 |
| 发布 | 发布负责人 | 发布记录、回滚预案 | 发布完成，观察期无重大异常 |
| 复盘 | 团队负责人 | 复盘记录、改进项清单 | 改进项已分配责任人和目标时间 |
逐项解释：每个字段为什么这样填
阶段划分的粒度，取决于团队需要在哪些节点做集体判断。样例把方案评审和测试验收单独设成阶段，是因为这两处最容易出现“做完了才发现方向不对”或“上线后才发现没验到”的情况，单独设阶段并配准入条件，能让判断发生在成本还低的时候。如果团队规模更小、需求变化更快，可以把方案评审并入需求受理，但准入条件仍要保留，否则评审会变成走过场。
角色填写要落到具体职责，而不是只写岗位名称。“产品负责人”在需求受理阶段负责判断范围和信息完整性，在测试验收阶段负责对照需求做验收确认，同一角色在不同阶段的动作不同，写清楚动作才能避免职责真空。样例中每个阶段只设一个主责角色，配合角色列在关键动作里，这样出问题时能找到第一责任人。
交付物与准入条件是一一对应的关系。交付物是“这一阶段产出了什么”，准入条件是“凭什么判断可以进入下一阶段”。需求受理的交付物是需求说明，准入条件就是这份说明信息完整；测试验收的交付物是测试报告和缺陷清单，准入条件就是缺陷分级达标。把两者分开写，评审时可以先看交付物是否齐全，再对照条件判断质量，减少主观争论。
退回与例外路径的设计，重点在于让例外有记录、有出口。完全不允许例外的流程在现实中很难执行，样例的做法是允许“有条件通过”，但条件项必须写明责任人和完成时间，并在下一阶段开始前确认关闭。这样既保留了灵活性，又不会让条件项无限期悬空。哪些字段可以随团队调整：阶段数量、角色名称、缺陷分级口径、观察期长短都可以改；输入输出和准入条件的对应关系建议保留，这是流程能被执行的结构基础。
可迁移规律：把这份样例改成自己团队的流程
把样例改成自用流程，建议按下面的顺序操作，先定骨架再填细节，避免一上来就纠结字段名称。
- 先定阶段边界。列出团队从接到需求到交付结果实际经过的关键节点，把需要集体判断的节点单独成阶段，其余合并。判断标准是：这个节点如果跳过，出问题的概率是否明显上升。
- 再填每个阶段的输入、动作、交付物和退出条件。填写时用团队真实使用的文档和记录名称，不要另造一套只在流程文档里存在的交付物。
- 按团队规模和交付节奏调整阶段数量。人数少、发布频繁的团队可以合并阶段，但每个合并后的阶段仍要保留明确的退出条件；多人协作、跨团队依赖多的团队可以拆分联调和验收，把接口确认单独设成检查点。
- 用真实项目回放校验。挑一个刚完成的项目，按新流程从头走一遍，检查每个阶段的交付物是否真的存在、退出条件是否真的能判断。走不通的地方就是流程需要修改的地方。
- 约定维护方式。流程文档指定一名维护人，明确修改触发条件（如组织调整、发布节奏变化）和版本记录方式，每次修改注明变更内容和生效时间，避免多份版本同时在用。
流程文档写好后，落地环节通常涉及阶段流转、评审记录和交付物的集中管理。ONES 支持项目管理、知识库、测试管理等模块组合，可用于承载需求、任务、测试与文档之间的关联；其面向汽车软件研发的解决方案描述了支持研发全生命周期流程活动和跨域协作可追溯性。团队可以把上面样例中的阶段和准入条件对应到工作项状态与评审记录中，让流程文档和实际执行保持同一套口径。具体配置方式需结合团队所用模块和部署情况确定。
适用边界：这份示例在什么情况下需要调整
这份样例适合需求来源相对稳定、发布节奏规律、团队规模在十几到几十人之间的产品研发团队，尤其是流程主要靠口头约定、希望先建立共用骨架的团队。它提供的是阶段、角色、交付物和准入条件的写法结构，不是一套必须照搬的固定模板。
以下情形需要做明显调整：强合规要求的项目，例如需要留存完整审计记录的场景，要在每个阶段补充记录要求和审批留痕，准入条件也要对应合规检查项；外包或多方协作项目，角色要扩展到外部接口人，交付物需要明确交接标准和验收责任方；多产品线并行时，共用流程之上要增加产品线级的差异说明，避免用一套阶段划分套所有产品。团队处于快速探索期、需求频繁推翻重来时，可以缩短阶段、提高评审频率，但退回规则要写得更明确。
需要说明的是，本文情景为虚构示例，用于演示填写方式，不构成真实客户案例，也没有实测效果数据。样例中的阶段划分和字段结构属于通用流程设计方法，读者应结合自身组织实际改写。本文聚焦组织共用流程的写法，单条工作项的状态如何设置与流转、IPD 或 ALM 等体系框架如何选型，属于另外的问题，需要单独评估。
常见问题
团队人数很少、发布很频繁，这份六阶段样例可以合并成几个阶段？
可以合并，但合并后每个阶段仍要保留明确的退出条件。常见做法是把方案评审并入需求受理，把开发与联调、测试验收合并为一个交付阶段，形成“受理与方案—开发与验收—发布—复盘”四段结构。合并的判断标准是：这个节点如果跳过，出问题的概率是否明显上升。评审动作可以简化，但“方案是否覆盖需求目标”“缺陷分级是否达标”这类判断依据建议保留，否则流程会退化成只走形式。
评审允许“有条件通过”，条件项一直没关闭怎么办？
样例的做法是给条件项写明责任人和完成时间，并在下一阶段开始前确认关闭。执行中可以把条件项登记为独立任务，纳入日常跟踪，到期未关闭时由阶段主责角色在评审记录中说明原因并重新约定时间。如果条件项涉及发布安全或验收结论，建议把它设为进入下一阶段的硬性前置条件，避免带条件上线后无人跟进。
外包或多方协作的项目，这份样例的角色和交付物要怎么改？
需要把角色扩展到外部接口人，明确每方的第一责任人和对接人；交付物要写清交接标准和验收责任方，例如方案文档由谁确认、联调结论由哪方签字、测试报告覆盖哪些范围。退回规则也要补充跨方退回的处理方式，写明退回后由哪一方补充、多长时间内响应。共用流程骨架可以保留，差异集中在角色表和交付物清单中体现。
流程文档写好后，怎么保证实际执行和文档一致？
关键是让流程中的阶段、交付物和准入条件对应到团队日常使用的工具记录里，而不是另存一份只在评审时打开的文档。ONES 支持项目管理、知识库、测试管理等模块组合，可用于承载需求、任务、测试与文档之间的关联；其面向汽车软件研发的解决方案描述了支持研发全生命周期流程活动和跨域协作可追溯性。团队可以把阶段与准入条件对应到工作项状态和评审记录中，让文档口径与执行记录保持同一套。具体配置方式需结合团队所用模块和部署情况确定。
强合规场景下，这份示例需要补充哪些内容？
强合规项目通常要在每个阶段补充记录要求和审批留痕，准入条件对应合规检查项，例如方案评审的参与人记录、测试执行的完整证据、发布审批的签署记录。退回和例外路径也要留痕，写明谁批准了例外、依据是什么。这类补充会增加流程重量，建议只对受监管范围的工作项启用，其余部分沿用较轻的共用流程。
