游戏项目最佳实践｜朝夕光年：从流程到数据，如何用飞书项目实现游戏质量管理一体化

🎯

飞书项目作为飞书旗下的项目管理平台，提供了高灵活度配置，为多种类型的项目管理提供可能性。对于产研团队，可实现从产品需求立项到功能上线的全流程质量管理，从缺陷的发现到缺陷的修复全流程跟进和复盘。

背景

近年来，游戏行业迎来了新的机遇和发展。

在这个过程中，游戏项目规模越来越大，需求变化频繁，资源投入增加，研发周期也随之变长。以量取胜的打法显然已经成为过去式，专注推出高品质的精品游戏成为游戏公司的新目标。只有快速响应用户反馈和市场变化，才能让玩家保持新鲜感和黏性，而保证质量则是迅速打入市场的有力武器。作为字节跳动旗下游戏业务品牌，朝夕光年也越来越重视对游戏开发质量的管理。

尤其在游戏上线后的运营阶段，游戏的 BUG 数量如何，是否有影响游戏运行的严重 BUG 存在，如何监控 BUG 数量，建立一套有效的缺陷质量管理流程，对于打造一款好玩且 BUG 少体验好的游戏至关重要。

缺陷质量管理集中体现 PDCA 循环上：P（Plan）计划 - D（Do）执行 - C（Check）检查 - A（Act），周而复始地进行质量管理，实现过程的持续性优化。

就缺陷管理而言，朝夕光年始终坚持应在缺陷被修复的基础上持续地改进开发过程/缺陷发现过程，分析/定位缺陷的共性原因，最终实现缺陷预防。

用户痛点

缺少与团队业务流程适配程度高的管理工具，缺陷提交标准难统一，进度跟踪透明度不高。
缺陷提交之后，难以及时分配和同步负责人，历史缺陷逐渐积累。
修复和关闭缺陷的标准不一致，需要从各处抓取复盘数据，费时费力。

解决方案

在飞书项目中搭建标准的缺陷提交流程，利用智能化能力便捷提交缺陷，统一记录。
飞书项目支持自动同步角色与人员，根据阶段、类型等分配负责人，避免责任不清。
灵活配置的字段既能统一抓取数据，也能针对不同人员设置可见性，数据维度一致可度量。

飞书项目 X 缺陷流程管理

如何搭建流程

飞书项目模板库提供了标准的缺陷流程。尽管不同的公司缺陷处理流程不一样，但基本的流程是相似的，状态基本会经过Open - Inprogress - Resolved - Closed - Reopened - Shelved。在标准流程基础上，还可以根据自身诉求灵活调整状态和字段来适配个性化场景。

如何提交缺陷

在搭建好缺陷提交流程的基础上，朝夕光年根据反馈来源类型衍生出了以下两种提交缺陷方式：

平台能力：需求下快速提交缺陷，缺陷无遗漏

通过飞书项目的关联能力，朝夕光年将缺陷列表关联在游戏开发需求的流程上，QA 在提测阶段就可以直接在需求【关联缺陷】直接新增缺陷。这样不仅实现了需求与缺陷相互关联，也能直接同步到缺陷工作项中统一管理，确保 BUG 无遗漏。

集成能力：飞书项目的开放能力和飞书话题群自开发集成，实现客服一键提单

游戏上线后，玩家反馈给客服 BUG 如何统一收口到飞书项目？飞书项目完备的开放接口可以很好地和飞书话题群集成，客服发布一条话题即可同步创建一条缺陷到飞书项目并通知相应的负责人，基本遵循搭建话题群 --> 自开发集成 --> 话题群提交反馈 --> 飞书项目同步创建缺陷工单的步骤。

⚡

@飞书项目机器人即可生成以下卡片信息

【反馈类型】缺陷

【反馈名称】无法撤回英雄

【USER ID】 123456789

【问题描述】玩家反馈自己英雄一直未返回主城，也无法撤回，从玩家反馈的视频上可以看出存在异常，辛苦帮忙看看。

【问题严重级别】p1

【客诉量】1

【服务器】12345

【问题发生时间】2023年5月5日

【咨询渠道】客服系统

【设备系统】IOS

【相关图片/视频】

如何流转缺陷

QA 收到所有的 BUG 反馈会进一步的过滤，通过补充填写字段信息，判定 BUG 是否有效并流转到下一个状态，飞书项目可实现配置不同字段的可见性判断缺陷状态的流转：

是否有效：决定缺陷是否需要修复
有效归因：定位缺陷产生的原因（可见条件和必填条件为：是否有效等于是）
无效归因：产品设计问题还是重复BUG（可见条件和必填条件为：是否有效等于否）
影响内容：明确影响面确定优先级

如何跟踪缺陷

在飞书项目中，可以切换不同类型的视图，或者根据条件创建不同维度的视图，定期跟进目前待处理的缺陷进展，保障项目发布质量和玩家体验。

而其中最受朝夕光年开发人员欢迎的，还是看板视图。在缺陷看板中，研发人员只需要横向拖拽看板模块，就能便捷地流转缺陷状态，可视化整个开发链路的阻塞点，快速驱动项目上线。

辅以自动化能力，操作人在飞书项目后台进行缺陷提交、人员分配、状态流转等关键动作时，飞书项目机器人就会自动提醒和通知到相关人员和群组，帮助开发人员和制作人及时发现阻塞点，催促当前负责人及时修复目前项目中的致命缺陷。

缺陷数据分析

缺陷流程沉淀的数据如何转化为游戏项目不断迭代的资产至关重要，飞书项目度量作为一个效能工具可以根据客观的数据协助朝夕光年的游戏项目组长期、高效地开发出有价值的产品，做出有价值的项目。

如何搭建度量图表

飞书项目中不仅预置了燃尽图、累计流图等度量图表，还支持用户根据实际场景灵活选择字段、创建公式来自定义指标和维度。

朝夕光年将 BUG 数量、修复率、留存趋势等关键指标都通过提前配置固定在数据看板上，日常站会或是项目复盘时，只需要打开度量模块，无需手动更新即可看到最新、最全的数据情况。

数据指标下钻分析

朝夕光年通过不同的度量图表定义并分析数据，下钻并定位缺陷的共性原因，持续性优化项目质量。

BUG总数和致命BUG数从全局的视角了解当前的质量情况，通过环比进一步的关注缺陷的增幅。

通常缺陷修复率应该超过95%，虽然遗留缺陷中不能有严重的缺陷，但同时也需要注意，缺陷遗留率不能超过5%。如果遗留的缺陷数太多，发布上线后系统不可控成本会增加。

缺陷的修复时长和数量可以定位到长尾数据，持续优化并解决长尾缺陷。

一般来讲缺陷密度<0.2则认为质量良好，定期复盘不同的阶段漏测率可以更好地完善测试用例，更准确地预防缺陷。

度量指标公式

以下公式指标仅供参考，可按需自定义修改。

名称	计算口径	度量计算公式
BUG总数	某个版本下的 BUG 总数	sum(工作项id)
致命BUG数	某个版本下的 P0 BUG 总数	sumif(优先级=="P0",工作项id)
BUG 修复率	（BUG 总数 - 未解决 BUG 数）/BUG 总数	COUNTIF(状态=="RESOLVED" or 状态=="CLOSED",工作项id)/（COUNT(工作项id)
Reopen 率	Reopen BUG 数/ BUG 总数	COUNTIF(状态流状态标识=="REOPENED"，状态流进入次数）/ COUNTIF(工作项id)
缺陷修复时长	已修复的 BUG 数/BUG 总数	(SUMIF(ISNULL(归档日期)==false,归档日期)-SUMIF(ISNULL(归档日期)==false,提出时间))/(COUNTDISTINCT(工作项id)*3600）
缺陷修复数量	每天修复的 BUG 数	COUNTIF(TOSTARTOFDAY(MAXIF(状态流状态标识="CLOSED",状态首次开始时间))=TOSTARTOFDAY(TIMELINE_CURSOR()) , 工作项id)
缺陷密度	(P0 BUG10+ P1 BUG3+P2 BUG1+P3 BGU 0.1)/Case 总数	（COUNTIF(优先级=="P0",工作项id)10+COUNTIF(优先级=="P1",工作项id)3+COUNTIF(优先级=="P2",工作项id)1+COUNTIF(优先级=="P3",工作项id)0.1)/ Case 总数
漏测率	线上BUG数/线下 BUG 数	COUNTIF(是否漏测=="是" ,工作项id) /（COUNT(工作项id)

综上，在游戏行业不断创新突破的过程中，规范的缺陷流程帮助游戏团队梳理清晰的流程图，数据化的图表协助制作人及时敏锐地发现团队中的问题，便于资源协调不断提升项目质量从而优化玩家体验。而飞书项目对于游戏工作室的助益不仅仅体现在质量管理上，了解更多关于飞书项目的游戏行业解决方案：飞书项目 X 游戏行业，打破游戏产研中的「战争迷雾」

朝夕光年：从流程到数据，如何用飞书项目实现游戏质量管理一体化

背景