Ludo Atlas · 团队与规模 · 小团队（3-10 人）¶
团队与规模。定位：3 到 10 人、三条职能线都靠兼岗顶住的团队，用轻流程与固定节奏把一款游戏从立项做到发布。 配套：《制作管理手册》·《独立开发生存手册》·《AI 工作流手册》·《游戏设计手册》。
1. 定位与适用¶
一句话定位：小团队是全员兼岗、轻流程、周迭代的规模段。人数已经超出「一句话就能同步」的范围，又不够拆出每一环的专职人手；流程要恰好多到压住沟通损耗，少到不拖慢开发。
三种规模的对照（同一套口径见《游戏开发全貌》的规模一节）：
| 规模 | 人数 | 工作方式 | 最大风险 |
|---|---|---|---|
| 单人 | 1-2 人 | 没有会议，自己拍板 | 范围失控，进度停滞 |
| 小团队 | 3-10 人 | 全员兼岗，轻流程加周迭代 | 沟通损耗，方向漂移 |
| 工作室 | 10 人以上 | 专职分工，阶段评审 | 成本高，决策慢 |
人数到 3 人上下，程序、美术、设计三条线值得各有人主责；到 6-10 人，「专职制作」开始必要：有一个人（哪怕半职）专门盯范围、进度与风险，而不是谁有空谁管。沟通通道的账也要算清楚：3 个成员两两沟通有 3 条潜在通道，6 人是 15 条，10 人是 45 条；人数翻倍，沟通面翻四倍。流程设计的目标只有一个：让信息走「广播」，而不是走「两两私聊」。
适用信号：
- 程序、美术、设计三条线都已有人负责，缺的是节奏与流程，不是人。
- 项目体量在 6-24 个月、目标是一款能发布的产品。
- 成员部分合作过，或愿意先做一个短项目验证磨合。
三种情形先别用这套打法：互相不熟且对项目期待不同，先磨合再谈长期；内容量明显超过团队产能，先按（《制作管理手册》§3）砍范围再排期；核心玩法还没验证，先做原型，周迭代救不了错误的方向。
2. 核心挑战与对策¶
小团队的协作问题大多能归到五个源头。每条挑战给可执行对策，不给原则口号：
| 挑战 | 典型症状 | 对策 |
|---|---|---|
| 沟通损耗 | 消息越回越多，决策越传越歪 | 单一信息源、异步优先、会议预算（§4.3） |
| 兼岗过载 | 头衔挂了四五个，每件事停在 40% | 主岗加副岗制，副岗有固定时间块 |
| 方向漂移 | 核心玩法反复推翻，范围越做越大 | 体验支柱与范围声明，新增需求一换一 |
| 进度不透明 | 各干各的，临近交付才拼不起来 | 每周可玩构建，里程碑按能玩的版本验收 |
| 单点依赖 | 一个人请假，关键路径停摆 | 关键系统文档化，每条线有第二人能接手 |
- 主岗加副岗：每人一个主岗，占七到八成时间；副岗占一到两成，用于覆盖而非精通，例如程序兼工具链、美术兼界面实现。副岗必须写进周计划并给固定时间块，否则它永远不会发生。
- 一换一：新增需求同步砍掉一个等量项，并写进变更记录。防的是「每周都很努力，范围每周都在涨」。
- 第二人：构建、发布、存档、核心玩法代码这些关键路径，必须有第二个人读过代码、跑通过流程。只有一个人会的模块，在请假和离职面前不堪一击。
3. 工作流与节奏¶
3.1 周迭代循环¶
全团队以周为单位跑同一个循环：
周一立标（每人不超过 3 件）→ 周中随时集成 → 周五出可玩构建 → 周五简报 → 下周一再循环
- 立标时每件事都要有负责人和可验收的完成定义。「打击感调优」不算任务，「把受击硬直从 12 帧调到 8 帧并录屏对比」才算。
- 周五的构建必须能打开、能玩、能展示；构建发不出来就是本周最大的信号，要么砍量，要么承认落后，别用「下周补上」掩盖。简报固定三行：完成了什么、卡在哪、下周计划，发在公开频道。
3.2 任务板¶
看板四列（待办、进行中、待审、完成），用纸或工具都行，纪律比工具重要：
| 规则 | 落法 |
|---|---|
| 任务粒度 | 每张卡不超过 2 天产出，超了就拆 |
| 并行上限 | 每人「进行中」同时不超过 2 张 |
| 卡片要素 | 负责人、完成定义、验收人，三样缺一不开工 |
| 阻塞处理 | 阻塞超过 1 天标红，当日上报，不让卡静默腐烂 |
| 每周整理 | 周五过一遍，拖过两周的卡拆小或砍掉 |
「待审」列不是装饰：美术、关卡、系统的改动至少有一人看过再进完成。小团队没有专职 QA，互看是唯一的质检层；QA 最小做法见（《制作管理手册》§5）。
3.3 里程碑与 Demo 节奏¶
里程碑按「能玩的构建」验收，不按文档或代码进度。五档里程碑（原型、垂直切片、Alpha、Beta、RC）的定义与验收标准见（《制作管理手册》§2.2），小团队再加两条纪律：
- 每个里程碑绑一个可展示版本：节点上必须有外人能在五分钟内上手的构建；做不出来的部分就是下一阶段的风险清单，确认超范围立即走砍功能预案（《制作管理手册》§3）。
- 每 4-6 周往外看一次：给朋友、同行或目标玩家看当周构建加基本包装后的版本，只问两个问题：「哪三秒最想玩下去」「哪里最想关掉」。这类反馈比进度汇报诚实；每个里程碑再补一次 30 分钟复盘，产出三条可执行改进项（《制作管理手册》§9）。
3.4 沟通节律¶
| 周期 | 动作 | 时长预算 |
|---|---|---|
| 每日 | 站会（含文字版）：昨天、今天、阻塞 | 15 分钟以内 |
| 每周 | 周一立标、周五构建与简报 | 各 30 分钟以内 |
| 每月 | 范围声明与风险登记表复核 | 30 分钟 |
| 每里程碑 | 验收逐条勾、复盘 | 60-90 分钟 |
- 站会只答三问，超时即停；需要展开的议题会后单独约人，不绑架全队。
- 每周留一天「无会议日」。整块的开发时间是最稀缺资源，它总是先被会议吃掉。
4. 协作与分工¶
4.1 角色三角与兼岗¶
程序、美术、设计是三条必须有人主责的线，其余职能用兼任与外包补齐；各条线的完整技能盘点见入门区《岗位与技能地图》。
| 职能 | 3-5 人的常见分配 | 6-10 人的常见分配 | 红线 |
|---|---|---|---|
| 程序 | 1 名主程，兼工具与构建 | 玩法、工具或服务端分工 | 构建与发布有第二人 |
| 美术 | 1 名主美，兼界面实现 | 主美加技术美术或外包对接 | 资产规范先于量产 |
| 设计 | 主设计由程序或美术兼任 | 专职设计，可能带关卡 | 数值必须进表 |
| 制作 | 任一成员兼任 | 专职或半职 | 只管范围、进度、风险 |
| 音频 | 外包或素材库 | 外包加兼职音乐人 | 先定格式与体积预算 |
| 测试 | 全员轮值 | 全员轮值加外部试玩 | 每版本固定破坏性测试时段 |
每人最多一个主岗加一个副岗；头衔写进责任表，谁在什么事情上有拍板权，写成一句话贴在文档里。
4.2 Owner 制度¶
- 每个模块设一名 owner：玩法系统、美术方向、关卡池、叙事、构建管线各算一个模块。owner 拍板自己模块内的方案，团队可以评，但决定和责任都在 owner。
- 「大家一起负责」在协作语境里等于没有负责人。任务卡、模块、风险条目都必须落到具体名字。
- owner 不是背锅位：出错先进复盘流程找根因、改流程，对事不对人（《制作管理手册》§9）。
4.3 沟通纪律：文档、单一信息源、异步优先¶
三条规则把沟通损耗压到可承受水平：
- 单一信息源：一个任务板、一个文档区、一个构建分发渠道，每类只有一处。信息有两份就会分叉，分叉三周就没人知道哪份是对的。
- 决策公开：不私聊定案；重大决定写成五行决策记录（背景、选项、决定、后果、日期），放在公开处。私聊里先聊出的结论，事后也补一份公开记录。
-
异步优先：能文字就不语音，能留言就不约实时。打断别人心流的成本，远高于晚两小时回复。「紧急」收窄为两种：发布受阻，或者今天不处理就连累别人。
-
只写四类必备文档：范围声明、决策记录、资产规范、构建说明。其余文档按「会被读才算数」取舍，不生产没人读的文档。
- 会议纪律：议题提前半天发、参会人等于必要人、结束前留五行纪要（决议、行动项、负责人）。
4.4 远程协作¶
- 重叠时段：远程成员之间保证每天 4 小时左右的重叠窗口，用于站会、评审与答疑；其余时间不要求在线。
- 记录代替记忆：同步会议默认留记录，关键结论当天落文档；缺席的人读记录，不重开会。
- 分区安排：独立性高的模块（美术资产、外包对接、文案）放在少重叠的时段；需要高频碰撞的（手感调优、系统联调）排进重叠窗口。垂直切片评审、Demo 定稿这类节点建议开摄像头，仪式感会让讨论更认真。
4.5 外包管理：怎么切、怎么验收¶
切包三原则：
- 切边界清晰、验收可量化的包：美术资产、音频、本地化、部分测试、营销素材。
- 不切迭代频率高的包：核心玩法手感、数值、核心关卡设计，它们的返工速度比外包的沟通速度快。
- 每个包只有一名内部对接人。多个接口对同一个外包方，是扯皮的开始。
流程固定五步，细节见（《制作管理手册》§4.3）：
需求包（参考图、规格表、验收标准、交付格式）→ 试单（小批量验证风格与效率）→ 里程碑合同（分批付款）→ 分批验收（草稿到终稿）→ 源文件与授权归档
- 验收标准必须可量化：尺寸、面数、风格对照图、动效时长、命名与图层规范。不接受「感觉不对」式的模糊往返；反馈攒成一份清单一次发出，不碎片化轰炸。
- 付款绑定验收节点，常见三期：预付款、草稿通过、终稿交付；源文件与商用授权每批验收时归档，攒到项目收尾再要，常见结果是找不到文件或找不到人。合同、版权与竞业条款的核对见《法务、专利与竞争手册》。
5. 工具与技术栈建议¶
原则：工具数量要随团队规模做减法，每类只选一个，能合并就合并。
| 类别 | 3-5 人 | 6-10 人 | 备注 |
|---|---|---|---|
| 任务板 | Trello、Codecks、飞书表格 | HacknPlan、Codecks | 一张板、四列够用 |
| 文档 | 仓库 docs、语雀、Notion | 加决策记录区 | 单一信息源落地处 |
| 沟通 | 一个群聊加一个语音频道 | 按职能分少量频道 | 不让频道数量失控 |
| 版本控制 | Git 加 LFS | 同上，资产走大文件方案 | 二进制资产用 LFS |
| 构建 | 每周手工打包 | 自动构建加内部分发 | 每周超过 2 小时就该自动化 |
| 资产 | 共享盘加命名规范 | 加命名校验脚本 | 规范先行 |
- 构建自动化优先级最高：手工打包是小团队最大的隐性成本，一旦每周超过 2 小时，就投一天把它自动化。别在第一版上全套 CI/CD、多分支策略与看板自动化，工具用不满就是纯维护开销；流程从最小集开始，痛点出现再加一项（节奏模板见（《制作管理手册》§10））。
- AI 工具按「编制放大器」用：编码代理、资产初稿、文档整理能明显顶掉一部分工时，但产出必须有人验收，红线与流程见《AI 工作流手册》。
6. 常见坑¶
- 会议膨胀：站会拖成周会，全队被议题绑架。站会限 15 分钟只答三问；要展开的议题转小范围专题，每周留一天无会议日。
- 方向漂移：每周都有「好点子」进 backlog，三个月后核心玩法面目全非。锁定体验支柱与范围声明，新增一换一，变更留记录。
- 任务无 owner：「谁有空谁看一眼」的任务永远没人看。卡、模块、风险都挂具体名字，没有 owner 不许开工。
- 招人过早：为「以后需要」提前招人，新人没有三个月内的明确任务，现金流先被掏空。只在瓶颈连续出现 2-3 个月时招，招前先回答「他未来三个月做什么」。
- 股权与分成只做口头约定：比例、退出机制、贡献认定全凭记忆，一旦有收入或有人离开必爆雷。组队第一周就把分配写成一页纸，条款问题找专业人士。
- 集成太晚：各自开分支做一个月的功能，合并时冲突到怀疑人生。小团队用主干开发，每天至少合并一次，每周必须有可玩构建。
- 兼岗叠得太满：一人挂四五个头衔，每件事停在 40% 完成度。每人一主岗一副岗，副岗也要有固定时间块。
- 流程过重：五个人照搬大厂全套评审与仪式，流程本身成了工作量。最小集起步（周立标、周构建、简报、决策记录），只在真实痛点出现时加一项。
延伸阅读¶
- 《制作管理手册》：立项包、估算排期、里程碑、范围控制与外包流程的总流程，本文多处直接引用其章节。
- 《独立开发生存手册》：现金流、节奏管理与防弃坑策略，小团队与单人的底层方法相同。
- 《AI 工作流手册》：用 AI 顶编制的具体流程、检查点与红线。
- 《游戏设计手册》：设计评审、数值表与玩法验证方法，主设计必备。
- 《避坑大全》：项目管理与团队协作章节的高频坑速查，里程碑复盘时对照过一遍。
- 《案例研究集》：按规模筛选公开复盘；组队与排期之前，先读同规模的失败案例。