探索质量外延 - 质量安全故事

故事1 - “我不是故意上传的……”

多年前，当时所在的公司为各类建筑工程提供项目管理系统。

研发部的项目经理大刚为刚入职的实施工程师小王提供了工时数据导入的测试表格文档，便于他熟悉工时管理系统的功能。小王拿到测试数据，在预发布环境进行了数据上传测试。

次日，大刚接到某大客户的重要干系人投诉：“你们怎么能随意上传真实的工时数据？” 大刚一边安抚客户，一边快速分析满脑子的疑问：数据是被谁上传的？在哪个环境上传了被客户看到？遍查一圈，发现这个事故有两个坑点：

1. 数据被新人小王误上传，原因是发给小王的测试数据里面包含了不该有的真实生产数据。

2. 小王在预发布环境测试，理论上客户不会看到这个数据。那客户是如何访问到预发布环境看到这份数据的呢？原来是研发经理张工把预发布环境地址和账号发给了客户，用于做客户侧的验收测试。

大刚揉着突突的太阳穴，紧急关停了预发布环境，删除了不该有的数据，并给客户创建了独立的测试账号用于验收测试，同时启动了这次事故的复盘。发生事故不可怕，问责个体或纠结情绪都无益于持续进步，及时处理并思考未来怎么避免再次发生，才是最大化事故价值的方式。大刚作为资深管理人员，这点觉悟还是非常具备的，于是带着团队进行事故复盘。

团队的进一步分析：

1. 大刚发送前未检查数据：这是表面现象，底层问题可能是新人的入职培训比较随意，没有一套成熟内容能让新人快速上手；另一方面也表现出数据管理相对混乱。
2. 小王上传时未检查数据：这也是表面现象，底层问题是小王未获得足够的知识，不足以判断各环境、数据的用途，进一步讲，现有环境不足以帮其快速建立起专业胜任力。
3. 客户在预发布环境做UAT，未建立独立的账号：同样是表面现象，底层问题首先是项目经理不知道客户被授权了预发布环境，然后是使用账号未隔离，不同多方人员使用相同的账号进行不同目的的测试，势必会造成混乱，这次的事故正好暴露了问题，不在这次暴露，以后也会在其他方面暴露这个问题。

针对不同的问题，分别制定改进项：

1. 制定新人岗位培训体系，为新人提供合适内容和环境进行安全的探索 - 项目经理大刚
2. 明确不同环境的用户和用途，盘点现有环境使用情况，进行“专物专用”改造 - 研发经理张工
3. 开展全体培训，对环境用途、不同环境用户管理和使用申请流程等信息进行全员同步，务必确保信息透明和及时同步 - 项目经理大刚
4. 编写系统使用入门指南，持续维护并用于后续培训和学习过程 - 新人实施工程师小王

经过这次复盘和改进，研发部再也没有发生过类似的事故，这真是从失败中学习和成长的优秀典范。另一方面，这个故事也充分说明，流程实践的不规范或缺失，非常容易引发类似的项目事故，降低外部对我们产品质量、项目管理乃至专业度的信任。 而信任的构建何其艰难，破坏它却只一件事即可。这样深远的长久损失是我们不愿看到的。

尚未建立规范的团队，可以防患于未然，基于风险建立高质量的过程管理办法，同时增强团队成员间的协作和信息透明度。而已经发生事故的团队，也可以学习其中的经验，通过事故复盘、提升过程质量、精细化管理等手段来避免事故再次发生。

故事2 - “防我之术，皆可为我所用。”

这个故事来自于社区朋友的分享，原始出处难以追溯：

我非常喜欢这个故事，惊叹于人类发挥在孜孜不倦薅羊毛上的聪明才智。如果我们也像故事1中那样来拆解这个故事线，会发现其中的明线暗线非常满足一个好故事的必备要素，起承转合，精彩纷呈。

进一步分析，黑客之所以成功的关键在于，他能发现看似不相关的登录业务和竞拍业务之间隐秘的关联，利用登录业务的正常功能去攻击拍卖业务的逻辑漏洞，行云流水一气呵成。而我们在设计、研发和验证业务逻辑的时候，都相对局限在当下的业务中，没有用全局视角整体审视业务之间的关联，进而产生能被别有用心之人所利用的业务逻辑缺陷。

这个故事告诉我们，不了解业务之间的关联，只是在局部优化和增强，也非常容易引发质量问题或安全漏洞。

探索质量外延

在管理复杂度高的项目中，提升质量的有效方式在于提升过程的精细化管理，把可能造成风险的因素扼杀在全程可控可追溯的完善流程中。

在做日常的业务增强时，每新增或变更一个功能，都需要考虑和原有业务之间的关联，思考业务、用户、数据等因素内部或彼此之间的相互关系，有助于预防深层次的意想不到的重大缺陷，从而获得较好的质量。