Proyek TI dan kontrak perangkat lunak yang dikembangkan di dalam negeri dapat menimbulkan konsekuensi serius bagi startup. Para pendiri harus menyadari risiko ini sebelum menandatangani kontrak.
Kontrak di luar rak?
Aturan yang jelas diperlukan, terutama ketika segala sesuatunya tidak berjalan sesuai rencana. Untuk menekan biaya, banyak perusahaan menggunakan rancangan kontrak untuk proyek TI yang disalin dari beberapa templat. Kontrak DIY ini cocok dengan setelan yang dibuat oleh orang awam. Biasanya, kontrak semacam itu hanya berisi ketentuan-ketentuan yang tidak jelas yang menimbulkan lebih banyak pertanyaan daripada jawaban. Dalam kasus terburuk, bahkan mungkin terdapat klausul kontradiktif yang tersembunyi dalam kontrak. Harapan yang tidak dapat didamaikan mengenai hasil akhir dan perselisihan mengenai layanan, kompensasi dan hak penggunaan hampir tidak dapat dihindari. Daftar hambatan umum dalam bidang kontrak TI dan perangkat lunak akan membantu kedua belah pihak menghindari kesalahan umum.
#1 Deskripsi subjek kontrak atau layanan
Klien sering kali memiliki ekspektasi yang terlalu tinggi terhadap hasil proyek TI karena cakupan layanan sebenarnya dan hasil yang harus dibayar tidak dinyatakan atau didefinisikan dengan jelas. Sebelum memulai proyek TI atau perangkat lunak, harus jelas bagi semua orang yang terlibat apa sebenarnya layanan kontraktor tersebut. Oleh karena itu disarankan untuk mencatat secara kontrak setidaknya aspek-aspek berikut untuk proyek-proyek besar:
- Tonggak sejarah proyek
- Deskripsi layanan (sebagian).
- Jenis manajemen proyek (lincah atau klasik)
#2 Kejelasan mengenai jenis kontrak
Dari perspektif hukum, deskripsi layanan yang akurat sangat penting untuk menentukan kategori kontrak mana yang harus ditetapkan kontrak proyek TI – yaitu kontrak layanan atau pekerjaan. Pengkategorian ini mempunyai konsekuensi hukum yang luas, karena dalam kontrak kerja, keberhasilan kontraktor ditentukan oleh kinerjanya, sedangkan kontrak jasa hanya menjamin kegiatan murni – tanpa jaminan keberhasilan. Jenis kontrak juga menimbulkan hak-hak mitra kontrak, seperti penarikan diri atau tanggung jawab atas kerusakan. Dalam kasus tertentu, bagian-bagian tertentu dari kontrak bahkan dapat diklasifikasikan sebagai kontrak kerja, sementara bagian lain dapat diklasifikasikan sebagai kontrak kerja.
Tip: Tidaklah cukup hanya menggunakan kata “kontrak kerja” sesering mungkin. Deskripsi layanan individual sangat menentukan dalam menentukan jenis kontrak.
#3 Proses dan peninjauan proyek
Kontrak proyek TI sering kali menetapkan interval yang terlalu pendek atau bahkan tidak ada sama sekali, setelah itu pelaporan harus dilakukan. Pelaporan mengenai status saat ini harus dengan jelas menunjukkan langkah-langkah mana yang telah diambil dan mana yang masih diperlukan untuk mencapai tujuan. Hal-hal berikut harus diatur dalam proyek TI:
- Deteksi kesalahan (analisis kesalahan)
- Batas waktu untuk menyelesaikan masalah teknis
- Backlog terisi
- Sprint (perencanaan dan peninjauan – proyek tangkas)
- Manajemen tugas dan peran
#4 Deteksi kesalahan
Pemecahan masalah secara profesional sangat penting untuk proyek TI dan perangkat lunak. Oleh karena itu, perusahaan harus secara tegas menyetujui aspek-aspek berikut dalam kontrak:
- Penerima Laporan
- Batas waktu untuk melaporkan kesalahan
- Indikasi sistem/pengguna yang terpengaruh
- Klasifikasi kesalahan (misalnya sistem kritis, parah, tampilan salah, prioritas rendah, dll.)
Deteksi kesalahan yang efektif dapat menghindari perselisihan mengenai penerimaan sebagian layanan terlebih dahulu.
Tip: Misalnya, ada kemungkinan ada klausul yang menyatakan bahwa suatu layanan tidak dapat diterima selama terdapat lebih dari empat kesalahan dalam kategori “serius”.
#5 Kompensasi dan permintaan perubahan
Waktu adalah uang – tetapi siapa yang membayar berapa dan kapan tidak diatur secara jelas dalam banyak kontrak. Namun, kesepakatan mengenai kompensasi dan tanggal jatuh tempo diperlukan. Hal ini bahkan lebih benar lagi ketika proyek-proyek besar dan intensif sumber daya masih tertunda.
Sekalipun kompensasinya sudah diklarifikasi, seringkali kita lupa untuk mencantumkan secara kontrak penyertaan layanan tambahan (permintaan perubahan) atau anggaran tambahan. Namun, penyesuaian seperti itu cepat atau lambat diperlukan di hampir setiap proyek TI. Justru pada titik inilah banyak proyek TI gagal: kontraktor berusaha memenuhi keinginan dan kebutuhan baru klien mereka dan memenuhinya dalam kerangka proyek yang ada. Pada saat yang sama, tidak jelas bagaimana dan kapan pekerjaan tambahan tersebut akan dibayar.
Paling lambat, ketika pelanggan menjadi tidak sabar dan pengembang menyadari bahwa biaya sebenarnya jauh melebihi perhitungan awal – meskipun fungsi dasar belum dilaksanakan – perselisihan tidak dapat dihindari. Apa yang disebut dengan scope creep hanya dapat dihindari dengan mengkomunikasikan secara jelas: Persyaratan baru setelah dimulainya proyek berada di luar lingkup proyek yang disepakati dan harus diberi kompensasi secara terpisah. Pelayanan tambahan ini harus selalu dicatat secara tertulis dan ditambahkan pada kontrak yang ada. Bahkan lebih mudah lagi untuk membuat peraturan yang jelas ketika kontrak telah selesai tentang bagaimana perintah selanjutnya dapat disusun dan dimasukkan ke dalam kontrak yang ada.
#6 Kualifikasi pengembang
Keberhasilan suatu proyek sering kali bergantung pada apakah alur kerja dan komunikasi berhasil. Idealnya, mitra kontrak berbicara setinggi mata. Ini juga mencakup keahlian teknis. Namun, dalam banyak kontrak perangkat lunak tidak ada peraturan mengenai apakah karyawan yang dipekerjakan di kedua belah pihak harus memiliki kualifikasi minimum tertentu. Kesepakatan yang cocok sangat berharga di sini. Jika kontak yang memenuhi syarat disebutkan dengan jelas di kedua sisi, mereka tidak dapat dengan mudah digantikan oleh rekan kerja yang “lebih murah” dan kurang berpengalaman.
#7 Perjanjian Tingkat Pemeliharaan, Dukungan, dan Layanan
Blok subjek “Dukungan dan Pemeliharaan” menawarkan banyak potensi sengketa hukum. Apa yang dianggap cacat dan kapan hak garansi berlaku? Ketika perangkat lunak dilisensikan, semua tindakan pemecahan masalah harus diberikan sebagai bagian dari “pemeliharaan dan dukungan”. Dalam kontrak proyek TI, sangat penting untuk membuat perbedaan yang jelas antara pemecahan masalah selama penerimaan sebagian selama proyek (garansi) dan layanan pemeliharaan setelah proyek selesai. Struktur kontrak harus sedemikian rupa sehingga perbedaan hukum ini tidak berperan dalam praktiknya, misalnya dengan memasukkan poin-poin berikut:
- Tidak ada lisensi atau kontrak tanpa pemeliharaan dan dukungan selama setidaknya dua belas bulan
- Struktur dan isi pesan kesalahan
- Definisi sistem tiket
- Menyepakati perjanjian tingkat layanan dengan kerangka waktu untuk respons dan penyelesaian masalah
#8 Hak penggunaan
Berkenaan dengan hak penggunaan, semakin tepat dan jelas hak pelanggan didefinisikan dalam kontrak, semakin sedikit perselisihan yang timbul mengenai bagaimana perangkat lunak atau hasil proyek dapat digunakan atau diubah. Dalam kasus ekstrim, pelanggan mungkin menerima perangkat lunak setelah perangkat lunak dibuat, namun tidak diperbolehkan menggunakannya untuk semua tujuan yang dimaksudkan. Ini adalah skenario terburuk yang harus dihindari bagaimanapun caranya. Jika kedua belah pihak belum menyetujui sesuatu yang spesifik mengenai hak penggunaan, pelanggan hanya menerima hak penggunaan yang diperlukan untuk memenuhi tujuan kontrak minimum.
#9 Dokumentasi status proyek
Kontrak proyek TI yang baik dilengkapi dengan peraturan yang jelas dan konkrit untuk dokumentasi proyek. Dokumentasi harus disesuaikan dengan ukuran proyek dan idealnya dilakukan secara paralel dengan kemajuan proyek. Sistem tiket dengan wiki cocok untuk ini, misalnya. Jika terjadi perselisihan, pengembang juga dapat mempengaruhi laporan selanjutnya demi kepentingan mereka.
Kepatuhan terhadap kontrak berarti kerja sama yang produktif
Bahkan kontrak terbaik pun tidak ada gunanya jika tidak dipenuhi. Sayangnya, banyak orang yang takut untuk menuntut penerapan yang konsisten. Namun kontrak TI yang baik justru mendorong komunikasi ini. Kedua belah pihak harus memanfaatkan kesempatan ini setiap saat untuk mengacu pada kontrak yang disepakati bersama jika timbul masalah.