Bug在软件工程中是不可避免的问题，所处环境存在一定程度职责界定不清晰的问题，稍不留神就从产品经理变为跟bug经理了。
　　产品经理跟bug的情形
　　产品经理跟bug的问题在于，代码不是产品经理写的，产品经理能做的是根据bug现象，如跟项目一样跟进bug解决，而定位问题跟进bug，测试人员更专业。解bug本身并不能体现产品经理的价值，产品经理的价值更多体现在挖掘需求和输出产品方案上，产品经理也难以在跟bug过程中获得产品感觉的提升。从专业性和职责定位两方面来考虑，产品经理跟bug显然是狗拿耗子。
　　从业半年多来，将产品经理跟bug情形归结为两类：其一、bug影响用户范围较大，测试人员推动不力；其二、公司上层政治需求，容不得出bug，为加多一层保障，产品经理跟bug。
　　Bug爆发式增长
　　众所周知，互联网行业已经从增量市场转变为存量市场，获取用户的成本越来越高，如何留住用户成为各个厂商最关心的问题，推送对产品拉活和留存具有重大意义。
　　产品的推送模块是乐帝负责的模块之一，但却是最让乐帝头痛的模块。为了提升推送达到率，产品接入了一些手机厂商提供的推送服务，第三方厂商一旦出问题，就会出现沟通成本高、响应不及时、难以定位问题等一系列麻烦。同时为了公司内部资源复用，推送服务作为通用服务，提供给公司内部多个部门使用，每个接入推送服务的产品，都需要负责接入和后续维护。负责推送服务服务端和客户端的人员因为相继离职，半年以来已经换到了第三波人，真是你方唱罢，我方登场，好不热闹。
　　在推送服务复杂性高和人员流动性高的情况下，推送服务的bug终于集中爆发了。主要bug体现在以下方面：多个部门产品推送整体数据下降、部分用户反馈推送过多、部分用户反馈收不到推送、部分用户反馈关掉推送开关仍收到推送、渠道反馈某渠道留存下降……乐帝作为推送业务的接口人，从四面八方不断接到推送服务bug。
　　Bug的各个击破策略
　　Bug的集中爆发一开始令乐帝有点懵逼。显然这些bug已经不是扔给测试人员提个bug就能解的问题。此时乐帝对bug采取了需求分析式的bug各个击破策略：是不是推送问题、哪些问题不需要开发调整、哪些问题需要开发调整。
　　首先，解决了不是推送的问题。经过分析对比某渠道留存半年下降数据和某手机厂商推送半年来总体趋势，整体厂商推送数据稳定，而渠道留存却一直降。趋势的不一致，至少可以得出结论，推送问题至少不是某渠道留存的主要导致因素。
　　其次，解决了不需要开发调整的推送问题。很多用户集中反馈不知如何关掉推送，关推送的是实际问题的解决方案，这背后的动因很可能是推送过多，对用户造成了打扰。推送过多可能是两个维度造成：推送总量过多、推送时间间隔过短。
　　通过定位部分用户的推送历史，发现自家产品，在单日推送总量上基本与竞品齐平。但发现每天某个时间段的半小时内通常用户会接到3条推送，基于数据分析基本能判定是推送时间间隔太短，打扰到了用户，导致用户抱怨并希望关掉推送开关。拿着用户反馈和数据这样的铁证，去驱动内容发送方就顺理成章了。对方调整后，用户抱怨希望关掉push开关的问题基本没有了。
　　最后，解决那些问题需要开发调整的问题。在实际推动解决需要开发调整的推送问题中，遇到了推不动没进度的问题。分析推不动原因主要在于，乐帝推动的开发人员属于最底层执行的工程师，底层执行工程师与leader差异在于，底层工程师更着眼于执行，不善于从全局角度考虑与沟通表达问题；另外，由于其需求方来源较多，并不一定把推送bug问题排在较高的优先级来处理。
　　针对以上分析，乐帝从暴露问题和推动问题方式方法上做了优化调整。
　　首先，以用户反馈和相关数据变化作为推动依据，将问题以邮件方式发送给执行工程师的leader，并抄送相关领导。将问题影响范围和严重程度暴露给对应leader，借其leader力来推动工程师重视并解决问题。
　　其次，鉴于存在解决推送bug没有进度的问题，采取车轮战的方式，将待解决问题进行汇总，再加入目前进展和下一步工作两个维度，将推送bug以项目日报形式进行发送，将进度的状态进行全方位的暴露，切实解决没有进度的问题。
　　后bug时代
　　采取以上各个击破的策略，推送问题反馈明显减少了。但同时铁血推进也着实给部分人员带来了压力。
　　后来领导跟乐帝表达了两点：其一，bug问题非产品能推动，推送bug日报可暂停发送，产品关注点应该放在方案上；其二，bug需要确定影响范围，如果属于疑难杂症就没必要占用开发精力，投入产出比不太合理。
　　从领导和bug处理反馈来看，乐帝执行的策略切实的解决了部分问题，也引起了上层领导关注与思考关于产品经理跟bug合理性的问题。最初暴露问题和解决bug，以稳定推送模块局面的初衷，基本得以实现。
　　同时领导考虑问题的格局显然更高，更多从资源投入产出是否合理角度来思考，也有助于乐帝精进思考。Bug出现的不确定性，决定了确定影响范围较为困难。但仍可以从用户反馈和数据两个维度来进行界定，比如用户持续反馈，或数据有明显影响，都可以定义为影响范围大，仍需要高优先级处理。至于推送日报还是需要发，只是没必要天天发，可以每周发。
　　毕竟，产品经理的精力，需要放在需求挖掘和产品方案上。