小游戏团队为什么要做项目管理？作为独立开发者或者小型开发团队，由于直接沟通成本较低，过多的项目管理流程反而使得开发过程变得繁琐，除此之外也因资源有限，小型开发团队很少设有专职的项目经理控制项目进度，以至于规范的项目管理方法常常在小团队开发中被忽视。也正因如此，如若没有外部压力（例如发行商的督促）独立开发团队也较容易因缺乏有效预估和进度控制等原因导致项目拖延。

因而本文整理了一些个人认为对于独立团队来说相对实用的项目管理方法，希望对各位有所启发。称之为“指南”其实并不很贴切，本文中所提及的方法主要来源于在NYU Game Center的一门项目管理课程Production Practicum中所学，结合个人的实际经验进行的简易总结，并不能被当作严谨全面的“指南”，希望借此抛砖引玉，欢迎各位也来分享自己认为实用的项目管理方法。

项目管理的核心可以概括为随时明确谁应该在什么时候做当下最该做的事情以及为什么要做，并且最大化的减少未知的模糊性。而项目开发分为三个阶段Pre-Production(开发前)，Production(开发中)，Post-Production(开发后)。 那么各阶段中又都有哪些重要的项目管理方法呢？

在项目立项之初，首先需要确定的是团队要采用的开发方法，是瀑布式开发还是敏捷开发。 传统的瀑布式开发强调把每一个阶段都做到完美才进入下一个阶段。从需求分析到设计，从设计到开发（程序，美术等）再到测试。瀑布模型强调文档，前期没有迭代与反馈，因而对于需求不明确易变更的项目很不灵活。

而在游戏开发中，个人认为好游戏不是想出来的而是改出来的，一切以玩家为中心才是好游戏的根本，非商业向的游戏需求变更更是家常便饭。因而强调小版本及频繁迭代与测试的敏捷开发（例如Scrum模型）或许更加适合游戏，不仅是小团队，目前也已基本被业界普遍推广采用。敏捷开发灵活性高，强调面对面的及时交流（例如Daily Check-in日常站会等），快速迭代（以Sprint为指导的短周期开发），经常性的打包可运行版本及时测试等等。后文中将讨论的方法基本是敏捷开发中常用到的一些方法。

在独立开发团队中常常被忽视的重要一环便是项目预估，而有效的项目预估可以帮助我们更好地把控全局，正确评估任务优先级，明确进度，最大化地减小未知模糊性等。而在项目立项之初，预估的第一项便是Pitch Document了，大概可以称之为创意文档，以最少的篇幅简要地描述游戏的核心内容。设计者在将创意写下来的过程中不仅可以帮助其明确创意雏形，也是立项后项目开发方向的核心指导。Pitch Doc需要随着项目变化保持更新，是在向他人介绍游戏时的重要参考文件。这类文档约在2-5页左右，主要解决以下几个问题：

• Feature: 为什么要做这个游戏？／为什么是一个值得做的项目？／有什么与众不同的特点？…（若是商业项目，可能需要简单的竞品分析）
• 同类产品: 为了更方便迅速的理解游戏，可以简要提及相似的同类型作品
• 美术方向：展示概念设计或参考图等
• Team: 简要描述团队成员分工及强项（为何可以很好的完成这个项目）

除了Pitch Doc外，在之后的开发中也还会配合增加一些必须的项目文档。但在敏捷开发中，繁冗传统的设计文档由于沟通成本过高并且没人想要读一本几十页的说明书，已经很少再作为沟通的媒介使用。以下两项是目前在行业内需要使用必要的设计说明文件时较常使用的方法：

简单来说是将传统文档变成在线文档，易检索与更新，方便共同编辑。通常作为查询归档使用，并不太作为开发指导文件。

1-Page Design Doc是提高文档使用率及沟通效率的新形式。最初灵感源之一是建筑工程图纸，强调以最少的篇幅（仅一页！）及直观的图示诠释设计。一页的篇幅极大地减轻了开发人员阅读繁冗文字的痛苦，并且使得及时交流与更新变得更为便捷，图示相较于文字也更容易展示系统间的关系及动态变化。1-Page Design Doc我们较常见的类型可能是UX设计中常用的Flow Chart界面流程图，但其实也可用于其他设计中，常见的比如还有关卡设计，核心玩法解析等。

（在网上无意发现了一个设计师的个人网站中有不少使用了1-Page Design Doc的例子，可以看看）

项目计划表可以算是项目管理中的核心文件了，小团队由于人力不足没有精力维护大量文件，因此在我自己的项目中，我把时间表，里程碑，以及Backlog，Sprint的任务安排都集合在了这个表里。这样我日常维护的文件基本就只有Project Plan及后文将提到的Build Note了。下图便是我目前项目在用的计划表，可以看到顶部横轴是时间节点划分以及里程碑相关内容。时间点跟工作密度相关，我的表内大概是半周一格，如果工作密度高可以分得更细。左侧竖轴第一列是大类类别（设计／美术／程序／音乐等），第二列再将每类分为不同的Sprint主题以及Backlog，三四列便是写成User Stories形式的具体任务或者也可以说是Feature List了，每个任务旁对应的是使用Story Points预估的工作量。中间可以用色块定义对应任务安排的时间段，不同的颜色代表由不同的人负责。定期完成的就变成深色，没有对应计划时间完成的，计划就变为灰色。

里程碑应该不用过多的解释，主要是根据自己项目的情况定义一些重要的时间节点，再根据工作量及优先级安排这个时间段内的工作。里程碑应当包括时间点及定义为“完成”的具体内容或标准。

我们在文初已经简要的提及了敏捷开发的工作模式，敏捷开发将一个长期的大项目切分成数个短周期，每个周期历时约为1-4周不等，称为一个Sprint（冲刺）。在立项之初，根据定下的Pitch Doc，团队成员要将目标转化为一系列待开发的Feature List（待实现的功能／特点），进而形成最初的Backlog（待完成的任务）。
在项目开发早期，比如仍在快速Prototype阶段时，可能由于项目需求尚不明确，提出的Backlog会比较大和模糊。不过没关系，这个时候不要认为这项工作是无用的，Backlog及Feature List会在项目不断清晰的过程中不断迭代更新，你的预估也会越来越准确。例如下图中所示，Product Backlog通常包含标题名，状态，描述（写成User Stories的形式），以及Size工作量预估等。
那么定义完最初的Backlog之后，我们就可以开始进入以Sprint为基础的开发阶段了。首先根据预估中对项目全局的把控及优先级的判断，确立当前Sprint的主题及定义为“完成”的标准及内容，然后从总Backlog中拿出符合这个Sprint的部分，将他们分解为易评估的具体任务并补充未考虑到的任务，根据优先级排序形成我们这个Sprint的“To Do List（待办）”。每天的日常站会（详见后文）后更新任务版，将今天要完成的任务从“To Do（要做）”移至“In Progress（进行中）”，将已完成的任务移至待测试／确认一栏。

任务管理看板作为日常进度控制的主要管理方法，可以使用实体的，也可以使用例如Trello等软件完成。但因为这样的看板不太利于归档记录，因此上面所说的Project Plan便可以承担总控制归档的角色，从Project Plan中取出相应的Backlog，Sprint完成后再归档更新至Project Plan即可。我因为团队很小且情况特殊，项目看板只有我一人使用，因而为了方便我没有重复使用额外的看板，而是直接使用了Project Plan进行进度追踪。
在每个Sprint结束后都要完成一个可以交付试玩的版本，并立即进行测试，根据反馈评估这次的工作并调整接下来的计划。不要因为担心游戏不完美就憋着不测试，尽早的接触游戏的核心服务主体“玩家”才能尽快的发现问题及时调整开发方向。敏捷开发极其强调可玩性，要求优先维护玩家体验。对可交付版本的高要求及高频率自然而然地会帮助我们明确哪些是可以提高可玩性及用户体验的任务，并优先完成他们，这也是我认为在游戏开发中应首要考虑的部分。

Backlog的需求描述通常需要写成User Stories的形式，用最清晰的表述方法让这个需求的目的明确且易评估。标准写法格式如下：

作为，我想要，以便于。

其中需要注意的是这个“角色”指的是这个“行为”服务的对象，在游戏中通常来说都是玩家，但也有其他情况比如为了方便开发进行的额外编辑器开发等服务对象就不属于玩家。

这样写看似比较麻烦，但实际上真正用起来好处也是比较明显的。首先可以更准确的传达真正的开发需求，同时“目的”可以让开发人员明确为什么要做这个工作，并且这样写相当于设定了评估主体和行为，为后期测试提供了一个可测量的标准。

对于工作量的预估，在敏捷开发中惯常使用的是Story Points。Story Points是任务间的工作量比较，而无关乎实际工作效率（例如团队规模等），与我们在其他地方见到的比如X人天或Y小时等与具体情况紧密相关的时间预估不同，这种预估方式拥有更强的灵活性，不会因为具体情况的改变导致所有预估需要重新进行。 每个人的工作效率／能力也可以使用 Story Points进行评估。比如根据预估及实际调整后可以基本定义人员A的每周工作效率是30点，B是35点等，再据此评估团队效率，安排这个Sprint中可以放进多少点的任务。在实际工作中，如果有实际工作量超出或少于预估的情况，我们可以根据偏移量的统计，判断项目是否可能延期或提前完成。

简单来说就是每个人手上有同样的一沓标有数字的扑克，代表Story Points的点数。挑选出一个需要讨论的Backlog，每人私下选好一张认为相对应的工作量点数牌，同时亮出。如若差距不大，则可确定，若差距较大，差距大的几个人间互相讨论理由，再继续游戏，直至所有成员基本达成一致。这个游戏可以帮助有效确定一些不好预估的任务，也可以加强团队成员的沟通，解决对潜在的对项目理解不一致的问题。

敏捷开发中的一个重要习惯便是每日站会，通常在每日/每周开始时进行，站立执行是为了保证汇报尽可能的简洁及快速。通常来说要求简短直接的向其余团队成员说明三个问题：

• Did（上个站会后）:“我上周/昨天做了什么”
• Doing（这个站会后）:“我今天/这周要做什么”
• Blockers:“我有没有遇到什么阻碍/问题”

这些在帮助自己明确计划的同时，也让其余成员清楚你的进度，如有工作交叉的部分可以及时沟通，同时隐形的压力会让你保持高效率，避免无故拖延。

在开发中，版本控制极为重要，这也是行业内必备项目管理流程，但是作为小白独立开发者在早期可能并不会意识到这点。简单来说版本控制就是随时将最新无问题的工程文件备份至云端服务器，所有修改均先在本地进行，确认无影响工程正常运行的问题后再更新至服务器。

版本控制由于可以同时开发极大促进了多人合作效率最大化，并使远程合作成为可能，出现了问题也可随时回退至之前的版本。即时是一人独立开发，养成使用版本控制的好习惯也会使开发更有条理及可控。版本控制可使用的软件非常多，比如SmartSVN，TortoiseSVN，Github等，服务器有一些是免费的比如可以在 Assembla 上申请一个服务器空间或者用 GitLab 配合 Source

归纳整理工作流程图（包括谁负责什么部分）以及技术流程图（包括各部分使用的软件等）能尽快帮助新成员融入了解项目，也能提醒团队成员工作流程。
但在小团队开发中，个人认为最重要的应该是资源流程图了（包括资源命名规则及存放位置），越早整理，规范使用可以帮助工程保持有序整洁，避免了越来越庞大的工程因没有尽早规范梳理，以致资源混乱却无从下手的情况。

在敏捷开发中，要养成经常Build的好习惯。（经常导出可运行版本）而Build Note即所谓的更新笔记就是每次导出时针对这个版本有哪些更新的内容所写的总结，有一些类似我们通常在app store中看到的更新附录。Build Note的愿意图是提供给QA方便测试的。然而在小团队中即使我们没有专职QA，保持良好地撰写Build Note的习惯依然很有用，因为它帮助我们及时理清我们在上个版本中完成了的内容，并给测试提供参考。另外在内部使用的Build Note中给一些必要的变更项附加变更意图是很重要的，因为在长期开发中有时候会忘记当时为什么要修改某个功能，Build Note可以帮助我们记下自己的设计思路。

在我的Build Note中，我把Bug报告与测试报告也放到了一起，归档到每个版本下，再据此统一更新到Project Plan里。有效利用Tag标定每个条目使得检索变得更为方便，在每次有可玩版本后我都会测试，因此每个Build Note后都跟了一个Playtest的测试报告，根据测试总结出一些需要更新或者需求等级高的任务。同样地，也可以给根据测试反馈的任务需求利用Tag标定优先级。

在每个Sprint完成及结项后都别忘了花点时间对前段时间的工作或项目进行总结，包括哪些做的好哪些不好的，如何改进，并及时对项目进行整理，包括源代码，最终资源及原文件，文档等。良好的回顾习惯可以帮助团队进步磨合，并且井井有条的工程及资源，文档等也使日后的更新或者二次开发变得容易的多。总之，未来的你会感谢现在的你的。