六年谈-12.工程管理
发表于2015-10-19
很多策划在工作一段时间后感到自己的团队像个作坊，感到乱。这都是因为团队主管没有把游戏制作过程当做一个工程，没有工程管理的技巧与措施。在大型项目，大型团队中（超过30人的团队），有效的工程管理比天才的设计或勤奋的执行更加重要。
工程是利用知识手段用最短时间、最少人力来做出可靠高品质的过程。工程管理就是主管为达到工程目的进行的管理行为。只要具备了工程管理的理念，做游戏团队的工程管理其实可以很简单——预计并记录要做什么，拆分成小的工作，分派安排，定期检查。
预计并记录工作目标是最初始的步骤，也是最关键的步骤。这一部一般被定为需求提出阶段。主管需要清楚在接下来的一个里程碑里，有哪些设计需求。一切工作都源于这些需求，这些需求必须确定和稳定，才能保证后面的工作正常的进行。如果需求不明确和需求胡乱的变化，几乎没有团队能按期按质完成任务。如果你总是加班，总是发现任务玩不成，或许应该找找是不是这个原因。所以，设计需求最好列表，能写多细就写多细，不要遗漏，并且让团队所有人都清楚当前的情况。设计需求形成文档，由主管最后审核确认，团队有了目标，接写来事情才好办。即使需求发生改变，可以通过更新需求文档，让团队执行者明确哪里需要再修改，避免混乱。团队时刻保持对目标——设计需求——最新最清楚的认知，比什么都好。
将设计需求拆分成工作点，是考验主管对游戏系统和团队工作的熟悉程度。主管或许不清楚具体的执行过程，但一定要清楚每一种工作是应该由谁通过做什么来实现的。依靠这种能力，主管可以讲设计需求细致的拆分成小的工作点，并给每个工作点安排具体唯一的一个负责人，最后标注应该完成的时间点。经过各负责人确认后，这就形成了生效的工程管理文档，该文档是设计需求文档的衍生，可用EXCEL或Project工具制作。
安排工作中有一种技巧。在很多软件工程相关的书籍中都有记录。（说明那种图）
主管应该每天都检查工程管理文档中各个负责人的进度，及时发现问题。当工作遇上延期问题的时候，分析原因。需求有问题，就追加需求描述；设计方案有问题就改进或调整方案；人力不足就增加人力或延期。总之，坚持每日的进度检查，可将问题提前暴露，提前应对，否则，到版本发布日，通宵的加班不仅损害心理与健康，还会让最终成品的品质下降一个档次。久而久之的拖延会让团队陷入散漫低迷的士气中。
如果你在一个团队中，发现不知道下一个里程碑是什么时间点，下个版本的设计需求是什么，自己负责的工作有哪些，此时你就需要警惕起来，一定是工程管理出现了问题。想到什么就做什么的作坊式工作最终会被要求效率与质量的市场淘汰掉。
针对游戏制作团队，还需要注意两种特殊的工作管理：设计创意管理和bug管理。
游戏团队成员常常会发散性的想到一些设计创意，我们在创意与设计需求之间要划一条明确的线。主管应建立一个创意库，当团队成员对游戏有看法或创意设想的时候，应该可以将他们的看法创意录入到这个创意库中，这不仅保存了游戏团队成员的创造力，还避免了一些头脑发热的情况出现，很多团队成员可能会一激动就直接将自己的创意制作到游戏中去了，这是非常危险的，应该完全的避免掉。当时机适当的时候，或者需要新创意的时候，我们可以从创意记录文档中找到很多可用的资源，有创意表达强迫症的策划们可以有地方输出自己的创意，需要创意的时候也不用临时逼自己去想，大部分创意都不是逼出来的，而是来自平时的灵感积累。
游戏团队成员也会经常发现游戏中的bug，此时，应该将这些bug先反馈给测试人员，而不是私下就开始修改这些bug，或者反馈给可能产生这些bug的制作执行者，他们也有可能就直接私下进行了修改。这种修改看似高效，但还是后患无穷。正确的bug处理流程是发现、验证、反馈、修改、发布版本、再验证、最终解决。严格的执行bug处理流程应该是不会产生问题的，而如果跳过了验证复现部分，可能会发生虚报bug或问题反馈不全面的情况，而导致浪费制作人员大量时间和人力。Bug没有明确的处理过程记录，失去了再验证的过程，可能导致bug并未完全修复，或者引发了其他未知的bug。私下修改bug的最大问题就是这处修改除了修改者，没有其他任何人知道，游戏的关联性导致其他数据相关者的前置条件发生变化，产生了成吨的新bug，主管不知道这处修改或者该处修改没有文档记录导致修改了什么东西的信息丢失，更是造成了版本失控的混乱——主管所知的提供出去的内容和实际提供出去的内容不一致，也就是说常说的：“我不知道我干了啥了”。
私下修改、无限追加设计需求，私下改变设计方案，私下修bug是游戏工程管理混乱的三大根源。
现代游戏团队经常遇到多版本管理的问题。已经运营的游戏，要一边维护一边研发新的资料片版本时，会遇到多版本管理。制作多语言版本，向不同地区发行时，也会遇到多版本管理的问题。
面对多个游戏版本，每个版本都需要自己的一套管理文档，包含版本设计需求、工程管理文档、更新记录与bug追踪文档。多个游戏版本中，最好有一个版本作为母版，其他所有版本的内容都现在母版中制作，再同步到其他版本中，其他版本再针对各自的需求制作各自特殊的修改。母版保证了各版本中共性的部分可以同步，例如某个版本发现了一个bug，不仅要在这个版本中改掉，还需要回到母版去验证，如果母版也存在相同的问题，那么其他从母版分离出去的版本也都要进行同步的修改。
另外，母版避免了ID重复。以道具ID为例，当一个分支版本中需求一个新道具，而母版中没有制作这个道具，那么在母版更新道具需求时，可能相同的一个道具ID，在两个版本代表了两个不同的道具。这样，当母版中的数据需要同步到这个分支版本的时候，道具ID就重复了。无论怎么修改，都将是一个庞大费时的麻烦事。因此，数据上及时是某个版本的特殊需求，也应该在母版中制作，之后同步到分支中去。所谓的各版本的特殊制作需求，最好只是卡住这些数据内容的开放开关。也就是说，中文版的春节活动数据在日文版的数据中也是有的，因为他们都来自母版的数据，只是日文版将春节活动的开关设为关闭，游戏过程中看不到任何春节活动相关的东西。
工程是利用知识手段用最短时间、最少人力来做出可靠高品质的过程。工程管理就是主管为达到工程目的进行的管理行为。只要具备了工程管理的理念，做游戏团队的工程管理其实可以很简单——预计并记录要做什么，拆分成小的工作，分派安排，定期检查。
预计并记录工作目标是最初始的步骤，也是最关键的步骤。这一部一般被定为需求提出阶段。主管需要清楚在接下来的一个里程碑里，有哪些设计需求。一切工作都源于这些需求，这些需求必须确定和稳定，才能保证后面的工作正常的进行。如果需求不明确和需求胡乱的变化，几乎没有团队能按期按质完成任务。如果你总是加班，总是发现任务玩不成，或许应该找找是不是这个原因。所以，设计需求最好列表，能写多细就写多细，不要遗漏，并且让团队所有人都清楚当前的情况。设计需求形成文档，由主管最后审核确认，团队有了目标，接写来事情才好办。即使需求发生改变，可以通过更新需求文档，让团队执行者明确哪里需要再修改，避免混乱。团队时刻保持对目标——设计需求——最新最清楚的认知，比什么都好。
将设计需求拆分成工作点，是考验主管对游戏系统和团队工作的熟悉程度。主管或许不清楚具体的执行过程，但一定要清楚每一种工作是应该由谁通过做什么来实现的。依靠这种能力，主管可以讲设计需求细致的拆分成小的工作点，并给每个工作点安排具体唯一的一个负责人，最后标注应该完成的时间点。经过各负责人确认后，这就形成了生效的工程管理文档，该文档是设计需求文档的衍生，可用EXCEL或Project工具制作。
安排工作中有一种技巧。在很多软件工程相关的书籍中都有记录。（说明那种图）
主管应该每天都检查工程管理文档中各个负责人的进度，及时发现问题。当工作遇上延期问题的时候，分析原因。需求有问题，就追加需求描述；设计方案有问题就改进或调整方案；人力不足就增加人力或延期。总之，坚持每日的进度检查，可将问题提前暴露，提前应对，否则，到版本发布日，通宵的加班不仅损害心理与健康，还会让最终成品的品质下降一个档次。久而久之的拖延会让团队陷入散漫低迷的士气中。
如果你在一个团队中，发现不知道下一个里程碑是什么时间点，下个版本的设计需求是什么，自己负责的工作有哪些，此时你就需要警惕起来，一定是工程管理出现了问题。想到什么就做什么的作坊式工作最终会被要求效率与质量的市场淘汰掉。
针对游戏制作团队，还需要注意两种特殊的工作管理：设计创意管理和bug管理。
游戏团队成员常常会发散性的想到一些设计创意，我们在创意与设计需求之间要划一条明确的线。主管应建立一个创意库，当团队成员对游戏有看法或创意设想的时候，应该可以将他们的看法创意录入到这个创意库中，这不仅保存了游戏团队成员的创造力，还避免了一些头脑发热的情况出现，很多团队成员可能会一激动就直接将自己的创意制作到游戏中去了，这是非常危险的，应该完全的避免掉。当时机适当的时候，或者需要新创意的时候，我们可以从创意记录文档中找到很多可用的资源，有创意表达强迫症的策划们可以有地方输出自己的创意，需要创意的时候也不用临时逼自己去想，大部分创意都不是逼出来的，而是来自平时的灵感积累。
游戏团队成员也会经常发现游戏中的bug，此时，应该将这些bug先反馈给测试人员，而不是私下就开始修改这些bug，或者反馈给可能产生这些bug的制作执行者，他们也有可能就直接私下进行了修改。这种修改看似高效，但还是后患无穷。正确的bug处理流程是发现、验证、反馈、修改、发布版本、再验证、最终解决。严格的执行bug处理流程应该是不会产生问题的，而如果跳过了验证复现部分，可能会发生虚报bug或问题反馈不全面的情况，而导致浪费制作人员大量时间和人力。Bug没有明确的处理过程记录，失去了再验证的过程，可能导致bug并未完全修复，或者引发了其他未知的bug。私下修改bug的最大问题就是这处修改除了修改者，没有其他任何人知道，游戏的关联性导致其他数据相关者的前置条件发生变化，产生了成吨的新bug，主管不知道这处修改或者该处修改没有文档记录导致修改了什么东西的信息丢失，更是造成了版本失控的混乱——主管所知的提供出去的内容和实际提供出去的内容不一致，也就是说常说的：“我不知道我干了啥了”。
私下修改、无限追加设计需求，私下改变设计方案，私下修bug是游戏工程管理混乱的三大根源。
现代游戏团队经常遇到多版本管理的问题。已经运营的游戏，要一边维护一边研发新的资料片版本时，会遇到多版本管理。制作多语言版本，向不同地区发行时，也会遇到多版本管理的问题。
面对多个游戏版本，每个版本都需要自己的一套管理文档，包含版本设计需求、工程管理文档、更新记录与bug追踪文档。多个游戏版本中，最好有一个版本作为母版，其他所有版本的内容都现在母版中制作，再同步到其他版本中，其他版本再针对各自的需求制作各自特殊的修改。母版保证了各版本中共性的部分可以同步，例如某个版本发现了一个bug，不仅要在这个版本中改掉，还需要回到母版去验证，如果母版也存在相同的问题，那么其他从母版分离出去的版本也都要进行同步的修改。
另外，母版避免了ID重复。以道具ID为例，当一个分支版本中需求一个新道具，而母版中没有制作这个道具，那么在母版更新道具需求时，可能相同的一个道具ID，在两个版本代表了两个不同的道具。这样，当母版中的数据需要同步到这个分支版本的时候，道具ID就重复了。无论怎么修改，都将是一个庞大费时的麻烦事。因此，数据上及时是某个版本的特殊需求，也应该在母版中制作，之后同步到分支中去。所谓的各版本的特殊制作需求，最好只是卡住这些数据内容的开放开关。也就是说，中文版的春节活动数据在日文版的数据中也是有的，因为他们都来自母版的数据，只是日文版将春节活动的开关设为关闭，游戏过程中看不到任何春节活动相关的东西。