Apa Itu Masalah Hukum dan Kontrak yang Berhubungan dengan Pengembangan Agile?

Ada berbagai metodologi dalam melanjutkan pengembangan sistem. Model Waterfall adalah yang paling klasik dan umum, dan banyak buku hukum yang membahas pengembangan sistem juga berdasarkan model ini. Dalam artikel ini, kami akan menjelaskan masalah hukum apa saja yang mungkin muncul dalam pengembangan sistem berdasarkan model Agile, yang sulit untuk mendapatkan informasinya dari buku dan sumber lainnya.

Pengembangan Agile dan Hukum

Apa itu Model dalam Pengembangan Sistem?

Dalam proyek pengembangan sistem, ada yang disebut model pengembangan sebagai kerangka kerja untuk memahami keseluruhan kemajuan. Contoh utamanya adalah model “Waterfall”. Yaitu, sama seperti air yang jatuh dari “hulu” ke “hilir” sungai, proses seperti definisi persyaratan, desain, implementasi, dan pengujian dilakukan secara berurutan. Ini adalah metode yang cocok untuk mengurangi sebanyak mungkin pengulangan dan pekerjaan ganda, dan untuk melanjutkan pekerjaan secara terencana.

Di sisi lain, dalam model pengembangan Agile, Anda mengulangi implementasi program kecil dan pengujian. Dengan mengulangi pekerjaan iteratif ini, Anda secara bertahap membangun sistem yang lebih besar. Untuk penjelasan lebih rinci tentang model pengembangan sistem ini dan perbandingan kelebihan dan kekurangan kedua model pengembangan, silakan lihat artikel di bawah ini.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Karakteristik Model Pengembangan Agile

Keuntungan besar dari pengembangan dengan model Agile adalah bahwa Anda dapat memulai pekerjaan sebenarnya dengan cepat. Karena pekerjaan “upstream” seperti definisi persyaratan dan pembuatan desain, dan pekerjaan implementasi program tidak dipisahkan, ini cocok untuk mengendalikan secara fleksibel, termasuk respons terhadap penambahan dan perbaikan fungsi, perubahan spesifikasi, dan sebagainya. Dari sudut pandang hukum, poin yang sangat penting untuk membuat model pengembangan Agile sukses adalah bagaimana Anda melakukan manajemen dokumen dan manajemen perubahan. Dalam model pengembangan Agile, peran dan tanggung jawab tidak dibagi sejelas dalam model Waterfall. Selain itu, karena ini adalah metode yang menekankan “kecepatan” untuk mencapai eksekusi dan tindakan, bukan “manajemen”, ini cenderung mengarah ke ketidaklengkapan berbagai desain, spesifikasi, dan catatan rapat.

Lebih lanjut, berbicara tentang manajemen perubahan, karena model pengembangan Agile memungkinkan respons yang lancar terhadap perubahan, ada risiko bahwa proyek dapat terbakar jika Anda melewati proses persetujuan dengan pembuat keputusan dan merespons permintaan perubahan spesifikasi di tingkat lapangan. Jika ini terjadi, keuntungan model pengembangan yang “respons terhadap perubahan setelahnya adalah lancar” itu sendiri dapat menjadi risiko kebakaran proyek.

Cara Mengelola Dokumen dan Perubahan dalam Pengembangan Agile

Pentingnya Manajemen Dokumen

Dalam proyek pengembangan berdasarkan model pengembangan Agile, titik yang menjadi kekhawatiran dari segi hukum adalah akumulasi interaksi berbasis lisan, yang mengakibatkan kekurangan dokumen. Mengenai hal ini, kami telah menjelaskan secara detail mengapa manajemen dokumen menjadi penting dalam proyek pengembangan sistem dalam artikel berikut.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Dalam artikel tersebut, kami menjelaskan pentingnya manajemen dokumen dalam proyek pengembangan sistem dari dua perspektif, yaitu pencegahan konflik sebelum terjadi (yaitu ‘Hukum Pencegahan’) dan pemeliharaan bukti saat konflik terjadi (yaitu ‘Manajemen Krisis’).

Pembentukan Dewan Konsultasi Efektif untuk Manajemen Dokumen

Ketika mengadopsi model pengembangan Agile, berbeda dengan model Waterfall, tidak ada rencana yang jelas yang disiapkan sebelumnya. Oleh karena itu, bukan hanya mengelola perbedaan antara rencana dan hasil yang sebenarnya, ada juga kekhawatiran bahwa biaya, baik dalam hal uang maupun waktu, akan meningkat jika semuanya diserahkan kepada tim di lapangan.

Oleh karena itu, langkah efektif adalah untuk memastikan bahwa orang yang bertanggung jawab mengadakan pertemuan konsultasi reguler untuk memastikan kelancaran proyek. Jika skala pengembangan kecil, memang, metode seperti mengumpulkan orang yang bertanggung jawab secara berkala daripada mengadakan pertemuan konsultasi reguler cenderung lebih disukai. Namun, dalam kasus model pengembangan Agile, risiko kehilangan masalah yang harus ditangani dalam pertemuan secara tepat waktu juga cenderung meningkat. Oleh karena itu, dapat dikatakan bahwa aman untuk memasukkan pengadakan pertemuan konsultasi reguler dalam kontrak dan sejenisnya. Cara menetapkannya ditunjukkan dalam kontrak model Kementerian Ekonomi, Perdagangan dan Industri Jepang sebagai berikut:

(Pembentukan Dewan Konsultasi)

Pasal 12 A dan B, sampai pekerjaan ini selesai, untuk membahas perkembangan, manajemen dan pelaporan risiko, kerja sama antara A dan B dan pelaksanaan tugas masing-masing, konfirmasi konten yang harus dimasukkan dalam spesifikasi sistem, diskusi dan penyelesaian masalah, dan hal-hal lain yang diperlukan untuk melaksanakan pekerjaan ini dengan lancar, akan mengadakan Dewan Konsultasi. Namun, (disingkat)…

2. Dewan Konsultasi, sebagai prinsip, akan diadakan secara reguler dengan frekuensi yang ditentukan dalam kontrak individu, dan di samping itu, akan diadakan setiap saat jika A atau B menganggapnya perlu.

3. Dewan Konsultasi, orang yang bertanggung jawab dari A dan B, petugas utama dan orang yang dianggap tepat oleh orang yang bertanggung jawab akan hadir. Selain itu, A dan B dapat meminta pihak lain untuk menghadiri Dewan Konsultasi jika diperlukan untuk diskusi, dan pihak lain harus mematuhi kecuali ada alasan yang masuk akal.

4. B, dalam Dewan Konsultasi, akan membuat laporan manajemen kemajuan dalam format yang disepakati antara A dan B dan mengajukannya, dan akan memeriksa status kemajuan berdasarkan laporan manajemen kemajuan tersebut, dan jika ada item yang tertunda, alasan dan tindakan untuk item tersebut, perubahan dalam struktur promosi yang ditentukan dalam bab ini (pergantian personel, peningkatan atau penurunan, perubahan kontraktor ulang, dll.), status pelaksanaan tindakan keamanan, keberadaan alasan untuk mengubah kontrak individu, jika ada alasan untuk mengubah kontrak individu, isi alasan tersebut, dll. akan dibahas sesuai kebutuhan, dan item yang telah diputuskan, item yang akan ditinjau lebih lanjut, dan jika ada item yang akan ditinjau lebih lanjut, jadwal tinjauan dan pihak yang akan melakukan tinjauan akan dikonfirmasi.

(Pasal 5, 6, dan 7 dihilangkan.)

Poin utama adalah bahwa keberadaan Dewan Konsultasi memberikan legitimasi tertentu dalam klausa kontrak, dan memberikan makna yang berbeda dari pertemuan yang diadakan secara ad hoc.

Memanfaatkan Rapat Koordinasi untuk Mengelola Perubahan

Selain itu, dalam pengembangan Agile, perubahan pada hal-hal yang telah disepakati oleh kedua belah pihak sejak awal adalah suatu hal yang dianggap sebagai prasyarat. Oleh karena itu, sangat penting untuk mengelola bagaimana situasi perubahan spesifikasi setelahnya.

Jika rapat koordinasi diadakan secara teratur, manajemen perubahan dan cara melakukannya akan menjadi sangat lancar. Misalnya, perubahan dapat dibahas dalam rapat koordinasi, dan jika ada permintaan untuk perubahan dari satu pihak, kewajiban untuk menanggapi diskusi tersebut dapat dimasukkan dalam kontrak. (Berikut adalah kutipan dari ketentuan kontrak model Kementerian Ekonomi, Perdagangan dan Industri Jepang.)

(Prosedur Manajemen Perubahan)

Pasal 37, Pihak A atau B, jika menerima proposal perubahan dari pihak lain (disingkat)…, harus memberikan dokumen tertulis yang mencantumkan hal-hal berikut (selanjutnya disebut “Dokumen Manajemen Perubahan”) kepada pihak lain dalam waktu ○ hari sejak tanggal penerimaan, dan Pihak A dan B akan mendiskusikan apakah perubahan tersebut dapat diterima atau tidak di Rapat Koordinasi sebagaimana ditentukan dalam Pasal 12. (Hal-hal yang harus dicantumkan diabaikan di sini)

Poin penting dari ketentuan di atas dapat diringkas sebagai berikut:

• Metode penerimaan proposal perubahan telah diseragamkan dengan format “Proposal Perubahan”
  
• Ada batas waktu dari penerimaan proposal hingga diskusi tentang hal tersebut → Meskipun tidak perlu ditulis sebagai “dalam waktu ◯ hari”, bisa juga diganti dengan kata-kata seperti “secepatnya”.
  
• Tempat untuk mendiskusikan apakah perubahan dapat diterima atau tidak telah diseragamkan menjadi “Rapat Koordinasi”
  

Dengan kata lain, untuk mencegah perbedaan persepsi seperti “saya telah mengajukan perubahan, atau tidak” atau “saya telah merespon tentang perubahan, atau tidak”, metode prosedur telah dijelaskan.

Pemahaman tentang Kewajiban Kejujuran dan Prinsip Kepercayaan Diperlukan

Sampai sejauh ini, kami telah memperkenalkan model klausul kontrak seperti “Dewan Komunikasi” dan “Diskusi Perubahan”. Namun, hal yang penting untuk pemahaman esensial dari hal-hal tersebut adalah isu-isu seperti “Kewajiban Kejujuran” dan “Prinsip Kepercayaan”. Pada dasarnya, model pengembangan Agile cenderung sulit berjalan tanpa adanya hubungan kepercayaan antara pihak pemesan dan penerima pesanan. Ini karena model ini lebih menekankan pada kecepatan dalam memulai pekerjaan sebenarnya, dan prosedur yang diperlukan untuk memulai biasanya diminimalkan. Oleh karena itu, seringkali dalam praktiknya, klausul yang membebankan “Kewajiban Kejujuran” kepada pihak lain juga dimasukkan.

Pasal 4 Ayat 3: Dalam diskusi perubahan, kedua pihak harus membahas secara jujur tentang objek perubahan, kemungkinan perubahan, dampak perubahan terhadap biaya dan jadwal pengiriman, dan apakah akan melakukan perubahan.

Ini bertujuan untuk mencegah tindakan yang dapat mengkhianati pihak lain dengan argumen hukum yang berbasis pada formalitas, seperti “Apakah akan menyetujui perubahan kontrak atau tidak sepenuhnya tergantung pada kebebasan pihak yang menerima permintaan, dan tidak ada kewajiban untuk mematuhi paksaan”, dalam negosiasi yang telah berjalan berdasarkan hubungan kepercayaan sejak awal. Ini juga mencerminkan prinsip hukum yang berlaku untuk transaksi antara individu, tidak hanya dalam pengembangan sistem.

Pasal 1 Ayat 2 Hukum Sipil Jepang

Pelaksanaan hak dan kewajiban harus dilakukan dengan kepercayaan dan kejujuran.

Hukum tidak selalu menghargai hanya “isi kontrak” atau “frasa pasal” yang berbasis pada formalitas. Terutama dalam transaksi dengan pihak lain, seharusnya digunakan secara fleksibel dengan memasukkan “kepercayaan” dan “kejujuran” yang substansial. Selain itu, kami juga menjelaskan secara detail tentang fakta bahwa “kewajiban” yang diberlakukan oleh hukum tidak selalu didasarkan pada prosedur “kontrak” dalam artikel berikut.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Ringkasan

Dalam proyek pengembangan sistem berdasarkan model pengembangan Agile, tentu saja penting untuk memahami risiko bahwa prosedur administratif dan struktur manajemen menjadi semakin sembrang. Namun, bukan hanya itu, juga penting untuk memahami karakteristik fleksibel yang dimiliki oleh hukum, seperti ‘Prinsip Kepercayaan’, dan sikap untuk memanfaatkannya dalam praktik sehari-hari.