无责文化在技术行业中并不是一个新概念。事实上，在 2012 年，John Allspaw 写了一篇文章，讲述了 Etsy 如何使用无责事后分析来深入问题的核心。其他技术巨头，如 Google，也努力实施无责文化。但是，什么是无责文化？它仅仅是事后分析吗？实现无责文化是否需要文化变革？那么，公然的不当行为又该如何处理呢？
探索无责文化
2009 年，Mike Rother 写了一本关于丰田文化的 获奖书籍，他在书中剖析了这家汽车制造商在 20 世纪如何取得如此巨大的成功，而当时大多数其他汽车制造商要么停滞不前，要么节节败退。关于丰田的书籍并不新鲜，但 Mike 探讨丰田成功的方式却很独特。他没有关注丰田实施的流程和程序，而是细致入微地解释了公司的文化，包括其对无责失败和持续改进的关注。
Mike 解释说，丰田在面对失败时，关注的是发生失败的系统，而不是追究谁的责任。此外，该公司将失败视为学习机会，而不是责骂操作员的机会。这正是无责文化的定义，技术领域仍然可以从中学习很多。
这不是文化转变
实现无责化不应采取高层倡议。我们需要改变的与其说是公司文化，不如说是我们对待错误和失败的态度。当然，公司文化应该改变，但是，即使在无责文化中，有些人仍然有根深蒂固的指责他人的冲动，并指出他人的缺点。
我曾经受雇于一家公司，负责开发和改进其数字足迹。这家公司聘请了自己的开发人员，你可以想象，有时会存在紧张关系。如果在生产环境中发现错误，会立即开始寻找责任人。我认为，想要找到人来责怪，这只是人之常情。但有一种更好的方法，这需要实践。
微观层面的无责化
当我谈论实施无责化时，我不是在谈论在公司和组织的规模上实施。这对我们大多数人来说太大了。相反，请将注意力集中在最小的规模：代码提交、代码审查和拉取请求。关注您自己以及您的同事和您领导的人员的行动。您可能会发现在这个领域的影响最大。
您或您的同事多久收到一次错误报告，深入挖掘以找出问题所在，并在确定是谁进行了破坏性更改后停止？您是否立即假设需要回滚拉取请求或代码提交？您是否联系该人员并告诉他们他们破坏了什么以及是哪个提交？如果这种情况发生在您的团队中，那么您离无责化就最远了。但这可以补救。
显然，当您发现错误时，您需要了解哪里出了问题、在哪里以及是谁造成的。但不要就此止步。尝试修复问题。修补代码很可能比试图找出要回滚哪个代码更快地解决问题。我曾多次看到人们试图回滚代码，结果却发现他们破坏了其他东西。
如果您不确定自己可以修复问题，请礼貌地请进行破坏性更改的人员协助。是的，协助！我妈妈常说，“用蜜糖比用醋能捉到更多的苍蝇。” 如果您请别人帮忙，而不是指出他们破坏了什么，通常会得到更积极的回应。
最后，一旦您有了修复方案，请务必让导致错误的人员审查您的更改。这不是为了让他们难堪。请记住，失败代表着学习机会，创建失败的人如果有机会审查您创建的修复方案，就会从中学习。此外，该人员可能掌握独特的细节和理由，表明您的更改可能修复了当前问题，但可能无法解决根本问题。
更快地发现公然的不当行为和滥用
如果有人明知故犯，无责文化并不能提供全面保护。但这并不意味着系统没有缺陷。还记得丰田如何关注发生故障的系统吗？如果一个人可以明知故犯地在其正在开发的软件中制造混乱，那么他们应该承担责任，但系统也应该如此。
在审查失败时，无论多么小，都要始终问：“我们如何才能更早地发现这个问题？” 您很可能可以改进软件开发生命周期 (SDLC) 的某些部分，以减少失败发生的可能性。也许您需要添加更多测试。或者更频繁地运行测试。无论解决方案是什么，请记住，修复错误只是完整修复的一部分。
评论已关闭。