《游戏项目系统工程手册》合订本vol.6

本文出自鸿杰撰写的《游戏项目系统工程手册》第三章——

3.9 经费：预算管理概述

3.10 需求剪裁与调整指南

前文回顾：【PM手册】什么是系统工程？研发管线和制作流程如何规划？

《游戏项目系统工程手册》合订本vol.2

《游戏项目系统工程手册》合订本vol.3

《游戏项目系统工程手册》合订本vol.4

《游戏项目系统工程手册》合订本vol.5

文档信息
目标读者： 制作人、项目经理、技术负责人、财务对接人
阅读收益： 读完本文，你能：掌握游戏项目预算管理全流程，理解生命周期成本概念，学会预算编制、审批、监控方法。

1 预算管理概述

预算管理包括四个阶段：规划、计划、预算、执行，核心是回答三个问题：为什么需要这笔钱？钱花在哪里？钱花得对吗？

预算管理的起点是明确的项目目标、团队规模估算和开发周期规划。输入包括项目计划（开发周期和里程碑）、人力计划（团队规模和岗位需求）和技术方案（服务器、工具和外包需求）。核心产出包括预算方案、执行报告和调整申请。

2 相关方与职责

架构师职责

架构师在预算管理中需关注：

1. 技术成本估算：评估服务器、带宽、工具链等技术投入

2. 生命周期成本：预测运营阶段的持续成本

3. 技术决策影响：分析技术选型对预算的长期影响

3 预算流程与时间线

四个阶段

不同规模项目的预算模式

关键原则：无论哪种模式，核心都是提前规划、预留缓冲、持续跟踪。独立团队尤其需要关注现金流健康和烧钱速率控制，按开发阶段分配资金，确保项目能撑到下一个融资或收入节点。

4 核心工作

预算编制与审批

预算编制常用四种方法：自上而下（公司定总额、项目分解，快速但可能脱离实际）、自下而上（项目汇总需求、公司审批，准确但耗时）、零基预算（从零论证，严谨但工作量大）、增量预算（基于上年调整，简单但可能累积偏差）。游戏项目通常组合使用多种方法：核心玩法和美术团队采用自下而上估算（人力和外包占大头，需要模块级精度），营销预算由发行方自上而下分配（基于DAU目标和买量单价倒推），技术基础设施采用零基预算（服务器和工具链随项目变化大，历史数据参考价值有限）。

编制步骤均为：收集各模块成本需求→按类别汇总→与历史数据对比审核→提交审批。游戏项目的成本类目比一般软件项目更复杂，编制时需覆盖以下特有项：

• 美术与音频外包：角色、场景、CG、音乐音效，按资产清单逐项估算

• 多平台适配：每增加一个平台（PC/主机/移动端），测试和适配成本增加20-40%

• 本地化：文本翻译、语音配音、文化适配，按目标语言数量估算

• 合规与版号：各目标市场的年龄分级、数据合规、版号申请周期和费用

• LiveOps​内容管线：上线后持续更新的美术、活动、赛季内容，需在建线阶段投入管线工具成本

预算审批与项目生命周期阶段绑定：

• 立项审批：基于核心玩法原型和GDD，审批项目总预算框架（准确度±30%）

• 里程碑审批：Alpha/​Beta​阶段根据实际数据调整预算（准确度±15%）

• 增资审批：因需求变更或市场环境变化需要追加预算时触发专项审批

游戏项目预算的核心挑战是高不确定性——核心玩法是否有趣、玩家是否买账，这些问题在立项时无法精确回答，导致预算审批本质上是"在不确定性中做资金承诺"。

关键提醒： 无论项目规模大小，都必须预留10-20%的应急缓冲。游戏开发存在大量不确定性，预留缓冲能避免意外情况导致项目资金链断裂。

预算执行监控

监控要点：

偏差预警：

超预算应对流程

5 生命周期成本管理

核心概念

生命周期总成本不等于开发成本。游戏上线只是成本故事的开始——服务器、带宽、内容更新、客服、合规审计等运营成本持续发生，且往往超过开发成本。

一个典型误区：开发阶段选择"省钱"方案，上线后运营成本远超预期。例如，选择自建服务器而非云服务，开发阶段节省50万，但运营阶段因运维人力和故障处理每年多花200万——三年下来，"省钱"决策反而多花了550万。

各阶段成本特征

不同开发阶段的主要成本驱动因素截然不同：

占比说明： 上述比例为中型及以上商业项目的参考范围。独立游戏预制作占比更高（20-30%，核心玩法验证周期相对更长），3A项目全面制作占比更高（50-60%，资产量和外包规模大）。运营阶段占比随运营时长持续累积——一款运营3年的手游，运营总成本通常达到开发成本的1.5-2倍。

成本预测方法

预测公式：

预测要点：

避免"研运脱节"

"研运脱节"是预算失控的常见根源：研发团队只关注开发成本，忽视运营阶段的成本结构。具体表现及应对：

通用原则：立项预算评审中，强制要求包含运营成本预测（至少覆盖上线后12个月）。任何"开发阶段省钱"的决策，必须同时评估对运营成本的影响——省下来的钱是否会在运营阶段数倍偿还。

成本追踪建议

6 预算评审门径

预算管理需要在关键节点设置评审门径：立项时评审预算方案合理性（需求依据是否充分、缓冲是否充足、风险识别是否完整），执行中评审调整必要性（调整原因、影响范围、资金来源），里程碑时评审执行情况（执行率、偏差原因、后续预测）。评审参与人员通常包括制作人、项目经理、技术负责人和财务代表，重大调整需公司管理层参与。

预算管理成功标志

1. 预算申请评审通过：方案合理可行

2. 执行偏差在可控范围内：±10%以内

3. 无重大预算事故：无因预算问题导致项目停滞

4. 经验教训总结完成：形成可复用的预算模板

7 常见问题与避坑指南

运营成本失控与执行偏差

问题表现： 上线后发现运营成本超出预期，或开发过程中实际开支大幅偏离预算。

根本原因： 生命周期成本预测不足，缺乏持续跟踪机制，偏差发现太晚。

解决方案：

1. 预防：开发阶段使用生命周期成本预测方法，提前估算运营成本，预留20-30%缓冲

2. 监控：建立月度预算执行报告机制，设置偏差预警阈值（如±10%）

3. 应对：定位超支项→评估影响→制定方案（技术优化降本、运营调整减支、资金申请增资）→每周跟踪

预算编制缺乏依据

问题表现： 预算数字拍脑袋，执行时大幅偏差。

根本原因： 缺乏历史数据参考，估算方法不科学。

• 建立项目成本数据库

• 采用类比估算法参考类似项目

• 分阶段细化预算，随项目进展调整精度

外包成本超支

问题表现： 外包费用远超预期，侵蚀预算。

根本原因： 外包范围不明确，变更频繁。

• 外包前明确交付标准和验收条件

• 合同中约定变更成本

• 预留外包缓冲资金

文档信息

目标读者： 制作人、项目经理、技术负责人、策划负责人

阅读收益： 读完本文，你能：掌握需求剪裁判定准则，了解三种剪裁方法，根据项目规模合理调整需求范围。

需求剪裁概述

在游戏开发过程中，"需求"指项目相关方提出的具体要求，通常以需求文档形式呈现。

每个游戏项目的团队规模、技术栈、预算和周期各不相同，流程规范的执行力度需随之调整以控制成本。剪裁和调整适用于各种规模的项目，但独立游戏与3A大作面临的挑战不同。独立游戏技术栈精简、团队规模小，需要在有限资金和周期内通过灵活方式实现项目目标。

前置条件： 项目目标已确定、初步需求列表已整理、资源约束已明确。

输入： 项目计划（开发周期、预算）、需求列表（功能需求清单）、资源评估（团队规模、技术能力）。

核心产出： 剪裁决策表（需求优先级和剪裁记录）、流程管理计划（剪裁说明和替代方案）。

剪裁与调整的定义

• 剪裁 (Tailoring)：根据项目目标和资源，减少项目需求。剪裁后需撰写说明，记录在《流程管理计划》中。

• 调整 (Customiz​ing)：基于经验制定适合项目的开发要求。一般无需特别说明，重大改动需记录。

相关方与职责

剪裁的判定准则

剪裁空间取决于以下项目特征：

综合判定方法

对上述8个因素逐一评估，按照"高/中/低"三个等级量化剪裁空间：

综合判定流程：

1. 逐项评估：对8个判定因素分别打分（高/中/低）

2. 汇总判断：统计各等级数量，多数等级决定剪裁策略（参考上表）

3. 底线检查：无论综合结果如何，涉及核心玩法循环、合规要求、安全性的需求不得剪裁

示例： 某中型独立手游的评估结果——游戏类型"中"、关键程度"低"、可接受风险"中"、品牌意义"低"、复杂程度"低"、游玩时间"低"、投入成本"低"、发行限制"中"。"低"占5项、"中"占3项，判定为"审慎剪裁"，优先缩减范围而非删除。

需求剪裁记录方法

需求优先级表

需求优先级表用于记录需求的适用状态和剪裁决策。

记录内容：

执行方式：

由制作人、技术负责人、策划负责人组成评审小组，依据游戏目标和资源约束，将剪裁决策记录到表中。

审批、存档与相关文档

审批流程：

1. 需求优先级表与《流程管理计划》一同提交审批

2. 剪裁结果需获得需求方认可

3. 通过审批的说明传达给团队每位成员及管理层

相关文档：

剪裁的方法

剪裁通常有三种做法：

剪裁风险删减需求可能带来的风险：

• 核心玩法不完整

• 用户体验降低

• 发布后需要额外开发

• 影响商业表现

删除不适用的

适用场景： 项目中明确不存在对应需求场景，该需求与游戏设计方向无关。

操作步骤：

1. 逐条审视需求列表，标注每条需求与当前项目的关联性

2. 对标注为"不相关"的需求，确认是否在任何未来版本中都不会用到

3. 若确认无需保留，标记为"删除"，记录删除理由

判断标准： 当一个功能在当前项目及可预见的迭代周期内都不会被使用时，即可删除。

游戏案例： 某款纯单机RPG游戏，在需求梳理阶段发现列表中包含多人联机相关的需求条目（服务器架构、匹配系统、好友系统、语音聊天、排行榜）。评审小组确认该游戏定位为沉浸式单人叙事体验，不存在多人元素，也无后续扩展多人的计划。最终将上述5条需求全部标记为"删除"，在需求优先级表中记录理由为"纯单机游戏，无联机需求"，替代方案填写"无"。此举减少了约15%的需求条目，使后续设计和测试工作更聚焦。

删除代价高的

适用场景： 需求本身合理，但实现成本远超其带来的价值。

1. 对每条保留的需求，评估实现所需的代价（人力、时间、技术难度、外部依赖）

2. 评估该需求对项目目标的贡献程度

3. 比较"实现代价"与"不实现的风险"，当代价显著高于收益时，标记为"删除"

4. 为被删除的需求寻找低成本替代方案

判断标准： 综合评估以下维度——

游戏案例： 某射击游戏原计划加入"家园建造系统"，允许玩家在基地中自由建造和装饰房屋。评估后发现：该系统需要2名设计师和1名程序全职开发3个月，占团队总人力约12%，且会导致关键里程碑延迟3周。经评估，该功能对核心射击体验无贡献，玩家调研中仅8%的受访者表示关注此功能。评审小组决定删除该需求，在需求优先级表中记录理由"实现成本高、对核心体验无贡献"，替代方案"无"。

改变范围

适用场景： 需求不能删除（影响核心体验），但当前资源无法满足完整实现，需要在"开发代价"和"不满足需求的风险"之间找到平衡。

1. 将需求拆解为最小可交付单元（MVP）

2. 定义"完整版"与"缩减版"的范围差异

3. 评估缩减范围对用户体验的影响程度

4. 制定后续迭代计划，明确补全路径

判断标准：

• 核心玩法相关的需求：优先保障MVP完整性，可缩减数量但不可降低质量

• 辅助功能相关需求：可大幅缩减范围，后续迭代补全

• 内容型需求（角色数量、关卡数量等）：可缩减数量，保留代表性内容

游戏案例： 某手游项目原计划首发100个可玩角色，每个角色包含独立技能组、专属剧情、全套动画和皮肤系统。评估后发现：完整制作100个角色需要12名角色设计师工作8个月，远超项目6个月的开发周期。评审小组将需求拆解为MVP：首发30个角色，每个角色保留独立技能组和基础动画，暂缓专属剧情和皮肤系统。缩减后的工作量降至4个月，满足了发布时间要求。替代方案记录为"首发30个角色，后续每季度通过版本更新添加10-15个角色，优先补全玩家投票最高的角色"。

调整方法

调整与剪裁并列，针对的是"执行方式"层面的灵活化，而非需求本身的增减。调整适用于项目资源有限或团队规模较小的场景。

可调整的范围

调整的边界

游戏产品剪裁案例

大型项目 (A/B类)

对应方法： 改变范围 + 删除代价高的

项目背景： 《赛博朋克​2077》是由​CD Projekt Red​开发的开放世界​RPG，开发团队超过​500​人，项目周期长达​8​年，是公司继《巫师​3》后的核心战略产品。

面临的需求压力： 游戏原计划包含多条完整的主线分支、多个势力的深度互动系统、大量支线任务和开放世界活动。随着开发推进，需求膨胀导致项目严重超出预算和周期。

剪裁决策过程： 开发后期，团队对需求进行了大幅剪裁——删除了大量康陶势力的支线内容，缩减了部分开放世界活动的深度，降低了部分NPC交互系统的复杂度。决策依据是"保障核心主线剧情的完整性和稳定性"。

剪裁结果： 游戏按时发布，核心主线体验完整。但剪裁也带来了明显的副作用——部分区域显得空洞，被删除内容导致了剧情连贯性问题。

经验教训：

• 大型项目剪裁宜早不宜迟，后期剪裁的代价远高于前期

• 剪裁决策需评估对整体体验的连锁影响，而非孤立地看单个功能

• 即使是A类项目，也必须设定需求的"最大边界"，避免无限制膨胀

独立游戏 (C/D类)

对应方法： 删除代价高的（美术简化，资源投入核心玩法）

案例一：《杀戮尖塔》

项目背景： 由Mega Crit Games开发，核心团队仅4人，预算有限，开发周期约3年。

剪裁决策： 团队将美术资产大幅简化——采用简约的2D卡牌插画风格，场景美术以静态背景为主，角色动画精简到最低限度。将节省的资源全部投入到卡牌平衡性、数值设计和核心循环的打磨中。

结果： 美术简化反而成为游戏的标志性风格，玩家对"简洁但不简陋"的美术给予了正面评价。核心玩法的深度和可重复性成为游戏成功的关键。

案例二：《Rimworld》

项目背景： 由​Ludeon Studios​开发，核心开发者仅​1​人（Tynan Sylvester），开发周期超过​5​年。

剪裁决策： 采用了极简的俯视角像素风格美术，没有动画过场，没有3D建模。但保留了极其深度的模拟系统——殖民者的心理、社交、健康、技能等系统层层嵌套。

结果： 美术的极度简化使得单人开发者得以将全部精力放在系统深度上。游戏凭借"故事生成器"的核心体验获得了巨大的商业成功。

• 独立游戏应"保核心、砍外围"，将有限资源集中在核心竞争力上——杀戮尖塔保的是卡牌平衡性，Rimworld​保的是模拟系统深度

• 美术简化不一定影响品质感，关键在于风格统一和执行到位

• 明确"什么不能剪"比"什么能剪"更重要

演示项目 (E/F类)

对应方法： 删除不适用的（只保留唯一核心概念）

项目背景： 各类Game Jam作品，开发周期通常为48-72小时，团队规模1-5人不等。

剪裁策略： Game Jam项目的核心原则是"只保留最核心的玩法验证"：

• 删除所有非核心功能（存档系统、设置菜单、多语言支持等）

• 使用现成素材或极简美术，不投入美术制作时间

• 忽略所有非功能性需求（性能优化、代码规范、可维护性等）

• 仅验证一个核心玩法概念是否有趣

典型案例： 2017年Game Jam作品《节奏光剑》（Beat Saber）的原型版本，仅包含基础的方块切割玩法和一首音乐，没有任何菜单系统、分数系统或难度选择。但这个极简原型成功验证了"音乐+光剑切割"的核心体验足够有趣，随后获得了投资并发展为完整商业产品。

• 极短周期项目的剪裁原则是"能砍尽砍"，只保留唯一的核心概念

• 原型的价值在于验证假设，不在于功能完备

• 优秀的Game Jam作品往往是"剪裁到极致"的结果

附录：常见问题与避坑指南

本附录汇总需求剪裁中的常见问题和解决方案。

相关方参与与认可不充分

问题表现： 剪裁决策未充分听取相关方意见，或未获得需求方认可，导致后续争议或返工。

• 剪裁评审必须包含所有相关方代表

• 使用​RACI​矩阵（Responsi​ble​执行者-Accounta​ble​决策者-Consulted​顾问-Informed​知会方）明确决策权

• 重大剪裁需获得需求方书面确认，记录在《流程管理计划》中

• 定期回顾剪裁决策的执行情况和有效性

剪裁决策缺乏记录

问题表现： 剪裁决策口头沟通，后续出现分歧无法追溯。

• 所有剪裁决策必须记录在案

• 使用需求优先级表统一管理

• 定期回顾剪裁决策的执行情况

剪裁过度导致核心体验缺失

问题表现： 为节省成本剪裁了看似非核心的功能，结果影响了整体体验。

• 明确核心循环，围绕核心循环保留必要功能

• 用原型验证剪裁决策的合理性

• 预留后续迭代空间

如何判断剪裁是否过度

问题表现： 团队不确定当前的剪裁幅度是否合理，担心"剪多了"或"剪少了"。

判断方法：

1. 核心循环测试：移除被剪裁的功能后，核心玩法循环是否仍然完整？如果断裂，说明过度

2. 用户故事验证：能否用剩余功能完成至少一个完整的用户故事？如果不能，说明过度

3. 替代方案检查：每项被剪裁的需求是否都有明确的替代方案或后续补全计划？如果没有，说明过度

4. 团队共识：团队核心成员是否都认可当前的剪裁方案？如果存在重大分歧，需要重新评审

参考标准：

注意：上述比例为经验参考值，具体项目需结合实际情况调整。超过警戒线时，应重新审视项目范围是否合理。

剪裁后需求变更如何处理

问题表现： 剪裁完成后，项目过程中出现新的需求或被剪裁的需求需要恢复。

处理流程：

1. 变更申请：提出需求变更申请，说明变更原因和紧急程度

2. 影响评估：评估变更对当前剪裁方案、项目周期和资源的影响

3. 评审决策：由评审小组决定是否接受变更，若接受需同步更新需求优先级表

4. 记录归档：将变更决策记录在《流程管理计划》的变更日志中

关键原则：

• 已剪裁需求的恢复成本通常高于初始实现成本（上下文切换、代码合并等）

• 优先考虑用替代方案满足新需求，而非直接恢复被剪裁的需求

• 变更评审应包含最初参与剪裁决策的相关方

关于作者

鸿杰

• 20年游戏开发经历，游戏美术、全栈美术、主美、技术美术。

• 跨多岗位的全链路经历，让我能从不同角色视角理解项目全流程的痛点，更懂如何让工程方法落地。

• 可关注公众号“系统联结”最快追更《游戏项目系统工程手册》