活动系统开发与验收
该标准工作流分为活动上线前的开发设计和活动上线后的验收,是游戏活动开发与验收的标准工作流程。(但其中包含的需求模板库是活动与系统通用的)
这个知识体为什么存在?
游戏上线后需要不断推出新的活动,创造新鲜感,定期为玩家提供F+,刺激付费,提升留存。但如果活动设计出现失误,会引起玩家的负性情绪,出现F-。所以我们始终需要一个参照标尺来设计和验收活动设计成果,避免活动上线后产生不可挽回的损失。 每次由我们自己思考活动设计思路,或者听取CP方提供的活动方案后,需要标准化工作流程模型作为理论指导,提升工作效率。每次活动结束后,都需总结当次活动相关数据与经验对该理论模型进行验证或更新。
这个知识体的时空坐标
这个知识体在我们的知识体系中,属于哪个时期的问题。 在实践中,应该在什么时期范围内使用这个知识体。 什么样的时期不适合用这个知识体。
属于产品类系统层中的活动系统模块。
这个知识体适用什么人群? 请描述他们的属性。
从数据方面,考虑活动的目的是为了赚钱,活跃,还是品牌,或者是三者之间的组合,明确通过哪些指标在多次活动间做出对比,验收合格程度。一般来说,商业目的都是一些相对目标,如“本次付费额目标比上次多8%”或“游戏付费额要与竞品一致”等。商业目的指导设计目的的挑选逻辑。
明确商业目的后,对玩家群体进行用户分群,分析并挑选最大化商业目的的用户需求,并产生对应的n个设计目的,设计一个完整的活动系统框架并用OPF表证明体验的完整性。设计层的目的主要是统筹全局,思考框定需求的上下限,避免犯错。
体验层负责往设计层的框架中填入具体的内容,进行体验验收,检查是否有设计层缺乏考虑导致的错误,对照需求验收表进行活动验收并产出数据埋点方案。
即活动的盈利需求。
活动需要有一定的活跃需求,不能片面追求盈利而导致大量用户流失,影响以后的收入。简单地说就是“把韭菜留住下次割”。
有些公司并不靠游戏营收生存,而是靠口碑积攒拉投资等,这时候活跃和收入就不是最重要的因素了。各大平台的好评占比与评分、玩家社区的口碑才是最应关注的维度。
我们需要定义玩家群体,进行用户分群以分析不同的群体需求。为了避免遗漏某些用户群体,我们通过三个用户属性参数排列组合进行分群:肝度、氪度、练度
常见的需求数据库,通常来源于当次活动商业需求推导出的群体需求、基于知识推导的需求(例如其他游戏的经验)和基于自身运营经验的安全需求,在需求模板数据库中基于最大化商业目的的逻辑挑选出设计层所需要的设计目的。
对系统框架结构进行验收,检查设计目的有没有得到实现。注意,这时活动还未上线实装,验收标准不涉及具体指标,只验收维度。活动验收表是从需求模板库中抽取挑选出来的。
对详细设计进行验收,用OPF表检查系统是否有完整的体验。
体验层设计完成后,要明确本次活动需要得到哪些数据,然后对一些活动环节进行数据埋点,在活动运行期收集相关的微观数据进行体验分析,在活动结束后收集相关的宏观数据进行商业验收与总结。
与玩家体验有关,一般精确每天每个关卡,例如关卡留存漏斗、活跃玩家平均游戏时长等。
与商业目的有关,只关心活动期间的总体宏观数据。
如何基于需求一步一步分析出结论的。
模型总体分为三个大块:商业层、设计层和体验层。
首先,一个活动的出发点应是商业层面的需求,要明确这次活动到底是为了赚钱,还是活跃,还是口碑,亦或是其他。不管是什么需求,都有个确切的目标,然后分析这个目标有多少维度可分析,方便数据进行埋点。
明确了这一需求后,我们需要对我们的活动参与者(即玩家)进行分析。玩家群体非常庞大,哪种人都有,主观划分很可能遗漏一部分玩家群体。所以我们对玩家群体进行参数化划分,设置三个参数:肝度、氪度、练度。这样就能清晰地划分玩家群体,精准分析群体需求,然后根据最大化商业目的的逻辑挑选出此次需要实现的需求列表。
为了提高以后的产出效率,我们需要设置需求模型库,方便日后反复更新和使用。需求模型库的来源除了当次需求分析推导,还来源于外部知识的输入,例如基于其他游戏的现成知识进行推导产生的需求,和基于运营经验(成就或事故)产生的安全需求。然后在需求模板库内,挑选出最大化商业目的的需求产生设计目的。
然后,基于多条设计目的设计出一个活动系统框架雏形,进入体验层,首先用opf表验证这个框架可以给玩家提供完整的体验,这时就需要有一个标准判断这个体验是否达到设计目的,那就需要有活动验收表。然后在这个系统框架内填入具体内容,产出数据埋点方案以便验收分析。
验收无误后,活动上线期间就需要根据埋点方案监测数据进行玩家的体验分析,积累经验教训。
活动结束,也需要进行数据总结,评估是否达到商业目的,活动验收是否合格,整个模型就形成了一个有生命力的闭环。
通过建立这个模型,我们以后推新活动的时候能迅速找到思路,通过标准化模块化流程进行活动设计和验收,提高工作效率。
“0”学习成本任务,可直接执行。 “1”学习成本任务,需要进行一次示范即可独立执行。 “C”学习成本任务,需要进行培训,考试合格后方可执行任务。
本任务属于 “C”学习成本任务
这样设计工作流的思路。 原理中的逻辑是事务本身的规律,这里的方法论考虑到使用者的现实情况,面向执行者。
流程编号解释:
编号 | 目标 | 方法 | 备注 |
1 | 得出商业目的及验收指标 | 数据分析、开会讨论 | 本次活动付费额较上次提升10% |
2 | 用户分群,分析需求 | 对照用户分群表进行主观分析 | 又肝又氪的大佬需要有养成反馈和氪金的优越感,偶尔也会需要氪金护肝 |
3 | 挑选出本次需要实现的需求列表 | 以最大化商业目的逻辑挑选需求清单 | 例如本次活动商业目的为提升付费同时控制收益流失比,那么我们的主要考虑人群就是氪度高的人群,同时也要兼顾肝度高的人群,然后挑选这些人群的群体需求进行实现。 |
4 | 更新需求模板库 | 若发现需求模板库中存在没考虑到的点,及时反馈更新 | |
5 | 在需求模板库中挑选设计目的 | 在库中查阅是否有自己没考虑到的用户需求,结合本次需要实现的需求产生设计目的 | 有不少基于运营经验的安全需求是很难通过用户需求分析得出的,通过查阅获取这些经验才能在设计活动框架时避免犯错 |
6 | 生成一个活动系统框架雏形 | 产出一个有完整体验的活动系统OPF表 | |
7 | 明确活动验收表 | 整理清单后在需求模板库中复制粘贴过来 | |
8 | 系统的具体设计 | 在框架下的具体化细节化设计 | 要实现养成反馈的通常手段是有关卡难度梯度,但是具体梯度怎么定,不同的难度梯度怎么划分用户练度等,都需要具体设计 |
9 | 对照活动验收表进行验收 | 检查活动设计成果有没有满足设计目的 | |
10 | 活动上线 | ||
11 | 收集微观数据进行体验分析 | 数数上按数据埋点方案拉数据 | |
12 | 运营事故经验总结 | 处理运营事故,开会总结,更新需求模板库 | |
13 | 宏观数据商业验收 | 参照商业验收维度在游戏后台或数数上拉数据 | |
14 | 修正下次的商业目的 | 开会总结分析 | 1 |
这个事情如何做。
设计的工作流
分为活动系统设计工作流和活动验收工作流。
活动系统设计工作流
OPF表通过对一个最终目标进行下属子闭环的拆分细化,最终得出每一个闭环的循环模式。
【腾讯文档】混沌之域 OPF表 https://docs.qq.com/sheet/DSFJkS0JuQUJZenlz
上图只是整个OPF表中的一个闭环,目的在于展示OPF表的结构。组成该闭环的子闭环仍可根据需要,依照该结构进行拆分,直到拆解到最底层的闭环。 在闭环的拆封中,我们一般只考虑拆分此次活动中新设计的系统闭环,而不考虑那些已经存在的系统中的闭环。
验收表的验收条目出资需求模板库,这些验收条目绝大部分都是经过探索型任务的知识体、也就是以往的活动系统开发中得到的;如果有需要补充的条目,则是通过本次活动系统开发的活动目的、面向的用户群体、需求列表来决定。
【腾讯文档】设计目的验收表 https://docs.qq.com/sheet/DZUdmR2lNTUhQaVhO
该文档是整个活动系统开发与验收的总结文档,记录了包括产出OPF表和验收表,活动中各个系统的具体设计,以及后期验收与体验分析的全部内容。 但是在活动系统设计阶段阶段,该验收模板主要用于记录活动中各个系统的具体设计模式。
【腾讯文档】验收模板 https://docs.qq.com/doc/DZVhkcWVCelhMWGpz
活动验收工作流
通过对照OPF表进行验收能够帮我们迅速发现那些能够通过文字直接表述出的系统设计上的缺陷与不足。
通过对照验收表,能够帮助我们从维度上分析系统设计的框架结构是否能够满足需求。
知识体的执行产出了什么结果?
通过设计目的得出的系统设计OPF分析表
【腾讯文档】混沌之域 OPF表 https://docs.qq.com/sheet/DSFJkS0JuQUJZenlz
最终的系统设计是否满足OPF表的需求
对通过活动目的与需求模板库提炼出的设计目的进行验收的表格
【腾讯文档】设计目的验收表 https://docs.qq.com/sheet/DZUdmR2lNTUhQaVhO
设计目的是否有被满足,以及是被系统中的哪部分设计所满足的。
基于这个知识体的产出内容清单,通常在工作流的结尾有归档阶段, 会要求执行者将结果归档到这份清单当中。