Melakukan Yang Kecil, Dapat Yang Besar

      Comments Off on Melakukan Yang Kecil, Dapat Yang Besar

Kok mirip falsafahnya orang ekonomi ya? Carilah pengorbanan minimal yang dapat memberikan hasil terbesar! Tapi saya sedang ingin mengambil hal yang positif dari prinsip itu, setidaknya dari ukuran saya. Tentu saja anda tidak harus setuju, karena ini hanya refleksi pengalaman saja.

Inti dari yang saya maksud adalah, bahwa kadang-kadang “strategi dan pertimbangan efektifitas” perlu diletakkan di atas kepuasan technical.
Alkisah, satu waktu bersama beberapa programmer lain, saya harus membangun satu sistem informasi di salah satu unit bisnis perusahaan kami. Seperti biasa, pertempuranpun segera dimulai. User requirement mulai dipresentasikan, design-design mulai dibuat. Sambil diselingi beberapa pertemuan dan presentasi, akhirnya design selesai. Tibalah saat yang menggairahkan itu: programming! Dan segera saja setelah itu ruangan menjadi “hidup”, ada perdebatan kecil antara programmer dengan database designer, ada programmer yang berteriak kegirangan karena berhasil memecahkan coding untuk formula yang cukup rumit, satu orang lagi ngeprint source code berlembar-lembar karena penasaran mencari bugs dari logic error yang sudah beberapa hari nggak ketemu. Beberapa tempat sampah, penuh dengan asap rokok yang bau coding. Dan biarpun beberapa standar telah dibuat dan disepakati, tetap saja yang namanya programmer selalu pengin beda dan nampak lebih baik. Tentu saja ini adalah hal positif jika diarahkan dengan benar, dan bisa juga sebaliknya.

Dan tibalah saat test, alpha test dan beta test, setelah beberapa kali penyempurnaan, akhirnya UAT ditandatangani dan go to the implementation. Running well satu bulan dan sip, pekerjaan selesai (bisa cuti nih..).

Tak terasa, setelah mencoba menghitung sejak kick off, hampir setahun proyek ini dikerjakan! Ketika implementasi berjalan hampir setahun kemudian, datanglah musibah itu. Di unit bisnis itu ada beberapa perubahan. Perubahan orientasi bisnis, perubahan organisasi, dan perubahan operasional kerja. Waduh, membangun satu tahun untuk sebuah pemakaian yang juga satu tahun! Dan mulailah kita mengevaluasi, siapa yang salah: System Analyst, Business Analyst, atau Project Owner! Dan petaka makin bertambah ketika sang BA (yang sebenarnya ngepos di divisi user) ternyata 2 bulan sebelumnya telah pindah di perusahaan lain.

Well, apes dan mengerikan. Semoga tak menimpa kawan lain.
Memang ada hal-hal lain yang tak kalah penting dari aspek technical. Feasibility study, business analysis adalah hal awal yang mesti yakin duluan.

Sementara itu, dalam kisah pengalaman yang lain, ada pekerjaan yang amat kecil, tidak nge-IT tapi berjalan sebaliknya. Implementasi fasilitas teleconference!. Wah ini sih kerjaan sampingan. Mulailah lihat sana-sini, undang vendor, test dan pilih yang bagus sekaligus murah. Beres tidak sampai satu bulan sudah oke. Pertemuan rutin sudah tidak perlu ngumpul di Jakarta lagi. Semua cukup dengan video conference. What’s the result? Orang-orang mulai berhitung tentang efisiensi. Sekian rupiah ternyata telah berhasil direduksi: transportation cost, accomodation cost dan waktu! Lalu, beberapa mulai bilang, hebat juga IT kita ya!
Ha-ha-ha. Kerjaan IT? Apa yang telah kita lakukan? Hanya mengundang beberapa vendor, merekomendasikan, menyediakan bandwith VSAT yang lebih gede dan, hanya itu.

Jadi saran saya, judul di atas tidak usah diikuti! Anggap saja itu nasib saya, cukup. Biarpun user tidak pernah mengerti, tapi tetap membanggakan ketika kita bisa bikin code 10 baris sementara orang lain perlu 50 baris untuk hal yang sama. Biarpun user tidak tahu, tetap membanggakan ketika kita berhasil mengintegrasikan beberapa komponen sulit dalam aplikasi kita sementara orang lain tekniknya biasa-biasa saja. Dan lakukan juga sejumlah kebanggaan yang lain, sebab ini dunia kita. Tapi jika anda mau juga sedikit menerima, pertimbangkan pula efektifitas. Jika yang mudah sudah cukup bagi user, ya sudahlah. Lakukan hal yang sulit itu di lab, dan tunjukkan ke komunitas yang sesuai dan memang sesekali kita perlu pibu dalam programming. Tapi tentu saja saya tidak bisa memberi saran untuk anda yang berprinsip, “jika bisa sulit, ngapain digampangkan?”