Game dengan scope kompleks biasanya tidak gagal karena tim kekurangan ide. Justru sebaliknya: terlalu banyak hal menarik ingin dibuat secara bersamaan, sementara waktu, budget, dan kapasitas produksi tetap terbatas.
Karena itu, Strategi Production Planning perlu mengubah visi kreatif menjadi rencana yang bisa benar-benar dikirim. Producer harus memahami kapasitas tim, risiko teknis, kebutuhan outsourcing, dependency lintas disiplin, hingga ruang untuk revisi.
Production plan yang sehat juga tidak membuat semua orang bekerja 100% kapasitas sepanjang waktu, karena proyek game hampir selalu menghadapi perubahan dan pekerjaan tak terduga.
Rencanakan Berdasarkan Kapasitas Nyata Tim
Punya 20 anggota tim tidak berarti proyek mempunyai 20 orang penuh untuk membuat feature setiap hari.
Programmer menghadiri meeting, designer melakukan playtest, artist menunggu feedback, lead melakukan review, dan sebagian anggota mungkin harus memperbaiki bug produksi sebelumnya.
Karena itu, resource planning harus menggunakan effective capacity.
Scrum Guide menjelaskan bahwa pilihan pekerjaan untuk Sprint sebaiknya mempertimbangkan performa sebelumnya dan kapasitas developer yang tersedia. Informasi tersebut membuat forecast menjadi lebih realistis.
Misalnya empat programmer secara teori memiliki 80 developer-days dalam satu bulan.
Setelah dikurangi support, meeting, code review, bug fixing, dan ketidakhadiran, kapasittas feature work mungkin hanya sekitar 55–60 hari.
Schedule sebaiknya menggunakan angka kedua.
Buat Work Breakdown berdasarkan Disiplin
Scope game sering terlihat sederhana dari perspektif design document.
Satu boss baru misalnya terlihat seperti “buat satu boss”.
Di production plan, pekerjaan tersebut mungkin melibatkan concept art, modeling, rigging, animation, AI, combat design, VFX, sound, UI, localization, QA, performance optimization, dan implementation.
Inilah alasan work breakdown penting.
Setiap deliverable perlu dipecah hingga tim dapat melihat siapa yang mengerjakan, apa dependency-nya, dan kapan output diperlukan tim berikutnya.
Unity menyarankan milestone pertama berisi highest-priority features serta critical dependencies, lalu fitur lain dapat dipisahkan ke milestone berbeda ketika scope mulai terlalu besar.
Breakdown seperti ini juga membuat biaya tersembunyi lebih terlihat.
Fitur yang terlihat kecil di design mungkin sebenarnya mahal karena menyentuh delapan disiplin berbeda.
Gunakan Risk-First Planning
Tim sering mengerjakan fitur termudah lebih dahulu karena progress terlihat cepat.
Namun untuk proyek kompleks, lebih aman membuktikan risiko terbesar lebih awal.
Atlassian menyarankan risk management plan mencakup risiko timeline, resource, budget, teknis, serta stakeholder. Setiap risiko idealnya dinilai dari likelihood, impact, ownership, dan mitigation plan.
Bedakan Known Work dan Uncertain Work
Membuat variasi prop menggunakan pipeline yang sudah matang relatif mudah diprediksi.
Membangun multiplayer rollback networking yang belum pernah dibuat tim jauh lebih tidak pasti.
Jangan memberikan confidence yang sama pada keduanya.
Prototype technical risk lebih awal.
Jika sistem ternyata membutuhkan empat bulan alih-alih enam minggu, tim masih punya kesempatan mengubah design atau scope sebelum puluhan fitur lain bergantung padanya.
GDC Production Workshop menempatkan prototype mekanik dan teknologi pada tahap concept, kemudian tools, pipelines, core mechanics, first playable, dan vertical slice pada pre-production. Pola ini menekankan validasi sebelum produksi penuh dimulai.
Sisakan Buffer untuk Ketidakpastian
Production plan yang memakai 100% waktu sampai hari launch bukan rencana agresif.
Itu rencana tanpa ruang kegagalan.
Bug kritis, certification issue, perubahan platform SDK, revisi art, vendor delay, dan feedback playtest hampir pasti membutuhkan waktu.
Buffer dapat ditempatkan pada milestone, technical risk, outsourcing delivery, maupun closing phase.
Tidak harus berarti menambahkan angka acak 30% ke semua task.
Gunakan historical data.
Jika environment team rata-rata membutuhkan tambahan 15% waktu untuk polish dan optimization, masukkan pola tersebut dalam forecast.
Buffer juga sebaiknya tidak dipublikasikan sebagai “waktu kosong untuk menambah fitur”.
Jika setiap ruang aman langsung diisi scope baru, buffer kehilangan fungsi sebelum masalah sebenarnya muncul.
Kelola Dependency Lintas Tim secara Aktif
Dependency tidak cukup dicatat lalu dilupakan.
Ia harus dipantau.
Atlassian menjelaskan bahwa dependency management membantu tim mengidentifikasi critical handoff, mengatur pekerjaan yang dapat berjalan paralel, serta memperkirakan dampak perubahan terhadap schedule.
Misalnya cinematic team membutuhkan final character rig pada minggu ke-12.
Jika character rig terlambat tiga minggu, cinematic tidak hanya terlambat tiga minggu. Motion capture cleanup, facial animation, camera work, audio sync, localization, dan QA cinematic juga ikut bergeser.
Buat dependency review mingguan untuk pekerjaan kritis.
Producer tidak perlu mengontrol setiap detail, tetapi harus tahu blocker mana yang mempunyai efek domino terbesar.
Koordinassi seperti ini jauh lebih murah daripada menyelesaikan bottleneck ketika beberapa tim sudah berhenti bekerja.
Pisahkan Feature Complete dan Content Complete
Salah satu kesalahan schedule adalah mencampur pembangunan sistem dengan produksi konten.
Misalnya quest system belum stabil tetapi tim sudah membuat 80 quest menggunakan tool yang terus berubah.
Setiap perubahan sistem kemudian memaksa revisi massal.
GDC Production Workshop menggambarkan Alpha sebagai versi kasar tetapi fully playable, dengan feature set lengkap meskipun sebagian konten masih placeholder.
Setelah itu, fase post-production berfokus pada penyelesaian konten, balancing, optimization, localization, accessibility, telemetry, dan bug fixing menuju Beta.
Konsep tersebut membantu production planning memisahkan dua pertanyaan:
“Apakah sistemnya bekerja?”
dan
“Apakah seluruh kontennya sudah selesai?”
Jangan meningkatkan volume content production terlalu cepat sebelum pipeline relatif stabil.
Kalau tidak, perubahan kecil pada sistem dapat menciptakan rework dalam skala besar.
Terapkan Change Budget pada Scope Baru
Ide baru akan terus datang sampai game hampir selesai.
Playtest menghasilkan feedback. Marketing melihat peluang. Creative director menemukan sesuatu yang terasa kurang.
Tidak semuanya harus ditolak.
Namun setiap perubahan membutuhkan biaya.
Atlassian menekankan bahwa scope creep muncul ketika deliverable bertambah tanpa perubahan sepadan pada timeline, budget, atau resource. Scope baseline dan proses change control membuat trade-off tersebut terlihat.
Gunakan konsep change budget.
Misalnya proyek menyediakan kapasitas terbatas setiap milestone untuk feedback atau improvement yang belum diprediksi.
Jika kapasitas tersebut habis, fitur baru harus menggantikan pekerjaan lama, pindah ke post-launch, atau mengubah deadline.
Cara ini membuat diskusi lebih sehat.
Pertanyaannya bukan “apakah ide ini bagus?”
Hampir semua ide bisa terdengar bagus.
Pertanyaan produksi adalah “apakah ide ini lebih berharga daripada pekerjaan yang harus kita korbankan?”
Gunakan Definition of Done yang Sama
Satu tim mungkin menganggap feature selesai ketika kode sudah berjalan.
QA menganggap selesai ketika semua severe bug ditutup.
Art team menganggap selesai setelah final asset masuk.
Perbedaan ini membuat progress report terlihat jauh lebih baik daripada kenyataan.
Scrum Guide menggunakan Definition of Done untuk menciptakan pemahaman bersama tentang kondisi Increment yang memenuhi standar kualitas.
Dalam game production, Definition of Done dapat disesuaikan per milestone.
Misalnya feature baru baru dianggap selesai jika implementation masuk build, UX tersedia, save/load bekerja, localization string sudah tersedia, basic telemetry dipasang, dan QA acceptance selesai.
Tidak semua proyek membutuhkan aturan sama.
Yang penting seluruh tim memakai definisi yang konsisten.
Hal ini mengurangi situasi ketika dashboard mengatakan “90% complete” tetapi masih ada dua bulan pekerjaan integrasi.
Review Plan melalui Data, Bukan Perasaan
Production plan perlu dikalibrasi sepanjang proyek.
Bandingkan estimasi dengan actual duration.
Track jumlah rework, blocker days, bug volume, outsourcing delay, dan completion rate milestone.
Jika tim environment terus membutuhkan 25% lebih lama dibanding plan, jangan berharap milestone berikutnya tiba-tiba sesuai estimasi lama.
Perbarui forecast.
Atlassian menekankan bahwa project plan harus mencakup scope, deliverables, risks, dependencies, schedule, dan baseline yang dapat digunakan untuk mengukur perubahan selama pelaksanaan.
Historical delivery data menjadi semakin bernilai ketika proyek bertambah panjang.
Production planning yang matang bukan berusaha membuktikan rencana awal benar.
Ia terus memperbaiki rencana berdasarkan kenyataan.
Dokumentassi perubahan juga membantu tim memahami mengapa deadline bergeser sehingga keputusan tidak hanya bergantung pada ingatan meeting beberapa bulan lalu.
Strategi Production Planning untuk scope kompleks harus menggabungkan kapasitas nyata, risk-first planning, dependency management, buffer, Definition of Done, dan kontrol perubahan.
Jangan mengukur kesehatan proyek hanya dari banyaknya task yang selesai. Ukur apakah milestone benar-benar menghasilkan build yang semakin dekat ke target.
Gunakan data aktual setiap sprint untuk mengkalibrassi forecast dan memotong risiko sebelum berubah menjadi krisis produksi.