敏捷测试转型 聊聊 Checklist-清单革命

鼎叔 · 2026年03月24日 · 440 次阅读

这是鼎叔的第一百三十八篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。
欢迎关注公众号《敏捷测试转型》,星标收藏,大量原创思考文章陆续推出。
人类的错误可以分为两大类,无知之错和无能之错。前者是因为我们没有掌握相关知识,后者是因为我们没有正确地使用已掌握的知识。
“无知之错” 可以原谅,只要人们尽力了,无论结果如何,我们都能接受。但 “无能之错” 不被原谅,如果人们明明知道该怎么做,却没有做到,这类错误很难让我们不暴跳如雷。
在很多复杂知识领域,我们所掌握的知识量已经超出了个人稳定发挥其功效的能力范围。因此,我们急需一场简单又伟大的清单(Checklist)革命来防止错误。
本文部分观点借鉴了《清单革命》一书,作者 Atul Gawande。

研发团队线上质量 checklist 有哪些常见问题
在分享清单革命知识前,我们先盘点下,研发团队针对线上风险或事故的 checklist 处理,经常踩的三个大坑有:
一 盲目套用其他团队的风险清单。不同金融业务模块,涉及的风险模型可能大不相同,比如 “合规报送模块”,“反欺诈模块”,“资产更新模块”,面对的线上风险场景可能完全不同。如果盲目套用其他团队的清单,可能导致很多检查项不适用,或者清单过长,使用效率低,从而形成团队敷衍应对的状况。
二 正确的废话。这点是鼎叔最常在复盘会议中反复提醒的。一遇到线上的严重缺陷,团队就会在清单中添加 “一定要做好自测”,“一定要做 code review”,“一定要补充边界值用例” 这种话,基本都是 “正确的废话”,针对一线员工没有把控效果。一线团队的清单动作一定要明确圈出场景(关键词),比如补充边界值用例,是什么场景的边界值。
三 难以保障执行。1,事故记录信息缺乏可追溯性,未强制记录关键信息,导致后继复盘中无法定位责任或还原问题场景。2,复盘提出的改进措施没有自动化保障机制和监督落实的责任人,会议上聊得热热闹闹,后继执行轻描淡写。3,跨部门协作的行动措施边界没有定义清楚,整改信息传递断层。

观念的变革
软件工程,智能硬件,医学,法律,航天等等,很多学科已经变成掌握极端复杂性的艺术,它考验人类能否驾驭这种复杂性。实际上,即使超级专家也难免犯错。无论分工多么细致,培训多么充分,一些关键的步骤还是会被人忽略。
清单从来不是大而全的操作手册,而是理性选择后的思维工具。抓取关键点比 “大而全” 更重要,这也是高绩效的保证。
但是人们会有一个固执想法:坚持认为自己的工作太复杂了,根本无法将其缩减到一张卡片上。
所以我们经常看到技术团队要么没有 checklist,要么就做出洋洋洒洒的超长表格。
从本人的亲身感受来看,在事务繁忙的情形下,确实很容易忽视一些单调的例行工作,比如管理者忘了定期和下属一对一的沟通。更有甚者,故意跳过一些明明记得的步骤,专家会认为这些清单检查步骤是助手们应该关注的无聊之事。
世界上的复杂问题解决过程,会带来非常大的不确定性。很多不同领域案例的影响因素看似非常不同,但核心问题都是一样的 - 如何集中注意力。我们通过清单来塑造行为,用直接的方法迫使必要行为的发生。
清单的制定并不容易。再好的清单也很难在事前就预测好各种情况,并准备好相关的处置程序。我们希望不犯低级错误,同时还要为随机应变和主观判断留出足够的时间。
以建筑业为例,从 20 世纪中叶开始,建造大师就从历史舞台上消失了。因为现代建筑过程每个阶段的复杂性和多样性早已超过了个人能力的极限,所以建筑设计和工程设计就开始分道扬镳,并不断进行细分和演进。建筑行业没有犯错的余地,出了问题可能意味着很多人要送命。在过去的几十年中,建筑领域的最大进展就是进程跟踪和沟通过程的不断完善。
专家们用一套清单来保证不遗漏简单问题,不跳过简单的步骤;再用另一套清单来保证所有专家都对困难或意料之外的问题进行充分讨论,商讨出解决方法。
类比我们软件服务行业:既有产品研发上线流程的检查清单,也有线上事故爆发时的应急响应清单,后者更需要快速充分的群体沟通。
如果让合适的专家聚在一起,作为团队来充分讨论(而不是作为个人),那么很多严重的问题是可以被避免的。面对未知,团队沟通的力量比经验丰富的个体更值得被信任。

清单革命的执行原则

谁来主导清单执行?
团队中的管理者,如果不放权,清单行动就会遭遇失败。当公司或政府遇到可怕灾难,无政府状态或官僚主义都会让事情变得更糟。
所以,每个人都应该是清单的主宰者和参与者。每个人都要做出超出自己级别的决定,务必根据掌握的信息做出最佳的选择,做自己认为正确的事。
公司高层或组织把工作重点放在设定目标和监控进度,以及保持各方联络上,但针对具体的危机不会发布具体的指令。事无巨细都由最高层定夺是注定要失败的。
一线团队使用清单查漏补缺和高效沟通,也使用它来提高主观判断的质量,在极端复杂情况下,清单是团队取得成功的必要条件。
对于强调高质量客户服务的领域,如餐饮,清单是保障餐厨正常运转的关键纪律,而厨师团队在面对客人突发情况时,也会按照沟通清单进行高效协作。
所有行业都能找到清单的用武之地,不管是需要高度个人技能的,还是分工极其细致的行业。

清单的简单、可测与高效
观察不同行业的清单实践成功案例,可以发现:它们采取的干预措施都非常简单,比如 “强制接种疫苗”,“医生手术前一定要洗手”,“卫生状况低的地区使用免费香皂”,“移除污染源的接触把手”,这些措施都能被准确的测量,因此措施的投资回报率非常高。
这些方法听起来毫不起眼,甚至有些搞笑,但是效果非常显著。
简单措施能成功的秘诀就是:通过杠杆动作(如发放免费的香皂),改变人的行为(正确的洗手方法),进而教育他们改变自己的传统理念(洗手能大幅降低疾病发生概率)。这也是系统思考的精髓。

会前简报
没有任何一张清单能囊括所有意外情况,因此前文提到 “团队沟通清单” 非常重要。而团队高效合作的阻力,来自细致分工下形成的 “事不关己,高高挂起”。这种想法对于复杂高风险项目是非常危险的。
我们不能割裂得看待各项任务的份内职责,而是应该为了更好地实现团队目标而贡献力量。
清单中最好有一个会前简报环节,团队花一点点时间在项目开始前进行简短讨论,这是促进合作效果的好方法。尤其是事前没有充分合作的同事,可以快速认识对方,俗话说:不知道彼此姓名的人往往不能很好的合作。而且一旦让人有机会发言,会增强他主动参与和表达观点的积极性,增强对任务的责任感。

清单中的 “非正常” 应急情况
清单中除了正常操作的主要动作和注意事项以外,更多是 “非正常” 清单,针对各种能想到的紧急情况设计正确的操作流程,有些紧急情况可能一辈子也遇不到,但万一遇到了,就能依靠清单化解危机。这对于高风险行业特别重要。

人是解决问题的主角,而不是清单
清单有好坏之分,我见过一些平庸的清单,冗长,模糊,也不方便使用。优秀的清单应该是非常精确和高效的。它只提醒最重要事情,帮助专家记忆复杂且关键的操作,它具备这样的特征:
清晰的检查点,清晰的版式。
不能太长。
明确是 “确认” 型还是 “边读边做型”。
用熟悉的专业语言,精炼准确。
经历过多次实践。
而人,要最终决定关键时刻该做什么,并在结束后优化清单,让事故的教训转变为清单的实用性。团队从在实践中发现新的知识,到转化成简单实用的操作方法,需要经历一个过程。这就需要人的积极行动。

谁负责让团队停下来执行检查程序?
如果把清单所有责任都给到一个专家或 leader,效果并不好。以航空为例,负责启动检查程序的人是 “不把杆的飞行员”,把杆的飞行员可能忙于各种操作而无暇顾及清单检查。
所以,清单执行的原则是让更多人分担责任,并分享提出质疑的权利。

清单的持续进化
对于执行中的清单进行改进,很有必要,也不容易取舍,因为简洁和有效之间存在矛盾。删减的项目过多,对安全性重要的许多步骤就无法检查。如果保留的项目太多,清单就会越来越冗余,难以使用。
如何从大型组织中评测新清单的价值?
我们需要参与清单试验的团队有比较强的语言沟通能力,且团队处于一个安全的运营状况。该试验团队能代表广泛的多样性,并承诺在清单投入的前后进行客观的对比数据调查。我们也希望试验团队能用自己的耐心和经验对清单进行必要的修改,而不是不经努力就彻底否定它。
当清单取得了显著的数据效果,我们也不要高兴得太早,我们需要分析这种进步是否属于巧合,或者是霍桑效应(即:因为被外人观察,所以团队处理事情更加小心和积极,导致测试结果提升)。
事实证明,团队合作质量改善得越多,项目的问题发生率就下降得越多。这样,团队成员才真正愿意接纳清单。

让清单成为习惯
我们的目标并不是让专业人士在清单检查项旁边乖乖打勾,而是要培养专业团队的合作纪律,这种压力可能迫使我们大胆改变传统文化,甚至改变人们的核心价值观。如果缺乏勇气和随机应变的能力,光靠清单是无法完成重大挑战的。
每 50 次检查可能有 49 次一无所获,但其中一次发现却能让你避免重大损失。
投资家的投资清单能够帮助他在投资过程的每一步保持冷静而睿智的头脑,获得所需的所有重要信息,系统化地决策,并和每个应该沟通的人充分交谈。
因此,清单是一个效率工具,它也可以让专业人士提高决策效率。
我们会经常认为,那些在千钧一发之际沉着冷静的大英雄从不循规蹈矩,从不使用清单这种简单道具,这显然是想当然了。
人们之所以不喜欢执行清单,是担心自己变得死板。但是我行我素不应该成为我们追求的理想。为了获得用户的信赖感,成为有职业精神的无私的人,我们必须遵守纪律,为此付出一定努力。
人类赖以生存的很多系统已经演进得非常复杂了,新科技又增加了系统的复杂性,为我们提供了新的犯错机会,所以清单制定也需要与时俱进,从整个系统的视角进行优化。

最后:清单革命对软件团队的线上问题处理的启发
一,区分边读边做 “Read-Do List” 清单,和操作/确认 “Do-confirm” 清单。前者适合流程固定的强制执行过程(如编包,发布),后者适合多方验证的过程(如上线前检查,上线后检查)。
二,保障团队沟通的效果。由于大型需求都是跨部门的研发团队协作,清单如果只保障 “各自执行到位”,无法防范复杂的长链路问题,因此清单革命强调要定义团队沟通的时机和力度。
三,聚焦 “关键风险点”,精简清单避免冗余。清单革命强调:不做 “所有步骤的流水账”,而是做 “关键薄弱点的集合”。基于历史问题和经验的 “风险场景地图”,可以筛选出高频检查点,未来鼎叔会输出专门文章来论述。同时,排除 “低风险常规问题”,这类动作应通过自动化保障,而不占用团队处理清单的精力。

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册