Bagaimana seorang PM Dapat Mengubah Produksi Seni: Sebuah Studi Kasus dalam Game AAA

Disclaimer

Saat bekerja sebagai project manager, saya sering mendengar komentar seperti: "Untuk apa kita butuh PM? Apa yang sebenarnya mereka lakukan? Mereka hanya bicara dan tidak lebih." Ini adalah opini yang cukup umum.

Jadi saya menyiapkan artikel tentang apa yang sebenarnya bisa dilakukan PM (bersama tim mereka) dan seberapa besar dampak pekerjaan itu terhadap sebuah proyek. Seperti yang kami PM dan producer sukai — dengan angka, tabel, dan grafik. Ada tiga bagian tentang Art Pipeline, Daily Routing Optimisation, dan JIRA etiquette.

Kasus ini berasal dari pengalaman pribadi saya dan fokus pada bagaimana kami membangun departemen Cosmetics dari nol pada proyek AAA dan akhirnya mengoptimalkan produksi art, mempercepat 3,3 kali lipat.

Terima kasih banyak. Selamat membaca.

Art Pipeline

Kasusnya

Suatu kali saya pindah ke produksi sebagai Project Manager dengan misi: membangun departemen cosmetics yang akan menghasilkan skin (dan lainnya) untuk battle pass dan event in-game.

Pada saat yang sama, kami sudah memiliki departemen character art. Mereka telah membuat delapan karakter dalam berbagai tahap penyelesaian dan satu skin tier tinggi dengan perubahan geometri. Memproduksi skin tunggal itu memakan waktu 16 bulan bagi artist.

Tugas saya adalah membangun pipeline produksi yang berfungsi dan sepenuhnya memenuhi persyaratan publisher pada tanggal rilis: 21+ skin dengan geometri baru dan 40+ recolor. Setelah itu, kami harus merilis 7+ skin dari berbagai jenis setiap bulan — dan tahun berikutnya, menggandakan angka tersebut.

Pekerjaan

Pertama, saya menganalisis pengalaman sebelumnya dan kecepatan produksi mesh saat ini (karakter dan skin). Menggunakan data dari Jira dan banyak spreadsheet Excel, kami mengidentifikasi beberapa titik lemah.

Roadmap produksi art

Tidak ada roadmap terstruktur untuk produksi character art secara umum dan cosmetics khususnya. Mesh dianggap sebagai bagian dari pipeline pengembangan karakter, dan semua pekerjaan terkait ditempatkan ke dalam tiga tahap besar — L0, L1, L2 — dari prototipe hingga versi akhir yang dipoles. Setiap tugas berukuran besar ini bisa melebihi panjang sprint tidak hanya dua siklus, tetapi kadang tiga atau bahkan empat.

Kurangnya standar

Setiap mesh diperlakukan sebagai fitur R&D. Ketika kami membandingkan tahap L0/L1/L2 di berbagai kasus, kami menemukan bahwa mereka membutuhkan waktu yang sangat berbeda — baik clean time (jam tercatat) maupun dirty time (jeda antara pembuatan tugas, memindahkannya ke "in progress," dan menandainya "done"). Bahkan jumlah tugas untuk jenis mesh yang identik sangat bervariasi, dan beberapa di antaranya memiliki deskripsi yang hampir tidak mungkin dipahami.

Hal terpisah yang menonjol: satu artist yang ditugaskan bekerja pada mesh dari awal hingga akhir (berdasarkan riwayat assignee). Dan selama produksi, tidak ada titik logis di mana dia bisa menyerahkannya kepada orang lain tanpa kehilangan kualitas atau waktu. Seluruh tugas terlihat seperti satu blok pekerjaan besar yang berkelanjutan.

Kurangnya transparansi proses

Tidak jelas apa yang terjadi selama pengembangan atau bagaimana itu dilakukan. Kualitas dan konsistensi update tugas sepenuhnya bergantung pada developer itu sendiri. Tidak ada cara untuk melacak kemajuan dari jarak jauh atau di luar stand-up pagi. Jika seorang artist sakit, lead bisa sebagian mengambil alih tugas mereka, tidak meninggalkan catatan sama sekali, dan tetap menutupnya.

Jumlah iterasi

Bahkan dari riwayat status dasar sudah jelas bahwa tugas tersebut masuk review, lalu kembali lagi, kemudian kembali ke review, dan kemudian kembali ke pekerjaan. Dan itu belum termasuk ketiadaan total komentar yang menjelaskan mengapa tugas dikembalikan ke pekerjaan dan kemudian dikirim kembali — tidak sepatah kata pun.

Kami berkumpul dengan lingkaran kecil Illuminati kami — saya (sebagai PM), principal artist, dan art lead — dan mulai bekerja.

Solusi

Untuk memulai, kami membuat dua keputusan penting tingkat tinggi untuk menghentikan kebingungan di tingkat atas.

Kami memperkenalkan grade

Sebelumnya, proyek penuh dengan berbagai istilah dan label: recolor, paintjob, skin, premium skin, veterans, dan sebagainya. Setiap kata merujuk pada jenis pekerjaan yang berbeda, yang hanya membuat kami semakin bingung. Kami menghilangkan semua itu dan memperkenalkan dokumen yang dengan jelas menguraikan perbedaan antara skin dan grade mereka.

Aturan "One skin = One epic = One branch"

Saya meminjam aturan organisasi ini dari tim pengembangan karakter. Satu epic mencakup semua pekerjaan terkait skin di sisi pengembangan. Setiap epic berisi satu branch dan satu pull request yang didedikasikan untuk skin tersebut. Pada gilirannya, epic terhubung ke inisiatif/fitur season (atau event) yang relevan untuk navigasi yang lebih mudah.

Ini adalah titik awal kami. Dari sana, kami membangun kembali seluruh workflow.

Kami menyingkirkan L0–L1–L2

Sebagai gantinya, kami membagi produksi sesuai dengan logika produksi aktual: Design → Geometry → Textures → Implementation.

Setiap tahap dipecah menjadi langkah-langkah logis yang lebih kecil, misalnya: \n Concept: Moodboard – 2D Sketch – 3D Sketch (jika diperlukan) \n Geometry: Low Res – High Res – FBX File Import \n Implementation: Rig – GD Setup – Art Review – QA

Skin itu sendiri juga dibagi menjadi tiga bagian: body, weapon, dan modules. Artinya sejak saat itu kami bisa memiliki tiga tugas terpisah, seperti: \n Body – Geometry Low Res, \n Weapon – Geometry Low Res, \n Modules – Geometry Low Res.

Ini mengubah apa yang dulunya satu blok pekerjaan besar menjadi konstruktor seperti Lego yang bisa didistribusikan di antara artist tergantung pada beban kerja mereka. Sekarang mungkin untuk melacak dengan tepat tahap mana produksi saat ini berada.

Roadmap produksi art yang baru

Pada dasarnya, semua yang telah kami lakukan di atas diatur sebagai urutan tindakan. Grafik ini membantu kami — dan PM mana pun yang mungkin perlu menggantikan saya selama cuti sakit atau liburan — memahami di mana dan proses mana yang bisa dijalankan secara paralel untuk menghemat waktu.

Format terpadu untuk Epic dan tugas

Epic sekarang hanya berisi tugas yang terkait secara ketat dengan grade skin — tidak ada yang ekstra.

Setiap epic mencakup konsep skin dalam deskripsinya, serta kriteria penerimaan dari producer.

Ini mengurangi kebingungan dan memberi artist pemahaman yang jelas tentang apa yang diharapkan di setiap tahap. (Kemudian kami menyempurnakan deskripsi tugas lebih lanjut, tetapi itu terkait dengan topik rutinitas harian, yang akan dibahas selanjutnya.)

Saya juga menyiapkan bagian terpisah yang muncul di Confluence dengan Mira board di mana semua deskripsi ini terdaftar untuk setiap tugas, dengan komentar untuk project manager yang menjelaskan kapan dan tugas apa yang harus dibuat, bersama dengan formula Jira yang bisa langsung disalin dan ditempelkan ke dalam body tugas.

Estimasi

Kami mencoba memecah tugas sehingga mudah direncanakan. Proyek menggunakan sprint dua minggu, jadi kami bertujuan menemukan struktur umum: tidak terlalu melampaui batas sambil tetap memberikan setiap tugas titik penyelesaian yang logis.

Terima kasih besar kepada kolega saya — tanpa pengalaman mereka kami tidak akan bisa memecah ini dengan tepat. Mengandalkan angka Jira saja akan jauh lebih sulit, karena dalam produksi art keterampilan spesialis individu sangat penting, dan saat merancang estimasi, kami harus menemukan titik tengah emas antara apa yang secara realistis bisa kami sampaikan dan apa yang ingin kami capai. Begitulah kami sampai pada formula bahwa satu langkah pengembangan = satu sprint ditambah dua hari paling banyak.

Sekarang artist bisa melihat berapa banyak waktu yang mereka miliki untuk setiap tugas dan seberapa dekat mereka dengan menyelesaikannya. Dengan komunikasi yang tepat, ini menjadi alat pendukung. Jika seorang artist melihat bahwa mereka memiliki tiga hari tersisa untuk tugas tetapi memahami mereka tidak akan menyelesaikannya — mereka bisa secara proaktif memberi tahu saya.

Ini berarti saya tidak harus "mengontrol" developer; mereka memiliki semua alat untuk membantu saya dan mengangkat bendera merah di mana kami mungkin melewatkan deadline.

Hasilnya, kami berhasil mencapai otonomi developer. Ketika membuka epic, artist menemukan tugas siap dan sepenuhnya disiapkan yang bisa mereka mulai segera — bahkan jika mereka tidak sepenuhnya yakin apa yang harus dilakukan pada awalnya. Kami membuat sesi review dan kriteria evaluasi transparan.

Hasil

Langsung ke intinya. Hanya angka.

Itulah kasusnya.

\ \ \