研发质量责任制度

把质量责任前置,让每一次马虎都有成本

制度不是为了事后发火,而是让产品、设计、开发、测试和负责人在上线前形成同一条质量防线。能发现却没发现,就要承担责任。

上线质量防线 越早发现,成本越低;越晚暴露,责任越重 产品/UI 需求与界面 开发 实现与自测 测试 验证与回归 负责人 Review 验收 线上暴露 = 责任启动 运营发现 ×1 老板发现 ×2 用户反馈 ×3

制度要解决的不是一个 Bug,而是一种习惯

反复提醒和事后批评解决不了质量问题。要让团队改变,就必须把责任、成本、奖励和红线写清楚,并且每次都执行。

01

马虎变成默认工作方式

文案、对齐、跳转、权限、数据等小错误反复出现,团队默认认为“有人会帮我兜底”。

02

管理层被迫像保姆一样补漏

问题上线后才被发现,管理层不断擦屁股、催改、批评,时间和精力被低级错误消耗。

03

客户和用户承担后果

严重问题会影响支付、登录、注册、数据和核心功能,最终损害客户信任和公司口碑。

共同责任制:能发现但没发现,就承担相应责任

默认责任链覆盖需求、设计、开发、测试、负责人和技术管理。责任不是无限连坐,而是按岗位能否发现、是否尽责来划分。

产品
15%
需求、规则、验收口径
UI
10%
视觉、交互、一致性
开发
35%
实现、自测、代码质量
测试
20%
用例、回归、边界验证
负责人
10%
Review、检查、验收
技术负责人
10%
流程、规范、统计
示例:处罚 300 元时,产品 45 元,UI 30 元,开发 105 元,测试 60 元,负责人 30 元,技术负责人 30 元。若能明确根因,可按实际责任调整。

问题分级:小错不放过,大错有重责

分级的目的不是把所有问题都当事故,而是让每类错误都有清晰成本,避免小问题被长期纵容。

A

轻微问题

50-100 元

主要是视觉、文案和细节错误。

文案错误 图片错误 图标错误 字体大小 间距对齐
B

普通问题

100-300 元

影响单个功能或正常使用路径。

按钮不可点 跳转错误 功能失效 数据错误 权限错误
C

严重问题

300-600 元

影响核心流程或大量用户。

支付异常 注册异常 登录异常 数据错误 大量用户受影响
D

重大事故

600-1000 元

影响系统可用性、数据或资金安全。

网站打不开 数据丢失 资金异常 大面积不可用

发现越晚,责任越重

制度鼓励团队在内部发现并修正问题。开发、测试、负责人阶段发现并修复,原则上免责;上线后才暴露,责任启动。

开发自发现

自己发现,自己修正,鼓励自检。

免责
测试发现

测试发现后开发修改,问题仍在内部消化。

免责
负责人发现

Review 或验收阶段发现,修改后不上线。

免责
运营发现

上线后内部运营发现,说明质量链已失守。

×1
老板发现

本应被团队发现的问题由管理层发现。

×2
用户反馈

客户或用户受影响,口碑和信任已经受损。

×3

责任调整:按真实根因分配,不搞平均主义

默认比例用于快速执行;若能明确根因,则按具体场景调整,让真正的问题源头承担更高责任。

产品需求错误

需求描述、规则定义或验收口径错误导致问题。

产品
60%
开发
10%
测试
20%
负责人
10%

开发写错

实现逻辑、接口调用、边界处理或代码质量导致问题。

开发
60%
测试
20%
负责人
10%
技术负责人
10%

测试漏测

用例覆盖不足、回归遗漏或关键路径未验证导致问题。

测试
60%
开发
20%
负责人
10%
技术负责人
10%

上线审批错误

未检查、未验收、流程放行不严导致问题进入线上。

负责人
40%
技术负责人
40%
开发
10%
测试
10%

UI 设计错误

设计稿错误、交互遗漏、视觉规范错误导致重大问题。

UI
60%
产品
10%
开发
10%
测试
10%
负责人
10%

技术规范/流程缺失

Review、监控、回滚、权限或上线流程缺失导致事故。

技术负责人
50%
负责人
25%
开发
15%
测试
10%

重复问题:同类错误不能反复发生

制度重点打击“知道错还继续错”。30 天内同类型问题反复出现,处罚倍数逐级增加,并进入绩效管理。

第一次

正常处罚,完成复盘并修正流程。

1.5×

第二次

30 天内同类型问题,按 150% 执行。

第三次

说明纠错无效,按 200% 执行。

绩效

第四次

进入绩效考核,处理工作习惯问题。

有罚也有奖:把认真做事变成正收益

制度不是只处罚。提前发现问题、长期保持线上质量、提出有效优化,都应被明确奖励。

一个月无线上 Bug

500 元

鼓励团队把问题拦在线上之前。

连续三个月无线上 Bug

1500 元

奖励稳定质量,而不是偶尔认真。

发现重大 Bug 避免上线

100-500 元

越早拦截,越应该被奖励。

优化建议被采纳

50-300 元

鼓励主动改善流程和质量。

一票否决红线

以下行为不是普通失误,而是破坏流程、破坏信任、破坏安全。直接 1000 元,并进入绩效。

  • 明知 Bug 仍然上线
  • 未经测试直接上线
  • 私自修改线上代码
  • 删除数据库或关键数据
  • 跳过审核流程
  • 故意隐瞒 Bug
  • 修改代码不提交记录
  • 伪造或缺失验收记录

执行闭环:每个问题都要留下证据和改进

处罚只是手段,真正目标是让团队从问题中改变。每个线上问题都要走完整闭环。

1

记录问题

记录发现人、发现时间、影响范围、截图或日志证据。

2

定级定责

按 A/B/C/D 定级,并确认责任链中哪些岗位应发现。

3

处理奖惩

按等级、发现阶段、重复次数和责任比例执行。

4

复盘改流程

更新检查清单、测试用例、Review 标准和上线流程。

负责人和技术负责人的责任

负责人不是只安排人,而是质量负责人。技术负责人不是只看架构,而是要保证规范、流程和数据持续运转。

负责人责任

没 Review、没检查、没安排测试、没验收,均承担负责人责任。负责人要对交付质量负责,而不是只对进度负责。

技术负责人责任

负责开发规范、上线流程、Review 制度、Bug 统计和测试规范。制度缺失导致事故,承担管理责任。

老板发现加倍

运营能发现的问题,如果技术链路没人发现却由老板发现,说明责任链整体失守,处罚按 2 倍执行。

合规落地提醒:本制度涉及处罚金额、绩效和奖金等执行方式。正式落地前,应由 HR/法务结合所在地劳动法规、员工手册、劳动合同和员工确认流程审查后执行。