Trumpas atsakymas
Programavimo įmonės pasirinkimas turėtų remtis atsakymais į klausimus apie procesą, žmones, kodo nuosavybę ir priežiūrą po paleidimo, o ne vien pasiūlymo kaina. Prieš pasirašant sutartį verta užduoti 12 klausimų, išvardytų žemiau, ir atsakymus palyginti raštu. Ypač svarbu, kad sutartyje būtų aiškiai perduotos turtinės teisės į kodą, sutarta dėl asmens duomenų tvarkymo, garantinio termino ir priežiūros sąlygų.
Programavimo įmonės pasirinkimas: kodėl pigiausias pasiūlymas dažnai brangiausias
Du pasiūlymai tai pačiai sistemai gali skirtis kelis kartus. Dažniausiai skirtumą lemia ne valandos įkainis, bet tai, kas į pasiūlymą įtraukta. Pigesniame pasiūlyme dažnai nėra procesų analizės, automatinių testų, dokumentacijos, duomenų migracijos ar apmokymų. Šie darbai vis tiek bus reikalingi, tik jie atsiras vėliau kaip papildomi užsakymai, kai keisti tiekėją jau sunku.
Todėl tiekėjus verta lyginti pagal keturis dalykus: kas bus padaryta, kaip bus tikrinama, kam priklausys rezultatas ir kas vyks po paleidimo. Žemiau pateikti klausimai sugrupuoti pagal šias temas. Juos galima tiesiog nusiųsti visiems tiekėjams ir paprašyti atsakyti raštu.
Klausimai apie procesą
1. Nuo ko prasideda projektas ir koks pirmojo etapo rezultatas?
Rimtas tiekėjas prieš vertindamas kainą nori suprasti procesą: pasikalbėti su žmonėmis, kurie juo naudosis, pamatyti esamus failus ir programas. Paklauskite, ar pirmasis etapas baigiasi dokumentu, kurį galėsite pasiimti, pavyzdžiui, procesų aprašymu, funkcijų sąrašu ir sąmata. Toks dokumentas naudingas net jei vėliau pasirinksite kitą kūrėją.
2. Kaip dažnai matysime veikiančią sistemos dalį?
Geras atsakymas nurodo konkretų ritmą, pavyzdžiui, demonstraciją kas dvi savaites testinėje aplinkoje, kur galite patys paspaudyti. Ataskaita apie „80 % atliktų darbų" be galimybės ką nors išbandyti mažai ką pasako.
3. Kaip bus priimamas atliktas darbas?
Priėmimo testavimas yra etapas, kai užsakovas patikrina, ar sistema atitinka sutartus reikalavimus. Paklauskite, kas parengs priėmimo scenarijus, kiek laiko turėsite patikrai, kas laikoma kritine klaida ir kas nutinka, jei ji randama. Aiškūs priėmimo kriterijai apsaugo abi puses: jūs gaunate tai, ką užsakėte, o tiekėjas žino, kada darbas baigtas.
Klausimai apie komandą ir kompetenciją
4. Kas konkrečiai dirbs su mūsų projektu ir ar bus subrangovų?
Pardavimų susitikime dalyvaujantys žmonės ne visada tie, kurie rašys kodą. Paklauskite, kas bus atsakingas už architektūrą, kas programuos ir testuos, ar dalis darbų bus perduota subrangovams. Jei subrangovai matys jūsų duomenis, tai svarbu ir dėl BDAR (žr. 9 klausimą).
5. Ar galite parodyti panašų veikiantį projektą?
Ekrano nuotraukos ir aprašymai yra pradžia, bet vertingiau pamatyti veikiančią sistemą ar bent jos demonstraciją. Paklauskite, kokią problemą projektas sprendė, kas jame buvo sudėtingiausia ir ar sistema vis dar naudojama.
6. Kokiomis technologijomis kuriate ir kodėl būtent jomis?
Technologijos madingumas mažai ką lemia. Svarbiau, ar po kelerių metų rinkoje bus programuotojų, galinčių sistemą prižiūrėti. Plačiai naudojamos atviro kodo technologijos su aktyvia bendruomene sumažina priklausomybę nuo vieno tiekėjo. Jei tiekėjas kuria savo uždarą platformą, paklauskite, kas nutiks su jūsų sistema, jei jis nustos ją vystyti.
Klausimai apie kodą ir nuosavybę
7. Kam priklausys turtinės teisės į programos kodą?
Tai vienas svarbiausių klausimų, ir Lietuvoje jį reguliuoja Autorių teisių ir gretutinių teisių įstatymas. Kompiuterių programa saugoma kaip autorių teisių objektas. Pagal įstatymo 10 straipsnio 2 dalį turtinės teisės į programą, kurią darbuotojas sukūrė atlikdamas darbo funkcijas, priklauso darbdaviui, jei sutartyje nenustatyta kitaip. Tai reiškia, kad be atskiro susitarimo teisės lieka programavimo įmonei, nors už darbą sumokėjote jūs.
Teisių perdavimui taikomos kelios įstatymo taisyklės, kurias verta žinoti:
- Autorinė teisių perdavimo ir kūrinio užsakymo sutartis sudaroma raštu (42 straipsnio 1 dalis).
- Sutartyje turi būti nurodytos perduodamos teisės ir kūrinio panaudojimo būdai, teritorija, terminas, atlyginimas (40 straipsnio 1 dalis).
- Jei naudojimo būdai nenurodyti, laikoma, kad perduota tik tiek teisių, kiek reikia sutarties tikslui pasiekti. Jei nenurodyta teritorija, laikoma, kad teisės perduotos tik Lietuvoje. Jei nenurodytas terminas, šalis gali nutraukti sutartį, raštu įspėjusi prieš vienerius metus (40 straipsnio 2 ir 3 dalys).
- Negalima perduoti teisių į naudojimo būdus, kurie perdavimo metu neegzistuoja ar yra nežinomi (38 straipsnio 3 dalis).
Praktiškai sutartyje verta aiškiai įrašyti, kad perduodamos teisės atgaminti, keisti, pritaikyti ir platinti kodą, neribotam laikui ir visame pasaulyje. Atskirai aptarkite, kokie jau egzistuojantys tiekėjo komponentai ir atviro kodo bibliotekos naudojami: į juos dažniausiai gausite licenciją be nuosavybės teisių, ir tai yra normalu, jei licencijos sąlygos aiškios. Sutartį prieš pasirašant verta parodyti teisininkui.
8. Kur bus laikomas kodas ir ar turėsime prie jo prieigą?
Paklauskite, ar kodas bus jūsų vardu sukurtoje repozitorijoje (pavyzdžiui, GitHub ar GitLab), ar tik tiekėjo serveriuose. Svarbu, kad prieigas prie serverių, domeno ir duomenų bazės turėtumėte ir jūs.
Jei kodas lieka tiekėjui, pavyzdžiui, kai perkate licenciją jo platformai, egzistuoja kodo deponavimo (angl. source code escrow) sutartys. Tai trišalė sutartis tarp tiekėjo, užsakovo ir nepriklausomos deponavimo įmonės, kuri saugo kodą ir dokumentaciją. Kodas perduodamas užsakovui, kai įvyksta sutartyje nurodytas įvykis, pavyzdžiui, tiekėjo nemokumas ar priežiūros nutraukimas. Deponuotą medžiagą verta periodiškai tikrinti, kad ji būtų išsami ir naudojama.
9. Ar pasirašysime duomenų tvarkymo sutartį?
Jei sistema tvarkys asmens duomenis, o tiekėjas turės prie jų prieigą (kurdamas, testuodamas ar prižiūrėdamas), jis tampa duomenų tvarkytoju pagal BDAR. 28 straipsnis reikalauja, kad duomenų valdytojas rinktųsi tik tokius tvarkytojus, kurie pakankamai užtikrina tinkamas technines ir organizacines priemones, o santykiai būtų įforminti rašytine (galima elektronine) sutartimi.
Sutartyje, be kita ko, turi būti nustatyta, kad tvarkytojas duomenis tvarko tik pagal dokumentuotus jūsų nurodymus, užtikrina darbuotojų konfidencialumą ir saugumo priemones, subtvarkytojus pasitelkia tik laikydamasis nustatytų taisyklių, padeda vykdyti duomenų subjektų prašymus, pasibaigus paslaugoms duomenis ištrina arba grąžina ir leidžia atlikti auditą. Jei tiekėjas nežino, apie ką kalbate, tai jau yra atsakymas.
Klausimai apie priežiūrą po paleidimo
10. Koks garantinis terminas ir ką jis apima?
Paklauskite, kiek laiko po paleidimo klaidos taisomos nemokamai ir kas laikoma klaida, o kas nauju pageidavimu. Jei sutartis laikoma rangos sutartimi, Civilinio kodekso 6.666 straipsnis numato, kad kai garantinis terminas nenustatytas, darbų trūkumai turi būti nustatyti per protingą terminą, bet ne ilgiau kaip per dvejus metus nuo rezultato perdavimo, jei įstatymas ar sutartis nenustato kitaip. Reikalavimams dėl trūkumų taikomas vienerių metų ieškinio senaties terminas (6.667 straipsnis). Aiškiai įrašytas garantinis terminas ir jo apimtis sutartyje išvengia ginčų, kaip šias normas taikyti programinei įrangai.
11. Kokios priežiūros (SLA) sąlygos?
SLA (angl. service level agreement) yra paslaugų lygio susitarimas. Jame paprastai nurodoma:
| Sąlyga | Ką reiškia | Ko klausti |
|---|---|---|
| Reakcijos laikas | Per kiek laiko tiekėjas pradeda spręsti problemą | Ar skiriasi pagal klaidos svarbą, ar galioja savaitgaliais |
| Sprendimo laikas | Per kiek laiko problema išsprendžiama arba apeinama | Ar tai įsipareigojimas, ar tik tikslas |
| Prieinamumas | Kiek laiko sistema turi veikti | Kaip matuojama, kas nutinka nepasiekus |
| Atnaujinimai | Saugumo pataisų ir versijų atnaujinimo tvarka | Ar įeina į kainą, kaip dažnai |
| Atsarginės kopijos | Kaip dažnai daromos ir kiek saugomos | Kada paskutinį kartą bandyta atkurti |
Prieinamumo procentus verta išversti į minutes. 99,9 % per 30 dienų mėnesį leidžia apie 43 minutes neveikimo, 99,5 % - apie 3,6 valandos. Kuo aukštesnis reikalavimas, tuo brangesnė infrastruktūra, todėl rinkitės tai, ko iš tikrųjų reikia jūsų procesui.
12. Kas nutiks, jei bendradarbiavimą nutrauksime?
Šis klausimas nemalonus, bet būtinas. Paklauskite, ką gausite nutraukus sutartį: kodą, dokumentaciją, duomenų bazės kopiją, prieigas, ir per kiek laiko. Tai verta aprašyti sutartyje prieš pradedant darbus, kol santykiai dar geri.
Atsakymai, kurie turėtų sunerimti
Dauguma šių atsakymų nereiškia nesąžiningumo. Jie rodo, kad rizika perkeliama jums, ir tai verta žinoti prieš pasirašant.
| Klausimas | Nerimą keliantis atsakymas | Kodėl tai svarbu |
|---|---|---|
| Pirmasis etapas | „Analizės nereikia, iškart pradėsime programuoti" | Neaiški apimtis vėliau reiškia papildomus užsakymus |
| Tarpiniai rezultatai | „Parodysime, kai viskas bus baigta" | Klaidos pastebimos per vėlai, kai jas taisyti brangu |
| Priėmimas | „Priėmimo kriterijai nereikalingi, pasitikėkite mumis" | Nėra pagrindo reikalauti ištaisyti trūkumus |
| Komanda | Negali įvardyti, kas dirbs su projektu | Neaišku, ar yra reikiamos kompetencijos |
| Nuosavybė | „Kodas lieka mums, bet jūs galėsite naudotis" | Be aiškios licencijos negalėsite keisti tiekėjo |
| Prieigos | „Serverius ir domeną administruosime mes" | Nutrūkus santykiams neturėsite prieigos prie savo sistemos |
| Asmens duomenys | „BDAR mums netaikomas, mes tik programuojame" | Kaip duomenų valdytojas atsakote už tvarkytojo pasirinkimą |
| Garantija | „Klaidos bus taisomos pagal valandinį įkainį nuo pirmos dienos" | Už tiekėjo klaidas mokate jūs |
| Išėjimas | „Tokių situacijų nebūna" | Nėra plano, kaip perimti sistemą |
Ko klausti buvusių klientų
Rekomendacijos vertingiausios, kai kalbate su žmogumi, kuris sistemą naudoja kasdien. Paprašykite tiekėjo kontakto ir užduokite kelis konkrečius klausimus:
- Ar projektas baigtas laiku ir biudžete, o jei ne, kodėl?
- Kaip tiekėjas elgėsi, kai atsirado nesutarimų ar pakeitimų?
- Kaip greitai sprendžiamos problemos po paleidimo?
- Ar turite kodą ir visas prieigas savo vardu?
- Ar pasirinktumėte šį tiekėją dar kartą?
Atkreipkite dėmesį ne tik į atsakymus, bet ir į tai, kiek laiko sistema veikia. Projektas, kuris naudojamas ir vystomas kelerius metus, daug pasako apie bendradarbiavimą po paleidimo.
Ką daryti toliau
Šiuos 12 klausimų galite užduoti bet kuriam tiekėjui, taip pat ir mums. Kaip į juos atsakome, aprašėme metodikos puslapyje: nuo mokamo analizės etapo iki SLA priežiūros. Jei dar neaišku, ko iš sistemos reikia, pradžiai tinka IT konsultacija ir sistemos projektavimas, o klausimus galite užduoti per kontaktų puslapį.
Šaltiniai
- Lietuvos Respublikos autorių teisių ir gretutinių teisių įstatymas (e-tar.lt, suvestinė redakcija)
- Lietuvos Respublikos civilinis kodeksas, 6.666 straipsnis. Terminas darbų trūkumams nustatyti
- Lietuvos Respublikos civilinis kodeksas, 6.667 straipsnis. Senaties terminas
- BDAR 28 straipsnis. Duomenų tvarkytojas (gdpr-info.eu)
- BDAR 32 straipsnis. Tvarkymo saugumas (gdpr-info.eu)
- techUK. What are the release events and clauses in software escrow agreements?