Digerakkan oleh Tujuan

Jika seorang ibu membuat nasi goreng untuk sarapan pagi, apakah setelah selesai, nasi goreng yang sudah jadi tersebut dibiarkan saja di wajan untuk kemudian menjadi dingin, dihinggapi lalat dan dikerubuti semut? Tentu sang ibu akan menyajikan nasi goreng tersebut di meja makan untuk disantap keluarganya. Ibu tersebut tidak membuat nasi goreng tanpa tujuan, tapi justru diawali oleh suatu tujuan, yakni memberikan makanan yang enak dan bergizi untuk keluarganya sebagai bekal awal melakukan berbagai aktivitas di sepanjang hari.

Seorang pencipta lagu tidak menciptakan lagu untuk kemudian hanya didengungkan dan didengar sendiri. Seorang pelukis tidak membuat lukisan untuk kemudian dipajang di dinding kamarnya sendiri. Lagu dan lukisan tersebut pasti diciptakan untuk suatu tujuan, mungkin untuk mengekspresikan suatu perasaan, atau menggambarkan suasana dan keindahan alam di suatu tempat. Perasaan dan keindahan yang kemudian dibagikan kepada orang lain.

Dalam perencanaan strategis, setiap organisasi harus memiliki visi dan misi. Visi dan misi tersebut diterjemahkan dalam bentuk strategi. Strategi kemudian diimplementasikan dalam bentuk rencana aksi.

Kalau kita bicara mengenai strategi TI, maka pasti diawali dengan strategi bisnis. Strategi bisnis diterjemahkan dalam bentuk strategi sistem informasi (proses dan prosedur). Strategi sistem informasi ini kemudian diimplementasikan dalam bentuk strategi teknologi informasi (perangkat lunak, perangkat keras, dan jaringan).

Setiap rencana aksi adalah buah dari strategi, dan berakar pada visi dan misi. Setiap penerapan teknologi informasi pada suatu organisasi, haruslah merupakan buah dari strategi sistem informasi, dan berakar pada strategi bisnis dari organisasi tersebut.

Seperti yang dipaparkan oleh Rick Warren pada video di atas, semua yang kita lakukan dan kerjakan dalam hidup ini seharusnya punya alasan dan tujuan filosofis yang benar. Bagaimana kita melakukan suatu pekerjaan, sebenarnya adalah buah dari apa yang kita kerjakan, dan berakar pada mengapa kita mengerjakannya. 

Dalam membangun suatu sistem teknologi informasi, kita tentu harus memikirkan BAGAIMANA cara kita membangun sistem tersebut. Kita juga harus memastikan APA sebenarnya yang sedang kita bangun. Namun demikan, satu pertanyaan maha penting yang tidak boleh kita lupakan adalah MENGAPA kita membangun sistem tersebut. Apa sebenarnya maksud dan tujuan dari sistem ini. Apa manfaat yang akan diperoleh seorang pengguna, suatu divisi, atau sebuah perusahaan, setelah menggunakan sistem ini.  Dengan berusaha memetakan setiap komponen dalam sistem dengan maksud dan tujuan sebenarnya dari sistem tersebut, kita sebenarnya sedang memberikan “nyawa” kepada sistem yang kita bangun, sehingga pada akhirnya tidak hanya menjadi objek yang canggih namun mati, tetapi memiliki “kehidupan” yang efektif untuk memberi manfaat bagi setiap orang yang menggunakannya.

Membuat Kesalahan yang Lebih Benar

Pada video di atas, seorang ekonom bernama Tim Harford mengatakan bahwa kita manusia seringkali berpikir diri kita adalah Tuhan, dalam arti menganggap bahwa kita tidak bisa salah. Dalam film Malice, seorang dokter yang diperankan oleh Alec Baldwin digambarkan sedemikian angkuhnya sehingga dokter tersebut mengatakan bahwa, jika dia sedang melakukan operasi untuk menyelamatkan nyawa seorang pasien yang sedang sekarat, maka ketika keluarga si pasien menunggu sambil berharap dan berdoa, sebenarnya yang sedang diharapkan bukanlah Tuhan, tapi dirinya sebagai dokter yang memiliki kemampuan untuk menyelamatkan orang yang sedang sekarat tersebut.

Dalam pembangunan sistem, mungkin tanpa disadari kita seringkali juga berperilaku angkuh seperti itu. Kita berpikir analisa kebutuhan kita sudah yang paling benar dan tidak mungkin meleset. Kita menganggap solusi yang kita rancang sudah yang paling sempurna dan tidak mungkin keliru. Apa yang tertulis dalam dokumen analisis kebutuhan dan dokumen rancangan kita anggap sebagai hukum Tuhan yang tidak boleh diganggu gugat. Kesalahan kita anggap sebagai kelemahan. Perubahan kita anggap sebagai dosa.

Jika konstitusi negara saja bisa di-amandemen, bagaimana kita bisa dengan angkuh mengatakan hasil analisis dan perancangan sistem sebagai dokumen keramat yang tidak boleh dikoreksi dan diperbaharui? Jika proyek Apollo yang dikerjakan oleh ribuan ilmuwan dan teknisi jenius saja harus melalui berbagai tahapan “trial and error” untuk kemudian mencapai tujuannya mendaratkan manusia di bulan pada Apollo 11 (bukan Apollo 1),  bagaimana kita bisa dengan yakin menganggap satu siklus pembangunan sistem sudah cukup untuk membuat sistem yang sempurna?

Daripada memiliki pola pikir “sekali tembak” yang menolak kesalahan dan menghindari perubahan, kita sebaiknya memulai pendekatan evolusioner yang justru bercirikan kesalahan-kesalahan yang terus dikoreksi dan perubahan gradual untuk menjadi lebih baik. Ada 2 karakteristik dalam pendekatan ini, yakni iteratif dan inkremental. Iteratif berarti pembangunan sistem harus dilakukan dalam sejumlah siklus yang berulang. Dalam sebuah proyek 6 bulan, daripada 1 bulan dihabiskan untuk analisis dan desain, 4 bulan untuk membangun, dan 1 bulan untuk pengujian dan implementasi, akan lebih baik bila dibagi dalam 3 “mini-proyek” yang masing-masing terdiri dari 2 minggu analisis dan desain, 4 minggu membangun, dan 2 minggu untuk pengujian dan implementasi. Setiap iterasi menghasilkan produk siap pakai yang sudah dapat dicoba oleh pengguna. Inkremental, berarti setiap iterasi harus memberikan hasil akhir yang lebih baik.  Kita tidak melakukan hal yang sama dan berputar-putar sebanyak 3 kali. Pada setiap iterasi harus ada persepsi yang diluruskan, kesalahan yang dikoreksi, proses yang diperbaiki, dan produk yang disempurnakan.

Orang Tidak Tahu Apa yang Mereka Inginkan

Salah satu contoh yang dipaparkan penulis Malcolm Gladwell pada video di atas kira-kita seperti ini: jika orang ditanya saus spageti seperti apa yang dia paling sukai, orang hanya menyebutkan jenis saus yang dia ketahui. Anggaplah dari saus tipe A, B, dan C, dia menyebutkan tipe A. Tapi setelah orang tersebut diberikan beberapa jenis saus spageti untuk dicoba, termasuk jenis2 yang tidak dia ketahui sebelumnya (misalkan selain tipe A, B, dan C, juga diberikan tipe D, E, dan F) barulah ditemukan bahwa ternyata orang itu sangat menyukai saus tipe F.

Demikian juga pada proyek pengembangan sistem, pernahkah kita menemukan pernyataan-pernyataan kebutuhan baik dalam bentuk lisan maupun tulisan, yang ternyata sama persis dengan apa yang sebenarnya diinginkan? Sesuai perjalanan waktu, setelah sistem tersebut sedikit demi sedikit dibangun, seringkali terjadi atau mungkin dapat dipastikan muncul hal-hal yang sebelumnya tidak terpikirkan. Kita bisa menanyakan sebanyak mungkin pertanyaan kepada pengguna, dan membuat dokumen analisis kebutuhan yang sangat terperinci dan lengkap, untuk kemudian menemukan bahwa apa yang kita tulis dalam dokumen tersebut ternyata tidak sesuai dengan keinginan dan kebutuhan pengguna yang sebenarnya.

Lalu, apa yang bisa kita lakukan agar apa yang kita bangun bisa semendekati mungkin dengan apa yang dibutuhkan? Rahasianya sebenarnya terletak pada hal sederhana yang mungkin seringkali kita anggap remeh, yakni komunikasi. Bangun relasi yang erat dengan pengguna. Jangan sebut pengguna dengan kata “mereka”, tetapi jadikan pengguna sebagai bagian dari tim. Bagian dari “kita”.

Kemudian yang perlu diperhatikan adalah bagaimana cara kita berkomunikasi. Kata-kata tidaklah cukup. Pernyataan lisan bahkan tulisan seringkali tidak mampu mengekspresikan secara lengkap apa yang ada di benak pengguna, sehingga memungkinkan terjadinya salah persepsi. Sebuah gambar bermakna ribuan kata. Gambarlah diagram atau model, yang berfungsi sebagai cetak biru dari sistem yang akan kita bangun. Setelah itu, buatlah prototype. Jika kita hendak membangun gedung, setelah kita membuat rancangan arsitektur dalam bentuk cetak biru, apa yang kita lakukan sebelum membangun gedung yang sebenarnya? Kita membuat maket gedung tersebut. Demikian juga jika kita ingin membangun mobil, kapal laut atau pesawat terbang, kita tentu membuat model/prototype-nya terlebih dahulu. 

Pembuatan prototype adalah suatu keharusan dalam dunia rekayasa/engineering. Jika untuk membuat objek yang kelihatan saja kita perlu membuat cetak biru dan prototype, apalagi untuk membangun sistem yang tidak kelihatan.

Melihat yang Tidak Terlihat

Semakin lama kita berkecimpung dalam bidang pembangunan sistem teknologi informasi, semakin banyak kita belajar bahwa keberhasilan dari apa yang kita lakukan seringkali terletak pada hal-hal yang tidak kelihatan ketimbang hal-hal yang kelihatan. Mungkin dulu kita menilai keberhasilan pengembangan sistem lebih pada parameter-parameter teknis seperti kecepatan respons, jumlah bug, dan tingkat keamanan. Parameter-parameter ini tentu penting, tapi berapa sering kita menemui sistem yang terbukti cepat, bebas dari bug, dan aman, namun ternyata tidak dapat memberi manfaat yang optimal terhadap penggunanya. Canggih, namun tidak efektif.

Kalau kita meningkat ke level proyek, parameter keberhasilan yang umum dijadikan acuan adalah tepat waktu, tepat biaya dan tepat cakupan. Tetapi tidak jarang kita mendengar proyek-proyek yang berdasarkan ketiga parameter tersebut tampaknya berhasil, tapi ternyata tidak. Bisa jadi proyek tersebut tepat waktu, tapi ternyata ketepatan waktu tersebut diperoleh dengan cara menutup mata dan telinga terhadap masukan dan kritik dari pengguna. Tepat waktu, tapi pengguna kesal karena tidak merasa dilibatkan. Akibatnya terjadi reaksi penolakan dalam wujud keengganan untuk menggunakan sistem yang sudah dibangun tersebut. Atau bisa jadi proyek tepat dari sisi biaya, tetapi diperoleh dengan cara murahan dan mengorbankan kualitas. Sekilas sistem bekerja dengan normal, hingga sampai pada suatu waktu dan kondisi dimana kelemahan-kelemahannya muncul di permukaan dan mengakibatkan masalah. Bisa jadi juga seolah-olah tepat dari sisi cakupan, tepat sesuai dengan yang diinginkan pengguna dalam dokumen kebutuhan, hingga kemudian pada saat sistem pertama kali digunakan, diketahui bahwa isi dokumen kebutuhan yang dibuat 3 bulan, 6 bulan atau 1 tahun yang lalu terrnyata sudah tidak sesuai dengan kebutuhan pengguna 3 bulan, 6 bulan atau 1 tahun kemudian.

Mengapa hal ini bisa terjadi? Mari kita coba belajar dari beberapa ide dan pemikiran yang dipaparkan dalam sejumlah presentasi dari konferensi TED. Konferensi TED (Technology, Entertainment and Design) adalah suatu acara dimana orang dapat mempresentasikan gagasannya dalam berbagai bidang, entah itu sosial, ilmu pengetahuan, ekonomi, teknologi, dsb. Konferensi ini pertama kali diselenggarakan tahun 1990 di Monterey, California. Versi lokalnya sudah diselenggarakan di banyak negara termasuk Indonesia. 

Mari kita simak 3 presentasi oleh 3 orang pembicara yang berbeda yang dapat kita jadikan pelajaran untuk melakukan pengembangan sistem yang lebih baik.

Pelajaran 1: Orang tidak tahu apa yang mereka inginkan

Pelajaran 2: Membuat kesalahan yang lebih benar

Pelajaran 3: Digerakkan oleh tujuan