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

篇目1,解析消極開發者對於團隊的影響及解決方法

作者:Lee Winder

當我們一開始進入一個團隊時並不會產生太多消極情緒,但是當我們努力去發展一個團隊並開始鼓舞團隊士氣和鬥志時,這種消極情緒便會一點一點滲透出來。以下內容並非對於世界各地開發團隊的深度研究,而是我在過去10幾年來通過管理和觀察各種團隊所獲得的經驗教訓。

當我們着眼於一個團隊的構成時,它總是會包含一些能夠有效完成遊戲創作的人以及某些會糟蹋了整體遊戲的人。任何一個項目開發總是會匯聚一些個體,然後詢問他們是否願意爲了達到一個共同目標而暫時一起工作。而這些不同個體所具有的不同個性有可能會促就一款成功的遊戲,也有可能會徹底毀掉一款遊戲。

很明確的一個現實便是,比起使用各種有效的方式去完善團隊,任何個體總是能夠更加輕鬆地摧毀一個團隊。也就是消極性總是能夠以燎原之火般的速度在團隊中迅速蔓延,而積極性卻如糖漿一般難以擴散。

negative(from robertfagan.com)

negative(from robertfagan.com)

這是爲什麼?

工作中的個體總是更容易產生消極態度。消極做事,大談團隊的壞話甚至是破壞遊戲的行爲總比創造更多優秀的內容,對自己的工作負責,走出一個定義清晰的角色或完成任何有意義的工作簡單得多。

消極開發者的定義是什麼?

開發者將會以多種不同的方式帶給一個團隊消極影響。最明顯的便是他們對於當前項目所持有的態度,如無端的抱怨,莫名地推脫工作要求或在上班時間偷懶等。

他們可能在開發過程中未能呈現出更多技能,或影響了開發產品的質量。

有時候這些開發者的態度並不能體現出團隊所追求的精神。也許你要求開發者對自己的工作(遊戲邦注:包括設計與執行)承擔更大的責任,但是某些開發者卻只會執行上頭所交付的相關工作。

可能開發者並未參加日常會議,或者只是含糊地陳述了一些觀點,並明顯透露出對別人工作的毫不關心。

不管怎樣,我們能夠很容易明確開發者的消極態度對於一個團隊的影響。這也是我們在開發過程中最難處理的一塊領域。

團隊開發

讓我們通過一定的情景進行分析,綠色代表“積極”開發者,紅色則代表“消極”開發者。

在第一種情景中,兩位開發者將並肩工作,一名開發者表現良好,而另外一名則沒有多大成效。也許其中一名開發者是抱着消極的態度,也許他只是不想爭取更好的結果。不管出於何種原因,他對團隊所做出的貢獻始終都不如積極開發者。

developers(from gamasutra)

developers(from gamasutra)

大部分情況下,這種情景只會促成一種結果。積極開發者在看到搭檔總是逃避工作並且未投入足夠的努力後,他便也會慢慢產生怠倦心理,並逐漸變成消極開發者。

通常情況下消極開發者並不會因爲看到積極開發者的辛勤工作而轉變自己的態度。所以最終你便只會同時擁有兩名消極開發者。

developers(from gamasutra)

developers(from gamasutra)

什麼情況下態勢纔會發生改變?什麼時候消極開發者纔會認清事實並開始努力發展遊戲?我想這些答案都不會有多大的激勵效果。

以下是另一種情景:

developers(from gamasutra)

developers(from gamasutra)

這是一種較爲平衡的情景,但是同時開發者也更容易忽視產品的質量而不是想辦法去完善它,即他們很容易走上錯誤的發展方向。

developers(from gamasutra)

developers(from gamasutra)

基於各種觀察,你最終獲得好結果的比例爲3:1,但是這仍是一種具有風險的方法,因爲當積極開發者開始出現態度轉變時,這一比例將重新回到之前的1:1。

developers(from gamasutra)

developers(from gamasutra)

如果你所擁有的積極開發者和消極開發者的比例爲4+:1,你便需要努力確保其他開發者不會出現態度動搖的情況。在很多情況下,消極開發者並不能憑藉自己的力量做出改變,其他開發者也不會因爲比自己更優秀的開發者所帶來的同儕壓力而發生改變。

developers(from gamasutra)

developers(from gamasutra)

積極開發者

但是不管是面對何種情景,我都不敢保證積極開發者始終都能夠帶給團隊積極影響。優秀的開發者並不能輕易放鬆,他必須更加努力地工作,不斷創造出更優秀的內容,並帶着更大的雄心而發展。

讓我們再看看以下的情景:

developers(from gamasutra)

developers(from gamasutra)

這些開發者之所以優秀都是有原因的,要麼具有較高的個人自豪感,要麼具有較強的野心,或者是純粹地享受着工作帶給自己的樂趣。而如果優秀的開發者長期待在一個滿是消極開發者的空間,那麼最終結果也是可想而知了。

developers(from gamasutra)

developers(from gamasutra)

如果積極開發者處在一個充滿了消極開發者的工作環境中,或者積極開發者很難在此感受到真正的推動力量,他們的態度便會很容易出現動搖。而一旦你失去了更多的積極開發者,你便會發現有越來越多開發者意識到自己不再有積極工作的必要了。

解決問題

面對團隊中的消極開發者主要有兩種方法。第一種方法較爲強硬,但是如果你身處的區域具有健全的勞動法,你便不適合使用這一方法。

即辭退這些開發者。

developers(from gamasutra)

developers(from gamasutra)

老實說我並不推薦這種方法。因爲這麼做雖然能夠解決問題,但是卻會在團隊中留下一些漏洞,你之所以會僱傭這些開發者肯定是出於某種原因,那麼你何不嘗試着去找回他們身上的這些亮點?

而組織內部的執行管理結構(如果使用得當的話)不僅能夠解決這一問題,同時還能幫助消極開發者重新正視遊戲並努力成爲團隊中的佼佼者。

明確問題的來源。是因爲開發者不喜歡遊戲還是他們在工作以外的時間遇到了某些困難,是因爲他們不認可上司的工作分配還是他們根本不想待在這一團隊中?

基於這些回答,你才能採取更合適的應對方法。。

明確目標。設定那些能夠扭轉局面的目標,不要只是設定好便不再搭理。每週或每兩週去審查目標的的落實情況,設定一些短期目標與長期目標形成互補。

設定一個明確的截止時間。不要因爲一些微小改進而不斷拖延時間,只有明確的截止期限才能讓你更加重視自己的工作。

明確最終結果。不管他們是否有機會去嘗試其它工作或者只能終止合約,你都必須讓團隊成員清楚在完成目標或錯失目標時會出現何種結果。

保持穩定的記錄。記錄下每次會議的內容,並且每天去記錄所有目標的發展過程或最終結果。

辭退他們。儘管這麼做較爲殘忍,但是如果你所採取的任何方法都沒有成效,你便別無選擇了。如果你一直在嘗試着解決這一問題但是開發者卻對此無動於衷,你便只能採取這一方法了。

在健全的勞動法律條款下,如果你所遵循的是績效管理策略,你便可以在改造開發者無效的前提下與之解除合約。

消極開發者的消極性是基於他們對於團隊目標的影響,以及對於其他開發者所帶來負面影響。消極態度的蔓延速度總是會大大超出你的想象,並且將會導致你的團隊中的其他人拉低了自己的真實能力標準,或最終選擇離開團隊。

篇目2,總結開發者在合作過程中的典型交流方式

作者:Cliff Bleszinski

到今年夏天,我從事職業遊戲設計就到第20個年頭了。我曾領導團隊設計平臺遊戲、FPS、單機遊戲、多人遊戲等等。我曾和一些最令人歎服的程序師、美術人員、動畫師、寫手和製作人共事。這20年以來,我注意到創意人員經常使用的交流方法。

我知道雖然開發人都非常高明,但有時候他們並不敢肯定與同行相比自己能有多聰明。我曾看到開發者在留言板上對百萬美元的遊戲大作、獨立遊戲寵兒等過度分析、吹毛求疵。我們總想證明自己比其他人有先見之明,或者引用一個例子,說明那個創意已經被嘗試了、能成功、會失敗或行不通等。

開發者們爲了“贏得”得談話,經常會使用一些討論、爭論和辨論方式。本文要介紹的就是這些常用手段。

以下說法和綽號沒有惡意地針對誰;事實上,有幾個方法確實是因爲有理有據才被使用的。例如,樣式對比可以避免製作出派生產品;邊界案例有時候可以抹殺可靠的想法。以下就是我所謂的交流“技巧”。

“樣式對比”

這是指開發人爲了否絕一個創意,立刻在他的頭腦中檢索他的遊戲/流行文化庫,然後找出最接近的想法作爲比較對象(常常是糟糕的或失敗的案例)。

以《阿凡達》爲例,“你想製作一部關於藍皮膚的人在叢林中對抗壞人類的軍隊和機器?什麼,藍精靈叢林大戰外星人?”不恰當地類比,《戰爭機器》可以看作是80年代的低級恐怖電影《C.H.U.D》(遊戲邦注:在電影《C.H.U.D》中有一種生活在城市底下的基因突變人,以食人肉爲生,而《戰爭機器》中也存在類似的怪物)。

“邊界阻塞”

這是指用一個邊界情況來否絕可能很了不起的想法。例如,舉出邊界情況的人可以否定在《天際》中創造一個大世界的想法,因爲擔心玩家要走回原來的地方,且步行太老套。清楚明確的修改方法如“快速旅行”的可以輕易地解決這個大世界問題。

邊界阻塞有變體:

“交際人”:這是指因爲某個想法在邊界情況或特定的合作模式中不成立就否決它——這是邊界阻塞的變體。“《英雄本色》的慢動作怎麼可能在合作模式中起作用?不可能!”

“完美主義者”:類似於邊界阻塞。這是指開發者發現在某種情況下,一個很不錯的設定可能看起來並不完美。比如,格鬥動作有時候會導致角色發生微小的變化。

“從來沒見過做得好的”

這句話的意思也就是“我以前從來沒見過這種想法行得通或做得好的。所以,我們不應該這麼做。”這是一種相當不言自明的論斷,事實上,這也可能是爲什麼應該執行某個想法的理由。按這種邏輯,所有創意都只能是雷同的。

比如,在《戰爭機器》中設定了一種生活在地下的Locust人,這個設定行得通的原因有很多,但我們仍然對它持保留意見。畢竟,這個設定使該遊戲從其他帶有常規外星人的遊戲中脫穎而出。

“故意唱反調的人”

爲了保全顏面,大多數開發人經常故意唱反調,甚至在他們自己也相信這個想法時候。律師經常使用這一招。

“不過是X+Y罷了”

這是指開發者懷着酸葡萄心理貶低其他成功的作品,因爲他可以輕易地看出其中的原理。事實上,正是因爲遊戲原理非常簡單明顯,才使遊戲如此成功。

例如,《Words with Friends》:“不過是異步拼字遊戲罷了。”是的,正是如此,所以它成功了。

“以後再說”

當開發者聽到一個想法——無論好壞,就說這個想法很適合之後的版本或續作。這句話的真實含義是,“我認爲這個想法不值一試,所以我們放棄吧,我說以後再說是爲了讓你不難受。”

tower of babe(from gamasutra)

tower of babe(from gamasutra)

“通天塔”

這是當開發者在一個本來很簡單的設定上堆砌太多額外的小東西時,但這些小東西最終危及整個設定。這座“通天塔”是被自己的重量壓跨的。

“雪崩效應”

之所以用這個方法否絕一個想法,是因爲這個想法需要許多其他部門(遊戲邦注:如動畫、UI或美術)做更多工作。通常,有趣或值得嘗試的特點都會牽涉到更多部門,因爲涉及多個學科的知識。

“過度分析”

這個常用的詞是指過分考慮某個想法,以致於一事無成。

“試什麼試?”

換句話說,“我們怎麼跟別人比?”因爲在某個方面面臨激烈的競爭,開發者就這麼問,以免嘗試。

“他們有N個開發者啊!”

當開發者說到某個競爭團隊的規模有多大時就會這麼說,說完這句話以後緊接的就是上面那句。爲了高效地工作,Epic公司總是讓最好的人從事同一個任務,用最好的工具。

“保守主義者”

“但是我們一般都是這麼做的啊!”在娛樂行業,特別是與技術有關的行業,爲了生存,創意和反思是非常必要的。自滿和墨守成規必然導致失敗。

在某個常規行業工作20年可能是個優勢,但在技術行業,這可能會成爲你的絆腳石。作爲開發者,越要保持眼界開闊,要活到老學到老。

“但我們是XXX(“XXX”指工作室名稱)

當工作室準備將自己的名譽押在某個項目的成功上時,就會發出這樣的戰鬥口號,還自認爲很強大。當工作室的人這麼說的時候,你就知道這個工作室離內亂的日子不遠了,因爲更年輕的新員工滿懷夢想,總是想取代老員工、創造新的輝煌。

“我們以前就試過了”

爲了否定舊想法的替代方案(可能行得通),就提出以前嘗試舊想法失敗的經歷。

“太先進了”

你的想法太棒了!事實上,這個想法太前衛太創新了。所以,我們不應該嘗試,因爲聽起來挺費功夫的。

“按我們這行的話說……”

這是指,爲了在爭論中佔上風,開發人拋出只有他自己專業的人才懂的術語,使不同專業的其他開發人不知所云。例如,程序員用代碼的原理跟美術人員討論,設計師用設計行話向動畫師解釋。

“部落首領”

當開發人固執地信仰自己的專業(美術、編程、設計等),而排斥工作室裏其他專業的人的見解。

“不在範圍之內”

“這個想法很好,但不在我們的項目範圍之內。”很不幸,有時候,最好的想法不會在原本的計劃之內。

“測試把戲”

開發人爲了否絕某個新設定、新武器,就強烈建議“和諧”它,他的方法是在測試時變更它,這樣遊戲就按着他的思路設計了。有時候,人們爲自己的想法付出了很多努力,結果卻被別人破壞了,遇上這種情況,看開了就好。

“學舌”

這是指一類人,他們聽到你的想法,反而像從來沒聽過似的,用自己的話把你的想法當成自己的說出來,還忘記自己是從哪聽到這個想法。這從根本上說沒什麼大不了的,只要這個創意行得通就行了。

“長篇大論”

這類人用三頁長的郵件迴應設計建議或討論。

每次都是這樣,最終,你得爲這個人設一個專門的文件夾。

e-douche(from gamasutra)

e-douche(from gamasutra)

“郵件盲”

這類人在郵件方面似乎總像個徹頭徹尾的傻冒,即使他們並不是故意的。

“哥拉斯”

因爲主觀地認定一個想法不好,這類人莫名其妙地就叫停所有進程,提出自己全新的想法,最終所有人都不得不重新開始。

“懷疑論者”

這類人沒有任何明確的理由就拒絕一個想法,他們的說法是“對此,我不知道……”,卻往往很管用。

the prophet(from gamasutra)

the prophet(from gamasutra)

“先知”

這類人對一個想法懷有一時的衝動熱情,但從未站在設計或其他學科的角度考慮它。這類人單純地希望所有人都相信這個想法會成功,而不是根據它做出原型。這往往是年輕的、沒經驗的設計師的舉動。

“亞哈船長”(遊戲邦注:這是小說《白鯨》中的人物,固執地想找白鯨復仇。)

這類人拒絕承認某個想法行不通,同時不斷地嘗試,不惜浪費珍貴的代碼和美術資源,妄想有一天,這個想法會成功。

“數據控”

這類人出現的情況是:“這個表格中的數據客觀公正地表明,你的想法永遠不會成功,你會使很多人不愉快,這個方向我們不能走。”

“精神期望”

這是指一個程序師拒絕理解被提出來的設想,直到這個設想以程序師自己想的方式被要求執行時。

“無視”

這類開發人有意(或無意)地忽略可能會成功的想法。

“事不關己”

這類設計師口口聲聲說想要創意,聽了別人的想法後又默默地忽略任何不是他自己想出來的東西。

the gardener(from gamasutra)

the gardener(from gamasutra)

“園丁”

園丁早早地種下了想法的種子,然後多次在會議上提起,甚至與他人閒聊時也不忘說上一句。最後,這個想法開始在其他人心裏生根發芽,直到它成爲遊戲中的一部分,都沒有人記得這個想法最初是從哪冒出來的。這確實是個實用的技巧。

“漏洞仔”

當進程中出現一個設定,設計師不考慮這個設定的目的或作用,只顧着指出明顯的錯誤,而這些錯誤顯然是最終能解決的。

multi boss(from gamaustra)

multi boss(from gamaustra)

“多個頭領”

當一個人沒有明確的頂頭上司,不知道該聽誰的發號施令時,他往往會聽從多個人的指揮。設計總監、執行製作人和董事可能各有自己的觀點,讓沒有明確上司的員工感到困惑不堪。

“打包票”

這個詞是指發言人向媒體承諾某個設定,讓團隊不得不按他放出的話來做。

“隨大流”

創意人員看到最近遊戲的遊戲中有什麼,他就採納什麼,心想這樣就可以做出好遊戲,也省了想法子創新。

總而言之,以上就是我這些年見識過的開發人的個性的交流“技術”。多謝了在Epic、ChAIR和People Can Fly的同行們爲我提供的材料。我希望有遠見的開發人可以意識到這些問題,並相應地改正。我也希望此文能讓博得創意人員的會心一笑。

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

作者: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也是一個日語單詞,即關於持續完善內容。製作人,產品管理者,利益相關者和內容創造者都必須不斷尋找完善他們工作工程的各種方法。這必須實踐於所有項目中,如此結果纔會在不斷的迭代中得到完善。

結論

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

篇目4,溝通也是一種重要的遊戲開發技能

知道如何開口和有效寫作與知道如何編程、使用Photoshop、遵守設計流程、創建關卡、作曲或者準備音頻一樣重要。這些都是某人在準備好將溝通這種技能呈現給團隊之前所需要學習的技術,需要掌握的概念,以及需要完成的練習。

遊戲開發者尤其如此

當然,世上人人都需要溝能,並且可以從中獲得更多益處。但我們爲何專挑遊戲開發者來講?

我並不是說只有遊戲開發者才存在溝通問題。但根據過去十年與數百名計算機科學系的學生、獨立開發者以及專業軟件工程師打交道的經驗,我可以說我所遇到的遊戲開發者普遍存在一個特定的溝通問題。這也是我們所面臨的一個特殊問題,因爲這並不單關係到一天的工作是否順利,我們的溝通能力還會對我們是否能夠合作甚至是獨立完成工作產生實實在在的影響。遊戲開發者通常爲自己的工作而興奮,但無論是因爲技術侷限性還是因爲溝通侷限性而導致某些很棒的功能無法實現,那都會讓遊戲遭殃。

分清工作職責

如果程序員負責編程,設計師做設計,美術人員做美工,音頻能力制音頻,這裏會有相同的溝通角色嗎?

當然,甚至還有好幾個。

製作人。即使是在小型業餘愛好者或學生團隊中,這通常也會由其他角色所包攬,製作人專注於團隊人員之間,以及團隊成員與外界的溝通問題。有時候這項工作會被誤解爲分配安排,但要制定這種分配計劃則需要大量的交流和郵件往來,以及讓所有人都處於同一軌道的持續溝通。

設計師。設計師在遊戲開發過程中的角色之一就是通過遊戲與玩家溝通。指出遊戲目標是什麼,哪些內容會對玩家受害或者受益,玩家下一步應該去哪裏,從而傳達遊戲的內部狀態信息——這對遊戲設計的影響遠大於編程。根據遊戲團隊的技能組合情況,某些情況下設計師與遊戲的直接工作就是關卡布局或數值調整,如果大家的工作互有交集,設計師與程序員、美術人員及其他人員的溝通交流更爲重要了。在一個人擔任多個角色的小型團隊中,溝通就成了讓其他人知道遊戲狀況的一個必要環節。

主管。在一個擁有主管的大型團隊中(常見於專業團隊),主程序員,主設計師或主美術師還得具有出類拔萃的溝通才能。這些人並不一定需要是最出色的程序員、設計師或美術師——雖然他們當然需要具有這方面技能,但他們是因爲能夠有效領導他人而身居高位,而這又涉及所有方向的大量溝通:與上級、下級之間的溝通,甚至協調上下級和他人之間的溝通。

文案:並非所有遊戲題材都需要文案,但對於那些需要寫作內容的遊戲來說,溝通就顯得更爲重要了。與那些並不身兼程序員一職的設計師相似的是,除了一些實際對話或其他遊戲內置和插頁文本之外,團隊中的文案通常並不直接創造多數內容或功能。會寫一些東西並不能算是稱職的文案,文案和內容創造者還應該同他人頻繁交流,以確保執行效果與自己所想象的世界完美融合。

非開發角色。這一切只考慮到了開發過程中的團隊內部交流。學習如何與測試人員、玩家或者項目消費者和潛在新僱員(這裏甚至還忽略了投資者和財務專業人員)更好地交流,則是另外一個巨大的挑戰,如果團隊規模夠大的話,你還得同人機互動專家、營銷專家、PR人員以及HR員式溝通。如果你是一名業餘愛好者,學生或獨立開發者,你就得自己扮演好這所有的角色。

我們通常遇到的溝通問題有兩種。雖然它們看起來好像是兩個極端,但實際上這兩者之間並沒有看上去那樣涇渭分明。在特定情況下,其中一者甚至可能從另一者演變而來。

Interpersonal-Communication(from onetechgeek.com)

Interpersonal-Communication(from onetechgeek.com)

挑戰1:羞怯

首個問題就是我們有些人比較害羞。我所遇到的一些極具天份的程序員、設計師、美術人員和作曲家就是害羞的人。這實際上會限制他們的創作——如果他們無法大聲說出自己的想法,就可能給遊戲、團隊或者公司造成損失。

不幸的是,我們很容易爲害羞找到藉口。畢竟,這些有才華而害羞的人之所以能夠發展自己的專長,就是因爲他們能夠遠離喧囂,獨善其身地修煉自身本領。但遺憾的是,這種想法不利於幫助他們和團隊從中獲益。

團隊成員之間的交流在遊戲開發過程中的作用不容小覷。有時候你得在3D Studio Max上完成工作,有時候又需要拿出來大家一起討論纔可能完成工作。

我發現害羞的另一個因素在於,人們知道自己所在領域的出色之處,他們總能看到自己的工作要達到自己的預期,還有很大改進空間。

一個人在所在領域的人羣中處於什麼地位並不重要,重要的是項目中的開發者比其他人更清楚其中的不同之處。由於大家的專長、興趣和背景各有不同,所以這就難免會成爲一個問題。

挑戰2:避免爭執

有時候害羞看似由於過去不太成功的互動而形成的過度補償。有人想開口來分享自己的想法,補充他人的觀點,但卻遇到了傷害,也沒有取得什麼成果。參與討論容易讓人們激動和生怒,所以有名開發者在一次無謂的掙扎之後終於放棄了。也許他們覺得自己的想法並沒有得到合理的接受,甚至它根本就不值得自己捲入這種麻煩中。

我的一名大學導師曾經向我指出:“Chris,有時候人們挑戰你的觀點時,他們並不是真的在否定你的說法。他們只是不認同你的表達方式!如果你用不同的方法說法同樣的觀點,可能他們就會支持了。”

他說的完全正確。我聽到這種說法後,除了突然讓自己住嘴,也開始發現其他人也存在這種情況。會議、合作型課堂項目,甚至是人們的日常交流都會產生衝突,那些心地善良,無意冒犯他人之人,確實總體上會認同雙方的目標和觀點,而普通人無意識的敵意升級卻經常引起事與願違的反覆爭執。

造成這種問題的原因和行爲模式有不少。在10年的研究之後,我開始更理解這一點,這種情況仍然時有發生,它仍然是我必須積極應對的情況。

這就不難理解人們在感覺自己融入團隊就是麻煩的起源之前究竟遭遇過多少次這種情況。這種情況的結果就是迴避,降低自己在對話中的個人投入,並服從人們在討論中所達成的一些行動項目。

如果溝通技巧很糟糕,無論其他技術或美術技能再好,你都很難得到他人的幫助,很難得到玩家和評論人員的關注。另一方面,如果你的溝通技能十分了得——極具說服力、清晰、公正而富有條理,那麼你能夠處理的項目範圍和類型可能就會驚人地擴展,因爲作爲優秀的溝通者最關鍵的地方就在於,成爲任何各具才能(以及經驗、靈感)的開發者所組成團隊中極有意義的一部分。

communication(from practicalpmo)

communication(from practicalpmo)

用心聆聽

仔細傾聽,意味着不但要聽到他們在說什麼,或者給予他們一個發泄口,還要試着與他們共同理解潛在意思,而據此作出相應的調整則遠比聽起來更困難,或者至少是比我們所想的更不自然。你可以通過訓練自己更好地傾聽而受益。我之所以能夠這麼說,是因爲任何人(無論是總統和實習生,家長和孩子,學生和老師)都能夠更好地傾聽。

但這裏有個傾向就是,將自己視爲主角,其他人則是NPC,儘管我們理智地知道這種做法是不現實的。傾聽的部分要素在於有意識地依此行事。其目標並不是讓他人來適應你的想法,而是通過大量背景和視角,以讓人們獲得參與其中的良好感受而找到前進的出路。

不要在乎誰贏

對話溝通中並不存在誰是贏家的問題。

這個道理聽起來顯而易見,但有許多人仍然沒有充分理解。開發討論並不一定是場爭論。即使是創意衝突也不可避免地會呈現某些不可兼容的想法都在爭奪日程表上有限的開發關注點的局面,但爭論並非解決問題的良方。

在一個交流對話的模式中,兩個持有不同觀點的人蔘與其中,最後其中一者贏了,另一人卻輸了。我並不認爲任何人都會有意識地認同這種對話模式,但從我們在電話上所看到的政治人物談話的頭部特寫,電影角色之間的對話,甚至是我們本能的鬥爭或逃跑意識都會將此視爲一種默認的對話模式。

不要去想誰是觀衆(注:要儘量避開其他觀衆,因爲這通常可能以防禦性、自我保護的姿態污染一個文明的對話環境),或者想象公正的裁判會判斷誰是贏家,要考慮參與其中的人所處的立場可能會影響到將來的爭論。

如果你所有的先決參考材料都在引導你強烈地相信某一特定方向,你可能只是在推波助瀾地給這個誇張的方向幫倒忙了。無論何時我們遇到一個不太喜歡,尤其是涉及設計、美術或商務等可能有許多可行方向的領域,只要我們將其與消極、敵意的人聯繫在一起,那無論是哪種理論依據在支持這項選擇都沒用了。

要友善地對待此事。首先要擔心的是理解他們觀點的優勢和考慮,然後纔是你自己的觀點得到理解和考慮。注意這兩者都不是要“說服”他們,或者向他們展示“正確的”方法,而是嘗試相互理解,因爲如果沒有這個前提,其他的討論內容都只會淪爲針對不同想法的爭吵。

可能是你錯了

談到相互理解:不要害怕在想出發生什麼情況後放棄一個觀點,並意識到還有另一個更可行的方法。我們總是顧及面子問題而堅持捍衛自己的觀點——尤其是在還沒有吃透這些想法的情況下。

聰明人在遇到新信息或顧及新的考慮時總是善於變通。你們並不是在玩紅隊對抗藍隊的遊戲。你們是同一個團隊中的人,要儘量向同一個方向傳球,也許你的隊友更清楚哪個方向纔是正確的目標。

另一方面就是要給其他人擺脫困境的出路。提供一些新信息或關注點,讓他們更容易改變自己的想法,即使這些信息實際上並不足以改變他們的想法(因爲這可以讓他們用更合適的方式 迴應新信息,而不是一開始就表現出不確定性)。承認他人所在立場的優勢並不會讓你的立場處於弱勢,這只不過是讓他們覺得自己的想法被傾聽和得到了認可,以及你考慮的並不只是自己的初始想法,還包括他們的想法。無論是以哪種方法解決一個問題,都要允許大家存在不同的見解,而不是形成誰站在你一邊,誰反對你的印象(實際上,通情達理的人一般是反對特定觀點而不是針對某人)。

當某一觀點不可避免地被妥協或放棄時,作爲富有技巧的溝通者就不要對此太刻薄或者窮追不捨了。不要介入太人私人感覺,這是團隊的最高利益,並非每個建議都可能被採納或者最終被遊戲所保留。

假定無過失,就要假設是最好的情況

所謂的稻草人論證就是指我們不贊同或者試圖反駁一個簡單化的反對立場這種情況。在非正式情況下,針對政治分歧或者宗教/文化信仰的激烈爭論,經常可以見到人們反對團體中最爲極端、非理性或明顯棘手的成員,而不是去對付那些更中肯、理性和富有說服力的信徒。這就會陷入一個僵局,由於雙方都覺得自己在推進一個反對對方的觀點,所以任何一方都不會覺得自己的問題得到了解決。

如果大家的目標是形成一個更爲成功的合作,而不只是讓自己暫時感覺良好,那麼最正確的做法就是採用與稻草人論證相異的做法。假設他人是出於理性、正式和好意的立場,如果這並非你在溝通中所看到的現象,那就去進一步理解對方。或者甚至可以幫助他們進一步發展他們的想法,尋找對方所沒有想到的其他優點——也許從這一點出發可以讓那些原本與你無關的立場受益。

如果你所持有的觀點與他人的提議並不相同,最好將自己的想法提出來,同時再提出另一個可以作爲替代性方案的想法。如果它被另一個你通過真正的討論和考慮所提出來的更好的建議所取代,或者形成了一個似乎對雙方都有好處的想法,那就更好了。

你的挫折感會形影不離

這是我通過自己的摔跤訓練生涯而得到的一點生活經驗。多數時候當人們不安或受挫或者失望時,他們多半是對自己失意和失望,而通過責備將矛頭指向他人卻並不能疏散這種情緒。

即使這在任何情況下並非100%正確(當然,有時候人們可能會非常欠考慮,自私或者不負責任,你有理由對他們感到失望)——我發現假想我們自己的情緒狀態是一個非常管用的方法,因爲它讓外界的事物得到了控制和變化,以便我們專注於自己所能做的事情。

對有違我們信任的人感到失望?我們的失望可能是源自我們無法認識到我們不應該信任他們。對做錯事的人生氣?我們可能是氣自己沒有把握好方向或者期望太高了。對不理解那些你認爲顯而易見的事情的人感到抓狂?你可能是因爲覺得自己無法向他們清晰而高效地描述事件而受挫。

如果人們沒有很好地理解或接受你的觀點,但你卻相信自己的想法具有價值,只是沒有得到充分的考慮,不要將此歸咎於他人的理解無能,而要想想這是因爲自己沒有表達清楚。也許他們不會遵從你的參考意義,或者無法更好地通過簡單的圖表或流程圖而理解你的想法。也許他們理解了你在說什麼,但卻不知道爲何你會認爲這值得一提,或者他們知道你的意思但就是不懂你所想的事情與你所認爲的改變之間有何聯繫。

最好是寫下概括性的重要內容(遊戲邦注:人們通常難以吸收含有大量細節的論據,除非他們已經知道其中的大意),並以其他方法來解釋說明。提供一個展示案例。如果你已經有一個自己認爲很重要但卻沒有得到認可的觀察,最好是以另一種新方法引出這個觀點,而不是令其夾雜在其他混亂無章的字詞中,導致其無法合理地呈現或得到支持。

將假設性誤會爲決定性

結論可能會變。當他們處於初稿階段時,他們很可能會這樣——這正是我們爲何要製作初稿的原因!因爲它們還只是一個計劃、理念或一個原型時更易於修改和調整,它們越是成型其結論就越爲牢固。

這種誤解會產生兩種錯誤的溝通方式:將你自己的假設性理念誤理爲決定性的,或者將他人的假設性理念誤解爲決定性的。在開發階段,隨着更多人的參與,項目就會發生變化從而反映出哪些做法可行或不可行,或者更好地利用團隊成員的強項或興趣。

如果你早期在項目中推進了一個人們看似贊同的想法,但之後則可能因開發過程中發現由於時間和資源有限,而不得不對其改進或刪減。它甚至可能被完全刪除,甚至在混亂中完全被忽略了。在提到它的案子之前,要先重新考慮一下項目可能會如何變化(因爲當時該想法只是剛剛成形),以便決定是否需要更新這一想法,令其符合團隊和遊戲發展方向。

有時候某些想法在開發過程中的價值就是給予我們專注的方向,而該理念能否保持其原來的形式則要讓位於團隊和玩家是否會喜歡遊戲。它可能需要重新加工,可能需要進行一點調整,也可能在最後的開發階段卻發現它並不像現在這麼可行了。也有可能你最終還是得放棄它,儘管它曾經是團隊過去所實現理念的墊腳石。

另一個做法就是犯同樣的錯誤,從而瞭解他人的想法:在它們還是假設性的時候將其想象成決定性的。這種情況的發生也許要歸因於該想法距離未來結果還很遠,以及初始理念和討論發生時大家還沒發現或解決的問題。如果一個項目需要人們有意支持一打汽車類型,但在開發過程中實際上只用了三種不同的汽車 ,以便將精力運用於其他必須的開發環節,那就會發生這種情況。人們會變得樂觀,人們會犯計劃性的錯誤,人們無法預測未來——但重要的是不要將這些人類瑕疵與有意的謊言或不守信混爲一談。如果有人在開發早期說出了一個項目之後可能實現的願景,不要太當真,也不要將其視爲板上釘釘的合約,只要將其視爲他們所打算的方向即可。執行的過程中實際上還需要妥協。

軟化確定性

團隊內鬥的一個普遍起源就是對某一個觀察或說法的確定性的錯位感,它反映了團隊其他人並不一定認同的價值優先權,尤其是當有一個人的說法凌駕於團隊其他人優先權之上的時候。

最好是謙遜地承認自己只能看到部分情況,你所能做的就是從自己的立場出發澄清事情的發展方向。爲大家的爭議留有餘地,“我最多隻能說……”或“在我看來……”或“我當然不可能代表所有人,但至少根據我所玩過的該類遊戲題材來講……”這類開場白看似無甚作用,但實際上卻可以避免將團隊拴死在一個結點上,從而根據不同角度展開有意義的討論。

顧問的挫折

校園裏充斥着大量想法與行事風格一致的人,他們擁有相似的價值觀,通常也是同一代人。在教室之外,無論是合作開發一個遊戲項目,加入一家公司,或者做其他事情,似乎都是這種情況。通常情況下,如果你的技能是視覺藝術,尋徑你就得同那些不是很懂視覺藝術的人合作。如果你的技能是設計,你就得與許多非設計師共事。如果你具有技術專長,你就得同大量非技術人員打交道。

這也正是你在團隊中的原因。因爲你知道他們所不懂的內容。你可以看到他們所無法看到的問題。你知道他們不知如何應對的方法。如果團隊或公司中的其他人能夠以相同的方式理解你的想法,尋徑他們可能根本就不需要你參與了。你在這個位置的目標就是幫助他們理解問題,而不是因爲他們的理解與你不同而看輕他們。要幫助他們看到你所見到的內容。

我將此稱爲顧問的挫折,因爲它特別強調一點:如果有一家並不瞭解銷售(或者設計、IT等領域)的公司給一名銷售顧問打電話,就是因爲他們不瞭解這個領域所以纔會打電話諮詢。此時幼稚、缺乏經驗、沒有準備的顧問對此情況的一個可怕反映就是——這些人怎麼會對如此基礎的內容一無所知?顧問的作用是找到這個認知差距,並給他們補上一課,而不是因此而貶低他們。畢竟這家公司還要做大量專家所不能完全理解的事情,因爲這些並非他們所熟悉的領域。

如果你發現了一些與自己有關的問題,要與團隊分享。因爲這正是你存在的部分價值。你也許會看到團隊中其他人所不能見到的方面。

每個角色的價值不同

上述要點的另一面就是欣賞其他不如你自身觀點更顯而易見的因素和問題需要同這一點相平衡,在某些情況下甚至需要顛覆它。

挫折可能起源於顧問挫折的一種誇張形式:程序員可能會本能地將團隊中的其他角色視爲二級程序員,設計師可能將其他人視爲二級設計師等等。這並不是一種有效的思考方式,因爲他們不適合你的位置,而且你也不併適合去做他們的事情。位置不侷限於某人推動項目進程的技能,它還代表他們在團隊中對項目的某一方面所持有的一種責任和身份,一種看待特定問題的專業眼光。程序員可能無需擔心色彩方案,美術人員可能不用操心如何編程,而只要玩法可行,設計師也不需要顧慮美術和編碼問題。

這正是讓人們各司其職的好處之一,即便團隊是由身兼數職或者獨立開發項目的成員組成。

由於大家的出發點不同,開發過程中就難免出現妥協。美術人員可能會因圖像渲染的異常問題而煩惱,但工程師可能會有團隊已經使用了他們可用的技術來支持這種美術風格但卻仍然無法實現的正當理由。音樂或音頻設計師可能會覺得某些增進譜或動態調整方法可能會讓遊戲的音頻增色,但玩法或關卡設計師則可能有一些自己所熟悉的關於用戶體驗、站程或輸入方法等棘手問題。

製作人有時候口碑很差的原因之一就是,作爲項目“經理”他們並不理解這些情況,因爲他們的職責是確保遊戲取得進展,直到按時完成和發佈爲止。所以他們遇到這些問題的妥協理由通常就是,“……但我們得按計劃完成遊戲”。如果某人不爲此而努力,那麼項目就無法完工。

所以當你有幸與一支優秀而平衡的團隊共事時,要善待團隊中的其他人,因爲他們都在找你所看不到的盲點。要讓你自己成爲一名更出色的溝通者,這樣你才能爲他們提供同樣的幫助。

過於強調角色作用

現在我覺得有必要特別說明一下小型團隊開發角色在討論和考慮過程中不應該捲入成員的能力分類問題。

雖然繪製視覺藝術的成員很可能是美術風格的最終決定者(遊戲邦注:這不僅是一個美學偏好問題,還是一個他們在工作中因自身的能力、強項與侷限性所帶來的副作用),但這並不意味着團隊中的其他人就無權提供一些自己對該美術風格的反饋和建議(要知道,美術人員可能只能創造一種特定的視覺風格,但這並不意味着程序員就應該全力以赴實時支持這種風格),應該允許他們提出自己的意見,並以遊戲粉絲或媒體的身份來談談看法。

一名團隊成員真的比項目中的其他人更瞭解動畫嗎?果真如此,那麼這名成員就應該參與同動畫執行或部署相關的討論。但即便你不是動畫人員,如果你能提出大量不同的媒體案例,並且有一個如何令之與技術、設計或其他學科相互作用的執行想法,那麼你還是有必要參與討論(儘管其決定權仍在於最有影響力,以及最有相關經驗的那個人)。

躲藏在自己的角色背後,認爲“我並不是美術人員,所以這不關我的事”或者“我是設計師,所以這不是你需要擔心的問題”並不會給團隊帶來好處。遊戲質量會影響到每個參與其中的人。你可以提出一個與自身有關的看法,並由擁有不同背景和不同觀點的人來提出意見。大家一起找到最佳方法。

boss-leader(from hobbygamedev)

boss-leader(from hobbygamedev)

與這些角色說明相關的一個區別理念就是僕人型領導。它提倡的是團隊領導不應該像製作人、總監或主設計師一樣將自己視爲其他人的上司,他人只能服從自己的命令,而要像團隊中的另一名合作者一樣與大家共處,所不同的只是自己還負有監管項目方向以及抽取不同經驗類型的責任。他們必須平衡自己與他人的想法,從而讓大家形成一個共識,要儘量讓團隊保持快樂心態,這就是他們手中的技能和工具。

有效地處理批評意見

在批評發生的時候——無論是你的遊戲完成之後的批評,還是遭遇了反對的聲音,要先讓自己同被討論的要點相隔離。當你們對你的工作給予反饋時,無論是針對你的編程、美術、音頻還是其他的,這些都是針對你所創造作品的反饋,而不是針對你本人的批評。

反饋的出發點幾乎都是爲了讓遊戲更好更棒,在問題暴露並影響到他人之前,或者在遊戲會遭遇重大返工之前指出並修復問題。有時候反饋來得太遲了,延誤了項目修復,與其否定反饋倒不如將其銘記在心並在之後多加用心(畢竟這不是你開發的最後一款遊戲或理念,不是嗎?)。

防禦性姿態通常只會產生事與願違的結果,至少是浪費有限的時間和精力。

系統和常規渠道

形式和一對一的日常簽到會令人感覺官僚作風,但合理的更穩和調節卻可以令其發揮重要功能。應該爲人們提供一個發表自己看法的渠道,要讓大家與項目相關的人進行半常規的接觸,這樣才能建立一種信任感,而不至於在發現問題時感覺是在彼此針鋒相對,而非提出一些小意見而已。

在我曾參與的一個遊戲開發團隊中,我們曾試圖在還沒有開始執行的早期階段就縮小可能的前進方向。在一次公開的討論中,大家提出了一些看似可行的想法。當我們讓大家舉手表決,看看這些想法的支持率時,我們發現有一個想法僅有廖廖數名支持者——這些支持者是其中最有發言權的參與者。即便只是引進一點形式,也可能給予那些項目中更寡言少語,但卻擁有同樣出色想法和考慮之人更多發言渠道,這樣團隊纔好權衡不同的考慮和優先權。

實踐,從錯誤中汲取教訓

抓住更多鍛鍊溝通能力的機會。在所有角色中,在人羣中,在正式與非正式場合,在與數人外出途中,與多人外出過程中均是可以利用的機會。

現在,我並不喝酒,也不去酒吧或俱樂部。我幾乎從不參加派對。這週末我也沒有去看超級盃的打算。我並不是說你應該強迫自己去做那些本不願意做的事情。我只是想說你應該去找那些能夠讓自己放鬆自如地練習溝通能力的場合。

無論你是單兵作戰還是與團隊共事,都要好好利用與團隊打交道的挑戰。去參加會議,參與一些俱樂部活動。如果你所在的團隊需要一些消息或花邊新聞,要自願提供這些信息。

溝通是一種遊戲開發技能。與任何其他遊戲開發技能一樣,你通過持之以恆的練習終會獲得巨大收穫。

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

篇目1,Opinion: Negative developers and team stability

By Lee Winder

It doesn’t take much for negative feelings to start to seep into a team but it takes a lot more to turn a team around and start to raise morale and motivation. The following isn’t based on an in-depth study of development teams across the world but on my own personal experience of managing and observing a number of teams over the last 10 years.

Take of that what you will…

When you look at the make-up of a team, it will always be staffed by people who raise the game and by some who only bring it down. It’s the nature of taking a group of individual people and asking them to work together for a period of time towards a common goal. It’s the individuality of these people who can take a project and make it fly or cause it to crash and burn.

One thing that’s clear is that it’s much easier for a single individual to bring a team down than it is for an individual to improve the team in any significant way. Negativity will spread like wild-fire through a team whilst positivity acts more like treacle and can be much harder to spread around.

But why?

A negative attitude to work is a whole lot easier. Doing less, talking badly about the team, or rubbishing the game is much easier than creating excellent content, taking responsibility for your work or stepping outside your defined role and doing something great.

What defines a negative developer?

There are many ways in which a developer might have a negative effect on a team. The most obvious is through their general attitude to their current project, be that general low-level complaining, pushing back against work requests for no good reason, or general slacking off during the day.

It could be a lack of skill development or even a backsliding in the quality of the work they are producing.

But it could also be an attitude that doesn’t gel with the general ethos the team is aiming for. Maybe you want your developers to take more responsibility for their work and how it’s designed and implemented, and one or two developers will only work when they are told exactly what they need to do.

Maybe it’s a developer who doesn’t get involved with the daily meetings, mumbling through and obviously not interested in what other people are doing.

At the end of the day, identifying a developer generating a negative effect on a team is usually pretty easy. They’re the ones who are difficult to deal with in usually many aspects of the development process…

Team development

Lets have a look at a few situations where a green developer is a ‘positive’ developer, red a ‘negative’ one.

In the first situation, we have two developers working side-by-side, one working well and another not doing so great. Maybe one of them has a bad attitude, maybe they don’t want to really push what they are doing. Either way, their contribution to the team is much less than that of the positive developer.

In most cases, this will go only one way. The good developer, seeing their partner being allowed to get away with not working so hard and not having to put in as much effort, will eventually start to slow down and equalize with the poorer developer.

It’s much less likely that the poorer developer who is getting away with poor work or a bad attitude will see the better developer and decide to put in that extra work. As a result, you now have two bad developers rather than one.

When does it go the other way? When does the poor developer look around and start to raise their game? The answer isn’t very encouraging.

Take the following situation:

Theres a tight balance here, but since it’s much easier for a developer to reduce the quality of their work rather than improve it, it’s easier to slide the wrong way, and at that point it’s very easy to see where this will go.

Based on a number of observations, it seems at though while a 3:1 ratio might get you some good results, it still brings risks because should one developer start to slip, it then becomes 1:1, which puts us right back at the start.

In most cases you can only really guarantee that other people will not slip if you have a 4+:1 ratio between positive and negative developers. In a number of cases, the negative developer didn’t change their attitude without help, but other developers didn’t slip due to the peer pressure of the other better developers.

Positive developers

But in all these situations, I’m not giving these positive developers enough credit. A good developer won’t always slack, they’ll continue working hard, producing great content and generally continue to fly high.

But take the following situation…

These developers are good for a reason, be that personal pride, ambition, or sheer enjoyment of the work they are doing. And if a good developer finds themselves in the minority for a long period of time, the outcome is inevitable.

Great developers won’t stick around if those around them are not working to their potential or failing to create an environment in which the better developers feel themselves being pushed. And once your great developers leave, you have a much higher chance of those left realizing they don’t need to actually work that hard to get through the day.

Solving the problem

There are two ways to deal with poor developers on a team. The first is the most drastic, but initially not an option if you’re working in a region with sane labor laws.

Just drop them.

To be honest, I wouldn’t recommend this anyway. Simply letting someone go generally removes the problem, but it can leave a lot of holes on the team, and you hired this person for a reason, why not try and get that spark back?

Performance Management structures (you do have a Performance Management process don’t you?) within an organization can, if done correctly, not only resolve the problem but allow the poor developer to raise their game and become a star on the team.

Identify the source of the problem. Does the developer just not like the game, are they having a difficult time outside of work, do they disagree with how work is being allocated, or do they just not want to be there?

Depending on what their answers are, you’ll have a good idea of where to go next.

Make sure goals are set. Define goals designed to turn the situation around, but don’t just set and forget about them (which happens far to often). Monitor them on a weekly or bi-weekly basis, setting very short-term goals to complement the longer term ones.

Define a fixed period of time. Don’t just let things drag on with only small improvements here or there, have a deadline at which point things will get more serious.

Make it clear what the end results will be. Whether they are the chance to work on something different or whether it’s a termination of the contract, make it clear so everyone knows what will happen when the goals are reached or missed.

Keep constant records. Make sure every meeting is documented and the progress or results of all the goals are recorded daily.

Let them go. While it is drastic, if improvements are not being made given all the opportunities you’ve given them, then there really is no other option. If you’ve bent over backwards to try and solve the problem and the developer hasn’t taken you up on the offer, then there really is nowhere else to go.

And even with those sane labor laws, the documentation you’ve been keeping over the Performance Management period mean you can release the developer from their contract knowing you tried your best and they didn’t want the help.

So negative developers, whatever is defined as negative based on the goals of your team, are almost guaranteed to have a bad effect on a group developers. Negative attitudes to work and development can spread much faster than you might think and will either cause people on your team to normalize at a level far below where they need to be or will simply leave.

It’s vital that as a group these developers are tackled fast, rather than when their effects start to be felt.

篇目2,Cliff Bleszinski’s Game Developer Flashcards

by Cliff Bleszinski

As of this summer, I’ll have been making games for 20 years professionally. I’ve led the design on character mascot platform games, first-person shooters, single-player campaigns, multiplayer experiences, and much more. I’ve worked with some of the most amazing programmers, artists, animators, writers, and producers around. Throughout this time period, I’ve noticed patterns in how we, as creative professionals, tend to communicate.

I’ve learned that while developers are incredibly intelligent, they can sometimes be a bit insecure about how smart they are compared to their peers. I’ve seen developer message boards tear apart billion-dollar franchises, indie darlings, and everything in between by overanalyzing and nitpicking. We always want to prove that we thought of an idea before anyone else, or we will cite a case in which an idea has been attempted, succeeded, failed, or been played out.

In short, this article identifies communication techniques that are often used in discussions, arguments, and debates among game developers in order to “win” said conversations.

These observations and monikers are not meant to be antagonistic; in fact, several of the approaches mentioned here are employed because of valid reasoning. For example, pattern matching can be a good way of avoiding making derivative products, and sometimes an edge case can, in fact, kill a solid idea. So here are my Game Developer Communication “Flashcards.”

“Pattern Match Dismissal”

This is when a developer immediately runs through his gaming/pop culture library in his head and finds the closest thing to compare it to (often, a bad or failed example) in order to shoot it down.

For example, in regards to Avatar, “You want to make a movie about blue people in a forest with a bad military and mechs? What, Smurf Ferngully Aliens?” The Gears of War franchise, pitched improperly, could be seen as the old ’80s schlock horror movie C.H.U.D.

“Edge Blocking”

This refers to using an edge case to block a potentially awesome idea. i.e., an Edge Blocker would shoot down the idea of having giant worlds in Skyrim because of a concern that you’d have to trek back to where you came from and that all that walking would get old. Obvious and clear fixes such as the gameism of “fast travel” can easily solve this issue, allowing for huge worlds.

Edge Blocking has variants:

“The Networker.” This is a way of shooting down an idea because it won’t work in an edge case or unique co-op situation — this is a variant of Edge Blocking. “How would Max Payne slo-mo work in co-op? Impossible!”

“Perfectionist.” Similar to Edge Blocking, this is when a developer finds one instance whereas a cool feature might not look absolutely perfect, e.g., an amazing melee move that occasionally will result in some minor clipping of characters into one another.

“Ne’er Do Well”

Or “I’ve never seen that feature done before, or done well. Therefore, we shouldn’t do it.” This one is pretty self-explanatory, and, in fact, can be the reason why an idea should be done. Following this logic only leads to “me-too” creation.

As a reference, a Locust population from the underground in Gears of War worked for many reasons, but we still had reservations about it. In the end, it helped differentiate the franchise from others that featured the usual aliens-from-above/space.

“Devil’s Advocate”

Most developers tend to use this technique, even when they believe in an idea, as a form of covering their ass. Often used by lawyers.

“It’s just X+Y”

This is when a developer dismisses another successful product, sour grapes style, because he can easily see the formula. The fact that the formula is so simple and obvious is often why said product is so successful.

For example, Words with Friends: “It’s just asynchronous Scrabble.” Yes, it is, and it’s brilliant.

“Future Release”

This occurs when a developer hears an idea — good or bad — and says that it will fit nicely into a later version or sequel. This is code-speak for “I don’t think that idea is worth doing, so we’re going to shoot it down by saying we’ll do it later in order to make you feel better.”

“Toppling,” a.k.a. “Tower of Babel”

This technique is when a developer adds too many bells and whistles to a feature that was pitched as simple, but ultimately jeopardizes the feature altogether due to these additions. The feature “topples” under its own weight.

“Think of the Children!”

This is otherwise known as “Cascading Dependencies.” The tendency is to shoot down an idea because it will cause more work for other departments, such as animation, UI, or art. Often, features that are interesting and/or worth doing have these sorts of ramifications as they combine all disciplines.

“Analysis Paralysis”

This is a commonly-used term for the technique of over-thinking things to the point where nothing is actually done.

“Why Even Try?”

In other words, “How do we even compete?” Intimidated by the immense competition in any given space, a developer asks this as a way of giving up before even giving it the “old college try.”

“They Have N Developers!”

This is a phrase that is often used by a developer to cite a competitive team and how large their staff is on their game, and is used as a way of leading to “why even try?” The Epic Way has always been to put the best people on a task, with the best tools in the business, in order to work smarter.

“Traditionalist”

“But this is how we’ve always done it!” In entertainment, and particularly in technology, innovation and re-thinking things is often quite necessary in order to stay alive. Becoming complacent and doing things the same way over and over again is a surefire way to induce failure.

Being a 20-year veteran of any regular business may be an advantage, but in technology, it can sometimes limit you. As a developer gets older, it’s crucial to keep an open mind and to always be learning.

“But We’re (Insert Studio Name)”

This is the battle cry of a studio that is ready to rest on its laurels due to a certain level of success and thinking they’re badasses. The moment folks at a studio start saying this, one can count the days until the studio implodes, because a younger, hungrier crew out there wants what you have and is willing to dream and make it happen.

“We Tried That Before”

Citing a previous failed attempt at an idea in order to kill a new (and potentially workable) permutation of said idea.

“Too Cool”

Your idea is great! In fact, it’s too cool and innovative. Therefore, we shouldn’t do it, because it sounds like a lot of work.

“Jargonating”

This is when a developer uses forms of jargon only native to his discipline in order to win an argument with a developer of a different discipline, e.g., a coder using code-speak to an artist, or a designer using designer lingo to an animator.

“The Tribal Leader”

This happens when developer believes in his discipline (art, code, design, etc.) over any other in the studio, so fuck those other guys.

“Noscope”

“That idea is great but isn’t within the scope of the project.” Sometimes, the best features are the fringe ones that sneak in under the radar and not on the original schedule, unfortunately.

“Playtest Grandstanding”

This is when a developer fails with a new feature or weapon and loudly suggests “balancing” it by changing it during a playtest, therefore often getting his way. Sometimes, people just suck with a sniper rifle and get destroyed by others, and that’s okay.

“The Repitcher”

This is the person who hears your idea, seems like they didn’t initially hear it, then re-pitches the same exact idea in their own words as their own, forgetting where they originally heard it. This ultimately doesn’t really matter, as long as the cool idea comes from somewhere and is implemented well!

“Filibuster,” or “TL;DR Guy”

This is the person who responds to a design suggestion or discussion with three-page emails.

Every time.

Without fail.

Eventually, you make a custom filter for this person.

“The E-Douche”

This is the person who almost always seems to come across as a total asshole in email, even when they don’t really mean to because, frankly, email sucks.

“Godzilla”

This is a person who somehow manages to shut down all progress on an idea and comes up with his own completely new pitch that is subjectively better or worse, essentially trying to make everyone start over.

“The Doubter”

Someone who rejects an idea without having any sort of clear reason why: “I don’t know about that…” Often useful against the…

“Prophet”

A designer who has a rush of excitement about an idea, but hasn’t thought through it fully in regards to its design and/or ramifications. Said designer simply expects everyone to have faith that the idea will wind up good instead of properly making the case for it. This is often common behavior with a younger, less experienced designer. Similar to…

“Captain Ahab”

This is when a designer refuses to admit that an idea just isn’t panning out, while endlessly iterating on it, using precious code and art resources, assuming someday, one day, it will be fun.

“Data Bombing”

This an argument used that goes as such: “This chart of loosely related and completely unbiased data shows how your idea will never succeed, you’ll offend lots of folks, and it’s a direction we cannot afford to go in.”

“Psychic Expectations”

This is a technique used by a coder in which said coder refuses to understand the pitched/desired feature until it is requested in the exact specific manner the coder wants to hear it.

“Ignorannihilation”

The developer who intentionally (or unintentionally) misses the obvious and starves a potentially good feature until it is cut.

“Not My Idea, Not Going to Do It”

This is when a designer takes input from others and claims to want a call for ideas, yet quietly ignores anything he didn’t come up with himself.

“The Gardener”

The Gardener plants the seed of an idea early and then brings it up again many times in meetings and in casual conversations with individuals around the office. Eventually, the idea starts to take root and grows on people until it becomes an actual feature in the game and no one can remember where the idea came from in the first place. This is actually a very useful technique.

“Obvious Bug Guy”

This is when a developer is being shown a work in progress feature and, instead of thinking about where the feature is headed or what it can do, feels the need to point out obviously broken things that will clearly get fixed eventually, like Z-fighting.

“Multiboss”

This when a person has no clear, obvious boss or chain of command, and is often told by multiple people what he should be working or focusing on. One’s design director, executive producer and president may each have varying opinions about what to do, leaving said staff member confused.

“The Promiser”

This term refers to a spokesperson who pitches or promises a feature to the media, which puts the team on the hook to actually code said feature once they’ve gone public with it.

“The Bandwagoner”

This is the term for the creative who wants to add whatever feature he saw in a recent popular game as a way of making the game better instead of trying other ways to innovate.

So, in conclusion, that’s the list of personalities and techniques that I’ve encountered throughout the years. Thanks to some of my peers at Epic, ChAIR, and People Can Fly for contributing to the list. I hope that aspiring developers can recognize these patterns and adjust accordingly, and I hope that established creatives are able to get a chuckle out of this.

篇目3,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.

篇目4,Communication is a Game Development Skill (Part 1 of 2)

Today’s subject is an incredibly important one that gets a lot less attention than it should. Most videogame development guides and tutorials fail to acknowledge that communication is a game development skill.

Knowing how to speak and write effectively is right up there alongside knowing how to program, use Photoshop, follow design process, build levels, compose music, or prepare sounds. As with any of those skills there are techniques to learn, concepts to master, and practice to be done before someone’s prepared to bring communication as a valuable skill to a team.
Game Developers Especially

Surely, everyone in the world needs to communicate, and could benefit from doing it better. Why pick out game developers in particular?

“…sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it!”

I don’t meant to claim that only game developers have communications issues. But after spending much of the past ten years around hundreds of computer science students, indie developers, and professional software engineers, I can say that there are particular patterns to the types of communication issues most common among the game developers that I’ve met. This is also an issue of particular interest to us because it’s not just a matter of making the day go smoother; our ability to communicate well has a real impact on the level of work that we’re able to accomplish, collaboratively and even independently. Game developers often get excited about our work, for good reason, but whether a handful of desirable features don’t make it in because of technical limitations or because of communication limitations, either way the game suffers for it the same.

Whose Job is It?

If programmers program, designers design, artists make art, and audio specialists make audio, is there a communication role in the same way?

There absolutely is. There are several, even.

The Producer. Even though on small hobby or student teams this is often wrapped into one of the other roles, the producer focuses on communication between team members, and between team members and the outside world. Sometimes this work gets misunderstood as just scheduling, but for that schedule to get planned and adjusted sensibly requires a great deal of conversations and e-mails, followed by ongoing communications to keep everyone on the same page and on track.

The Designer(s). One way to think about the designer’s role in game development is to communicate with the player through the game. Indicating what’s the goal, what will cause harm or benefit, where the player should or shouldn’t try to go next, expressing the right amount of internal state information – these are matters of a game’s design more so than its programming. Depending on a game team’s skill makeup, in some cases the designer’s only direct work with the game is in level layouts or value tuning, making it even more critical that within the team a designer can communicate well with programmers, artists, and others on the team when and where the work intersects. On a small team when the person mostly responsible for the design is also filling one or more other roles (often the programming) communication then becomes integral to keeping others involved in how the game takes shape.

The Leads. On a team large enough to have leads, which is common for a professional team, the Lead Programmer, Lead Designer, or Lead Artist also have to bring top notch communication skills to the table. Those people aren’t necessary the lead on account of being the best programmer, designer, or artist – though of course they do need to be skilled – they’re in that position because they can also lead others effectively, which involves a ton of communication in all directions: to the people they lead, from the people they lead, even mediating communications between people they lead or the people they lead and others.

Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.

The Writer. Not every game genre involves a writer, but for those that do, communication becomes even more important. Similar to the designer that isn’t also helping as a programmer, a team’s writer typically isn’t directly creating much of the content or functionality, aside perhaps from actual dialog or other in-game and interstitial text. It’s not enough to write some things down and call it a day, the writer and content creators need to be in frequent communication to ensure that satisfactory compromises can be found between implementation realities and the world as ideally envisioned.

Non-Development Roles. And all that’s only thinking about the internal communications on a team during development. Learning how to communicate better with testers, players, or if you’ve got a commercial project your customers and potential new hires (even ignoring investors and finance professionals), is a whole other world of challenges that at a large enough scale get dealt with by separate HCI (Human-Computer Interaction) specialists, marketing experts, PR (public relations) people and HR (Human Resources) employees. If you’re a hobby, student, solo, or indie developer, you’ve got to wear all of these hats, too!

There are two main varieties of communication issues that we tend to encounter. Although they may seem like polar opposites, in reality they’re a lot closer than they appear. In certain circumstances one can even evolve from the other.

Challenge 1: Shyness

The first of these issues is that some of us can be a little too shy. Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.

It’s unfortunately very easy to rationalize shyness. After all, maybe the reason a talented, quiet person was able to develop their talent is because they’ve made an effort to stay out of what they perceive as bickering. Unfortunately this line of thinking is unproductive in helping them and the team benefit more from what they know. Conversation between team members serves a real function in the game’s development, and if it’s going to affect what gets made and how it can’t be dismissed as just banter. Sometimes work needs to get done in 3D Studio Max, and sometimes it needs to get done around a table.

Another factor I’ve found underlying shyness is that a person’s awareness of what’s great in their field can leave their self-confidence with a ding, since they can always see how much improvement their work still needs just to meet their own high expectations. Ira Glass has a great bit on this:

It doesn’t matter though where an individual stands in the whole world of people within their discipline, all that matters is that developers on the project know different things than one another. That’s inevitably always the case since everyone’s strengths, interests, and backgrounds are different.

Challenge 2: Abrasiveness

Sometimes shyness seems to evolve as an overcompensation for unsuccessful past interactions. Someone tried to speak up, to share their idea or input, just to add to someone else’s point and yet it somehow wound up in hurt feelings and no difference in results. Entering into the discussion got people riled up, one too many times, so after one last time throwing hands into the air out of frustration, a developer decides to just stop trying. Maybe they feel that their input wasn’t properly received, or even if it was it simply wasn’t worth the trouble involved.

As one of my mentors in my undergraduate years pointed out to me: “Chris, sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it! If you made the same point differently they might get behind it.”

He was absolutely right. Once I heard that idea, in addition to catching myself doing it, I began to notice it everywhere from others as well. It causes tension in meetings, collaborative classroom projects, even just everyday conversations between people. Well-meaning folks with no intention of being combative, indeed in total overall agreement about both goals and general means, often wind up in counterproductive, circular scuffles arising from an escalation of unintended hostility.

There are causes and patterns of behavior that lead to this problem. After 10 years of working on it, I’ve gotten better about this, but it still happens on occasion, and it’s still something that I have to actively keep ahead of.

It’s understandable how someone could run through this pattern only so many times before feeling like their engaging with the group is the cause of the trouble. This is in turn followed by backing off, toning down their level of personal investment in the dialog, and (often bitterly) following orders from the action items that remain after others get done with the discussion.

篇目5,Communication is a Game Development Skill (Part 2 of 2)

…if you communicate masterfully enough – persuasively, clearly, fairly and reasonably – then the scale and types of projects that it’s possible for you to work on expands tremendously…

Last month, in part one, I identified a couple of common points of trouble that arise for videogame developers. Communication matters! If communication skills are in bad enough shape, no matter what other technical or artistic skills have developed it’ll be hard to get others to collaborate, and hard to get players and reviewers to hear about the work. On the other end of the spectrum, if you communicate masterfully enough – persuasively, clearly, fairly and reasonably – then the scale and types of projects that it’s possible for you to work on expands tremendously, because being a good communicator is essential to winding up as a meaningful part of (or even starting and leading) any team of other developers who are bringing their own respective skills, experience, and inspiration into the picture.

Listening and Taking to Heart

You’ve heard this all your life. You’ll no doubt hear it again. Hopefully every time communication comes up this gets mentioned too, first or prominently.

Listening well, meaning not just hearing what they have to say or giving them an outlet but trying to work with them to get at underlying meaning or concerns and adapting accordingly, is way harder than it sounds, or at least more unnatural than we’d like to think. You can benefit from practicing better listening. I can say that without knowing anything about you, because everyone – presidents and interns, parents and kids, students and teachers – can always listen better.

There’s a tendency, even though we rationally know it’s out of touch with reality, to think of oneself as the protagonist, and others like NPCs. Part of listening is consciously working to get past that. The goal isn’t to get others to adopt your ideas, but rather it’s to figure out a way forward that gains from the multiple backgrounds and perspectives available, in a positive way that people can feel good about being involved with.

Don’t Care Who Wins, Everyone Wins

There’s no winner in a conversation.

This one also probably sounds obvious, but it’s an important one that enough people run into that it isn’t pointed out nearly enough. Development discussion doesn’t need to be a debate. Even to the extent that creative tension will inevitably present certain situations in which incompatible ideas are vying for limited development attention on a schedule, debate isn’t the right way to approach the matter.

In one model for how a dialog exchange proceeds, two people with different ideas enter, and at the end of the exchange, one person won, one person lost. I don’t think (hope?) that anyone consciously thinks about dialog this way, but rather it may emerge as a default from the kinds of exchanges we hear on television from political talking heads, movie portrayals of exchanges to establish relative status between characters, or even just our instinctive fight or flight sense of turf.

Rather than thinking in terms of who the spectators (note: though avoid spectators when possible, as it can often pollute an otherwise civil exchange with defensive, ego-protecting posturing) or an impartial judge might declare a winner, consider which positions the two people involved would likely take in separate future arguments.

If all of your prior references have led you to believe strongly about a particular direction, you only do that rhetorical position (and the team/project!) a disservice by creating opponents of it.

Whenever we come across as unlikeable, especially in matters like design, art, or business where a number of directions may be equally viable, then it doesn’t matter what theoretical support an option has if people associate it with a negative, hostile feeling or person.

It doesn’t matter what theoretical support an option has if people associate it with a negative, hostile feeling.

Be friendly about it. Worry first about understanding the merits and considerations of their point, then about your own perspective being understood for consideration. Notice that neither of those is about “convincing” them, or showing them the “right” way, it’s about trying to understand one another because without that the rest of discussion just amounts to barking and battling over imagined differences.

You Might Just be Wrong

Speaking of understanding one another: don’t ever be afraid to back down from a point after figuring out what’s going on, and realizing that there’s another approach that’ll work just as well or better. There’s a misplaced macho sense of identity attached to sticking to our guns over standing up for our ideas – especially when the ideas aren’t necessarily thoroughly developed and aren’t exactly noble or golden anyhow.

A smart person is open to changing their mind when new information or considerations come to light. You’re not playing on Red team competing against Blue team. You’re all on the same team, trying to get the ball to go the same direction, and maybe your teammate has a good point about which direction the actual goal is in.

You’re all on the same team…

The other side of this is to give the other person a way out. Presenting new information or concerns may make it easier for them to change their mind, even if that particular information or concern isn’t actually why they change their mind, simply because it can feel more appropriate to respond to new information then to appear to have been uncertain in the first place. Acknowledging the advantages in the position they’re holding doesn’t make your position seem weaker by comparison, it makes them feel listened to, acknowledged, and like there’s a better chance you’re considering not just your own initial thoughts but theirs too. When a point gets settled, whichever way things go, let the difference go instead of forming an impression of who’s with or against you. (Such feelings have a way of being self-fulfilling. In practice, reasonable people are for or against particular points that come up, not for or against people.)

When an idea inevitably gets compromised or thrown out, being a skilled communicator means not getting bitter or caught up in that. Don’t take it personally. It’s in the best interests of the team, and therefore the team’s members (yourself included), that not every idea raised makes it into implementation or remains in the final game.

Benefit of the Doubt, Assume the Best

A straw man argument is when we disagree with or attempt to disprove a simplified opposition position. In informal, heated arguments over differences in politics or religious/cultural beliefs, these are frequently found in the form of disagreeing with the most extreme, irrational, or obviously troubled members of the group, rather than dealing with the more moderate, rational, and competent justifications of their most thoughtful adherents. This leads to deadlock, since both sides feel as though they’re advancing an argument against the other, yet neither side feels as though their own points have been addressed.

Assume that the other person is coming from a rational, informed, well-intentioned place with their position.

When the goal is to make a more successful collaboration, rather than to just make ourselves temporarily feel good, the right thing to do is often the opposite of setting up a straw man argument.

Assume that the other person is coming from a rational, informed, well-intentioned place with their position, and if that’s not what you’re seeing from what has been communicated so far, then seek to further understand. Alternatively, even help them further develop their idea by looking for additional merit to identify in it beyond what they might have originally had in mind – maybe from where you’re coming from it has possible benefits that they didn’t realize mattered to you.

If the idea you may be holding is different than what someone else is proposing, welcome your idea really being put to the test by measuring it against as well put-together an alternative as the two of you can conceive. If it gets replaced by a better proposal that you arrived at through real discussion and consideration, or working together to identify a path that seems more likely to pan out well for both of you, all the better.

Your Frustration is With Yourself

This is one of those little life lessons that I learned from my wrestling coach which has stayed with me well after I finished participating in athletic competitions. Most of the time when people are upset or frustrated or disappointed, they’re upset or frustrated or disappointed mostly with themselves, and directing that at somebody else through blame isn’t ever going to diffuse it.

Even if this isn’t 100% completely and totally true in every situation – sure, sometimes people can be very inconsiderate, selfish, or irresponsible and there may be good reason to be upset with them – I find that it’s an incredibly useful way to frame thinking about our emotional state because it takes it from being something the outside world has control over and changes to focus to what we can do about it.

Disappointed with someone violating our trust? Our disappointment may be with our failing to recognize we should not have trusted them. Upset with someone for doing something wrong? We may be upset with ourselves for not making the directions or expectations more clear. Frustrated with someone that doesn’t understand something that you find obvious? Your frustration well may lie in your feeling of present inability to coherently and productively articulate to that person exactly what it is you think they’re not understanding.

If your point isn’t well understood or received but you believe it has value that isn’t being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it. Maybe they don’t follow your reference, or could better get what you’re trying to say if you captured it in a simple visual like a diagram or flow chart. Maybe they understand what you’re saying but don’t see why you think it needs to be said, or they get what you mean but don’t see the connection you have in mind for what changes you think it should lead to.

If your point isn’t well understood or received but you believe it has value that isn’t being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it.

Clarify. Edit it down to summary highlights (people often have trouble absorbing details of an argument until they first already understand the high level). Explain it another way to triangulate.

Provide a demonstration case or example. If there’s a point you already made which you think was important to understanding it but that point didn’t seem to stick, find a way to revisit it in a new way that leads with it instead of burying it among other phrases that were perhaps too disorganized at the time to properly set up or support it.

Mistaking Tentative for Definitive

Decisions can change. When they’re in rough draft or first-pass, they’re likely to – that’s why we do them in rough form first! It’s easier to fix and change things when they’re just a plan, an idea, or a prototype, and the more they get built out into detail or stick around such that later decisions get made based on them, then the more cemented those decisions tend to become.

There are two types of miscommunication that can come from this sort of misunderstanding: mistaking your own tentative ideas for being definitive, or mistaking someone else’s tentative ideas for being definitive. During development, and as more people get involved, projects can change and evolve a bit to reflect what’s working or what isn’t, or to take better advantage of the strengths and interests of team members.

If there was an idea you pushed for earlier in a project and people seemed onboard with it then, it’s possible that discoveries during development or compromises being made for time and resource constraints have caused it to appear in a modified or reduced form. It might even be cut entirely, if not explicitly then maybe just lost in the shuffle. Before raising a case for it, it’s worth rethinking how the project may have changed since the time the idea was initially formed, to determine whether it would need to be updated to still make sense for the direction the team and game has gone in.

Sometimes the value of ideas during development is to give us focus and direction, and whether the idea survives in its originally intended form is secondary to whether the team and players are happy with the software that results. It may turn out to be worth revisiting and bringing back up, possibly in a slightly updated form, as maybe last time was at a phase in development when it wasn’t as applicable as it might be now. Or it may be worth letting go as having been useful at the time, but perhaps not as useful now, a stepping stone to other ideas and realizations the team has made in the time that has passed.

People get optimistic, people make planning mistakes, and people cannot predict the future – but it’s important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise.

The other side to this is to make the same mistake in thinking about someone else’s ideas: thinking they are definitive when they are necessarily tentative. This happens perhaps because of how far off the idea relates to the future, and how much will be discovered or answered between now and then that is unknown at the time of the initial conception and discussion. If a project recruits people with the intention of supporting a dozen types of cars, but during development reality sinks in and only three different vehicles make sense in favor of putting that energy into other development necessity, those things happen. People get optimistic, people make planning mistakes, and people cannot predict the future – but it’s important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise. If early in a project someone is trying to spell out a vision for what the project may look like later, don’t take that too literally or think of it as a contract, look at it as a direction they see things headed in. Implementation realities have a way of requiring compromise along the way.

Soften That Certainty Away

A common source of fighting on teams is from a misplaced sense of certainty in an observation or statement which reflects value priorities that someone else on the team doesn’t necessarily share, or especially when the confidently made statement steamrolls value priorities of someone else on team.

Acknowledge with some humility that you only have visibility on part of all that’s going on, and that the best you can offer is a clarification of how things look for where you’re coming from or the angle you have on things. Leave wiggle room for disagreement. Little opening phrases like “As best as I can tell…” or “It looks to me like…” or “I of course can’t speak for everyone, but at least based on the games that I’ve played in this genre…” may just seem like filler, but in practice they can be the difference between tying the team in a knot or opening up valuable discussion about different viewpoints.

Consultant’s Frustration

School surrounds people with other people that think and work in similar patterns, with similar values, often of the same generation. Outside the classroom, whether collaborating on a hobby game project, joining a company, or doing basically anything else in the world besides taking Your Field 101, that isn’t typically how things work. Often if your skills are in visual art, you have to work with people that don’t know as much about visual art as you. If your skills are in design, you’ll have to work with a lot of non-designers. If you have technical talents, you will be dealing with a lot of non-technical people.

That is why you are there. Because you know things they don’t know. You can spot concerns that they can’t spot. You understand what’s necessary to do things that they don’t know how to do. If someone else on the team or company completely understood everything that you understand and in the same way, they wouldn’t really need you to be involved. Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see. Teach a little bit.

That is why you are there. Because you know things they don’t know… Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see.

I refer to this as the consultant’s frustration because that’s a case that draws particular emphasis to it: a company with no understanding of sales calls in a sales (or design, or IT, or whatever) consultant, because they have no understanding of that and that’s why they made the call. A naive, inexperienced, unprepared consultant’s reaction to these situations is one of horror and frustration – how on Earth are these people so unaware of the basic things that they need to know? The consultant is there to spot that gap and help them bridge it, not to look down on them for it. Meanwhile they’re doing plenty of things right the specialist likely doesn’t see or fully understand, because that’s not the discipline or problem type that they’re trained and experienced in being able to spot, assess, or repair.

When you see something that concerns you, share that with the team. That is part of how you add value. You may see things that others on the team do not.

Values Are Different Per Role

The other side to the above-mentioned point is appreciating that other factors and issues less visible to your own vantage point may have to be balanced against this point, or in some cases may even override it.

Frustration can arise from an exaggerated form of the consultant’s frustration: a programmer may instinctively think of other roles on the team as second-rate programmers, or the designer may perceive everyone else on the team as second-rate designers, etc. This is not a productive way to think, because it’s not just that they are less-well suited to doing your position, but you’re also less-well suited to doing theirs. A position goes beyond what skills someone brings to move a project forward, it also brings with them an identity and responsibility on the team to uphold certain aspects of the project, a trained eye to keep watch for certain kinds of issues. The programmer may not be worried about the color scheme, the artist may not be worried about how the code is organized, the designer may not care about either as long as the gameplay works.

…a programmer may instinctively think of other roles on the team as second-rate programmers…

That’s one of the benefits of having multiple people filling specialized roles, even if it’s people that are individually capable of wearing multiple hats or doing solo projects if they had to.

In the intersection of these concerns, compromises inevitably have to get made. The artist may be annoyed by a certain anomaly in how the graphics render, but the engineer may have a solid case for why that’s the best the team’s going to get out for the given style of the technology they have available. The musician or sound designer may feel that certain advanced scoring and dynamic adjustment methods could benefit the game’s sounds cape, but the gameplay and/or level designer may have complications they’re close to about user experience, stage length, or input scheme that place some tricky limits on the applicability of those approaches.

One of the reasons why producers (on very small student/hobby/indie teams this is often also either the lead programmer or lead designer) get a bad rap sometimes, as the “manager” that just doesn’t get it, is because their particular accountability is to ensure that the game makes forward progress until it’s done and released in a timely manner. So the compromise justification that they often have to counter with is, “…but we have to keep this game on schedule” which is a short-term version of “…but this game has to get done.” If someone isn’t fighting that fight for the project, it doesn’t get done.

Be glad that other people on a team, when you have the privilege of working with a good and well-balanced team, are looking out for where you have blind spots. Push yourself to be a better communicator so that you can help do the same for them.

Too Much Emphasis on Role

After that whole section on role, I feel the need to clarify that especially for small team development (i.e. I can total understand military-like hierarchy and clarity for 200+ person companies) role shouldn’t pigeonhole someone’s ability to be involved in discussions and considerations.

While it’s true that the person drawing the visual art is likely to have final say on how the art needs to be done (not only as a matter of aesthetic preference, but as a side effect of working within their own capabilities, strengths, and limitations), that does not mean that others from the team shouldn’t be able to offer some feedback or input in terms of what style they feel better about working with, what best plays to their own strengths and limitations (ex. just because an artist can generate a certain visual style doesn’t mean the programmer’s going to be able to support it in real-time), and what they like just as fellow fans of games and media.

Does one team member know more about animation than others on the project? Then for goodness sake, of course that person needs to be involved in discussions affecting the implementation or scheduling of animation. But even if you’re not an animator, that you’ve accumulated a different set of media examples to draw upon, and have an idea for how that work may intersect with technical, design, or other complications, there’s still often value in being a part of that discussion (though of course still leaving much of the decision with whoever it affects most, and whoever has the most related experience).

It’s unhelpful to hide behind your role…

It’s unhelpful to hide behind your role, thinking either “Well, I’m not the artist so that isn’t my problem” or “Well, I’m the designer, so this isn’t your problem to worry about.” The quality of the game affects everyone who got involved with making it. You make a point of surrounding yourself with capable people that are coming from different backgrounds and have different points of view to offer. Find ways to make the most of that.

A related distinction to these notes about role is the concept of servant-leadership. Rather than a producer, director, or lead designer feeling like the boss of other people who are supposed to do what they say, it can be healthy and constructive for them to approach the development as another collaborator on the team, just with particular responsibilities to look out for and different types of experience to draw from. They’re having to balance their own ideas with facilitating those of others to grow a shared vision, they’re trying to keep the team happy and on track, that’s their version of the compiler or Photoshop.

Handling Critique Productively

When critique comes up – whether of your game after it’s done or of a small subpoint in a disagreement – separate yourself personally from the point discussed. When people give feedback on work you’re doing, whether it’s on your programming, art, audio, or otherwise, the feedback is about the work you’re doing, it’s not feedback about you (even if, and let’s be fair here, we could all honestly benefit from a little more feedback about ourselves as a work-in-progress, too!).

Feedback is almost always in the interest of making the work better, to point out perceived issues within a smaller setting before it’s too late to fix the work in time for affecting more people, or before getting too far into the project to easily backtrack on it. Sometimes the feedback comes too late to fix them in this case, in which case rather than disagree with it accept that’s the case and keep it in mind to improve future efforts (this isn’t the last game or idea you’re ever going to work on, right?).

Defensiveness, of the sort mentioned in the recent playtesting entry, is often counterproductive, or at lease a waste of limited time and energy.

Systems and Regular Channels

Forms and routine one-on-one check-in meetings can feel like a bureaucratic chore, but in proper balance and moderation they can serve an important function. People need to have an outlet to have their concerns and thoughts heard. People need to be in semi-regular contact with the people who they might need to raise their concerns with, before there is a concern to be raised, so that there’s some history of trust and prior interaction to build upon in those cases and it doesn’t seem like a weirdly hostile exception just to bring up something small.

In one of the game development groups I’ve been involved with recently we were trying to narrow down possible directions for going forward from an early stage when little had been set into action yet. From just an open discussion, three of the dozen or so ideas on the whiteboard got boxed as seeming to be in the lead. When we paused to get a show of hands to see how many people were interested in each of the ideas on the board, we discovered that one of the boxed items had only a few supporters – those few just happened to be some of the more vocal people in the room. Even introducing just a tiny bit of structure can be important in giving more of an outlet to the less outspoken people involved with a project, who have ideas and considerations that are likely just as good and, as mentioned earlier, probably weighing different sets of concerns and priorities.

Practice, Make Mistakes to Learn From

Seek out opportunities to get more practice communicating. In all roles, and at all scales. As part of a crowd. In front of a crowd. In formal and informal settings. Out with a few people. Out with a lot of people.

Now, for personal context: I don’t drink. I don’t go to bars or clubs. I’ve admittedly never been one for parties. This weekend I have no plans to watch the Super Bowl. I’m not saying you should force yourself to do things that you don’t want to do. What I am saying is to look for (or create) situations where you can comfortably exercise your communication abilities. Whatever form that may take for you.

Seek out opportunities to get more practice communicating.

Given a choice to work alone or work with a group, welcome the opportunity to deal with the challenges of working with a group. Attend a meetup. Find some clubs to participate in. When a team you’re on needs to present an update, volunteer to be the one presenting that update.

Communication is a game development skill. As with any other game development skill, you’ll find the biggest gains in ability through continued and consistent practice.