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

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

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

3.9 经费：预算管理概述

3.10 需求剪裁与调整指南

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

文档信息

目标读者： 制作人、项目经理、技术负责人、财务对接人

阅读收益： 读完本文，你能：掌握游戏项目预算管理全流程，理解生命周期成本概念，学会预算编制、审批、监控方法。

1 预算管理概述

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

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

2 相关方与职责

角色	职责	关注重点
制作人	预算申请、整体把控	项目能否按预算完成
项目经理	预算编制、执行跟踪	预算执行率、偏差控制
技术负责人	技术成本估算	服务器、工具、外包成本
财务部门	审批、监督	合规性、成本控制
公司管理层	审批决策	投资回报率

架构师职责

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

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

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

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

3 预算流程与时间线

四个阶段

阶段	主要工作	关键产出
规划	分析内部条件和外部环境，制定年度绩效目标	战略规划、绩效目标
计划	制定计划和资源指南，进行计划分析和校正	年度计划白皮书、计划决策备忘录
预算	编制预算方案，提交审批	预算方案、拨款申请
执行	执行预算，监控使用情况	执行报告、结算报告

不同规模项目的预算模式

公司/项目类型	预算规模	预算周期	典型流程
大型厂商（3A大作）	数千万至数亿	按财政年度	提前3-6个月提交预算申请，多层审批，年度评审
中型公司（中型游戏）	数百万至数千万	按项目里程碑	项目立项时申请，里程碑评审调整
独立团队（独立游戏）	数十万至数百万	按阶段	预算≈可用启动资金，现金流管理为主，持续跟踪

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

4 核心工作

预算编制与审批

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

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

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

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

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

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

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

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

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

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

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

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

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

预算执行监控

监控要点：

监控维度	具体内容	频率
执行率	已使用预算 / 总预算	月度
偏差率	(实际支出 - 计划支出) / 计划支出	月度
预测准确度	预测值 vs 实际值	季度

偏差预警：

偏差程度	预警级别	建议行动
±5%以内	正常	继续跟踪
±5%-10%	关注	分析原因，记录备查
±10%-20%	警告	分析原因，制定调整方案
超过±20%	严重	立即上报，启动调整流程

超预算应对流程

超预算幅度	应对措施
10%以内	分析原因，项目内部调整，上报备案
10%-20%	制定调整方案，提交审批
20%以上	重新评估项目必要性，启动立项变更流程

5 生命周期成本管理

核心概念

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

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

各阶段成本特征

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

开发阶段	主要成本驱动	典型占比（参考）	预算关注点
预制作	核心团队人力、原型工具	约总成本10-15%	控制团队规模，快速验证核心玩法
全面制作	人力、外包、工具链	约总成本40-50%	外包管控是核心，需求变更是最大风险
打磨与上线	测试、优化、营销预热	约总成本15-20%	营销投入启动，性能优化成本易被低估
运营	服务器、内容更新、客服、合规	长期持续，可超过开发总成本	按DAU增长预测，预留弹性扩容预算

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

成本预测方法

预测公式：

预测要点：

成本类型	预测方法	关键参数
服务器与带宽	按DAU预估峰值 × 单用户成本	DAU增长率、CDN单价、数据库容量
运维人力	按24小时覆盖需求估算排班	值班人数、倒班比例、外包比例
内容更新	按更新频率 × 单次成本	月更次数、美术音频单价
合规与安全	按地区法规要求估算	目标市场数量、审计频率

避免"研运脱节"

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

研运脱节表现	评审节点	应对动作	责任人
技术选型只看授权费用，忽视长期运维复杂度	技术方案评审	提交"技术选型长期成本影响分析"，对比3年总成本	架构师
美术资产只看单次制作成本，忽视持续更新的管线成本	美术风格锁定	提交"持续内容生产的管线可行性评估"	美术总监
服务器架构只看初期部署成本，忽视DAU增长后的扩容成本	架构评审	提交"DAU从1万到100万的扩容成本曲线"	服务端主程

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

成本追踪建议

成本类型	开发阶段	运营阶段
服务器成本	开发测试环境	生产环境、CDN、数据库
人力成本	开发团队	运维、客服、社区运营
内容成本	核心内容	持续更新、活动内容
合规成本	基础合规	持续合规、安全审计

6 预算评审门径

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

预算管理成功标志

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

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

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

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

7 常见问题与避坑指南

运营成本失控与执行偏差

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

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

解决方案：

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

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

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

预算编制缺乏依据

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

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

• 建立项目成本数据库

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

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

外包成本超支

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

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

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

• 合同中约定变更成本

• 预留外包缓冲资金

文档信息

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

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

需求剪裁概述

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

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

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

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

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

剪裁与调整的定义

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

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

相关文档：

文档	作用
《需求优先级表》	记录剪裁结果和理由
《流程管理计划》	审批通过后传达给团队
《需求规范》	剪裁需求后的最终版本

剪裁的方法

剪裁通常有三种做法：

方法	核心判断	适用条件
删除不适用的	需求与项目无关	项目中不存在对应场景
删除代价高的	成本远超价值	需求合理但代价不可接受
改变范围	需求必须保留但资源不足	影响核心体验，无法直接删除

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

• 核心玩法不完整

• 用户体验降低

• 发布后需要额外开发

• 影响商业表现

删除不适用的

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

操作步骤：

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

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

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

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

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

删除代价高的

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

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

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

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

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

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

代价维度	高代价信号
人力	需要投入超过团队10%的人力持续1个月以上
时间	会导致关键里程碑延迟2周以上
技术	需要引入新的技术栈或外部中间件
外部依赖	依赖第三方服务且不可控

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

改变范围

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

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

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

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

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

判断标准：

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

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

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

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

调整方法

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

可调整的范围

调整对象	调整方式	适用条件
文档	合并多个计划为几页纸或图表，写入《流程管理计划》	团队≤10人
评审	缩短评审周期至几小时会议，问题记录在文档中即可	非关键里程碑
流程	将需求评审、技术评审、美术评审合并为一次综合评审	低风险需求
工具	用轻量工具替代重型管理系统	独立/小型项目

调整的边界

类别	内容	说明
不可调整	需求变更的审批流程	必须有记录
不可调整	核心玩法的设计评审	必须通过
不可调整	质量验收标准	不可降低
不可调整	合规与安全相关流程	不可省略
可以调整	文档的格式和详细程度	—
可以调整	评审的频率和参与人数	—
可以调整	非核心流程的执行方式	—
可以调整	管理工具的选型	—

游戏产品剪裁案例

大型项目 (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作品往往是"剪裁到极致"的结果

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

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