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

基础建设

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

代码架构

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

团队

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

需求管理

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

流程

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

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

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