2024 年 6 月，高考结束后，我们开始做一款二次元卡牌肉鸽游戏，玩法接近《杀戮尖塔》。核心团队只有三个人，其他工作找外包帮忙。我是主程序。项目没有单独的制作人，方向、功能和发售安排都由我们三个人一起决定，实际上三个人都承担了制作人的工作。

当时定的目标是开发一年，2025 年 6 月发售，销量做到 5 万份。实际发售时间是 2026 年 6 月，整整晚了一年。项目经历了大约一年半的集中开发，前后拖了两年。

销量倒是远超预期，照现在的情况看，全年可能超过 20 万份。如果只看这个数字，这个项目无疑是成功的。但游戏上线以后，我回想更多的还是开发过程中那些失控的部分。我们最后确实把游戏做出来了，只是这套做法很难再来一次。

最矛盾的是，真正帮助游戏获得销量的，基本都是项目一开始就定下来的方向和内容。后面花了很多时间增加的功能，大多没有带来直接的销量增长。联机是一个例外：它对销量的帮助不算特别大，却明显增加了日活，也帮助了社区活跃和玩家之间的传播。

一年是怎么变成两年的

最初定在 2025 年 6 月发售，没做完，推到 12 月。12 月还是没做完，后来又陆续定过 2026 年 3 月、5 月和 6 月。

每次延期时，我们都觉得只剩最后一点工作：补齐美术资源，整合一下，再修一轮 Bug。可真正开始收尾后，美术交付总会比预想中更久，已经完成的内容也经常需要调整。与此同时，新的需求还在往项目里加，美术的待办没有减少，反而越积越多。

我们平时会分配任务，但很少认真维护排期。“这个过几天能交”“那个明后天差不多”，说完基本就算安排过了。至于什么状态才算做完、如果延期会卡住谁，通常没有写清楚。等到关键节点一对时间，才发现已经不得不延期了。

没做过的东西，我们也敢直接估半年

我们估工期时一直很乐观，尤其是面对从来没有做过的内容。

剧情模式是最典型的例子。我们三个人之前都没有做过相关内容，不知道剧本、演出、资源和程序最后会怎样配合，也没有完成过一个可以参考的流程。但每次讨论到它，我们都觉得半年应该能做出来。

这个“半年”不是拆解任务后算出来的，也没有原型或者过去的经验支撑。它更像是一个听上去足够宽裕的时间。因为还有半年，我们觉得可以以后再开始；等时间真的过去一部分，剩下的工作仍然没有变得更清楚。

对熟悉的工作，我们至少还能参考过去的速度。对完全陌生的内容，越缺少信息，估计反而越容易乐观。剧情模式最后没有进入包体，却长期占据着计划，影响了我们对剩余工期的判断。

每个人都有一票延期权，却没有一票提前权

我们三个人分管不同的工作。任何一块没有达到上线标准，整个项目就不能发售。从这个意义上说，三个人都有“一票延期权”。这不是我们正式定下的规则，而是分工和依赖关系带来的结果。

美术这一块尤其明显。关键资源没有完成，或者完成后发现效果不对，需要返工，游戏就只能继续等。程序和其他部分做得再早，也没办法代替缺失的美术内容。

反过来，我们没有与之对等的“一票提前权”。一个成员提前两个月做完自己的工作，并不能让项目提前两个月发售。发售日期取决于最后一个没有完成的关键环节，而不是三个人的平均进度。

程序端正好说明了这种不对称。程序很少因为实现速度卡住项目，很多需求很快就能做出来，甚至有不少冗余产能。但这些余量没有让发售日期提前，反而给了我们继续加设计的空间。

程序做得越快，我们越容易觉得“这个也能加”。功能实现之后，又会产生新的美术资源、界面、测试和平衡需求。程序端的高效率最后扩大了项目范围，让原本已经吃紧的美术环节承担更多工作。

三个人天天聊，信息还是会错位

我以前觉得，小团队不需要太正式的协作方式。三个人都很熟，有问题直接说，应该比开会、写文档更省时间。后来发生的一些事情证明，这种省事只是把成本推迟了。

有一次，需求没有讲清楚，美术同学花了很多时间做一批资源，最后程序端根本用不上。再往前追一步，那个功能从设计上就不该进入制作。美术本来就是排期最紧的环节，我们却让有限的时间消耗在了错误的需求上。

美术交付也经常比计划晚。原来说几天能完成的内容，后来拖了很久，依赖它的人却还在按照原时间安排工作。消息传到时，已经没有多少调整空间了。项目几次延期，最直接的原因就在这里。

口头聊过不等于达成了一致。有时大家记住的是不同版本，有时需求改了，只通知到其中一个人。就算团队只有三个人，也需要一套足够完整的信息同步和协作机制。

这套机制不一定复杂，但信息不能缺。我们可以通过飞书或者类似的协作软件建立一块统一的任务板，把异步协作真正做起来。每个人现在在做什么、接下来准备做什么、任务由谁负责、各个环节推进到哪里，都应该随时能查到。任务的预计交付时间、依赖关系和完成条件也要写清楚。

成员更新自己的任务状态后，其他人不需要专门开会或者追着询问，也能知道项目发生了什么。需求和决策有变化，就直接更新到对应任务和记录里。语音里说过、群里提过，不能代替最终结论。

过去很多信息只存在于某个人的脑子里，时间一长，连本人都不一定记得当时为什么这样决定。人脑可以用来思考，不能拿来充当项目管理系统。

后来加进去的功能，收益和代价并不对等

这个项目最初的方向很清楚：角色要有吸引力，卡牌肉鸽的战斗要能让人反复玩。最后真正帮助销量的，也是这些最早确定的内容。开发到中后期，我们又加入了联机、剧情和卡牌自定义。它们各自带来的结果并不一样。

联机是首发前最麻烦的一项。系统不稳定，留下了大量 Bug，程序端在最后阶段一直忙着救火。但它不能简单算作帮倒忙。联机给游戏带来了特别多的日活，让我们在同类产品中更容易被记住，也让社区讨论和玩家之间的裂变传播有了更好的基础。它没有明显拉高销量，却产生了真实的社区价值。

剧情模式则停在了准备阶段，至今没有真正做起来，也没有放进安装包。它没有给销量带来任何正向帮助，反而留下了一批以后还要处理的设计和技术债。

卡牌自定义主要是我在做。我当时很在意它够不够灵活，结构能不能支持更多玩法，为此投入了不少时间。上线后再看，玩家能感受到的变化很小。这是一个挺典型的程序员陷阱：实现过程很有意思，不代表它对产品同样重要。

这些功能被提出时，我们讨论最多的是能不能做、做出来好不好玩。程序开发效率很高，于是“能不能做”几乎总能得到肯定答案。可代码完成以后，还要补资源、界面和测试，后面每次更新也得继续维护。很多冗余设计正是这样被快速实现，又在其他环节变成了新的工作。

回头看这份投入产出很不对称。最初的角色定位和核心玩法撑起了销量；联机付出了稳定性和开发时间的代价，换来了日活和社区传播；其他一些新增内容则主要留下返工和技术债。我们当时没有先说清楚每个功能到底要改善什么，也就很难判断它的收益是否值得成本。

跟玩家说过，也可以砍

剧情模式迟迟没有被砍掉，一个重要原因是我们之前向玩家透露过这个计划。既然说过要做，我们就总觉得不能反悔，担心取消以后会让玩家失望。于是它虽然一直没有真正开始制作，却长期留在计划里。

等到游戏发售，我们才发现很少有玩家在意剧情模式有没有随首发上线。我们把自己的承诺想得太重，也把玩家对这个功能的期待想得太高。说得直接一点，这只是我们的自作多情。

已经提出的功能仍然应该有退出计划的空间。即使向玩家许诺过，发现它的收益太低或者成本失控时，也要有砍掉的魄力。越早决定，浪费的制作时间越少，需要向玩家解释的范围也越小。一直拖着不处理，才会让一句早期承诺变成越来越重的负担。

我们都没有及时踩下刹车

我是主程序，很容易先从实现角度考虑问题。遇到新需求，我会想架构怎么搭、接口怎么留、能不能做得更通用。程序端实现得快，也让我误以为项目还有余量。实际上，程序有余量，不等于整个团队都有余量。

不过，功能是否进入版本并不是我一个人决定的。项目相关的决策一直由三名核心成员共同讨论，我们既做各自专业内的工作，也一起负责方向和版本取舍。

从任务交付上看，美术是延期的主要瓶颈，这一点需要说清楚。但在共同决策时，我们没有按照美术的实际产能控制版本规模，也没有把程序端的余量用在正确的地方。新增需求有时由我提出，有时来自另外两名成员，最后都是三个人一起接受。程序很快做出了更多系统，美术和后续环节则背上了更多工作。

我们缺少的并不是提出新想法的能力，而是在合适的时候停止。功能一旦决定做，就很少再被重新评估。等到程序、资源和其他系统已经缠在一起，再想删除当然很难。很多决定如果能早两个月做，成本都会小得多。

下一作要换一种做法

这次的销量让我们有机会继续做下一款游戏。复盘这些问题，最终也是为了下一次立项时，不再重复同样的过程。

下一作首先要把核心卖点和首发范围说清楚，也要保护立项时已经确定的方向。三个人都同意一个新功能，并不足以说明它值得做。它还要证明自己能加强核心体验，并且比被它挤掉的工作更重要。

进入计划也不等于必须做到底。开发过程中发现价值不足、成本超出预期，就应该重新判断是否保留。对外透露过的功能也不例外。与其拖到最后交付一个价值不高的功能，不如尽早取消，把变化和原因向玩家说清楚。

下一作从立项开始就要建立统一的任务板和决策记录。三个人各自维护正在进行和即将开始的工作，任务板展示负责人、进度、依赖关系和交付时间。平时通过飞书等工具异步更新，确实需要共同讨论的问题再开会处理，会后的结论立即写回任务板。只要任务状态还散落在聊天记录和个人记忆里，我们就无法准确判断项目到底做到哪一步。

程序仍然可以提前验证各种想法，但原型能跑不代表它应该进入正式制作。验证的目的应该是尽早淘汰不合适的设计，而不是因为已经写出代码，就顺势把它塞进游戏。

对团队没有做过的内容，也不能再凭感觉直接给出半年、一年这样的完整工期。先做出最小流程，确认需要哪些资源和协作，再把剩下的工作拆开估算。连任务都说不清楚时，发售日期也不可能估得准。

排期也不能再按照程序的实现速度来估算。我们需要先看最紧张的环节能完成多少，再决定整款游戏做多大。中途想加入新需求，就同时拿掉一项原计划，而不是继续往上叠。发现某个环节跟不上时，也应该尽早缩小范围。

三个人的“一票延期权”在下一作里仍然会存在。只要其中一块没有做好，项目就不能发售。但我们至少可以更早把各自的进度放到一起看，不再因为某一个环节做得快，就误以为整个项目都还有余量。

下一次决定发售日期时，依据应该是三个人共同完成了多少，还有多少内容没有达到上线标准。不能再凭“应该快做完了”的感觉，先定一个日期，再靠延期追赶计划。