企业官网建设流程全解析

简介：这份《游戏项目管理》PDF文档面向游戏研发团队管理者、项目经理及有志于进入游戏行业的从业者，梳理项目管理在游戏开发场景中的落地框架。内容从项目管理的基本定义切入，系统讲解规划、组织、人事、领导与控制五大过程，并延伸到项目经理的职责定位、组织架构应以结果为导向的设计原则，以及项目经理与制作人在权责划分上的差异。文档还附有实用的检讨清单，逐项辨析制作人、执行制作人、监制、企划、游戏设计师、编剧、角色设计师、2D/3D插画师等岗位的职务分工，并涉及甘特图、进度表等常用工具与项目评价标准。资源为单个PDF文件，压缩包约20KB，轻量易读，适合作为团队内部分工梳理与流程规范建设的参考。目前已有388人学习下载。

1. 别急着排甘特图：《游戏项目管理.pdf》里最扎眼的是组织架构检讨

项目做到第八个月，例会上一句"这个改动谁签字"把所有人问住了——制作人认为自己管方向，项目经理认为自己管流程，监制认为自己只管这周的活，结果三份周报对应三套进度。这份《游戏项目管理.pdf》开头那段"项目管理检讨"几乎就是这场景的病历：公司与项目应有不同架构却混着用、各部经理与总监的职务定位含混、项目经理与制作人的权责没划开，甚至连"项目算不算已经成立"都没有界定标准。它真正值钱的地方不在附录里那串规划、组织、人事、领导、控制的定义，而在于把游戏行业特有的头衔——制作人、执行制作人、监制、企划、游戏设计师、编剧、角色设计师——和草案、仕样书、α版、β版、Master 这套收敛流程摊在同一份文档里。适合带着五到二十人团队、正准备从"作坊"切到"流水线"的人读；如果你同时被外包与发行方两头追进度表，这份文档能把你缺的那几块补上。

2. 权责错位怎么修：用 RACI 把项目经理、制作人与监制的边界写死

头衔不清不是命名问题，是决策问题。同一件事有两个人都觉得"我能拍板"，最后的结果通常是谁都不拍，工期在等签字的过程中一点点漏掉。先把每个头衔的实际职责摆平，再用一张矩阵把签字权固定下来，最后才是照着结果去搭组织。

2.1 五个头衔到底各管什么

中文游戏圈常把这几个叫法混用，尤其是"制作人"和"项目经理"，很多团队干脆一个人兼。混用本身不是错，错在兼了之后没人说得清哪些决定必须由谁做。下面这张表按文档里的职责描述整理，重点看"关键决策权"一列。

分界线可以粗暴记成三句话：制作人回答"做什么、值不值得做"，项目经理回答"怎么按时做出来、现在卡在哪"，监制回答"这周谁做哪件活"。文档里那句"游戏制作人并不能随时与游戏研发在一起，所以执行面由执行制作人来负责"就是这个意思——制作人要面对公司与外部，执行面必须有人常驻现场。

2.2 一张 RACI 矩阵把签字权落定

RACI 的四个字母分别对应执行（R）、最终负责（A）、被咨询（C）、被告知（I）。规则只有一条要紧：每一行交付物必须有且仅有一个 A。有两个 A 等于没有 A，一个 A 都没有则意味着这事没人对结果负责。下面是按游戏项目常见节点填的示例。

小团队常见做法是制作人兼 A、项目经理兼 R，这没问题，但名字要写死在同一格里，不能写"看情况由谁定"。矩阵本身是文档，改起来容易，所以最好让机器帮你守规则。

2.3 以结果为导向搭架构，而不是按人头搭

文档里有一段讲得很直白：许多公司把组织营建在员工身上，而不是先决定要达成的结果，再找合适的人占住那些位置。小公司没有真正的组织架构，先把现有人员分配去做所有工作，不用多久又招一批人来分摊，架构始终是补出来的。可执行的做法分四步：先列出这一阶段必须交付的结果；给每个结果指定唯一负责人；按结果把岗位画出来；最后才往岗位里填人。落到工具上，把矩阵存成 CSV 并用脚本校验，比每次开会确认要省事得多。

# raci_check.py # 校验 RACI 矩阵：每个交付物必须有且仅有一个 A，且至少一个 R # 输入 CSV 第一列为交付物，其余列为角色，格值为 R/A/C/I 或留空 import csv import sys LIMIT = {"A": 1} # A 只能出现一次 AT_LEAST = {"R": 1} # 至少要有一个执行人 def check(path): problems = [] with open(path, newline="", encoding="utf-8") as f: rows = [r for r in csv.reader(f) if any(c.strip() for c in r)] for row in rows[1:]: deliverable, marks = row[0], [m.strip().upper() for m in row[1:]] counts = {k: marks.count(k) for k in "ARCI"} for k, limit in LIMIT.items(): if counts[k] != limit: problems.append(f"{deliverable}: {k} 数量为 {counts[k]}，应为 {limit}") for k, least in AT_LEAST.items(): if counts[k] < least: problems.append(f"{deliverable}: 缺少 {k}") for p in problems: print("[FAIL]", p) print("矩阵校验通过" if not problems else f"共 {len(problems)} 处问题") return 1 if problems else 0 if __name__ == "__main__": sys.exit(check(sys.argv[1] if len(sys.argv) > 1 else "raci.csv"))

脚本读的是格值而不是角色名，所以换了角色列也不用改代码。LIMIT和AT_LEAST两个字典是唯一需要动的地方，比如某个交付物确实要两个 A，把 limit 改成 2 就行，改完再跑一遍。退出码为 1 表示矩阵不合格，可以直接挂进 CI 或 git pre-commit 钩子，矩阵被改坏的时候构建会红，比等人发现要快。

调用方式很简单：

python raci_check.py raci.csv

提示：同一个人兼任多个角色时，仍然要把名字写进对应单元格，不要用"看情况"糊过去，否则这张矩阵对现场没有任何约束力。

3. 草案与仕样书：把「好玩在哪」和「怎么实现」拆成两份文档

文档里有个容易被忽略的对照：日文语境中的"企划书"约等于我们说的草案，"仕样书"才是我们说的企划书或规格书。两份东西的读者、粒度、变更成本完全不同，混成一份，后期的返工量会非常可观。

3.1 草案的使命只是传达意念

草案没有固定格式，少的时候两三页 A4，多的时候连参考资料五十几页，不同公司、不同企划、不同项目都能不一样。它只回答两个问题："这是个什么样的游戏""什么好玩、哪里好玩"。除了核心玩法，草案还要带上对应平台、预定发行时间、适合的年龄层、主要画面草图（Rough Continuity），必要时附参考资料，写到这个程度就可以拿去评审了。

常见误用是把冗长的故事剧本和详细角色设定塞进草案。这些内容属于仕样书，提前写会拖慢筛选节奏，还会让评审者抓不到重点。稍具规模的制作公司随时压着一百份以上未商品化的草案，来源包括内部企划和外部募集——草案是筛选单元，不是开工文件，只有通过层层筛选才进入仕样书阶段。

3.2 仕样书要写到可执行粒度

仕样书是让企划把想法传达给程序、图形、音乐等制作成员的文件，不能只写"知道游戏的概略"。从开始画面到结束画面、画面中任何角落的表现设定、分数计算方式、角色的动作，都要具体写清楚。RPG 这类剧情分支庞大的项目，页数用"几公分厚""几个纸箱"来计量反而更贴切。

写法本身很自由，按画面单位写或按登场角色写都行，唯一标准是制作成员看完知道自己要做什么。下面的骨架是我一般会用的最小结构，重点是修订记录放在最前面。

# 仕样书 SPC-014 关卡战斗系统 ## 0. 修订记录 | 版本 | 日期 | 修改人 | 变更点 | 影响范围 | ## 1. 系统目标（一句话说清这个系统解决什么） ## 2. 输入与输出 - 输入：玩家操作、当前关卡配置 ID - 输出：结算结果、分数、掉落表 ## 3. 数值规则 - 伤害 = 攻击力 * 系数 - 防御力（系数表见附录 A） ## 4. 画面与表现 - 命中特效：第 0 帧起播，持续 12 帧，取消条件为玩家受击 ## 5. 验收用例 - 用例 ID / 前置条件 / 操作步骤 / 预期结果 / 负责人员

修订记录里的"影响范围"一栏是关键，它决定要不要重排工期；验收用例一栏是给 QA 和主程看的，没有用例的条目不允许冻结。这两栏空着的仕样书，后期一定会变成口头需求。

3.3 用 PROTOTYPE 证伪「好不好玩」

程序前期不铺细节，只搭系统骨干：主角动作、画面显示系统。用绘画打比方，就是先准备纸、画具和颜料，把轮廓勾出来。必要时先做工具和编辑器，地图编辑器、动作编辑器先做好，后期编辑动作和地图的效率差别会非常明显，像盖房子之前先把锯子做好。

这一步的目的是回答两个问题："企划脑子里的东西真能实现吗""真会好玩吗"。原型有结论之后才决定是否朝完整版推进，砍掉某个核心循环也通常发生在这一步。

原型代码通常复用率不高，所以我一般单独开分支，不往正式线上合：

# 原型独立分支，避免探索期的临时逻辑污染主线 git checkout -b proto/battle-core-0712 main git push -u origin proto/battle-core-0712

原型通过后，由主程挑必要模块重写进正式分支，而不是直接 merge。原型结论必须回写到草案或仕样书里，否则半年后没人记得当初为什么砍掉某个系统。

4. 内存预算、α/β/Master：把收敛变成可检查的数字

项目做到中期，麻烦会变得具体：内存不够、创意被判定"不可能"、抽象需求在团队间来回传递。这几类问题的共同点是——不解决也能往前推，但每推一天，后期代价都在涨。把它们变成数字和门槛，才有讨论空间。

4.1 开工前先分内存，超了要有仲裁路径

文档里描述得很典型：计划一开始就分配好图形多少兆、主程序多少兆、音乐多少兆，随着制作推进总有人超。原因可能是企划阶段估算错误、开发能力不足，也可能是某个组确实需要更大容量来表现效果。这时候制作人或监制必须明确判断：还有没有余量可以分配？削减哪个部分？是否变更规格？

这张表手工维护很容易看漏，用脚本每周跑一次更稳：

# budget_check.py # 读取内存预算 CSV，输出超标模块与需要仲裁的条目 # CSV 列：module,budget_mb,used_mb,owner import csv, sys TOLERANCE = 0.05 # 允许超出 5%，超过即进入仲裁流程 def check(path): rows = [] with open(path, newline="", encoding="utf-8") as f: for r in csv.DictReader(f): budget, used = float(r["budget_mb"]), float(r["used_mb"]) rows.append((r["module"], budget, used, used - budget, (used - budget) / budget, r["owner"])) rows.sort(key=lambda x: -x[4]) total_budget = sum(r[1] for r in rows) total_used = sum(r[2] for r in rows) print(f"总量：{total_used:.0f}MB / {total_budget:.0f}MB") for name, b, u, over, ratio, owner in rows: if ratio > TOLERANCE: print(f"[仲裁] {name}: 预算 {b:.0f} 实际 {u:.0f} 超出 {over:.0f}MB " f"({ratio*100:.1f}%) 责任人 {owner}") return 0 if __name__ == "__main__": sys.exit(check(sys.argv[1] if len(sys.argv) > 1 else "budget.csv"))

TOLERANCE是容忍度而不是硬上限，5% 意味着小幅波动不进会，超过就必须有人做取舍。总额那一行是给制作人看的第一眼数据：总量有余量，仲裁就是内部调配；总量都满了，就只能改规格。

4.2 α、β、Master 的准入标准

三个阶段的门槛必须提前说清，临到发布才定标准，一定会吵。

α 阶段最容易踩的坑是"看得到树却看不到森林"：各部门分工做出来的东西单看没问题，拼起来不像一个游戏，α 的工作就是把一棵棵树修成一片森林。另一个坑是 α 之后还在加功能——内容没在 α 之前全部进来，β 阶段就会变成边加功能边 Debug，回归测试永远追不上新增。

4.3 用 SQL 盯 Debug 收敛曲线

Debug 是最后也是最大的一项工程，覆盖范围从游戏讯息里一个文字错误到会导致当机的重大问题。判断能不能按计划进 Master，看的是净增而非总量。

-- 按周统计缺陷新增、关闭与净增，判断能否按期进入 Master SELECT date_trunc('week', created_at) AS week, COUNT(*) FILTER (WHERE created_at >= date_trunc('week', created_at)) AS opened, COUNT(*) FILTER (WHERE closed_at IS NOT NULL) AS closed, COUNT(*) FILTER (WHERE closed_at IS NULL AND severity = 'blocker') AS open_blocker, COUNT(*) FILTER (WHERE closed_at IS NULL AND severity IN ('major','minor')) AS open_normal FROM issues WHERE build_stage IN ('alpha','beta') -- 只统计 α 之后的缺陷 AND created_at >= DATE '2024-01-01' GROUP BY 1 ORDER BY 1;

opened与closed的差就是净增。判读规则很直接：连续两周净增为正、且open_blocker没有下降趋势，当前排期就不可能进 Master，制作人要在范围、时间、人力里砍掉一项。build_stage这个字段是关键，它把 α 之前的技术债和 α 之后的收敛缺陷分开统计，否则早期的历史遗留会把曲线彻底污染，看着吓人却没有参考价值。

5. 把「不可能」变成可排期项：冲突升级与版本冻结的检查脚本

制作现场反复出现的两句台词是"这是可以办到的吧"和"不可能，我做不出来"。争论靠嗓门没有产出，靠流程才有。做法是把争议降级成一条时间盒验证任务：限时两天，产只出两个结论——可行或不可行，附带实测数据，比如帧率、内存占用、预估工期。结论回写仕样书并走变更单，变更单里必须写影响范围，否则工期重排没有依据。

抽象需求也是同一类问题。"再可爱一点""我要一种无形的感觉""反应要有速度感"这类说法，发言者的想法和听者的理解天然存在偏差。落地时把它们翻译成可验收描述：

到了版本冻结这一步，检查项应该固定下来并自动化，而不是每次靠人回忆遗漏了什么。

#!/usr/bin/env bash # freeze_check.sh 版本冻结前检查，任一失败即不冻结 set -euo pipefail echo "== 1. 构建可重复性 ==" git diff --quiet || { echo "工作区存在未提交改动"; exit 1; } echo "== 2. 阻塞级缺陷清零 ==" blocker=$(grep -c ",blocker,open," issues.csv || true) [ "$blocker" -eq 0 ] || { echo "仍有 $blocker 个阻塞级缺陷"; exit 1; } echo "== 3. 资源包版本与构建配置一致 ==" grep -q "^assets_ver=$(cat ASSETS_VERSION)" build/config.ini \ || { echo "资源包版本与构建配置不一致"; exit 1; } echo "== 4. 范围冻结 ==" grep -q "state=accepted" changes.csv && { echo "存在未评审的变更单"; exit 1; } echo "冻结检查通过"

set -euo pipefail保证中间任一步失败立即中断，不会出现"检查到一半还打印通过"的假象。四项检查分别对应可复现构建、缺陷门槛、资源版本和范围冻结，退出码非 0 时直接拒绝合并到 release 分支——冻结就从一句口头承诺，变成了一条会失败的构建。

本文还有配套的精品资源，点击获取