研发过程改进要落到可执行的动作上：先从交付记录、评审问题和角色访谈中筛出1—2个可观察的过程问题，再把每个问题改造成有输入、动作、输出和完成标志的目标做法，明确责任人与交付物，选一个团队小范围试点，用改进前后的过程证据判断是否有效，通过后固化为过程资产并分批推广。本文聚焦组织过程能力的改进，不展开度量数据驱动的小范围效能实验。
要点总览（TL;DR）
- 研发过程改进从筛选问题开始：从交付延期与返工记录、评审与测试问题分布、角色访谈中的交接断点收集候选问题，按影响面、可观察证据、可控范围和改进成本筛选，本轮只做1—2个问题。
- 每个问题按五步改造：现状描述、定义目标做法、确定责任人与协作接口、选择试点团队与周期、收集改进前后证据并判断，每步都有输入、动作、输出和完成标志。
- 角色分工要提前定清：过程负责人定义做法并判断推广，团队负责人组织试点执行，一线角色执行并记录过程证据，过程改进接口人维护台账和证据汇总。
- 试点结束用完成检查表核对：目标做法是否写入工作约定、是否有过程记录、前后证据是否可对比、未达标项是否有处置方式；无证据、无责任人、无完成标志不得判定完成。
- 验证通过后把做法写成过程说明，关键节点落到可追踪的工作项与文档状态，用统一台账记录改进项，按团队分批推广并保留反馈入口。
先定改进范围：从哪些过程问题入手
研发过程改进的第一步是确定改什么、改多大。范围定得过大，改进会变成一次性铺开整套流程体系，执行者疲于填表，问题本身反而没有被解决。可行的做法是先收集候选问题，再按统一标准筛选，最后把本轮范围压缩到1—2个问题。
改进对象的三个来源
- 交付延期与返工记录：查看近几个迭代或项目的计划完成时间与实际完成时间差异，以及返工工单、缺陷回退、需求变更导致的重复开发记录。关注反复出现的同类延期，而非单次偶发情况。
- 评审与测试发现的问题分布：统计需求评审、设计评审、代码评审、测试各环节发现问题的类型和数量。如果某类问题在评审通过后仍大量出现在测试阶段，说明上游环节的把关动作存在缺口。
- 角色访谈中的交接断点：分别访谈产品、开发、测试、运维等角色，询问“你拿到上一环节的产出时，最常缺什么信息”“你交付给下一环节时，最常被退回什么”。交接断点往往无法从数据中直接看出，需要访谈补充。
筛选标准
| 标准 | 判断问题 | 处理方式 |
|---|---|---|
| 影响面 | 该问题影响几个团队、几条产品线或多少比例的交付 | 影响面广的优先，但需评估可控性 |
| 可观察证据 | 是否有记录、数据或访谈材料能证明问题存在 | 无证据的问题先补充观察，不直接进入改进 |
| 可控范围 | 改进动作是否在团队或部门权限内可以调整 | 涉及组织架构、考核制度的问题本轮暂缓 |
| 改进成本 | 需要新增多少会议、文档、工具配置和培训 | 成本低、见效快的优先试点 |
写成一句话问题陈述
筛选出的问题要写成一句可核对的话，包含现象、环节和角色。例如：“需求评审通过后，测试阶段仍有约三成缺陷源于需求描述歧义，涉及产品经理与开发、测试三个角色。”这句话标明了现象（缺陷源于需求歧义）、环节（需求评审到测试）、角色（产品、开发、测试），后续定义目标做法时可以直接对应。
本轮范围建议只保留1—2个问题。问题清单中记录问题陈述、涉及环节、涉及角色和筛选理由，作为后续动作定义的输入。范围边界写清楚“本轮不处理什么”，避免执行过程中不断追加议题。
核心操作步骤：把每个问题改造成可执行动作
问题确定后，需要把它转换成团队能照着做的目标做法。以下五步按顺序执行，每一步都有明确的输入、动作、输出和完成标志，避免改进停留在“加强沟通”“提高评审质量”这类口号上。
步骤一：现状描述
记录当前做法与产出物，不做评价。输入是问题清单和现有过程记录；动作是访谈执行角色、收集当前使用的模板和检查单、记录实际发生的步骤；输出是一页现状说明，写清谁在什么时点做什么、产出什么、交给谁；完成标志是至少两名执行该环节的角色确认现状描述与他们的实际做法一致。
步骤二：定义目标做法
针对现状中的缺口，定义新的做法。输入是现状说明；动作是明确目标做法的输入物、执行动作、输出物和完成标志，并说明与现状的差异点；输出是改进动作卡；完成标志是动作卡中的每个动作都能被一线角色复述，且完成标志可以被第三方核对，例如“评审记录中包含需求验收条件字段并由测试角色签字确认”。
步骤三：确定责任人与协作接口
为动作卡上的每个动作指定责任人，并写明上下游交接的接口。输入是改进动作卡；动作是识别每个动作的执行者、审核者和接收者，标注交接时点与交接物；输出是带责任人的动作卡；完成标志是每个动作有且仅有一个直接责任人，交接双方对交接物内容达成一致。
步骤四：选择试点团队与试点周期
输入是带责任人的动作卡；动作是选择一个受该问题影响明显、团队负责人愿意配合的团队，约定试点周期（通常覆盖2—3个完整迭代或一个交付周期），并提前说明试点期间只执行新做法、不叠加其他变更；输出是试点计划；完成标志是试点团队、周期、观察指标和证据收集方式均已书面确认。
步骤五：收集改进前后证据并判断
输入是试点计划与过程记录；动作是按约定方式收集试点期间的过程证据，与现状描述中的基线对比；输出是对比记录与判断结论；完成标志是结论明确写出“继续推广”“调整后延长试点”或“停止”三种之一，并附证据依据。
五步对照表
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 现状描述 | 问题清单、现有过程记录 | 访谈执行角色，记录实际步骤与产出物 | 一页现状说明 | 执行角色确认描述与实际一致 |
| 定义目标做法 | 现状说明 | 明确输入、动作、输出、完成标志及差异点 | 改进动作卡 | 一线角色能复述，完成标志可被第三方核对 |
| 确定责任人与接口 | 改进动作卡 | 指定执行者、审核者、接收者与交接时点 | 带责任人的动作卡 | 每个动作有唯一直接责任人，交接物达成一致 |
| 选择试点 | 带责任人的动作卡 | 选定团队、周期、观察指标与证据方式 | 试点计划 | 团队、周期、指标、证据方式书面确认 |
| 收集证据并判断 | 试点计划、过程记录 | 收集试点证据，与基线对比 | 对比记录与结论 | 结论明确为继续、调整或停止，并附依据 |
角色与交付物：谁负责什么、交什么
改进过程中常见的失败是“大家都在推，没人真正负责”。把角色和交付物提前定清楚，可以让每个环节有明确的交接对象和时点。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 过程负责人 | 定义目标做法、组织评审、判断是否推广 | 改进动作卡、评审结论、推广决定 | 动作卡在试点前交付团队负责人；推广决定在试点结论评审后给出 |
| 团队负责人 | 组织试点执行、反馈执行障碍 | 试点执行记录、障碍清单 | 试点期间按周反馈障碍；试点结束时提交执行总结 |
| 一线角色 | 按新做法执行并记录过程证据 | 过程记录、评审记录、交接确认 | 每个工作项完成时同步提交记录 |
| 质量或过程改进接口人 | 维护改进台账、汇总证据 | 改进台账、证据汇总表 | 试点中期和结束时各汇总一次，提交过程负责人 |
过程负责人对“改什么、改成什么样”负责，团队负责人对“试点能不能执行下去”负责，一线角色对“过程证据是否真实完整”负责，接口人对“台账和证据是否齐全可查”负责。四类交付物在试点开始前、试点中期和试点结束时三个时点完成交接，避免证据在试点结束后才补记。
示例：一次需求评审环节的改进落地
以下为演示情景，用于说明步骤如何串联，不代表特定组织的真实数据。
问题与现状
某产品团队发现，需求评审通过后进入测试阶段，仍有较多缺陷被判定为需求理解偏差导致的返工。现状记录显示：需求评审会以产品经理讲解为主，开发与测试在会中提问较少；评审产出是一份会议纪要，没有记录验收条件和边界场景；评审通过的标准是“无人反对”。
目标做法
改进动作卡定义：需求文档在评审前一个工作日发出，包含验收条件和异常场景说明；评审会由测试角色逐条确认验收条件；评审输出为带确认状态的评审记录，未确认项标注责任人和补充时限；完成标志是评审记录中所有验收条件均有测试角色确认，未确认项在时限内关闭。
试点与证据
选择一个迭代周期为两周的团队试点两个迭代。试点期间收集三类证据：评审记录中的确认项比例、测试阶段判定为需求理解偏差的缺陷数量、开发与测试对评审有效性的简短反馈。改进前的基线取自试点前两个迭代的同类记录。
对比与结论
试点结束后对比发现：评审记录中验收条件确认比例明显上升，需求理解偏差类缺陷数量下降，但评审会时长增加。结论为“调整后继续”：保留验收条件确认动作，将评审会拆分为书面预审和集中确认两段，控制会议时长。该结论附有前后对比记录，作为推广依据。
可迁移的规律与边界
这个示例可迁移的部分是：把“评审通过”从主观判断改为可核对的确认动作，并用试点前后的过程记录判断效果。适用边界在于，该方法依赖团队愿意在评审前投入准备时间；如果需求来源极不稳定、变更频繁，应先处理需求变更管理，再改进评审环节。
完成检查：判断本轮改进是否真正落地
“做了动作”和“过程真的改变”是两件事。以下检查项用于在试点结束时逐项核对，全部通过才判定本轮改进完成。
- 目标做法写入团队工作约定：新做法已写入团队的工作约定或过程说明文档，团队新成员可以据此执行，而非只存在于会议纪要中。
- 试点期间按新做法执行并有过程记录：抽查试点周期内的工作项，能查到对应的评审记录、交接确认或过程证据，记录时间与实际执行时间一致。
- 改进前后证据可对比：基线数据与试点数据采用同一口径收集，对比记录中写明了观察指标、样本范围和结论。
- 未达标项有明确处置方式：对未达到预期的部分，写明了是调整做法、延长试点还是停止，并指定了跟进责任人。
阻断项需要单独强调：没有过程证据、没有明确责任人、没有可核对的完成标志，三者任一缺失，本轮改进不得判定为完成。此时应回到步骤二补充定义，而不是用“基本达成”之类的表述结项。
把改进沉淀为可复用的过程资产
试点通过后，改进成果需要从“这个团队的做法”变成“组织可复用的过程资产”，否则人员变动或项目切换后做法容易丢失。
写成过程说明或工作约定文档
把验证过的目标做法整理为过程说明，写清适用场景、输入物、执行步骤、输出物和完成标志，并附上试点中总结的常见问题和处理方式。文档放在团队日常查阅的位置，与现有过程文件保持一致的编号和版本管理。
关键节点落到可追踪的工作项与文档状态上
评审、交接等关键节点如果只靠口头约定，执行情况难以核查。可以把这些节点对应到工作项的状态流转和文档的评审状态上，使“是否完成评审”“交接是否确认”可以从系统中直接查看。ONES 效能管理提供效能管理实践体系，支持对系统中产生的研发数据进行多维度分析，帮助团队进行效能的持续改进；其应用场景中列有 CMMI 研发过程改进度量。对于需要观察改进前后过程指标变化的团队，这类基于系统内流转数据的分析可以作为证据收集的辅助手段，具体配置方式需结合团队实际的工作项设计确定。
用统一台账记录改进项
建立改进台账，逐条记录改进项名称、问题陈述、责任人、试点团队、证据位置、结论和推广状态。台账由过程改进接口人维护，过程负责人定期查看。台账的作用是让多轮改进之间可以追溯：上一轮调整过的做法，下一轮是否仍然有效，都能从台账中找到依据。
分批推广并保留反馈入口
推广按团队分批进行，每批推广前说明新做法的适用条件和证据要求，推广后保留一个反馈周期，收集团队在执行中遇到的障碍。对反馈中反复出现的问题，回到动作卡调整定义，而不是要求团队自行消化。推广批次计划中写明每批的团队范围、开始时间、观察指标和反馈收集方式，使推广过程本身也可被检查和调整。
常见问题
团队规模小、没有专职过程改进人员，这套方法还能执行吗？
可以执行，但需要压缩角色和交付物。小团队中过程负责人和团队负责人常由同一人兼任，此时建议把“定义目标做法”和“组织试点执行”分开记录：定义时以团队负责人的身份写动作卡，执行时以试点执行者的身份记录障碍，避免自己定义、自己验收。质量或过程改进接口人的职责可以简化为一页改进台账，由团队内一名成员兼管，试点中期和结束时各汇总一次证据即可。
范围上更应坚持本轮只做1—2个问题。人手有限时，优先选择影响面明确、证据已在手边的问题，例如评审记录和缺陷记录中能直接查到的那一类，减少额外收集数据的工作量。
试点效果不明显时，应该延长试点还是直接停止？
先判断“不明显”属于哪种情况。如果是执行不到位，例如新做法只在部分工作项上执行、过程记录缺失，应先补齐执行再观察一个周期，这属于执行问题，不宜直接归因于做法本身。如果是执行到位但前后证据没有差异，需要检查观察指标是否对准了问题：问题陈述是需求理解偏差导致的返工，指标却只看整体缺陷数量，就可能掩盖局部变化。
调整后仍无改善，就按步骤五的结论写“停止”，并在台账中记录停止原因和已投入的成本。停止一轮改进是正常结论，把原因写清楚，可以避免下一轮重复尝试同样的做法。
改进做法推广到其他团队时，需要原样照搬吗？
推广时保留目标做法的核心动作和完成标志，执行细节允许按团队情况调整。例如需求评审改进中，“验收条件由测试角色确认”是核心动作，评审会拆成书面预审加集中确认还是单次会议确认，可以由各团队根据需求规模和会议习惯决定。推广前向接收团队说明适用条件和证据要求，推广后保留一个反馈周期，收集执行障碍。
如果多个团队反馈同一处做法难以执行，应回到动作卡调整定义，统一更新后再继续推广，避免各团队各自变通、做法逐渐走样。
改进台账应该记录到什么颗粒度？
台账以“改进项”为单位，一条记录对应一个已定义的问题和一组目标做法，不按单个工作项逐条记录。每条至少包含：改进项名称、问题陈述、涉及环节与角色、责任人、试点团队与周期、证据存放位置、结论（继续、调整或停止）以及推广状态。
台账的作用是让多轮改进之间可以追溯。上一轮调整过的做法在下一轮是否仍然有效，从台账中能查到依据。颗粒度过细会让维护成本超过收益，颗粒度过粗则无法判断某项做法是否经过验证，建议以“一个问题对应一组动作”为基本单位。
过程证据具体包括哪些材料，日常怎么积累？
过程证据是能证明新做法确实被执行的材料，常见的有：评审记录及确认状态、交接确认记录、工作项状态流转记录、缺陷分类记录，以及试点期间的简短执行反馈。证据要与动作卡上的完成标志对应，完成标志写“验收条件由测试角色确认”，证据就应是带确认人和确认时间的评审记录。
积累方式上，尽量让证据随日常执行自然产生，例如在工作项完成时同步提交记录，而不是试点结束后集中补记。补记的记录时间与实际执行时间不一致，在完成检查时会被视为证据不可靠。
