为什么一次fix的时间这么紧？

产品经理说那边report了一个bug，然后需要马上fix，其实这个bug存在很长时间了，不知道那边为什么突然要改，然后我和产品经理商量出了一个方案，一步到位，结果架构师参与进来，问了一些问题，经理和还有一个工程师也参与进来，问了些问题，我感觉就几个小时的活需要被问这问那的，什么也没干，晚上加了点班，然后到了第二天，上午我有点事，到下午才开始test，结果发现有问题，还得改些代码，又是周五了，我也不想查了，采取了第二套方案，分两步release，得到下周了。 大家遇到过这样的吗？

经常。 不过慢慢学乖了，非必要不立即fix。 放backlog reprioritize，基本永远论不到它了。

回复 2楼huaren_2018的帖子
但是产品经理急啊，他说上面急，我也是稍微有点低估了，但也想尽快发布。

有组员，不一定有意，fix 一个，introduce一个更大的。慢慢的非技术人员，自己就会掂量了。 必须的还是咋都必须fix的，要不客户没法用。 那种尽量在之前多测试。

回复 4楼huaren_2018的帖子
这太理想了，即使10个task有9个能充分测试，也有一个漏了的，各种原因，测试的人没上心，漏了test case或者要急着发布。不过其实大部分bug都不紧急，不会导致用户没法用。

如果这个bug是需要我负责，我会做多一点功课，至少要让上面知道问题的难度，打补丁后会产生的问题和一些相应的应对机制，如果急，我会和经理沟通手上的其它活，让他去安排优先顺序。
如果上面有架构师，和更高职位的工程师共同承担，那就看这个案子对你有多重要了。如果重要我就会多承担一些，如果不太重要，又有其他人共同承担，那么我会让他们去承担多一些。
测试不足在很多地方是常态，很多地方都会偷工减料，以至需要花费更多的后续资源去解决问题。