产品经理的日常就是充满问题的日常，而这些问题很多时候都在预料之外。例如突然出现的系统bug，例如之前没有发现的存在很久的隐患，例如基础条件的突然变化。
刚做产品经理的那一年，虽然公司强调要拥抱变化，但当这些问题层出不穷的爆出时，心里的丧还是会越积越深，久而久之开始怀疑工作的意义。
后**历了各种项目的历练，开始总结出一套面对问题时的处理方法，于是不断实践不断重复，最终让自己在问题爆发时更加冷静与平和。
一、接纳问题的发生
很多产品经理是规划控，无论是项目的推进还是产品的迭代，都希望按照既定好的节奏进行。而当问题产生时，规划控们会下意识地产生抗拒。
我也会这样，老实说，我抗拒的不是问题带给我的额外的工作量，而是问题的出现所带来的自我价值的否定，直接一点，是挫败感。
前段时间去听一个讲座，我提出了一个问题“如果一个爱写作的产品经理只有拿得出手的作品，没有拿得出手的产品，他算不算一个合格的产品经理”。在主讲人的解答中，我逐渐接纳了一个共识：决定一个产品成功的要素太多了。
正因为我们的产品不会100%按照我的规划演化，所以我们也得学会接纳问题的发生。这是产品经理工作的一部分。就像我们接纳自己的不完美，这是人生的一部分。
二、定义问题的严重程度
如果第一步需要做的是心理上的调整，那这一步要求我们在第一时间具有定义问题严重程度的判断力，因为这样的定义，将决定我们采取什么行动。
经典的重要+紧急的分级标准依旧适用——
如果是重要且紧急的问题，不用多说，赶紧“打补丁”。打补丁是针对问题可能会造成的损失，第一时间采取止损措施。例如线上促销配错了，那就赶紧下线促销；例如某个商品价格标错了，那就赶紧下线。无论如何，止损第一。
如果是不重要但紧急的问题，那也应该快速解决，但可能不至于止损第一。例如线上某个活动banner图的样式存在一点问题，但不影响点击跳转。那可以赶紧出合格的UI图，但我认为不至于下掉这个banner入口。
如果是重要但不紧急的问题，我建议以彻底根治为主，这很可能是产品潜在的缺陷，总是要解决的。
如果是不重要且不紧急的问题，那就按排期逐步优化吧。
对于问题严重程度的定义，最微妙的两个词是“重要”和“紧急”，什么是重要的，什么是紧急的，很难严格统一。就我个人的经历来说，重要的判断标准，是是否会带来直接的经济损失或严重的用户投诉，紧急的判断标准，是此刻有无替代的解决方案，如果是绕不过去的，那就是紧急的。
三、问题的诊断与治疗
“打补丁”虽然可以缓解燃眉之急，但毕竟不是解决方案。要彻底解决问题，产品经理就要能像医生面对疾病时一样，能诊断，能治疗。
出现问题的不同，所采用的诊断方法是不一样的。如果说非要抽象出一套逻辑的话，我会把它概括为：从公理到定理，从逻辑到变量。
我们都知道，几何学有五条公理，他们是不证自明的，是绝对正确的，是推导其他定理的前提。同样的，在产品经理的工作中，也有一些如公理一般的逻辑，从这些逻辑出发我们才能去诊断问题。
例如底层数据源相同时，经过相同的业务逻辑封装，所取的数据是一样的。这个逻辑就是公理。如果不认可这个大前提，那不同人对同一个诊断结果是有不同认识的。
应用这个逻辑的过程中，我们会发现有很多决定最后输出的变量，包括底层数据源，包括业务逻辑，包括封装。如果最后数据不一样，那一定是某些变量或者说某些环节出现了问题。最后，治疗就是逐个击破的过程，按环节逐个验证。
多说一句，产品经理要做的是引导这种方法的落地，开会也好，讨论也好，要知道当前是诊断还是治疗，是逻辑还是变量。而具体的验证过程，例如对sql逻辑，例如对接口参数，则交给专业的人去做就好。
四、明确解决方案的边界
很多问题的解决方案，都有其适用条件。作为产品经理，在解决问题时，要将解决方案的边界同步出来。就像医生给患者出药方时，还会附上医嘱，你得怎么样怎么样做，才能最终痊愈。同样的，产品经理要知道此刻问题的解决是基于什么样的前提条件，例如并发数在某个数值之下，例如数据量还不太大，一旦前提条件变了，还是会存在风险。
我们不是以解决一个出现的问题为最终目标，而是通过问题了解系统最真实的状态。
结语：
写这篇文章，是因为看到我们团队中有个同事因为项目压力太大，导致很长时间以来都没有见她怎么笑过，感觉每天都很压抑。跟她沟通的时候，她说因为工作导致了失眠。最后，她还是选择了离职。
产品经理的工作就是会每天面临各种问题，各种事故，各种让你感觉随时要暴躁的瞬间，但我们就是要面对它、接纳它、解决它。
实在扛不住，那放过自己，也挺好的。
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。