萬字長文,團隊文化建設如何影響和改變企業的最終戰鬥力,下篇

篇目1,闡述King公司“快樂工作”的運營理念

作者:Jim Squires

與其他知名媒體的同行一起,我有幸參觀了位於斯德哥爾摩的King工作室。這家休閒遊戲巨頭的代表作是《Candy Crush Saga》和《Farm Heroes Saga》。

此行我們詳細地瞭解了他們如何成爲領先的跨平臺開發者,儘管這些事蹟和數字令人震撼,給我們留下最深刻印象的卻是:King的員工很快樂。不是“因爲有媒體在這裏,所以大家要擺出笑臉”的那種快樂,而是發自內心的那種快樂。目睹了他們的日常運作情況後,不難看出爲什麼。

下午5點下班。與遊戲行業的許多公司一樣,組成King團隊的成員具有各種各樣的背景。成員名單有很多是做過某AAA遊戲的人的名字。比如,《Pet Rescue Saga》的首席製作人Henrik Sebring在進入King的Malmo工作室以前是在育碧參與制作即將推出的遊戲《The Division》。如果你曾經做過AAA遊戲,你一定經歷過那種令人崩潰的時期——每一款遊戲在發佈前都要經歷的“關鍵時刻”。

當你從事AAA/零售遊戲,你必須時時追趕可怕的截止日期。爲此,你可能要每週在辦公室工作120個小時,直到力竭不支。這就是糟糕的現實,也是King不得不擔憂的問題。因爲從事社交/手機遊戲開發,King可以設置自己的截止日期。產品不到發佈就不算完工,如果潤飾還不夠就把發佈期延後。因此,King的員工總是能按時下班陪家人。

collaborate(from gamezebo)

collaborate(from gamezebo)

團隊合作不競爭。當一家公司內有好幾支團隊在做多個項目時,往往形成競爭性環境。團隊A希望自己的遊戲賣得比團隊B的好,團隊B也不甘心輸比團隊A。這並不是適合好好做遊戲的環境。雖然King的團隊承認希望看到自己的產品成爲公司的“《Candy Crush》第二”,但King的整個結構是圍繞“合作和分享”建立起來的。

怎麼做?雖然King旗下有多個工作室且每個工作室都有自己的項目,但King努力把所有工作室都聚集在歐洲。這麼做有兩非常明智的理由:一是工作室都處於相同的時區,二是工作室之間可以通過快速航班往返。假設你在倫敦的工作室做《Farm Heroes Saga》,你可能有一個創意想添加到遊戲中,但你不知道如何執行。因爲這是一款三連消遊戲,你打電話給身在斯德哥爾摩的首席製作人,看看他們有沒有試過。接着你接到通知這款遊戲的幾位開發者來倫敦跟你一起工作幾天,和你的團隊一起完善想法,看看是否可行。

King的合作文化不是把你自己的遊戲做好——而是把King的遊戲做好。那意味着所有人其實都在一個大團隊中,無論你屬於哪一個工作室,在做哪一款遊戲。

team(from gamezebo)

team(from gamezebo)

寬容失敗。做遊戲是一個要麼成功要麼失敗的命題。有些遊戲會成功,有些遊戲會失敗。King接受這個事實。他們在斯德哥爾摩有一個團隊就是專門負責爲新遊戲構思創意的。或者準確地說,King有一支專業的空想家團隊。

當他們想到一個想嘗試的點子時,他們就會做成網頁遊戲放在King.com上。網站是他們的“競技場”,也是新想法的測試基地。

如果遊戲在King.com上表現良好,他們就知道這款遊戲的成功只是時間問題,多虧了神奇的分析學。我不想廢話太多細節,但King有一個公式可以推導某款遊戲是否能夠成爲下一個“Saga”,是否值得重製爲Facebook遊戲和手機遊戲。極少遊戲能達到這個程度——沒關係。嘗試和失敗是我們的學習途徑;對於像King這樣的遊戲公司也不例外,因爲這就是生活。

每個工作室不超過80人。還記得上中學時你怎麼知道你的年級的所有學生的名字吧嗎?雖然King正在以過快的速度成長着,但他們保證把每個工作室的人數控制在人人都能記住其他人的名字的範圍內。我們都聽說工作室人數不應該超過70或80。爲什麼?我想答案還是得回到之前提到的合作文化。如果你知道所有人的名字和他們分別幹什麼,你就不會老是說“喂,那誰,過來看看我設計的新關卡。”

瑪芬蛋糕。我沒有問過他們每天的“福利”是什麼,但根據上圖,應該可以猜到是美味的瑪芬蛋糕。蛋糕的白色部分是白巧克力/奶酪蛋糕,餡料是巧克力醬。這種蛋糕太粘了,我只好用紙把它包成像墨西哥煎玉米卷的樣子。

早上9點來工作室,我看到有幾個人聚在一起,一邊吃美味的早餐,一邊開小會。確實,正是這樣的氛圍使King成爲King。King不是那種讓你急匆匆地闖進來撲到辦公桌上的公司。在King,你與周圍的人建立良好的關係。你合作,你傾聽,你享受美味的早餐。也許,只是也許,你還會在這個過程中想出個把令人驚豔的休閒遊戲。

篇目2,Harald Riegler談塑造公司文化的若干原則

作者:Christian Nutt

在歐洲GDC的深入談話中,Sproing聯合創始人Harald Riegler坦白談及塑造能夠贏得尊重及帶來成功的企業文化的挑戰性及優點。

Riegler(遊戲邦注:他管理一家65人的奧地利公司,公司主要製作免費遊戲和主機遊戲)表示,“正確的企業文化能夠激發員工出乎意料的優點。”

他表示,遺憾的是,塑造正確的企業文化是項艱鉅挑戰——但塑造這一文化非常重要,每位團隊成員都要清楚這點。

Riegler表示,“這一文化將決定工作室或團隊的成敗。糟糕的企業文化甚至會摧毀整個團隊。”

雖然“近來的銷量上百萬管理方式”書籍給出許多建議,但Riegler對於趨勢和技巧不屑一顧。他表示,“真正重要的是,着眼於人際互動、人類特性及其行爲。”

“良好的企業文化是建立在若干持久原則基礎上——原則對我來說不只是系列規則,它是你生活及行動方式的基礎。”

但他表示,“完善企業文化需要經久不息的投入,”所以請做好進行改變的準備。

如下是他總結的原則:

尊重

Riegler表示,“要領導團隊,你必須對他們懷有內在的尊重之情。”若你不尊重和你共事的人士,“那你從一開始就註定要失敗。”

他表示,“若你覺得自己高人一等,”對方會感覺得到。“肢體語言是我們的主要溝通方式。”

Riegler表示,“尊重會帶來相互信任的環境,信任非常重要,因爲只有在相互信任的環境中,你才能夠應對複雜問題。你可以公開談論大家不想談論的話題。”

以身作則

Riegler表示,“各種書籍都紛紛表示,如果你希望自己的孩子動手,那就自己親自示範。”這也適用於公司環境中。

Riegler表示,反過來亦成立:“若你不希望大家這麼做,那你也不要這麼做。己所不欲,勿施於人。”

責任感

Riegler表示,“這點着實有些棘手。”

他表示,“要讓下屬變得富有責任感有些傷腦筋。”但作爲經理,“我覺得唯一的方式就是,將自己變得富有責任感,進而將此引入企業文化中。”

你要怎麼做?他表示,“你得告訴大家,你要着手做什麼。你要願意評估自己。”最後,“你要公開描述自己取得多少成就,這並不簡單,因爲你很少能夠做到事事順利。”

成熟

“成熟並不意味着你非常有經驗,你是個行業元老。在我看來,成熟是指能夠自我反思,清楚自己的優缺點,知道自己該做什麼,該朝何處前進。”

他表示,遺憾的是,“鮮少有人能夠做到這點,因爲這需要誠實思考自己的性格,這會讓人覺得不舒服。”

但他表示,記住,“優秀參與者通常非常清楚團隊所面臨的挑戰”,自我誠實和自我反思在此是關鍵——這不僅只是完善自我以及更有眼界;它給團隊及公司業務帶來深遠影響。

他還表示,總是會摻雜愛出風頭的人士、陰險小人及強勢角色。Riegler表示,“注意所有這些角色,他們非常危險。”

樂趣

他表示,“我覺得樂趣非常重要。”大家可以轉投其他不那麼有趣的行業,賺取更多收益,因此在遊戲行業,趣味是關鍵。

但他表示,這並不是個不專業或鬆懈的行業。Riegler表示,“有時這被看作是鬆懈的行業——年輕人通常將樂趣和缺乏嚴肅性及雄心壯志混淆。”所以不妨進行你的桌上足球比賽,但要確保公司的目標保持清晰。

另一方面,“成熟和瘋狂並不矛盾”(遊戲邦注:怪異在遊戲行業的文化中不可避免,所以不妨保持開放態度)。

自由

Riegler表示,“自由決定如何解決某任務”非常關鍵——“而不是採用事無鉅細的微觀管理方式。”

Rigeler 表示,“享有彈性上班時間,能抽出時間處理家庭問題等”非常重要。“自由給予所有成員較多自主性,互相信任的環境能夠有效創造自主性,而自主性能夠促使成員倍受鼓舞。”

誠實

這是最重要的元素之一,同時也是最具挑戰性的一點原則。“若是犯了錯誤,不妨大膽承認。不要害怕。在你所處的文化中,承認失敗是能夠被接受的。”

他表示,缺乏可行性的環境是“怪罪文化”。“在此文化中,很多重要元素就不會公開呈現出來。”

成員們爲什麼不想保持誠實?他表示,“這都是因爲他們害怕應對失敗。”但你必須承認,“我們偶爾總是會出錯。”

若所處的是倡導公開及誠實溝通的文化,“聰明的團隊成員就會發現你出錯了,他們會向你指出,防止你鑄成大錯。”

但他有個提醒:若成員總是誠實指出出錯地方,“你可能會陷入吹毛求疵的誤區中,”這會帶來悲觀主義。“但你不能喪失信心。”

認知

Riegler表示,“大家的普遍認知是,文化非常重要,我們的互動方式能夠塑造帶來成功的文化,這非常重要。”換而言之,“所有人都要清楚這些原則,嚴格遵循它們。”

你需要承認的是,“大家都能夠有所改善。”但“你不能直接告訴他人要進行改善。這不是實際運作模式。這是個緩慢過程。”

後果

Riegler表示,“這些原則若沒有得到執行,它們就沒有什麼意義。”這是自下而上的過程。

他表示,“若你容忍成員忽視公司原則,那你脫離這些原則意味着什麼?大家會覺得這些不是真正的原則,這將帶來嚴重危害。”

最後思考

他表示,在沒有開放文化的公司中,“很多時候大家會對在會議上指出‘這出錯了’的成員印象深刻,你很好奇他們如何做到這點,因爲企業文化讓我們很難直接指出這些地方。”但若你塑造的是基於相互信任、責任感和互相溝通的文化,“更多成員就可以這麼做,公司將得到顯著改善。”

他表示,“你能夠反思你的優缺點,這會讓你變得非常有價值。你需要找到志同道合的夥伴,你可以創建能夠順利存活下來的團隊。”

篇目3,開發者需適應並謹慎管理遊戲製作風險

作者:Florian Schwarzer

惡夢是什麼?惡夢就是,你組建了一支優秀的團隊,辛苦地工作了兩年,發佈了一款精良的遊戲——最後眼睜睜地看着它失敗了。

更可怕的是:我們這個行業每天都在上演這種悲劇。

令人驚訝的是,我們並不太經常討論這種風險。甚至我們當中那些肩負着“企業責任”的人似乎也在逃避這個話題。我們經常討論開發過程或領導策略,卻極少花時間探討如何應對開發風險。這通常會讓你產生一種錯覺:我們在發佈遊戲方面一直在進步——但事實上,我們在保證產品成功方面卻沒有什麼長進。

是不是因爲居於成功遊戲的核心的東西與導致其他軟件成功或失敗的東西完全是不同的?

長久以來,我們的項目管理一直向軟件開發行業看齊,我們從中學到的經驗已經幫助我們改進製作遊戲的方法。但我仍然認爲,侷限性是存在的;我們所面臨的挑戰是其他軟件開發管理者永遠不會遇到的。遊戲開發者遇到的第一個挑戰是:遊戲設計。

小區別

遊戲是用來娛樂的。這就把遊戲與傳統的軟件區別開來了,遊戲相當於軟件的子類別。這也意味着我們承擔的風險與電影或小說一樣:我們的受衆可能根本看不到我們的遊戲好在哪裏。研究人員稱之爲“製作風險”。

Illustration(from-develop-online)

Illustration(from-develop-online)

作爲管理者,我們通常認爲風險就是應該最小化的威脅,或者在更糟的情況下,至少應該緩解。然而,我們也能這樣對待這樣的風險:玩家感覺不到我們認爲有趣的東西到底有趣在哪裏嗎?

基本上,讓某種東西變得有趣的很大一部分在於讓受衆產生好奇心。衆所周知,我們喜歡新事物——幾乎所有遊戲都努力地爲它的玩家提供一定程度的新意。我們研究,我們製作,我們宣傳嶄新的東西,無論它是實驗作品還是老遊戲的續作。

豪賭

當然有一個問題:對我來說是原創的東西,可能對你來說是老套的。要在做出來以前預測一款遊戲是否達到我們的期望是非常困難的。特別是還要考慮到這麼多受衆,預測基本上是一件不可能的事。想一想爲什麼好萊塢電影會走進模式化的怪圈。

顯然,這意味着冒太多創作風險是不明智的。畢竟,如果我們發佈的產品與以前的產品都大不相同,那麼它很可能就迎合不了大多數人的品味,是吧?

確實,但我們的玩家仍然喜歡新玩意。像《傳送門》或者《Wii Sports》這類遊戲表明,如果你冒險了,並且找到受衆,反響是會非常熱烈的。創作風險就像搞投機——結果可能好也可能壞。

當然,圍繞一個比較保守的概念做出一款好玩的遊戲也是有可能的。比如《星際爭霸2》,就是一個成功的案例。再以吉他遊戲爲例,它們的主題太保守了,雖然執行得不錯——所以它們的玩家都玩不久。所以,保險也是一種冒險。

說到底,無論你做的遊戲是哪種類型、你做得有多好,你仍然是在投骰子。遊戲的賣點正是讓遊戲成功又冒着最大風險的東西。所以,我們在計劃時必須認真考慮。

管用嗎?

顯然,如果我們想幫助遊戲設計師處理有風險的設計,我們首先應該評估它們。同樣顯然的是,最好能儘快把這些設計做出可測試版。

這裏有一個好消息,所有與遊戲設計有關的部門都有自己的一套快速製作原型和測試想法的辦法。因此,制定測試計劃似乎是相當容易的事。比如,你可以先測試新設計的紙上草圖,再模擬UI,邏輯原型,最後在測試服務器上發佈完全版。這種計劃很吸引人,因爲讓團隊和投資商都感到穩妥。當然,它是不管用的。

部分原因在於時間。團隊總是太專注於詳盡的測試,結果卻發現沒有時間修復錯誤的地方。

更糟的情況是,玩家測試產生混亂的數據。玩家會提出各種改進建議,不同看法很容易產生分歧,所以解決方案當然也是五花八門。這時,只要主要投資人或主管認可這種不同的意見,那麼遊戲設計師馬上就失去他們自己的概念的控制權。

敏捷開發的侷限性

爲了解決時間不足的問題,似乎只能把大規模的原型製作活動嚴密地整合到開發過程中。讓我驚訝的是,當我開始做敏捷開發方面的顧問時,有人告訴我,這是一個糟糕的主意。

我們都知道Scrum和極限編程。把待做事項列成一個目錄,把最重要的東西放在最上面。這就好像爲自己設定了一系列衝刺目標,每到達一個目標,就應該做完一定量的工作。因爲追求每一個目標的過程都是一場衝刺賽跑,所以擠出來的時間就會越來越多。

但我們當中許多人都忽略了“傳統的”敏捷開發是什麼。沒有標誌性事件,沒有審查。做完前面幾周後,最重要的東西做出來了。然後,隨着衝刺目標,團隊會做出更好的東西。

順着這個邏輯,把衝刺時間用於製作最終可能要丟掉的原型或要重製的東西,簡直就是浪費。制定全面計劃?那就是我們出錯的地方。

對於B2B應用開發,敏捷開發適用於開發確定的東西。然而,確定排在目錄最前面的東西對用戶來說就是重要的,這是不可能確定的事。這也是遊戲開發中不能確定的。

Illustration(from develop-online)

Illustration(from develop-online)

根源

這意味着,我們應該適應遊戲設計的創作風險,我們必須根據我們的領域特性安排開發流程。我們不知道我們最中心的特徵對玩家來說是否有價值。我們只能希望是。

對我而言,那些特徵和它們被實證的程度,應該作爲項目的驅動力。從根本上說,這意味着接受它們每一個都可能被多次重製的事實。以我的經驗,不要對實現可能性少於60%的特徵做計劃。

更大的挑戰:我們必須接受爭論的存在。它有助於迫使遊戲設計師在一開始就確定特徵。這樣當被告之某個特徵不可行時,他們就能很快提供提供實現方法。這使設計師具有一定程度的測試自主權,並且爲任何討論設置可行性標準。

最後,我們必須讓投資方發揮一定的影響力。爲此,在大測試完後製定一個里程碑式的階段性目標是明智的。這樣你就更加了解你的項目進展到什麼程度。因此,如果有必要,這時候也是最適合討論變化的時候——比如增加預算、調整規模或者取消特徵等。

變化也是我們不太討論的另一個話題。但如果我們能嚴肅地對待制作風險,我們就總會考慮到那一步。在紙上看起來各種牛逼的東西,可能根本實現不了。儘管如此,太過冒險仍然是不可原諒的錯誤。

篇目4,分享改進團隊信息交流和溝通狀況的6種方法

作者:Lee Winder

對於一支優秀的運作和生產團隊來說,成功的交流和溝通是最重要的因素之一。如果員工,管理者,發行商以及其他參與遊戲開發的人員之間缺少了足夠的交流,這個團隊的表現就會很成問題了。

如果開發者對自己的工作缺乏自信,不理解自己的工作對於遊戲的整體開發有何意義,甚至不知道自己的存在價值在哪,那麼這個開發團隊只能生產出一些劣質產品,並且團隊氛圍也將始終籠罩在相互猜疑和摩擦之中。如果溝通不暢,我們很可能要爲因此而犯下的錯誤付出慘痛代價。

以下是我過去幾年在團隊中試過的改善交流方法:

團隊百科

team wiki(from gamasutra)

team wiki(from gamasutra)

建立一個團隊百科文庫去收集信息和內容,這是一種長久存放文件和信息的好辦法,但並不適合保存那些短期內容易失效的信息。

如此,團隊成員便能很容易地在百科文庫中找到開發過程中的各種相關文件,並且如此也不會影響團隊的日常工作。雖然成員們仍必須持續去尋找一些長期有效的信息,但並不需要定期搜索新信息。

不過這種方法雖然很有用,但卻不能有效地改善團隊成員的日常交流。

博客

我們有一個團隊博客,每週更新兩三次,更新內容是關於日常工作的討論,遊戲截圖以及遊戲開發現狀等。這種方法讓我們能夠更簡單地向團隊成員傳達信息,但是前提是,所有成員都必須進入博客中才能進行團隊交流。

討論可以呈現每個員工的工作生活,並以此衡量他們的工作,不過這麼做並不能用於評估項目成果。

微博

利用內部微博工具如Yammer(商務社交網絡和交流平臺)或Status.net(開源微博服務)能夠快速公開關於自己的工作,遇到的問題或者其它關於團隊信息。微博最厲害之處便在於這是一種很好的交流工具,人們可以頻繁地更新內容,並接受關注者的反饋評價。

但是直到今天,利用微博去調動團隊氛圍仍然是我的一大薄弱點。

並不是因爲這個方法不好,而是我很難找到一個平臺去迎合絕大多數用戶,並且我也很難判斷哪些信息是用戶所不願意看到的。但如果你找不到更好地篩選有益信息的方法,那麼你所公開的內容可能只會被當成沒有幫助的垃圾信息,根本不可能幫助改善團隊溝通氛圍。

展示牆

展示牆真的是一個很有幫助的工具,特別是在統間式辦公室裏,但人們往往容易忽視這面牆的作用。在工作室裏設置一堵顯眼的展示牆能夠更好地在團隊中傳遞一些重要信息。

例如,我現在所參與的遊戲開發團隊有一個很明確的時間安排計劃,包括髮行時間,開發進度,功能特點描述以及目標要求等。除此之外我們還設有一扇“衝刺牆”,這是最能夠展示我們工作狀況的地方。而這扇牆的位置更是非常重要,但我們卻將其設置在巨大的電視,轉動電扇以及衆多服務器之間,這削弱了它的影響力。儘管如此,我還是認爲展示牆的重要性不容忽視,因爲我們確實很難找到一個比它更折衷,更容易讓人親近的方法了。

晨會

晨會能夠幫助我們更好地在團隊中傳遞信息,但是爲了體現出這種會議的真正價值,你必須遵循一些規則。

儘可能地縮小開會人數。我曾經參加過多次有20多人蔘與的“站立會議”,但是我卻發現大多數參會者都面露疲倦或者只是無聊地等着自己的發言。如果開會人數太多,你便很難準確地將所有重要信息傳達給全部參會者。

讓參會者集中注意力。如果你的會議是讓少數人分別闡述15分鐘的執行細節,那麼其他參加者肯定會迫切希望早點結束會議回到自己的工作中。

不要把會議變成一種彙報過程。如果每個人在會上都是面向着一個人(特別是經理級任務)作彙報,那麼請暫時把那位經理請出會議室,而讓彙報者面向所有人說話,這樣參會者才能更容易地理解他的內容。

重要事記評論

與玩遊戲一樣,我們總是喜歡討論哪裏做得好,哪裏做得不好,或者怎麼做才能變得更好。但這種方法若使用不當,很容易變成無足輕重的討論。

而如果這些討論缺乏焦點,或者就像是一個普通的時間表,人們也許就不知道如何發表評論,甚至不知道自己到底在做些什麼了。你必須確保人們能夠輕鬆地做出評論並應對任何糟糕情況。

但是如果使用得當的話,我們便能夠從這些評論中看到需要改進的內容以及一些有價值的信息。除此之外這還能夠讓評論者看到自己對於開發團隊的幫助和貢獻,讓他們知道自己的想法的重要性。

結語

由管理者制定時間表並交給開發者執行的日子已經一去不復返了。

提前讓幾個開發人員聚在一起討論並規劃工作能夠讓團隊成員更加清楚自己的工作職責。

並且,如果成員們在如何執行工作,如何分配任務以及安排時間方面擁有發言權,這會對團隊內部的信息傳播以及開發工作更加有利。

篇目5,如何消除遊戲開發過程中的浪費

作者:Harvard Bonin

最近我們在網上經常會看到許多在一般軟件開發時很受歡迎的項目管理技術,但它們卻很少用於遊戲創造中。儘管Scrum已經有力地推動了遊戲製作,但是還有許多技術仍然被忽視。這是一種不幸的情況,因爲來自傳統和敏捷方法的其它方法也能夠應用於我們的產業中,並幫助我們創造出一些正面的結果。

在本文,我並不會詳細解釋精益六西格瑪。相反地,我將專注於精益六西格瑪的核心原則並分析如何將其應用於我們每日的遊戲開發中。

精益六西格瑪

Lean Six Sigma(from baidu)

Lean Six Sigma(from baidu)

精益六西格瑪是名爲“精益”和“六西格瑪”的兩種項目管理技術的結合。

精益:專注於在所有活動中有效地傳遞消費者的價值。任何不能爲消費者添加價值的活動都必須果斷刪除。

六西格瑪:專注於從過程中刪除所有瑕疵和變量。

換句話說,這兩者都是爲了消除一些“浪費”。在精益六西格瑪中,浪費被定義爲“muda”。這是一個日文單詞,意味着“無價值的;無用的;閒置的;多餘的;廢棄的;消耗的;浪費的。”浪費可以以任何方式出現。停工時間,重做,不匹配的功能需求,過度交流等等。精益六西格瑪明確了8種類型的浪費(有時候是7種)。

精益六西格瑪中存在許多潛在的理念。完整的開發項目是圍繞着這一框架中的技術,等式和工具而盡心,但是因爲內容太泛了,我們難以在本文中進行探索。如果你進一步探索的話可能會注意到許多理念直接應用於製造業中。同時其核心原則也對遊戲製作帶有直接且正面的影響。

爲什麼會出現浪費問題

根據我的經驗,浪費元素是團隊最大的焦慮來源。最重要的便是浪費時間。在所有領域中努力清除浪費是製作人和項目管理者必須擁有的一種心態。許多製作人認爲他們的主要角色便是領導整個項目。他們認爲自己就像騎着馬位於軍隊最前方的將軍一般,朝着敵軍方向揮舞着劍並高喊“衝啊”!也許他們的角色帶有這樣的元素,但這卻是非常有限的。一支帶有經驗的團隊可能已經知道如何有效工作,而製作人如果想有效利用時間就必須專注於如何避免浪費而不是引導着團隊朝目標盲目前進。有時候製作人必須讓團隊做其最擅長的事並花時間去消除阻礙發展的內容。

兩大不可饒恕的罪行

在我的職業生涯中,我曾經遇到許多充斥着問題的項目。實際上,我的所有項目都是困難重重。當完成這些項目時,團隊經常會轉向事後檢查並照亮製作過程中引起的許多問題。最頻繁且最具影響的關注點通常是圍繞着“交流問題”和“偏差的期望”。

交流問題:團隊經常會抱怨他們不知道項目的目標,日期,各部門的任務或管理者的期望。這一問題似乎會出現在每一個項目中。幸運的是我們能夠通過紀律,技術和透明度承諾輕鬆解決它。最重要的是,製作人和項目管理者必須清楚這一問題,因爲這是浪費時間的主要根源。

偏差的期望:當創造功能,圖像,代碼等等內容時,在“完成”的定義方面,管理層和內容創造者總是不能實現同步。這種矛盾將導致更頻繁的重複勞作。產品擁有者,利益相關者和所有者(遊戲邦注:創造性控制的唯一來源)都必須清楚地與所有內容創造者進行溝通。

這兩個問題間的共性就是“浪費”。它們都有可能導致時間的浪費。時間是產品開發中最有價值的資源。因爲精益六西馬格是關於消除浪費,所以它將能夠有效應用於遊戲開發中。

TIM WOODS:8種類型的浪費

在精益六西格瑪中有8種類型的浪費。

以下是一些學術定義:

T—-轉移:移動人們,產品和信息

I—-庫存:儲存零部件,組塊,需求文件

M—-動作:彎曲,轉向,觸及,提升

W—-等待:爲了零部件,信息,只是和設備而等待

O—-生產過剩:創造出超過需求的內容

O—-國度加工:更嚴格的容差或更高級的材料(超過標準)

D—-瑕疵:重做,廢棄,錯誤的文件

S—-技術:未充分使用的功能,刪除未充分訓練的功能

來源:http://www.isixsigma.com/dictionary/8-wastes-of-lean/

想想你自己的每日遊戲開發體驗。這些對於浪費類型的定義是否能夠幫助你揭露項目的低效能?以下是一些例子:

轉移:資產轉移是否花了太長時間?是否存在創造時間太過冗長且帶有瑕疵?

庫存:是否投入了太多時間於隔天就會改變的冗長的設計文件中?是否存在太多範圍外且會導致團隊分心的未修剪理念?

動作:環境的設置是否會阻礙交流?致力於高度迭代功能的人們是否坐在一起?工具是否容易使用且有效?他們的工作空間是否有利於高效工作?

等待:團隊是否不斷地等待着其它部門完成工作?他們是否經常出現空閒?

生產過剩:美術師是否創造出不符合最終要求的資產?這些資產是否有用?在明確要求前某些部門是否早已趕超其他人?

過度加工:是否創造出比要求更加詳細的資產?他們是否過度優化那些對消費者沒有多少意義的功能?

瑕疵:代碼是否伴隨着漏洞?是否是可擴展的?最終工作是否與預期相匹配?資產的創造是否匹配引擎功能?他們的工作是否符合預期標準?

技術:任務是否與團隊成功的技能組合相違背?PHD是否致力於GED能夠完成的任務?或者相反?

TIM WOODS:應用

理論和概念很棒,但是它們沒有多少好處,除非能夠應用於開發過程中的實際活動中。以下是我的特定遊戲列表(未完成的),團隊們可以將精益六西格瑪整合到其中並嘗試着去消除浪費。沒有任何方法能夠解決所有的項目問題,但是如果將其全部整合在一起便能帶給開發團隊巨大的幫助。當然了你也可以添加更多內容。

進行每日站立會議:儘可能簡短,10至15分鐘的站立式會議非常有用。這能夠促進成員間頻繁的面對面交流,並且不需要耗費太多時間。較少且不準確的交流便是一種浪費。

用風險會議取代每週製作人狀態審查會:在每週的狀態審查會中,所有人將圍繞着一間屋子提供一些更新內容,這是一點幫助都沒有的。在定期的交流和報告中,成員們已經瞭解了相關信息。我們需要的會議是每個製作人能夠提出他們的前三個項目風險並向羣組請求指導。無用的會議是一種浪費。

在實體項目空間突出張貼目標/日期/價值等內容:滲透式交流能夠確保所有團隊成員都能夠清楚項目的宏觀目標。通過貼海報等方式去幫助團隊成員牢記目標。面對面的交流是最有效的迭代方式。製作人必須採取任何機會向團隊成員和利益相關者傳達目標期待。不統一的團隊成員會創造浪費。

坐在附近的人能夠致力於高度迭代且相互協作的功能:團隊成員致力於統一的功能,特別是未知且具有探索性的功能對於他們的成功很重要。避免他們無需走太多路便能夠與同事進行溝通。功能越陌生,他們越能近距離共事。較少的交流將會創造浪費。

面對面頻繁地交流轉折點和項目目標:在牆上張貼目標和價值雖然很有幫助,但面對面的交流更加重要。爲了得到一封電子郵件的回覆可能需要花費1天以上的時間,但面對面討論將是實時進行的。製作人和產品擁有者必須把握任何可能的機會向團隊成員和利益相關者傳達目標期待。通過電子郵件或聊天工具而造成的交流延遲便是一種浪費。

頻繁地交流創造性目標:與截止日期一樣,我們必須持續地分享創造性目標。通常情況下,“完成標準”是取決於創意總監或產品擁有者。他們必須頻繁分享自己的要求。誤解創造性目標將會創造浪費。

確保所有內容創造者都清楚完成標準:產品擁有者的一個主要角色便是傳達他們對於功能的創造性要求和指令的期待。更快地做出慎重的決策很重要。我始終都堅信着美國海軍陸戰隊的:70%規則。如果你認爲你的計劃擁有70%的可行性,你就必須儘快地去執行它。如果它是錯的,你則可以不斷地調整它。我曾與許多不斷等待着“完美”計劃的創意總監合作過。紙上談兵只會創造出浪費。

在所有相關項目中推動透明交流的價值非常重要:我曾經待在一些牢牢握着項目核心數據的公司。他們總是認爲團隊不能處理壞消息或者他們會失去一些人員。但是公開與誠實不僅是一種道德,同時也是一種良好的商業意識。團隊必須獲得最佳信息才能幫助自己更好地朝着目標前進。在大多數情況下保持祕密是一種錯誤的做法,將有可能引起團隊的反抗。糟糕且極少的交流會創造浪費。

優化價值流:項目管道可能是項目中最大浪費的創造者。內容創造者必須能夠儘快地回顧並迭代他們的工作。破損的結構,較長的資產轉移都有可能限制團隊完成工作的能力。較長且破損的價值流可能創造浪費。

鼓勵內容創造者去呈現臨時工作:沒有人喜歡呈現未完成的工作。他們會認爲評論者不會理解它最終會變成怎樣活着他們會因爲一些不相干的問題受批評。創造者和評論中必須創造這種信任。頻繁地評論迭代工作將能夠消除重做(浪費)。呈現臨時工作也能夠避免浪費時間。等到工作完成後在呈現出來將會創造浪費。

嘗試着消除創造性評論會議所創造的重做:這一點與前一點相似,然而理想的情況是沒有任何來自“官方”創造性評論會議的重做。這些工作應該在評論會議前便接受過評論和修改。評論會議應該是官方的“許可證”,而不是探索創意總監全新理念的會議。在我所致力的每一個項目中,內容創造者都會抱怨工作的評論時間太長了。這不僅會創造時間的浪費和重做,這對於所有參與者來說也是一大挫折。產品擁有者必須刪除評論,真正相信團隊成員。爲了這麼做,他們必須能夠清楚傳達要求和他們的期待。源自少有的創造性評論的重做將會導致浪費。

流線型化或刪除會議:如果你的團隊覺得會議無用,有可能是你未能有效地組織會議。你可以找到許多關於如何有效運行會議的內容。你必須準備好適當的會議議程,特定問題等等內容。人們都不是很喜歡會議並覺得它們只是在浪費時間。製作人必須學習各種關於組織有效會議的方法。會議應該是關於解決方法的集合,而不是重申所有人都清楚的內容。無效的會議只會創造浪費。

適當的環境下使用反挖掘代碼是有幫助的:並不是代碼的每一部分都必須帶有完美的架構。有時候團隊將通過親身體驗一個功能獲得更多好處,即使潛在的代碼很混亂。玩家經常在敏捷的狀態下遭遇失敗。這意味着團隊必須快速創造原因,如此他們便能夠儘快地進行迭代。反挖掘代碼將能夠幫助你更快地獲得一個實例功能。在功能被熟知前進行過度的設計和大量的系統創造可能導致浪費。

追蹤並解決開放式問題:團隊必須不斷追蹤圍繞着項目的開放式問題。應該優先解決帶有最重要引擎和期望值的問題。消費者最期待的功能應該被放置在最前方。開放是問題是項目的風險來源。

專注於消費者的需求:團隊必須保證他們是在爲消費者創造功能,而不是自己。未能與消費者需求相關聯的活動必須被刪掉。有時候人們會喜歡致力於自己所喜歡的項目,而不管終端用戶的價值。致力於與項目最終目標無關的功能只會創造浪費。

KAIZEN(改善)

最後,製作人的最大責任便是繼續探索保證項目順暢運行的方式。Kaizen也是一個日語單詞,即關於持續完善內容。製作人,產品管理者,利益相關者和內容創造者都必須不斷尋找完善他們工作工程的各種方法。這必須實踐於所有項目中,如此結果纔會在不斷的迭代中得到完善。

結論

就像之前所提到的,精益六西格瑪是包含圖表,等式,方法和技術的一個綜合型框架。團隊只需要理解獲得利益的原則便可。這不只是一個框架,還是一種心態。浪費是項目殺手。尋找方法去消除浪費是所有團隊都必須具有的一種心態。

篇目1篇目2篇目3篇目4篇目5(本文由遊戲邦編譯,轉載請註明來源,或諮詢微信zhengjintiao)

篇目1,5 reasons you want to work at King

By Jim Squires

Along with a handful of other notable press outlets, Gamezebo was recently given the opportunity to tour the Stockholm studios of King, the casual games giant behind titles like Candy Crush Saga and Farm Heroes Saga.

We learned a lot about the business of being a leading cross-platform developer, yet despite all of the facts and figures thrown our way, one learning stood out above everything else: King’s employees are happy. Not just “there’s press here, plaster on a fake smile” happy, but really, genuinely happy. After seeing how the day-to-day operates, it’s not hard to see why.

You’ll be home by 5pm. Like many employees in the games industry, the teams that make up King have a diverse background. It’s not uncommon to come across names and faces that had previously worked on AAA games production. Henrik Sebring, the lead producer on Pet Rescue Saga, was working on Ubisoft’s upcoming The Division before heading up King’s Malmo studio. And if you’ve ever worked in AAA games, there’s a dreaded period that every title seems to go through right before release – “crunch time.”

When you work in the AAA/retail space, there are hard deadlines that need to be met. This can result in 120-hour weeks with people living at the office, only stopping to collapse from exhaustion.

It’s a terrible reality, and it’s one that King doesn’t have to worry about. By working in the social/mobile space, King can set their own deadlines. Products are never final at launch, and if something isn’t quite polished enough, they can always move dates around. Because of this, you’ll always be home in time to enjoy quality time with your family.

Teams don’t compete, they collaborate. When a company has multiple teams working on multiple projects, all too often they see it as a competitive environment. Team A wants their game to sell better than Team B, and vice versa. It’s not an environment that’s conducive to making your game the best it can be. And while the different teams at King admittedly want to see their product become the next Candy Crush for the company, King’s entire structure is designed around collaboration and sharing.

How so? While King operates a number of studios, each focused on their own games, they’ve made an effort to keep all of those studios in Europe. There are two very smart reasons for this: everyone will be working in the same time zone, and no studio is more than a quick flight away. Let’s say you’re working on Farm Heroes Saga in King’s London office. You might have an idea that you’d like to add into the game, but you’re not sure how it will perform. Since it’s a match-3 game, you pick up the phone and call the lead producer on Candy Crush Saga in Stockholm to see if they’ve ever tried it. The next thing you know some Candy Crush folks have just landed at Heathrow to spend a few days with you, fine-tuning the idea with your team to see if it can work.

The corporate culture isn’t about your game doing well – it’s about King doing well. That means everyone is on the same team, regardless of the studio and game you’re tied to.

Failure is totally an option. Making games is a hit or miss proposition in the most literal sense possible. Some games will be hits, more games will be misses. King both gets and embraces this fact. They have a team in Stockholm whose entire job is to dream up ideas for new games. Let that sink in for a minute – King has professional daydreamers. When they hit on a formula that they want to try, they make a web-based game for King.com – their “tournament” site that doubles as a testing ground for new ideas.

If a game performs well on King.com, they’ll know its future in a matter of days thanks to the magic of analytics. I won’t bore you with the details, but there’s a formula that will tell King whether or not a game should graduate to “Saga” status and get a deep-and-detailed remake for Facebook and mobile. Very few games get to this point – and that’s ok. Trying and failing is how we learn; this is a fact that’s as applicable to a games company like King as it is in our own lives.

Studios don’t have more than 80 people. Remember being in elementary school, how you knew all of the names of the kids in your grade, and the grades above and below you? Welcome to King. While the company is growing at a breakneck pace, they’re committed to keeping individual studios small enough that everybody knows everybody else. We were told that no studio should have more than 70 or 80 people. Why? I suppose this loops right back to the earlier mentioned positive: the culture of collaboration. If you know who everyone is and what everyone does, there are fewer roadblocks to saying “hey Lars, come take a look at this new level I’m designing.”

This muffin. I didn’t ask them about what their day-to-day catering is like, but if this muffin is any indication, it’s insanely good. The white part was kind of a white chocolate/cheesecake thing, and the inside was like a chocolate soup. It was so gooey that I eventually had to use the paper sleeve to squish it into a taco.

Walking through the studio at 9am, I saw more than a few folks gathered around a pretty great breakfast spread, taking a quick meeting as they enjoyed some communal food time together. And really, it’s this vibe that sums up what King is all about. This doesn’t seem to be the sort of studio where you rush in and tie yourself to your desk. It’s about good working relationships with the people around you. You collaborate; you listen. You enjoy a good breakfast. And maybe, just maybe, you make some amazing casual games in the process.

篇目2,The keys to a company culture that works

by Christian Nutt

In a heartfelt talk at GDC Europe, Harald Riegler, co-founder of Sproing, frankly discussed the challenges and advantages of shaping a company culture that leads to respect and success.

“The right company culture will bring really good things out of people where you didn’t expect they existed,” says Riegler, who manages a company of 65 that works on free-to-play and console games in Austria.

Unfortunately, he says, forging the right company culture is a challenge — but it’s crucial to shape it, and that every team member understand it.

“That culture will largely decide the success of the studio or team,” says Riegler. “A bad company culture can even destroy teams completely.”

While “the latest million-selling management style” books offer advice, Riegler was dismissive of trends and tricks. “The really important thing is… that it’s entirely about human interaction, the characters of the humans, and their behavior,” he says.

“A good company culture is built on some lasting principles — principles, to me, means more than a set of rules, it’s a foundation on how you live and how you act,” he says.

“Working at it day by day, week by week, year by year is required to improve your company culture,” he says, however, so be prepared to commit fully to change.

Here are his principles:

Respect

“To lead any group of people, you need an innate respect for people,” says Riegler. If you don’t respect everyone you work with, he says, “I feel you’re doomed to fail from the outset.”

“If you feel superior to people,” he says, that comes across. “Body language is most of our communication.”

“Such respect leads to an environment of trust, and trust is really important because only in an environment of trust can you address tricky things. You can bring stuff out into the open that nobody wants to talk about,” says Riegler.

Lead by Example

“Every [parenting] book says that if you want your children to do something, you do it yourself,” says Riegler. This applies to companies, too, he says.

And the reverse is true, too: “If you don’t want somebody to do something, don’t do it yourself,” Riegler says. “Never ask anybody to do something you’re not prepared to do yourself.”

Accountability

“This is where it gets really tricky,” says Riegler.

“It’s often confused for just holding your subordinates accountable,” he says. But as a manger, Riegler says, “the only way, in my opinion — and that’s something I absolutely believe in — you an introduce accountability into organizations by making yourself accountable first.”

How do you do it? “You have to tell people what you’re setting out to do,” he says. “You have to be willing to benchmark yourself.” And then finally, “you have to be prepared to stand there and say just how successful you have been, which isn’t easy, because rarely do you achieve everything you set out to do.”

Maturity

“Maturity does not mean that you’re super-experienced, that you’re an elder statesman,” Riegler says. “Maturity to me is the ability to self-reflect and have a clear understanding of what your strengths and weaknesses are, and what you should be working on, and where you should grow.”

Unfortunately, he says, “a lot of people don’t really do well here, because it requires an honest reflection on your personality, and that can be uncomfortable.”

However, he says, bear in mind that “the best contributors can understand the challenges your team is up against,” and having that self-honesty and self-reflection is key for that — it’s not just about improving oneself and having a better outlook; it has a meaningful effect on the team and the business.

Then again, he says, there are divas, backstabbers, and power players. “Beware of all these kinds of characters; they’re very damaging,” Riegler says.

Fun

“I think fun is really important,” he says. People could probably work in other, less interesting industries for more money, he says, so in the game industry, fun is key.

It isn’t, however, an environment that isn’t professional, or one that’s lax, he maintains. “Sometimes it’s perceived as laxness — young people confuse fun with a lack of seriousness or ambition,” Riegler says. So have your foosball tournament, but make sure the goals of the company are clear, too.

On the other hand, “maturity does not contradict with being crazy” — being weird is part and parcel with the culture of the game industry, he argues, so be open to it.

Freedom

“Freedom to decide how to solve a task,” Riegler says, is key — “not being micromanaged.”

“To come and go at flexible hours, to take some time off to deal with family issues and what have you,” is very important. “Freedom leads to a lot of autonomy of every person, and an environment of trust supports such an autonomy, and autonomy leads to motivated people,” Rigeler points out.

Honesty

This is one of the most important elements, but also one of the most challenging. “If something went wrong, admit it. Don’t be afraid,” Riegler says. “You have to a culture where admitting failure is accepted.”

What won’t work, he says, is “a blame culture.” When you have one of those, “a lot of stuff that is important will not come out in the open,” Riegler says.

Why don’t people want to be honest? “It’s all because people are so afraid to deal with failure,” he says. But you have to recognize that “we all screw up every once in a while.”

If there’s a culture of open and honest communication, “people on the team who are smart will spot you are screwing up, and they will point it out and they will stop you from costly mistakes.”

But he did have one warning: if people are always brutally honest about what’s not working, “you may fall into the trap of becoming hypercritical,” which leads to pessimism. “But you can’t lose faith.”

Awareness

“The common awareness in every person that the culture is important and the way we interact sets the culture for success is really important,” says Riegler. In other words, “Everybody has to understand these principles and live by them.”

What you have to recognize is that “everybody has the ability to improve.” However, he says, “You can’t just go out there and tell people to improve… that’s not how it works. It’s a really slow process.”

Consequence

“These principles are not worth much if they are not enforced by everyone,” says Riegler. This is from the bottom to the top of the organization.

“If you tolerate someone ignoring the principles in the organization, what does that mean, that you can get away with that? Then people will understand they are not really principles, and that will be very harmful,” he says.

Final Thoughts

At companies without an open culture, he says, “a lot of times people are impressed by people who speak out in a meeting and say ‘This is going wrong,’ and you wonder how they do it, and that’s because the culture makes this stuff hard to bring out into the open,” he says. But if you shape a culture built on mutual respect, accountability, and communication, “more people can do that, and everything improves.”

“Your ability to self-reflect on what your strengths and weaknesses are will make you really valuable,” he says. “You need to find like-minded people and you can build teams that can survive in our day and age.”

篇目3,Managing risk: The creative gamble

by Florian Schwarzer

Here’s a nightmare: Build the best team you can, work hard for two straight years, release a well-crafted game – and watch it fail in the market.

Here’s the crazy thing: We work in an industry where that nightmare comes true somewhere every day.

Surprisingly, we don’t talk about this very often. Even those of us who carry ‘business responsibility’ over our games seem to avoid the topic. There’s valuable discussion of development processes or leadership strategies, but little time is spent on how to deal with the great volatility of our products. Often, you’ll get the impression that we’re improving at releasing games on time – but not at ensuring their success.

Can it be that this is because what is at the heart of a successful game is radically different from what makes or breaks other software?

For a long time, our project management has looked to IT for its cues, and what we learned from there has enhanced our way of making games. Still, I would argue that there are limits; challenges we have to face that other software managers will never see. Most of them start with two words: game design.

THE SMALL DIFFERENCE

Games try to entertain. This sets us apart from traditional software, like eshops. It also means that we run the same risk as any movie or novel: Our audience might just not find the game appealing. Researchers call this ‘creative risk’.

As managers, we usually think of risks as threats to be minimised, or, in the worst case, mitigated. One has to wonder: Is the same possible for the risk of people not having fun?

Fundamentally, a big part of what makes something entertaining is down to curiosity. We like new things. This will be news to nobody – pretty much every game tries to offer some degree of novelty to its players. We search, we build, we advertise fresh new features, whether in an experimental title, or a sequel.

ON GREAT GAMBLES

There’s a problem, of course: What may seem original to me, can feel trite to you. Even individually, it can be very difficult to predict whether a game will meet our tastes before we try it. For a whole audience, it becomes effectively incalculable. Just consider how often century-old Hollywood gets it wrong.

Intuitively, this means that it’s a bad idea to take a lot of creative risks. After all, if we release a product that’s different from anything that’s come before, there’s a good chance it’ll miss everyone’s tastes, right?

True, but our players still really like new stuff. Games like Portal or Wii Sports show that if you take the risk, and manage to connect to your audience, the reaction can be tremendous. Creative risk is speculative – its outcomes can be negative or positive.

Of course, it is possible to build an entertaining game around a relatively conservative concept. Take StarCraft II, a careful extension of a well proven game. Then again, take the guitar game genre. There, we have a group of very well executed titles that got too conservative – and saw their audience move on. Taking no creative risks is a risk, too.

In the end, no matter what kind of game you build and how well you build it, all you get is a roll of the dice. The game’s USPs, the very things that can make it succeed, will carry the greatest, most central risks. Accordingly, there’s nothing we should take more seriously in our plans.

DOES IT WORK?

Obviously, if we want to help our game designers deal with risky features, we should help evaluate them. Just as obviously, it’s a good idea to make these features testable as quickly as possible.

The good news here is that every discipline involved in the creation of games has found its own ways of quickly prototyping and testing ideas. Based on those, it seems pretty easy to set up whole test plans. Say, you start out by testing a paper draft of a new feature, graduate to UI mock-ups, logic prototypes, and eventually release a fleshed-out version on a beta server. Such plans are hugely attractive. They reassure the team and stakeholders. Also, they don’t work.

Partially, it’s down to time. Way too often does a team invest into elaborate tests, only to discover that there’s no room to fix what is broken.

Things can get even worse, though: User tests, by their very nature, produce messy data. It’s easy to come to rivaling interpretations, and thus solutions. If a major stakeholder subscribes to such a differing view, the game designers may quickly lose control over their own concept.

THE LIMITS OF AGILE

To avoid all this, it seems sensible to integrate large-scale prototyping more tightly into the development process. To my surprise, when I began consulting Agile experts on this, they told me it was a bad idea.

We all know the basic artifacts of Scrum and XP. You’ve got a backlog, with the most important stuff up top. You’ve got a sprint, during which a certain amount of stuff is supposed to get done. You’ve got a working increment, which grows sprint by sprint.

What a lot of us miss is that, as far as ‘traditional’ Agile is concerned, that’s it. No milestones, no gates. After the first few weeks, the most important stuff is in. Then, with every sprint, the team will be able to release something better.

Following that logic, it’s a waste to spend a sprint building a prototype that may get discarded or even lead to a rework of stuff that’s already done. Setting up whole plans full of that? That’s missing the point.

For B2B application development, the environment Agile was built for, that’s true. There, it is possible to ensure that what is at the top of the backlog is also the most valuable for the user. In games dev, that’s the very thing we often can’t be sure about.

THE ROOT CAUSE

What this means is that to accommodate the creative risks of our games, we must tailor our processes in ways unique to our field. We don’t know whether our most central features are valuable to the player. We only hope so.

To me, those features – and the degree to which they are proven – should drive a project. At the root, this means accepting that each of them will be reworked many times. In my experience, one shouldn’t plan with less than 60 per cent of feature-specific contingency here.

More challenging: We have to acknowledge that there will be controversy. Here, it can help to have the game designers prepare while they are defining the features in the first place. Ask them to name ways by which to tell that the feature doesn’t work. It provides the designers with a degree of ownership over the tests, and sets a reliable yardstick for any discussion.

Finally, we have to give our stakeholders a fair chance to take influence. For this, it’s sensible to set milestones after major tests. There, you will have learned something important about your project. Thus, if necessary, it’s the ideal time to discuss changes – whether that means budget extensions, scope adjustments, or the dreaded cancellation.

That’s another thing we don’t talk about. But if we take creative risk seriously, it’s a step we should always consider. It’s always possible that what sounded fun on paper doesn’t really work out. Pressing on nonetheless – now that’s inexcusable.

篇目4,Opinion: Communication Is Key

by Lee Winder

Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers, and anyone else involved in the game development process, a team will not perform at it’s best.

If developers do not feel confident in the reasons behind their work, if they don’t fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch.

But communication is one of the most difficult things to get right but so costly when it’s done wrong.

The following are methods I’ve used over the years to try and improve communication within the team. I’d be very interested to hear other ways people have tried too!

Team Wiki

Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information.

Documentation on team processes (getting the latest build, creating submissions, setting up PC’s etc.) is usually the kind of information that finds a home on a wiki, and while it’s useful, it’s not something that affects the team on a daily basis. And as it requires people to physically search for the information in the long term people don’t bother looking for new information on a regular basis.

As a result, the Wiki is useful but doesn’t actually improve the day to day communication on a team.

Blogs

We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screenshots or letting people know the state of the project. It’s a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going.

Discussions can take on a life of their own, which is actually a good way to gauge buy in into a project but can’t be used to judge the success of the process.

But you’d be amazed how many people don’t have any kind of RSS feed reader set up…

Micro-blogging

Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they’re working on, problems encountered or general team information. The best thing about micro-blogging is it’s push communication style with people’s updates being automatically feed to clients, which people can update as much as they want (I usually recommended at least twice a day).

But so far I’ve had very little success with micro-blogging tools in a team environment.

Not because the idea was bad (when it worked it worked well), but I’ve yet to find a service where the official client is anywhere near usable and able to filter out the information people don’t want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do), it either becomes an information overload or a sea of noise, neither of which improves communication.

Wall Displays

Walls are valuable real estate, especially in an Open Plan office, and I’ve rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team.

As an example, on my current project we have the entire timeline of the project (it’s only a short one) with dates/deliverables clearly indicated, a ‘where we are right now’ marker and a description – feature by feature – of what is required for a given milestone.

Next to that, we have our sprint wall, which is our most ‘live’ wall display. But position is key, and in our case, the sprint wall’s impact on the team is reduced due to it’s rather awkward position between a big TV, a constantly spinning fan, and quite a lot of server machines. But I did say wall space is valuable real estate, and it’s always hard to find a compromise between distance from team and accessibility.

Morning Meetings

Morning meetings are one of the best ways to push information across a team, but I’ve found that you need to follow a few rules to make them really valuable.

Keep the groups small. I’ve lost count of the number of 20+ people stand-up meetings I’ve seen where the majority of the ‘participants’ are looking bored or simply waiting for their turn. If your groups are not small, the information is less targeted and much less relevant, meaning more information is lost than actually passed around the team.

Keep them focused. There is nothing worse than 1 out of the 6 people speaking for 15 minutes about the most intimate implementation details, leaving everyone else itching to get back to their seats to carry on working.

Don’t make them reporting sessions. If everyone is talking at a single person (usually their manager), take the manager out for a while and get people used to talking to each other as it makes it much more likely for people to take in what is being said.

Milestone Reviews

I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong, and what we can do better next time. But it’s easy for these to be less than stellar if not approached in the right way.

If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You’ve also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will).

I’ve found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard.

Sprint Planning

The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there’s good reason for it.

Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team.

Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it’ll be done by is vital to spreading information about the project and the work being done.

So those are a couple of methods I’ve used to try and improve communication and information across the team. I’m sure there are plenty more (and I’ve tried a few which have been colossal failures) so what methods have you used and how well did they work out?

篇目5,The Elimination of Waste: Lean Six Sigma applied toward Game Development

by Harvard Bonin

These days one must only search online to find many project management techniques that are prevalent within general software development but are not utilized often in game creation. While Scrum has made a strong push into game production, many other techniques remain on the sidelines. This is unfortunate since other methods from Traditional and Agile methodologies can be applied to our industry and could help yield positive results.

In this article I will not explain Lean Six Sigma in detail. There are plenty of materials available if you’re interested in pursuing further. Instead, I will focus on the core principles of Lean Six Sigma and show how it can apply to everyday game development.

LEAN SIX SIGMA PRIMER

Lean Six Sigma is a combination of two project management techniques called “Lean” and “Six Sigma”.

Lean: Focuses on delivering customer value efficiently above all other activities. Any activity that does not add value for the customer is removed from the process.

Six Sigma: Focuses on removing all defects and variation from the process.

In other words, both are seeking to eliminate “waste”. In Lean Six Sigma terms this waste is defined as “muda”. This is a Japanese term popularized by Toyota and means specifically “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”. Waste can appear in many ways. Idle time, rework, mismatched feature requirements, under and over communication, etc. Lean Six Sigma identifies eight (sometimes seven) types of waste.

There are many concepts underlying Lean Six Sigma. Entire development projects have been built around the techniques, equations and tools available within this framework but they are much too involved to explore in this short article. If you explore further you may notice that many of the concepts apply most directly to manufacturing. While this is true the core principles can still have a direct, positive impact on game production.

WHY WASTE MATTERS

In my experience, wasted opportunities are the single largest source of angst on teams. Wasted time, most of all. Continually striving to remove waste in all areas is a mindset that producers and project managers must develop and embrace. Many producers think that their main role is to lead projects through guidance, task-forcing and sheparding. They believe that they are like a general on a horse in front of an army, pointing their sword towards the enemy and yelling “charge!” While the role can have these elements, it’s shortsighted and limited. An experienced team probably already knows how to work well and the producer’s best use of time might be to focus on waste rather than march them toward a goal. Sometimes producers must let the team do what it does best and spend their own time bulldogging the blockers out of the process.

THE TWO DEADLY SINS

Throughout my career I’ve experienced many problem ridden projects. In fact, all my projects have been difficult. When they are completed the team usually turns to the post mortem to help shine a light on the many issues the production experienced. The the most frequent and impactful concerns often revolve around “communication problems” and “misaligned expectations”.

Communication Problems: Teams often complain that they weren’t aware of the project goals, dates, inter-departmental tasks or management expectations. This issue seems to arise on every project. Fortunately, it’s one that is the most easily fixed through discipline, techniques and a commitment to transparency from all involved. Most of all, producers and project managers must be acutely aware of this issue since it’s a main source of wasted time.

Misaligned Expectations: Often management and content creators are not in sync regarding the definition of “done” when creating features, art, code, etc. This misalignment leads to more rework on titles than most any other issue. The product owner, stakeholder, owner, etc. (whoever is the single source of creative control) must be clear in this communication to all content creators.

The commonality between these two issues is “waste.” Both issues are instrumental in creating wasted time. Time is the single most valuable resource available to product development. Since Lean Six Sigma focuses on waste removal (time creation) it’s particularly useful when applied to game development.

TIM WOODS: THE EIGHT KINDS OF WASTE

There are eight kinds of waste defined in Lean Six Sigma. An easy mnemonic to recall these is “TIM WOODS”.

Here is the academic definition.

T Transport: Moving people, products & information

I Inventory: Storing parts, pieces, documentation ahead of requirements

M Motion: Bending, turning, reaching, lifting

W Waiting: For parts, information, instructions, equipment

O Overproduction: Making more than is immediately required

O Over processing: Tighter tolerances or higher grade materials than are necessary

D Defects: Rework, scrap, incorrect documentation

S Skills: Underutilizing capabilities, delegating tasks with inadequate training

source: http://www.isixsigma.com/dictionary/8-wastes-of-lean/

Consider your own daily game development experience. How may these types of waste definitions can be applied to help uncover your project’s inefficiencies? Here are some examples:

Transport: Does the transfer of assets take too long? Are build times lengthy and defect ridden?

Inventory: Is too much time invested on lengthy design documents that change the next day? Are there too many unpruned ideas out of scope that distract the team?

Motion: Is the environment set up to hamper communication? Are people working on highly iterative features physically sitting together? Are the tools accessible and effective? Is their workspace conducive to doing effective work?

Waiting: Is the team continually waiting for other departments to complete their work? Are they often idle?

Overproduction: Are the artists creating assets without confirmation of the end requirements? Will the assets be used? Are departments running ahead of others before requirements are specified?

Over processing: Are people making assets that are too highly detailed than what is required? Are they “gold plating” and polishing features that are the least impactful or important to the customer?

Defects: Is the code ridden with bugs? Is it extendable? Does the resulting work align with the expected work? Do the assets created align with the engine capabilities? Does the work match the expected grade?

Skills: Are tasks mismatched with the skillset of the team member? Are PHDs working on tasks a GED could accomplish? Or vice versa?

TIM WOODS: APPLIED

Theory and concepts are fine but they have little benefit unless they are applied toward tangible activities during development. Below you’ll find my game specific (incomplete) list of actions teams can perform to embrace Lean Six Sigma thinking and try to eliminate waste. None solve all project issues alone but taken collectively they may help teams significantly. No doubt you can add many more.

Conduct daily stand-ups: Short, ten to fifteen minute, well run Scrum stand-ups are useful. They promote face to face communication on a frequent basis and don’t require a large time investment. Infrequent and inaccurate communication is wasteful.

Replace weekly producer status meetings with risk meetings: Conducting a weekly status meeting where everyone goes around the room to provide updates are generally useless. The information should have already been known through regular communication and reports. Focused weekly meetings where each producer brings up their top three project risks and asks for guidance from the group can be very useful. Useless meetings are wasteful.

Prominently post goals/dates/values within the physical project space: Osmotic communication envelopes the team to ensure that no team member is confused about the macro goals. Put up posters, monitors, etc. to help keep the goals on the forefront of the team’s mind. Face to face, personal communication is best and the most iterative. Producers must take all opportunities to communicate the goal expectations to the team and stakeholders. Uniformed team members create waste.

Seat people working on highly iterative and collaborative features near each other: Team members working on the same feature, especially if it’s unknown and exploratory is critical to their success. Eliminate as much walking as possible and ease collaboration. The more unknown the feature, the closer they should be. Infrequent communication toward a focused goal creates waste.

Frequently communicate sprint, milestone and project goals face to face: While posting goals and values on the surrounding team walls is supportive, personal communication is best. It is the most iterative. An email may take a day or more for a response but face to face discussion iterates in real time. Producers and Product Owners must take all opportunities to communicate the goal expectations to the team and stakeholders. Communication delays via email or chat is waste.

Frequently communicate creative goals: As with due dates, the creative expectations must be shared continually. Generally, the “definition of done” lies with the Creative Director or Product Owner. They must be vigilant in sharing their requirements…often. Misunderstood creative goals create waste.

Make sure the definition of “Done” is clear to all content creators: One of the main roles of the Product Owner is to communicate their expectations surrounding a feature’s creative requirement and quality. Fast, measured decision making is vital. My continued belief (which is supported by Lean Six Sigma) is to follow the United States Marine’s “70% Rule”. If you think your plan has a 70% chance of working you must execute as quickly as possible. You can always adjust if it’s wrong. I’ve worked with too many creative directors that wait for the “perfect” plan. Navel-gazing creates waste.

Promote the value of transparent communication on all project related matters: I’ve worked in many companies that held core data about the project closely. They often felt the team couldn’t handle bad news or they might lose people to attrition. Being open and honest is not only ethical, it’s also good business sense. Teams must be fed the best information to help them work toward their goals. Keeping secrets, in most cases, is a mistake and can fester into discontented teams. Poor, infrequent communication creates waste.

Optimize the value stream: The project pipeline can be one of the biggest waste creators on project. Content creators must be able to review and iterate on their work as fast as possible. Broken builds, long asset transfers, etc. can significantly limit the ability of the team to do their best work. Long, broken value streams create waste.

Encourage content creators to show interim work: No one likes to show work that is undone. They may think that the reviewer doesn’t understand what it will evolve into or that they’ll get critiques about irrelevant issues the creator already intends to resolve. The creator and the reviewer must develop this trust. Frequent reviews on iterative work will help eliminate rework (waste) overall. Showing interim work reduces wasted time. Waiting to show work till it’s finished creates rework…and waste.

Attempt to eliminate rework resulting from creative review meetings: This point is similar to the previous one, however the ideal situation is that NO rework comes from “official” creative review meetings. This work should have already been reviewed and altered prior to the review meeting. The review meeting should be a bureaucratic “stamp of approval”, not a meeting to explore the creative director’s lofty new ideas. On nearly every project I’ve worked on content creators have complained that they must wait far too long for their work to be reviewed. Not only does this create waste in the form of idle time and possible rework, it’s a significant frustration for all involved. The Product Owner must delegate reviews to trusted team members. To do so, their requirements must be communicated clearly and their expectations must be established. Rework from infrequent creative reviews creates waste.

Streamline or eliminate meetings: If your team finds meetings useless you are probably not conducting them properly. There are many, many sources that outline the best way to run them. Proper agendas, specific questions to be answered, etc. People generally dislike meetings and find they are a waste of their time. Producers must study the many ways to hold effective meetings. Meetings should be about collaboration on solutions, not reiterating what everyone already knows. Inefficient meetings create waste.

Hack, in the right circumstances: Not every piece of code must be beautifully architected. Sometimes the team gets more benefit from experiencing a feature hands-on, even if the underlying code is messy. An agile adage states that teams should “fail frequently”. This means the team must prototype quickly so that they may iterate toward quality as fast as possible. Hacking code can get to an example feature faster. Over designing and massive system creation before the feature(s) is well known can lead to waste.

Stalk and assassinate open questions: The team must continually stack rank the open questions surrounding the project. The questions with the most impact and expected frequency should take the highest priority. The features with the highest value for the customer (gamer) should be placed at the front of the line. Killing open questions with religious fervor steadily removes uncertainty and risk from projects. Open questions are sources of risk on a project.

Focus work on customer needs: Teams must be vigilante in making sure they are creating features for their customers, not themselves. Activities that don’t directly correlate with customer needs should be removed. Sometimes people like to work on their own pet projects despite the value for the end user. Working on personal features that don’t align with the project end goals creates waste.

KAIZEN

At the end of the day the producer’s foremost responsibility is to continually search for ways to make the project run more smoothly. “Kaizen” is a Japanese term from Toyota that evangelizes continuous improvement. Producers, Product Managers, Stakeholders and Content Creators must always be on the hunt for ways to improve their work process. It’s a mindset that must be practiced on all projects so that results can improve over iterations.

IN CONCLUSION

Lean Six Sigma, as noted earlier, is a very involved framework that includes graphs, equations, methods and techniques that are very involved. Teams may only need to understand the principles to gain benefit. More than a framework, it is a mindset. Waste is a project killer. The practice of finding and eliminating it is a mindset that all teams should embrace.