遊戲產業歷史故事【25】有問題的是制度?還是人?

在遊戲開發的過程中,不同的遊戲公司會採用不同的組織架構。這些不同的組織架構都不是完美的,因此在執行專案的過程中會冒出一些問題。遇到這些問題,每間公司解決寸問題的方法各有不同,有的解決方法可以找出問題,讓公司未來的遊戲開發進行更加順暢;不過有的時候沒有找到真正的問題,反而會造成更大的問題。

小型的遊戲公司﹝或是只有一個專案在運作的公司﹞通常會採用專案制,所有研發專案的成員都由專案的主導人來指揮。至於中大型的遊戲﹝或是有多個專案在運作的公司﹞有的則會採用矩陣式的組織架構,將所有的開發成員依職種分為各部門,然後再依各專案的需求由各部門的主管負責人力的指派,而這些被指派到專案的成員,則由專案的主導人指揮和管理。

這兩種制度各有優點,也各有缺點。不過只要運用得宜,其實在遊戲開發的領域裡也都可以順利的達成遊戲開發的任務。不過當制度執行時出了狀況,要怎麼處裡這個狀況,想辦法讓制度可以繼續運作下去,就看得出每間公司的本事。

以下這段故事,是在這兩個制度中搖擺的某間遊戲公司的故事:

故事的主角是一間名叫學友的遊戲公司﹝假名,請勿對號入座﹞,在那個遊戲市場還沒有進入線上遊戲的時代裡,這間公司雖然不像當時市場上的罐頭﹝假名﹞和鯨魚﹝假名﹞這兩間遊戲公司的規模那麼大,不過也算是一間中型的遊戲公司。靠著每年固定推出的兩到三款單機遊戲,這間公司的業績持續的成長,員工的人數也越來越多。

公司的規模變大了,以往的開發制度已經不符公司的需求,因此老闆聽從某個從事企管方面工作朋友的建議,引進了『矩陣式的組織架構』這個制度,將原本公司研發部門的員工依工作的類別劃分為企劃、程式、美術這三個部門,由比較資深的員工擔任這三個部門的主管,然後再將這三個部門的人員分別撥到目前正在進行的三個專案。由於夠資格的資深員工不夠多,因此其中程式和企劃部門的主管也各自兼任了一個專案的負責人。

目前公司的這三個專案,有個甲專案﹝程式主管帶領的那個﹞即將在幾個月後推出,矩陣式組織架構的特色,就是公司比較容易動態調整人力,在專案時程最緊張的時候調動其他專案的人力來協助,然後在專案推出後再將這些人力調往其他的專案。於是在這樣的制度下,其餘兩個專案為了配合甲專案的上市調動了部份人力來協助,而在這些支援人員的協助下專案提前的完成,也順利的推出上市了。

甲專案上市後,照矩陣式組織架構的運作模式,甲專案應該要釋出多餘的開發人力去支援其他的專案。不過這個時候遊戲市場開始有點轉變,線上遊戲的出現讓原本單純的遊戲市場有了不太一樣的挑戰。從目前市場上對於線上遊戲的接受度來看,原本飽受盜版威脅的單機遊戲開發廠商似乎找到了新的一條路。

甲專案的負責人是程式部門的主管,他認為未來公司應該要轉向線上遊戲,於是向老闆報告了之後接下來要開一個新的專案就是線上遊戲。由於線上遊戲對於學友公司是新挑戰,因為原本該派去支援其他專案的人力在『開發新技術』的說法下就不釋放出來了。而且因為甲專案的負責人自己也是程式部門的主管,他還調動了其他專案比較資深的程式人員來到自己的專案,開始研發公司的線上遊戲相關技術。

甲專案推出後不但沒有釋出人力,反而還調走了其他專案資深的程式人員,這樣的作法當然會引發乙專案和丙專案負責人的反彈。丙專案距離推出上市的時間還有一段距離,因此受到的影響並不是很大。但是乙專案幾個月後就要上市,原先調派人力去支援甲專案的時候以為接下來公司會調派較多的人來乙專案支援,現在不但支援的人力沒有,連專案中最資深、技術最好的程式還被程式部門的主管調到甲專案的後續專案。照目前的狀況,乙專案的時程以及專案的表現都會受到影響。

果然後來乙專案在開發的後期受到人力不足的影響,專案的內容因為進度砍掉了一些,也比原本規劃的上市日期晚了幾週。專案上市後銷售的成績沒有預期的好,由於銷售的成績不是很理想因此乙專案的成員沒有拿到獎金。乙專案的負責人和成員們自然為了這件事找老闆抱怨,雖然老闆想辦法安撫他們,不過這不滿的情緒已經埋在乙專案負責人的心中。由於乙專案負責人也是企劃部門的主管,接下來他也為了自己後續的專案作了利己的人力調度。

原本應該是利於人力調度的矩陣式組織架構,才不過運作了不到一年的時間,就因為甲專案和乙專案的推出接連著引發了公司內部的不滿。眼見這個制度不但沒有幫助公司做更好的人力運作反而還造成反效果,老闆決定取消這個制度的運作,將公司研發單位的運作模式回到原本的專案制。從矩陣式組織架構再次回到專案制,各專案的人力又重新的調動了一次,不過原本學友公司的研發人力就沒有辦法同時組三個完整的研發組,因此各專案都有人力不足的現象。

為了解決人力不足的問題,學友公司開始大規模的招募研發人員,在短短的時間內,公司的研發人力增加了許多。不過人力的增加並沒有解決原本人力不足的問題,因為新招募的研發人員有的需要熟悉環境,有的則是沒有經驗需要重新訓練才能進入狀況。而這招募和訓練需要比較有經驗的研發人員來處理,結果原本因為人力不足造成的專案進度延誤,又因為這些額外的負擔變得更為嚴重。甲專案和乙專案都是新開的後續專案,在進度部份延誤影響的有限,不過丙專案就在這樣的狀況下一拖再拖,等到專案完成的時候,市場已經被線上遊戲給吃掉了,所以專案的銷售成績更是不理想。

原本一間運作得很順利的公司,每年可以持續推出賺錢產品的遊戲公司,在接連兩款專案的銷售成績不理想的狀況下,面臨了公司虧損的這個結果。為了減低虧損的壓力,老闆決定要裁員來降低公司的開支,一口氣裁掉了許多的研發人員,原本三個專案的產品線在這樣的裁員動作下縮成了兩個。丙專案的大多數成員在這一波的裁員下被砍掉,前不久才加入公司一些新員工也在這裁員動作下被砍掉,不久之前才大舉徵才的行為現在看起來顯得很諷刺。

公司的狀況不佳,老闆那位從事企管方面工作的朋友又成為咨詢的對象,在這位朋友的建議下,公司決定要再改變現在的組織架構,用新的方式來面對下一年的挑戰‧‧‧

 

 

學友公司後來的狀況如何不是重點,銀狐也不希望各位花時間去研究這間公司未來的發展到底怎麼樣。在這裡要說的是不同的制度,原本就各有優點和缺點,有的時候一個制度執行的不順,其實出問題的並不是制度,而是執行這些制度的人。就以矩陣式組織架構來說,這樣的制度部門主管和專案負責人的任務是不同的。專案負責人的目標就是把手上的專案作好,因此他要盡量爭取對該專案最有利的成員;但是部門主管要看的是全部的專案,如何妥善的運作和調派人力是部門主管的工作。

學友公司讓專案負責人兼任部門主管是這一切問題的起因,如果這位主管能夠無私的看待所有的專案,在安排和調度人力時不會只以自己的專案為重,那麼人力爭議就不會發生。而公司無法針對這個問題來解決,放棄了矩陣式組織架構所導致的人力膨漲狀況,則是專案制運作時最常見的狀況。遭遇這些問題,其實都有更好的解決方法,不斷的改變制度,這種『三個月一小改,五個月一大改』的方式反而是最糟糕的。

  • 顏宏益

    屁股決定腦袋。

    • 有些人喜歡用『換了位置就換了腦袋』來批評人。不過在實務的經驗上,有些時候換了位置還真的需要換腦袋,如果不換,有時候反而會更糟糕。

      不過呢,並不是所有的人都適合轉換職位,原夲從事基層工作的老員工,隨著年資成長是不是適合擔任管理職,其實一直也都有很多不同的看法。找外面的人是一種辦法,不過也需要適應環境也需要時間的磨合,這也是另一個問題。

      • 顏宏益

        那…如果用原本的資深員工,去學習管理相關的課程,依狀況來轉換職位好像感覺也不錯。
        記得以前看過一本”成功人士”的傳記書籍,書上是這樣說的:要給優異的員工轉換職位的契機。大概意思熟悉且倦怠原本職位的員工,公司該多提供更換職位的機會。並不是一定往上”提升”,”平調”也是可以的。可惜技術取向的遊戲業應該是不適合這種方式的。

        話說我並沒有學習過管理相關的課程,所謂的企管畢業是真的有學到管理的精髓嗎?
        還是后宮甄環傳認真點看比較有幫助? XD