运营开发如何在技术上持续突破

作者 | donnyhuang

为融水等地区用户提供了全套网页设计制作服务,及融水网站建设行业解决方案。主营业务为网站设计制作、做网站、融水网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!

​运营开发为什么会存在呢?“肯定是因为有运营嘛,有运营需求,需要开发完成这些需求,所以我们才存在。” 那么,真的是这样的吗?

一、运营需求是什么

这个话题首先要先分析:运营是干啥的?一个运营需求的生命周期是什么样的呢?通常来讲分三步:评估决策-落地-效果反馈,然后迭代改进。跟我们精益研发的价值循环有点像。

在这个过程中客户对我们有两个比较大的诉求,一个是运营工具,第二个就是数据,希望通过运营工具能快速落地他的想法,而不是需求提出要一两个月才能验证,这样就谈不上快速迭代。

另外就是希望一上线就要能看到数据反馈,能通过数据精确制导他们策略制定、评估更好的方案,精确制导。

二、客户诉求和现实差距

但理想和现实还是有差距的,我们过去在运营效率上还远远不够。

就如同大家在工作中经常遇到这样的场景:需要数据的时候发现没有上报,要等埋点几个月发布。

运营落地也是如此,大家有没有很熟悉这样的场景:

比如运营同学突然脑洞一开:“ XXX策略,可以让我们业务增长XXX倍,看看能否明天上线。” 研发只能说:“需求已经排满了,你和xxx pk一下,看能否排进下个月迭代。”

三、反思:运营研发是要思考如何不断的提高运营效能

所以反思一下,上面下的定义不对,我们存在的意义,是要完成运营需求,但又不止是完成运营需求,而是思考如何不断的提高运营效能。

甚至比较理想的是运营不再需要给我们提需求了,想要的时候就有了,因为如果走需求评审、排期、开发这种模式,代码写的再快都很难达到。

团队其实在有些场景上实际也有了初步探索,比如我们现在正在做的无埋点上报,目的就是不用提需求就获得数据,开发也不用埋点,想要的时候开启就有。

又例如工具落地,之前行业个性化返佣,落地一个政策,要找人要数据,定排期,再开发,一两个月才完成一个政策,最后还算错了,搞出故障。

现在我们对需求分类梳理,抽先出核心公式,实现标准化、模式化、配置化,完全产品自助就搞定了,而且会有比较软的风险管控措施,可以防止算错。比如,我们还做了通用的风控模型,每个政策起手可以防刷返佣。

当然这些还远远不够,目前可能只是解决了某些环节某些场景的问题。比如数据这块,除了上报,搭建数据仓库,数据应用、数据分析的效能提升也要不断加强。

例如,上次帮一个同学review代码,发现半年一共上传不到1000行代码,我很震惊,半年上传的代码这么少?后来问了才知道平时比较多的是帮产品临时分析,代码都没有沉淀,所以当时就给他们提了要求,要把这些分析需求盘点分类,模板化,沉淀下来,后面就不用老是来临时分析了。

同样,运营活动类的需求也是一样,不能一两个月才落地,特别今年涉资的业务都要求接入审计,防止资金风险,研发资源投入上需要增加,更加需要关注效率的提升。

另外还有一类需求,现在还有管控流程线上化的需求,比如人脸的设备管控,之前因为没有这些能力,很多流程是人肉跑的,但业务不可能停下等系统慢慢完善,导致系统建设跟不上业务发展,有很多债务,比如设备类型数据对不上,设备sn乱码等等。

这些工具也是可以抽象沉淀的,基于一个原则“”能标准化的标准化,实在个性化的可以分类分场景来模式化,实在全新场景的通过原子组件和框架实现低代码快速搭建系统”。总之新的管控场景要起手做好,不能再踩之前的坑了。

四、稳才是第一位

但是,做到这样是不是就够了呢?刚才讲的都是怎么快,其实最重要的是要稳,不要搞出问题,运营往往涉及资金或者其他资源,出了问题,影响是非常恶劣的。

例如,经常看到因为配置引发的各种问题,有些直接导致出现重大事故。我们现在发配置特别担惊受怕,担心手一抖就导致重大事故,我们也在探索怎么通过更好的办法预防配置的风险发生。

确实,我们通过FMEA梳理出来,发现配置这个东西,风险无处不在。

但总结起来归根到底就是太灵活,也分析了历史上出现过的大部分故障的原因,大部分是因为配置太灵活。

  • 可配置的内容太灵活,所以也非常容易配错;
  • 配置发到线上的流程太灵活,跟代码不一样,没经过测试验证也可以发到线上;
  • 使用配置太灵活,觉得啥都用配置最好,觉得可配置就是牛逼;

因此需要思考在控制灵活性的前提下提高效率。

五、突破机会怎么找

整体的要求就是快、准、稳,下图是我们团队梳理的运营支持研发全景图。同样也是针对提出的快准稳三个愿景作出的一些梳理部署吧,上层是我们支撑的业务板块,底下是我们为了实现快准稳,需要沉淀的基础能力。

我最近在维护这个图的时候发现个很有意思的事情,我看到上层是不大稳定的,有一些我们之前做的运营工具,比如收银员激励、智慧推荐什么的,因为市场环境和监管要求的变化,已经不存在的,但底层的东西是相对比较稳定,而且需要不断的做深做细,才能真正不断的提高运营效率。

例如,一个上报,之前从来没有想过背后有这么多技术难点和挑战,例如配置,之前做了一个可以快速生成配置页面的能力,觉得已经很牛逼了,现在发现,除了把页面作出来,还要考虑配置安全性,怎么防止配错,怎么防止自己的服务挂了影响上游,都是更深入的问题,需要想办法突破。

那么,这些也是我们运营研发技术上持续突破的机会!

六、结语

以上就是运营开发在技术上持续突破的实践经验。

最后,新年之际,给大家送上一副春联,祝愿大家无论工作和生活都能持续突破!

网站名称:运营开发如何在技术上持续突破
当前网址:http://www.stwzsj.com/qtweb/news16/8766.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联