本文主要是介绍工作失误回顾-2021年11月，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
我没想到这次做需求也栽了，也做个总结，正视自己。
背景：当时我负责的这块业务，指挥平台上的统计，一种费用，以下简称第一种费用，要包括另一种费用，以下简称第二种费用，然后由于某次需求，第二种费用从每月录入改成了按年录入。
带来的问题：因为指挥平台上，第一种费用有按月的统计，是那种折线图
原来费用1包括费用2是好说的，费用1可以做到按月统计，费用2也是按月录入，但是费用2改成按年录入后，这种的就做不了了。
对于那种按年统计的倒是不影响
当时的情况：当时是web后台和指挥平台都要做费用2从按月录入改成按年录入，开发也稍微有点紧，当时我在整理指挥平台上需求的时候，我是发现了这个问题，但是没有把问题反馈出来，而是稍微和产品做了私下沟通，后面在过进度的时候，我才在会议上说这里有问题，有些地方做不了，给测试人员带来了困扰。
结果：测试同事发现涉及费用2的统计有点问题，向我反馈，后面其他同事也知道了。
处理方式：项目组那边弄了一个修复需求来做。
处理后果：绩效被扣20%，下面是评价
总结：
不知道为什么，之前我喜欢做需求时就拉个小群，总觉得在大群里面沟通会对别人造成困扰，是别人不关心的东西，另外有种想隐蔽自己又不想隐蔽自己的心态，可能当时有一点点厌恶了吧，想隐蔽自己是说拉小群沟通，不在大群沟通，又不想隐蔽自己是说有问题又会主动找人，但是可能他人不知道。后面主管特意说了不要拉小群沟通，会造成信息不畅。
1.需求提前熟悉，避免重复全盘，浪费时间。
2.工时评估要再切合实际一点，这个在上一篇也说到了。
3.对复杂的模块要熟练再熟练，工作再细致一些，避免遗漏造成补充需求或返工。虽然也有一点奈的，我这边费用1和费用2基本每次都是大改，可能业务本身也多变吧。
4.不要拉小群做需求。
新的一年我调整工作状态，改进之前不好的工作方式，其实想想，高调做事，低调做人，不妨如此。别人对你可能并不关心，但你要做好自己的事，广泛沟通并没有什么，非常简单，是自己把自己圈起来了，没这个必要。于是我按照新的要求约束自己，关注代码质量，有一些提升，希望在以后的工作中，继续坚持好的工作方式，以新的面貌投入到新的工作中，时而回顾以前，也是为了更好的前行。
这篇关于工作失误回顾-2021年11月的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
