Demo能为游戏带来什么？

游戏的Demo到底是什么?它会一个游戏开发团队带来什么?有时候会带来灾难，但是在处理正确的情形下，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是让软件自己说话且获得反馈意见的恰当方式。

优化约束问题

对Demo来说，目标日期本质上是一种约束，而实际上，一个项目的最终目标可能就是最大最强的约束。约束能够帮助团队集中精力发现问题并提出创造性的解决方案。当然它也可能导致相反的方向，如果因为管理的混乱导致团队成员不知道时限的存在，项目可能会有一个糟糕的结局。总结所有的情形：团队沟通为王。

总结

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