标签归档:活动

活动运营总结

背景

沉默一年,所做活动过百,所见所想,所思所虑。
活动常规化,小组年活动量1000+
人力不足,需求变更多,资源到位时间不定,

基础建设

  • 活动运营,想要快速,就需要有一个强大的运营平台的支持。
    建设:运营平台作为基础建设,需要作为重点投入,在建设过程中,强化运营支撑系统 大系统小做,不停的迭代,专门的产品跟进,与使用者沟通,将系统的开发和活动的开发交替给不同的开发,以调节和深入。另,在人力方面需要确保运营系统的投入。
  • 可扩展性:从运营支持平台的业务框架层面,在适应现有业务发展的基础上增加代码的通用性,在一定程度上保证系统的可扩展性。
  • 监控告警:运营系统的告警不能成为常态,一是可能会形成告警疲劳,从而放过真正的问题,二是告警会影响日常的工作开展,此时如果确认常态的告警是问题,则解决问题,如果是告警系统本身的问题,则优化告警系统。

代码架构

  • 前端静态页面,资源文件,活动隔离,按日期归档,CDN加速。
  • 前端公用库版本升级,不同版本间清晰隔离,不做兼容,固化业务逻辑抽象为公用组件,实现业务的可配置化开发。
  • 数据和页面分离,行为和表现分离,前端和后端分离,后端固化业务,中转接口。
  • 轻重分离,将固化的业务以更高性能的服务实现,将变化较多的业务需求以脚本类CGI实现。

团队

  • 固化业务外包,需要考虑人员的稳定性问题,这是一个矛盾点,并且外包政策需要切合公司的大的政策方向,存在风险点。
  • 新业务主力人员承担,待固化后可以给新同学或相对较新的同学实现。
  • 人员流动问题:做活动是比较重复的工作,在一般的团队,活动是给新人熟悉流程,熟悉业务的,而当做活动是常规工作,不做活动才是调节时,人才的选用育留是比较严峻的问题,留住一到两个核心人员,招聘合适的稳定的人,发展新的业务促进人员的成长。然而,人的问题往往是最根本的问题,也是最难解决的问题。人员的流动会成为一个一种常态,业务特性决定的,能减缓。
  • 新人问题:新人进来,总会踩到各种各样的坑,不管是产品还是开发,如何规避?新人手册?新人FAQ?导师审核?通过流程?不管是哪种方式,最后成长并适应下来的都是需要经过时间的洗礼。
  • 人员的分工:业务的模块化,从而引发人对这些模块的分工,人与模块对应上。比如接入新游戏,专人负责接入过程,负责接入后的文档撰写

需求管理

  • 同时以产品的维度和开发的维度组织;
  • 强跟进,变更的需求及时汇总;
  • 关注需求中提到的资源,如重构,资源单,号码包等,这往往是风险所在;

流程

  • 发布流程(活动发布过程检测,人工确认最终结果) 免测发布,版本发布,应用场景,开发自测,产品体验,外团体验
  • 后台CGI大变更灰度发布,前端大变更以大版本发布
  • 如何固化流程,如何确保上线的活动的正常可用,现在还在依赖于人工的检查和验证

以上是一年积累,有所感,有所想,无太多逻辑,且行且珍惜,只愿岁月静好。

产品驱动技术,改变的是kpi,
技术驱动产品,改变的是世界
这只是一个开发的遐想而已。
现实让我们知道疼!