【Gamelook專稿,轉載請註明出處】
Gamelook報道/對於遊戲研發來說,似乎技術傾向最重的就是代碼團隊,然而,最近一名來自獨立手遊工作室BlackRiver Studios的主程序Ariel Madril Tota5在博客中表示,作為遊戲研發團隊的主程序,雖然強大的技術是必須的,但或許更重要的是與團隊之間的溝通和對團隊成員的管理,在博文當中,他分享瞭處理不同情況以及事情之間的方式,對於中小團隊的主程序們來說,或許是非常值得參考的,以下是博文的完整內容:
之所以可以寫出這篇博客,主要是因為過去一年多的研發,在此期間我整理瞭此前做遊戲研發的所有經驗。在遊戲團隊裡,我擔任過很多的角色,從初級到高級程序員,我後來成為瞭《Jake & Tess Finding Monsters Adventure》手遊版研發工作室的主程序,所以,接下來我希望分享一些我的經驗。
成為一個主程序,通常意味著你需要純粹的批判性思維和決策,但是,我們往往忽略的是人性化的方面。我們經常會遇到很多特別擅長優化代碼的主程,但真正能夠瞭解該如何與周圍同事協作的並不多。
所以,這篇文章主要講述主程職責的2個方面:與引擎工程師互動、專註於指導、沖突解決並保持團隊比較高的工作熱情;和其他領域的同事互動、與高層交流。
首先要說明的是,所有的人類都是有感情的。不管一個人的專註度有多高,他的決策、互動以及生產活動都或多或少地受到情緒的影響。如果這還不夠的話,那麼另一個在代碼團隊中比較常見的問題就是冒名頂替綜合征(imposter syndrome),他們的工作、思考過程、解決方案都暴露在同事的眼皮底下,而且需要重復地被審核。作為一個程序員,這會讓他們感到與同事們相比的時候不自信。
而作為一名主程序,你的目標是做出一個穩定的產品,及時地對代碼進行高度優化和有序的組織。不過,你所處的環境是會經常發生巨大變化的,這就是遊戲行業的常態,很多的遊戲功能都會改變,遊戲項目的研發計劃和發佈日期通常也會不斷變化。
最重要的是領導團隊成員而不是代碼
主程序可能隻是這個職位的頭銜而已,但你通常領導的並不是一個項目,而是做這個項目的人,因此有些事情可能是很多註意不到的,比如:不同資歷和經驗的人在做同樣的代碼庫;不同的團隊成員存在不同的編碼風格;不同的區域會直接影響接下來的代碼;挫敗感是經常存在而且容易被低估的因素,會影響團隊寫代碼的動力;每一個超過3名碼農團隊的項目都會存在編程技術和風格的巨大差異,尤其是在嘗試做同一個代碼庫的時候。
需要知道的是,他們很大可能會遭受冒名頂替綜合癥的幹擾,特別是與其他團隊成員對比的時候。
在一個項目的研發過程中,保證團隊的工作動力是一項需要長期維護的工作,與此同時,你還需要保證代碼質量、穩定性和優化必須是每一個團隊成員都做到的,而這個要求往往會導致有些人遭到批評。
對於主程們來說,批評一個程序員的工作或許是最微妙的事情,如果批評得當,普通的程序員可以變得優秀,但如果不得當的話,很容易導致受批評的程序員出現工作效率低下,甚至是離職或者被炒魷魚。
由於程序員們經常會把自己的工作和同事們對比,所以在批評他們的時候把他的代碼和其他人對比或許是最糟糕的方式。
非常清楚的是,這個程序員的所有努力都應該是被認可的,而且要讓他知道,並不會因為代碼出現的錯誤被懲罰。相反的是,要和他們溝通如何達成更好的結果,並不僅僅是因為公司需要這樣,而是團隊認為他可以做得到。
即便你希望一個人把工作做好,用消極的語調也會讓談話對象的專註點偏移到不好的方面,而不是如何提高他的表現或者技術。
作為領導者,你需要打造一個舒適安全的環境讓團隊成員可以成長,避免讓他們承擔過多的壓力,即便是代碼方面沒有提高也不要讓他們覺得會因為一次的錯誤就被炒魷魚。
但是,不要誤以為我這麼說是讓你對人過於溫和,在項目開始的第一天,你就需要打造一個安全的環境,指導程序員們做出更好的結果必須是項目主程的日常工作之一。
瞭解你的團隊
對每個程序員的強項和弱點都做一個詳細的瞭解,瞭解他們的編碼風格,當問題出現的時候必須要及時和他們溝通。對每個團隊成員可能出錯的領域進行提前規劃,這可以讓指導者和被指導者都養成更好的編程習慣,同時確保遊戲代碼的穩定性和連貫性。
一個主程序不能把指責不好的編碼習慣並要求改變作為最後的方法,因為這樣做會導致被批評的人所寫出來的代碼會出現一系列的波動,他可能會自我辯護或者選擇不溝通,最可能出現的後果是,他的代碼進度會減緩,因為害怕犯新的錯誤,但是,越是這麼做,犯錯的概率就會越大。而且,這種情況下還很容易難以發現他的錯誤,因為由於不自信,他往往不會主動讓其他隊員看到自己的工作,不希望成為眾矢之的。
相反的是,當一個不好的編碼習慣出現的時候,一定要盡快指出,告訴程序員錯誤所在,當然,最好是通過建議的形式,解釋其中的原因以及如何用更好的方式來改變。
親自指導並找出更好的方法可以讓他的工作做的更好,然後認可他的努力並且恭喜他找到瞭新的解決方案。
如果一個問題的出現是此前發生的,而且是新的領導到來之後才發現的,那最好是做技術討論,而且應該選擇午餐談話的形式,而非把所有人都叫過來開會。
為什麼要像個保姆一樣?
可能看到這裡會有人問,為什麼主程序要做這麼多保姆照顧嬰兒一樣的事情?作為一個成熟的人,難道程序員們不應該自己找出這些問題並解決嗎?畢竟他們是技術人員,他們有辯證思維而且知道一個好的代碼該是什麼樣的。然而,人類是習慣性動物,很多人養成瞭不好的習慣卻自己沒有意識到。
改變習慣是困難的,如果被人對質的時候往往會引起自我辯護並且不願意做出改變。作為一個主程序,你必須瞭解人類的這個特性,養成良好的溝通技巧,不要因為這些問題的溝通帶來團隊成員之間的沖突。
坦率真誠的交流方式可能對於遊戲人是有效的,但這種方式很容易引發領導者和開發者之間的相互不滿,往往不會讓所有人為瞭更好的工作而彼此開誠佈公。
一個領導者往往不需要強調自己的權威或者告訴別人正確的做事方式,做一款遊戲並不像釘釘子那麼簡單。如果人們不夠投入,對於做這個遊戲不夠有動力或者熱情的話,他們很可能不會得出具有創意的解決方案,所以,要打造一個熱衷於迎接挑戰的團隊,提高遊戲研發水平。
平衡研發團隊和上層管理團隊
遊戲研發是微妙的,你的團隊不僅要完成遊戲研發, 還必須為其他項目創造工具,確保穩定性和及時性。成熟的大團隊可能在每個研發的細分領域都有專門的團隊,但中小團隊必須資源共享。不同的項目之間調用程序員並不像調動建築工人那樣簡單,在一個新的項目上是需要時間適應並且回到研發狀態的。
當高層管理人員想要直接幹涉研發過程的時候,開發者們面臨最大的問題就是代碼質量,因為這個要求會帶來比較大的變動,有可能需要重做,還可能帶來新的功能,給開發者們帶來大量的挫敗感。
作為主程,你必須反對不顧後果的改變,讓你的團隊盡可能避免出現因此帶來的騷動,隻接受必須進行的改變以及有可能完成的調整。這可能會帶來比較大的沖突,還會有人擔心因此丟掉工作。
但作為一名主程序,最重要的是有責任感。你需要負責項目的技術決策,如果有些是不合理的,那就不能讓步。一旦做不到的話,團隊所有的工作都需要做兩次,一次是進行不合理的改變,另一次就是糾正這個錯誤。這樣的話,整個過程就是一種損失,會給整個團隊帶來挫敗感。
除此之外,開發者們還會開始懷疑領導者做出的所有決策,因為讓這麼一個沒有意義的決策交給他們實施可能被認為是主程的決定(實際上也是的)。這樣的話,你們之間的信任會受到損害,未來的協作也會受到影響,你再交給他們什麼任務,團隊成員的熱情就沒那麼高瞭。
如何處理研發團隊和其他領域的問題
遊戲研發的每個領域都需要或多或少的代碼支持,功能方面的要求總是無止盡的,但這完全取決於研發團隊能夠做出多少。在研發過程中,遊戲功能的改變是無法避免的,隨著不斷地進化,這些功能往往會變成完全不同的事物。所以,代碼庫也會遭受影響,因為廢棄代碼會越來越多。為瞭解決這個問題,如果為瞭加入一個新功能而需要對舊系統進行過多修改的時候,最好是放棄它,也就是說,你需要重做。
這通常都會遭到制作團隊的抵制,因為他們沒有這麼多的時間完成,所以,這還是主程的工作,你需要確保重做所需要的時間是足夠的,這樣做的好處其實不止一方面。最明顯的好處是代碼的穩定性,因為代碼會變的有可預測性,而且更可靠。
另外,參與這些任務的程序員們對於這部分的代碼會更能接受,他們在做新功能的時候壓力和緊張感不會過大。加強代碼庫的決定意味著遊戲項目正變得更成熟,這部分代碼的編程會變的更容易和靈活。需要知道的是,如果剛加入一個團隊的主程不考慮到這些的話,他很容易就可以感受到來自各個方面的抵制。
一旦項目完成之後,代碼的穩定性和bug修復以及優化的便捷性會讓所有人都看到他們的努力是值得的,特別是此前從事過大項目研發而且每次都在截止日期前出現很多問題的成員們。這對於大團隊的開發者們來說,聽起來可能有點誇張,但作為手遊團隊,尤其是人員剛剛開始增長的工作室來說,這是你們都會遇到的問題。
結論
帶領一個程序員團隊一開始可能看起來是非常技術向的,但是,團隊之間的互動甚至會更加重要。主程有強悍的技術背景是必要的,但是,通常做這個職位的人在社交技巧方面的能力比較低,當這種情況發生的時候,那麼主程序就需要完成大多數的代碼工作,因為他不能直指導其他人做的更好,所以必須親力親為。這樣做也會讓他和團隊之間更有隔閡,給每一個程序員都帶來人人自危的心理。
不僅如此,主程序還需要足夠成熟,保護自己的研發團隊不受外界的幹擾,確保一個穩定而具有創造性的環境,讓每一個程序員都可以做出更好的結果來。