Software Projects: Quo Vadis?

Berapa probability sebuah project pembuatan software akan berhasil - on-time, on-budget, as expected? Awalnya saya ngira ini pertanyaan iseng, tapi semakin ke sini justru kok semakin relevan. Rekan-rekan saya di sesama field pastilah punya cerita “gila” tentang bagaimana kami semua, bukannya sekali dua kali saja, tapi hampir selalu dibuat terkapar oleh software-project yang entah kenapa kok nggak kelar-kelar.

Tapi kita nggak sendirian ternyata. Laporan dari The Standish Group (a must-read!) yang menganalisa lebih dari 8.000 software-project di U.S. menyimpulkan sesuatu yang membuat kami semua langsung manggut-manggut mengiyakan:

… the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. – The CHAOS Report 1994.

Kemungkinan sukses project kita, statistically, cuman 15%! :-(

Besar sekali kemungkinan bahwa software-project di tangan kita akan… ya kalau nggak molor, over-budget, atau dua-duanya. Untuk project-project skala menengah-besar, bisa lebih parah lagi. Jadi, seperti terlihat di laporan Standish, ada korelasi antara project-size dengan success-level. Semakin besar project, semakin tinggi resiko kegagalannya. Dari pengalaman kita, project-project yang nggak seberapa (i.e. sekitar dua tiga bulan dengan lima atau enam team-members) biasanya adalah project-project sukses. Lebih dari setahun, dengan tim di atas 15 orang, biasanya ada tendensi bakal horor! Ada cerita, project ERP yang dijadwal 2 tahun, nilainya 2 milyar. Tapi setelah jalan 2 tahun dan menghabiskan 4 milyar, baru 10 - 15% jadi! Gila kan?

Penyebabnya yah, menurut report itu… umum sih sebenarnya: requirement yang nggak jelas, usernya nggak peduli dan nggak proaktif – kasih input sepotong-sepotong, keinginannya berubah-ubah; Pak Bos kasih schedulenya nggak realistis (tender sih), nggak ada commitment dari top managementnya di sisi usernya sendiri, kurang planning di sisi kita, kurang resources… Masing-masing kami punya versi lucu-lucunya:

Dri, coba estimasi berapa lama projectnya? – Uhm… perhitungan kami seminggu ini, sekitar 6 bulan, Pak. – Hah? Nggak mungkin itu! Client cuma minta 3 bulan! (Lah, ngapain nyuruh estimasi?)

Requirement document? Ehm, kami nggak perlu itu. We hire you to write programs, not documents.

300 mandays, Pak. – Bagus, Sarto. Berarti dengan 30 orang, project akan selesai dalam 10 hari kan? (Sambil menerawang dengan tololnya kalau saja ada 300 orang, besok pagi udah bisa product launching).

Wow, mahal sekali! Lha wong Excel aja saya beli cuma $100 kok?!

Miris kan? Ini baru sebagian aja. Teknologi sudah melesat sekian depa, tapi faktor-faktor itu dari dulu sampai sekarang kok ya sama aja, nggak maju-maju. Stupidity ada di mana-mana: nggak di sisi user, nggak di sisi kita sendiri. Mungkin benar juga pendapat Pak DeMarco:

For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure… The major problems of our work are not so much technological as sociological in nature. (Peopleware, Tom DeMarco)

Barangkali kita telah salah kira bahwa kita masuk di dunia high-tech business. Well, we’re NOT. We’re (still) in people business!

Entahlah, faktanya barangkali nggak seburuk angka-angka yang dimunculkan di Standish Group Report. Dalam arti: setiap project yang tidak on-time dan on-budget kan nggak bisa begitu saja dianggap sebagai failure. Tidak sedikit client yang cukup punya cadangan toleransi pada time dan budget yang pada akhirnya masih menerima itu sebagai suatu achievement yang patut diacungi jempol. Bagaimanapun, dari feedback pengalaman selama ini, saya setuju satu hal: kita punya masalah besar di sini.

Saya coba coret-coret, bukan untuk mencari solusi, tapi revisiting aja terhadap asumsi-asumsi yang kita pegang selama ini:

(1) Menyadari failure-ratenya sebesar itu, mindset mustinya diubah. Bukan lagi soal how to complete the project, tapi lebih ke how to manage the risk of failure. Bukan soal tune-up kendaraan, tapi lebih ke persiapan menghadapi kerikil-kerikil dan buasnya medan di jalanan. Lebih jauh lagi, persiapan menghadapi kegagalan.

(2) Sekalipun mirip, software development project sebenarnya nggak persis sama dengan project bikin rumah misalnya. Faktor surprise-nya jauh lebih banyak. Bisa dibilang yah, sebuah innovation project, karena seringkali tantangan yang dihadapi selalu baru. Saya penasaran dengan bagaimana Toyota, misalnya, meng-outsource design mobil-mobil baru mereka.

(3) Saya ngerasa user involvement itu penting. Penting sekali! Musti ada semacam mekanisme yang menegaskan bahwa they are the project’s owner. Mindset user selama ini kan: so that’s why we hire you to do all these dirty stuffs. This is not right. Setuju, kami ini dokter, tapi kalo pasien nggak mau ikut andil minum obatnya, mau sembuh gimana?

Talk about this later.

1 Comment »

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>