Joel on Software   Pojok Software Joel

Artikel-artikel "Joel on Software" lain dalam bahasa Indonesia

Artikel-artikel "Joel on Software" lain dalam bahasa Inggris

Email pengarang (hanya dalam bahasa Inggris)

"Saya tidak tahu apa yang salah pada tim pengembangan saya," pikir sang CEO. "Segalanya berjalan begitu lancar ketika kami memulai projek ini. Untuk beberapa minggu awal, tim bekerja gila-gilaan dan mendapatkan prototipe hebat yang bekerja baik. Tapi setelah itu, segalanya terlihat seperti sangat melambat. Mereka tidak lagi bekerja keras." Dia memilih Driver Titanium Callaway dan menyuruh caddy untuk mengambil limun dingin ber-es. "Mungkin kalau saya memecat beberapa orang yang lambat, hal itu akan memicu semangat mereka!"

Sementara itu, tentu saja, tim pengembangan tidak menyadari bahwa ada yang salah. Sebenarnya, tidak ada yang salah. Mereka tepat jadwal.

Jangan biarkan hal ini terjadi padamu! Saya akan membocorkan kepadamu sebuah rahasia kecil tentang tipe-tipe manajer non-teknik seperti itu yang akan membuat hidupmu sejuta kali lebih mudah. Sangat sederhana. Sekali engkau tahu rahasiaku, engkau tidak akan pernah mendapat masalah ketika bekerja dengan manajer non-teknik lagi (kecuali engkau terjebak kedalam debat tentang koefisien restitusi dari tongkat golfnya).

Sangat jelas bahwa para programer berpikir dalam satu bahasa, dan para MBA dalam bahasa lain. Saya telah beberapa lama merenungi masalah komunikasi dalam manajemen software, karena sangat jelas bagiku bahwa kekuatan dan imbal balik terkumpul kepada para individu langka yang tahu bagaimana menterjemahkan antara para programer dan pada MBA.

Semenjak saya mulai bekerja di industri software, hampir semua software dimana saya ikut mengerjakannya adalah apa yang mungkin boleh disebut sebagai software "spekulatif". Artinya, software itu tidak dibangun untuk pelanggan tertentu -- dia dibangun dengan harapan bahwa berzillion-zillion orang akan membelinya. Tapi banyak pengembang software yang tidak mempunyai kemewahan seperti itu. Mereka mungkin para konsultan yang mengembangkan sebuah projek untuk satu pelanggan, atau mereka mungkin para programer in-house yang mengerjakan suatu entahapa korporat yang rumit untuk akunting (atau apapun yang kalian, para programer in-house lakukan; hal ini agak misterius bagiku).

Pernahkan engkau menengarai bahwa pada projek-projek kustom tersebut, satu- satunya penyebab paling umum dari keterlambatan, kegagalan, dan kesengsaraan selalu mengarah kepada, pada dasarnya, "kustomer (tambahkan kata-terlarang disini) itu tidak tahu apa yang mereka inginkan?"

Ini adalah tiga versi dari patologi yang sama:

1. "Keinginan kustomer sialan itu selalu berubah. Pertama dia ingin client/server. Lalu dia membaca tentang XML di majalah penerbangan Delta Airlines dan memutuskan bahwa dia harus memakai XML. Sekarang kami menulis ulang sistem ini memakai sepasukan robot kecil Lego Mindstorm."
2. "Kami membangunnya persis seperti yang mereka inginkan. Kontrak memuat seluruhnya sampai ke detil-detil terkecil. Kami memberikan persis seperti yang dinyatakan dalam kontrak. Tapi ketika kami menyajikannya, mereka sangat kecewa."
3. "Orang sales kami yang sangat menyedihkan menyetujui kontrak dengan harga tetap untuk membangun sesuatu yang pada dasarnya tidak dispesifikasikan, dan pengacara kustomer cukup cerdas untuk menyisipkan klausul di dalam kontrak bahwa mereka tidak harus membayar kami sampai 'kustomer setuju untuk menerima', sehingga kami harus membentuk tim dengan sembilan pengembang pada projek mereka selama dua tahun dan hanya dibayar $800."

Bila ada satu hal yang dibutuhkan oleh setiap konsultan junior untuk disuntikkan ke kepala mereka dengan bor kelas berat DeWalt 2500 RPM, itu adalah: Kustomer Tidak Tahu Apa Yang Mereka Inginkan. Berhentilah Berharap Kustomer Untuk Tahu Apa Yang Mereka Inginkan. Hal itu tidak akan mungkin terjadi. Hadapilah kenyataan itu.

Alih-alih, andaikan bahwa engkau bagaimanapun mesti membangun sesuatu, dan kustomer akan harus menyukainya, tetapi mereka akan sedikit terperanjat. ENGKAU harus melakukan riset. ENGKAU harus menemukan suatu disain yang memecahkan masalah yang dimiliki kustomer dengan cara yang memuaskan.

Andaikan engkau duduk di posisi mereka. Bayangkan bahwa engkau baru saja memperoleh $100.000.000 dari penjualan perusahaanmu ke Yahoo!, dan engkau telah memutuskan bahwa sudah saatnya untuk merenovasi dapurmu. Maka engkau menyewa seorang arsitek ahli dengan instruksi untuk membuatnya "sekeren Dapur Will dan Grace". Engkau tidak punya bayangan bagaimana menyelesaikan ini. Engkau tidak tahu bahwa engkau ingin tungku Viking dan pendingin Subzero -- ini bukan kata-kata dalam kamusmu. Engkau ingin si arsitek melakukan sesuatu yang bagus, itulah sebabnya engkau menyewanya.

Orang-orang Extreme Programming bilang bahwa solusi untuk ini adalah dengan mengajak kustomer ke dalam ruangan dan melibatkan mereka dalam proses disain pada setiap langkahnya, sebagai anggota tim pengembang. Hal ini, saya pikir, sedikit terlalu "ekstrim". Hal itu seperti kalau arsitekku memintaku hadir ketika mereka mendisain dapur dan memintaku memberi masukan atas setial detil kecil. Hal itu membosankan bagiku, bila aku ingin menjadi arsitek, saya sudah akan menjadi arsitek.

Bagaimanapun, engkau tidak benar-benar ingin seorang kustomer di dalam timmu bukan? Perwakilan kustomer besar kemungkinan adalah seorang kuper yang memelas dari bagian Account Payable yang dikirim untuk bekerja dengan para pemrogram karena dia adalah pekerja paling lambat disana dan mereka hampir tidak merasakan ketidakhadirannya. Dan engkau akan menghabiskan semua waktu disainmu menjelaskan berbagai hal dalam kata-kata yang terdiri dari satu suku.

Asumsikan bahwa kustomermu tidak tahu apa yang mereka inginkan. Disainlah hal itu oleh dirimu sendiri, berdasarkan pemahamanmu atas domain tersebut. Jika engkau butuh meluangkan waktu untuk belajar tentang domain itu atau seandainya engkau butuh seorang ekspert domain untuk membantumu, itu tidak apa-apa, tapi disain software itu adalah pekerjaanmu. Bila engkau mengerjakan PR domainmu dan membuat suatu UI yang baik, kustomer akan terpuaskan.

Sekarang, saya berjanji untuk menceritakan kepadamu sebuah rahasia tentang menterjemahkan antara bahasa para kustomer (atau para manajer non-teknik) dari softwaremu dan bahasa para pemrogram.

Engkau tahu bahwa gunung es itu 90% di bawah air? Yah, kebanyakan software seperti itu juga -- ada user inteface cantik yang memerlukan 10% kerja, dan 90% pekerjaan pemrograman tersembunyi di baliknya. Dan jika engkau ikut pertimbangkan fakta bahwa separuh dari waktumu dihabiskan untuk memperbaiki bug, UI hanya mendapat porsi 5% dari pekerjaan. Dan bila engkau batasi dirimu pada bagian visual dari UI, piksel-piksel, apa yang akan kau lihat di PowerPoint, kini kita hanya bicara kurang dari 1%.

Itu bukan rahasianya. Rahasianya adalah bahwa Orang Yang Bukan Programmer Tidak Tahu Hal Ini.

Ada beberapa 'corollary' yang sangat, sangat penting atas Rahasia Gunung Es.

Corollary Penting Pertama. Bila engkau menunjukkan ke seorang bukan programmer suatu screen yang memiliki user interface yang 90% lebih jelek, mereka akan berpikir bahwa programnya 90% lebih buruk.

Saya belajar hal ini sebagai seorang konsultan, ketika saya memberikan sebuah demo tentang suatu projek berbasis web besar bagi tim eksekutif klien. Projek itu hampir 100% selesai dikodekan. Kami masih menunggu disainer grafis untuk memilih font-font dan warna-warna dan menggambar tab 3-D yang keren. Sementara itu, kami hanya memakai font-font polos dan hitam putih, ada banyak ruang sisa yang jelek di layar, pada dasarnya itu tidak terlihat bagus sama sekali. Tetapi 100% fungsionalitas ada disana dan menghasilkan beberapa hal yang menakjubkan.

Apa yang terjadi selama demo? Para klien menghabiskan seluruh pertemuan mengeluhkan tentang penampilan grafis layar. Mereka sama sekali tidak bicara tentang UI. Hanya penampilan grafisnya. "Itu sama sekali tidak terlihat bagus," protes projek manager mereka. Hanya itu yang bisa mereka pikirkan. Kami tidak bisa mengajak mereka berpikir tentang fungsionalitas sesungguhnya. Jelas saja memperbaiki disain grafis membutuhkan waktu sekitar satu hari. Itu hampir seperti seolah mereka mengira mereka telah mempekerjakan para tukang cat.

Corollary Penting Kedua. Bila engkau menunjukkan kepada bukan programmer, sebuah tampilan layar dengan user interface yang 100% cantik, mereka akan berpikir bahwa program hampir jadi.

Orang-orang yang bukan programer hanya melihat ke layar dan menyaksikan pixel-pixel. Dan bila pixel-pixel terlihat seperti membentuk sebuah program yang melakukan sesuatu, mereka berpikir "oh, wah, akan seberapa sulit lagi untuk membuat itu benar-benar bekerja?"

Resiko besar disini adalah bilah engkau membuat mock up dari UI terlebih dahulu, dengan anggapan engkau akan bisa menuntun ke percakapan dengan kustomer, maka setiap orang akan berpikiran bahwa engkau sudah hampir selesai. Dan kemudian ketika engkau menghabiskan tahun berikutnya bekerja "dibalik layar", tidak seorangpun yang akan benar-benar melihat apa yang engkau kerjakan dan mereka mengira itu tidak ada.

Corollary Penting Ketiga. Dotcom yang punya situs web yang nampak keren dan terpoles dan sekitar empat halaman web akan memperoleh penilaian lebih tinggi daripada dotcom yang sangat fungsional dengan arsip selama 3700 tahun dan latar belakang bawaan warna kelabu.

Oh, tunggu, dotcom tidak ada harganya lagi. Lupakan saja.

Corollary Penting Keempat. Ketika masalah politik menuntut bahwa berbagai manajer atau kustomer non-teknik untuk "sign off" pada suatu projek, beri mereka beberapa versi disain grafis untuk dipilih.

Bedakan penempatan beberapa hal, ubah "look and feel" dan font, pindahkan logo dan buatlah menjadi lebih besar atau lebih kecil. Biarkan mereka merasa penting dengan memberi mereka lipstik-pada-seekor-ayam yang tidak penting hanya untuk dicoba-coba. Mereka tidak bisa merusak skedulmu disini. Seorang dekorator interior yang bagus terus-menerus membawakan klien mereka swatch dan contoh-contoh dan berbagai hal untuk dipilih. Tapi mereka tidak akan pernah mendiskusikan penempatan pencuci piring dengan klien. Itu akan diletakkan di sebelah bak cuci, tidak peduli apapun yang diinginkan klien. Tidak ada gunanya membuang waktu berdebat tentang dimana pencuci piring diletakkan, itu harus di sebelah bak cuci, jangan sekali-sekali menyinggungnya; biarkan klien menyalurkan naluri disainnya dengan melakukan beberapa hal tak berbahaya seperti mengubah keinginan mereka 200 kali tentang apakah akan memakai Granit Italia atau Tile Mexico atau blok butcher kayu Norwegia untuk bagian atas meja.

Corollary Penting Kelima. Ketika engkau memamerkan, satu-satunya hal yang berarti adalah tampilan layar. Buatlah dia 100% cantik.

Jangan, untuk semenitpun, berpikiran bahwa engkau bisa lolos dengan meminta siapapun untuk membayangkan betapa kerennya ini nanti. Jangan mengira bahwa mereka melihat ke fungsionalitas. Mereka tidak. Mereka ingin melihat pixel-pixel cantik.

Steve Jobs memahami ini. Oh boy betapa dia memang memahami ini. Para insinyur di Appel telah belajar untuk mengerjakan berbagai hal yang bisa membuat tangkapan layar yang hebat, seperti icon-icon baru berukuran 1024x1024 yang sangat indah di dok, walaupun seandainya mereka memakan tempat yang sangat berharga. Dan kerumunan pengguna desktop Linux menjadi gila tentang xterm yang semi transparan, yang membuat tangkapan layar bagus tapi biasanya menjengkelkan ketika dipakai. Setiap kali Gnome atau KDE mengumumkan suatu rilis baru saya langsung menuju ke tangkapan layar dan berkata, "oh, mereka mengganti planetnya dari Jupiter ke Saturnus. Keren." Lupakan apa yang sebenarnya mereka lakukan.

Ingat sang CEO di bagian awal artikel ini? Dia tidak senang karena timnya telah menunjukkan PowerPoint yang hebat di awal -- mockup, dibuat dengan Photoshop, bahkan bukan dengan VB. Dan sekarang mereka benar-benar menyelesaikan berbagai hal di balik layar, terlihat seperti mereka tidak melakukan apapun.

Apa yang bisa engkau lakukan tentang ini? Sekali engkau memahami Rahasia Gunung Es, menjadi mudah bekerja dengannya. Pahamilah bahwa sebarang demo yang engkau sajikan di ruang yang digelapkan dengan projektor akan menjadi semua tentang pixel. Bila engkau bisa, bangunlah UI-mu dalam suatu cara sehingga bagian yang belum beres terlihat belum beres. Misalnya, gunakan coret-coretan untuk icon di toolbar sampai fungsionalitasnya siap. Seraya engkau membangun layanan webmu, engkau mungkin ingin mempertimbangkan untuk tidak memunculkan fitur-fitur di halaman awal sampai fitur-fitur tersebut selesai terbangun. Dengan cara itu orang bisa menyaksikan halaman awal berubah dari 3 perintah menjadi 20 perintah ketika lebih banyak hal terbangun.

Lebih penting lagi, pastikan bahwa engkau mengendalikan apa yang orang pikir tentang skedul. Sediakan sebuah skedul detil dalam format Excel. Setiap minggu, kirimkan email yang menyelamati diri sendiri yang berbicara tentang bagaimana engkau telah bergerak dari 32% komplit ke 35% komplit dan pada jalurnya untuk mengirimkan pada tanggal 25 Desember. Pastikan bahwa fakta aktual mendominasi sebarang pemikiran tentang apakah projek bergerak maju pada kecepatan yang tepat. Dan jangan biarkan bossmu memakai Driver Titanium Callaway, saya tidak peduli seberapa besar keinginanmu agar dia menang, USGA telah melarang itu dan itu memang tidak fair.