The Art of Getting It Done

Judul kemiggris, tapi bahasanya Indonesia ajalah.

Posting ini tercetus gara-gara post di reddit As someone who doesn’t write code, I think the idea of “Done is better than perfect” is wrong. Sebagai programmer respon pertama adalah bagian pertama sudah menjelaskan semuanya, dia bukan programmer maka tidak akan paham lah. Tapi mari kita elaborasi kenapa “Done is better than perfect”. Poin-poin di bawah berasal dari prinsip pemrograman yang aku pelajari, tapi nampaknya prinsip ini dampaknya luas.

1. Kita tidak tahu sempurna itu seperti apa.

Saat kita membuat program, kita punya visi bahwa program kita akan melakukan A, B atau C, bahkan seringkali kita punya spesifikasi kebutuhan dari user program kita. Jika proses pengembangan aplikasi menggunakan sistem Waterfall, saat kita mulai menulis koding, kita punya visi yang sempurna apa saja yang kudu dipenuhi program kita. Sempurna bukan?

Tapi kenyataan berkata lain. Visi user dan visi programmer bisa saja berbeda, kata-kata di dokumen bisa saja diinterpretasikan lain, bahkan yang paling menyebalkan, seringkali user tidak tahu apa yang mereka mau atau kebutuhan mereka sangat mahal untuk dipenuhi(mahal secara waktu pengembangan atau susah membuat fitur tersebut tapi manfaatnya kecil).

Intinya sih, user berbohong soal apa yang dia inginkan sehingga susah untuk memenuhi keinginan mereka.

2. Pareto principle, 20% fitur menghasilkan 80% manfaat.

Pertanyaannya 20% yang mana? Satu-satunya cara untuk mengetahui hal ini adalah dengan bereksperimen, mengirim aplikasi ke user dan meminta feedback. Hal ini sangat berguna jika aplikasi yang dikembangkan sangat kompleks dan programmer tidak paham soal domain masalahnya, kadangkala hal ini juga dilakukan dengan memangkas fitur yang tidak dipakai.

Salah satu aplikasi yang pernah aku kembangkan adalah soal pemrosesan invoice secara otomatis. Di awal development ada banyak fitur dan requirement yang diajukan. Setelah develop dan melihat aplikasiya berjalan beberapa lama, aku menemukan bahwa banyak fitur yang diminta di awal jarang atau tidak pernah dipakai, dan fitur-fitur tidak pentung itu membuat user interface susah untuk dipahami. Setelah memotong banyak fitur dan menyederhanakan aplikasi user puas dengan hasilnya.

User memang jadi lebih susah melakukan beberapa hal seperti merollback transaksi yang sudah terjadi(kudu minta bantuan support dan spesialis SAP), tapi dia bisa dengan lebih sederhana memproses transaksi yang normal. Jika 99% proses yang terjadi adalag proses normal dan hanya ada 1-2 yang bermasalah, maka pemotongan fitur adalah solusi yang optimal.

Google juga mendisain fiturnya dengan prinsip ini, dia tahu semua orang yang mengakses google.com ingin mencari sesuatu, maka dia memotong semua fitur yang tidak berhubungan dengan pencarian sehingga tampilannya minimalis. Hal ini membuat kita sedikit susah dalam mengubah setting pencarian misalnya, tapi membuat kita mencari sesuatu lebih cepat.

3. Kebutuhan akan terus bertambah dan berubah, aplikasi berevolusi untuk mengikutinya.

Salah satu bukti bahwa aplikasi kita digunakan adalah banyak yang komplain atau meminta tambahan fitur. Sebagai contoh aplikasi yang berubah, setahun yang lalu siapa bisa membayangkan Facebook akan seperti sekarang(dalam hal fitur). Semua perubahan itu adalah respon atas kebutuhan user, kebutuhan advertiser, kebutuhan regulasi atau kompetisi. Tidak ada yang menduga bahwa Google akhirnya meluncurkan Google Plus dengan fitur circlenya, dan Facebook merespon dengan mengimplementasi pengelompokan teman dengan caranya sendiri.

4. User pasti komplain, mari kita beri alasannya.

Kita sudah tahu bahwa membuat aplikasi yang bug-free dan memuaskan semua user itu mustahil. Jadi, daripada kita mengirim aplikasi yang sempurna dan toh dicela juga, maka berilah aplikasi yang tidak sempurna agar user bisa mengeluh dengan lebih terarah.

5. User menginginkannya SEKARANG.

Menunggu sesuatu untuk sempurna sebelum dirilis akan membuat usermu bosan menunggu dan beralih ke kompetitor. Maka rilislah sekarang. Feedback dan respon dari user akan menghasilkan momentum ke depan karena kita tahu apa yang harus diperbaiki. Sementara menunda rilis aplikasi sehingga sempurna menghilangkan kesempatan itu dan membawa kita ke jebakan prokrastinasi.

6. Harga kegagalan sesuatu yang sempurna itu mahal.

Prototype yang gagal lebih murah dari full product yang gagal. Kita bisa belajar banyak dari Google. Mereka banyak merilis produk setengah jadi macam Google Plus, Google Wave atau Google Buzz. Mereka dengan cepat menambahkan fitur atau menutup bug aplikasi mereka. Tidak ada yang tahu seperti apakah Google Plus nantinya atau akankah dia berhasil. Tapi Google memilih untuk selalu merilis tanpa takut gagal dan belajar dari kegagalan untuk terus berevolusi.

Mereka tidak menunggu Google Plus sempurna baru dirilis, kalau sudah siap ya dirilis saja.

Tapi bedakan dengan merilis produk setengah jadi, produk setengah jadi punya fitur penting yang hilang atau bug fatal sehingga user tidak bisa menggunakannya. Produk setengah jadi menandakan kamu nggak serius dengan produkmu dan jaminan gagal.