小团队管理指南：项目开发前、中、后期都有哪些管理方法？

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

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

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

• Pre-Production
  

• Waterful vs Scrum瀑布式开发及敏捷开发

• Pitch Doc / Project Summary 直观概括的项目文档

• Design Wiki

• 1-Page Design Doc
  

• Project Plan 项目计划
  

• MileStone 里程碑

• Product Backlog/Feature List 待完成任务
  

• Sprint 快速迭代
  

• User stories
  

• Size: Story Points 关于工作量预估
  

• Planning Poker计划扑克
  

• Burn Down Chart & Velocity Chart
  

• Daily/Weekly Check-in每日站会
  

• Version Control版本控制
  

• Pipeline 工作流程
  

• Build Note 更新笔记 + Bug Report 问题报告 + Playtest 测试
  

• Post-Production

• Retrospective 及时回顾总结

Waterful VS Scrum瀑布式开发及敏捷开发

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

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

Pitch Doc / Project Summary 直观概括的项目文档

在独立开发团队中常常被忽视的重要一环便是项目预估，而有效的项目预估可以帮助我们更好地把控全局，正确评估任务优先级，明确进度，最大化地减小未知模糊性等。而在项目立项之初，预估的第一项便是Pitch Document了，大概可以称之为创意文档，以最少的篇幅简要地描述游戏的核心内容。

设计者在将创意写下来的过程中不仅可以帮助其明确创意雏形，也是立项后项目开发方向的核心指导。Pitch Doc需要随着项目变化保持更新，是在向他人介绍游戏时的重要参考文件。这类文档约在2-5页左右，主要解决以下几个问题：

• 你想要做什么？
  

• Overview: 一句话概述游戏

• Platform & Genre: 目标平台及游戏类型

• Gameplay: 核心玩法概述（可以配合图示解说，参考下文1-Page Design Doc）

• Feature: 为什么要做这个游戏？／为什么是一个值得做的项目？／有什么与众不同的特点？…（若是商业项目，可能需要简单的竞品分析）

• 同类产品: 为了更方便迅速的理解游戏，可以简要提及相似的同类型作品

• 它看起来是什么样的？
  

• 美术方向：展示概念设计或参考图等

• 你打算怎么做？
  

• Team: 简要描述团队成员分工及强项（为何可以很好的完成这个项目）

• Scope, Budget, Timeline: 简要描述项目规模，预算及时间规划

Design Wiki & 1-Page Design Doc

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

Design Wiki （比如可以参考看看Stardew Valley的 Wiki ：链接http://stardewvalleywiki.com/Stardew_Valley_Wiki）

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

1-Page Design Doc （详参GDC讲座地址 ： 链接http://www.gdcvault.com/play/1012356/One-Page）

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

（在网上无意发现了一个设计师的个人网站中有不少使用了1-Page Design Doc的例子，可以看看TUTORIALS：链接http://bobbyross.com/tutorials/）

Project Plan 项目计划

项目计划表可以算是项目管理中的核心文件了，小团队由于人力不足没有精力维护大量文件，因此在我自己的项目中，我把时间表，里程碑，以及Backlog，Sprint的任务安排都集合在了这个表里。这样我日常维护的文件基本就只有Project Plan及后文将提到的Build Note了。

下图便是我目前项目在用的计划表，可以看到［顶部横轴］是时间节点划分以及里程碑相关内容。时间点跟工作密度相关，我的表内大概是半周一格，如果工作密度高可以分得更细。

［左侧竖轴］第一列是大类类别（设计／美术／程序／音乐等），第二列再将每类分为不同的Sprint主题以及Backlog，三四列便是写成User Stories形式的具体任务或者也可以说是Feature List了，每个任务旁对应的是使用Story Points预估的工作量。

中间可以用色块定义对应任务安排的时间段，不同的颜色代表由不同的人负责。定期完成的就变成深色，没有对应计划时间完成的，计划就变为灰色。

MileStone 里程碑

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

Product Backlog/Feature List 待完成任务

我们在文初已经简要的提及了敏捷开发的工作模式，敏捷开发将一个长期的大项目切分成数个短周期，每个周期历时约为1-4周不等，称为一个Sprint（冲刺）。在立项之初，根据定下的Pitch Doc，团队成员要将目标转化为一系列待开发的Feature List（待实现的功能／特点），进而形成最初的Backlog（待完成的任务）。

在项目开发早期，比如仍在快速Prototype阶段时，可能由于项目需求尚不明确，提出的Backlog会比较大和模糊。不过没关系，这个时候不要认为这项工作是无用的，Backlog及Feature List会在项目不断清晰的过程中不断迭代更新，你的预估也会越来越准确。

例如下图中所示，Product Backlog通常包含标题名，状态，描述（写成User Stories的形式），以及Size工作量预估等。