MANAJEMEN PROYEK PERANGKAT LUNAK

Assalammualaikum Wr. Wb.

Setelah sekian lama tidak membuat note, akhirnya saya membuat lagi untuk pertama kalinya di tahun 2019. Di tahun 2019 ini saya akan memberikan catatan tentang manajemen proyek perangkat lunak.

MANAJEMEN PROYEK PERANGKAT LUNAK

Sebelum mengetahui apa itu manajemen proyek perangkat lunak, kita harus tahu apa itu manajemen, proyek dan perangkat lunak tersebut. Berikut ini penjelasannya :

A.  Manajemen

Ada beberapa pengertian manajemen menurut para ahli. Berikut ini pengertian manajemen menurut para ahli :

1.   George R. Terry

Manajemen adalah proses yang khas yang terdiri dari tindakan-tindakan: perencanaan, pengorganisasian, penggerakan, dan pengawasan yang dilakukan untuk menentukan serta mencapai sasaran-sasaran yang telah ditetapkan melalui pemanfaatan sumber daya manusia serta sumber-sumber lain. Manajemen ialah wadah didalam ilmu pengetahuan, sehingga manajemen bisa dibuktikan secara umum kebenarannya.

2.   Ricky W. Griffin

Manajemen adalah sebuah proses perencanaan, pengorganisasian, pengkoordinasian, dan pengontrolan sumber daya untuk mencapai sasaran secara efektif dan efisien. Efektif berarti bahwa tujuan dapat dicapai sesuai dengan perencanaan, sementara efisien berarti bahwa tugas yang ada dilaksanakan secara benar, terorganisir, dan sesuai dengan jadwal.

Dari pengertian menurut 2 ahli tersebut dapat disimpulkan bahwa manajemen merupakan suatu proses yang terdiri dari perencanaan, pengorganisasian dan pengontrolan untuk mencapai suatu tujuan.

B.  Proyek

Ada beberapa pengertian manajemen menurut para ahli. Berikut ini pengertian manajemen menurut para ahli :

1.   Nurhayati (2010:4)

Proyek adalah upaya atau aktivitas yang diorganisasikan untuk mencapai tujuan, sasaran dan harapan-harapan penting dengan menggunakan anggaran dana serta sumber daya yang tersedia, yang harus diselesaikan dalam jangka waktu tertentu.

2.   PMBOK (Project Management Body of Knowledge) Edisi ke-3

Proyek adalah usaha sementara dengan awal dan akhir dan harus digunakan untuk menciptakan produk, layanan atau hasil yang unik.

Dari pengertian menurut 2 ahli tersebut dapat disimpulkan bahwa proyek adalah suatu aktivitas sementara untuk mencapai suatu tujuan.

C.  Perangkat lunak

Sama seperti manajemen dan proyek, perangkat lunak mempunyai pengertian menurut para ahli. Berikut ini pengertian menurut para ahli :

1.   Imam Prayogo Pujiono

Ahli yang mendefinisikan software adalah Imam Prayogo Pujiono, M.kom yang merupakan praktisi dan dosen di dalam bidang rekayasa perangkat lunak. Imam berpendapat bahwa software adalah sebuah program dalam komputer yang dirancang sedemikian rupa, yang seandainya dijalankan akan memberikan perintah ke komputer / hardware / software lain dalam rangka menyelesaikan sebuah tugas, pekerjaan, dan juga tuntutan tertentu seperti yang diharapkan user.

2.   Fauziah

Ahli lainnya yang mendefinisikan software adalah Fauziya, menurut Fauziyah software adalah sebuah program komputer yang berguna untuk menginput data, menyimpan data, mengecek data, memanipulasi data dan memperoleh hasil dari data tersebut. yang dilakukan dengan menggunakan perangkat hardware.

Dari pengertian menurut 2 ahli tersebut dapat disimpulkan bahwa perangkat lunak adalah suatu program komputer yang dirancang untuk menginput data, menyimpan data dan lainnya yang berkaitan dengan komputer tersebut dengan menggunakan perangkat keras (hardware).

Setelah kita mengetahui apa itu manajemen, proyek dan perangkat lunak, mari kita mengetahui apa itu manajemen proyek perangkat lunak dapat kita simpulkan bahwa manajemen proyek perangkat lunak merupakan sebuah proses perencanaan, pengorganisasian dan pengontrolan program komputer yang beraktivitas sementara.

PERMASALAHAN YANG TERJADI DALAM MENGERJAKAN PROYEK PERANGKAT LUNAK

Ada beberapa permasalahan yang sering sekali terjadi dalam mengerjekan proyek perangkat lunak menurut salah satu sumber eksternal yaitu :

1.   Poor User Input

User kurang terbuka dalam menyatakan kebutuhannya, padahal hal itu sangat berdampak pada pekerjaan software developer. Akibatnya, pihak developer harus bekerja keras untuk memahami apa saja yang menjadi bisnis user, sehingga bisa memprediksi fasilitas apa saja yang diperlukan.

2.   Stakeholder Conflichts

Stakeholder bekerja di bawah ilusi bahwa semua orang harus mendapatkan apa yang mereka inginkan. Akibatnya sejumlah alternatif yang berbeda dipersiapkan untuk mengakomodasi semua permintaan yang mungkin timbul. Perbedaan tersebut selanjutnya diekspos oleh developer dan mengakibatkan sistem menjadi ambigu. Konflik dalam stakeholder ini bisa menjadi tokoh utama kegagalan sebuah proyek, karena pihak developer tidak dapat memahami apa yang sesungguhnya diinginkan oleh stakeholder.  

3.   Vague Requirement

Perlu bekerja keras untuk mempelajari apa yang akan terjadi ketika sebuah proyek mulai dikerjakan pada saat kebutuhan yang diinginkan belum jelas. Bisa jadi untuk setiap step yang diambil kemudian perlu mundur tiga langkah ke belakang. Biaya proyek dan kualitas hasil yang berubah cepat bisa lepas dari kontrol, sehingga perusahaan bisa dipersalahkan bahkan bisa kehilangan kontrak untuk menyelesaikan proyek tersebut.Seperti yang sering terjadi pada sejumlah proyek gagal, bahwa lingkup permasalahan yang tidak cukup sempit tidak bisa memberi peluang yang masuk akal untuk sukses. Oleh karenanya perlu memastikan kebutuhan yang diinginkan user sebelum pekerjaan tersebut dimulai. Kendati demikian, kenyataannya perkembangan kebutuhan masih saja terjadi. Permasalahan ini bisa diatasi bila arsitektur dan prosesnya dibuat mampu mengakomodasi perubahan atau setidaknya dibuat ketentuan jelas bagaimana dan kapan requirement bisa ditambahkan, dilepas dan diimplementasikan, termasuk siapa yang akan menanggung biaya perubahan tersebut. 

4.   Poor Cost and Schedule Estimation 

Sebenarnya tidak fair menuduh setiap proyek PL pasti mengalami kegagalan, jika tidak mengaitkan antara biaya yang dikeluarkan dengan tujuan yang diinginkan. Sama seperti yang lain, setiap proyek PL juga memiliki jadwal dan biaya minimal yang dapat dicapai. Permasalahan bisa muncul kapan saja manakala orang  yang membuat jadwal tidak mendengarkan masukan orang yang biasa mengerjakannya. Misalnya untuk menyelesaikan sebuah program biasanya diperlukan 5 orang selama setahun, jelas berbeda seandainya hanya dikerjakan 4 orang selama 8 bulan, baik dilihat dari sisi desain maupun quality-check-nya.   

5.   Skills That Do Not Match The Job

Pengerjaan proyek dengan teknologi tinggi memerlukan seorang manajer dengan kemampuan teknik yang hebat. Penanggung jawab proyek harus bisa menempatkan orang yang memahami dampak dari resiko teknik yang diambil. Namun demikian, seorang teknolog yang baik tidak perlu diseimbangkan dengan manager yang baik, karena kemampuan manajemen dan pemrograman tidak bisa dipertukarkan.Pada proyek yang lebih besar membutuhkan orang-orang yang cakap dalam planning, oversight, organization dan communication skill; sementara seorang teknolog yang brilian tidak perlu memiliki keahlian tersebut.Sebuah team yang beranggotakan orang-orang dengan gaji lebih besar namun memiliki kemampuan spesialisasi yang baik, akan lebih pantas dipilih daripada sebuah kelompok yang terdiri dari orang-orang dengan gaji rendah yang masih memerlukan berminggu-minggu bahkan berbulan-bulan untuk mempelajari sebuah proses atau teknologi baru sebelum mereka mulai mengerjakannya. 

6.   Hidden Cost of  Going “Lean and Mean”

Sejumlah kegagalan akan dipandang sebagai hasil langsung dari kinerja yang buruk, meskipun sesungguhnya kinerja yang buruk tidak menunjuk pada faktor yang signifikan dalam kegagalan pada kebanyakan proyek. Kegagalan sebuah proyek tidak bisa terlepas dari rencana tujuan yang ingin dicapai.  Hal lain yang juga pantas dicermati adanya perbedaan kecenderungan yang terjadi dalam sebuah organisasi. Pada level yang lebih rendah, seorang developer akan sibuk menghitung pengeluaran mereka yang mahal, hasil kerja pegawai, update software dan pekerjaan-pekerjaan lainnya, sedangkan pada tingkatan yang lebih tinggi hal tersebut akan dikerjakan oleh seorang spesialis yang memadai. Kebanyakan software developer akan menghabiskan setengah dari jam kerja mereka untuk berlama-lama dalam mengerjakan tugas yang diberikan dengan tanpa melakukan apapun terhadap pekerjaan tersebut. Orang-orang demikian ini sangat tidak berkemampuan dan menjadi isu produktifitas yang sangat serius. 

7.   Failure to Plan

Banyak orang bekerja keras, tapi tak seorangpun yang memiliki rencana, karena tidak ada yang merasa perlu membuat rencana. Seorang manajer proyek sering tidak membuat rencana, karena banyak rencana yang diserahkan bersamaan dengan berlalunya waktu.  Mereka mengira waktunya akan habis untuk melakukan hal-hal seperti planning, design, requirement dan inspection.   Kebanyakan dari mereka berpendapat bahwa hal-hal tersebut bisa dilakukan bersamaan dengan pekerjaan sesungguhnya, seperti pada saat coding dan testing. Pandangan ini umumnya datang dari kalangan programmer yang mengisukan bahwa hal tersebut dapat dilakukan ketika perangkat lunak diimplementasikan, padahal jelas ada perbedaan antara speed dan progress. Kita perlu memberi penghargaan pada orang-orang yang tidak menganut pandangan itu sehingga terlepas dari misi bunuh diri tersebut. 

8.   Communication Breakdown

Sejumlah problema yang timbul pada proyek berskala besar biasanya jika orang yang mengerjakannya berasal dari bagian yang berbeda. Dalam banyak kasus proyek yang bermasalah, tidak ada seorang pun yang memiliki pandangan yang menyeluruh pada proyek tersebut, khususnya bila proyeknya berskala besar. Untuk itu perlu kiranya menginvestasikan waktu tambahan secara periodik agar semua orang di setiap posisi bersedia mempelajari gambaran besar proyek tersebut. Hal ini sejalan dengan sementara orang yang berpendapat bahwa seorang yang mengerjakan kepingan-kepingan kecil sebuah puzzle perlu mengetahui bagaimana sebuah keping bisa masuk ke dalam arsitektur gambar keseluruhan.   

9.   Poor Architecture

Desain perangkat lunak sebaiknya dapat dikonfigurasi ulang untuk mendukung sebuah fungsi baru. Sebuah arsitektur PL seharusnya bisa mengikuti organisasi dan misi yang berubah, setidaknya harus memperhitungkan keterbatasan jangka panjang, tingkat kesulitan dan harganya. Arsitektur PL harus dipandang seperti bangunan rumah, dimana penambahan pipa dan kabel  harus bisa dilakukan untuk fasilitas yang belum terpikirkan sebelumnya. Begitupun ketika sebuah PL mengalami perubahan kebutuhan atau bisnis yang tidak diantisipasi sebelumnya, harus dapat ditambah atau dimodifikasi tanpa harus membuat PL yang baru. 

10. Late Failure Warning Signals

Lamanya waktu penyelesaian dan besarnya biaya pembuatan PL sangat dipengaruhi oleh  sinyalemen orang yang mana kita takut mengatakan “tidak” kepadanya. Kedengarannya hal ini tidak baik secara politik dikarenakan  mengatakan atau menunjukkan perkiraan yang jauh dari yang dapat dijalankan. Memang kenyataannya tak seorangpun bisa mengetahui bencana yang mendekat karena sering kali tak terlihat gejala awalnya. Dalam dunia nyata, sama seperti orang yang levelnya lebih rendah dapat meyakinkan manajer level atasnya bahwa proyek tersebut sesungguhnya tidak dapat dikerjakan sedemikian rupa hingga jatuh kepadanya.

Dari penjelasan tentang permasalahan tersebut, dapat disimpulkan bahwa mengerjakan proyek perangkat lunak banyak sekali permasalahannya, mulai dari user yang kurang terbuka sampai permasalahan yang berkaitan dengan waktu, waktu memang merupakan suatu hal yang pasti dalam permasalahan ini.

Ada sebuah pertanyaan yang sering sekali dipertanyakan yaitu “mengapa mengerjakan sebuah proyek perangkat lunak jauh lebih bermasalah dibandingkan dengan mengerjakan proyek rekayasa lainnya?”. Dengan pertanyaan tersebut sudah terlihat jelaskan bahwa permasalahan saat mengerjakan sebuah proyek perangkat lunak jauh lebih bermasalah. Kita sudah mengetahui banyak sekali permasalahannya dari bagian yang sudah diperjelaskan di atas. Banyak sekali permasalahan yang tidak bisa diselesaikan dengan cepat dibandingkan dengan mengerjakan proyek rekayasa lainnya.

Referensi

• https://www.zonareferensi.com/pengertian-manajemen/
• https://ilmumanajemenindustri.com/pengertian-manajemen-proyek-project-management-karakteristik-manajemen-proyek/
• http://www.materidosen.com/2017/03/9-pengertian-software-menurut-para-ahli.html
• https://yayuk05.wordpress.com/2007/10/01/faktor-faktor-penyebab-kegagalan-proyek-perangkat-lunak/