队伍成长手册

备注

最后更新：2025年9月7日

管理学大师彼得·德鲁克说，任何组织的首要任务都是回答“我们的事业是什么？”。对于Refactor，我们的事业是“创造两类客户”：

  1. 为“玩家”创造价值： 做出能给他们带来完美的情感体验的游戏。

  2. 为“成员”（也就是你）创造价值： 帮助你在这里收获实战经验、闪光的作品集，以及专业素养。

文化

  1. 坦诚

    我们相信，坦诚的、建设性的批评是让作品变得伟大的唯一途径（《创新公司：皮克斯的启示》的“智囊团”文化），在这里：

    • 我们批评“作品”，而非“作者”。 所有反馈都是为了让游戏更好，与个人能力无关。

    • 我们鼓励暴露问题。 遇到困难时，要认识到自己“不知道”，无需觉得丢人，因为这是团队介入的最佳时机（换句话说，也是帮助团队降低成本的最佳时机）。

  2. 拥抱“丑陋的婴儿”

    同样，根据《创新公司：皮克斯的启示》的“保护早期创意”，我们都应该认为：所有伟大的创意，在诞生之初都是“丑陋”的。 我们鼓励各种原型和试错，因为今天的“烂主意”，可能就是明天“神作”的起点。失败只是我们为学习支付的成本。

  3. 驱动力

    我们相信，真正的驱动力发自内心。因此，我们致力于创造一个让你能感受到以下三点的环境：

    • 自主： 你将有权主动认领你感兴趣的任务。

    • 精通： 队伍有权通过Code Review、技术分享和分配有挑战性的任务，让你能够清晰地感受到自己的飞速成长。

    • 目标： 你所做的每一项工作，都是我们共同事业的一部分。

“我们如何实践‘坦诚’？主要通过Scrum（见下文）中的‘每日站会’暴露问题，以及‘冲刺回顾会’来进行坦诚的团队复盘等。”

“我们如何实践‘拥抱丑陋的婴儿’？通过每个‘Sprint’(见下文)快速迭代出可玩的原型等”

队长

一、从“我”到“我们”

成为队长，意味着一次深刻的思维转变，意味着你必须从“最大贡献者”->“团队倍增器”。你的成功不再由你个人写了多少行代码、画了多少张图来衡量，而是你所带领的整个团队的产出总和。一个开发者最大的成就，是交付一个伟大的产品；而一个领导者最大的成就，是打造一个能持续交付伟大产品的团队。

二、职责

  1. 设定目标：

    你的职责是带领团队，通过“目标管理法(MBO)”设定清晰、有挑战、且所有人认同的项目总目标。目标管理法：它的核心思想就是：用目标来管理，而不是用监督来管理。

    • 具体化目标： 目标必须是清晰、可衡量的，而不是模糊的口号。 - 坏例子：“我们要做一款更好玩的游戏。” - 好例子：“我们要在这个月内，完成一个包含[A、B、C]三个核心玩法的游戏原型。”

    • 参与决策： 目标不是由队长单方面拍板决定的，而是由团队成员共同讨论、协商出来的。

    • Ddl： 每一个目标都必须有一个明确的完成时间。

  2. 组织工作： 你的职责是将宏大的目标，拆解为每个“冲刺”（见下文Scrum）中可执行的任务。

三、模式

Scrum：

  • 每日站会： 在群里花5分钟时间快速同步一下：“昨天做了什么，今天打算做什么，遇到了什么困难”。

  • 我们的开发以 两周 为一个冲刺周期：每两周开会总结并评估进度，确保不会像无头苍蝇一样乱飞。

维护单一信息源，队长的职责之一，是建立并维护一份清晰、实时更新的GDD，确保团队所有人都在为同一个目标工作。

四、反模式

  1. 首席开发者陷阱：

    警惕：将所有有趣、核心的工作留给自己，把重复、枯燥的任务分给别人。这会剥夺成员的成长机会，是团队的最大杀手（没人想跟你合作！！！）。

  2. 好好先生：

    无法拒绝任何来自团队内外的需求，导致项目范围无限膨胀。抑或是明确了Game Dev Doc，但还是“耐心”跟不看GDD的人解释概念等。

  3. 微观管理的误区

    对所有成员采用同一种“手把手”教的模式。请参考《高产出管理》的 任务相关成熟度（TRM）：

    1. 低:

    • 表现： 成员对这项任务完全不熟悉，缺乏相关经验和技能，不知道从何下手。

    • 对应的管理风格： 指令/结构化 - 你必须提供非常 具体、清晰、一步一步 的指示。你需要明确地告诉他：“做什么 (What)”、“何时完成 (When)”以及“如何做 (How)”。 - 例子：对于一个从未接触过Unity UI系统的程序新手（低TRM），你不能说“去做个背包界面”。你必须说：“打开Canvas，创建一个Panel作为背景，然后使用Grid Layout Group组件来排列背包格子，每个格子的模板(Prefab)我已经做好了，你先把它拖进去实现布局。” 或者挑选相关的教学视频给他，并让他做笔记学习后再继续完成任务。

    2. 中:

    • 表现： 成员对任务有了一些经验，但还不够独当一面，在过程会遇到问题或犯错。

    • 对应的管理风格： 教练式/沟通 - 你不需要再下达详细指令，而是更多地进行 双向沟通。 - 例子：那位已经做过几个UI界面的成员（中TRM），你可以说：“我们需要一个新的角色属性界面，这是设计图。你可以先思考一下实现方案，尤其是数据如何绑定等，我们明天10点花15分钟讨论一下（或者 每日站会 上）你的方案再开始做。”

    3. 高:

    • 表现： 成员是这项任务的专家，经验丰富，完全可以独立、高质量地完成工作。

    • 对应的管理风格： 授权 - 你需要做的就是 充分放权。只需明确最终的目标和要达成的结果即可，然后就让TA放手去做。过多的干预不仅没有必要，反而会打击TA的积极性。 - 例子：几个月后，那位成员已经成为团队的UI专家（高TRM），你可以说：“下一个版本我们需要重构整个UI系统，目标是提升性能和可扩展性，这件事全权交给你负责了，有需要我支持的地方随时找我。”

队员

谦逊。

关于

作者:

Refactor团队

主要贡献者 (按姓氏拼音排序):

  • 邱文涛

特别鸣谢:

所有走在前列、为后辈探路的游戏开发行业的师兄师姐们。