作者 | donnyhuang
运营开发为什么会存在呢？“肯定是因为有运营嘛，有运营需求，需要开发完成这些需求，所以我们才存在。” 那么，真的是这样的吗？
一、运营需求是什么
这个话题首先要先分析：运营是干啥的？一个运营需求的生命周期是什么样的呢？通常来讲分三步：评估决策-落地-效果反馈，然后迭代改进。跟我们精益研发的价值循环有点像。
在这个过程中客户对我们有两个比较大的诉求，一个是运营工具，第二个就是数据，希望通过运营工具能快速落地他的想法，而不是需求提出要一两个月才能验证，这样就谈不上快速迭代。
另外就是希望一上线就要能看到数据反馈，能通过数据精确制导他们策略制定、评估更好的方案，精确制导。
二、客户诉求和现实差距
但理想和现实还是有差距的，我们过去在运营效率上还远远不够。
就如同大家在工作中经常遇到这样的场景：需要数据的时候发现没有上报，要等埋点几个月发布。
运营落地也是如此，大家有没有很熟悉这样的场景：
比如运营同学突然脑洞一开：“ XXX策略，可以让我们业务增长XXX倍，看看能否明天上线。” 研发只能说：“需求已经排满了，你和xxx pk一下，看能否排进下个月迭代。”
三、反思：运营研发是要思考如何不断的提高运营效能
所以反思一下，上面下的定义不对，我们存在的意义，是要完成运营需求，但又不止是完成运营需求，而是思考如何不断的提高运营效能。
甚至比较理想的是运营不再需要给我们提需求了，想要的时候就有了，因为如果走需求评审、排期、开发这种模式，代码写的再快都很难达到。
团队其实在有些场景上实际也有了初步探索，比如我们现在正在做的无埋点上报，目的就是不用提需求就获得数据，开发也不用埋点，想要的时候开启就有。
又例如工具落地，之前行业个性化返佣，落地一个政策，要找人要数据，定排期，再开发，一两个月才完成一个政策，最后还算错了，搞出故障。
现在我们对需求分类梳理，抽先出核心公式，实现标准化、模式化、配置化，完全产品自助就搞定了，而且会有比较软的风险管控措施，可以防止算错。比如，我们还做了通用的风控模型，每个政策起手可以防刷返佣。
当然这些还远远不够，目前可能只是解决了某些环节某些场景的问题。比如数据这块，除了上报，搭建数据仓库，数据应用、数据分析的效能提升也要不断加强。
例如，上次帮一个同学review代码，发现半年一共上传不到1000行代码，我很震惊，半年上传的代码这么少？后来问了才知道平时比较多的是帮产品临时分析，代码都没有沉淀，所以当时就给他们提了要求，要把这些分析需求盘点分类，模板化，沉淀下来，后面就不用老是来临时分析了。
同样，运营活动类的需求也是一样，不能一两个月才落地，特别今年涉资的业务都要求接入审计，防止资金风险，研发资源投入上需要增加，更加需要关注效率的提升。
另外还有一类需求，现在还有管控流程线上化的需求，比如人脸的设备管控，之前因为没有这些能力，很多流程是人肉跑的，但业务不可能停下等系统慢慢完善，导致系统建设跟不上业务发展，有很多债务，比如设备类型数据对不上，设备sn乱码等等。
这些工具也是可以抽象沉淀的，基于一个原则“”能标准化的标准化，实在个性化的可以分类分场景来模式化，实在全新场景的通过原子组件和框架实现低代码快速搭建系统”。总之新的管控场景要起手做好，不能再踩之前的坑了。
四、稳才是第一位
但是，做到这样是不是就够了呢？刚才讲的都是怎么快，其实最重要的是要稳，不要搞出问题，运营往往涉及资金或者其他资源，出了问题，影响是非常恶劣的。
例如，经常看到因为配置引发的各种问题，有些直接导致出现重大事故。我们现在发配置特别担惊受怕，担心手一抖就导致重大事故，我们也在探索怎么通过更好的办法预防配置的风险发生。
确实，我们通过FMEA梳理出来，发现配置这个东西，风险无处不在。
但总结起来归根到底就是太灵活，也分析了历史上出现过的大部分故障的原因，大部分是因为配置太灵活。
- 可配置的内容太灵活，所以也非常容易配错；
- 配置发到线上的流程太灵活，跟代码不一样，没经过测试验证也可以发到线上；
- 使用配置太灵活，觉得啥都用配置最好，觉得可配置就是牛逼；
因此需要思考在控制灵活性的前提下提高效率。
五、突破机会怎么找
整体的要求就是快、准、稳，下图是我们团队梳理的运营支持研发全景图。同样也是针对提出的快准稳三个愿景作出的一些梳理部署吧，上层是我们支撑的业务板块，底下是我们为了实现快准稳，需要沉淀的基础能力。
我最近在维护这个图的时候发现个很有意思的事情，我看到上层是不大稳定的，有一些我们之前做的运营工具，比如收银员激励、智慧推荐什么的，因为市场环境和监管要求的变化，已经不存在的，但底层的东西是相对比较稳定，而且需要不断的做深做细，才能真正不断的提高运营效率。
例如，一个上报，之前从来没有想过背后有这么多技术难点和挑战，例如配置，之前做了一个可以快速生成配置页面的能力，觉得已经很牛逼了，现在发现，除了把页面作出来，还要考虑配置安全性，怎么防止配错，怎么防止自己的服务挂了影响上游，都是更深入的问题，需要想办法突破。
那么，这些也是我们运营研发技术上持续突破的机会！
六、结语
以上就是运营开发在技术上持续突破的实践经验。
最后，新年之际，给大家送上一副春联，祝愿大家无论工作和生活都能持续突破！
