Aiming 開發者信條

專案導向組織

跨領域(interdisciplinarity)的必要性

過於明確的分工
過於明確的分工
在可行範圍內相互支援的團隊
在可行範圍內相互支援的團隊

我們不斷挑戰新的領域以及新的平台,商務環境變化速度也很快。

對於找不到答案的問題必須另尋途徑找到突破點的類似狀況,過於明確的分業分工、過於顯著的上下關係會是失敗之因,往往會造成「將失敗的原因推諉他方(其他部門或上司)」的情況。

遊戲以及服務的成立,需要各方面的人才。遊戲製作人、企劃、2D 以及 3D 繪圖工程師、UX 以及 UI 設計師、腳本設計師、資料處理者、KPI 分析師、市場調查人員、客服支援人員……等擁有各種專業性質的一群人,只有融入團隊、不分上下,朝向相同目標邁進,才能夠獲致成功。 我們的工作,從根本上來說就需要跨領域性。

專案導向式的座位安排

Aiming 內部的座位安排
Aiming 內部的座位安排

跨領域的構想,首先體現在 Aiming 內部的「座位安排」上。一款遊戲需要經過反复的試驗嘗試才會越磨越光,若是對於應該進行的變更表示「辦不到」,做出來的只會是一款爛遊戲。信任企劃,甚至時而自己嘗試企劃或思考商務的基本面,盡可能提昇團隊 Output 價值,這份努力不受任何專業性的限制。

因此,我們不採取類似「工程師孤島」方式的座位分配,而讓有相同目的的成員不分職種、不分關係集中於一處,一同進行工作。

T型技能的價值與讀書會

T型スキルを持ち寄った組織

根據專業進行分工而導致失敗,在程式開發中也同樣會發生。若是以「誰來寫伺服器」「誰來寫用戶端程式」「誰來設計資料庫」的方式分派,一旦發生問題,很容易出現「這是負責寫伺服器的問題」之類的指責。

在網路遊戲中,伺服端、用戶端以及資料庫必須串連動作,才能建立起整個功能。用戶端負責人最低限度應該具備能夠理解伺服端負責人意圖的實務經驗,不然將難以理解對方的主張,導致相互爭論。 除了本身專業以外,廣而淺的知識、經驗以及好奇心也很重要,有助於減少爭執發生。

Aiming 每週都舉辦工程師讀書會。讀書會能夠提供拓寬知識領域的契機,是很重要的一環。 舉凡 3D 遊戲引擎的話題、網路服務擴縮性的話題、源碼管理以及佈署方法的話題、網路環境的話題等等,我們舉辦非常多元的讀書會,也非常推薦同仁們參加與專案無關的技術領域讀書會。

好奇心的價值

Aiming 制作風景

T型技能的產生源自好奇心的萌芽,好奇心則是一種享受變化之樂的能力。

工程師對於自己慣用而熟悉的語言、程式庫、開發平台太過固執,很容易醞釀不願追隨變化的習氣以及過時老舊的系統。以某個程式 X而論,X 專家之所以是專家,並非因為只知道 X 程式而已,也了解 Y 甚至是 Z 程式,這樣才清楚 X 的優缺點所在。當 X 程式過於老舊的時候懂得適時放棄,這才是真正的專家。

個人的好奇心,能創造出經常接觸新環境的組織風氣,而這股風氣能夠促進對陳腐的抗性,並建立能夠挑戰新事物的組織基礎。

變化為善 – 敏捷開發