The Mythical Man-Month: Essays on Software Engineering
oleh Frederick P. Brooks Jr.
Sembilan wanita tidak bisa melahirkan bayi dalam satu bulan. Tapi sampai hari ini, masih ada manajer yang percaya sembilan programmer bisa.
1964. IBM sedang mengembangkan OS/360, sistem operasi paling ambisius yang pernah mereka buat.
Proyeknya molor. Manajemen panik. Solusinya terdengar masuk akal: tambah lebih banyak orang.
Hasilnya justru lebih buruk.
Fred Brooks, manajer proyek itu sendiri, menyaksikan langsung bagaimana keputusan yang kelihatannya logis ini malah membuat semuanya makin terlambat.
Bertahun-tahun kemudian, dia menulis satu esai untuk menjelaskan kenapa. Esai itu berkembang jadi buku yang sekarang dianggap salah satu teks paling berpengaruh dalam sejarah software engineering.
Brooks tidak menulis buku manual teknis. Dia menulis kumpulan pengamatan jujur dari kesalahannya sendiri, tentang kenapa proyek software punya cara unik untuk gagal, cara yang tidak berlaku sama di industri konstruksi atau manufaktur.
Salah satu kalimatnya menjadi begitu terkenal sampai punya nama sendiri: Brooks's Law.
“Adding manpower to a late software project makes it later.”
Kedengarannya berlawanan dengan akal sehat. Tapi begitu Anda paham alasannya, Anda tidak akan pernah melihat perencanaan proyek software dengan cara yang sama lagi.
Bagian 1: Kenapa Menambah Orang Justru Memperlambat Proyek
Bayangkan Anda dan seorang teman bisa menggali sumur dalam dua hari. Logikanya, sembilan orang seharusnya bisa selesai dalam waktu jauh lebih singkat.
Brooks bilang, logika itu berlaku untuk pekerjaan yang bisa dipecah rapi tanpa saling bergantung. Software bukan pekerjaan semacam itu.
Man-Month Adalah Ilusi Berbahaya
Konsep "man-month", anggapan bahwa jumlah orang dan jumlah waktu bisa saling ditukar secara linear, menurut Brooks adalah mitos yang berbahaya kalau dipakai untuk mengukur pekerjaan software.
Kenapa? Karena tugas-tugas pemrograman punya ketergantungan yang rumit satu sama lain, dan menambah orang baru berarti menambah beban komunikasi baru. Orang baru butuh waktu untuk belajar konteks proyek, dan waktu itu diambil dari orang-orang lama yang harus mengajarinya, bukan dari udara kosong.
Semakin banyak orang di dalam tim, semakin banyak pula jalur komunikasi yang harus dijaga, dan jalur ini bertambah jauh lebih cepat dibanding jumlah orangnya sendiri.
Bagian 2: Kompleksitas Komunikasi yang Tumbuh Lebih Cepat dari Timnya
Berapa banyak jalur komunikasi yang dibutuhkan tim berisi tiga orang? Tiga jalur.
Berapa untuk tim berisi sepuluh orang? Empat puluh lima jalur.
Anda menambah tiga kali lipat orang, tapi jalur komunikasinya meledak lima belas kali lipat.
Beban yang Tersembunyi di Balik "Menambah Tenaga"
Inilah akar dari Brooks's Law. Setiap anggota tim baru bukan cuma menambah kapasitas kerja, dia juga menambah jumlah percakapan, rapat koordinasi, dan potensi miskomunikasi yang harus dikelola seluruh tim.
Untuk proyek yang sudah terlambat, menambah orang di tengah jalan berarti anggota lama harus berhenti sejenak untuk mengajarkan konteks ke orang baru, sementara tenggat waktu tetap berjalan tanpa ampun.
Brooks tidak bilang menambah orang selalu salah. Dia bilang, menambah orang di proyek yang sudah terlambat, tanpa memikirkan biaya komunikasinya, hampir selalu memperburuk keadaan.
Bagian 3: Konsep Ahli Bedah, Cara Membuat Tim Besar Bekerja Seperti Tim Kecil
Kalau tim besar sulit dikoordinasi, tapi proyek besar butuh banyak orang, bagaimana jalan keluarnya?
Brooks mengusulkan sesuatu yang dia sebut "surgical team", struktur tim yang meniru cara kerja tim bedah di rumah sakit.
Satu Pikiran Utama, Banyak Tangan Pendukung
Di ruang operasi, ada satu ahli bedah utama yang mengambil semua keputusan kritis. Di sekelilingnya ada asisten, perawat, dan spesialis lain yang mendukung, tapi keputusan desain tetap datang dari satu kepala.
Brooks menerapkan pola yang sama untuk tim programming. Satu "surgeon" bertindak sebagai perancang utama sistem, dibantu co-pilot, administrator, penulis dokumentasi, dan penguji, masing-masing punya peran jelas yang mendukung sang perancang utama.
Kalau Anda punya dua puluh tim seperti ini, Anda sebenarnya cuma perlu mengoordinasikan dua puluh kepala perancang, bukan dua ratus orang sekaligus. Kompleksitas komunikasi turun drastis, sementara kapasitas kerja tetap besar.
Bagian 4: Integritas Konseptual, Kenapa Desain Sebaiknya Datang dari Sedikit Kepala
Pernah pakai software yang terasa seperti dijahit dari potongan-potongan berbeda, tidak konsisten, membingungkan?
Brooks bilang, itu tanda hilangnya conceptual integrity, keselarasan visi desain di seluruh sistem.
Kenapa Terlalu Banyak Koki Merusak Masakan
Menurut Brooks, sistem yang paling mudah dipakai dan dipahami selalu lahir dari satu pikiran, atau sekelompok kecil pikiran yang benar-benar selaras, bukan dari puluhan orang yang masing-masing menambahkan idenya sendiri tanpa arah bersama.
Tekanan jadwal sering memaksa perusahaan mempekerjakan banyak orang sekaligus untuk mempercepat pembangunan. Tapi tanpa satu arsitek yang menjaga visi keseluruhan, hasilnya adalah sistem yang berfungsi secara teknis namun terasa berantakan dari sisi pengalaman penggunanya.
Solusi Brooks bukan menolak tim besar, melainkan memisahkan dengan jelas antara arsitektur, yang harus dipegang segelintir orang, dan implementasi, yang bisa didistribusikan ke banyak orang begitu arsitekturnya sudah jelas.
Bagian 5: Kenapa Prototipe Pertama Anda Hampir Pasti Harus Dibuang
Ada satu nasihat dari Brooks yang sering bikin kaget engineer muda: rencanakan untuk membuang sistem pertama Anda.
Pengalaman yang Baru Terlihat Setelah Sistem Selesai
Menurut Brooks, saat pertama kali membangun sistem baru, Anda pasti akan menemukan bahwa asumsi-asumsi awal ternyata salah, begitu sistem itu benar-benar dipakai di dunia nyata.
Masalahnya, banyak tim justru terus menambal sistem pertama itu selamanya, alih-alih mengakui bahwa pelajaran dari sistem pertama seharusnya dipakai untuk membangun versi kedua yang jauh lebih baik.
Brooks juga memperingatkan bahaya sebaliknya, yang dia sebut "second-system effect". Setelah sistem pertama berhasil, tim sering jadi terlalu percaya diri di sistem kedua, menambahkan terlalu banyak fitur sekaligus karena merasa sudah tahu segalanya, dan akhirnya sistem kedua ini justru jadi terlalu rumit dan kembali bermasalah.
Pelajaran untuk Hari Ini
1. Jangan Buru-buru Menambah Orang ke Proyek yang Terlambat Pikirkan dulu biaya komunikasi dan waktu pelatihan yang harus ditanggung tim lama sebelum menambah anggota baru di tengah jalan.
2. Jaga Struktur Tim yang Punya Satu Pengambil Keputusan Desain Utama Meniru konsep tim bedah, biarkan satu orang memegang visi arsitektur, sementara yang lain mendukung eksekusinya.
3. Waspadai Godaan Menambahkan Terlalu Banyak Fitur di Sistem Kedua Kepercayaan diri berlebih setelah sistem pertama berhasil sering membuat sistem kedua jadi terlalu rumit dan sulit dikelola.
4. Terima Bahwa Versi Pertama Sistem Anda Kemungkinan Besar Perlu Dirombak Pengalaman nyata dari pemakaian sistem pertama adalah pelajaran berharga, bukan sesuatu yang harus ditambal selamanya.
Tentang Buku Asli
The Mythical Man-Month ditulis hampir lima puluh tahun lalu, dari pengalaman membangun sistem operasi yang berjalan di komputer mainframe raksasa. Tapi bacalah setiap barisnya hari ini, dan Anda akan menyadari betapa sedikit yang benar-benar berubah dari sisi manusia dalam proyek software.
Tim masih terlambat. Manajer masih tergoda menambah orang di menit-menit akhir. Dan sistem masih sering kehilangan kejernihan desainnya ketika terlalu banyak tangan ikut campur tanpa arah yang sama.
Di era ketika tim engineering makin terdistribusi lintas zona waktu, dan tekanan mengintegrasikan AI ke berbagai sistem produksi makin besar, pelajaran soal komunikasi, integritas desain, dan batasan penambahan sumber daya justru terasa makin relevan, bukan makin usang.
Pertanyaannya untuk Anda, kapan terakhir kali tim Anda menambah orang ke proyek yang sudah terlambat, dengan harapan itu akan mempercepat semuanya? Dan apakah harapan itu benar-benar terwujud?
