作者：复盘延期的游戏项目，把原因写成一句实话，大多数时候不是“技术太难做不出来”。程序问题当然有，但真正把工期拖垮的，十有八九是两个不起眼的环节：需求变更失控，和美术返工。这两个环节有个共同点——单看每一次都很小，“就改一小块”“就调一版颜色”，累积起来却能吃掉项目一半以上的缓冲时间。
第一个环节：需求变更失控
游戏研发有个特殊性：需求天生模糊。做之前谁也说不准这个玩法好不好玩，于是边做边想、边看边改，听上去合理，实际是延期最大的来源。
常见的失控路径是这样的：立项时文档写了三十页，看着挺全，关键细节却全是“待定”；开发到第三周，策划玩了竞品，觉得“技能最好带点成长感”，改；美术稿出来，老板看了觉得“风格可以再年轻一点”，又改。每一次改动单拎出来都有道理，可改动有传导成本——一个技能逻辑动了，配套的UI、数值、音效、测试用例全要跟着动，评估时只算了“改一下”的半天，实际牵扯的是三四天。见过比较极端的项目，上线前需求文档改到第11版，光背包系统一个模块就推倒过两回，排期表从第二周起就没对上过现实。
怎么防？三个动作比任何管理工具都管用。给需求设冻结点，进入开发的功能，非bug级别的变更一律进下一版本，这句要写进项目制度，而不是靠项目经理个人魅力去拦；变更走评估，任何改动先回答三个问题——影响哪些已完成的部分、多几天、值不值，让提需求的人自己看到成本，一大半“顺手改改”会自动消失；核心玩法先做原型，花两三周做个能玩的糙版本，确认好玩再铺开完整开发，改动发生在原型阶段，成本只是开发阶段的零头。
缓冲怎么留也要诚实：需求稳定的项目，开发周期后留10%-15%弹性就够了；变更频繁的团队，留多少都不够——根子上还是先把变更管住。
第二个环节：美术返工
美术返工的可怕之处，在于它和需求变更互相喂养：需求没定稳就开工画图，需求一变，图全得重画；反过来，美术稿出来了，看着图提需求又特别容易——“这个角色能不能再瘦一点”。
防美术返工，核心就一条：规格先行。正式铺量之前，先把这几样定死——风格参考图（拿现成产品图圈出来“要这种感觉”）、主角色板和三视图、一张关键场景的成品样张。样张确认之前一张量产图都不开工；样张确认之后，量产阶段的修改只允许是执行错误（比例错了、色号不对），不接受“感觉不对”。
样张这关多说一句：审的时候别干看，把使用场景放进去——这张图标放进游戏界面是什么效果，这个角色跑起来是什么剪影。脱离场景看图，怎么改都“差一点意思”。另外确认人要少而固定，五个人的审美凑不出一个标准，甲方的确认流程乱，是返工的另一半来源。
两个环节咬在一起，才是真正的灾难
单独一个环节失控，项目咬咬牙还能追；两个一起失控，就是常见的死亡螺旋——需求变更导致美术重画，重画期间程序闲置等图，等图期间又有人提新想法，循环往复。碰上这种项目，延期的锅最后往往甩给“外包不给力”或“程序员太慢”，其实源头都在前面。
如果已经陷进去了怎么办？止损只有三板斧：需求当场冻结，范围砍到能上线的最小集合，里程碑按新范围重新谈。三件事至少做两件，不然延期只会从一个月变成三个月。
所以排期时不妨反过来检查两件事：开发启动前，核心玩法有没有经过原型验证？美术开工前，规格文档和样张确认有没有完成？两个答案都是“有”，项目大概率能按点走；都是“没有”，排期表写得再漂亮也只是愿望清单。
外包合作的项目，这两个环节更要白纸黑字约定——需求冻结、修改轮次，都是合同该管的事，这个话题在之前那篇游戏外包成本拆解里提过一部分。正在排期、或者已经被延期折磨的团队，欢迎把里程碑计划发给我们看一眼（电话 18616880101），哪些坑，一眼就能指出来。