Bahaya Requirement Volatility

WAKOOL.ID-- Beberapa waktu yang lalu saya diundang sebagai nara sumber oleh sebuah instansi pemerintah yang akan mengembangkan sebuah sistem aplikasi. Pada forum tersebut hadir pemilik pekerjaan, perwakilan user dan tim vendor yang ditunjuk untuk mengembangkan sistem aplikasi tersebut. Salah satu hal menarik yang ingin saya sampaikan disini adalah bahwa pada forum tersebut Project manager dari vendor tersebut menyampaikan komplain atas kebingungan yang mereka hadapi.

Kebingungan yang disebabkan oleh berubah-ubahnya kebutuhan sistem yang mereka terima. “Terus terang kami bingung sebenarnya sistem seperti apa yang perlu kami develop ini. Kebutuhan yang kami terima terus berubah..”, kata project manager vendor itu menyampaikan keluhannya. Saya lebih terkejut lagi bahwa ternyata spesifikasi kebutuhan yang terakhir disampaikan kepada vendor tersebut adalah dokumen hasil kajian saya. Saya heran karena dokumen saya itu sebenarnya adalah dokumen kajian terhadap kelayakan dan risiko dari sebuah proyek implementasi sistem tertentu. Tapi setelah mengamati perdebatan diantara kedua pihak ini, saya pun akhirnya menangkap bahwa sebenarnya kondisi ini disebabkan karena baik user maupun developer tidak memahami secara pasti sistem seperti apa yang sebenarnya mau dibangun. Sehingga kebutuhan sistem pun bergerak terus, mengambang terus, berubah-ubah terus seiring dengan berjalannya proyek.

Dalam sebuah proyek pengembangan dan implementasi aplikasi, masalah kebutuhan sistem yang berubah-ubah terus adalah hidangan rutin sering dihadapi. Hanya saja hidangan yang ini adalah jenis hidangan yang bikin pusing, bikin repot dan bisa merugikan semua pihak. Hidangan ini biasa dinamakan Requirements Volatility (RV). Termasuk dalam RV ini adalah penambahan, penghilangan dan modifikasi kebutuhan yang terjadi pada siklus pengembangan sistem aplikasi. RV menyebabkan pengerjaan ulang pada desain dan kode yang disamping dapat membengkakkan waktu dan biaya pengembangan sistem juga dapat mempengaruhi kualitas dari sistem yang dikembangkan tersebut. Di satu sisi mengabaikan permintaan perubahan kebutuhan ini dapat menyebabkan kegagalan implementasi karena penolakan user untuk menggunakan sistem nantinya, sementara jika dituruti dapat menyebabkan waktu dan biaya proyek jadi membengkak.

Berbagai penelitian mengkonfirmasi kritikalitas manajemen RV ini terhadap kesuksesan proyek pengembangan aplikasi. Penelitian yang dilakukan antara lain mengatakan bahwa project scope management (dimana RV berada) merupakan area yang paling berdampak besar terhadap kesuksesan/kegagalan proyek [Thakurta, 2010] (lihat grafik di bawah, skala dampak: 0-5).

Statistik Faktor Penyebab Kegagalan Proyek

Gambar: Project Scope Management merupakan faktor paling kritikal penyebab kesuksesan/kegagalan proyek

Sehingga manajemen terhadap RV ini sangat kritikal terhadap kesuksesan proyek [Thakurta, R.; F. Ahlemann, 2010]. Untuk mengelola RV ini dengan baik, maka kita perlu mengidentifikasi terlebih dahulu faktor risiko yang memicu RV ini. Faktor risiko untuk RV ini meliputi [Satkhivel, 2010]:

  • Sistem Informasi yang strategis. Biasanya sistem informasi yang strategis merupakan hal baru bagi perusahaan dan mungkin juga tidak diimplementasikan di perusahaan lain di luar. Kebutuhan untuk sistem seperti ini umumnya awalnya tidak terlalu jelas dan berkembang terus seiring dengan waktu.
  • Teknologi baru. Karena biasanya teknologi baru membutuhkan waktu untuk mencapai kematangannya, maka penggunaan teknologi tersebut dapat menyebabkan RV.
  • Pemahaman user dan/atau developer yang kurang memadai terkait aplikasi. Ini seperti kasus yang saya ceritakan di awal tulisan ini. Mengingat pada pengembangan sistem aplikasi itu merupakan pekerjaan kolaborasi berbagai pengetahuan, maka kurangnya pengetahuan user terkait aplikasi akan menyebabkan kebutuhan yang muncul tidak terartikulasikan dengan baik/benar yang akan dikoreksi/diubah belakangan. Demikian juga developer yang kurang paham area aplikasi maka dia pun tidak dapat menangkap dengan benar apa yang sebenarnya dibutuhkan oleh user, sehingga belakangan nanti harus diubah.
  • Kurang pengalamannya Developer dan kurangnya pengetahuan user dalam teknologi terkait. Developer yang kurang berpengalaman dapat pula memicu RV. Selain itu RV juga dapat dipicu oleh kurangnya pemahaman user dalam teknologi terkait. Kedua faktor ini jika berkumpul jadi satu akan berpotensi besar memicu RV.
  • Sistem yang sangat besar dan kompleks. Sistem yang besar tentu juga memiliki daftar kebutuhan yang banyak pula, yang masing-masingnya memiliki kemungkinan berubah. Tanpa ada representasi user yang cukup dari semua bagian yang terkait maka akan menyebabkan daftar kebutuhan yang tidak lengkap yang akan ditambahkan kemudian atau kebutuhan yang salah yang nantinya mesti dikoreksi. Pada sebuah sistem yang kompleks, perubahan pada satu titik akan dapat memicu reaksi berantai perubahan-perubahan pada bagian yang lain. Itu kalau ketahuan. Kalau tidak ketahuan atau ketinggalan, koreksinya baru dilakukan belakangan (setelah teridentifikasi).
  • Banyaknya departemen/fungsi yang terkait dengan sistem. Banyaknya pihak yang terkait pada sebuah sistem jika tidak dikelola dan terwakili dengan baik akan menyebabkan gelombang permintaan perubahan yang muncul belakangan.
  • Tim proyek yang tidak stabil. Tingginya tingkat turnover dari personil proyek (baik dari sisi user maupun developer) dapat mengganggu kesinambungan pengembangan aplikasi dan dapat pula memicu adanya perubahan-perubahan.
  • Jadwal proyek yang dimampatkan. Proyek-proyek yang –karena alasan tertentu—dipaksa harus selesai sebelum waktu yang seharusnya dibutuhkan akan menyebabkan kebutuhan yang ditangkap menjadi kurang lengkap atau kurang tepat yang akan mengakibatkan perlunya perubahan-perubahan di kemudian hari.
  • Perubahan-perubahan kebutuhan yang tidak esensial. Setelah user mendapatkan gambaran mengenai aplikasi yang dikembangkan, biasanya memicu ide-ide baru untuk penyempurnaan sistem yang sebenarnya tidak esensial, atau sekedar nice-to-have.

Satu hal penting yang juga perlu dicatat adalah  bahwa pihak user dapat menambah, memodifikasi, atau menghilangkan kebutuhan sebenarnya bisa juga karena kurangnya perencanaan di pihak mereka atau karena adanya ketidak-tegasan dalam pengambilan keputusan.

Diharapkan dengan mengenali faktor-faktor risiko yang dapat menyebabkan RV ini dapat membantu dalam pengelolaan risiko proyek yang terkait dengannya. Sehingga kemudian dapat direncanakan bagaimana metode atau kontrol yang paling sesuai untuk menghadapi faktor-faktor risiko tersebut. Mudah-mudahan dalam tulisan berikutnya dapat saya lanjutkan. [wkid/mti/picture:shilpagupta4]


Tentang Artikel :

Dalam sebuah proyek pengembangan/implementasi sistem/software, requirement volatility merupakan salah satu ancaman yang dapat menggagalkan proyek secara keseluruhan. Apa dan bagaimana Requirement Volatility itu?


Download Apps