这是一个创建于 1961 天前的主题，其中的信息可能已经有所发展或是发生改变。
先说我们的
不管多严重 如果原因是因为什么校验什么枚举判断错误之类 先数落你 怎么能犯这么低级的错误
如果是你手下人写的 就数落你 为什么不给手下 review 代码
如果 是外部业务因素导致的 比如 用户的等级千奇百怪 开发根本完全不了解没有兼容到 就说落你为什么没有想到或者单测覆盖到？
好奇别的别的团队出现小 bug 和大 bug 团队都是怎么对待的 ？
是不管问题大小 先数落一遍开发
还是按不同问题严重性，不同对待的
还是 谁没写过 bug 宽容对待的
 | 1 wangkun025 2020 年 11 月 28 日  5 我们对待错误比较宽容，可能因为老板很懂，或者老板完全不懂（有敬畏之心）。 其实这个问题挺简单的。 首先是需求问题。 其次是测试问题。 最后才是开发。 如果 BUG 是没考虑到的，就是需求的问题。 如果 BUG 涉及的需求在文档里，测试没测出来，就是测试的问题。 如果需求提出了功能，但开发实现不了，但别人家的开发能实现，才是开发的问题。 换个角度看，BUG 其实跟开发一毛线关系都没有。 |
 | 2 HariopaNic 2020 年 11 月 28 日 via iPhone 遇到 bug 首先解决问题，解决完说一下原因，比较低级的就说下次注意一下。 |
 | 3 hoyixi 2020 年 11 月 28 日 1 楼兄弟，很粗暴啊，是不是从来没写过单元测试 |
| 4 wangkun025 2020 年 11 月 28 日 @hoyixi 写过。分担责任嘛。只折磨开发，有意思吗？ |
 | 5 yuhuan66666 OP @hoyixi #3 说起单元测试 ，我们基本出了 bug 就 数落开发 单元测试没写或者单元测试覆盖度不够 |
| 6 hoyixi 2020 年 11 月 28 日 1 @wangkun025 #4 同意，不过，不管谁的问题，最后 bug 都还是开发改啊，哈哈 bug 一出，先定位打击人群，类似楼主提的”数落一遍开发”，甚至还有扣钱的， 感觉这是中国软件作坊特征之一。 出 bug 多正常的事，按照流程该干嘛干嘛，迭代就是了。可能很多公司连像样的“流程”都没有，只能让各部门内斗了。 这现象不光 IT 业有，类似现象本质，感觉就是领导无能，于是为了显得自己永远对，就让下面部门或者人员互斗~ |
| 7 yuhuan66666 OP @wangkun025 #1 我上面 和 上面的上面都是开发干过来，但是我不知道他们是什么心理 都喜欢从自己下属找毛病，出了问题先怪自己下属，外部问题也能怪到自己下属身上，什么 为什么提前没沟通，为什么单元测试没覆盖到，为什么开发阶段没了解过这个问题 |
| 8 yuhuan66666 OP @wangkun025 #4 因为 是团队合作关系 开发团队 测试团队 产品团队 出了 bug 开发领导只能数落手底下开发，QA 和产品团队人家数落不到 |
 | 9 dumbass 2020 年 11 月 28 日 via iPhone 1 反正发生什么不都是开发背锅 |
 | 10 XDy0 2020 年 11 月 28 日 先解决问题，然后再找问题发生的原因。主要是我好像没出过什么大的 bug，所以也没被骂过，很多问题都是我自己发现自己解决的= = |
| 11 yuhuan66666 OP @XDy0 #10 上线后 自己发现的吗？ 那你观察总结的时间挺多的 我们开发完一个需求 立即下个需求开始 把敏捷开发中的 双周迭代 概念单独拿出来用 |
 | 12 binux 2020 年 11 月 28 日 |
| 13 wangkun025 2020 年 11 月 28 日 |
 | 14 007yxc 2020 年 11 月 28 日 via iPhone @wangkun025 ....你这逻辑 我很佩服 |
| 15 yuhuan66666 OP @wangkun025 #13 管理的手段就是 当出现一个问题数落完之后 问如何避免下次再出类似的问题， 然后又把问题推到了充分单元测试 提高单元测试覆盖程度 和 review 代码上 |
 | 16 whypool 2020 年 11 月 28 日 整个组背锅，然后影响年终奖 |
 | 17 zerofancy 2020 年 11 月 28 日 2 拿起手机，发现 iOS 那边也挂了，松了一口气。看来不是客户端的锅。 |
| 18 yuhuan66666 OP @whypool #16 小问题也这样么。。。。 |
 | 19 boris93 2020 年 11 月 28 日 via Android 1 首先受影响的人会来找我，告诉我出现什么问题了 确认后，后 JIRA 上开 bug 单 我按照紧急程度以及当前 sprint 的时间安排，决定是这个 sprint 修好，还是下个 sprint 再做 修完了，测试，上线 因为 bug 数落下属，只是发泄情绪而已，没啥实际用途。不如花心思在制定改进方案和落地上面。 |
 | 20 leavic 2020 年 11 月 28 日 谁写的 bug 拉出去祭天。 |
 | 21 seki 1 对事不对人，是人都能写出 bug 来 对于今后的整改措施，是要从手段和方法上去避免和控制，因为人都会犯错，需要通过加静态检查，加测试来避免犯同样的错误 |
 | 22 SjwNo1 2020 年 11 月 28 日 via iPhone 1 好好反思，耗子尾汁 |
 | 23 musi 2020 年 11 月 28 日 是个开发多多少少都会写 bug 吧。。。真要说没 bug 那就是 no write, no bug |
 | 24 cheng6563 2020 年 11 月 28 日 反正出事故都是开发的 赚大钱都是运营的 |
 | 25 beidounanxizi 2020 年 11 月 28 日 一楼说的很对啊 不会真的以为单元测试 就能做好吧 |
 | 26 qiaobeier 2020 年 11 月 28 日 1. 立即解决问题 2. 会议回顾问题 3. 扣责任人的奖金 |
 | 27 frankkai 2020 年 11 月 28 日 如果是走了一个完整的“开发->测试->验收->发布”的流程 因为是团队，所以理所应当大家一起背锅 |
 | 28 akira 2020 年 11 月 28 日 提交缺陷跟踪 根据紧急程度安排优先级 该谁改谁改 测试 上线 |
 | 29 cabing 2020 年 11 月 28 日 先修复 bug，非紧急情况下，再找写出 bug 的人，修复 bug 上线。 |
 | 30 railgun 2020 年 11 月 28 日 1 、补偿客户损失 2 、定位问题 3 、确定修复方案 4 、临时修复 5 、正式修复 6 、事故复盘 7 、修改发布流程，避免再犯 8 、确定责任、惩罚措施 |
 | 31 dreamapple 2020 年 11 月 28 日 via Android 运维报故障 写故障分析报告 定级 邮件通报 还没遇到被领导请喝茶的情况 |
 | 32 nuk 2020 年 11 月 28 日 1. 写 report 2. 能修就修 3. 修不好就甩锅 |
 | 33 raaaaaar 2020 年 11 月 29 日 via Android 楼上说得很好，我认为第一步应该是定位问题，解决问题，而不是一来就开始追责，那种领导最坑爹了，还有就是领导不会反思，不会开会大家一起思考，总结暴露出来的问题，虽然可能是开发的锅，但是通常都会暴露出开发流程的问题，但是有些领导根本不搞这些，就让你背锅，先把责任让你背着再说 |
 | 34 yjxjn 2020 年 11 月 29 日 1.提 ticket，报告问题 2.定位错误，调查 3.修改 BUG，做测试，测试没问题，MR |
 | 35 wanguorui123 2020 年 11 月 29 日 via iPhone 上线出现 bug，1 、定位问题和日志； 2 、看能否在线修复； 3 、无法修复立即回滚历史版本； 4 、无法回滚就立刻限制有问题的部分功能与发布公告； 5 、加班修复问题并发版 |
 | 36 ydpro 2020 年 11 月 30 日 出问题，改 bug，结束。 |
 | 37 luozejian 2020 年 11 月 30 日 忙着甩锅大部分人都是第一时间想到这个 |
| 38 yuhuan66666 OP @raaaaaar #33 更坑爹的是 会反思 但是反思出来都是开发的问题，都是因为开发没做某某控制，导致了 bug 。那解决办法呢，自然也是开发应该想到可能出现的问题，应该更全面的写单元测试。然后如果 开发需要 10 分钟写单测 10 小时，他就会觉得 你不够努力，为什么单测要那么久，既不想让开发占用工时写单测，又要求单测必须要全面。 |
Select Language