Систем хөгжүүлэлтийн хөлс төлөгдөөгүй үед хэрэглэгдэх хууль юу вэ?
Систем хөгжүүлэх үйлчилгээг гүйцэтгэгч вендоруудад хамгийн том эрсдэл нь “бүтээгдэхүүнийг хүргэсэн ч хэрэглэгч тал төлбөрийг төлөхгүй байгаа” гэсэн нөхцөл байдал биш гэж үү? Систем хөгжүүлэхэд шаардлагатай зардал ихэнхдээ программист болон бусад чадварлаг хүмүүсийн хүчин чармайлтаас шалтгаалдаг учир, хүний нөөцийн зардал ихэвчлэн өндөр байдаг. Орлогын олдоц хойшлуулах нь заримдаа амьдралын эсрэг асуудал болдог. Энэхүү нийтлэлд бид хэрэглэгч тал төлбөр төлөхөөс татгалзсан тохиолдолд вендор тал юу хийх ёстойг хууль зүйн өнцгөөс авч үзэж тайлбарлах болно.
Эхлээд, төлбөр хүсэх боломжтой байдалтай эсэхийг шалгах хэрэгтэй
- Вендор нь хэрэглэгчид бүтээгдэхүүнийг хүргэсэн ч, хэрэглэгч нь хүлээн авахаас татгалзаж, үүний улмаас төлбөрийн хүсэлт гаргах үйл ажиллагаа зогсонги байдалтай байна
- Хүлээн авалтыг дууссан гэж ойлгосон ч, хэрэглэгчийн ойлголттой зөрүүтэй байгаа бөгөөд төлбөрийг төлөхөд хүлээн зөвшөөрөхгүй байна
Энэ нь бодит байдлаар боломжтой үйл явдал юм.
Түүнчлэн, хэрэглэгч нь бүрэн боловсруулсан системийн үзүүлэлтийг шалгаж, хүлээн авах нь систем хөгжүүлэлтийн нэр томъёогоор ‘хүлээн авалт’ гэж нэрлэгддэг. Энэ ‘хүлээн авалт’ гэдэг нь юуны учир чухал болохыг ба түүний явц сайн бус байх үед авч үзэх ёстой зүйлсийн талаар дараах нийтлэлд дэлгэрэнгүй тайлбарласан байна.
Холбоотой нийтлэл: Систем хөгжүүлэлтийн хүлээн авалт ба үүнийг харгалзан үзэх хүлээн авалтын заалтуудын хэрэглээ[ja]
Хүлээн авалтын ерөнхий тайлбарыг дээрх нийтлэлд үлдээсэн ч, хууль ёсны хувьд хэрэглэгчийн хүлээн авалт дууссан эсэхийг ‘үүнийг харгалзан үзэх хүлээн авалтын заалт’ гэдэг заалтын хүрээнд авч үзэх шаардлагатай болдог.
Энэ нь танд санаа зовох ёстой чухал цэг болохыг анхаарах хэрэгтэй, хэрэглэгч төлбөрийг төлөхгүй байгаа тохиолдлыг төсөөлөн, эхлээд авч үзэх ёстой зүйлс нь дараах байна.
- Анх удаа ажил бүрэн дууссан эсэх, эсвэл одоо ч гүйцээгдээгүй байгаа эсэх
- Дутагдалтай барааны баталгаажуулалтын хариуцлага (Japanese 民法６３５条) хэрэглэгдэх боломжтой эсэх
Дээрх хоёр цэгийг эхлээд шалгах хэрэгтэй учир нь, ажил бүрэн дууссан байгаа, мөн дутагдалтай барааны баталгаажуулалтын хариуцлага (Japanese 民法６３５条) хэрэглэгдэхгүй байгаа нь урьдчилан тогтоосон байхгүй бол, хэрэв шүүхэд хандсан ч, төлбөрийг төлүүлэх боломж бага байна гэсэн үг.
Тэгвэл, тодорхойлолт, дээрх хоёр цэгийг шалгахын тулд, вендорын талын хариуцсан хүн юу шалгах хэрэгтэй вэ? Доорхи бичиг баримтуудыг шалгах хэрэгтэй болохыг харцгаая.
Төлбөрийн хүсэлт гаргах эсэхийг шалгахад шаардлагатай баримт бичиг
| Найрлага хүлээн авах баримт Найрлага хүлээн авах баримт байхгүй бол, энэ нь ажил хийгдээгүй, бүтээгдэхүүн дуусаагүй гэсэн дүгнэлтэд хүргэдэг. |
| Хүлээн авалтын үр дүнг мэдэгдэх баримт Ажил дууссан эсэхийг шийдвэрлэхэд хамгийн чухал баримт бичиг болдог. Мөн хэрэв хэрэглэгчийн шалтгаанаар хүлээн авалт хойшлуулагдаж байгаа бол, гэрээнд ‘хүлээн авалтыг үзэх заавар’ хэрхэн бичигдсэн байгааг мөн шалгах хэрэгтэй. |
| Асуудлын удирдлагын жагсаалт Өмнө нь ямар асуудлууд илэрсэн болон тэдгээрийг хэрхэн зохицуулсан талаар мэдэхийн тулд зориулагдсан баримт бичиг. Мөн найрлага хүлээн авсны дараа илэрсэн саатал, гэмтлийн байдлыг болон тэдгээрийг засварлах явцыг ойлгохын тулд зориулагдсан баримт бичиг. |
| Шаардлагын тодорхойлолт, зураг төсөл болон өөрчлөлтийн удирдлагын баримт, түүнчлэн төрөл бүрийн хурлын тэмдэглэл гэх мэт Хэрэглэгч ба ханган нийлүүлэгч эхлээд ямар ойлголттой байсан талаар тодорхой болгох замаар, юу нь саатал, гэмтэл гэж нэрлэгдэх ёстойг тодорхойлох баримт бичиг. |
Мөн, систем хөгжүүлэх үед шаардлагын өөрчлөлтийг хэрхэн удирдах, өөрчлөлтийн удирдлагын баримт бичгийг хэрхэн бэлтгэх талаар нь бусад нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.
Холбоотой нийтлэлүүд：Хууль ёсны үзэглэлээс харахад, систем хөгжүүлэлтэд өөрчлөлтийг хэрхэн удирдах вэ[ja]
| Цуцлах мэдэгдэл эсвэл хэрэглэгчийн саналыг илэрхийлэх бичиг Хүлээн авалтыг хийхгүй байх (эсвэл төлбөрийг төлөхгүй байх) талаар хэрэглэгч ямар санаа бодолтой байгааг мэдэх арга болно. |
Дараа нь, хэдийн хэмжээний хөлс хүсэх боломжтойг шалгах
Хэдийн хэмжээний хөлс хүсэх боломжтой талаар гэрээнд заасан байдаг нь зарчим юм. Гэвч, дараа нь үзүүлэлт өөрчлөгдсөн зэрэг тохиолдлуудад, зөв гэрээ (эсвэл түүнтэй адилхан бичиг баримт) үлдээгдээгүй гэх мэт тохиолдлуудыг төсөөлөх хэрэгтэй. Үзүүлэлт өөрчлөгдсөн, нэмэлт функцийг нэмсэн зэрэг дараа нь гарч ирсэн шалтгаануудын үндсэн дээрх төсөвт дахин тооцоолох арга барилыг доорх нийтлэлд дэлгэрэнгүй тайлбарласан байна.
Холбоотой нийтлэл: Систем хөгжүүлэлтийн төсөвт өртгийг дараа нь нэмэгдүүлэх боломжтой юу[ja]
Төсвийг дахин тооцоолох арга барил нь энэхүү нийтлэлийн дагуу боловч, түүнчлэн төлбөрийн дүнг нэмэгдүүлэх боломжийг авч үзэх хувьд,
- Нэмэлт хөгжүүлэлт, функцийн засварын хэсгийн төсвийн тодорхойлолт ба түүний агуулга
- Төсвийн тодорхойлолтод хэрэглэгчийн талын хариу урвалын агуулга
- Асуудлын удирдлагын жагсаалтад бичигдсэн нэмэлт хөгжүүлэлт, функцийн засварыг үүсгэсэн нөхцөл байдлыг ба түүний үнийн тохиролцооны байдал
гэх мэтчилэн цэгүүдийг төвлөрүүлэн авч үзэх болно. Өөрөөр хэлбэл, “энэхүү үнийн дүнгээр ажлыг захиалга өгөх” гэсэн талаар хэрэглэгчийн талтай санал нийлэх байдал байсан уу (өөрөөр хэлбэл, гэрээ байгуулагдсан гэж үзэж болох уу) гэдгийг шалгах явц юм.
Сүүлд, шүүхэд хандаж маргааныг шийдвэрлэх үед тулгарч болзошгүй асуудлуудыг авч үзэх
Харин хариуцлагын өргөдөл гаргах магадлалд анхаарах
Систем хөгжүүлэлтэд, хэрэглэгч эсвэл үйлдвэрлэгчийн аль нэг тал нөгөө талд шүүхэд хандсан тохиолдолд, хариуцлагын өргөдөл гаргах нь түгээмэл байдаг. Өөрөөр хэлбэл, төлбөрийг хийхгүй байгаа талаар хэрэглэгч талд ч өөрсдийн хэлэх зүйлс байдаг гэсэн үг юм.
Эхлээд систем хөгжүүлэлтэд хэрэглэгч тал мөн олон төрлийн хамтын ажиллагааны үүрэг хүлээдэг ч, үйлдвэрлэгч тал систем хөгжүүлэлтийн мэргэжлийн хүн гэдгээрээ өргөн зүйлсийн шийдвэр гаргах болон томоохон хариуцлага хүлээдэг гэдгийг мартаж болохгүй. Үйлдвэрлэгч талын систем хөгжүүлэлтэд хүлээдэг төслийн удирдлагын үүргийн талаар доорхи нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.
Холбоотой нийтлэл: Систем хөгжүүлэлтэд төслийн удирдлагын үүрэг гэж юу вэ[ja]
Өөрөөр хэлбэл, төлбөрийг нэг талтайгаар төлөхгүй байгаа хэрэглэгч талыг буруутгах боломжтой эсэхийг урьдчилан сайн бодож үзэх шаардлагатай гэсэн үг юм. Өнгөрсөн шүүхийн шийдвэрүүдийг харахад, анх үйлдвэрлэгч тал төлбөрийн хүсэлтээр шүүхэд хандсан ч, хэрэглэгч талын хариуцлагын өргөдөл, хохирлын б compensаар төлбөр төлүүлэх гэсэн тохиолдлууд олонтаа байдаг.
Бизнесийн үндсэн дээр үнэхээр ашигтай эсэхийг ч бас шалгах хэрэгтэй
Төлбөрийн хүсэлтээр шүүхэд хандсан үйлдвэрлэгчийн үг хүлээн зөвшөөрөгдсөн ч, шүүхийн шатанд хүртэл хэрэлдсэн тохиолдолд, цаашид харилцааг үргэлжлүүлэх нь бодит асуудал болохыг таамаглах болно. Мөн шүүхэд өөрийн үгийг хүлээн зөвшөөрсөн ч, төлбөрийг хүлээн авах хүртэл удаан хугацаа шаардлагатай болохыг бэлдэх хэрэгтэй. Шүүхийн үйл ажиллагаанд оролцох зардал ба хүчин чармайлт ч бага биш болохыг тооцоолбол, заримдаа зөрчилдөөнийг зохицуулах арга хэмжээ авах нь зүйтэй байж магадгүй.
Хураангуй
Хэрэв хэрэглэгч урамшууллын төлбөрөө төлөхөөс татгалзвал, тухайн асуудлыг хууль ёсны хүрээнд авч үзэхдээ олон төрлийн бичиг баримтыг шалгах шаардлагатай болдог. Мөн зөвхөн бичиг баримтын удирдлагыг сайтар хийсэн байхад л хангалттай гэсэн үг биш, хэрэв эцсийн шатанд шүүх хуралдааныг эхлүүлэх шийдвэр гаргасан тохиолдолд байгууллага ямар рискийг, сул талыг үүрэх болохыг мөн л анхааралтай авч үзэх хэрэгтэй.
Өдөр тутмын бичиг баримтын удирдлагыг сайтар хийх нь тодорхой хэмжээнд талбарын түвшний ажилд хамааралтай байдаг. Гэхдээ хадгалагдсан бичиг баримт, материалыг ашиглан шүүх хуралдааныг эхлүүлэх шийдвэр гаргахад, энэ нь чухал удирдлагын шийдвэр болох боломжтой. Ийм онцгой нөхцөл байдлын үед талбарын баг болон удирдлагын багийн нэгдмэл байдлыг, байгууллагын хүчийг шалгаруулах нь чухал бөгөөд энэ нь нэгдсэн урсгалыг ойлгож, бэлтгэлтэй байх ёстойг харуулдаг.
Category: IT
Tag: ITSystem Development
