游戏开发者的项目管理：为什么你的游戏一再错过截止日期

问任何一个游戏开发者，是什么终结了他们上一个项目，你几乎听不到"代码太难了"这个答案。几乎总是某种形式的范围蔓延、倦怠、失去动力，或者就是搞不清楚接下来该做什么。游戏开发的技术层面得到了所有的关注，但组织层面才是真正决定游戏能否交付上线的东西。 这不是只有独立开发者在业余时间做自己热爱的项目时才有的问题。有真实预算和真实团队的工作室也会延期交付、砍掉功能或整个取消项目，因为管理层面崩溃了。一款能发布的游戏和一款永远停留在40%完成度的游戏之间的差距，几乎总是结构性的，而非技术性的。 游戏开发之所以特别难以管理，是因为它同时涉及如此多的学科。你不只是在写软件，而是在同一个项目内协调美术、设计、音频、叙事、程序、QA，有时还有市场营销。每个学科都有自己的工作流、依赖关系和"完成"的定义。如果你没有一个系统来把这一切聚拢在一起，事情将会分崩离析。

一个典型的软件项目有相对可预测的结构：收集需求、构建功能、测试、部署。游戏开发不是这样运作的。你有一个按自己的进度生产素材的美术管线；你有游戏设计，它本质上是迭代式的，因为你不到试玩就不知道某个东西是否好玩；你有依赖于最终视觉效果的音频；还有把这一切串联起来的代码。 游戏开发中的依赖关系链是残酷的。程序员无法实现敌人AI行为，直到设计师敲定战斗系统；动画师无法制作攻击动画，直到角色模型完成；音效设计师无法制作击打音效，直到动画计时确定。一个瓶颈会在整个项目中级联传导。 这就是为什么通用的项目管理建议对游戏开发者来说不够用。"用个待办清单就行了"在你有200个任务跨越5个学科且存在复杂依赖关系时是行不通的。你需要一个能同时处理视觉、技术和组织层面的系统。

对你的游戏项目最重要的一件事，就是把它拆分成里程碑——不是"完成游戏"这样模糊的里程碑，而是有清晰交付物和日期的真实、具体的里程碑。 一款典型的独立游戏可能有这样的里程碑：原型（核心机制可运行，使用占位美术）、垂直切片（一个完整关卡，具有最终品质的美术和音频）、Alpha（所有功能实现，内容大致完整）、Beta（内容完整，进行Bug修复）和Gold（上线发布）。每个里程碑都应该感觉像一条小型终点线，让你获得动力，而不是盯着一个无尽的待办事项库。 在每个里程碑内，按学科拆分任务：美术任务、程序任务、设计任务、音频任务。如果你在与团队合作，给每个任务设定优先级和负责人。追踪完成百分比，这样你就能一眼看出美术是否超前，而程序是否落后。这种可见性能防止那种"我以为我们快完成了"的意外——那会要了项目的命。

每个游戏项目都需要一份核心文档，描述游戏是什么、如何运作，以及计划是什么。叫它游戏设计文档、项目圣经，随你叫什么。重点是项目中的每个人——包括未来的你，那个会忘记三个月前在想什么的你——都能看到一个地方来理解正在构建什么。 这份文档不应该是一份没有人阅读的50页规范。它应该是一份结构化的、分节的文档，涵盖核心游戏循环、关键机制、美术方向、技术需求和项目范围。保持简洁，并保持更新。一份六个月前还准确但此后从未被触及的设计文档，比没有文档更糟糕，因为它会主动误导人。 将任务链接回这份文档的相关章节。当有人问"我们为什么要构建这个功能"时，答案应该是一个指向相关章节的链接。这在从高层愿景到单个任务之间创造了一条推理链，让每个人保持对齐。 IndieDevBoard 中的设计文档让你可以创建带有章节的结构化文档，这些章节就在看板和里程碑旁边。你更新文档、更新任务，一切保持连接，而不需要在五个不同的应用之间切换。

游戏开发本质上是视觉性的——你在构建人们会看到并互动的东西。你的项目管理应该体现这一点。 看板追踪任务效果很好，因为你可以一眼看到什么在进行中、什么被阻塞了、什么完成了。但对于游戏开发来说，你还需要时间线视图，以便看到里程碑在未来几周和几个月中如何排列。一个显示美术管线与程序冲刺并行运行的甘特图，会立刻告诉你某些事情是否会发生冲突。 灵感板是另一个游戏开发者在项目管理中未被充分使用的工具。把你的美术风格、UI设计、环境概念和角色美学的视觉参考收集在同一个地方，意味着你的整个团队都在使用同样的视觉语言。这能防止一个极其常见的问题：角色美术师和环境美术师最终风格完全不同，因为没有人建立过共同的参考。

以下是关于游戏开发的一个令人不舒服的事实：你最初的愿景太大了。总是如此。能够交付游戏最重要的技能是削减功能，同时不削减项目的灵魂。 做到这一点的方式是从第一天起就对优先级毫不留情。每个功能、每个机制、每个素材都应该被标记为"必须有"、"最好有"或"额外目标"。当你不可避免地落后于计划时——你一定会——从底部往上砍。先砍额外目标，再砍"最好有"，"必须有"是你的最小可行游戏。 用你的任务管理追踪这一点。在看板上使用优先级和标签，这样你可以筛选，只看关键路径。当距离目标发布只剩三周、而你已经落后时，你需要能调出仅包含"必须有"任务的视图，清楚地看到你与上线之间还有什么。这种清晰感才是让游戏走出大门的东西。 支出追踪也比大多数独立开发者意识到的更重要。如果你在购买素材、支付外包或运行任何形式的预算，你需要在项目层面知道钱花在了哪里。小额购买积累得很快，失去对支出的追踪是另一种让项目悄然死去的方式。

世界上最好的项目管理系统，也帮不了那些把游戏视为"某天会完成"的人。设定一个日期——即使是随意的，即使你之后会调整它。有一个目标会改变你对每个决定的思考方式。 有了截止日期，"我该加入这个很酷的新功能吗"就变成了"我能加入这个功能，同时还能按时交付吗"？这种重新框架很有力量，它把每个功能请求从愿望清单上的条目变成了一次权衡计算。 真正交付游戏的开发者，不一定更有天赋或更有纪律。他们是那些把自己的项目当作一个项目来对待的人——有结构、有可见性、有责任感。他们把工作拆分成可以追踪的小块，记录自己的决策，在不得不砍时砍功能，并且即使在不再有趣的时候也继续前进。 无论你是一个有梦想的独立开发者，还是一个努力赶上Steam发布窗口的小团队，你的游戏存在于世界中与只存在于你硬盘上之间的差距，归根到底取决于你如何管理工作。像认真对待代码和美术一样认真对待这件事，你的成功概率会大幅提高。