ASPICE过程责任要解决的是把过程域要求落到具体角色、交付物和证据上的问题。常见做法是以过程域为单元指定过程负责人，把实践要求拆成活动，再逐项对应执行角色、评审角色和证据位置，形成可核对的责任表。本文给出建表步骤、字段规则、填写示例和落实检查方法，并在日常协作承载部分说明如何借助ONES的工作项与文档能力保持可追溯。
要点总览（TL;DR）
- ASPICE过程责任以过程域为划分单元，每个过程域指定一名过程负责人，再把实践拆成活动，逐项落到执行角色、评审角色、交付物和证据位置上。
- 过程责任表至少包含过程域、活动、执行角色、评审角色、交付物、证据位置、完成状态和复核节点八个字段，执行角色与评审角色原则上分离。
- 一人多岗时把角色重叠显式记录在责任表中，并用跨过程域互评或上级评审补充确认，未记录的重叠才是风险。
- 责任落实按过程域抽查：核对责任行与证据是否对应、角色能否指认到人，在里程碑处由过程负责人复核，结论分为通过、需整改和阻断三档。
- 把每条活动建为工作项并关联交付物文档，状态流转与评审记录留在同一记录链上，可用ONES的项目管理与知识库承载。
ASPICE过程责任的核心答案与建立步骤
ASPICE过程责任的划分单元是过程域，而不是部门或岗位。一个过程域（如软件需求分析、软件架构设计、软件单元验证）包含若干基本实践和管理实践，这些实践需要有人执行、有人评审、有人保管证据。按部门划分容易出现“部门都管、实践没人认领”的空档；按过程域划分则能保证每个实践都有明确的责任归属，再通过角色映射到具体人员。
从过程域推导到责任行，可以按以下五步执行。每一步都说明输入、动作、输出和完成标志，便于团队按序推进。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定过程域范围 | 项目适用的ASPICE过程域清单、项目类型与裁剪说明 | 确认本项目需要覆盖哪些过程域，标注适用与不适用及理由 | 过程域适用范围清单 | 每个过程域都有“适用/不适用”结论和依据 |
| 2. 拆解过程实践为活动 | 所选过程域的过程要求、组织过程定义 | 把每条基本实践和管理实践翻译成可执行的活动，一条实践可拆成多个活动 | 活动清单，标注对应实践编号 | 每条实践至少对应一个活动，无遗漏 |
| 3. 指定过程负责人 | 活动清单、组织角色设置 | 为每个过程域指定一名过程负责人，明确其对符合性和证据完整性的责任 | 过程域—负责人对应关系 | 每个过程域有且仅有一名负责人 |
| 4. 分配执行与评审角色 | 活动清单、人员技能与授权 | 为每个活动指定执行角色和评审角色，确认两者独立性 | 活动—角色对应关系 | 每个活动都有执行角色和评审角色，且不违反独立性要求 |
| 5. 确定交付物与证据位置 | 活动清单、组织证据管理规范 | 为每个活动写明产出物、证据存放位置和完成状态判定口径 | 过程责任表初稿 | 每个活动都有可指认的交付物和证据位置 |
五步完成后形成过程责任表初稿，在项目启动会上确认，并在里程碑处复核。需要说明的是，过程域范围与裁剪结论应依据项目实际和评估范围确定，本文不涉及具体评级结论。
过程责任表的字段设计与填写规则
责任表的价值在于能直接回答“谁做、谁审、产出什么、证据在哪、什么状态算完成”。字段设计围绕这五个问题展开，字段过多会增加维护负担，过少则无法核对。建议采用以下字段结构。
| 字段 | 填写口径 | 常见填错方式 |
|---|---|---|
| 过程域 | 填写ASPICE过程域名称与编号，与组织过程定义保持一致 | 只写中文简称，与评估用过程域清单对不上 |
| 活动 | 一条可执行的动作描述，标注对应的实践编号 | 直接抄实践原文，无法判断具体做什么 |
| 执行角色 | 承担该活动的岗位或角色名称，写到可指认到人的粒度 | 写“研发团队”“项目组”等集体名称，无人真正负责 |
| 评审角色 | 对该活动产出进行评审确认的角色 | 与执行角色填同一人且无说明 |
| 交付物 | 活动产出的具体文档、记录或数据，写名称和类型 | 写“相关文档”“必要记录”等模糊表述 |
| 证据位置 | 交付物存放的库、目录或系统位置，写到可检索的层级 | 只写“已归档”，评估时找不到具体条目 |
| 完成状态 | 定义该活动完成的判定口径，如“评审通过并归档” | 写“已完成”，未说明以什么为完成标志 |
| 复核节点 | 该责任行在哪个里程碑或评审点被复核 | 留空，导致责任表建完即束之高阁 |
填写时有几条规则需要坚持。执行角色与评审角色原则上分离，评审的角色是独立确认产出满足要求，同一人既执行又评审会削弱确认的有效性。交付物和证据位置要写到可检索的粒度，评估或内审时能按表直接调取。完成状态必须是可观察的条件，例如“评审记录已签署并归档”，而不是主观判断。复核节点要与项目里程碑对应，让责任表在项目推进中被反复使用。
角色分工：过程负责人、执行角色与评审角色
过程责任涉及三类角色，职责边界清晰才能避免责任空转。过程负责人对某个过程域的整体符合性负责，包括该过程域活动是否按定义执行、证据是否完整可追溯、发现的不符合项是否闭环。过程负责人通常不直接执行全部活动，其核心动作是组织过程域内的责任确认、跟踪证据状态和在复核节点上做出判断。
执行角色负责按活动要求完成具体工作并产出交付物，对交付物的内容和提交及时性负责。评审角色负责独立检查交付物是否满足要求，给出通过或退回的意见并留下评审记录。两者的分工体现在动作上：执行角色提交，评审角色确认，确认结果形成记录。独立性要求意味着评审角色不应由同一活动的执行者担任；当组织规模小、人员有限时，可以通过跨过程域互评、上级评审或引入独立评审人等方式保持确认的有效性。
一人多岗在小型团队中难以避免。处理方式是把重叠情况显式记录在责任表中，例如在评审角色栏注明“因人员配置由XX兼任，采用跨项目互评补充”，并在复核时重点检查这类活动的证据质量。角色重叠本身不构成问题，未记录、未补充确认手段才是风险来源。交接动作也要写清楚：执行角色完成交付物后以什么方式通知评审角色、评审意见如何反馈、退回后由谁修订，这些交接规则应随责任表一并确认。
示例：一个过程域的责任表填写示范
以软件需求分析过程域为例，示范从要求到责任行的填写方式。以下为演示情景，活动与角色名称可按组织实际调整。
| 过程域 | 活动 | 执行角色 | 评审角色 | 交付物 | 证据位置 | 完成状态 |
|---|---|---|---|---|---|---|
| 软件需求分析 | 收集并整理利益相关方需求，形成需求来源记录 | 需求工程师 | 系统工程师 | 利益相关方需求清单 | 需求库/来源记录目录 | 评审通过并归档 |
| 软件需求分析 | 编写软件需求规格，标注需求属性与追溯关系 | 需求工程师 | 架构师 | 软件需求规格说明书 | 需求库/规格文档区 | 评审记录签署，追溯链接完整 |
| 软件需求分析 | 分析需求并建立与系统需求的追溯 | 需求工程师 | 系统工程师 | 需求追溯矩阵 | 需求库/追溯视图 | 双向追溯无缺口 |
| 软件需求分析 | 评审需求变更并更新基线 | 需求工程师 | 变更评审组 | 变更评审记录、更新后的基线 | 变更记录库/评审记录 | 评审结论明确，基线已更新 |
评审记录的写法要能体现确认过程：记录评审时间、参与角色、检查项、发现的问题、结论（通过/有条件通过/退回）以及问题关闭情况。完成状态与评审结论挂钩，例如“有条件通过”时需注明遗留问题的关闭证据位置，问题关闭后才转为完成。
从这个示例可以提炼几条迁移规律。活动描述以动词开头，指向一个可交付的结果；每条活动都对应到具体实践，便于回溯覆盖情况；交付物名称具体到文档类型，证据位置写到目录层级；完成状态写成可观察条件。换到软件架构设计、软件单元验证等其他过程域时，字段结构和填写口径保持一致，只需替换活动内容和角色名称，这样整张责任表在项目间具有可比性。
责任落实的检查方法与完成标准
责任表建好不等于责任落实。检查的目标是确认表上的每一行在项目中真实发生，并且证据可调取。检查按过程域抽查，而不是逐行普查，抽查比例可根据项目风险和里程碑确定。
- 责任行与证据对应检查：从责任表随机抽取若干活动，按证据位置调取对应交付物，核对交付物内容、评审记录和完成状态是否与表中一致。抽查覆盖每个过程域至少一条执行活动和一条评审活动。
- 角色可指认检查：核对执行角色和评审角色能否对应到具体人员，一人多岗的活动是否有重叠记录和补充确认手段。
- 里程碑复核：在项目关键里程碑处，由过程负责人对照责任表复核本过程域活动的完成状态和证据完整性，形成复核记录；复核发现的问题进入整改跟踪。
- 变更同步检查：过程域范围、角色或交付物发生变更时，检查责任表是否同步更新，避免表与实际执行脱节。
检查结论可分为三档。通过：抽查活动均有对应证据，评审记录完整，完成状态与证据一致，角色可指认。需整改：证据存在但评审记录不完整、完成状态判定口径不一致或角色重叠未记录，限期补充并在下次复核时验证。阻断：关键活动无证据、执行与评审由同一人承担且无补充确认、或责任表与项目实际执行明显脱节，此时应暂停相关里程碑的放行，完成整改后再复核。三档标准应在项目启动时与团队确认，避免检查时临时解释。
用工作项与文档承载过程责任
责任表如果只存在于电子表格中，活动执行、评审和证据归档仍分散在邮件和本地目录里，追溯成本会随项目推进不断上升。把责任表落到日常协作工具中，可以让角色、交付物和证据保持同一条记录链。
具体承载方式可以这样设计：把责任表中的每条活动建为工作项，工作项上指定执行角色和评审角色，并关联所属过程域；交付物以文档或附件形式挂接到对应工作项，证据位置即工作项下的文档区，避免另建目录造成两套记录；状态流转按“待执行—待评审—评审中—已完成/退回”设置，评审意见和结论作为记录保留在工作项上，退回时回到待执行并保留历史。这样从活动到交付物、从评审到完成状态形成可追溯链条，检查时按过程域筛选工作项即可核对。
ONES在ASPICE场景下的方案描述提到，其研发管理加ASPICE解决方案第一阶段为线上化建设，支持汽车软件研发全生命周期流程活动，支持跨域协作全过程的可追溯性；方案层面的功能模块组合包括项目管理、知识库、工单管理、资源管理、测试管理和效能管理。对于本文的责任承载需求，可以用项目管理承载过程活动工作项与状态流转，用知识库存放交付物与评审记录，使责任表中的证据位置对应到具体文档条目。团队在选型或配置时，应结合自身过程域范围和证据管理规范确认字段与流程设置，具体版本与部署方式以实际环境为准。
常见问题
过程负责人需要亲自执行过程域内的活动吗？
通常不需要。过程负责人的核心职责是组织本过程域的责任确认、跟踪证据状态、在复核节点上判断符合性，并对发现的不符合项推动闭环。具体活动的执行由执行角色承担，产出由评审角色独立确认。过程负责人可以同时承担部分活动的执行角色，但应在责任表中写明，避免复核时自己确认自己的工作。
项目裁剪掉某个过程域后，责任表要怎么处理？
裁剪结论本身要留痕。在过程域适用范围清单中写明该过程域“不适用”及理由，责任表中保留该过程域条目并标注裁剪状态，而不是直接删除。这样在评估或内审时能说明裁剪依据，也便于后续项目范围变化时恢复。裁剪理由应依据项目实际和评估范围确定，本文不涉及具体评级结论。
责任表建好后，项目中途角色调整怎么办？
角色调整时同步更新责任表中的执行角色和评审角色，并在变更同步检查中确认表与实际执行一致。已经完成的活动保留原角色记录和评审证据，不追溯改写；未完成的活动按新角色继续执行。若调整涉及评审独立性，需重新确认补充确认手段是否仍然有效。
用协作工具承载责任表，评估时怎么快速调取证据？
关键是让证据位置可检索。把每条活动建为工作项并关联所属过程域，交付物以文档或附件挂在工作项下，评审结论作为记录保留在工作项上。检查时按过程域筛选工作项，即可从活动直接跳到交付物和评审记录。ONES的ASPICE解决方案提到第一阶段为线上化建设，支持汽车软件研发全生命周期流程活动与跨域协作的可追溯性，方案模块组合包括项目管理、知识库、工单管理、资源管理、测试管理和效能管理，可作为承载方式的参考；具体字段与流程设置需结合自身过程域范围确认。
小型团队人员少，执行与评审无法分离时如何保证确认有效？
可以采用替代手段保持确认的独立性，例如跨过程域互评、由上级或质量角色评审、引入独立评审人。无论采用哪种方式，都要在责任表的评审角色栏记录重叠情况和补充手段，并在复核时重点检查这类活动的评审记录质量。角色重叠本身可以接受，缺少记录和补充确认才是需要整改的情形。
