Dasturiy ta'minot shartnomasida bo'lishi shart 7 ta band

Ko'pchilik dasturiy ta'minot nizolari buzilgan narsaga emas, hech qachon yozilmagan narsaga borib taqaladi. Shartnoma loyiha o'rtasida ajralishdan keyin kod kimniki ekanini aytmagan, shuning uchun hech kim texnik jihatdan noto'g'ri emas - va hamma tiqilib qolgan.

Mana buning oldini oladigan yetti band.

Qisqa javob

Yetti band, va har biridagi aniq so'zlash shu nomdagi band mavjudligidan ko'ra muhimroq.

Trigger sanasi bilan IP va kod egaligi

Eng muhim band, va ataylab yoki tasodifan eng ko'p noaniq yoziladigan band.

"Mijoz barcha ish mahsulotini egallaydi" himoya qiladigandek eshitiladi. Triggersiz esa qilmaydi: qachondan boshlab egallaydi? Ba'zi shartnomalar egalikni faqat "hamkorlik yakunlangandan keyin" o'tkazadi - bu esa munosabat to'rt oylik qurilishning ikkinchi oyida tugasa real muammoga aylanadi, chunki texnik jihatdan hech narsa yakunlanmagan.

Buning o'rniga nima qidirish kerak: egalik har bosqich to'lovida o'tadi, yoki yaratilishi bilanoq o'tib, dasturchiga portfolio uchun litsenziya qaytariladi. Ikkalasi ham ishlaydi. Noaniq vaqtlash ishlamaydi.

Aniq scope istisnolari

Biz ilgari nega scope hujjatiga istisnolar bo'limi kerakligi haqida yozganmiz, va shartnoma ham o'sha aniqlikni erkin ishora emas, o'zida olib yurishi kerak.

"Ilova qilingan scope'da tasvirlangan MVP ishlab chiqish" ilova qilingan scope'ning o'zi nima istisno qilinganini sanab bermasa - uchinchi tomon API xarajatlari, kontent, ma'lumot ko'chirish, belgilangan muddatdan tashqari qo'llab-quvvatlash - ko'ringanidan zaifroq. O'sha ro'yxatsiz ikkala tomon ham o'z taxminiga tayanadi, va taxminlar kamdan-kam mos keladi.

Kalendarga emas, bosqichga asoslangan to'lov

Sanalarga bog'langan to'lov jadvali - net 30, keyin 30 kundan keyin, keyin yana 30 kundan keyin - nimadir yetkazib berilganidan qat'i nazar to'laydi. Bu loyiha orqada qolsa sizning yagona real tayanch nuqtangizni olib tashlaydi.

Bosqichlarga bog'langan to'lov jadvali - ishlaydigan login oqimi, asosiy tranzaksiya boshdan oxirigacha ishlaydi, admin panel ishlaydi - faqat siz haqiqatan tekshira oladigan narsaga qarshi to'lovni chiqaradi. Bu yagona o'zgarish mijozni himoya qilishda shartnomadagi deyarli har qanday boshqa banddan ko'proq ish qiladi.

Belgilangan o'zgartirish so'rovi jarayoni

Scope o'zgaradi. Qanday o'zgarishini aytmaydigan shartnoma yashirin ravishda "sodir bo'lganda hal qilamiz" deyapti, bu esa o'sha paytda kimda ko'proq tayanch bo'lsa - odatda siz emas, loyiha o'rtasida, hamkor almashtirish qimmat bo'lganda - o'shanga foyda beradi.

Band oddiy aytishi kerak: belgilangan scope'dan tashqaridagi o'zgartirish so'rovi ish boshlanishidan oldin alohida, yozma baholanadi va narxlanadi. Bu ikkala tomonni ham himoya qiladi - dasturchi bepul scope o'sishini singdirmaydi, va siz kiritilgan deb o'ylagan narsangiz uchun kutilmagan hisob-fakturani topmaysiz.

Aniq chegaralangan qo'llab-quvvatlash muddati

"Ishga tushirilgandan keyingi qo'llab-quvvatlash kiritilgan" - bu band emas, ibora. Qanday chegaralangan - necha kun, qanday muammo turini qamrab oladi, qanday javob vaqtida?

Mavjud funksionallikdagi xatolarni tuzatishning o'ttiz kuni - oqilona, keng tarqalgan asos. Undan tashqaridagi har qanday narsa - yangi funksiyalar, doimiy texnik xizmat, ustuvor javob vaqtlari - shartnomada yoki bog'langan kelishuvda bayon qilingan alohida, narxlangan retainer bo'lishi kerak, ikkala tomon jimgina qiladigan taxmin emas.

Tugatish va chiqish shartlari

Har bir shartnoma kerak bo'lishidan oldin, yozma javob berishi kerak: agar bir tomon loyiha tugashidan oldin chiqmoqchi bo'lsa nima bo'ladi?

Kamida: ogohlantirish muddati, o'sha nuqtagacha bajarilgan ish uchun nima to'lanishi, va egalik shartlari (birinchi bandga qarang) erta tugatishda ham toza amal qilishining tasdig'i - faqat muvaffaqiyatli yakunda emas. Faqat toza yakunda nima sodir bo'lishini tasvirlaydigan shartnoma nizoga eng ko'p sabab bo'ladigan stsenariyni rejalashtirmagan.

Maxfiylik va qayta ishlatmaslik

Ko'pchilik professional shartnomalarda standart, lekin asoschilar qamrab olingan deb taxmin qiladigan va ko'pincha qamralmagan aniq narsani tekshirishga arziydi: dasturchiga sizning aniq biznes mantig'ingizni, ma'lumotingizni yoki xususiy yondashuvingizni boshqa mijoz loyihasida qayta ishlatishni taqiqlaydigan band, faqat biznesingiz haqida ochiq gapirmaslik haqidagi umumiy maxfiylik emas.

Umumiy NDA'lar sirni qamrab oladi. Bu band qayta ishlatishni qamrab oladi, va agar mahsulotingizning qiymati nimadir qanday ishlashida bo'lsa, faqat mavjudligida emas - aynan shu versiya muhim.

Shartnomada bular yo'q bo'lsa nima qilish kerak

Bularning ko'pchiligi qayta yozish emas, qo'shimcha. Aniq egalik sanalari, bosqichli to'lovlar yoki istisnolar ro'yxatini qo'shishga qattiq qarshilik ko'rsatadigan hamkor sizga imzo chekishdan keyin emas, oldin bilishga arziydigan ma'lumot beryapti - imzo chekishdan oldin beriladigan savollar shu tekshirish jarayonining suhbat versiyasini yoritadi.

Bu yetti banddan hech biri g'ayrioddiy yoki agressiv so'rov emas. Ular munosabatni tasvirlaydigan shartnoma bilan munosabat noto'g'ri ketsa sizni haqiqatan himoya qiladigan shartnoma o'rtasidagi farq.

MVP qurilishi uchun shartnomani ko'rib chiqyapsizmi va shartlar bo'yicha ikkinchi fikr kerakmi? Tafsilotlarni yuboring - biz nima yetishmayotganini aytamiz. Bizning shartnoma strukturamiz, jumladan IP shartlari va to'lov bosqichlari narxlar sahifamizda tushuntirilgan.