Apa itu Isu Hukum dan Kontrak yang Berhubungan dengan Pembangunan Agile?

Ada metodologi dalam cara memajukan pembangunan sistem. Model air terjun adalah yang paling klasik dan umum, dan banyak buku hukum yang menangani pembangunan sistem juga membahas berdasarkan model ini. Dalam artikel ini, kami akan menjelaskan masalah hukum apa yang ada dalam pembangunan sistem berdasarkan model pembangunan Agile, yang sulit untuk mendapatkan informasi daripada buku dan sumber lainnya.

Model Pembangunan Agile dan Undang-Undang

Apa itu Model dalam Pembangunan Sistem?

Dalam projek pembangunan sistem, terdapat sesuatu yang dikenali sebagai model pembangunan, yang berfungsi sebagai kerangka kerja untuk memahami keseluruhan kemajuan. Contoh utama adalah model ‘Waterfall’. Iaitu, sama seperti air yang jatuh dari ‘hulu’ ke ‘hilir’ sungai, proses seperti definisi keperluan, reka bentuk, pelaksanaan, ujian dan lain-lain dilakukan secara berterusan. Tujuannya adalah untuk mengurangkan sebanyak mungkin kerja yang perlu diulang dan merupakan cara yang sesuai untuk menjalankan kerja secara terancang.

Sebaliknya, dalam model pembangunan Agile, program kecil dilaksanakan dan diuji secara berulang. Dalam proses kerja berulang ini, sistem yang lebih besar dibina secara beransur-ansur. Untuk penjelasan lebih terperinci tentang model pembangunan sistem ini dan perbandingan kelebihan dan kekurangan kedua-dua model pembangunan, sila rujuk artikel di bawah.

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

Ciri-ciri Model Pembangunan Agile

Kelebihan besar pembangunan menggunakan model Agile adalah keupayaan untuk memulakan kerja sebenar dengan cepat. Kerana kerja ‘hulu’ seperti definisi keperluan dan pembuatan reka bentuk, dan kerja pelaksanaan program tidak dipisahkan, ia sesuai untuk mengendalikan perubahan seperti penambahan fungsi, pembetulan, perubahan spesifikasi dan lain-lain dengan fleksibel. Dari segi undang-undang, aspek yang sangat penting untuk menjadikan model pembangunan Agile berjaya adalah bagaimana pengurusan dokumen dan pengurusan perubahan dilakukan. Dalam model pembangunan Agile, peranan dan tanggungjawab tidak dibahagikan dengan jelas seperti dalam model Waterfall. Selain itu, kerana ia adalah kaedah yang menekankan ‘kecepatan’ untuk melaksanakan dan memulakan kerja, bukan ‘pengurusan’, ia cenderung menyebabkan kekurangan dalam dokumen reka bentuk, spesifikasi, minit mesyuarat dan lain-lain.

Lebih lanjut berkenaan pengurusan perubahan, kerana model pembangunan Agile membolehkan penyesuaian terhadap perubahan dengan lancar, terdapat risiko bahawa projek mungkin terbakar apabila proses kelulusan kepada pengambil keputusan dilangkau dan permintaan perubahan spesifikasi di tempat kerja dijawab. Jika ini berlaku, kelebihan model pembangunan yang ‘membolehkan penyesuaian terhadap perubahan dengan lancar’ boleh menjadi risiko pembakaran projek itu sendiri.

Cara Pengurusan Dokumen dan Pengurusan Perubahan dalam Pembangunan Agile

Kepentingan Pengurusan Dokumen

Dalam projek pembangunan berdasarkan model pembangunan Agile, isu yang menjadi kebimbangan dari segi undang-undang adalah penumpuan komunikasi secara lisan, yang mengakibatkan kekurangan dokumen. Mengenai isu ini, kami telah menjelaskan secara terperinci mengapa pengurusan dokumen menjadi penting dalam projek pembangunan sistem dalam artikel berikut.

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

Dalam artikel tersebut, kami menjelaskan kepentingan pengurusan dokumen dalam projek pembangunan sistem dari dua perspektif, iaitu pencegahan konflik sebelum berlaku (iaitu ‘pengurusan risiko’) dan pemeliharaan bukti apabila konflik berlaku (iaitu ‘pengurusan krisis’).

Pemasangan Majlis Perundingan Hubungan Efektif untuk Pengurusan Dokumen

Jika anda mengamalkan model pembangunan Agile, berbeza dengan model Waterfall, tidak ada rancangan yang jelas yang disediakan terlebih dahulu. Oleh itu, bukan hanya menguruskan perbezaan antara rancangan dan hasil sebenar, tetapi juga ada kebimbangan bahawa kos akan meningkat secara drastik dalam segi kewangan dan masa jika dibiarkan kepada pihak lapangan.

Oleh itu, langkah yang efektif adalah untuk memastikan pengurus menjalankan majlis perundingan hubungan secara berkala untuk memastikan kelancaran projek. Jika skala pembangunan adalah kecil, memang benar, cara yang lebih disukai adalah untuk berkumpul secara beransur-ansur antara pengurus daripada mengadakan majlis perundingan hubungan secara berkala. Walau bagaimanapun, dalam kes model pembangunan Agile, risiko untuk tidak menangani isu yang tepat pada masanya dalam mesyuarat juga cenderung meningkat. Oleh itu, adalah selamat untuk menggabungkan pengadakan majlis perundingan hubungan secara berkala dalam kontrak dan sebagainya. Cara yang ditetapkan adalah seperti yang ditunjukkan dalam kontrak model Kementerian Ekonomi, Perdagangan dan Industri (METI) Jepun seperti berikut:

(Pemasangan Majlis Perundingan Hubungan)

Klausa 12: Pihak A dan B akan mengadakan Majlis Perundingan Hubungan untuk membincangkan perkara-perkara yang diperlukan untuk memastikan pelaksanaan kerja ini dengan lancar, termasuk kemajuan kerja, pengurusan dan pelaporan risiko, kerja sama antara kedua-dua pihak dan pelaksanaan kerja yang dibahagikan, pengesahan kandungan yang harus dimasukkan dalam spesifikasi sistem, dan penyelesaian isu, sehingga kerja ini selesai. Walau bagaimanapun, (disingkat).

2. Majlis Perundingan Hubungan akan diadakan secara berkala pada frekuensi yang ditentukan dalam kontrak individu sebagai prinsip, dan di samping itu, akan diadakan sewaktu-waktu apabila Pihak A atau B menganggap perlu.

3. Pengurus dan pegawai bertanggungjawab utama dari kedua-dua pihak, dan orang-orang yang dianggap sesuai oleh pengurus akan hadir di Majlis Perundingan Hubungan. Selain itu, Pihak A dan B boleh meminta pihak lain untuk menghadirkan orang yang diperlukan untuk perbincangan di Majlis Perundingan Hubungan, dan pihak lain harus mematuhi kecuali ada alasan yang munasabah.

4. Pihak B akan membuat dan mengemukakan laporan pengurusan kemajuan mengikut format yang telah dipersetujui antara Pihak A dan B di Majlis Perundingan Hubungan, dan akan mengesahkan kemajuan berdasarkan laporan pengurusan kemajuan tersebut, serta membincangkan dan menentukan perkara-perkara seperti keberadaan item yang tertunggak, alasan dan langkah-langkah jika ada item yang tertunggak, keperluan untuk mengubah struktur promosi yang ditentukan dalam bab ini (pertukaran staf, penambahan atau pengurangan, perubahan kontraktor semula, dll.), status pelaksanaan langkah-langkah keselamatan, keberadaan sebab-sebab yang memerlukan perubahan kontrak individu, dan kandungan jika ada sebab-sebab yang memerlukan perubahan kontrak individu, dan akan mengesahkan item yang telah diputuskan, item yang perlu dipertimbangkan selanjutnya, dan jadual dan pihak yang akan mempertimbangkan jika ada item yang perlu dipertimbangkan selanjutnya. 

(Klausa 5, 6, dan 7 diabaikan.)

Poin utama adalah memberikan keabsahan tertentu kepada klausa kontrak untuk keberadaan Majlis Perundingan Hubungan dan memberikan makna yang berbeza daripada mesyuarat yang diadakan secara spontan.

Merangka Penggunaan Mesyuarat Perhubungan untuk Pengurusan Perubahan

Selain itu, dalam pembangunan Agile, adalah asas bahawa perkara yang kedua-dua pihak bersetuju pada awalnya boleh berubah kemudian. Oleh itu, bagaimana menguruskan situasi perubahan spesifikasi selepas itu juga sangat penting.

Sekiranya mesyuarat perhubungan diadakan secara berkala, pengurusan perubahan dan cara melaksanakannya juga akan menjadi sangat lancar. Sebagai contoh, perbincangan perubahan akan diadakan di Mesyuarat Perhubungan, dan jika ada permintaan untuk perbincangan perubahan dari satu pihak, kewajipan untuk mematuhi perbincangan tersebut akan dimasukkan dalam kontrak. (Berikut adalah petikan dari peraturan kontrak model Kementerian Ekonomi, Perdagangan dan Industri Jepun.)

(Prosedur Pengurusan Perubahan)

Perkara 37, Pihak A atau B, apabila menerima cadangan perubahan berdasarkan (omitted) dari pihak lain, dalam masa ○ hari dari tarikh penerimaan, akan memberikan dokumen bertulis (selanjutnya dikenali sebagai “Dokumen Pengurusan Perubahan”) yang mencatat perkara-perkara berikut kepada pihak lain, dan Pihak A dan B akan berbincang tentang sama ada perubahan tersebut boleh diterima atau tidak di Mesyuarat Perhubungan seperti yang ditentukan dalam Perkara 12. (Perkara-perkara yang dicatat ditinggalkan)

Titik utama peraturan di atas boleh diringkaskan seperti berikut:

• Menyatukan cara menerima permintaan perubahan dengan format “Cadangan Perubahan”
  
• Membatasi tarikh dari penerimaan cadangan hingga perbincangan tentangnya → Walaupun tidak perlu ditulis sebagai “dalam masa ◯ hari”, ia juga boleh digantikan dengan kata-kata seperti “secepat mungkin”.
  
• Menyatukan tempat untuk berbincang tentang sama ada perubahan boleh diterima atau tidak ke “Mesyuarat Perhubungan”
  

Dengan kata lain, prosedur ini menjelaskan cara untuk mengelakkan kekeliruan persepsi seperti “saya telah membuat permintaan perubahan, atau tidak” dan “saya telah menjawab sama ada perubahan boleh diterima atau tidak, atau tidak” berdasarkan percakapan lisan.

Pemahaman terhadap Kewajipan Kejujuran dan Prinsip Kepercayaan Ditanya

Sehingga kini, kami telah memperkenalkan model klausa kontrak seperti ‘Majlis Perhubungan’, ‘Perbincangan Perubahan’ dan sebagainya. Namun, perkara penting untuk memahami hakikat mereka adalah isu-isu seperti ‘Kewajipan Kejujuran’ dan ‘Prinsip Kepercayaan’. Model pembangunan Agile pada asasnya memerlukan hubungan kepercayaan antara pihak yang membuat pesanan dan pihak yang menerima pesanan, jika tidak, prosesnya mungkin sukar. Ini kerana ia menekankan kecepatan memulakan kerja sebenar, dan prosedur yang diperlukan untuk memulakan kerja biasanya dikurangkan seminimum mungkin. Oleh itu, dalam praktik, seringkali termasuk klausa yang membebankan ‘Kewajipan Kejujuran’ kepada pihak lain.

Perenggan 3 Artikel 4: Dalam perbincangan perubahan, kedua-dua pihak harus berbincang dengan jujur tentang objek perubahan, kemungkinan perubahan, kesan perubahan terhadap harga dan tarikh penghantaran, dan sama ada untuk membuat perubahan.

Ini bertujuan untuk mencegah tindakan yang mengkhianati pihak lain dengan hujah undang-undang yang berdasarkan formaliti, seperti ‘Sama ada untuk bersetuju dengan perubahan kontrak adalah sepenuhnya bebas bagi pihak yang menerima tawaran, dan tidak ada kewajipan untuk mematuhi paksaan’, dalam rundingan yang telah berjalan berdasarkan hubungan kepercayaan awal. Ini juga mencerminkan prinsip undang-undang yang berkaitan dengan transaksi antara individu, tidak terhad kepada pembangunan sistem.

Perenggan 2 Artikel 1 Undang-Undang Sivil Jepun (Japanese Civil Code)

Pelaksanaan hak dan pemenuhan kewajipan harus dilakukan dengan kepercayaan dan kejujuran.

Undang-undang tidak semestinya menekankan hanya pada ‘kandungan kontrak’ atau ‘bahasa klausa’ yang berdasarkan formaliti. Terutamanya dalam transaksi dengan pihak lain, ia juga harus digunakan dengan fleksibiliti sambil memasukkan ‘kepercayaan’ dan ‘kejujuran’ yang substantif. Selain itu, kami telah memberikan penjelasan terperinci dalam artikel berikut tentang hakikat bahawa ‘kewajipan’ yang dikenakan oleh undang-undang tidak semestinya berdasarkan prosedur ‘kontrak’.

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

Ringkasan

Dalam projek pembangunan sistem berdasarkan model pembangunan Agile, tentunya penting untuk memahami risiko prosedur dan struktur pengurusan menjadi semakin longgar. Namun, bukan itu sahaja, memahami ciri-ciri fleksibel asal undang-undang yang berakar pada prinsip-prinsip seperti ‘Prinsip Kepercayaan’, dan sikap untuk memanfaatkannya dalam praktik juga dianggap penting.