版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/l460133921/article/details/78080117
从技术开发做到管理团队、带项目，我清楚在面对产品报出来的问题时研发人员与管理人员所考虑的问题重点有时是不同的尤其 临近产品重要节点的时刻，研发人员更注重对问题的分析、定位和提供解决方案，而项目管理人员则着眼于项目全局考虑，如修改是否会引入新问题、是否会导致版本发布延迟、问题是否值得修改等。这种差异也是正常的，因为研发和项目管理人员站在的层面不同、对问题思考的角度也不同，但是这种不同的消除我认为最终一定会归结到一点：对产品带来的价值和损失。
产品在开发阶段报出来的问题，按照正常的问题管理流程进行分析、修改、上库和验证，这是没有问题的，因为一般我们还有足够的时间去发验证方案和发现新问题。但是如果在产品的重要节点，甚至是在快要上市的时候突然报出来一些问题，我们该如何处理呢？当然，对这些问题的分析还是必须要做的，但是是否需一定要解决，我的经验是从如下几方面考虑：
- 问题复现的场景用户是否会经常遇到
- 内部Beta用户的舆情分析（如果场景用户会经常遇到，那么舆情必然高）
- 与产品对应的竞品表现如何（一般要比竞品表现好，做参考）
- 关键干系人的要求，如产品经理要求等
如果这问题符合这几条，尤其是前两条，我认为该问题一定是要在产品的重要节点前或上市前要解决的（我想内部Beta用户的舆情对产品和公司的影响一定要比实际用户报出来后要小的多），但是对于问题的解决方案我认为一定要考虑如下几个方面：
- 问题的根因分析是否清晰
- 解决方案的风险是否考虑全面
- 测试用例设计是否全面
- 解决方案的风险是否经过实际验证而排除
- 如果是概率性问题是否经过压测
也只有一个解决方案经过了如上几个方面的评估，这个解决方案才能最终上库。还有另外一种常见的情况：三方问题。一般来说，三方问题当然需要由三方来解决，但是三方解决的话一般会面临如下两个问题：
- 三方是否愿意解决
- 三方的解决时间能够跟得上产品的上市时间
对于这种问题我认为我们的工作至少要做到如下几个方面：
- 指定直接负责人与三方进行直接的沟通，推动三方对问题的处理
- 内部要提供一个备选方案，并且该备选方案至少要能够通过上述五条的评估
我想也只要内部做了这些充分准备工作之后，在面对三方无法解决问题，或解决问题周期太长时，我们才能做到有条不紊。
以上只是我对产品问题处理的一些经验，尤其是在产品重要节点或即将上市的情况下所报出的问题，欢迎大家积极讨论。