产品运营的本质

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