两人团队怎么运营一个目录

Hage Game 是一个两人项目。一个写代码;另一个写散文、设计页面模板、编辑一切。没有项目经理,没有社区团队,没有 QA,没有市场。我们这样做了 25 款游戏和 30 篇双语文章,这个结构管用 —— 但它以特定方式管用,这些方式值得描述,因为"两人团队就是更小更便宜的、但其他方面和大团队一样"的假设是错的。

严格的分工

我们做的第一个决定 —— 也是我们最严格坚持的 —— 是其中一人只做代码,另一人做其他一切。没有重叠。技术合伙人从不编辑文章;编辑合伙人从不打开代码编辑器。我们考虑过两人都做两边的混合模型,因为一个原因否决了它:上下文切换的代价远远高于专业化的代价。

游戏的代码和游戏的评测是不同种类的工作,调动大脑不同部分。在一天里在它们之间切换,产出比集中几天做一种都低质量的两边工作。通过永久分工,我们确保每个人每天都在自己的主模式里运作,没有切换税。

这需要信任。编辑合伙人必须信任代码在做它声称在做的事;技术合伙人必须信任评测准确描述了游戏。我们不互相复查工作,因为做不到 —— 我们真的没时间,即使有,复查的动作本身就是我们试图避免的上下文切换。我们绝对依赖彼此的判断。做不到这点的两个人不该做两人工作室。

我们刻意不做的

两人团队最重要的技能是说不。我们对以下说过不:建后端、建用户账号、建社交功能、建排行榜、建推送通知、支持超过两种语言、支持超过现代浏览器基线、在社交媒体上推广游戏、投广告、接受外部开发者投稿、有评论区、有论坛、有 Discord 服务器、有邮件订阅。

每一项都是更大团队会做的事。每一项单独看都合理。没有一项对两个人合理。我们作为项目活下来的方式是对"我们是什么"非常严格:一个发布原创浏览器游戏和写作的小型编辑部。其他一切,我们明确选择不做。

复利的小决定

两人的另一个模型是让每件工作产生下一件工作。我们不是先做游戏再写关于它们的文章;我们一起做游戏和文章,在同一周,因为每一件让另一件更好。写评测迫使代码评测者清楚地想游戏实际是什么,这常常浮出代码的小修复。写代码迫使作者投入实际机制,这产生更准确的评测。

这不是"敏捷开发"或任何其他有名的方法论。这是两人团队在两人物理上(或虚拟上)能喊到彼此、决定小到五分钟就能做的情况下,自然的工作方式。大团队的开销来自协调工作互相依赖的人;两个人通过对话协调。

关于节奏我们学到的

两人团队的节奏不规律。我们不稳定地一周一款游戏。我们五天爆出三款游戏,然后停一周写文章,然后再爆一波游戏。试图强制稳定的节奏会通过强制我们还没赚到的上下文切换让我们变慢。让节奏呼吸 —— 接受高产爆发由安静的延伸分开 —— 是我们找到的唯一可持续节奏。

这个教训超出游戏范围。多数小团队过度工程化自己的流程,试图看起来像大团队的可预测。两个人的诚实答案是少做流程多做工作,信任爆发会在项目内平均开来。

发布 · 2026 年 5 月 14 日 · 撰写并署名:Bill