>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

　　游戏的Demo到底是什么?它对于一个开发团队来说有多重要?它有时候会带来灾难，但是在处理正确的情形下，Demo会对项目的成功提供一个正面的效应。

　　演示Demo是游戏团队中最两极化的一个话题。在每年二三月份，团队为六月举办的E3电子娱乐博览会作准备时，有关这个话题的讨论就会进入高潮。为了展示或体验即将到来的最新最好的游戏，开发商、发行商、影视明星、体育明星以及其它各式各样的人物都会出现在展会上。在那儿，有大量展示游戏的机会，而开发团队却在畏惧着。

　　畏惧是因为需要赶在游戏开发进度完成前几个月的时间提前完成某些东西。这通常会演变成游戏开发团队的灾难，因为这些本应该在正常开发周期内完成。一个对开发周期脆弱性没有认识的开发团队，在设定一个随意地期限内完成开发，这看起来是一件很疯狂的事。但是有一个办法可以解决这个看似疯狂的问题，在这篇文章中我将列举Demo实际上对游戏开发很有用处的一些关键原因，并试图推翻这个论调。

　　Demo是什么

　　Demo实际上就是一个示例。它是一个将被呈现或者使用的软件产品。如果它通过报刊、展台、下载链接等途径面向消费者，那么它一定相当接近最终版本。在Demo中展示游戏的非亮点，将会降低游戏获得成功的机会，这不是在宣传游戏，而是在伤害它。

　　游戏需要向各种相关者、媒介、会展展示，它们似乎总是不可思议地从四面八方蜂拥而来，导致开发团队往往需要制作各种各样的游戏Demo。这就导致了开发团队抱怨市场团队不理解开发流程，而市场团队埋怨开发团队不支持自己的营销需求。

　　那些仅仅将游戏开始系列展现出来的Demo设计无疑是糟糕的，新手引导肯定是游戏中的必要环节，但往往也是费时乏力的，它决对不可能展示游戏的乐趣与潜力所在，而Demo中最需要展示的是游戏最值得炫耀的部分。因此Demo必须是用心制作的，用于展示游戏光彩亮丽的一面。

　　Demo的价值

　　上面列举了Demo带来了一些负面的事情，你可能会奇怪我还是坚持认为Demo是正面地而不是负面地。Demo有很多收益大于成本的情形，我下面会列举出一些，也希望读者可以给我反馈更多。

　　制定透明的、共享的目标

　　基于传统或者敏捷的项目管理方式都强调要向团队传递一个单一的共同目标。如果你搜索这个话题就可以发现大量的有关社会与团队心理行为学的研究。Demo提供了一个单一的，可论证的目标，可以把它看成一种催化剂或者一个集结点，团队成员可以用它进行各种评估。我上面说过Demo会出现在一些比较特殊的场合，但我并没有说过它只能出现在这些场合。共同目标只是阶段性目标的简单结束，知名的敏捷讲师Clinton Keith说过：“团队应该把阶段性目标看成一个Demo”。他的观点是，通过努力完成Demo将团队团结在一起，而将每一个阶段性目标看成一个Demo并达成，这将迫使团队专注于当前目标并降低风险。

　　明确完成的定义

　　我将“明确完成的定义”放在团队问题列表仅次于“沟通”的位置。这两者经常在项目验收或者回顾时被提及。很多时候，我希望详细地看到团队成员或者外包人员的工作，想知道他们认真与否，他们认为这个项目或者功能是需要进一步改进，还是可以结束了。实际中我将这些职责全部归于我自己。在早些年前，我与团队或者个人一起工作，并同他们一起定义完成的标准。这可以明确工作的标准与质量。生产者需要与它们的股东和团队一起合作，确保每个人都与该完成标准一致以达成交付。这个标准也是相对的，但它并不是始终意味着最终完成的标准。有些工作可能会持续好几个星期，如果某个团队成员计划他的阶段性工作标准而不是最终的标准，没关系。在达成阶段性目标过程中，经常进行面对面的交流，有助于保持项目的推进，如果不进行这种分析讨论，无论项目工程的多大或多小，问题或者压力定会随之而来。这一原则适用于从最小的独立游戏到大型的PC或掌机游戏。

　　完结实践

　　一些团队非常善于完成项目，而另外一些却不是这样。我认为一般这取决于项目经理、团队leader和整个团队确定项目重点与节奏。在项目的完成阶段，团队成员可能不再专注于项目中的重点功能或者Bug，反而希望项目尽快完结。当这发生时，工作就不会再与整个项目的目标保持一致了。

　　我们必须清楚团队专注于什么、它们的bug修复率如何。这时，Demo提供给团队一个项目完结的实践机会，如果每个阶段目标都被看成一个Demo，那么项目肯定能够很好地结束。

　　那些为了制造惊喜的Demo不做也罢。营销展会通常会提前一年时间预订日期，正常情况下发货日期是确定的。生产部门与市场部门应该合作评估可能出现的风险并做出相应的风险管理措施。

　　相关者

　　相关者指的是那些通过一定的方式会对项目产生影响的人，不幸的是有很多这样的人，一般情况下，它们指的是管理人员、董事会等等，不过它们同样也可以指团队成员、客户、政府机构等。生产者应该向它们清晰地展示项目的进展情况，而Demo提供了这样一种手段。电子乐的创造者Bing Gordon经常在会议期间要我们停止使用“含糊不清地词语”，他指出展示软件时使用这些词语会显示说话者自己的紧张情绪。他认为应该让软件自己说话而不是被别人说“这还没有开发好”或者“这是我们需要提高的地方”。现在我意识到，“含糊的词语”实际上妨碍了双方的交流，因为它抢先切断意见或反馈或批评出现的路径。Demo是让软件自己说话且获得反馈意见的恰当方式。

　　优化约束问题

　　对Demo来说，目标日期本质上是一种约束，而实际上，一个项目的最终目标可能就是最大最强的约束。在Sendhil Mullainathan教授和Eldar Shafir合着的《Why Having Too Little Means So Much》一书中，作者对结束的价值进行了探讨。他们声称，大脑会优先记忆稀缺性食物、金钱等。这种观点非常有趣，我们稀缺的是时间。换句话说，不足的时间导致人们往往侧重于优先级最高的工作。如果不能正确地设置这些时间点，就可能会对未来的目标造成不利的影响。这就是为什么我同意Clinton Keith的“将阶段性目标看做Demo”的观点。常规时间产生的压力使团队专注于自己的工作节奏。在经过数年的努力后，项目快要结束时，团队经常会失去动力与专注度。而阶段性目标使团队的紧迫感可持续，有利于缓解恐慌，特别是在最后时刻就要来临时。回首自己的项目，你会发现在项目的初始阶段花费更多的时间是明智的。

　　约束能够帮助团队集中精力发现问题并提出创造性的解决方案。我与其它艺术家、设计师、程序员探讨过类似的观点，他们都认为约束能够帮助他们解决问题且更富有创意。要尽快完成项目，团队成员必须保持效率，因此时限约束有助于提高思维的创造性、有助于减少时间浪费。当然它也可能导致相反的方向，如果因为管理的混乱导致团队成员不知道时限的存在，项目可能会有一个糟糕的结局。总结所有的情形：团队沟通为王。

　　总结

　　最后，我相信在处理正确的情形下，Demo会对项目的成功提供一个正面的效应。我肯定，很多读者会有其它不同的想法，因为这本来就是一个开放性话题。我欢迎任何意见。

网载 2014-07-02 15:10:43