懒+忙+春节，时隔3个月才再次输出一篇文章。10月接手了两个项目，目前已完成一个，特此输出一篇项目总结，分享下自己是如何将一个涉及技术层面的项目运营转化为易理解的运营。
*由于涉及内部信息，部分数据及内容已适当处理。
1.背景
1.1项目背景
我所在部门是负责对公司业务部门进行技术支持的，某天内部论坛有一个帖子反馈，大致内容是：xxx存在密码风险。后来引起关注，讨论决定需要在全司进行改造。
首先需要进行相关功能开发，然后引导全司所有存在上述问题的开发同事进行一些复杂的配置才能完成改造。
这必然不是个容易的活，类比一个场景：你在用某个软件工作时突然弹框告诉你不能用了，必须要升级，升级还特么需要下载并设置一堆极其复杂的东西。可见此处风险，乐观点是被喷的体无完肤，严重的话影响到业务造成收入损失，那就卷地铺走人了。
我负责的就是整个改造的运营。
1.2时间
9月功能开发
10月部门灰度测试
11月初开始全司灰度
12月底全面完成改造
1.3范围
改造维度：IP（共X个）
推广维度：人（共X人）
2.项目目标
2.1眼前
- 完成上头安排的任务，切换成功
- 尽量平稳，润物无声
- 减少客服的压力
2.2长远
沉淀方法，优化服务效率
3.困难有哪些
3.1配置复杂
系统的多样导致配置教程的步骤虽然详细，但过于复杂繁琐。
3.2不可预估的问题
用户配置过程中出现的问题不可预估的太多，比如复制粘贴时不完全、所需程序的系统位数不对、网络策略等等。
3.3人性的弱点
- 普遍的拖延症：不到截止日期不操作
- 懒惰：出问题不先自查
- 自私：以自我利益为主，不配合
以上几点导致处理用户问题压力较大，同时有可能波及到相关的平台，导致相关业务受影响（此处为最高风险）。
4.做了什么
把这个项目当做一个产品来看的话，在一定要切换新系统的情况下，对用户场景进行分析，可以得出相关的需求及所需功能：
4.1教程指引
为了给用户提供完整的指引、QA和反馈（吐槽发泄）渠道，在平台上搭建了一个专题，整个切换过程中遇到的典型问题和解决方法都会不断更新在其中。
其中官方的详细配置教程由我们的开发同学来进行主笔，确保可用性。再由运营同学配操作图润色，确保易读性。然而图文的方式依旧显得繁琐，后面又加录了视频教程。但这仍然无法从根本上解决问题，最终安排开发资源去优化配置的一些环节，得以最大程度的简化了整个配置过程。
此外，还对不同构建环境的配置教程进行了有奖征集，最终获得教程X篇，若用户根据这些教程配置出现问题则会问作者，一定程度减轻了我们处理问题的压力
4.2通知机制
- 节奏要对：每周三开始对下周三灰度的BG（事业群）进行倒计时7天邮件推送，在倒数第2天和灰度当天以弹tips的形式进行通知；对于人数最多的BG和重点BG则提前14天进行通知，此处的细节为在前7天隔天推送一次，后7天则为正常的一天一次，实践证明这频率并没有引起反感。
- 有力不失温和：通知邮件上加入一两个颜文字表情，使得整个通知邮件在正式权威之余多了一份幽默。
- 关键人物：将重点BG的各开发组负责人拉个群预先通知到位，请他们通知下属并配合切换
4.3灰度进行
灰度分为了三个阶段：
- 阶段一，部门内测试：在配置教程及开发工作完成后，首先在部门内部进行测试，以确保系统以及教程的可用。
- 阶段二，相关部门测试：部门内部测试完成后，找了本次项目的相关部门---XXXX部和XXXX部进行测试。在人数及环境变量的增加下进行二次测试，以发现更多问题并解决。
- 阶段三，全司推广：实战环节，按BG进行灰度，每周1个BG，在此过程中每天进行数据收集，整理出的数据供下周的BG参考，如配置的爆发点在经过3个BG的统计分析后得出切换前一天、当天、后一天这3天是配置的峰值，那么问题的爆发也会是在这3天内，相关的同事要做好充分准备。
4.4分级响应
4.4.1业务侧
在封网当天，实施以下响应机制，对发生的情况进行分级响应，从高到低为：
4.4.2 PR侧
由于存在用户在内部论坛发帖吐槽的风险，这就需要提前做好公关准备：
- 订阅论坛的相关标签提醒以便第一时间发现
- 当出现问题后相关人员及时回答并及时更新结果，此处有参考模板（见附件1）
- 若用户为实名发帖，则私聊了解情况并安抚
5.项目成果
- 负面消息总数实则为0（2条为简单的咨询）
- 用户咨询数整体呈下降趋势
- 未配置的长尾用户后续需要使用时会断断续续配置，不会集中爆发
6.经验与不足
6.1经验
- 由图（略）可见配置高峰为封网前一天、当天、后一天
- 小白问题占较大比例，可以先看是否为操作失误（命令缺失、多余或复制不全），无法判断则让其照着教程重新配一遍，减少拉开发解决的人工成本。
- 对几天前都不配置直至封网出了问题才找上头的用户，安抚并指引，视情况严重与否临时开通特权
- 当用户周围较多同事配置成功后将形成有利传播，减缓一定的用户咨询
- 避开周一封网（较多版本发布）
- 专题页的任何配置文章勿进行删除，改动需谨慎，数据库应备份一份
- 开发与运营需配合介入
- 用户永远比想象复杂
- 时刻保持服务意识，遇到极品用户情绪要控制
6.2不足
- 由于切换公告未表达十分清楚，导致部分用户理解出现偏差。
- 仍无法做到完全用户自助服务
- 发动起来的用户数量不多
- 专题页面设计不够美观
7.附件
7.1回帖模板：
这是准备于用户在内部论坛吐槽时回应用的，最后也确实用到了一次。
首先非常感谢XXX同学（点名）的反馈，对您带来的不便请见谅！（感谢+道歉）
其次从您的问题中可以得出您的需求是XXXX（确定对方的问题）
对此我进行以下解答：（解释）
因为，所以。。。
以下是具体解决方法：（解决措施）
1、2、3、。。。
十分能理解楼主作为一名开发遇到这种情况的无奈和烦躁（感同身受）
但安全无小事，公司的代码作为立业的宝贵资产需要我们每个鹅厂人去保护（站在公司立场）
XXX策略是为了避免出现密码泄露等安全事故，在XXX部、XXX部、XXX部讨论多次后最终确定的预防措施，在此希望XXX同学以及其他同学能理解。
这个策略的推进是灰度进行的，欢迎大家对过程中出现的问题进行曝光和给予建议，这会使后续的过渡工作越来越平顺。（悄悄地告诉还没参加灰度的同学）
最后，如果大家在使用过程有什么建议和意见，可以联系我或相关同事，感谢！（售后服务）
一些思考
- 在项目的过程中结合到了《引爆点》的一些内容，虽然该书是讲解流行潮背后的原因，但能变相利用一下思路。如果切换出现了意外，将是消极的大爆发；那么反过来想，能否让大家产生积极的爆发呢？于是从引爆点三法则切入
个别人物法则：通知到关键的人物
附着力法则：传播的容易被注意与记忆的内容
环境威力法则：类似从众
在这里我分别做了什么？
1、通知了各BG相关的开发组组长
2、推送的邮件、公告等一直在强调“配置5分钟，安全无限时”（没错就是仿照Oppo R9s的slogan）
3、当12完成后各组的成员就开始配置形成效应了
- 虽然该项目几乎是技术层面的，但可以通过理清业务逻辑、换位思考进而转化成通俗易懂的场景，更好地下手开展。同时也有一些想法，这个思路是否可以借鉴到产品日常的版本更新与系统维护中而不只是这一次临时的任务？
