Бағдарлама жасау келісім-шарты: толық нұсқаулық + тегін үлгі

Көпшілік бағдарламалық қамтамасыз ету жобалары әзірлеушілер код жазуда нашар болғандықтан сәтсіздікке ұшырамайды. Олар сәтсіздікке ұшырайды, себебі ешкім "дайын" дегенді не білдіретінін жазып алмаған. Standish Group-тың CHAOS есебі бағдарлама жобаларының сәттілік деңгейін небәрі 31% деп көрсетеді — ал ауқым бойынша келіспеушіліктер, IP иелігінің анық еместігі және даулы төлем шарттары ең көп тараған себептер.

Бағдарлама жасау келісім-шарты жұмыс басталмай тұрып бұл барлық мәселелерді шешеді. Бұл клиент пен әзірлеуші (немесе агенттік) арасындағы келісім-шарт, ол не салынатынын, кімнің иелігінде болатынын, қанша тұратынын және бұзылған кезде не болатынын анықтайды. Онсыз сіз жақсы ниет пен жадыға сенесіз — ал соттар екеуін де қабылдамайды.

Бұл нұсқаулық бәрін қамтиды: бағдарлама жасау келісім-шарты қашан қажет, төрт келісім-шарт түрі және әрқайсысын қашан қолдану керек, маңызы бар әр тармақ, және жобаңыз үшін реттеп алуға болатын тегін жүктеп алынатын үлгі. Егер негіздерді білсеңіз және тікелей үлгіге өткіңіз келсе, үлгі бөліміне өтіңіз. Әйтпесе, контекст маңызды — әсіресе IP бөлімі, өйткені көптеген келісім-шарттар дәл сол жерде бұзылады. Келісім-шарттар мен келісімдердің айырмашылығын кеңінен қарау үшін біздің келісімшарт vs келісім нұсқаулығы білуге тұратын заңды айырмашылықтарды қамтиды.

Бағдарлама жасау келісім-шарты (SDA) — бұл клиент пен бағдарламалық қамтамасыз ету әзірлеушісі немесе әзірлеу компаниясы арасындағы заңды түрде міндетті келісім-шарт. Ол жұмыс ауқымын, төлем құрылымын, жеткізу мерзімін, зияткерлік меншік иелігін, құпиялылық шарттарын және екі жақтан біреуі келісімді тоқтатқысы келген кезде не болатынын анықтайды.

SDA — бұл ұсыныс, жоба қысқаша түсінігі немесе жұмысты растайтын Slack хабарламасы емес. Бұл әзірлеу басталмай тұрып екі жақ та келіскен нәрсенің ресми заңды жазбасы. Қол қойылғаннан кейін бұл — дау туындағанда сілтейтін құжат — және сотқа жеткен жағдайда сот оқитын құжат.

SDA не қамтиды

Дұрыс жасалған бағдарлама жасау келісім-шарты мына мәселелерді қамтиды:

• Жұмыс ауқымы — әзірлеуші не салатыны, үшінші тарап аяқталуын бағалай алатындай дәлдікпен
• Жеткізілімдер мен маңызды кезеңдер — не жеткізілетіні, қандай түрде және қашан
• Төлем шарттары — жалпы сома, төлем кестесі және әр төлемді не белгілейтіні
• IP иелік құқығы — код жазылғаннан кейін кімге тиесілі
• Құпиялылық — әр тараптың қандай меншікті ақпаратын құпия сақтауы керек
• Қабылдау тестілеуі — клиент жеткізілген бағдарламалық қамтаманың талаптарға сай келетінін қалай бағалайды
• Кепілдіктер — әзірлеуші бағдарламалық қамтаманың функционалдылығы туралы не кепілдік береді
• Тоқтату шарттары — кез келген жақ келісімді қалай аяқтай алады және аяқталған жұмысқа не болады

Кейбір клиенттер SDA-ны Жұмыс сипаттамасымен (SOW) шатастырады. Қабаттасу бар, бірақ олар бірдей нәрсе емес — және бұл айырмашылық маңызды. Ұзақ мерзімді жобаларда бұл құжаттар қалай бірге жұмыс істейтіні туралы MSA мен SOW арасындағы қатынас түсіндіреді.

Қысқа жауап: бағдарламалық қамтаманы жасау үшін біреуге төлем жасаған кезде немесе оны жасау үшін төлем алған кезде.

Келісім-шарт екі апталық жоба үшін жеке фрилансер жалдағанда да, 12 айлық өнімді құру үшін 20 адамдық агенттікпен жұмыс істегенде де маңызды. Ауқым өзгереді; жазбаша шарттардың қажеттілігі өзгермейді.

Сізге бағдарлама жасау келісім-шарты мына жағдайларда қажет:

• Бағдарламалық қамтаманы аутсорсингке бергенде — әсіресе оффшорлық немесе қашықтағы командаларға, мұнда юрисдикциялық айырмашылықтар ресми емес келісімдерді қиындатады
• Тапсырыс бойынша бағдарламалық қамтама жасалғанда — жұмыс неғұрлым ерекше болса, IP иелігін нақты құжаттау соғұрлым маңызды
• Бірнеше әзірлеу кезеңдері бар болса — маңызды кезеңдік төлемдер әр кезеңді қозғайтын жазбаша қабылдау критерийлерін қажет етеді
• Сезімтал деректер немесе жүйелер қолданылса — клиент деректеріне қатысты кез келген жоба құпиялылық пен қауіпсіздік тармақтарын қажет етеді
• Меншікті фреймворктерде салынса — тапсырыс бойынша жеткізілімдерге енгізілген алдын ала жазылған код қ清晰的 иелік мәселелерін тудырады
• Шекаралар арқылы жұмыс істегенде — әзірлеуші мен клиент әртүрлі елдерде болғанда басқарушы заң мен юрисдикция аталуы керек

Толық SDA-сыз айналып өтуге болатын жалғыз жағдай: барлық тиісті шарттарды қамтитын кеңейтілген негізгі қызмет көрсету келісім-шартымен басқарылатын өте қысқа, аз құнды жұмыс. Бірақ тіпті сол жағдайда да көптеген адвокаттар құжаттарды жасау керек дейді.

Әр жобаға сәйкес келетін жалғыз SDA үлгісі жоқ. Келісім-шарт құрылымы жобаның қалай бағаланатыны мен қамтылатынына сәйкес келуі керек — және дұрыс емес құрылымды таңдау жақсы нәтижелерге қарсы жұмыс істейтін ынталандырулар жасайды.

Бірдей бағалы келісім-шарттар

Бірдей бағалы SDA жоба талаптары әзірлеу басталмай тұрып тұрақты және жақсы түсінілген кезде жұмыс істейді. Әзірлеуші белгіленген ауқымды келісілген жалпы төлемге жеткізуге міндеттенеді. Бюджеттік белгілілік клиенттерге негізгі артықшылық болып табылады. Қауіпі: егер талаптар жеткіліксіз анықталса, әзірлеуші артық шығынды өзі көтереді немесе даулар басталады.

Уақыт пен материалдар келісім-шарттары

T&M келісім-шарттары талдау жобаларына, бастапқы сатындағы өнімдерге немесе толық ауқым алдын ала анықталмайтын кез келген жағдайға сәйкес келеді. Клиент келісілген бағалар бойынша нақты жұмыс сағаттары үшін төлем жасайды. Сіз икемділік аласыз; айырбас — құнының белгісіздігі. Бюджеттік шектеулер мен айлық төлем шегіне қол жеткізу бұл қауіпті басқаруға көмектеседі.

Бөлімген команда келісім-шарттары

Тұрақты қашықтағы инженерлік команда қажет ететін компаниялар үшін — бір реттік жоба жеткізуі емес — бөлімген команда келісім-шарты үздіксіз қатынас шарттарын белгілейді. IT-компаниялар үшін келісімшарт басқаруы көбінесе бір уақытта бірнеше SDA, SOW және NDA құжаттарын жүргізеді.

Барлық тармақтар бірдей маңызды емес. Міне, сонықтары, онда жоқ немесе анық емес тіл нақты дауларға әкеледі.

1. Жұмыс ауқымы және жеткізілімдер

Не салынатынын жобаға қатыспаған адам аяқталғанын бағалай алатындай дәлдікпен сипаттаңыз. Функционалдық талаптар, техникалық сипаттамалар, қолданылатын платформалар және өнімділік көрсеткіштері осында болуы керек. Ауқымнан тыс не екенін нақты атаңыз.

Анық емес ауқым — бағдарлама дауларының ең көп тараған себебі. "Веб-сайт салу" — бұл ауқым емес. "Қосымша A-да тізілген мүмкіндіктері бар жауап беретін React/Next.js қолданбасын салу, мобильді құрылғыда Lighthouse өнімділік көрсеткіші 90+" — бұл ауқым.

2. Төлем шарттары және маңызды кезеңдер кестесі

Әр төлемді тізімдеңіз: сомасы, қозғайтын оқиға және төлем әдісі. Маңызды кезеңдік төлемдер қабылданған жеткізілімдерге байланысты болуы керек, тек күнтізбелік күнге емес. Валютаны, төлем мерзімін (Net-15 немесе Net-30 стандартты) және кешіктірілген төлем үшін айыппұлды анықтаңыз.

3. Зияткерлік меншік иелігін

Бұл — клиенттер тым тездете оқитын тармақ. Тапсырыс бойынша код кімге тиесілі? Әзірлеуші енгізген алдын ала бар код кімге тиесілі? Ашық кодты бағдарламалық қамтама қамтылған ба? SDA-ның IP бөлігі жеткізілгеннен кейін бағдарламалық қамтаманы кім пайдалана, өзгерте, сата немесе лицензиялай алатынын анықтайды. Бұны қате жасау қымбатқа түседі — төмендегі IP бөліміндегі Cadence v. Avanti ісін қараңыз.

4. Құпиялылық

SDA өзара құпиялылық міндеттемелерін қамтуы керек. Әзірлеуші клиент деректерін немесе меншікті бизнес логикасын ашпауы керек; клиент әзірлеушінің меншікті процестері немесе құралдарын ашпауы керек. Толық NDA шарттары үшін жеке келісім-шартта бағдарлама компанияларына арналған мердігер NDA нұсқаулығы осы нұсқаулықпен қатар оқуға тұрады.

5. Қабылдау тестілеуі

Клиент әр жеткізілімді қалай қарап, қабылдайтынын анықтаңыз. Қарау терезесі (5–10 жұмыс күні стандартты)...

Бұл үлгіні келісім-шарт негізі ретінде пайдаланыңыз. Барлық жақшадағы өрістерді өз талаптарыңызға ауыстырыңыз. Күрделі жобалар үшін соңғы нұсқаны бағдарламалық қамтама адвокатына тексертуге жіберіңіз — әсіресе IP және кепілдік бөлімдері.

Бірнеше әзірлеу серіктестерімен келісім-шарттарды басқаратын IT-компаниялар үшін барлық SDA-ларды бір құжат басқару жүйесінде орталықтандыру — нұсқа тарихы мен бұзуға төзімді қолтаңбалармен — бірнеше email тізбектері мен қол қойылмаған жоба нұсқаларының хаосын жояды.

Жоғарыдағы үлгіде толтыруға оннан астам өріс бар. Мына нұсқаулық кейінірек даулар тудыратын бос орындар қалдырмай әрқайсысын қалай толтыру керектігін көрсетеді.

Қадам 1: Келісім-шартқа қол тигізбей тұрып ауқымды анықтаңыз

Үлгіні ашпай тұрып, бағдарламалық қамтаманың не істеуі керектігін құжаттаңыз. Функционалдық талаптар, техникалық шектеулер, қолданылатын платформалар, интеграция тәуелділіктері — бәрі. SDA-ның ауқым бөлімі оның артындағы сипаттама құжатына жақсы болған сайын жақсы.

Күрделі жобалар үшін толық сипаттаманы Қосымша A ретінде қосыңыз және оны ауқым тармағынан сілтеме жасаңыз. Бұл негізгі келісім-шартты оқуға ыңғайлы етіп сақтайды және толық техникалық мәліметтердің заңды түрде тіркелгенін қамтамасыз етеді.

Қадам 2: Маңызды кезеңдер кестесін құрыңыз

Жеткізу күнінен кері қарай жұмыс істеңіз. Жобаны кезеңдерге бөліңіз — талдау, дизайн, әзірлеу, тестілеу, орналастыру — және әрқайсысына доллар сомасын және мерзімін белгілеңіз. Кезеңдік төлемдер әр кезеңде жеткізілген құндылыққа шамамен сәйкес келуі керек.

Абайлаңыз: бұл тараптардың көбі күткеннен ұзағыраққа созылады, әсіресе алғашқы жобаларда. Екі тарап та қатысқан 1-2 сағат жоспарлау.

Қадам 3: IP иелігін нақты қарастырыңыз

3-тармақты мұқият оқып, барлық бос орындарды толтырыңыз. Егер әзірлеуші осы жобадан бұрын құрастырған меншікті фреймворктер немесе құралдарды пайдаланса, оларды алдын ала бар жұмыс бөлінуінде тізімдеңіз. Егер сіз ашық кодты кітапханаларды пайдалансаңыз, лицензияларды атаңыз.

Тапсырыс бойынша жұмысты беру (3.1-тармақ) клиенттер үшін әдетте ең маңызды тармақ болып табылады: бұл жеткізілген кодтың иелігін әзірлеушіден сізге ауыстырады. Бұны анық емес қалдырмаңыз.

Қадам 4: Қабылдау терезесін және критерийлерін белгілеңіз

Толтыру алдында қарау терезесін шешіңіз. Он жұмыс күні кәдімгі нәрсе. Екі апта бос клиенттерге жеткізілімді нақты тестілеуге жеткілікті уақыт береді; одан қысқарақ болса, тестілеушілер саяхаттап немесе басқа айналысқан кезде даулар тудырады.

5-тармақ үшін...

Көптеген үлгілер негіздерді қамтиды. Міне, арзан немесе тездетіп жасалған келісім-шарттарда жоқ тармақтар — және бұлар әдетте бұзылғанда ең маңызды болады.

Қабылдау тестілеуі өту/қайтару критерийлерімен

Жоғарыдағы үлгідегі 5-тармақ клиенттің жеткізілімдерді *қашан* және *қалай* қарап, қабылдайтынын анықтайды. Көптеген келісім-шарттарда өткізетін нәрсе: өту/қайтарудың нақты критерийлері. Өлшенетін өту/қайтару нормаларысыз қабылдау келіссөзге айналады. Клиент әрқашан бағдарламалық қамтама "жеткіліксіз жақсы" емес деп дәлелдей алады. Әзірлеу басталмай тұрып объективті критерийлерді Қосымша A-ға жазыңыз.

Бастапқы кодты депозитарлық сақтау

Егер сіздің бизнесіңіз тапсырыс бойынша бағдарламалық қамтамаға тәуелді болса және әзірлеуші бизнесін жапса, сізге бастапқы кодқа қол жеткізу керек. Бастапқы кодты депозитарлық сақтау тармағы әзірлеушінің бастапқы кодын бейтарап депозитарлық агентпен сақтауды талап етеді. Егер әзірлеуші қызметін тоқтатса немесе келісім-шартты айқын бұзса, депозитарлық сақтау кодты клиентке береді. Көптеген клиенттер мұны сұрауды ешқашан ойламайды — қажет болғанша.

Жеткізілгеннен кейінгі жауапкершілік мерзімі

7-тармақ толық жауапкершілікті шектейді, бірақ көптеген үлгілер уақыттық терезені қарастырмайды. Жауапкершілік қашан аяқталады? Егер кемшілік жеткізілгеннен кейін 18 ай өткен соң деректер жоғалуына әкелсе, әзірлеуші әлі де жауапты ма? Кепілдік мерзімін және кепілдік мерзімінен кейінгі жауапкершілік терезесін нақты анықтаңыз. Кепілдік мерзімінен кейін әзірлеушінің міндеті әдетте тек оның тудырған кемшіліктерін түзету — клиенттің өзгертулерінен туындаған бақалар емес.

Өзгерістерді бақылау процесі

9-тармақ ауқым өзгерістері үшін қол қойылған Өзгерту бұйрығын талап етеді. Көптеген келісім-шарттарда жоқ нәрсе: Өзгерту бұйрықтарына қол қоюға кімнің құқығы бар екенін анықтау. Егер клиент тарапынан жоба менеджері ауызша жаңа мүмкіндік сұраса және әзірлеуші оны салса, әзірлеушіге төлем төленуі керек пе? Тек Өзгерту бұйрығы процесі орындалса. Өзгерістерді бекітуге құқығы бар нақты рөлдерді (жеке тұлғалар емес, олардың атаулары өзгереді) атаңыз.

Ашық кодты лицензияға сәйкестік

Ашық кодты компоненттерді пайдалану заманауи бағдарламалық қамтамада стандартты болып табылады. Бірақ MIT, Apache 2.0 немесе GPL лицензиялары әрқайсысы коммерциялық пайдалану жөнінде әртүрлі міндеттемелер қояды. SDA ашық кодты компоненттерді қамтитынын мойындауы керек және әзірлеуші лицензияларды сәйкестікке сәйкес пайдаланғанын кепілдендіруі керек. Клиенттер бұл мәселені аудармайды — және кейінірек заңды қиындықтарға тап болады.

IP иелігін — клиенттер көпшілігі жылдам қарап өтетін тармақ. Және бұны қате жасаудың салдары ең үлкен.

Cadence v. Avanti ісі: $265 млн сабақ

2002 жылы Калифорния соты Avanti Corporation-ның бәсекелес өнімде ұрланған Cadence бастапқы кодын пайдаланғанын анықтады. Зиян шығындары $265 млн жетті. Бұл іс бағдарламалық қамта IP дауларында жиі цитируется, себебі бастапқы код иелігінің даулы немесе, нашар жағдайда, өнімге ешқашан енгізілмеуі керек кодтың енгізілген кезде не болатынын көрсетеді. Дұрыс жасалған IP тармақ тек соңғы жеткізілім кімге тиесілі екенін анықтамайды — сонымен қатар әзірлеуші үшінші тарап IP-сы дұрыс емес енгізілмегенін кепілдендіруді талап етеді.

Төрт IP моделі

Алдын ала бар жұмыс vs тапсырыс бойынша жұмыс

Көптеген әзірлеушілер сіздің жобаңыз басталмай тұрып құрастырған құралдар, фреймворктер және кітапханаларды әкеледі. Бұлар "алдын ала бар жұмыстар" немесе "фондық IP". SDA енгізілген алдын ала бар жұмысты нақты анықтауы керек және клиентке оны жеткізілген бағдарламалық қамтама құрамында пайдалану лицензиясын беруі керек — бұл негізгі құралдардың иелігін берместен.

IP мәселелерін тереңірек қарау үшін біздің бағдарлама жасау келісім-шарттарындағы IP құқықтары нұсқаулығы келісім-шартта сізге не қажет екенін түсіндіреді.

Бұл үш құжатты үнемі шатастырады. Әрқайсысының өз рөлі бар және дұрыс емесін пайдалану немесе оларды араластыру — есептілікті жоюға әкеледі.

Бір реттік жобалар үшін бұл нұсқаулықтағыдай standalone SDA бәрін қамтиды. Ұзақ мерзімді әзірлеу серіктесімен жұмыс істегенде — уақыт өтегі бірнеше жобаларды жүргізгенде — MSA + SOW құрылымы тиімдірек. MSA заңдық негізді бір рет келіседі; әр жоба жаңа SOW қосады. Біздің SOW-ға арналған толық нұсқаулық SOW құрылымын егжей-тегжейлі қамтиды.

Қол қойылған SDA алу бұрын басып шығару, сканерлеу, email жіберу және екінші тараптың нұсқасы сіздікіне сәйкес келетініне үміттану дегенді білдіретін. Бұны бұлай жасауға ешқандай себеп жоқ.

Электрондық қолтаңбаны заңды жарамды ететін нәрсе

ESIGN Act (АҚШ) және eIDAS (ЕО) бойынша электрондық қолтаңба мына жағдайда коммерциялық келісім-шарттар үшін заңды жарамды:

• Қол қою ниетімен қолданылуы керек
• Қол қойылатын нақты құжатпен байланысты болуы керек
• Қол қоюшыға теңестіруге мүмкіндік беруі керек
• Жазба кейінірек алынатын формада сақталуы керек

Криптографиялық қолтаңбалар одан әрі жүреді: әр қолтаңба құжаттың хэшіне математикалық түрде байланысты. Қол қойылғаннан кейін бір таңбаны өзгертсеңіз, хэш өзгереді, бұл бұрмалауды дерлік анықтауға мүмкіндік береді. Бұл қайтарылмайтындық келісім-шартты сотта қорғайды — ешқандай жақ кейінірек құжат өзгертілді деп мәлімдей алмайды.

Қол қою жұмыс процесі қалай жұмыс істейді

IT-компаниялар үшін құжат басқаруы көбінесе бір уақытта бірнеше SDA, SOW және NDA құжаттарын жүргізеді. Мақсатты жұмыс процесі email негізіндегі қол қоюдың нұсқа бақылау кошмарының алдын алады:

1. 1.
   Қорытындыланған SDA-ны келісім-шарт басқару платформасына жүктеңіз
2. 2.
   Әр қол қоюшының email адресін және қол қою ретін қосыңыз
3. 3.
   Әр тарап қауіпсіз қол қою сілтемесін алады — қол қою үшін тіркелу қажет емес
4. 4.
   Қолтаңбалар қолданылады; платформа аяқтау сертификатын уақыт белгілері, IP мекенжайлары және құжат хэшімен жасайды
5. 5.
   Екі тарап та автоматты түрде орындалған құжатты алады
6. 6.
   Аудит іздері бұзылмай сақталады, болашаққа сілтеме немесе дау шешу үшін қолжетімді

Маңызды кезеңдік төлемдерді қол қоюмен байланыстыру

Заманауи келісім-шарт платформасындағы ең пайдалы мүмкіндік — қолтаңбаның өзі емес, келесі не болатынына байланыстыру. Әзірлеуші маңызды кезеңді жеткізгенде және клиент қабылдау формасына қол қойғанда, келісім-шартқа байланысты төлемдер автоматты түрде іске қосылады. Қолмен шот-фактура қуып жүру жоқ, "мен сіз... деп ойладым" жоқ.

Келісім-шарт басқару жоспарларының толық баға бөлінуі үшін Chaindoc баға беті әр деңгейде не екенін қамтиды.