Pengembangan Software Gagal?

Pengembangan Software Gagal?

Kenapa banyak perusahaan yang mengembangan software ada yang berhasil ada yang gagal? Apa yang membedakan yang berhasil dan yang gagal? Apa sebab utama kegagalan dalam mengembangkan software?

Alasan 1: Komunikasi

Terminologi teknologi kadang membinggungkan, ditambah dengan banyaknya orang yang bergerak dibidang teknologi senang menggunakan jargon-jargon keren. Kadang membinggunkan juga kenapa mereka senang sekali menggunakan jargon-jargon tersebut yang sebenarnya tidak perlu.

Kesulitan utama dalam mengembangankan satu teknologi atau software adalah komunikasi tentang apa yang dibutuhkan dengan bahasa yang sederhana yang dipahami oleh semua pihak. Terutama untuk kalangan yang memang tidak bersentuhan langsung dengan teknologi, misalnya management pemasaran.

Kenapa ini alasan kegagalan nomor 1?

Komunikasi merupakan gerbang awal untuk memulai satu project pengembangan software. Dari hal inilah diturunkan spesifikasi software yang diinginkan oleh pemakai nanti. Spesifikasi software ini merupakan satu perangkat/dokumen yang penting untuk seorang developer. Karena dari spesifikasi inilah sistem dibuat. Jadi bila komunikasi macet, disatu sisi user/client tidak mengerti apa yang mereka inginkan/capai, disisi yang lain pengembang/provider tidak menangkap apa yang diinginkan/dicapai, yah hasilnya akan berantakan.

Lebih parah lagi bila client/user tidak berani bertanya pada pengembang secara detail apa maksud jargon tertentu dan berasumsi mereka tahu tentang hal tersebut, ini akan menjadi bom waktu pada saat pengembangan software nantinya.

Bagaimana sebaiknya agar resiko ini bisa di minimalisasi?

Gunakan list! buat daftar apa yang anda butuhkan atau anda ingin lihat diakhir pengerjaan mulailah dari sana.

Alasan 2: Tidak realistik

Sering kali user tidak realistik dalam melihat satu proses pengembangan software dikarenakan ketidaktahuan atau lebih parahnya lagi adalah sok tahu. Banyak penerapan teknologi yang gagal dikarenakan tidak realistiknya user dalam 3 hal berikut:

  • Waktu pengerjaan
  • Budget
  • Sumber daya manusia

Waktu pengerjaan dalam pengembangan software tidak berbanding lurus dengan jumlah orang yang mengerjakan. Misalnya satu project dengan tingkat kerumitan tertentu membutuhkan waktu pengerjaan 1 tahun dengan 5 orang developer dengan skill tertentu. Kemudian karena kebutuhan harus selesai dalam waktu 3 bulan 20 developer dengan skill tertentu. Hal inilah yang disebut sebagai tidak realistik.

Dengan mengalikan empat jumlah developer maka otomatis waktu pengerjaan menjadi seperempat kali-nya. Tidak seperti itu, bahkan ada kecenderungan dengan menambahkan jumlah developer akan membuat resiko satu project menjadi lebih tinggi.

Demikian pula dengan budget, dalam teknologi anda tidak dapat menawar semurah-murahnya untuk mendapatkan hasil sebaik-baiknya. Kenapa? Karena ada yang namanya requirement yang dibutuhkan untuk spesifikasi yang dibuat bisa di-delivery dengan baik. Delivery dari spesifikasi yang telah dibuat bisa membutuhkan orang dengan skill tertentu atau bahkan teknologi tertentu dengan harga tertentu.

Sumber daya disini maksudnya adalah kemampuan dari satu perusahaan/divisi/perorangan menjalankan software yang dibuat tersebut. Sebaik apapun software atau teknologi yang dibangun, pada akhirnya adalah orang juga yang akan menjalankan. Bila orang/team yang nantinya akan memakai tidak mau memakai software tersebut atau tidak mampu untuk menjalankannya maka tidak akan berjalan dengan baik.

Meminimalkan resiko ini dapat dilakukan dengan melakukan telaah yang jujur terhadap apa yang dibutuhkan dan apa yang inginkan dalam pengembangan satu software. Buatlah daftar apa yang anda inginkan kemudian bagi 2 menjadi 2 list:

  • MUST HAVE (Spesifikasi yang harus ada dalam software yang dikembangkan)
  • NICE TO HAVE (Spesifikasi yang kalau ada bagus, kalau tidak ada tidak akan memberi pengaruh berarti untuk hal yang ingin dicapai)

Dari sana komunikasikan dengan pengembang bagaimana delivery-nya, berapa lama, dan berapa budjet yang dibutuhkan. Bila semua yang ada dalam “must have” sudah tercakup, budjet anda masih ada, baru komunikasikan apa yang ada dalam list “nice to have“. Seperti dalam kehidupan cobalah tidak serakah dalam mengembangkan teknologi yang ingin anda pakai. Karena bila anda memaksakan untuk mendapatkan semuanya dengan budget dan waktu yang dipaksakan akhirnya hasilnya pun akan terpaksakan!

Alasan 3: Closure Yang Buruk

Biasanya dalam pengembagan software anda mempunyai Kerangka Acuan Kerja. Tugas dari dua pihak adalah memahami dengan pasti apa saja yang ada dalam KAK tersebut. Dari awal pelaksaan kedua belah pihak haruslah mengerti apa yang akan di-delivery pada akhir project pengembangan.

Project biasanya akan molor menjadi tidak ada batas waktu dan menghabiskan energi dua belah pihak bila salah satu, baik itu developer ataupun client/user ada yang tidak mengerti KAK apa yang termasuk dan apa yang tidak termasuk dalam pengembangan. Satu project pengembangan software baik itu internal atau melibatkan pihak ketiga butuh closure (penutup) agar jelah apa yang di-delivery dan apa yang harus dipertanggung-jawabkan.

Jadi jangan ada dari kedua belah pihak yang mengatakan: “Oh, itu toh maksudnya saya tidak tahu, saya kita maksudnya adalah bla bla bla”. Bila ada pihak yang mengatakan hal tersebut maka sebenarnya kesalahan ada dipihak yang mengatakan hal tersebut dengan alasan apapun.

Kenapa begitu?

Karena kalau tidak tahu apa yang harus di-deliver kemudia berani tanda tangan atau menyetujui kemudian diakhir mengatakan tidak tahu maksudnya, maka cuma ada 2 kemungkinan, pada saat tanda tangan tidak membaca (ini jelas bodoh), atau yang kedua menandatangani atau menyetujui apa yang tidak dimengerti (ini juga jelas bodoh). Dengan dua kemungkinan kesalahan diatas maka jelaslah siapa yang salah.

Jadi bagaimana untuk menghindari ini?

Bijaklah dalam membaca satu dokumen, minta diceritakan sehingga anda mengerti. Bila sudah diceritakan belum mengerti juga, jangan takut kelihatan bodoh, mintalah developer atau client/user anda mengambarkan maksudnya. Bila belum yakin buatlah mockup untuk itu. Kemudia masukan kedalam lampiran dalam KAK sehingga semua mengerti.

Moe

Just a simple human being...