【DIY小记】工作中失误了，应该如何对待？-Toy模板网

这篇具有很好参考价值的文章主要介绍了【DIY小记】工作中失误了，应该如何对待？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

今天整理博客时，恰好瞄到CSDN创作活动里，最近在搞这个主题：如何对待工作中的失误？笔者个人觉得，这个话题是非常有意义的，尤其是在现在经济形势不好，人人都担忧失业的情况下，怎么样对待工作的失误，甚至是工作本身，不论是从心态上，还是从策略（抓手）上，都是值得去深入讨论的。因此，笔者决定为【DIY小记】系列特别撰写一篇文章，来谈一下工作中失误了之后，到底需要如何对待。

那么接下来，就以CSDN创作模板里的几个问题入手，来讨论这个话题吧！

一、在面对失误而带来的指责和沮丧时，你是如何做的？

首先我们要厘清一点，尤其假设你是在打工，而不是作为一个老板。打工人聚在一起，是因为利益聚在一起的，业务好了大家一起吃大锅饭，业务不好那就得吃散伙饭。你的一个失误，实际牵动着的，就是整个业务的利益。被人指责，可能也在所难免；自己沮丧，本质也是因为自己的心力无法满足自己的责任感，也是情有可原。工作失误带来指责和沮丧，客观上都是合理的表现。

但是，不论是指责别人，还是自己沮丧，这两种行为对于避免失误这件事情，实际都是无用功。工作的内容本身，就是一件件问题的解决。而弥补工作失误，也是工作中需要解决的问题之一。

要解决这个问题，业务里相关联的同学都需要担起责任来，通力合作，建立防范机制，去让类似的失误不再发生。从自己的角度出发，就是得做几个事情：

止损，修复缺陷，解决面前的问题
事后集中复盘，看哪些环节出现了问题，优化大家后续的工作和配合方式

二、发生了失误之后，你是如何找到问题的？如何避免只看到表面现象而忽略了根本问题？

如何找到问题，第一块是需要反推什么时间点做了些什么，不只是你自己，也需要参考关联同学以及线上运作的时间线。把这些信息因素拼凑起来，就可能得到几种可能场景：

技术失误：我的代码本身就有bug，有些业务场景/技术细节没有考虑，导致有线上问题
业务失误：我做的事情，如果什么时候给A同学评估下，给B同学测试下，可能不会发生失误
无感知失误：X同学如果在什么时候早一点告诉我什么信息，我可能就不会做出这种行为，导致"失误"产生

这些就是所谓问题的"表面现象"了。其中的根本原因可能会是：

技术失误：技术设计/交接文档不规范，部分场景没有清晰说明
业务失误：缺乏标准上线流程，上线内容没有方案review机制
无感知失误：业务上下游缺乏信息互通渠道，上游变更影响下游感知不到

那么解决这些根本原因，就得：

技术失误：针对失误内容，重新review并彻底梳理清楚实现细节。并且，修复逻辑一步到位，防止实际只弥补了冰山一角。
业务失误：建立起文字版的上线流程和标准持续发布（DevOps）工作流，上线内容的需求背景、技术设计、Review审批记录、发布过程记录全部留痕。一来通过能让更多人感知，避免失误在线上呈现的可能性；二来如果真的有发生问题，通过操作留痕也能够方便回溯排查。
无感知失误：上下游建立联防联控机制，联合梳理上游变更影响下游的场景。上游建立变更周知机制，必要时增加演练环节，使得下游业务第一时间能感知变更风险，确立对策。

但不管怎么说，从合作的角度来讲，很多工作失误背后，可能是业务运作机制的问题，仅靠自己一个人，还是很难彻底解决问题的。说句实在话，要解决根本问题，还得靠所谓的拉通对齐，做好复盘，大家通力协作，打好组合拳。

三、在工作中我们应该怎么做才能降低失误率，分享一下你的工作技巧和方法吧！

笔者自己是程序员，针对这个问题，就从程序员角度来回答一下。

首先是程序设计/实现的方面。虽然面试里头经常会有八股文的出现，但在实际写业务代码当中，八股文代码的成分其实不会太多，更多的是我们需要通过代码，去模拟某一领域业务的运作过程。因此，我们需要了解业务本身的需求，最终呈现的效果，以及在实现过程中，需要定义哪些概念，每个概念之间联系是什么。把你要代码实现的东西，先在大脑上或者在草稿纸上过一遍，然后再填上代码，这样就能有效避免代码写到一半，发现实现有问题，再弥补也为时已晚的窘境。

这里还需要注意的是，我们在做架构设计的时候，可能是自顶向下的，也就是有一个目标，通过层层分解，来确定技术呈现的方案。但是我们在编码的时候，是自底向上的，首先要把每个细分模块实现了，然后层层堆积，从而达到最终的效果。因此，概念的定义，概念间的联系，一定要想好，才可以下笔。

然后是沟通交流的层面。业务里不同线的同学，掌握的信息是不一样的。如果你在编码时候有实现效果上的疑问，不妨和产品同学对一对，效果能不能满足需求；如果你对觉得代码里很多badcase很难一时梳理到，不妨问问测试同学，对一下用例，或者测一轮，看有什么具体的问题呈现；如果你不确定操作某个接口会不会有危险，不妨问问接口的开发人，或者接口下游的负责人，一起拉来看一下会不会有什么case没有考虑到，或许就能规避某一次危险的操作。

工作中很多令人纠结的问题，其实可能找对个人，聊一两句话就可以解决。有同学可能觉得，当社牛找人聊天，是一件困难麻烦的事情。但如果你是抱有"规避失误"的工作态度的话，当社牛找人聊天，才是工作中必须要做的事情。