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

篇目1,分享工作室協調團隊分工需知的6個要點

作者:Samuel Rantaeskola

隨着團隊規模增大,協調各成員的工作也會變得困難。作爲遊戲從業者,我們非常擅長將小項目從概念做成成品。但是,當團隊規模大到一定程度,許多看得見看不見的障礙和麻煩就露出苗頭了。大規模團隊如果沒有運作項目的經驗,就會非常阻礙行業的發展。

1、達成一致

在小團隊裏,各成員之間的持續交流是激發靈感、提高積極性和達成共識的有效方法。然而,在團隊成員上百,再加上設計文件並非人人都看過的情況下,單純依靠成員之間的交流就必然導致項目失敗。遊戲設計和製作計劃之間的緊密聯繫是保證將高級概念轉換成實際產品的關鍵。

當然,保持“是什麼”和“怎麼做”之間的聯繫只能達到一半的目標。達成最終目標的首要方法應該非常清楚,讓整個團隊都明確。這樣,團隊才能夠既保持工作進度,又不斷萌生創意。

team-structure(from smartinsights.com)

team-structure(from smartinsights.com)

2、決定組織

在製作早期階段,你應該考慮如何組織整個項目。當遊戲還在製作時,你如何對它進行排錯?記住,當你允許項目組的成員時,應該適當地擴充排錯人員。另外,最好能盡制定工作流程,而不是等到有需要時才確定。工作流程可以幫助你計劃進度。

3、細分問題

對於大多數團隊,這是必須考慮的,但有不少團隊仍然把項目當作一個大型拼圖遊戲。他們費了大量精力,試圖最大程度上優化資源配置和管理,但在這樣一個信息叢林裏,這各方式是不可能產生好決策的。因爲他們面臨的困境在於,如何從一個大問題中細分出保持儘可能互相獨立的小問題。

4、根據問題分配職能

理論上,似乎所有人都很熟悉交叉職能團隊,但實際上,混合團隊職能是極其危險的。這種形式其實是遊戲行業中的落後習慣。如果能控制好交叉職能部門的規模,添加一兩個成員產生的麻煩也不會超過在細分職能部門的組織結構中添加成員。並且,如果團隊之間的依賴性較小,管理上的開支也會相對少。

5、下放決策權

你應該接受現實:你會失去控制權。自上而下的管理層級結構可能“適用”於小團隊,但在大型開發環境下,極其容易出錯和導致效率低下。你很快會意識到,這種形式很有風險,即使不能完全淘汰,也必須改革。大型開發團隊從休閒遊戲工作室的“鳥槍法”中吸取了經驗, 也就是獨立團隊在自己的職權範圍內行使決策權。在這種環境下,就不存在拖延團隊工作進度的外部干擾了。自然而然地,休閒遊戲開發團隊非常適合這種管理方式。當然,如果能儘早把問題細化,以及下放權力,大遊戲開發團隊也能採用這種模式。

6、一個團隊就是一個小單位

不要在管理個人上浪費時間了。信任你的團隊會做好自己的份內事。在執行項目的某個任務時,個把人可能並沒有參與,因爲他等着團隊中的其他人完成這個階段的任務。相信我,他可能想到成千上萬他可以爲項目做的事。畢竟你的團隊成員基本上是人才。

篇目2,遊戲公司CEO應該避開的11個陷阱

作者:Nick Hatter

在我創建giftgaming之前,我只是喜歡遊戲。因爲非常喜歡遊戲我纔開始開發遊戲。13歲的時候我便開始使用DarkBASIC。18歲我開始基於Java創造《俄羅斯方塊》。21歲的時候我使用了Unity。23歲開始使用Marmalade。我的生活重心似乎始終圍繞着遊戲開發。

在過去10年間我開發了許多遊戲,不管是休閒遊戲還是第一人稱射擊遊戲。在完成計算機科學的BSC後,我開始進行一個名爲“Pilgrim”的大型JRPG項目,其靈感是來自《最終幻想VIII》。這是一個伴隨着全景攝像機,戰鬥,庫存和保存系統的項目。

但是我遇到了一個大問題:我沒有資金去支持自己全職完成這個項目或支付美術師的薪資。

於是我天真地參加了Cambridge Startup Weekend希望能夠接觸到一些投資者。結果我遇到比我想象中更多的投資者。於是我便創建了一家初創公司giftgaming。

TechCrunch Startup BattlefieldAfter的Nick Hatter參與了劍橋賈吉商學院的Accelerate Cambridge課程,在這裏我學到了如何籌集資金,如何宣傳,如何提防法律問題,如何聘請員工(與解僱員工),所有的這些都是開始一項新業務所必要的元素。

techcrunch(from gamasutra)

techcrunch(from gamasutra)

我知道接下來我將獲得像TechCrunch和Management等媒體的報道。然後我出現在了《WIRED Magazine》上。所有的一切都快速發展着。這真的很誇張。就在上週我的初創公司被稱爲2015年最值得期待的10大來自劍橋的公司之一。我也在2周內便獲得了30萬英鎊的資金。我甚至差點忘記自己開始做這件事才1年左右的時間。

就像我的一個導師所說的那樣,這是一次“嚴峻的考驗”。但在這一年時間裏,我真的學到了許多。不管是關於業務,人,我自己還是生活。從一名獨立開發者變成一名首席執行官需要一次“巨大的突破”。

應該避免的11大陷阱:

1.想要達到完美

我已經創造了7款完整的遊戲。而我真正發行了多少遊戲呢?只有1款(《Thundrclap》)。因爲我很害怕創造一些並不完美的內容。其實你應該發行任何內容。然後問自己某一功能是否真的必要。用戶是否真的會注意到它?你將會驚訝於所得到的答案。

2.在團隊中平等劃分股權

我們並非完全平等。基於經驗,時間,技能等等元素,人們帶給團隊的價值也會不同。做到公平的一種有效的方法便是使用“分配公正”原理,如基於上述所有參數讓團隊基於每個領域以10分爲點數進行劃分。然後通過整個團體的點數去劃分其中每個成員的點數。這將幫助你確保每個團隊成員享有相應的分配。

3.讓創始者輕易拿走股權

你應該讓每個創始者簽訂一份帶有“行權計劃”的股東協議書。行權計劃是關於“如果你在X年之前離開,你便只能獲得Y%的股份”。最理想的情況是,每完成一年的工作,創始人只能拿走其股份的25%。所以如果創始人在1年以前便離開公司,那麼他們將不能分配到任何利益。這聽起來是否太過苛刻了?並沒有。這是很公平的做法。我便見過一些初創公司因爲聯合創始人帶着大量股權離開而被迫關閉的情況。你可以基於Lawbite(遊戲邦注:爲中小型公司提供在線法律服務)以一個合理的價格定製專屬的股權協議書。

4.沒有正式的知識產權所有權

如果任何人爲你的遊戲創造部分內容,你就需要確保到底是誰擁有這些內容的所有權。即使你向對方付錢,他們可能仍擁有內容所有權。而IP轉讓協議能夠幫助你正式擁有內容的所有權。不過你還是需要尋求適當的法律諮詢。

5.花費太多時間於競爭中

競爭可以是一種有效的PR方式。但這同時也需要花費大量時間,並可能分散你的注意力。每當看到那些已經擁有自己初創企業的創業家參加startup weekends去思考其它創業理念時我都很困惑。我認爲這一點意義都沒有。這就像是已經結婚的人還去參加速配活動一樣。是的,這麼做是有趣的。但是你將會因此分散注意力。如果你正致力於一款遊戲,特別是身處一個團隊中,你就應該全身心投入於遊戲中。這纔是你的主要工作。如果你不能保持注意力,你可能最終便難以完成併發行遊戲。

6.不睡覺或不運動

“具有創造性的人總是最嚴重的”這是我的一位導師在在談到睡眠不足時所說過的一句話。你必須擁有足夠的睡眠與運動。只有這樣你才能擁有健康的身體與思維。當你擁有健康的心理狀態(如足夠放鬆)時,你便能夠有效地發揮創造性。而如果你始終睡眠不足,你便很難發揮創造性。

7.失去激情

就像有些人只關心最底層的財政面,而不再享受自己的工作。這在遊戲開發中也是如此。創造你想要創造的遊戲,這便是你真正的激情所在,即使你創造的並不是一款賺錢的複製遊戲。從統計來看,你的遊戲獲得成功的機率很低(就像任何初創企業所面對的那樣),所以你至少還能夠享受創造遊戲的樂趣。。而如果這正是你的激情所在的話,你便更有可能繼續下去,直至情況變得更加艱難,並且你有可能比以前更加努力地執行工作。成功不一定是基於金錢—-這取決於你自己的定義,有可能是來自用戶的好評,擁有一個立基用戶基礎或者擁有自己的遊戲品牌等等。

8.認爲自己可以做任何事

作爲一名CEO,我在這點上就表現得很糟糕。不幸的是,不管你擁有多少才能,總是存在一些你並不擅長的事。你不可能成爲任何事物的專家。對於你來說更好的方法是去尋找真正的專家並告訴對方你需要他們做什麼事,退後一步讓他們能夠執行工作。說真的我們一天所擁有的時間並不多,特別當你還是一名兼職獨立開發者時。你應該組建一個團隊。是的,很少出現真正成功的獨行者,擁有一支團隊而獲得成功的機率更高。並且團隊工作總是會更有趣。想想如果你是一個人工作的話每天晚上都要獨自面對屏幕做事該多難受啊。或者你也可以選擇與好友一起致力於遊戲創造中。

除此之外,團隊還是籌集資金的重要元素。大多數投資者都不願意投資於獨立個體(但也存在例外)。

9.認爲演示版本總是有效的

我還記得之前嚮導師呈現giftgaming早期原型的情形。在30分鐘的會議中,我將所有時間都用於運行遊戲原型。我本來應該呈現遊戲玩法的相關視頻和截圖。“啊,它昨天還好好的”這是我經常聽到的一句話。你應該在演示的時候使用截圖或視頻。如果你必須展示一個演示版本的話,也請先準備好截圖備份。因爲很多時候當你迫切需要使用技術或多媒體時,它們總是會突然壞掉。

10.相信否定者的意見

當我剛開始創建giftgaming時,便有人跟我說我是不會成功的。他們認爲:“當一個品牌或遊戲發行商能夠進行直接交易的時候他們怎麼可能還會與你合作呢?”時間能告訴我們答案。我們往往需要花費許多時間去結束與一個品牌的直接交易。品牌和遊戲發行商(當然是較爲小型的發行商)通常都沒有足夠的時間去管理這些關係,更別提爲自己的遊戲尋找適當的品牌。這便是giftgaming能夠做到的。千萬不要低估創造一個強大的廣告平臺所需要投入的時間。

現在我們已經擁有超過15個主要品牌,並且我們也開始收到來自世界各地遊戲工作室的自助註冊。如果我相信那些否定者的意見的話會怎樣?如果我未進行研究的話會怎樣?我的生活可能會一成不變。否定者是危險的存在,是創新的大敵。如果你擁有一個新的遊戲理念,請謹慎對待他們的看法。全新理念總是能夠改變一切。

11.未採取建設性的反饋

又名“我的孩子並不醜!”這與上一點有點矛盾,但是如果有人能夠提供給你有幫助的反饋,這將非常重要。認真聆聽遊戲早前反饋。也許你需要重新思考機制的設定。也許遊戲玩法或控制不如你想象中的那樣具有直覺性。不管好壞,你都需要接受所有具有建設性的反饋。並從中獲得學習。有時候聽到批評總是會難受,但這總比你因爲不想聽到批評而導致遊戲變得更糟糕好受多了。

這便是遊戲開發者應該避開是11個陷阱。事實上並不只有這些陷阱。但如果你能夠避開這些,你便能夠在任何企業中(不只是獨立遊戲)獲得成功。

篇目3,Wooga成員揭祕公司自主化的團隊工作方式

作者:Jesper Richter-Reichhelm(社交遊戲公司Wooga工程主管)

去年底有篇描述Spotify如何使用分散處理方法管理部落和小組的文章深深吸引了我。它讓我認識到我們並非使用這種方法的唯一團隊,我希望在此討論這篇文章所說的一些理論。

我還想借此說明,我們完全有可能在小型自治團隊中採用真正的敏捷工作環境。這並非小事一樁,它需要我們每天都付出精力來保證這種結構順利運行。以下就是我以自己在Wooga的工作經歷爲例,對保持團隊獨立性爲何有助於衡量一家公司優劣的總結。

Wooga現狀及願景

Wooga成立於2009年,其願景是到2020年,所有人都將成爲遊戲玩家。我們四年前大約20名成員,現在員工(來自40多個國家)已經超過250人,大家都在柏林工作室辦公。
員工規模壯大是公司經濟成功的一個副產品,在這個成長過程中,我們面臨的最大挑戰卻是不要喪失我們所建立的企業文化。在早期階段,公司中每個人都緊密合作,也不需要因爲等待審批結果而拖延進度。通常來說,隨着公司發展壯大,管理層的增加,這種工作方式就會發生變化,並且趨於低效率。

我們該如何守住這種文化?答案就是:一切以獨立遊戲團隊爲中心。我們曾對這種方法產生懷疑,但我們相似這至少值得一試。

Wooga是一個由許多小型獨立團隊組成的集合體,每個團隊都要負責製作和運行一款遊戲,並在跨職能和自治環境下自主制定決策。他們可以自由分享心得,無需相互較勁,這意味着他們能夠在一個大型框架中像小型獨立創業團隊一樣高效執行工作。

wooga structure(from thenextweb)

wooga structure(from thenextweb)

他們可以自己決定聽從還是忽略外部建議——即使這些建議來自公司創始人。這種方法只適用於傑出的人才。所以僱傭正確的人就是我們在Wooga最重要的事情。我們相信“用人不疑,疑人不用”這個道理。事實證明這個原則非常管用。

團隊

團隊是Wooga組織的核心。70%員工是遊戲團隊成員。公司還有部門主管,例如兩名負責不同領域的工程主管,以及其他監管各自部門工作的主管。

其餘員工則負責提供營銷、客服支持和本土化(20%)或者HR、PR、金融、商業分析等中心服務,以及維護遊戲的簡單服務。“服務”是這裏的關鍵詞——這些團隊要支持遊戲團隊,而不是後者服務前者。例如,公司沒有專人預算處理流程,遊戲團隊可以自主決定相關發佈日期。

wooga team ratio(from thenextweb)

wooga team ratio(from thenextweb)

每個遊戲團隊都有一名產品主管負責爲團隊制定最終決策。這可以確保團隊總能快速制定決策,公司高管也不會成爲干預其決策的瓶頸。這實際上是核心管理層對團隊的授權。從團隊希望製作哪種遊戲,到團隊打算如何自我管理,都由遊戲產品主管來決定。

wooga game team ratio(from thenextweb)

wooga game team ratio(from thenextweb)

公司中的團隊小至1-3人,首先入夥的人通常會成爲未來的項目領導,並提供遊戲的最初理念。他們會開發一個可評估並且可試玩的原型。如果原型不夠好,團隊就會重新開始。如果它看起來極富潛力,團隊就會逐步擴大規模,但會盡量將其控制在10人以內。

在遊戲上線之後,團隊規模會保持穩定或有所增長。更多遊戲功能的開發不會拖延開發過程,但會從在線數據分析、A/B測試中提取額外信息,並且需要管理整款遊戲。

共享知識

重點在於,即使這些團隊是獨立動作,並且會相互比較KPI,他們之間卻並不會相互競爭。他們之間會經常交換知識和經驗。這也正是我們影響獨立團隊創新(以及彌補獨立團隊所帶來的風險)的方式。

weekly meeting(from thenextweb)

weekly meeting(from thenextweb)

每個團隊每週都要開展一個5-10分鐘的會議,向公司其他成員報告自己的進度,說明自己的收穫(例如之前的A/B測試結果,或者宣佈遊戲新功能)。這種會議並不限制團隊成員所分享的信息類型,只要其分享的是對他人有益的結果即可。

此外,任何人都可以參與這些會議。我們可以在遊戲中嘗試新事物,如果它們具有可行性,其他團隊也可以效仿。

5 minutes of fame(from thenextweb)

5 minutes of fame(from thenextweb)

另一種層面的知識交流發生於同個學科的成員之間。我們每月會織織一次內部快閃演講(5分鐘),公司任何人都可以上臺說說自己想分享的內容,任何人都可以參與這種演講。這是一種傳播信息,在公司中展開討論和增強聯繫的好方法。我們還有針對後端開發、前端開發、遊戲設計、商業分析和美術的專門會議。

如果一個話題太複雜,無法在快閃演講中解決時,就可以在“便當演講”中提出,此時的參與者在發表25分鐘的演講之後可以得到一次免費的午餐。公司中有半數人蔘與這種演講,我們每個月會舉辦一次這種演講。

我們會在大禮堂舉辦這種“便當演講”,而公司每週例會則在週一早上展開。在這種15分鐘會議裏,大家會給予新人溫馨的問候,或者公佈公司戰略,宣佈遊戲發佈等消息。這是每週重要的開端,有助於公司中的每個人都獲得相應的知情權。

協作

由於團隊具有跨職能特點,大家就有了廣泛可用的一系列技能,緊密合作的成員也由此組建了優秀的團隊。但我們的理念並非讓一人獨自了解和決定一切,而是讓每個團隊成員都負起推動遊戲前進的責任。

團隊本身就有自治權,無需根據其他團隊的情況來創造和運行自己的遊戲。因此,開發團隊在使用由商業分析服務團隊提供的共享服務,以及一些標準KPI時要自己進行分析。與之相似,公司中也不會有運行/管理團隊幫助他們運行服務器或其他基礎設施,而是由編寫軟件的人自己來運行。公司也不會迫使工程師共享或重用代碼,不存在人人必須使用的中心框架。

如果工程師想重用代碼,可以訪問github中的私人和公共套件庫,但他們也可以選擇自己重新做起。這是一個折衷方法:我們有時候會白費力氣重複工作,但整個公司仍然更爲靈活而創新。新團隊開工時,原來的團隊進度並不會被拖延,整個通信開銷也仍然保持在較低水平。

凡是聽說過Dunbar相關理論的人都應該知道,當一個羣體成員超過150人時,其團隊凝聚力就會開始下降。Wooga要求團隊成員積極與其他遊戲團隊互動,相互學習經驗,瞭解其他團隊之前掌握的教訓。爲促進團隊溝通,我們將團隊一起整合到工作室中。這是我們正在執行的一個戰略,目前來看效果理想。

studio structure(from thenextweb)

studio structure(from thenextweb)

敏捷方法

我們認爲敏捷開發並不是指運用特定方法,而是遵從正確的原則,並持續反思自己是否執行了正確的方式。

所以,這裏並不存在團隊開發軟件的統一流程。團隊可自主決定如何行事,不過他們通常會結合Scrum和Kanban元素來開發內容。

但這也存在一定約束性:

*團隊需要在每週例向公司其他人彙報進度和收穫。

*較小的原型團隊需要通過批准之後才能開發完整的遊戲。大量原型都沒有通過這個階段,這讓我們能夠在較短時間內測試大量新遊戲理念。“失敗”正是這個階段的一部分。公司會分享從被取消遊戲項目所得到的經驗和教訓。

*公司所有人都可以共享所有源代碼。

*公司任何人都可以瞭解所有KPI和參數。

*我們希望大家根據常識來思考和決策。我們試圖避免形式化的流程,因爲規章制度並不靈活。我們也有一些引導個人決策的普遍原則,有時候也會給予必要的提供,但總體來看這些方法還是很管用。

總結

我是在2009年Wooga還只有10個人時就加入了公司。隨着時間發展,創始人希望讓Wooga成爲一個人人爲自己的工作、團隊和公司負責的集體。保持獨立性和自治性就是我們在Wooga的普遍工作方式。

所以我們的企業文化很強調自主權,公司信任大家能夠制定正確的決策,並且多數時候,他們也確實做出了正確決策。當然,人也難免偶爾犯錯,但因爲大家並不會避諱這一點,所以他們可以很快糾正問題。

篇目4,Valadares談團隊理念、社交遊戲發展及企業文化

作者:Vlad Micu

Playfish倫敦工作室總監Jeferson Valadares及其團隊肩負沉重使命。他們的任務是:理清社交遊戲的未來發展方向。在Valadares看來,這意味着他們需在遊戲中融入更多社交情 感和故事元素。Valadares表示,“第一代遊戲主要關乎競爭和排行榜元素,我們正在觀察這類遊戲的未來發展態勢及要如何充分利用Facebook有 所變化的用戶體驗。”Valadares在某次採訪中談及如何將團隊視作企業單位進行管理,分析社交遊戲領域的下步發展,及要如何在全球範圍內經營公司文化。

團隊管理

Valadares表示,“我們投入衆多時間試驗自己的上線遊戲。每週遊戲都會呈現新元素。發行過衆多作品及擁有龐大用戶基礎的優點是你可以在不同遊戲中試驗這些內容,查看其運作情況。”各Playfish團隊都將項目視作小型企業進行管理,此過程讓他們得以輕鬆獲悉什麼新功能能夠順利運作。各團隊會將運作順利的功能植入自己的作品中。

game screenshot from gamesauce.org

game screenshot from gamesauce.org

Valadares表示,“現在公司已有團隊開始着手新項目,這些團隊正在試驗不同類型的遊戲構思。”Valadares工作室的一個新團隊嘗試通過更具合性質的方式體驗社交遊戲。據Valadares表示,這旨在弄清此模式如何在減少玩家參與遊戲所需好友數量的同時提高他們之間的社交關係。Valadares表示,“玩家無需和10位同事共同操作內容,只需和3位好友合作。”

質量>數量

隨着越來越多公司開始涉足社交遊戲,社交遊戲領域在過去幾年獲得顯著發展(遊戲邦注:Valadares從此發展趨勢中看到積極的一面,他不僅鼓勵同事進行更多嘗試,同時希望看到更多業內人士這麼做)。

他表示,“當行業日益擴大,業內人士就能夠製作出並非瞄準大衆用戶的獨特內容。很多走此路線的人士最終都獲得成功。”

除更多嘗試外,Valadares還發現,行業涌現更多融入合作模式的作品。這是否能夠轉化成社交遊戲還有待分曉。Valadares表示,“這可能實現,但我不確定這能否在短期內達成,因爲我們所處的位置越尖端,所要進行的運算就越多。除非我們轉而運用OnLive之類的服務,這樣你就不需要藉助強大計算機呈現內容,行業就會涌現富有社交性的尖端內容。”

新鮮的靈感

Valadares表示,“有時我們會參考棋盤遊戲。這類遊戲的優點在於其包含優質故事內容。這通常頗吸引眼球。”Valadares希望社交領域未來能夠包含若干元素。“能夠出現傑出的故事遊戲,因爲用戶非常一直都非常看重故事元素,我覺得這種情況會一直持續下去。所以我們要如何在社交體驗中更凸顯此元素?行業已進行若干粗略嘗試。”

Playfish文化

獲得顯著發展後,Valadares的倫敦工作室努力維持自己的公司文化。Valadares表示,“我們獲得顯著發展,2009年只有3位員工離開公司。我覺得這非常好。我們持續廣泛招募人員。公司和我剛加入時相比擴大了4倍(遊戲邦注:1年多前公司規模還很小)。”

由於獲得顯著發展,Valadares不斷問自己:“我們要如何慶祝此成績,同時牢記工作室的最初目標。”隨着公司新工作室在全球各地紛紛成立,Playfish人員正努力維持着相同的公司文化。Valadares表示,“在倫敦,各成員都很清楚公司的發展變化,但要將其他工作室聯繫起來則就困難許多。我們既積極尋求發展,同時又努力維持我們最初的創新精神。”

但就Playfish各地區工作室的特殊文化來說,有些文化差異性應受到推崇。Valadares解釋稱,“在中國,工作室成員偏好某些遊戲。過去,我們試着讓他們製作西方國家的遊戲,但最後發現他們更擅長製作自己理解的內容。這也是我們分別在美國、歐洲和亞洲設立工作室的原因所在。”

篇目5,影響團隊發揮生產力的2大問題

作者:Marcelo Spiezzi Raimbault

遊戲開發中最大的挑戰並不是學習新技術,創造最佳工具或尋找樂趣。對於許多開發者來說真正的挑戰和噩夢應該是如何創建並維護一支多產的團隊。從邏輯角度來看,創造遊戲只是正確遵循一系列步驟而已。然而遊戲卻是由人類所創造的而不是機器,所以情況也開始變得嚴重起來。

很多情況都有可能導致團隊的失敗。可能是個人的原因也有可能是組織的原因。理解爲什麼一支團隊會遭遇失敗比了解如何促成團隊的成功更加重要。交流不順可能會破壞團隊工作:《Dark Side of Teams》便是一篇總結了可能導致團隊失敗的不同問題的優秀論文。而在本文中我將討論這一論文中所提到的2大問題,即發生於學生所開發的項目《Cult》的開發過程中,並且這些問題也很有可能出現在任何遊戲開發團隊裏。

模棱兩可的目標

對於任何項目來說,模棱兩可的目標可能是最大的問題。在開發階段,我們很容易迷失在理念,過程,細節間並忘記真正需要做的一些事。我們必須確保所有團隊成員都清楚並理解特定階段的目標。當目標並不明確時,人們很容易將時間花費在一些不必要的任務中或浪費時間做一些不正確的事。

不幸的是我們經常會忽視這一問題。首先,領導者通常更熟悉項目理念並且總是會認爲其餘團隊成員也有相同的理解。其次,團隊領導者只會專注於自己的任務而未關注其它任務也未爲它們其設定明確的目標。

對於團隊領導者來說,如果他們未能提供給所有團隊成員明確的目標便有可能影響他們對於信任的感知。團隊成員可能會認爲領導者在特定任務上不夠信任自己所以才未明確任務。而缺少信任的團隊便等於低產能的團隊。

如果沒有明確定義目標,團隊便不可能具有自主性,而缺少自主性的團隊將很難開發自己的路線並達到較高的生產力。

缺少緊迫感

截止日期!儘管這是一個會讓任何開發者大叫的詞,但這卻是能夠推動團隊生產力的必要元素。我們都知道一款遊戲是永遠都不可能被完成。遊戲將經過不斷的完善,這也是爲何需要截止日期的原因。

我們很容易發現一個成功的Kickstarter項目或一款獨立遊戲因爲缺少足夠的錢而未能完成項目。通常情況下,未明確開發時間是導致這些項目失敗的主要原因。人們總是會基於緊迫感而行動。如果不存在足夠理由爲明天做某事的話,人們便可能不會在今天做這件事。我們總是認爲自己跟別人不一樣,即我們會盡快完成自己的所有任務。然而在團隊項目中卻不是如此,特別是在遊戲開發的創造性環境中。如果不存在緊迫感,項目便不可能按照我們所期待的那樣快速發展並在時間到達時具有預期的表現。

創造短時間的交付成果是在團隊中保持高度緊迫感的一種有效方式(遊戲邦注:就像敏捷開發和scrum開發過程便非常有幫助)。我們必須牢記基本功能還未完成,這是之後需要繼續完成的功能。

而截止日期問題通常也是基於模棱兩可的目標之上。也就是隻有擁有了明確的目標,一個項目纔有可能準時完成。即使你擁有許多短期的交付成果,但是它們卻不具有明確的目標,團隊也不清楚它們該何時完成這項任務,那麼這一切也就失去了意義。

首先你需要明確問題

我們總是能夠找到全新的“關於成功團隊的10大訣竅”,但是關於團隊遭遇失敗的原因卻永遠都是一樣的。提高團隊生產力的最佳方式便是努力處理並消除阻礙它的問題。

篇目6,分享開發團隊創造迭代文化的3個要點

作者:Seth Sivak

迭代才能產生最棒的遊戲,但我們該如何將其融入工作流程和文化中?這正是我們Proletariat工作室努力的方向,我們每天都在培養這種文化。以下是在你自己的團隊中創造迭代文化的三個重要步驟:

1.不斷評審

目標:團隊中的每個人都能夠以一種建設性的方式相互幫助,創造出最好的作品。

創造迭代文化的第一步是讓團隊成員不斷評審他人的作品。雖然一開始大家會有所不適,尤其是被評審的作品尚未完工之時,但這卻是在團隊中建立一種反饋循環的關鍵。在Proletariat,我們通常是在週五進行每週評審會議,更小的團隊則進行非正式的評審會議。

任務項:在開發過程中創造評審環節,讓來自各個學科、領域的成員給予反饋想法。一開始可以是非正式的評審,之後可以逐步發展成自然行爲。

iterative-process(from protoshare.com)

iterative-process(from protoshare.com)

2.不存在所謂的“完成”

目標:保持功能的彈性,以便團隊成員可以在返工的時候,隨着遊戲發展對其潤色。

持續的評審過程可以讓團隊自然地展示未完成的作品。下一步就是讓大家清楚不存在所謂的“完成”。無論是美術、設計或代碼,一切都存在改進或潤色的空間。這裏的尚未“完成”是指團隊會在前進過程中知道自己還有機會重返原來的功能對其進行迭代。但這隻適用於團隊信任製作人以及進程安排的情況。

在Proletariat,我們會在備忘錄中創建列表指出團隊需要重新解決的問題。在每個階段結束時,我們都會盡量留出一週時間來解決備忘錄的問題,在此我們將其稱爲“債務周”。此時團隊成員可以做自主行事,優先執行自己認爲最重要的事情。

任務項:在備忘錄中創建列表指出需要優化的事項。在開發過程中提供一些間歇期,以便大家有餘力處理備忘錄的事情。

3.放手

目標:允許開放式和誠懇的反饋,以便團隊不要執拗於個人想法。

開發者難以割捨自己的某個想法,從而導致項目進程受阻的這種現象很常見。與其執拗於某個理念,還不如放手讓團隊其餘人圍繞它展開工作。

應該鼓勵團隊中每個人都拋出自己的想法,看看最終會產生什麼結果。團隊每個成員都必須清楚,當某個理念被公之於衆時,它就不再屬於個人想法。無論是美術、音樂、音效還是編程,各項工作均是如此。我認爲最好是讓大家把自己的想法傳達給團隊。讓團隊成員貢獻自己的創作才華,才能更好地創造最終產品。

任務項:認真對待理念本身而非其來源。開發一種能夠客觀分析遊戲情境中的選項的過程。

總結

創造一種迭代文化需要整個團隊投入大量時間和精力。優先事項的變化當然會對開發過程帶來影響,但是這種文化形成氣候時,就能夠推動團隊每個人在積極、合作的環境中創造最好的作品。

篇目7,分享遊戲製作人的7條團隊管理建議

作者:Samuel Rantaeskola

我曾在一篇文章中介紹製作人常犯的錯誤。與教育孩子一樣,父母總是會告訴孩子不能做什麼,然後再說應該做什麼。所以如果我只介紹常見錯誤而不告訴大家應該做什麼,意義不大。於是我又寫了本文。

我們都聽說過某些個人英雄主義的製作人把整個開發過程扛在自己肩上。這些故事往往是浸潤了製作人的個人犧牲的血淚史。然而讀者們往往看不到該製作人後來怎麼樣了:這位英雄不得不花一年的時間讓自己從壓力綜合症中恢復過來,而他的團隊因爲羣龍無首,這一整年都處於混亂狀態。這個人可能爲產品的誕生做出極大的貢獻,但我很懷疑他能否維持團隊的長期穩定。

製作是一個領導性工作,不是項目管理;不同的製作人有不同的領導風格。有些製作人喜歡在團隊面是施展作爲領導的權威,而有些人偏好更平等友善的合作方式。領導風格很大程度上取決於人員構成。但考慮到大部分工作室的員工都是年輕人,製作人確實應該學習一下年輕人喜歡的領導方式。

不幸的是,本文不是一份成功的領導人的工作手冊,我在此分享的建議更多地是告訴你怎麼想,而不是具體怎麼做。製作人必須找到最適合自己的團隊和處境的方案。

game develop team(from edge-online.com)

game develop team(from edge-online.com)

1、隨機應變

不存在以不變應萬變的方法。這意味着製作人必須非常靈活,隨機應變。他們必須知識豐富,多才多藝,這樣遇到問題時纔不致於不知所措。我知道這是一條很難讓人接受的建議,但要成功,這個心態是必須的。

2、成爲合格的傾聽者

製作人的職責是讓團隊中的不同人才各司其職。製作人不能只顧發號施令而不聽取其他人的聲音。因此,我堅信優秀的領導者也必須是一名合格的傾聽者。除了錯過有價值的信息,光說不聽的製作人還會遇到這個問題:如果下面的人覺得自己不被傾聽,就不太可能服從領導。

對於性格外向的人,比如我,這一條很難做到,因爲滔滔不絕也是我們的思考過程。

3、信任他人

不被信任感會導致團隊成員志氣低下,工作力不從心。製作人必須儘自己最大的努力讓團隊成員相信,他相信團隊中每一個人的判斷。即使他內心還是有所懷疑。這也意味着製作人必須寬容錯誤,因爲犯錯是成長的一部分。製作人應該努力幫助團隊成員從錯誤中學習,而不是一味的批評責罵。

4、成爲好老師

製作人的最終目標是建立一個沒有他本人存在也能正常運作的系統,甚至是一個讓他本人變得多餘的系統。當團隊遇到他們覺得棘手的問題時,他們通常會首先找製作人去解決。優秀的製作人會幫助團隊從問題中學習解決方案,從而讓團隊得到成長。這樣,當下次遇到類似的問題時,團隊就不需要過問製作人,自己就能解決了。

5、尋找長期解決方案

有些方法只能讓團隊暫時擺脫困境。製作人必須不斷地評估處境,並尋找問題的長期解決方案。當製作人太專注於解決具體的問題時,他就會忘記修復長期問題。製作人必須依靠團隊去解決短期的問題,而把自己的精力放在與團隊一起制定防止“舊病復發”的計劃上。對我本人而言,這是一個大問題,因爲我總是忍不住去碰那些短期問題。

6、目標驅動型

製作人做什麼事都應該是目標驅動的,而不是任務驅動的。當他們把時間花在詳述達到目標的路徑和分配任務時,他們往往忽略了團隊更擅長做這些事。描述目標和幫助團隊理解爲什麼要完成這些目標纔是難點。這讓我想到最重要的一點:製作人必須記住向團隊解釋爲什麼。例如,如果要在團隊中普及新的工作方式,那麼就必須向團隊解釋這種工作方式的目標是什麼。如果沒有解釋,團隊執行效率可能會很低,因爲他們看不到那麼做的價值。這樣,製作人推廣新工作方式就得不到應有的改進效果。

7、遵守規定

這幾乎不需要說;製作人是團隊的一員,應該與其他人遵守一樣的規定。如果規定上班時間是早上10點開始,那麼那個時間一到,製作人就必須出現在辦公室裏。如果團隊爲了趕截止日期而加班,那麼製作人最好也一起。領導者不能指望團隊比自己付出更多心血。

我在本文中提出的建議大多專注於製作人應該如何與團隊打交道。我認爲爲了打造一支長勝不衰的團隊,製作人應該做到以上幾點。然而,具體情況不同,我不認爲以上建議是時時管用的。爲了處理某些情況,製作人有時候會背離這些建議。但他們應該努力使所謂的“某些情況”成爲例外,而不是常規。

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

篇目1,How to not fail in scale

by Samuel Rantaeskola

As game teams are growing in scale there are some severe pains in coordinating these efforts. As an industry, we are quite capable and efficient at moving small scale projects from concept to a finished product. When the team sizes eclipse the century mark, many more obstacles and hindrances both seen and unseen begin to rear their ugly head. The general lack of production experience of running projects at this larger scale is handicapping us as an industry at large.

I am not claiming that the solution I’m proposing here is rocket science in anyway, but rather these are the common pain points I see and hear continuously within the games industry.

1. Unify what to do and how to do it

In a small team, continually communicating the vision of the project with each member is a battletested way to keep everyone inspired, motivated and on the same page. However, solely relying on that method when working in the hundreds and adding to that having a game design document that nobody reads, is a sure path to failure. A tight connection between the game design and production plan is one way on how you can approach breaking down the game from a high level vision into actual work. In this video, I talk about a method for achieving that: http://vimeo.com/51747636

Connecting what and how will only take you half way there. The overarching method of getting to the end goal should be basic enough to be easily explained and understood by the entire team. Within that method, the teams should be able to select the best working formula for them moving forward whilst still feeding in to the whole project.

2. Decide on a structure

In the early phases of production, you should think of how to structure your entire project. How are you going to troubleshoot it when it’s being built? Bear in mind that it needs to scale appropriately as you will add teams to it. It is also a good idea to iron out workflows early on, instead of defining them on-demand. This process will help you plan how to track progress as you are getting into production mode.

3. Subdivide the problem

For most in our industry this is given, but there are a lot of teams out there that are looking at the project as one gargantuan jig-saw puzzle. They spend a lot of effort trying to optimize resources and dependencies to the smallest detail and in that jungle of information it is impossible to make good decisions. The challenge is to create sub problems that are as independent as possible from each other.

4. Build teams around the problems

Everyone seems familiar with the concept of cross functional teams in theory, but in practice evolving to a cross functional organization is extremely arduous. Historically, it has much to do with the outdated culture in the games industry, where the tradition has been to sit with peers in silence. A cross-functional organization scales nicely, and adding a team does not increase the complexity as much as in a departmentalized organization. Resolving dependencies is within the teams and the management overhead can remain fairly sparse.

5. Decentralize decision making

Accept that you will lose control. A top down driven management style and structure “works” in small environments, but is extremely slow and error prone in large scale development ecosystems. You will quickly realize that this strategy is fraught with hazards and will need to be corrected, if not eliminated outright. Large scale development teams have a lot to learn from the casual game studios’ “shotgun approach”, in so far as, the concept of having independent teams which are the decision makers within their domain. In this kind of environment, there are no external bottlenecks which slow down the teams’ progress. Naturally, casual games lend themselves well to this style. However, with an early sub division of the problem and delegation of ownership, it can work in more complex games as well.

6. A team is the smallest unit

Don’t go on a duck hunt to optimize the hours. Trust your teams to make good calls within their area. Every now and then one of the guys in a team will be short on project specific tasks, because he’s waiting for the other guys in the team to finalize the level. Trust me; he can probably think of a million things that he could do that will add value to the game. After all you’re probably hiring talent.

篇目2,From Indie Dev to CEO: 10 Indie Pitfalls

by Nick Hatter

Before I founded giftgaming, I was just like you; I loved games. I loved them so much I started developing them. First in DarkBASIC, at the age of 13 years old. By 18, I was building Tetris in Java. By 21, I was using Unity. And by 23, Marmalade. Somehow, my life kept going back to game development.

In the last 10 years I’ve developed a number of games, everything from Casual to FPS. After finishing my BSc in Computer Science, I started a big J-RPG project codenamed “Pilgrim”, which took a lot of inspiration from Final Fantasy VIII (cliche inspiration; superb game). It was coming on great, with a fully fledged camera, battle, inventory and saving system.

There was just one big problem: I didn’t have the funds to pay myself to do it full-time or to pay artists.

So I naively went to Cambridge Startup Weekend to “make investor contacts”. But instead, I got much, much more than I bargained for. I gave birth to a startup: giftgaming. I became The Pilgrim.

Nick Hatter on TechCrunch Startup BattlefieldAfter being accepted on to the Accelerate Cambridge programme at Cambridge Judge Business School, I was taught everything from how to raise funds, how to pitch, legal issues to watch out for, how to hire (and fire) — all the staples needed for a new business.

The next thing I know, I’m getting press coverage from publications like TechCrunch and Management Today. Then I appear in WIRED Magazine. Everything moves so fast. It’s crazy. Only last week my startup was named as one of 10 Companies From Cambridge To Watch In 2015. I’m also pitching for £300,000 in 2 weeks time. I forget I’ve only been doing this for just over a year…

(Image above of me from TechCrunch’s Startup Battlefield)

It has been a “baptism of fire” as one of my mentors says. But in this one year, I have learnt a lot. About business. People. Myself. Life. Going from an indie developer to a CEO requires a “quantum leap”.

Before embarking on the journey to becoming an indie game studio/company, take heed of the following…

Top 10 Pitfalls to Avoid (IMHO):

0. Thinking it has to be perfect
I’ve made over 7 complete games. How many did I actually publish though? Just one (Thundrclap). Because I was too afraid of making the others imperfect. Ship something. Anything. And ask yourself, is that feature really necessary? Will users actually notice? You’d be very surprised.

1. Evenly splitting equity in the founding team
No no no! We are not all equal. Unfortunately. What tends to happen is that people bring different value to team in experience, time commitment, skill and so forth. One good way to assign equity is to use “Distributive Justice”, ie. to slice the pie is to take into account all of the aforementioned metrics, weight them, then have the team grade each other on points out of 10 on each area. Then divide each members points by the points of the entire group. This gives you the equity split for each team member.

2. Letting founders walk off with equity
It’s a very good idea to have each founder sign a Shareholder Agreement with a “Vesting Schedule”. The vesting schedule basically says “if you leave before x years, you only get to keep y% of your shares”. Ideally, you would let founders “vest” (keep) around 25% of their shares for each complete year of service. So if a founder leaves before a year, then potentially they leave with nothing. Sound harsh? It’s not. It’s fair. I have seen other startups been screwed over by cofounders leaving with huge chunks of equity, forcing them to close down. Investors will not like founders leaving with big chunks either. You can get a tailored Shareholder Agreement for a very reasonable price from Lawbite who provide an online legal service for small to medium enterprises.

3. No formal Intellectual Property (IP) ownership
If anyone does any work for your game, you must make sure it’s clear who actually owns what. Even if you pay them, they still own it. An IP Transfer Agreement allows you to formally assign “moral” (ownership) rights over. As always though, seek legal advice.

4. Too much time on competitions
Competitions can be great PR. But they can also take a lot of time, and also cause you to lose focus. I get confused whenever I see entrepreneurs who already have startups going to startup weekends to come up with another startup idea. Makes no sense to me. That’s almost like being married and going to a speed dating event. The same can go for gamejams. Yes, they’re fun. But you will get distracted. So, if you’re working on a game, especially in a team, stick to that game. It’s your significant other and you wouldn’t want to cheat on it. If you don’t keep focus, you may end up with a lot of unplayed and unpublished games like me.

5. Not sleeping or exercising enough
“Creative people suffer the worst” as one of my mentors tells me on the subject of sleep deprivation. You must get enough sleep and exercise. Both have been proven to improve well-being and thinking. When you’re in the right psychological state of mind ie. relaxed, that’s the prime time for creativity. It is very hard to be creative when you’re a sleep-deprived zombie. Trust me. I have been there.

6. Not pursuing your passion
Sounds obvious, doesn’t it? But I see it happen. Some people only care about the bottom financial line, rather than enjoying their job. Again, the same goes for your game development. Build games that you want to build, that are your true passion, even if they’re not a money-making clone game. Statistically, the chance of your game being successful is low (as is any startup), so you might as well enjoy it at least. And if it is your passion, you’re more likely to keep going even when times get tough, and you’re more likely to work harder than ever before to make it succeed. Success doesn’t have to be financial by the way — it is how you define it, whether that is critical acclaim, having a niche fanbase, your own game brand and so forth.

7. Thinking you can do everything
As a CEO, I’m guilty of this one. But unfortunately, no matter how multi-talented you are, there will always be things that you’re simply not an expert at. And you can’t be an expert at everything. It actually makes more sense to find people who are experts, tell them what you need them to do, then step back so they can do their job. There are simply do not have enough hours in the day, especially if you’re a part-time indie developer. Get a team. You need one. Yes, there are a few successful solos, but your odds of being successful as a team and not burning out is much higher. Plus a team is more fun. Do you want to be all alone every night behind a screen? Or would you rather be working on your awesome game with your friends and having a good time?

In addition, a team is absolutely essential for raising funds. Hardly any investors will invest in individuals (there are exceptions to every rule though…)

8. Thinking the live demo will work
I remember going to show my mentor an early prototype of giftgaming. In the 30 minute meeting I had with her, I spent all of the time trying to get it to work. What I should have done is recorded a video of gameplay, and taken some screenshots. “Huh, it was working last night” — A phrase I’ve heard many times. Use screenshots or video in presentations. If you absoultely have to do a live demo, have screenshot backups ready. Technology and multimedia will usually fail you when you most need it.

9. Listening to naysayers
Someone said to me when I first started giftgaming that it would never work. In their words, “why the hell would a brand and a game publisher ever come to you when they can do a direct deal?” The answer is time. It takes a lot of time to close a big deal with a brand direct. Brands and game publishers (certainly smaller ones) do not have the time to manage all these relationships, not to mention finding the appropriate brands to put in their game. That’s something giftgaming does. And don’t underestimate how long it takes to build a robust ad platform.

We now have over 15 major brands onboard and we have started receiving self-service signups from game studios worldwide. What if I had listened to that guy? What if I hadn’t done my research? My life may have stayed the same. Naysayers are dangerous, and are an enemy to innovation. Be careful listening to them if you have a new concept for your game. That one new concept could change everything.

10. Not taking constructive feedback onboard
Also known as “My baby is not ugly!” Contradicting my last point, it is also important to spot when someone is giving you helpful feedback. Listen to early feedback for your game. Perhaps the mechanic needs a bit of rethinking. Maybe the controls or gameplay aren’t as intuitive as you thought. Good or bad, take all constructive feedback onboard. Learn from it. It is painful to have to listen to criticism sometimes, but it’s more painful when your game or product is shunned because you didn’t listen.

So, that’s actually 11 pitfalls. And unfortunately, there are more. Many more. But if you can dodge these ones, I think you can be successful in any venture, not just indie games.

And maybe, just maybe, my baby might enable you to make enough money so you don’t have to look for early-stage funding (without dirtying your game up with more intrusive ad solutions). It’s best to get a team and prototype well-developed with some customers before you try to raise funds, or you end up giving too much of the business away.

篇目3,Using independent teams to scale a small company: A look at how games company Wooga works

By Jesper Richter-Reichhelm

Jesper Richter-Reichhelm is Head of Engineering at social games company Wooga. Here he gives an insight into the firm’s internal organization.

At the end of last year, a document was published that described how Spotify works using a decentralized approach of tribes and squads. Since then, the article stuck with me. It made me realize we were not alone in this approach of fostering independent teams and with this article I want to contribute to the discussion and challenge a few conceptions.

I also want to explain that it is possible to have a truly agile work environment based on small, autonomous teams. It’s no small feat though, it takes effort everyday to keep this structure working smoothly. The following is a work in progress summary of how keeping teams independent can help scale a company, using my experience at Wooga as an example.

Wooga – now and then

Wooga was founded 2009 with a vision that by 2020, everyone will be playing games. Four years ago we had around 20 employees and now there are more than 250 employees from 40 nations all working in our Berlin office.

While that employee growth is a byproduct of economic success, in the process of growing it was a big challenge to not lose the company culture we had built. In the early days everyone in the company worked closely together and were not slowed down having to wait for approvals. Normally as a company grows this changes as management layers are added, and work simply becomes less efficient.

How did we hold onto that culture? The answer: centering everything around independent game teams. We had doubts about this approach, but we believed it would be worth the effort to at least try.

Wooga is a collection of many small, independent teams. Each team is responsible for making and running a single game and is expected to make their own decisions while being cross-functional and autonomous. They should freely share learnings and don’t compete with each other, meaning they effectively act like small, independent start-ups within a larger framework.

It’s completely up to them if they want to listen or ignore outside advice – even if it’s from one of the founders. This is only possible by having great people. So hiring the right people is the single most important thing we do at Wooga. We believe in the mantra, “If in doubt, don’t hire.” That works very well.

Teams

Teams are at the heart of how Wooga is organized. 70% of employees are working in a game team. There are departmental heads, such as the Head of Engineering of which we have two who take care of different parts of that field, and others that look after their respective departments.

The rest are providing central services like marketing, customer care and localization (20%) or others like HR, PR, Finance, Business Analytics and teams that maintain simple services for persistence of games. “Service” is the key word here – those teams serve the game teams and not the other way around. For example there are no artificial budget processes and game teams can decide release dates themselves.

Each game team is led by a product lead that has the final decision for the team. This ensures a fast decision is always possible and the company can scale without top management becoming a bottleneck. In essence this is a delegation of power from central management to the teams. This starts with the type of game a product lead wants to make and ends with the way the teams organize themselves internally.

Teams start small with 1-3 people, with the first always being the future lead and providing the initial concept of the game. They develop a prototype that can be reviewed and most importantly, play tested. If it’s not good enough, the team starts afresh. If it looks promising, the team is ramped up slowly, keeping it below 10 people for as long as possible.

After going live the team size can remain stable or be increased. Further feature development does not slow down the development process but as extra information is derived from live metrics, a/b testing becomes possible and the whole game needs to be operated.

Knowledge sharing

An important point is that even though teams are independent and compare KPIs, they do not compete with each other. There is a constant exchange of knowledge and lessons learned between them. This is how we leverage the innovations made by individual teams (and compensate risks individual teams take).

On one level this is done by each team being asked to provide a 5-10 minute weekly meeting where they report their progress to the rest of the company and explain their learnings, which could be from something like previous a/b tests or new feature announcements. There are no limits or off areas regarding which information can be shared as long as others can benefit from the information.

Also, these meeting are open for every employee to attend. This way we can try out new things in one game, and when they work, that knowledge is spread to other teams. This works quite organically.

Another level of knowledge exchange is between members of the same discipline. We organize monthly internal lightning talk rounds called “5 minutes of fame” where anyone in the company can give a short talk regarding something they want to share and everyone can attend these talks. It’s a good way to spread knowledge and start discussion throughout the company and increase networking. We have specialized meetups for backend development, frontend development, game design, business analytics and art.

Whenever a topic is too complex to handle it in a lightning talk we do brown bag talks. This is a lunchtime talk where participants get a free lunch after the 25-minute talk. Half of the company usually attends these talks of which we have about one per month.

The brown bags are held in our auditorium area where our weekly company meeting takes place every Monday morning. It’s a 15-minute meeting where new hires get a warm welcome, company strategy is presented and announcements like game releases are made. It’s an important start to the week, and helps to keep everyone in the company connected and informed.
Cooperation

Since teams are cross-functional there is a wide range of skills to utilize and good teams organize themselves with members working closely together. Again the idea is not to have a single person knowing and deciding everything, but making it the responsibility of every team member to push the game forward.

Teams themselves are autonomous and do not depend on other teams to create and run their game. As a result teams do their own analytics while using a shared service provided by the Business Analytics service team and a few standardized KPIs. Similarly there is no operation/admin team to operate the servers or other parts of infrastructure. Those who write the software operate it themselves. Engineers are not forced to share or reuse code, so there is no central framework that everyone must use.

Instead, private and public repositories emerge on github when engineers want to reuse code, but they also have the option to start from scratch. This is a conscious trade-off: we sometimes reinvent the wheel and repeat mistakes, but the company as a whole is much more flexible and innovative. Existing teams are not slowed down when new teams start and the overall communication overhead remains small.

Those who have heard the theory behind Dunbar’s number will know that group coherence will start to dissolve when it grows beyond 150 members. At Wooga we rely heavily on team members proactively reaching out to other game teams to learn from their experiences and be aware of what those other teams have learned in the past. To assist communication we grouped together teams into studios. This is a work in progress strategy but so far it looks good.

Being agile

We think agile development is not about applying a specific methodology, it is about following the correct principles and to constantly reflect on whether you are aligned correctly and to correct things when necessary.

As a result there is no unified process on how teams should develop their software. Teams decide on their own how to do things, although they usually blend in elements of Scrum and/or Kanban. That means stand-ups in the morning are the standard, although variations do exist.

There are some constraints though:

Teams work in weekly iterations and present progress and learnings in weekly meetings to the rest of the company.

Small prototyping teams need to get a green light to develop a full game. A lot of prototypes do not pass this stage which allows us to play test many new game ideas in a short time. “Failure” at this stage is part of the process. Lessons learned from cancelled games are shared within the company.

All source code is available to everyone in the company.

All KPIs and metrics are available to everyone in the company.

We expect people to think and decide on their own using common sense. We try to avoid formalizing processes as the resulting rule book wouldn’t be flexible enough. There are some common principles to guide individual decisions and sometimes reminders are necessary but overall it works well.

Conclusion

I joined Wooga when we were just 10 employees in 2009. Over time the founders attitude to work lead to an organic evolution of the company based on everyone being responsible for their own work, their own team and ultimately their own company. Being independent and working autonomously are the common threads in every approach we take at Wooga.

This had lead to a culture where taking ownership is emphasized and expected. People are trusted to make the right decisions and they do make the right decisions most of the time. Of course sometimes people do make mistakes but since they don’t try to hide them it’s actually quite easy to fix things.

篇目4,Playfish’s Jeferson Valadares on teams as business units, social game evolution and managing the company’s culture

by Vlad Micu

Playfish London’s studio director Jeferson Valadares and his team have a big task ahead of them. Their mission: figure out what’s next for social games. For Valadares, that means bringing out more social emotions and narrative in games. “The first generation was about competition and leaderboards, but the second generation is more about self-expression,” says Valadares. “We’re still waiting to see what is going to be next and how to make use of the changing user experience on Facebook.” We sat down with him to talk about teams as business units, the next step in social game evolution and managing a company’s culture worldwide.

Little big teams

“We spend a lot of time experimenting on our live games,” says Valadares. “Every week, there’s always something new in a game. The benefit of having a lot of games and big audience is that you can try these things out in different games and see what works.” With each team at Playfish managing their game as a small business unit, this process allows them to easily find out which new features work well. The individual teams then take the successful features and appropriate them into their own game.

“There are teams that are starting new games now, and these are the teams that are trying different types of game concepts,” says Valadares. One of those new teams at Valadares’ studio has started to take a more collaborative approach to playing social games. According to Valadares, the goal was to figure out how this could minimize the amount of friends playing a social game, but increase the social relationship between them. “Instead of doing something with ten people you are just colleagues with, why don’t you do something with three people you’re friends with,” explains Valadares.

Quality > quantity

With an increasing amount of game companies focusing on social games, the social game space has experienced exponential growth in the past couple of years.
Valadares sees the positive side of this growth, not only encouraging his own colleagues to experiment more, but also hoping to see more of that around him.

“When the space gets this big, there is space for people to do some unique things which might not be for everyone,” he argues. “But there are enough people who are interested in that to be successful.”

Aside from experimentation, Valadares is also noticing a rise in projects that involve cooperative game modes. Whether or not that could translate into social games is still not clear. “It could be,” says Valadares. “I’m not sure whether that’s going to happen in the short-term though, just because the more high-end you get, the more computing you need. Unless we move to things like OnLive, where you don’t need a strong computer when those things take off, then we’ll see social high-end as well.”

Fresh inspiration

“Sometimes we look at board games,” admits Valadares. “The value of having good writing, a good story. It’s something that is really compelling to people in general.” There are lots of things Valadares would like to see in the social space. “A really great story-based game, because a story is something that is very strong for humans, always has been, and I suspect always will be. So how can we weave that in with the social experience more strongly? There have been a few shallow attempts.”

Playfish culture

Undergoing substantial growth, Valadares’ studio in London is very much struggling to keep their corporate culture in place. “We’ve been growing a lot, there are maybe three people who have left in the last year or so,” says Valadares. “I think that’s pretty good. We’re still hiring a lot. I think the company is four times bigger then when I joined, which was a little over a year ago.”

Because of that growth, Valadares has been constantly asking himself “how we can celebrate success and not forget the reason we do things.” With new offices starting in different areas of the world, a lot of Playfish people are moving around trying to maintain that same culture everywhere. “In London, everybody kind of sees what’s happening, but it’s harder to keep the other studios connected,” admits Valadares. “We’re still trying to grow while maintaining the creative spirit that we had in the beginning.”

But baring in mind the particular cultures of the regions each Playfish office is located in, some of those cultural variations should also be encouraged. “In China, the guys in the office like their particular games,” explains Valadares. “In the past, we tried to make them do Western games, but what we actually realized is that they’re better doing what they understand. That’s exactly why we have an office in the US, Europe and Asia.”

篇目5,Two simple factors that can compromise team productivity

by Marcelo Spiezzi Raimbault

The greatest challenge in game development is not learning new technologies, building the best tool or even finding the fun. The true challenge and nightmare of many developers is how to build and maintain a productive team. By a simple logical perspective, creating games is nothing more than following a series of steps in a correct order. However, games are made by people and not by machines (luckily!), and that’s when things can start to go really bad.

Many situations can lead to a team failing. It can go from the individual level to the organization he belongs. Understanding why a team fails can be much more important than knowing what makes a team succeeds. Communication that Damages Teamwork: Dark Side of Teams is a good paper that summarizes different problems that may lead a team to fail. In this blog post, I’ll talk about two big problems mentioned on the paper that happened during the development of Cult, a student project developed at The Guildhall at SMU, and that are likely to happen in any game development team.

Ambiguous Goals

I thought that was right… Ambiguous goals are probably the most critical problem for any project. During development, it is easy to get lost in ideas, processes, details, and forget about what really needs to be done. It is important that all team members clearly see and fully understand the goals for that particular sprint/milestone. When goals are unclear, people are likely to spend their time in unnecessary tasks or even waste time doing the tasks incorrectly.

Unfortunately, this problem may goes unnoticed. First, leads usually have a clearer idea of the project and may assume that the rest of the team also has this same comprehension. Second, team leads can focus only on their tasks and forget to give the proper attention and set clear goals for other tasks.

One important insight for team leaders is that not providing clear goals to all team members can even affect their perception of trust. Team members may think that tasks are not clear/available because the lead does not trust them enough for specific tasks. And a team without trust is a low productivity team.

Without clearly defined goals, there is no way for a team to be autonomous, and only a team with enough autonomy can develop its own path and achieve high levels of productivity.

The feeling of urgency

Deadlines! Although a word that can make any developer cry, deadlines are essential for a team tobe productive. We know that a game is never finished. Games can always be improved and that is exactly why deadlines need to exist.

It is easy to find a successfully backed Kickstarter project or an independent game that failed for not having enough money to finish the project. Usually, undefined development time is the main reason behind these failures. People mainly act based on a feeling of urgency. If there is not enough reason to do something for tomorrow, people probably won’t do it today. We may believe that we are not like everyone else, and that we do all our tasks as soon as possible. However, that is not how things happen in a team project, even more in a creative environment as game development. If there is no feeling of urgency, the project won’t move as fast as it could and may not reach the functionalities needed when the time comes.

Creating short time deliverables is a good way to keep the feeling of urgency always high in the team (Agile development and Scrum really comes in handy here!). Always keep in mind that an essential feature not finished now, is a feature that needs to be finished later.

Deadlines problems also build on top of ambiguous goals. Clear and precise goals are essential for a project to be timed right. It is pointless to have many short time deliverables if their goals are not clear and the team cannot tell when they were achieved or not.

First, understand your problems!

As a last word, there will always be a new “top 10 tips for a successful team”, but the reasons of why a team may fail will never change. The best way to increase a team productivity is to address and remove the issues decreasing it.

篇目6,Creating an Iterative Culture

by Seth Sivak

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

This is cross-posted from the Proletariat Blog

The best games come from iteration, but how can we build that into our process and culture? This is something we have worked hard to create at Proletariat and we push every day to foster this culture. Here are three important steps to creating a culture of iteration within your own team:

1. Constantly review

Goal: Everyone on the team helps each other create the best work possible in a constructive manner.

The first step in creating an iterative culture is for team members to constantly review their work with the rest of the team. While uncomfortable at first, especially when work is in-progress, it’s critical to establishing feedback loops within the team. At Proletariat, we formally do this on Fridays in our weekly review meetings (which we stream live on Twitch) and informally with smaller groups.

Action Item: Create review steps in the process where people from all different disciplines can give feedback on ideas. Start these formally and then allow them to develop organically.

2. Nothing is ever “done”

Goal: Stay flexible with features so that team members can return to past work and polish it while the game evolves.

The constant review process will get the team comfortable showing work that isn’t complete. The next step is to make it clear that nothing is ever “done”. There’s always room for improvement or polish, whether it is art, design, or code. As the game continues to evolve and features are completed, multiple passes may be required. The idea that it’s not done means that the team can move on knowing they’ll have a chance to return to features later and iterate on them. This only works if the team trusts the producers and the schedule.

At Proletariat, we build lists into our backlog that contain issues the team wants to re-address. At the end of every milestone, we try to leave a week to work on the backlog, which we call a “debt” week. Team members can work on their own, prioritizing the parts of their work they feel need the most attention.

Action Item: Build lists in the backlog with pieces that require polish. Provide frequent breaks during the development process to let the team dig into the backlog.

3. Give it away

Goal: Allow for open and honest feedback and ideas to encourage the team to not hold on to a single personal idea.

It is common to see developers struggle to let go of “their” idea, hurting the process. Instead of focusing on letting an idea go, put the focus on giving the idea away so the rest of the team can build from it.

Everyone on the team is expected to throw ideas into the pile and what comes out is the result of the process. Each member of the team must understand that the moment an idea is spoken aloud to the group it is no longer their idea. This is the same for any art, music, sound, or code. I like to think about this as not letting go of your ideas but instead giving them away to the team. Members are expected to contribute their creative talents and that is a great gift to the final product.

Action Item: Be critical of ideas but not their sources. Develop a process that can objectively analyze options in game context.

Conclusion

Creating a culture of iteration takes time and focus from the entire team. Priorities need to be shifted and changes to the process can certainly take a toll on development. However, once this culture is established, it can enable the team to push each other to create their best work in a positive, collaborative environment.

篇目7,7 Production Guidelines

by Samuel Rantaeskola

Previously I wrote a post about the common mistakes of a producer, which you can find here: Top 6 production mistakes. As with raising children, it is easier to say what not to do than to describe the opposite. Nevertheless, just writing about the mistakes is not helpful unless you take a stab at describing the proper thing to do. So here we go.

We have all heard stories about the hero producers that carried whole productions on their shoulders. The stories include components of great personal sacrifice and extreme commitment. What is often left out is what happened afterwards, a hero that had to recover a year from the stress syndromes and a team in chaos because the engine was not available anymore. This person might be the best solution to get something out the door immediately, but I doubt he is the best to build teams that function in the long run.

Producing is mainly leadership, not project management, and how to lead people differs from person to person. Leaders that are comfortable on stage might execute a lot of their leadership in front of the team, while the ones that prefer intimate environments might want to work more with one-on-ones. The type of leadership required is also highly dependent of the situation. But given that most game studios consists of quite a lot of young people, this article in Forbes about how young people want to be led is a good read if you are an aspiring producer.

Unfortunately there is not a single recipe for successful producing, any advice I can share on this topic has to be focused on how to think rather than exact advice on what to do. Anyone taking on that role of producer will have to find the best solutions for the people and situation they are in. That brings me to the first point of the list.

1. Adapt to the situation

As mentioned earlier there is no generic advice that works in every situation. This means that producers need to be very flexible and good readers of situations. They need to have a wide range of tools that they can adapt to the problem at hand. I know that this is a very hard advice to take in, but this mindset is required to be successful.

2. Be a great listener

A producer’s job is to find the wisdom in the team and make sure that is used. They cannot do that by constantly broadcasting their own message and ignoring the voice of the others. Therefore I am a firm believer that being a great listener is one of the most important traits of a leader. Apart from missing the opportunity to gaining valuable information, the talkative producer ignores the fact that people need to feel listened to in order to accept leadership. The following article explains this in more detail: Leadership & The Power of Listening.

For extroverts, like me, this is a tough advice to apply as speaking is part of our thinking process.

3. Trust people

The feeling of not being trusted will bring down the morale of any person and will also make them less likely to take responsibility for their work. Producer must do their best to show that they trust the judgment of each and every one on the team. Even in instances where they have their internal doubts. This also means that there needs to be tolerance for mistakes as they are part of the growing process. The producer should strive towards helping team members to learn from their mistakes over throwing rants.

4. Be a great teacher

The producer’s ultimate goal is to build a system that works without him, essentially making him redundant. When the team encounters problems that they are struggling with it is often tempting for the producer to take them on personally and ensure they are solved quickly. The great producer will focus his effort on aiding the team on learning from the problem so that they grow. Next time a similar situation comes up the team will be able to get through it without the assistance of the producer.

5. Seek long term solutions

Short term thinking will never get anyone out of a hole for more than a short period. The producer must continuously assess situations and look for long term solutions when problems occur. If he is too engaged in solving the problem it is easy to forget to fix the problem long term. The producer must rely on the team to solve it and spend his energy on devising a plan in collaboration with the team on how to prevent it from reoccurring. This was a big problem for me personally when I was acting as producer, as my itchy fingers really wanted to be in on the fixing.

6. Be goal driven

Everything producers do should be goal driven, as opposed to task driven. When they spend their time detailing the path to the goals and breaking that down to tasks they are usually overlooking the fact that the team is way more capable of this. The challenge lies in describing the goals and helping the team understand why it needs to be done. This brings me to the most important point of this. Producer must remember to explain why to the team. For example, if a new way of working is rolled out in the team it is as important to explain the goals of it as how it works. Without that explanation the buy in for the process will probably be low, as the team members might not see the value. On top of that the producer is missing out on the possible improvements that can come from the team if they are bought into the goal.

7. Obey the rules

This almost goes without saying; producers are part of the team, which means that they should play by the same rules as the rest. If the agreed start time is 10 AM, then the producer better be there. If the team works late for a deadline, the producer better be there. Leaders cannot expect more of the team than from themselves.

Most of the advice I have given in this post is focused on how a producer should interact with the team. These are my views on how they should think in order to build a long term successful team. However, situations differ and I do not think you can follow these guidelines all the time. Producers will often have to diverge from them and get their hands dirty in pressing situations. But they should strive towards making these situations the exception rather than the rule.