Agile гэрээ нь эцсийн үр дүнг урьдчилан тогтоогоогүй хамтын ажиллагааг бүртгэдэг тул хэн тэргүүлэх чиглэлийг тогтоох, спринт үр дүнг хэзээ хүлээн авах, хүргэх огноо нь заавал дагаж мөрдөх эсэхийг зохицуулах ёстой. Нидерландын хуулийн дагуу agile төслийн хүргэх огноо нь автоматаар хатуу хугацаа биш юм: шүүх гэрээ, ажлын арга барил, талууд хэрхэн хамтран ажилласныг хардаг бөгөөд хатуу хугацаа алдсан ч гэсэн гэрээг цуцлах үндэслэл болдоггүй.
Agile хөгжүүлэлтийн үед талууд богино хугацаанд ажиллаж, төсөл урагшлахын хэрээр бүтээгдэхүүнийг тохируулдаг. Энэ нийтлэлд нийлүүлэгчийн үүргийг хэрхэн хангах, гэрээг хэрхэн бүтцээр нь байгуулах, сүүлийн үеийн шүүхийн практикт хугацаа дуусах талаар юу гэж заасан, үйлчлүүлэгчид болон нийлүүлэгчид юуг шалгах ёстойг тайлбарласан болно.
Агуулгын хүснэгт
Яагаад agile working-д өөр гэрээ хэрэгтэй вэ?
Учир нь үр дүн нь хөдөлж буй бай болдог. Уламжлалт мэдээллийн технологийн төсөлд талууд функциональ болон техникийн загварыг тогтоодог бөгөөд нийлүүлэгч нь тогтоосон хугацаанд хүргэхээ амладаг; agile хөгжүүлэлтийн үед спринт бүр ажлын хэсгийг нийлүүлдэг бөгөөд үйлчлүүлэгч нь үзүүлэнгийн үндсэн дээр чиглэлээ тохируулдаг.
Тиймээс гэрээ нь уламжлалт тодорхойлолт өөрөө хариулдаг дөрвөн асуудлыг шийдвэрлэх ёстой:
- техникийн тодорхойлолт болон тэргүүлэх чиглэлийг хэн тодорхойлдог вэ: үйлчлүүлэгчийн талын бүтээгдэхүүний эзэмшигч;
- өөрчлөлтүүдийг хэрхэн боловсруулдаг вэ (бэлтгэх ёстой функцүүдийн тэргүүлэх жагсаалт), төлөвлөлт болон үнэ;
- дууссаны тодорхойлолт болон хэмжигдэхүйц хүлээн авах шалгуурт үндэслэн эд ангийг дууссан гэж тооцох үед;
- тохиролцсон хүргэлтийн огноо нь хатуу эсвэл заалттай эсэх.
Чадварлаг ажлыг хамрах хүрээг урьдчилан бүрэн тогтоосон олон нийтийн тендертэй хослуулахад хэцүү байдаг. Чадварлаг хөгжлийг хүсч буй гэрээт байгууллага нь уян хатан тодорхойлсон захиалгат даалгавар бүхий хүрээний гэрээнд зориулж тендерийн баримт бичигт зай үлдээх хэрэгтэй.
Энэ нь хамгийн сайн хүчин чармайлт уу эсвэл үр дүнгийн үүрэг үү?
Чадварлаг төслүүдэд нийлүүлэгчийн үүрэг хариуцлагыг ихэвчлэн хамгийн сайн хүчин чармайлтын үүрэг хариуцлага (inspanningsverbintenis) гэж ангилдаг, учир нь тодорхой эцсийн үр дүнд тохиролцоо хийгдээгүй байдаг. Үр дүнгийн үүрэг хариуцлагын (resultatsverbintenis) дагуу нийлүүлэгч нь тодорхой тайлбарласан үр дүнг амладаг.
Гэрээний шошго нь шийдвэрлэх хүчин зүйл биш юм: шүүх нь тохиролцооны агуулга болон талууд хэрхэн ажилласныг хардаг. Үр дүнгийн үүргийн дагуу үр дүн гарсан эсэх, хамгийн сайн хүчин чармайлтын үүргийн дагуу нийлүүлэгч нь боломжийн чадавхтай, боломжийн үүрэг гүйцэтгэгч мэдээллийн технологийн мэргэжилтний тусламж үйлчилгээг үзүүлсэн эсэх нь асуулт юм.
Нидерландын Иргэний хуулийн (BW) 6:74(1) зүйлд үүргээ биелүүлээгүйгээс үүдэлтэй хохирлыг барагдуулах үндэслэл болдог боловч хэзээ алдаа гарсан тухай заагаагүй; энэ нь үүргийн шаардлагаас хамаарна. BW-ийн 6:248(1) зүйлийн дагуу гэрээ нь мөн боломжийн болон шударга байдлаас үүдэлтэй үр дагавартай байдаг бөгөөд энэ нь хамтын ажиллагааны уян хатан шинж чанарыг харгалзан үзэх боломжийг олгодог.
Та уян хатан гэрээг хэрхэн бүтэцлэдэг вэ?
Ихэвчлэн хоёр давхаргатай байдаг. Хүрээний гэрээ нь ерөнхий дүрмийг тогтоодог: холбогдох нөхцөл, хариуцлага, нууцлал, оюуны өмч болон хамтран ажиллах арга зам. Даалгавар эсвэл чөлөөлөлт бүрийн хувьд хэрэгжүүлэх гэрээ нь цар хүрээ, төлөвлөлт, баг, үнэ болон хүлээн авах шалгуурыг тогтоодог.
Спринт бүрт тодорхой, хэмжигдэхүйц хүлээн авах шалгуур нь үүргийн шошгоноос илүү чухал юм. Тэдгээргүйгээр үр дүнг шалгах зүйл байхгүй бөгөөд спринт амжилттай болсон эсэх талаар маргаан хурдан үүсдэг. Зөвхөн функциональ байдал төдийгүй кодын чанар, баримтжуулалт, дамжуулах чадварыг хамарсан хийгдсэн гэсэн тодорхойлолтыг оруулна уу.
Ачаалалтай төсөл нь тогтсон төгсгөлийн цэггүй тул уламжлалт гэрээнээс илүү эрт цуцлах нь илүү анхаарал татах ёстой. Талууд хэзээ зогсох, хүргэгдсэн бүрэлдэхүүн хэсэг болон эх кодод юу тохиолдох, ажлыг өөр нийлүүлэгчид хэрхэн шилжүүлэх талаар тохиролцоно уу.
NLdigital Terms гэх мэт стандарт мэдээллийн технологийн нэр томьёо нь agile талуудыг зөвхөн хязгаарлагдмал хэмжээгээр зохицуулдаг. Аль хэвлэл хамаарахыг шалгаж, agile зохицуулалтыг хэрэгжүүлэх гэрээнд тэмдэглэнэ үү.
Хугацааны талаар шүүхийн практикт юу гэж заасан байдаг вэ?
Агилай төслийн огноо хэзээ ч хатуу байдаггүй гэсэн ерөнхий дүрэм байдаггүй. Саяхны хоёр шийдвэрээс харахад шүүх гэрээ болон хамтын ажиллагааг хэрхэн үнэлдэг болохыг харж болно.
Мидден-Нидерландын дүүргийн шүүх, 2023 он: хатуу хугацаатай боловч хэрэгсэхгүй болгохгүй
ECLI:NL:RBMNE:2023:5936-тай хийсэн шүүхийн шийдвэрт жинлэлтийн системийн програм хангамжийг scrum ашиглан боловсруулсан бөгөөд тохиролцсон хугацаа нь ойролцоогоор 24 долоо хоног бөгөөд дараа нь хуанлийн огноог тогтоосон. Шүүх эдгээр огноог хатуу хугацаа гэж үзсэн тул нийлүүлэгч хугацаа нь дууссан үед мэдэгдэлгүйгээр гэрээгээ цуцалсан гэж үзсэн.
Гэсэн хэдий ч үйлчлүүлэгчийн гэрээг цуцлах ажиллагаа бүтэлгүйтсэн. Төслийн уян хатан шинж чанар, хоёр талын хамтын хариуцлага, зөвхөн нэг ажлын хэсэг үлдсэнийг харгалзан үзвэл уг бүтэлгүйтэл нь BW-ийн 6:265 дугаар зүйлийн дагуу гэрээг цуцлах үндэслэл болохгүй. Буцаан олголт болон хохирлын нэхэмжлэлийг хэрэгсэхгүй болгосон.
Дүүргийн шүүх Amsterdam, 2026 оны 4-р сарын 22: Заалттай огноо
ECLI:NL:RBAMS:2026:3930 дээр нэгэн үйлчлүүлэгч хөгжүүлэгч шинэ аппликейшнийг хожимдуулсан, төсвөө хэтрүүлсэн, одоо байгаа аппликейшнуудыг муу засварласан гэж мэдэгдсэн. Үнийн саналд хоёр долоо хоногийн скрам спринт болон танилцуулсан нээлтийн огноог ашигласан.
Шүүх хатуу хугацаа тогтоогоогүй гэж үзсэн: эхлүүлэх огноо болон спринт төлөвлөлт нь заалт байсан бөгөөд скрам арга барил нь нягт хамтын ажиллагаа шаарддаг байв. Хатуу хугацаа тогтоогоогүй тохиолдолд үйлчлүүлэгч гэрээг цуцалсан тухай хүчин төгөлдөр мэдэгдэл авах шаардлагатай байсан бөгөөд түүний мэдэгдэл нь хөгжүүлэгчийг гэрээг цуцалсан байдалд оруулаагүй болно. Бүх нэхэмжлэлийг хэрэгсэхгүй болгосон.
Сургамж: Хэрэв та огноог хатуу байлгахыг хүсвэл гэрээнд үүнийгээ тодорхой зааж өгөөрэй. Үнийн санал эсвэл имэйлд огноо оруулах нь ихэвчлэн хангалтгүй байдаг.
Үйлчлүүлэгчийн хувьд та юуг шалгах ёстой вэ?
- Танай бүтээгдэхүүний эзэмшигч хэн бэ, тэр хүн таны өмнөөс хүлээгдэж буй бүтээгдэхүүний жагсаалтыг өөрчлөх эрх мэдэлтэй юу?
- Хүлээн авах шалгуур болон хийгдсэний тодорхойлолтыг спринт эсвэл суллалт бүрийн хувьд тэмдэглэсэн үү?
- Гэрээнд аль өдрүүд хатуу хугацаа болохыг тодорхой заасан уу?
- Хүргэлтийг ямар хугацаанд туршиж, хариу өгөх ёстой вэ, хэрэв та үүнийг хийхгүй бол юу болох вэ?
- Та эх код болон баримт бичигт хэзээ хандах боломжтой вэ?
- Гэрээг эрт цуцлах үед юуг, ямар үнээр хүлээлгэн өгөх вэ?
Нийлүүлэгчийн хувьд юуг шалгах ёстой вэ?
- Өөрөөр тохиролцоогүй бол үнийн санал болон төлөвлөлт дэх огноо нь заалт болох нь тодорхой байна уу?
- Та бүтээгдэхүүний эзэмшигчийн шийдвэр болон ажлын жагсаалтад гарсан өөрчлөлтийг бичгээр тэмдэглэдэг үү?
- Үйлчлүүлэгч мэдээлэл өгөөгүй, хүчин чадлыг нь шалгаагүй эсвэл шийдвэрээ цагт нь өгөөгүй тохиолдолд та бүртгэдэг үү? Энэ нь зээлдүүлэгчийн үүргээ биелүүлээгүйтэй тэнцэж болно (BW-ийн 6:58-р зүйл).
- Төлбөрийн үндэслэл тодорхой байна уу: спринт тутамд, цаг тутамд, функцийн цэг тутамд эсвэл үр дүнд тус бүр үү?
- Та хүрээний гэрээнд хариуцлагыг хязгаарлаж, үр дагаварт учрах алдагдлыг хассан уу?
Бид танд зориулж agile гэрээгээр юу хийж чадах вэ?
Манай мэдээллийн технологийн хуульчид мэдээллийн технологийн нийлүүлэгчид болон үйлчлүүлэгчдэд уян хатан төслүүдэд тусалдаг. Бид дараахь зүйлийг хийж чадна.
- уян хатан төслийн хүрээний гэрээ болон хэрэгжүүлэх гэрээг боловсруулах эсвэл хянах;
- хүлээн авах шалгуурыг томъёолох, дууссан ажлын тодорхойлолт болон тодорхой хугацааны заалтуудыг боловсруулах;
- гэрээг хугацаанаас нь өмнө цуцалж, өөр нийлүүлэгч рүү шилжүүлэх тухай гарах зохицуулалтыг боловсруулах;
- нийлүүлэгч төлбөрөө төлөөгүй эсэх, гэрээг цуцлах боломжтой эсэхийг үнэлэх;
- гэрээг цуцлах тухай мэдэгдэл эсвэл түүнд хариу арга хэмжээ авах, хойшлуулах эсвэл цуцлахтай холбоотой журмыг хэрэгжүүлэх.
Мэдээллийн технологийн хуульч юу хийдэг талаар дэлгэрэнгүй уншина уу.
Дүгнэлт
- Агилей гэрээ нь ихэвчлэн хүрээний гэрээ болон даалгавар тус бүрийн хэрэгжүүлэх гэрээнээс бүрдэнэ.
- Нийлүүлэгчийн үүрэг нь ихэвчлэн хамгийн сайн хүчин чармайлтын үүрэг байдаг; гэрээнд заасан шошго нь шийдвэрлэх үүрэг гүйцэтгэдэггүй.
- Хэмжиж болох хүлээн авах шалгуур болон хийгдсэний тодорхойлолт нь спринт амжилттай болсон эсэх талаарх маргааныг урьдчилан сэргийлдэг.
- Хүргэлтийн огноо нь хатуу хугацаатай эсэх нь гэрээ болон хамтын ажиллагаанаас хамаардаг тул үүнийг тодорхой зааж өгөх хэрэгтэй; хатуу хугацаа алдсан ч гэсэн гэрээг цуцлах үндэслэл болохгүй (ECLI:NL:RBMNE:2023:5936).
- Эрт дуусгавар болгох, эх код бичих, өөр нийлүүлэгчид шилжүүлэх ажлыг урьдчилан зохицуулах.
Түгээмэл асуултууд
Хөгжилтэй гэрээ гэж юу вэ?
Талууд уян хатан хамтын ажиллагааг бүртгэдэг зохицуулалтын багц. Энэ нь ихэвчлэн ерөнхий дүрмүүдтэй хүрээний гэрээ болон хамрах хүрээ, төлөвлөлт, үнэ болон хүлээн авах шалгуурыг хамарсан даалгавар тус бүрийн хэрэгжүүлэх гэрээнээс бүрдэнэ.
Agile төслийн хүргэлтийн огноо нь хатуу хугацаа мөн үү?
Автоматаар биш. Энэ нь гэрээ, ажлын арга барил болон бодит хамтын ажиллагаанаас хамаарна. ECLI:NL:RBAMS:2026:3930-д scrum спринт ашиглан ишлэлд оруулсан огноог заалт гэж үзсэн. Хэрэв та огноог хатуу байлгахыг хүсч байвал үүнийгээ тодорхой зааж өгнө үү.
Хатуу хугацаа хэтэрсэн нь гэрээг цуцлах үндэслэл болох уу?
Үргэлж биш. ECLI:NL:RBMNE:2023:5936-д нийлүүлэгч нь хатуу хугацаа алдаж, төлбөрөө төлөөгүй байсан боловч төслийн уян хатан шинж чанар болон бараг дуусч байсан тул BW-ийн 6:265 дугаар зүйлийн дагуу гэрээг цуцлахаас татгалзсан.
Хэн хоцрогдсон жагсаалтыг өөрчилж чадах вэ?
Үйлчлүүлэгчийн талд байгаа бүтээгдэхүүний эзэмшигч. Тэр хэн бэ, мөн тэр үйлчлүүлэгчийн өмнөөс тэргүүлэх чиглэлийг өөрчлөх эрх мэдэлтэй эсэхийг тэмдэглэнэ үү.
Agile working системд төлбөрийг хэрхэн зохицуулдаг вэ?
Нийтлэг суурь нь спринт тутамд, цаг тутамд эсвэл функцийн цэг тутамд төлбөр юм. Нэг тогтмол хүргэлтийн огноонд төлөх нь тогтмол эцсийн үр дүнгүй аргатай тохирохгүй байна. Сонгосон суурийг тодорхой тэмдэглэнэ үү.
