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

簡體     傳統

　　游戲的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