这段时间带新人，出了很多问题，在解决问题上经常不太满意，有必要总结出来。

解决问题的基本流程：

发现问题→确定问题→沟通→确定解决方案→实施解决方案→后续跟进→总结教训

解决问题内在因素：责任心，责任心，还是责任心

解决问题的外在因素：老大，配合同事，用户

发现问题

发现问题是第一步，如果问题长时间不解决很可能会升级。所以我始终坚持自己负责的产品不关闭评论，不严格管制用户言论（下沉，移动等）。

我始终相信产品及服务品质是影响用户言论的最大因素，管制只能让用户积累怨念。中国的网络环境就是一个最佳实例。

确定问题

这个步骤绝对不能少，我们发现的大部分问题，源头都是用户反馈。用户经常会撒谎，经常不明真相，经常夸大事实，经常自己做错然后说官方的问题。

所以，用户说出来的话我们都只能参考，不要轻易相信，发现问题后自己测试一下，或者找数据和文档确认一下。

如果长时间不做这一步就会造成“狼来了”的后果。

沟通

向上级汇报：出问题了要向上级汇报，让他们知道起因，经过，结果。

跟技术商量：一起寻找解决方案，选择一个最优的来执行，考虑因素：时间，人力，经济成本，可行性，解决方案可能引发的其他风险等

跟上级沟通比较简单，老实交代客观事实即可，不要隐藏任何信息。

跟技术沟通是一个比较麻烦的事情，首先我们无法命令他们做任何事情，其实问题是否解决得当可能跟他没有关系。所以技术有时候会站在自己的角度考虑，哪个方案工作量最小，就做哪个。

我一般有2种办法：1是装可怜，很多人都有同情弱者的心，大部分人都能被搞定（女生更有此类优势）。如果1不行就用第2种分析后果，理性的跟他分析这个解决办法会带来什么后果，最好跟他的工作量打上勾，这样的话，就算为了他自己也会放弃这个方案，听从你的建议。

我不主张也从来没有用过拿他的老大来压他，因为跟技术沟通不是一锤子的买卖，下次还会有事情求人家，这次你压他，下次他故意整你你都没辙，谁让你不懂技术。

其次，沟通上有几个原则：

• 跟技术拉近关系是王道，任何类型的人都会给自己关系好的人更多的支持。
• 提供准确的信息，信息越准确，越细致越方便技术检查，跟技术不要说太多废话。
• 不管如何装孙子，如何弱势，都要把住一个目标：把问题解决了！跟这个目标有分歧的东西都不能妥协
• 问题解决之前不要去追究责任，一心先想着如何快速有效的解决完。不然只会浪费宝贵的时间

关于沟通，推荐几个阅读：

产品运营过程中如何与开发有效沟通？
【转】项目中的一点沟通心得

确定解决方案

自己和技术评估好一个最佳的方案，老大点头即可。千万不要去询问用户的意见，用户都是贪婪的，用户的需求也是不同的，如果把用户加进来会严重影响方案的确定。

实施解决方案

实施解决方案如果是技术的事情，千万不要甩手不管，如果时间很长，需要偶尔打听一下解决的进度，是否遇到问题，预估完成的时间。

说到打扰技术，这里插一个昨天的段子。昨天下班后服务器出问题，我电话通知了运维，然后去打球，我让新人跟进这个问题，回头我问他情况，他解释了一下原因并说正在解决中，我说什么时候搞定，他说不知道，我说打电话问一下，让运维预估一个大致时间，他说不太好，以后还要合作，现在总是打扰人家，刚才电话时他已经不耐烦…

解决问题不是包袱，甩手扔给技术就算完事。我们要负责解决问题的全过程，解决问题的进度我们也需要知情，用1小时解决和用1天解决搜用到的处理手段肯定是不一样的。

每个技术都能理解运营焦急的心情，我们掌握进度和预估时间都是技术能够理解的，只要不是频繁的去骚扰技术，他们不会反感。如果运营把问题甩给技术，不闻不问，技术反而会对你有看法。

实施解决方案之后，我们还需要通知用户，我们发现了什么问题，原因是什么，我们如何解决的，然后给出一定的补偿。

后续跟进

问题解决了，但是并没有结束，解决方案是否生效，是否引发了其他问题，这些都需要观察一段时间。

另外，快速回复用户的疑问，引导用户言论，表明官方的态度。让用户知道我们有关心他们，在乎他们。

最后收集用户的反馈，对解决方案的反馈，对补偿的反馈。

总结教训

写一份详细的事故报告（如果公司要求的话），记录关键时间节点（发现问题，确定问题，解决方案确定，方案执行，解决完成），问题的影响范围，问题严重性，发生的原因，解决方案，解决后玩家反馈和数据反馈。整个报告都客观记录，多使用数据。

如果不需要写报告就总结一下问题发生的原因，下次如何避免；解决方案的评估，下次遇到这个问题是否有更好的办法；补偿的尺度，这次玩家对补偿的看法如何，下次如何优化。

最后总结一下几个关键句：

• 确定目标，不向违背目标的事情妥协
• 信息准确，透明，让需要知道的人了解全过程
• 了解进度，掌握事态的发展，控制全局
• 总结，避免第二次

打印  |  类别：设计思想  |  源地址