产品运营的本质.docVIP

看到了四位同事对自己半年以来的工作总结，许多困惑都集中在怎么样做工作，以及做什么样的工作，才能让我们的工作变得更好，做到忙而不茫。 我就根据我这几年的经历，给大家说我的一些感受。 首先，我们是产品运营部门，负责易飞产品线的运营发展。那么，运营类主管的主要职责是什么？我个人以为：对于运营而言，两点很重要：1.保持工作的动态稳定性；2.日常工作持续改善，这两点是互相交融的（产品运营毕竟不是一锤子买卖）。下面我将分别阐述： 稳定性 对于一个商用产品，对于客户而言或者我们内部而言，保持稳定很重要。我就举一个例子。今年年初的时候，我们有一个服务器安装了金山毒霸，功能很丰富，貌似该有的全都有了，并且不定期的推出眼花缭乱的应用让你安装更新（什么开机小助手啊，什么围攻僵尸网络啊），我更新了，就老是让我重启电脑，让人很是烦恼。后来这个电脑开始蓝屏，后来频率越来越高，费了很大功夫，才发现它新推出的一个功能和硬件冲突，无奈卸掉，这个也是排查了不少时间（而在这段期间，我要向很多人解释为什么我们的FTP又不能用了，查序号网站怎么又DOWN了的许多咨询和质问，我自己痛苦不堪不提，还影响了前方同事的工作状况）。 产品要保证一定的稳定性，运营工作何尝不是如此。 场景一： 测试程序时，同一个现象，测试员张三说这是一个问题；李四说，这不是一个问题。这就让程序员很纠结，到底改还是不改。 场景二： 客户提了一个问题，张三说这个问题不清楚，李四说这个问题不归他管。 场景三： 我们给客户解决一个效能问题，有的同事神速解决，有的同事，虽然也很认真来做，但就是半天没有成效。 要保障运营工作的稳定性，需做到以下几点： 必须要有清晰可执行的规章制度、操作手册。 没有规则，且还能把事情做的很好，除非我们的同事个个都是活雷锋，并且能力很强大，一个人搞定一切。 必要的规则和制度，能够明确责任归属，使工作流转更加顺畅。我们也梳理了不少的工作流程，比如外部填单方式，问题类型划分，内部问题流转过程，我们的开发注意规范、测试问题严重等级划分等等。 基础的编程操作手册、常见问题排查步骤说明，能够一定程度上减少人为的疏忽和偏差性。我们的运营要想平稳运行，健全的支撑体系就尤为重要。 确保员工有做该工作必备的基础技能 同样的问题，不同的人处理，结果差异很大，除了员工主观能动性和个人天赋外，我们要考虑，该员工是否已经掌握了此类问题的必要的基础技能。比如，让程序员处理LRP问题，如果他对LRP一问三不知，肯定是不行的。让他处理效能优化问题，连常用的三板斧都不会，其结果可想而知。 对于现有规章、制度的日常督促执行 好多事情刚开始做，大家比较认真，落实的不错，后续就越来越差。其往往就是中间缺乏一定的监督。人都是有惰性的，如果没有日常的一些督促和监督，那么执行就全依赖个人自觉性了。而我们日常的一些工作也往往验证了这一点，比如服务器数据备份问题，最近的触发器事件等等。做对的事情不难，难的是坚持做对的事情。 说到这里，有的人很欣赏那种受命于危难之际，拯救人民与水火的超级英雄和大事件。 其实，产品运营不是英雄片，而是淡如水的生活片。日常体系的落实和稽核，很大程度上能够预防和减少灾难的发生。之前我有给大家发送过一个关于矿难分析的PPT，就是这类例子。所以，日常例行性的动作，虽然枯燥，但还是要做。要做到如同呼吸一样，融入到你的工作当中。 持续改善 在保障运营相对稳定性的情况下，降低运营成本，提升运营效率，是我们的重要目标。那么，该如何做，能够较好的达成这一点呢，我认为是过程改善。 我们推出了一个新模块的安装盘，目前已经有几家客户反馈说，如果数据库版本较低，则无法顺利安装。那么，我们是被动等待其他客户再反馈此类问题的时候，告知他们需手动升级数据库版本，重头再来。还是立即制作新的安装盘，如果数据库版本不符合条件，就无法进行安装，同时发送通报给地区事业部，告知大家注意这一事项。（前者是扬汤止沸，后者是釜底抽薪） 持续改善就是：我们在解决问题的过程中，发现好的做法（可以提高解决问题效率或者减少问题的发生）；或者借鉴其他人的好的做法，纳入到规章制度、操作手册、绩效考核等现行体系中，并且不断的加以完善和改良。 我们要的是变革，而不是革命，因为革命成本和风险非常高，先打破旧有一切，再重启炉灶。很有可能就要了产品的命。（历史上农民起义不计其数，而成功案例屈指可数），而过程改善，属于渐进性、改良性质的，其成本和风险降低很多，坚持时间越长，收效越大。 就拿效能处理而言，从08年下半年开始，效能问题逐渐变多，我们开始梳理一些解决问题的思路，使之基础化、傻瓜化，从最初的效能问题只能有技术组的资深同事处理，到现在的服务组同事也可以处理相当数量的此类问题，这就是一个典型的过程改善的动作。 过程改善就是一个聚沙成塔的过程。从最