Seandainya Arsitek Harus Bekerja Seperti Programmer (1995)

Jika Arsitek Harus Bekerja Seperti Programmer

• Meminta arsitek untuk merancang dan membangun rumah tanpa mengetahui kebutuhan yang jelas.
• Rumah itu harus bisa memiliki 2 hingga 45 kamar tidur, dan kamar tidurnya mudah ditambah atau dihapus.
• Keputusan akhir akan diambil setelah melihat gambar denahnya.
• Rumah yang dipilih harus lebih murah dari rumah yang saat ini ditempati.
• Semua cacat rumah saat ini harus diperbaiki (seperti lantai dapur yang bergetar dan isolasi dinding yang kurang).
• Tetap gunakan praktik desain dan material paling mutakhir sambil meminimalkan biaya pemeliharaan tahunan.
• Diperlukan desain dapur yang bisa menampung kulkas model Gibson tahun 1952.
• Mendesain rumah yang memuaskan seluruh keluarga, termasuk ayah mertuanya, setelah mempertimbangkan pendapat semua orang.
• Jangan terlalu memikirkan detail kecil; susunlah rencana secara menyeluruh.
• Lebih diutamakan pengembangan rencana dan spesifikasi detail dibanding penyediaan sumber daya.
• Setelah rencana disetujui, atap harus selesai dalam waktu 48 jam.
• Harus mempertimbangkan selera beragam calon pembeli agar nantinya dapat dijual kepada orang lain.
• Sebelum rencana final dikunci, diperlukan persetujuan masyarakat setempat.
• Menyiapkan gambar arsitektur, meskipun desain akhir dapat diubah kemudian.
• Bertanggung jawab atas kenaikan biaya konstruksi akibat perubahan desain di kemudian hari.
• Proyek ini menarik karena memungkinkan penggunaan teknologi terkini dan desain yang lebih bebas.
• Istri menyebut bahwa ia mungkin memerlukan travel trailer, bukan rumah, dan meminta saran tentang hal itu.

Pendapat GN⁺

• Tulisan ini menyindir klien yang memberi tuntutan tidak masuk akal dan kontradiktif kepada arsitek, dan menyamakan secara cerdasnya dengan harapan serta tuntutan tak realistis yang sering dialami programmer.
• Ini dapat dibaca sebagai contoh pentingnya kebutuhan dan ekspektasi proyek yang jelas, serta pentingnya pengelolaan perubahan.
• Tulisan ini membantu pembaca memahami dan berempati pada masalah umum yang dialami profesional di bidang pemrograman dan arsitektur, serta menyampaikan tantangan manajemen proyek secara jenaka sehingga terasa menarik.

[GN⁺]

Komentar Hacker News

• Ringkasan komentar pertama:

  Dalam menjalankan proyek, pekerjaan harus dipecah secara rinci dan diestimasi, dan meskipun estimasinya tidak akurat, jika melebihi waktu yang ditentukan kita tetap harus bertanggung jawab. Harus melaporkan perkembangan selama satu jam setiap hari, dan mungkin juga mengulang pembaruan yang sama di pertemuan lain. Jika terjadi keadaan darurat, kita harus menanganinya, tetapi kondisi itu tidak boleh memengaruhi estimasi waktu.

• Ringkasan komentar kedua:

  Membangun rumah sering kali melibatkan percakapan dengan pemilik yang sulit atau orang yang menginginkan desain yang tidak enak, dan ini juga merupakan bagian dari kerja seorang insinyur perangkat lunak. Terkadang desain bisa salah atau tidak akurat, tapi orang tetap membangun rumah.

• Ringkasan komentar ketiga:

  Ini contoh yang sangat pas dari gagasan "cocktail party" tentang menganggap kita tahu bagaimana bidang lain dijalankan. Arsitek juga bisa menulis dengan asumsi dan kesalahpahaman serupa tentang para programmer.

• Ringkasan komentar keempat:

  Meminta arsitek membuat model berskala nyata sebelumnya untuk memeriksa fungsinya, dan membuatnya ulang dari awal jika tidak memuaskan. Karena sudah pernah membuatnya sekali, membuat ulang dengan perubahan semestinya tidak terlalu sulit.

• Ringkasan komentar kelima:

  Konstruksi dan rekayasa perangkat lunak adalah dua bidang yang sangat berbeda. Konstruksi memiliki banyak peran dan tanggung jawab, sementara rekayasa perangkat lunak terdiri dari manajer produk, desainer, insinyur perangkat lunak, auditor, dan lain-lain. Kedua bidang itu tidak bisa dibandingkan.

• Ringkasan komentar keenam:

  Lebih menyukai versi sebelumnya tentang tim pembangun jembatan. Dibaca sebagai tuntutan agar waktu kerja dinyatakan dalam bentuk "poin" dan juga kritik terhadap industri perangkat lunak. Umumnya orang IT cenderung menerima tuntutan yang tidak realistis, tetapi penting untuk membuat para klien mengerti realitas ini.

• Ringkasan komentar ketujuh:

  Kita harus melindungi privasi orang yang masuk ke rumah secara ketat sekaligus membuat komunikasi tetap lancar. Selain itu, harus menjamin keamanan dari kebakaran, ancaman fisik, dan orang lain, tanpa biaya tambahan atau pembatasan penggunaan.

• Ringkasan komentar kedelapan:

  Menganggap pemrograman mirip dengan konstruksi adalah anggapan yang salah. Menciptakan produk baru terdiri dari tahap desain produk dan tahap manufaktur. Arsitek maupun insinyur perangkat lunak sama-sama berada di tahap desain produk. Rekayasa perangkat lunak adalah bagian dari desain, bukan manufaktur berdasarkan desain akhir.

• Ringkasan komentar kesembilan:

  Sebagian besar pekerjaan adalah mendengarkan apa yang dibutuhkan orang lain. Orang-orang mungkin tidak tahu persis apa yang mereka inginkan, tetapi mereka ingin didengarkan terkait masalah mereka dan dibantu sebaik mungkin.