Kontrak Agile dalam hukum TI: kontrol hukum atas cara kerja yang fleksibel.

Pengembangan perangkat lunak Agile terasa janggal jika dipadukan dengan kontrak yang menetapkan hasil akhir, ruang lingkup tugas, dan tanggal pengiriman di muka. Dalam proyek Agile, para pihak bekerja dalam sprint pendek, yaitu periode kerja yang telah ditentukan, dan isi produk disesuaikan seiring berjalannya proyek.

Hal itu menawarkan fleksibilitas, tetapi juga menimbulkan pertanyaan hukum. Siapa yang menetapkan prioritas? Kapan hasil sprint diterima? Dan kapan keterlambatan pengiriman mengakibatkan wanprestasi? Artikel ini menjelaskan bagaimana para pihak dapat menjawab pertanyaan-pertanyaan ini secara kontraktual.

Yang dimaksud dengan kontrak tangkas, dalam uraian selanjutnya, adalah serangkaian kesepakatan yang digunakan para pihak untuk mencatat kolaborasi yang tangkas. Dalam praktiknya, kolaborasi tersebut berbentuk perjanjian kerangka kerja dengan perjanjian implementasi terpisah untuk setiap tugas.

Kerja dan kontrak yang tangkas

Dalam proyek TI tradisional, para pihak menetapkan desain fungsional dan teknis terlebih dahulu. Kemudian, pemasok berjanji untuk memberikan hasil tersebut pada waktu tertentu. Dalam pengembangan agile, tujuan tetap tersebut sengaja dihilangkan: hasilnya adalah tujuan yang terus berubah.

Setiap sprint menghasilkan bagian perangkat lunak yang berfungsi dan dapat digunakan. Berdasarkan demonstrasi dan pengalaman pengguna, klien menyesuaikan arah pengembangan. Jika kontrak tradisional mencatat di mana proyek berakhir, dalam metode kerja agile hal itu tetap terbuka.

Oleh karena itu, para pihak harus menyelesaikan secara kontraktual apa yang biasanya sudah ditunjukkan dalam spesifikasi proyek tradisional. Empat hal yang menonjol adalah:

• Siapa yang menentukan spesifikasi, yaitu, siapa yang memenuhi peran pemilik produk (orang yang menetapkan prioritas atas nama klien);
• bagaimana perubahan diproses ke dalam backlog (daftar prioritas fungsionalitas yang masih harus dibangun), perencanaan, dan harga;
• ketika suatu komponen dianggap selesai, berdasarkan definisi selesai (kriteria yang disepakati untuk hasil akhir) dan kriteria penerimaan (persyaratan yang digunakan untuk menguji suatu pengiriman);
• apakah tanggal pengiriman yang disepakati bersifat pasti atau hanya perkiraan.

Salah satu konsekuensi praktisnya: metode kerja agile sulit dikombinasikan dengan tender di mana ruang lingkup tugas ditetapkan sepenuhnya di muka. Pihak yang tunduk pada aturan pengadaan tetapi tetap menginginkan pengembangan agile disarankan untuk membuat ruang dalam dokumen tender untuk perjanjian kerangka kerja dengan tugas implementasi yang didefinisikan secara fleksibel.

Upaya terbaik atau kewajiban hasil?

Dalam kewajiban upaya terbaik, pemasok tidak menjamin hasil tertentu. Pemasok berjanji untuk menerapkan kehati-hatian yang dapat diharapkan dari seorang profesional yang kompeten dan bertindak secara wajar. Dalam kewajiban hasil, pemasok berkomitmen pada hasil yang dijelaskan secara spesifik.

Label dalam kontrak bukanlah hal yang menentukan. Bahkan jika kontrak merujuk pada kewajiban hasil, pengadilan dapat memutuskan, berdasarkan substansi kesepakatan dan konteksnya, bahwa itu sebenarnya adalah kewajiban upaya terbaik, dan sebaliknya. Oleh karena itu, bagaimana para pihak benar-benar bekerja sama setidaknya sama pentingnya dengan kata-kata yang dipilih.

Perbedaan ini penting dalam praktik karena dalam kewajiban hasil, hasil yang disepakati adalah hal yang utama, sedangkan dalam kewajiban upaya terbaik, harus dinilai apakah pemasok telah mengerahkan upaya yang dibutuhkan. Perbedaan tersebut menentukan apa yang diperdebatkan para pihak dalam suatu sengketa dan apa yang harus mereka buktikan.

Dua ketentuan hukum muncul kembali di sini. Pasal 6:74(1) Kitab Undang-Undang Hukum Perdata Belanda memberikan dasar untuk ganti rugi atas kegagalan pelaksanaan yang dapat diatribusikan. Namun, pasal tersebut tidak menyebutkan kapan terjadi kegagalan; hal itu bergantung pada kualifikasi kewajiban dan isi perjanjian. Pasal 6:248 menyatakan bahwa suatu kontrak juga memiliki konsekuensi yang timbul dari kewajaran dan keadilan. Hal itu memberikan ruang untuk mempertimbangkan sifat kolaborasi yang lincah ketika menafsirkan kewajiban para pihak.

Dasar kontraktual: kerangka kerja dan perjanjian pelaksanaannya

Dalam praktiknya, kolaborasi agile dicatat secara berlapis. Sebuah perjanjian kerangka kerja mengatur kerangka umum: ketentuan yang berlaku, tanggung jawab, kerahasiaan, dan cara kerja sama.

Untuk setiap penugasan, para pihak menyepakati perjanjian pelaksanaan yang menetapkan ruang lingkup, perencanaan, komposisi tim, harga, dan kriteria penerimaan untuk bagian tersebut. Dengan demikian, hubungan hukum tetap stabil sementara substansi dapat berubah seiring dengan setiap sprint atau rilis.

Tanpa kriteria penerimaan yang jelas, tidak ada catatan tentang apa yang harus diuji terhadap hasil tersebut. Perselisihan tentang apakah sprint berhasil atau tidak kemudian lebih mudah muncul. Oleh karena itu, kriteria penerimaan yang konkret dan terukur per sprint lebih penting daripada label yang diberikan para pihak pada kewajiban tersebut.

Salah satu hal yang perlu mendapat perhatian lebih dalam kontrak agile dibandingkan kontrak TI tradisional adalah penghentian dini. Karena proyek agile merupakan serangkaian sprint berturut-turut tanpa titik akhir yang tetap, kontrak harus mengatur kapan suatu pihak dapat berhenti, apa yang terjadi pada komponen dan kode sumber yang telah dikirimkan, dan bagaimana proses transfer ke pemasok lain berlangsung.

Syarat dan ketentuan umum juga penting di sini. Syarat dan Ketentuan NLdigital 2025 menggantikan edisi 2020, menambahkan bab tentang kepatuhan, keamanan siber, berbagi data, kecerdasan buatan, dan platform daring, di antara lainnya. Syarat dan ketentuan 2020 tetap berlaku jika para pihak menyetujuinya, jadi periksa versi mana yang berlaku untuk kontrak Anda. Syarat dan ketentuan tersebut hanya membahas aspek-aspek spesifik Agile secara terbatas; aspek-aspek tersebut harus diselesaikan oleh para pihak dalam perjanjian pelaksanaannya.

Yurisprudensi tentang tenggat waktu dan kerja sama

Yurisprudensi menunjukkan tidak ada aturan umum bahwa tanggal pengiriman yang fleksibel tidak pernah bisa bersifat ketat. Kualifikasi tersebut bergantung pada isi kontrak, metode kerja yang dipilih, dan kerja sama aktual para pihak. Tiga kasus mengilustrasikan hal ini.

Pengadilan Distrik Midden-Nederland, 26 Juli 2023 (ECLI:NL:RBMNE:2023:5936). Pemasok IPS mengembangkan perangkat lunak timbangan menggunakan Scrum untuk klien Synergy. Kontrak tersebut merujuk pada waktu tunggu sekitar 24 minggu. Waktu tersebut tidak terpenuhi; tenggat waktu baru ditunda dan terlewat lagi. Ketika, pada pertengahan Desember 2020, sembilan dari sepuluh blok mingguan yang disepakati telah diselesaikan, Synergy membatalkan kontrak. Pengadilan memutuskan bahwa waktu tunggu yang dijanjikan memang dianggap sebagai tenggat waktu yang ketat, sehingga terjadi wanprestasi. Namun, pembatalan tersebut tidak berlaku: mengingat sifat kolaborasi, di mana pengaturan baru dibuat ketika tenggat waktu terlewat, dan mengingat bahwa proyek hampir selesai, wanprestasi tersebut tidak membenarkan pembatalan. Signifikansi praktis: bahkan dalam kolaborasi tangkas, waktu tunggu yang dijanjikan dapat bersifat ketat, tetapi wanprestasi tidak secara otomatis membuat pembatalan menjadi sah.

Pengadilan Distrik Amsterdam, 22 April 2026 (ECLI:NL:RBAMS:2026:3930). Seorang klien menuduh pengembang DTT telah mengirimkan aplikasi seluler baru terlambat, melebihi biaya yang dianggarkan, dan melakukan pemeliharaan pada aplikasi yang sudah ada secara tidak memadai. Pengadilan menolak semua klaim. Tidak ada tenggat waktu yang ketat: tanggal pengiriman yang disebutkan dalam penawaran dan dalam korespondensi harus dilihat sebagai kewajiban upaya terbaik dalam metode kerja agile atau scrum, di mana fleksibilitas dan wawasan yang berkembang menjadi pusatnya. Signifikansi praktis: pihak yang menginginkan tanggal yang ketat harus mencatatnya secara eksplisit; tanggal dalam penawaran saja tidak cukup.

Amsterdam Pengadilan Banding, dalam kasus antara On Air dan Triple IT. Para pihak telah sepakat untuk bekerja secara agile atau scrum tanpa mendefinisikan hasil akhir. Dalam konteks itu, kewajibannya hampir sama dengan menyediakan pengembang yang kompeten yang bekerja sesuai dengan desain dan kewajiban untuk berhati-hati sebagai kontraktor yang teliti. Jika apa yang diberikan tidak sesuai, upaya untuk membuatnya sesuai pada prinsipnya merupakan pekerjaan tambahan. Hal itu mungkin berbeda jika pemasok tidak mematuhi kesepakatan atau kewajibannya untuk berhati-hati, tetapi beban pembuktian terletak pada klien. Fakta bahwa kinerja produk akhir tidak memenuhi keinginan klien saja tidak cukup untuk membuktikan kegagalan. Dalam persidangan ini, pengadilan juga menunjuk seorang ahli TI untuk menjelaskan istilah-istilah seperti scrum master, sprint, dan selesai. Signifikansi praktis: jika hasil akhir yang didefinisikan tidak ada, pekerjaan perbaikan dengan mudah menjadi tanggung jawab klien.

Dalam menilai klaim pembatalan, pengadilan dapat mempertimbangkan peran masing-masing pihak dalam keterlambatan dan pelaksanaan proyek. Pihak yang tidak ingin bergantung pada pertimbangan tersebut dalam kasus individual harus mencatat sendiri kapan tenggat waktu bersifat ketat dan kapan penghentian dini dimungkinkan.

Delapan poin yang perlu dibahas dalam kontrak.

Pertimbangkan poin-poin berikut saat menyusun kontrak agile. Untuk setiap pokok bahasan, rumuskan jawaban atas pertanyaan yang menyertainya.

• Cakupan: fungsi mana yang termasuk dalam sprint, dan apa yang secara tegas berada di luar sprint?
• Prioritas: siapa yang berwenang mengubah backlog, dan apakah orang tersebut memiliki mandat untuk melakukannya atas nama klien?
• Penerimaan: dalam jangka waktu berapa lama klien harus melakukan pengujian dan memberikan tanggapan, dan apa yang berlaku jika klien tidak melakukannya?
• Batas waktu: apakah tanggal yang disebutkan bersifat indikatif atau mutlak, dan apakah kontrak tersebut menyatakannya secara eksplisit?
• Harga: apakah pembayaran per sprint, per function point, per jam kerja atau per hasil?
• Kepemilikan dan penggunaan: pada saat apa klien memperoleh akses ke kode sumber dan dokumentasi?
• Pemutusan hubungan kerja: apa yang dialihkan pada pemutusan hubungan kerja lebih awal, dan dengan pembayaran apa?
• Kontinuitas: dapatkah pemasok lain melanjutkan pekerjaan, dan dokumentasi serta transferabilitas kode apa yang dibutuhkan untuk itu?

Sertakan juga definisi "selesai" yang tidak hanya fungsional tetapi juga menetapkan persyaratan terkait kualitas, dokumentasi, dan kemampuan transfer kode. Jika tidak, perselisihan tentang apakah pekerjaan yang diserahkan dapat digunakan atau tidak akan tetap muncul pada saat pengakhiran kontrak.

Kesimpulan

Pendekatan kerja Agile menawarkan fleksibilitas, tetapi membutuhkan kontrak yang berbeda secara mendasar dari model tradisional. Perbedaan antara kewajiban upaya terbaik dan kewajiban hasil, kriteria penerimaan yang jelas, dan pengaturan untuk pengakhiran dini sangat menentukan. Kasus-kasus yang dibahas menunjukkan bahwa hasilnya sangat bergantung pada pengaturan spesifik dan kerja sama yang sebenarnya. Kontrak yang membahas poin-poin ini lebih sesuai dengan cara para pihak benar-benar bekerja dan mengurangi risiko perselisihan.

Law & More Kami membantu pemasok dan klien TI dalam menyusun, meninjau, dan menegosiasikan kerangka kerja dan perjanjian implementasi, serta memberikan saran tentang kualifikasi kewajiban, kriteria penerimaan, dan pengaturan penghentian. Apakah Anda menghadapi perselisihan tentang keterlambatan, hasil, atau penghentian proyek agile? Jangan ragu untuk menghubungi kami untuk mendapatkan saran yang sesuai dengan kebutuhan Anda.

Pertanyaan yang sering diajukan

Di bawah ini kami menjawab pertanyaan-pertanyaan yang paling sering diajukan kepada kami mengenai topik ini.

Apa itu kontrak agile?

Serangkaian kesepakatan yang digunakan para pihak untuk mencatat kolaborasi yang lincah. Dalam praktiknya, kesepakatan ini terdiri dari perjanjian kerangka kerja yang menetapkan kerangka umum, dengan perjanjian implementasi untuk setiap tugas yang mencakup ruang lingkup, perencanaan, harga, dan kriteria penerimaan untuk bagian tersebut.

Apakah tanggal pengiriman dalam proyek agile merupakan tenggat waktu yang ketat?

Tidak secara otomatis. Tidak ada aturan umum; itu tergantung pada kontrak, metode kerja, dan kerja sama yang sebenarnya. Jika Anda menginginkan tanggal yang pasti, catatlah secara eksplisit. Tanggal dalam penawaran dianggap tidak cukup.

Apa perbedaan antara kewajiban upaya terbaik dan kewajiban hasil?

Dalam kewajiban hasil, hasil yang disepakati adalah hal yang utama. Dalam kewajiban upaya terbaik, harus dinilai apakah pemasok telah mengerahkan upaya yang dibutuhkan. Perbedaan itulah yang menentukan apa yang diperdebatkan para pihak dalam suatu sengketa.

Apakah label dalam kontrak tersebut menjadi penentu?

Tidak. Bahkan jika kontrak merujuk pada kewajiban hasil, pengadilan dapat memutuskan berdasarkan substansi dan konteksnya bahwa itu sebenarnya adalah kewajiban upaya terbaik, dan sebaliknya. Bagaimana para pihak benar-benar bekerja memiliki bobot yang sama pentingnya.

Siapa yang berwenang mengubah daftar antrian?

Orang yang menjalankan peran sebagai pemilik produk. Catat siapa orang tersebut dan apakah mereka memiliki mandat untuk melakukannya atas nama klien. Tanpa pengaturan tersebut, akan timbul perselisihan tentang siapa yang bertanggung jawab atas perubahan prioritas.

Mengapa kriteria penerimaan sangat penting?

Tanpa kriteria penerimaan yang jelas, tidak ada catatan tentang apa yang harus diuji terhadap hasil tersebut. Perselisihan tentang apakah sprint berhasil atau tidak kemudian lebih mudah muncul. Dalam praktiknya, hal itu lebih penting daripada label yang melekat pada kewajiban tersebut.

Siapa yang membayar biaya perbaikan jika pengiriman tidak sesuai?

Jika hasil akhir belum ditentukan, upaya untuk memenuhi keinginan klien pada prinsipnya menjadi tanggung jawab klien sebagai pekerjaan tambahan. Hal ini berbeda jika pemasok tidak mematuhi kesepakatan atau kewajiban kehati-hatiannya, tetapi beban pembuktian terletak pada klien.

Bagaimana pengaturan pembayaran dalam metode kerja agile?

Mengaitkan pembayaran dengan satu momen pengiriman tetap kurang tepat untuk metode yang tidak memiliki hasil akhir tetap. Alternatif umum adalah pembayaran per sprint, per function point, atau per jam kerja. Catat dasar pembayaran yang dipilih secara eksplisit.

Bisakah saya menggabungkan metode kerja agile dengan tender publik?

Hal itu memerlukan pendekatan yang disesuaikan, karena tender dengan ruang lingkup yang sepenuhnya tetap mengasumsikan hasil yang diketahui sebelumnya. Berikan ruang dalam dokumen tender untuk perjanjian kerangka kerja dengan tugas implementasi yang didefinisikan secara fleksibel.

Apa yang perlu saya atur terkait penghentian kontrak kerja lebih awal?

Dengan syarat apa suatu pihak dapat menghentikan pekerjaan, apa yang terjadi pada komponen dan kode sumber yang telah dikirimkan, dengan imbalan apa transfer pembayaran dilakukan, dan apa yang dibutuhkan pemasok lain untuk melanjutkan pekerjaan.

Apakah Persyaratan NLdigital 2025 memberikan panduan yang memadai?

Hanya sampai batas tertentu. Dokumen ini menggantikan edisi 2020 dan menambahkan bab tentang kepatuhan, keamanan siber, berbagi data, kecerdasan buatan, dan platform daring, antara lain, tetapi tidak membahas aspek-aspek spesifik dari metodologi Agile. Ketentuan tahun 2020 tetap berlaku di tempat yang telah disepakati. Ketentuan tersebut harus Anda atur sendiri dalam perjanjian pelaksanaannya.

Apakah Anda memiliki perselisihan dengan pemasok TI, atau ingin kontrak TI Anda ditinjau? Pengacara TI kami siap membantu.

Seterpercayaapakah Olymp Trade? Kesimpulan Law & More Yang dapat membantu Anda dalam hal ini dijelaskan di halaman kami. Pengacara TI .