Salah Beli Software

Perusahaan tempat saya bekerja, saat ini sedang kebingungan dengan masalah software yang digunakan untuk mengelola database keuangan dan nasabah/debitur. Maklumlah memang sebelumnya semua data dicatat/direcord dan diolah secara manual dengan menggunakan spreadsheet, jadi penggunaan software khusus untuk pengolahan database mungkin agak sedikit membingungkan bagi rekan-rekan dan karyawan di perusahaan. Biasa, masa transisi memang sulit apalagi sampai harus mengubah kebiasaan yang sudah me-nahun.

Permasalahan yang terjadi tidak hanya sampai disitu, masalah makin diperparah dengan adanya ketidaksesuaian antara kompatibilitas dan fitur dari software yang telah dibeli dengan harga jutaan rupiah dengan keinginan dari pihak manajemen perusahaan. Fitur yang disediakan oleh software tersebut dinilai tidak mendukung atau tidak sesuai dengan sistem kerja yang diterapkan perusahaan, bahkan format laporan yang disajikan pun juga berbeda, ditambah lagi dengan ketidakmudahan pengoperasian software dari sisi operator, yang cenderung mengakibatkan kesalahan dalam penginputan data atau mungkin istilah keren-nya user interface yang tidak friendly, mengakibatkan keengganan dari pihak operator dalam proses menginput data, sehingga berujung pada software yang tidak terpakai dan pihak manajemen perusahaan merasa dirugikan untuk pembelian software yang sia-sia.

Sebenarnya hal tersebut diatas bisa saja dihindari, jika saja terjadi komunikasi dan pengertian antara pihak customer dan developer tentang cara kerja sistem perusahaan dan software yang seperti apa yang diinginkan dari pihak customer. Bahkan kalau perlu bisa melibatkan pihak ketiga sebagai seorang konsultan, yang menjembatani antara customer dan developer.

Mungkin artikel yang ditulis oleh Sdr. Joko Nurjadi, yang saya dapatkan dari majalah PCMedia edisi bulan ini, banyak membantu dalam memahami permasalahan diatas. Sebelumnya saya minta maaf kepada Sdr. Joko Nurjadi karena saya menyadur tulisan beliau tanpa ijin dan kedua saya juga ucapkan banyak terima kasih, karena tulisan beliau banyak membantu pemahaman saya tentang software development. Terima Kasih. Berikut saduran tulisan tersebut, semoga bermanfaat.

CATATAN HITAM SOFTWARE DEVELOPMENT

Dengan berbekal Internet berkecepatan tinggi, mungkin dalam satu hari Anda dapat men-download puluhan software. Lalu, untuk apa membuat software??

Dunia software memang cukup ironis. Disatu sisi banyak terdapat pilihan software-software jadi yang dapat diperoleh dengan gratis maupun bayar (ataupun seharusnya bayar, tetapi di-crack!), tetapi di sisi lain tidak mudah mendapatkan software yang sesuai keinginan sehingga software perlu dipesan dan dibuat khusus.

Dalam hal ini, programer/developer mirip dengan penjahit yang membuat pakaian secara khusus, tugas system analyst dan database administrator dapat diibaratkan dengan desainer pakaian yang merancangnya terlebih dahulu.

Hanya saja, tidak semua software development berjalan dengan mulus. Software terhenti di tengah jalan, dirombak ulang, selesai tapi tidak memuaskan, merupakan cerita-cerita hitam yang bukan jarang-jarang terjadi. Sementara waktu dan materi telah banyak dikorbankan untuk itu.

Hubungi Developer!
Pak Kumis membuka sebuah toko sederhana, saat pelanggan semakin banyak dan penjualan meningkat, Pak Kumis mulai berpikir untuk membuat dan menerapkan sistem komputerisasi untuk mengembangkan bisnisnya.

Jalan pertama yang ingin diambil oleh Pak Kumis tentu jalan yang termurah dan termudah (kalau ada mengapa tidak), Pak Kumis mendengar di Internet banyak terdapat software yang dapat diperoleh dengan cuma-cuma. Maka, dalam waktu relatif singkat Pak Kumis telah mengumpulkan cukup banyak software yang berhasil di-download.

Pak Kumis kemudian mencoba software tersebut satu demi satu, ada yang tidak sesuai dengan keinginan Pak Kumis kerena terlalu kompleks, sebaliknya ada juga yang terlalu sederhana, ada yang berbahasa asing dan tidak dimengerti, ada yang membuat komputer Pak Kumis hang, dan seterusnya sampai akhirnya tidak ada satupun software yang sesuai.

Akhirnya, Pak Kumis memutuskan untuk menyewa seorang programer/developer yang dapat mewujudkan sistem yang diidamkan oleh Pak Kumis, setelah melalui negoisasi harga yang cukup ketat, maka dimulai pembuatan software kustomisasi atau sering juga disebut tailor made.

Tersedia cukup banyak skenario yang mungkin terjadi menyusul kesepakatan antara Pak Kumis dan pihak developer. Tetapi, hanya ada dua pilihan akhir yang munkin terjadi, happy ending atau sad ending.

Happy ending kalau software buatan sang developer sesuai dengan keinginan Pak Kumis, sad ending kalau software tersebut tidak pernah sesuai dengan keinginan Pak Kumis. Pada artikel ini, kita akan fokus pada pembahasan sad ending, bukan untuk menceritakan hal-hal yang memprihatinkan, tetapi bagaimana untuk belajar dan menghindari hal tersebut.

Menebak Wajah Software
Pakaian dapat digambar sebelum dibuat sehingga customer dapat membayangkan hasil akhirnya. Sbuah rumah juga dapat dibuat cetak birunya sehingga customer dapat me-reka strukturnya, tetapi membayangkan wajah software yang belum ada kadang hampir sama sulitnya dengan membayangkan wajah bayi yang belum dilahirkan.

Tentunya, desain software dapat dibuat agar mampu memberikan gambaran bagaimana wujud software tersebut. Bahkan beberapa customer dapat membuat user requirement sedemikian rupa, lengkap dengan desain tampilan dan alur yang sangat jelas.

Tetapi, sebagian customer tidak memiliki bayangan sedikit pun bagaimana mengimplementasikan sistem manualnya ke dalam sistem komputer. Bahkan mungkin tidak juga sepenuhnya memahami desain software yang dibuat oleh system analyst.

Kejadian seperti ini dapat terjadi bahkan dalam ruang lingkup sistem yang relatif kecil, dan kita tidak dapat menyalahkan salah satu pihak, jika software yang ingin dibangun gagal untuk didesain lebih dahulu, yang jelas merupakan sebuah kesalahan besar untuk memaksakan membuat software yang belum diketahui dengan jelas desain sistemnya.

Menyamakan persepsi akan sistem yang akan dibangun merupakan suatu proses yang relatif dapat berlangsung cukup lama, dikarenakan pihak customer dan developer harus berkolaborasi menyusun sistem tersebut.

Dari sisi developer, tentunya sudah memiliki background pengetahuan tahap-tahap pengembangan software, bagaimana siklus hidup software dan seterusnya. Sedangkan dari sisi customer, memiliki pengetahuan mengenai proses bisnis yang digelutinya.

Mempertemukan dua hal ini merupakan awal yang sangat menentukan untuk melahirkan sotware yang sesuai. Tetapi, untuk menyatukannya tidak semudah membalikkan telapak tangan, bisa diakibatkan karena background yang berbeda serta tingkat komunikasi yang kurang baik.

Komunikasi merupakan bagian penting agar sebuah kerja sama dapat berjalan dengan baik, skill teknikal yang luar biasa tidak menjamin developer selalu mampu menghasilkan software yang dibutuhkan. Sebaliknya juga komunikasi yang baik jika tidak didukung dengan teknikal yang memadai, tidak akan menghasilkan produk yang memuaskan.

Untuk bersama-sama menghasilkan gambaran software yang akan di-develop, ada kalanya diperlukan pihak konsultan teknologi informasi (IT Consultant) untuk menjembatani antara customer dan developer. Konsultan tersebut harus memahami proses bisnis customer dan mampu menyarankan solusi TI yang perlu dikembangkan oleh developer.

Developer atau Konsultan?
Sering terdapat kerancuan antara tugas developer dan konsultan. Beberapa customer memiliki anggapan bahwa pihak developer harus bertugas dan berlaku sebagai konsultan bisnisnya, selain tentunya membuat program.

Hal ini kadang kala berbuntut dengan kerugian bagi kedua belah pihak. Hal pertama karena pihak developer seharusnya tidak merangkap sebagai IT Consultant tanpa kesepakatan yang jelas, hal kedua karena pihak developer belum tentu memahami sudut pandang customer dri sisi bisnis dan kebutuhan.

Karena itu jika pihak developer merangkap sebagai konsultan, maka pihak developer harus memiliki kapasitas sebagai konsultan dan perlu dipahami oleh customer bahwa proses konsultasi dan proses development merupakan dua proses dan tanggung jawab yang terpisah.

Pihak konsultan juga dapat merupakan pihak ketiga yang disewa oleh customer untuk membantu mengembangkan bisnisnya. Solusi yang ditawarkan tidak selalu merupakan pengembangan software, tetapi juga dapat berupa perbaikan infrastruktur, penggunaan teknologi tertentu, peningkatan keamanan sistem dan seterusnya.

Metodologi
Sebuah metologi pengembangan sistem software dapat dijadikan sebagai patokan developer untuk melakukan tahap-tahap pembuatan software. Metodologi yang umum dikenal adalah System Development Life Cycle (biasa disingkat DSLC atau SLC) yang didefinisikan US Department of Justice.

SDLC menjelaskan tahapan pembuatan software, diantaranya adalah perencanaan, analisis, desain, development, testing, deployment, implementasi dan maintenance. Idealnya SDLC diharapkan menghasilkan sistem berkualitas yang memenuhi (atau kalau perlu melebihi) harapan customer dan sesuai dengan estimasi biaya dan waktu.

Sebuah metodologi lainnya adalah Extreme Programming atau disingkat XP di http://www.extremeprogramming.org, yang membagi tahapan ke dalam empat bagian besar, yaitu Planning, Designing, Coding dan Testing.

XP menekankan peran customer sebagai bagian dari keberhasilan sistem. Tentunya bukan bertugas sebagai developer, tetapi untuk berperan serta menuliskan skenario (User Stories) tanpa harus menggunakan istilah teknis. User stories ini nantinya akan mengarah pada User Acceptance Test (UAT).

Bagaimanapun, SDLC dan metodologi lainnya hanya merupakan sebuah alat bantu untuk mengarahkan pengembangan sistem yang lebih baik. Di dalam perjalanan pengembangan software tersebut, sering kali terdapat berbagai kendala, terutama didalam sistem yang besar dan terbagi-bagi atas beragam subsistem.

Software Tambal Sulam
Berikut ini adalah cerita yang cukup umum terjadi. Seorang developer datang ke kantor customer dan melakukan entah instalasi, perbaikan bug, ataupun maintenance rutin.

Customer kemudian meminta developer untuk menambahkan suatu modul ringan, developer yang kebetulan memiliki source code software tersebut kemudian mendemontrasikan kepiawaiannya dengan membuat modul tersebut hanya dalam hitungan menit.

Kadang kala untuk membuat modul ringan tersebut, developer mengambil jalan pintas yang termudah, dengan tujuan utama adalah menghasilkan modul yang diminta dengan cepat, tanpa harus banyak mengubah kode program.

Tetapi, sangat disayangkan jika untuk mencapai hal tersebut, developer mengabaikan konsep dan prinsip software development yang seharusnya diketahuinya.

Praktik seperti ini, baik dalam skala kecil maupun besar akhirnya dapat merugikan developer maupun customer. Pihak customer harus memiliki pengertian bahwa perubahan modul kecil pada sistem seringkali bukanlah sebuah pekerjaan kecil, dan pihak developer harus tetap berpegang pada desain sistem yang benar.

Jangan ragu-ragu untuk kembali pada metodologi awal yang digunakan. Sebuah requirement baru biasanya akan melahirkan perencanaan yang baru, dan bisa jadi mengubah estimasi waktu dan biaya awal.

Perubahan Spesifikasi
Cukup umum terjadi, desain yang telah dirancang pada awalnya kemudian harus diubah karena berbagai sebab. Bisa jadi karena terdapat kasus-kasus yang tidak terpikirkan sebelumnya, ataupun dikarenakan perubahan kebijaksanaan yang dilakukan customer terhadap proses bisnisnya dan seterusnya.

Saat hal ini terjadi, komunikasi yang baik akan memegang peranan yang sangat penting. Karena seringkali customer dan developer sama-sama merasa rugi dan tidak mau disalahkan atas terjadinya perubahan spesifikasi sistem.

Karena itu, jauh sebelum pihak customer dan developer mencapai kata sepakat, sebelumnya perlu dipahami bahwa iterasi atau pengulangan merupakan hal yang sangat wajar pada pengembangan software. Termasuk pengulangan requirement, perencanaan dan bisa jadi mempengaruhi estimasi biaya dan waktu.

Jika salah satu pihak tidak siap dengan hal tersebut, maka pihak tersebut juga belum siap untuk melahirkan sebuah sistem.

Implementasi
Saat software telah mencapai tahap akhir development dan akan masuk pada tahap production, jangan buru-buru membuat setup installer software yang rapi karena bisa jadi masih akan terjadi cukup banyak perubahan saat dipergunakan end user.

Karena itu, perencanaan sistem yang baik tentunya telah memperhitungkan level pengguna, dari pihak customer juga harus mampu memberikan deskripsi detail kebutuhan-kebutuhan user.

Jika end user merupakan staf perusahaan yang harus mengoperasikan sistem tersebut, maka dapat terjadi perubahan cara kerja yang cukup signifikan. Sering kali implementasi awal sistem memerlukan proses manual dan proses komputerisasi berjalan secara pararel untuk menguji sistem.

Tentunya dari pihak developer harus terlebih dahulu melakukan tes hingga pada unit terkecil untuk mengurangi tingkat kegagalan sistem saat implementasi.

Berubahnya rutinitas kerja terkadang dikeluhkan oleh user yang merasa pekerjaannya bertambah (tetapi gaji tidak bertambah), sementara keberhasilan suatu sistem harus didukung sepenuhnya oleh pihak-pihak terkait, termasuk pengguna sistem tersebut.

Karena itu, diperlukan pengarahan dan training yang mendukung user untuk menggunakan sistem dengan nyaman dan memberikan pengertian bahwa sistem diciptakan justru akan membantu pekerjaan manual dan memperbaiki sistem yang lama.

Penutup

Dari awal hingga akhir software development, cobaan terbesar pada umumnya adalah menghadapi iterasi atau pengulangan. Biasanya proyek yang tidak selesai adalah sistem yang terhenti pada suatu titik bukan karena ketidaksanggupan untuk melanjutkan development secara teknis (walaupun mungkin saja terjadi pada beberapa kasus tertentu), tetapi karena berputar-putar dalam sebuah lingkaran karena adanya konflik kepentingan.

Salah satu buah simalakama yang sering terjadi adalah sebagai berikut:

Developer memiliki pengetahuan, prosedur dan tools yang baik untuk membangun sistem komputerisasi yang baik, memenuhi standar pengembangan software sesuai dengan buku teks dan literatur.

Di pihak lain, calon customer tidak selalu datang dari background teknologi Informasi, mungkin memiliki budget relatif rendah, dengan skala bisnis menengah ke bawah.

Sering kali yang dikejar kedua pihak adalah kata deal, dimana developer mungkin akhirnya menawarkan biaya murah tetapi bertekad membuat software secara instan, atau pihak customer menyanggupi biaya yang diajukan tetapi menuntut sistem harus memuaskan tanpa kriteria yang jelas.

Salah satu solusinya adalah dengan menerapkan software development dimulai dari skala dan modul yang terbatas, dimana budget dapat diterima dan kualitas software dapat dipertanggungjawabkan. Kesuksesan sebuah software tercermin dari penggunaan software itu sendiri, dimulai dari skala yang relatif kecil.

Sebuah contoh yang jelas adalah operating system Windows Vista saat ini, bukankah merupakan hasil perjalanan panjang dari sistem operasi MS-DOS yang demikian sederhana dibandingkan Windows Vista?

Software development dibuat untuk melahirkan sebuah sistem yang lebih baik, karena itu sudah seharusnya software development menjadi merupakan perjalanan yang menyenangkan baik bagi developer, customer dan pengguna.

Leave a comment

No comments yet.

Comments RSS TrackBack Identifier URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s