指责满天飞

想象一下这样的场景：当一个项目进入关键阶段，或者一个团队持续在高压力状态下工作时，突然出现的一个问题造成一些列的问题，每个人的工作进度都受到影响了，让整个团队都进入一个混乱的状态，大家开始互相指责和抱怨，团队的情况进一步恶化。

我曾经多次经历和目睹过类似的情况。当时团队已经连续高强度工作了多周，每天工作时间从 9 到 14 个小时不等，一个突发问题（测试环境数据库被某个工程师误删除了），扰乱了所有人的工作，团队的反应大概率是归咎于个人。

很明显，在这些持续高压工作条件一定会导致错误，只是碰巧是那个工程师手误删掉了数据库的事情发生了。

除了像上面描述的那样是一个紧急严重的问题外，把任何错误归咎于个人并不是一种有益于团的整体的行为。

很容易指责对模块进行最后更改或处理问题的人，只是有人被挑了出来。然而，这真的是问题所在吗？通常还有更深层次的问题存在。

背后的原因

为什么这个指责和抱怨问题会是影响团队效能和士气的一个重要问题呢，主要原因有以下几点：第一，第一个原因是因为它是低效的。指责和惩罚一个团队成员并不能解决当前的问题。处理问题的两个点是：第一个重点应该是解决这个问题；第二个重点应该是解决导致问题发生的根本原因。

第二，责备一个人会阻止你找出问题的根源。根本原因可能是过度工作、不适当的系统权限、不规范的发布过程、缺乏自动化、糟糕的测试策略，或者是这些问题的组合。如果不解决根本原因，你将再次遭受同样的问题。

第三，指责游戏只会进一步增加团队的压力和紧张。当错误被归咎于个人，或者更糟的是被公开指责时，这对开发者的参与和心理健康都是不利的。

最后，它忽略了软件开发的两个基本事实：

这就是为什么我们拥有QA团队、检查问题的工具、单元测试、发布过程等等。开发和测试，部署过程中的bug并不是一个人的失败的原因。

找出问题发生的根本原因是防止将来出现更多问题的关键。一旦确定了根本原因，就可以开始进行最有效的改进，以减少问题再次出现的可能性。

问题频发，导致团队互相指责抱怨的深层次的原因有以下几种：

第一，持续的高压工作会造成问题的频繁。如果是加班或是持续压力造成的，就需要看看你工作安排是否合理。众所周知，加班和压力会导致错误和效率降低。一旦这些错误出现，就会越来越频繁地发生。错误和决策失误的增加，实际上是在短时间内产出增加的情况下，加班会减缓发展的速度。

虽然许多研究都表明加班的最大有效时间可能是 3 周或 4 周。但我们必须记住，即使这是一个准确的时间范围，这些都是整个团队的平均值，并且会根据加班的程度而有所不同。有些团队成员不能坚持那么久，有些人会坚持更长时间。这完全取决于个人和他们的环境。安排日程时请记住这一点。

第二，导致问题频发的根本原因是流程问题，需要进一步优化流程。流程问题可以是不完整的流程、尚未发现的边缘案例、绕过流程的关键节点，或其他更多的原因等等。

技术团队构建或发布流程的目的是明确工作的步奏和规范。如果这个流程繁琐或耗时太长，就可能会被绕过。如果一个团队成员不熟悉这个过程，他们就不会很好地遵守流程。只是流程本身可能缺少一些关键步骤。

任何发布或构建过程的目标应包括：

第三，自动化不足，导致手工操作增加出错概率，在可能的情况下，流程中的所有步骤都应该自动化。如果没有人参与，就不会犯人类的错误。自动化所有可能的事情。从长远来看，自动化成本更低、更方便、更有效。

第三个原因可能是开发人员对系统的访问权限太多，而这是他们不应该拥有的。也许他们配置了太多的服务器，或者删除了错误服务器上的文件系统。不管是什么，都应该有适当的权限和配额来防止这类事故的发生。

许多开发人员可能会立即对这一对话视而不见。在太多的公司里，这场斗争花费了太多的时间来为开发者获得额外的权限，以使他们达到最大的生产力和使用他们所有的工具。作为一个开发人员，我知道受人喜爱的“管理权限”对开发人员有多大的好处。但适度的权限分离，可以避免掉很多严重的生产事故的发生。

首先，软件开发是一个复杂的系统工程，是一个需要团队协作才能更好完成的工作，在工作过程中出问题是不可能完全避免掉的。

对于频繁发生的问题，指责和抱怨某个人是不利于解决问题的。

解决问题更需要我们从根本上去分析和思考，找到问题发生的真实原因，从最本质层面去解决问题，例如，控制节奏和压力，建立优化流程，增加环境权限的区分，加强自动化等等。

指责和抱怨是一剂毒药，会严重影响团队的士气。 面对问题，团队整体要保持开放坦诚，管理者更要有效的引导团队积极解决问题。