Dorëzimi i projektit softuerik: çfarë duhet të marrësh nga zhvilluesi para se projekti të mbyllet

Dorëzimi i projektit softuerik është çasti kur një punë e paguar bëhet vërtet e jotja. Një projekt nuk mbaron kur funksionon veçoria e fundit. Mbaron kur mund ta mbash sistemin në punë, ta ndryshosh dhe, nëse duhet, t’ia dorëzosh dikujt tjetër pa telefonuar personin që e ndërtoi. Pikërisht këtu shumë biznese të vogla e të mesme zbulojnë se kanë paguar për një produkt që nuk e kontrollojnë plotësisht.

Ky udhëzues përmban listën e asaj që duhet të marrësh nga një zhvillues, freelancer ose agjenci para se ta mbyllësh projektin, pse ka rëndësi secili artikull dhe si ta kërkosh pa e kthyer bisedën në mosmarrëveshje. Shkon mirë me shkrimet tona për kontratën e zhvillimit të softuerit dhe për zgjedhjen e kujt t’ia besosh softuerin.

Pse problemet në dorëzim janë kaq të zakonshme

Dorëzimi rrallë shkruhet në objektin fillestar të punës, ndaj trajtohet si një favor në fund të projektit, kur buxheti është shpenzuar dhe të gjithë duan të kalojnë te puna tjetër. Zakonisht rezulton një nga tre situatat:

• Kodi gjendet në repository-n personale të zhvilluesit, ndërsa ti ke vetëm një skedar ZIP që është tashmë i vjetruar.
• Hosting-u, domeni dhe shërbimet e palëve të treta janë regjistruar me llogaritë personale të zhvilluesit.
• Asgjë nuk është shkruar, kështu që vetëm një person e di si të publikojë një ndryshim ose si të rikthejë një kopje rezervë.

Asnjëra nuk kërkon keqdashje. Ndodh thjesht kur “dorëzim” nënkupton “punon” dhe jo “mund ta administrosh vetë”. Të biesh dakord për standardin e dorëzimit që në fillim nuk kushton pothuajse asgjë; rindërtimi i tij më vonë mund të kushtojë javë të tëra.

Dorëzimi i projektit softuerik: lista hap pas hapi

1. Kodi burimor dhe aksesi në repository

• Repository-ja e plotë, me historikun e plotë të ndryshimeve, në një llogari organizate që e zotëron ti (GitHub, GitLab ose Bitbucket), jo në llogarinë personale të zhvilluesit.
• Të gjitha degët (branches) dhe etiketat (tags), përfshirë atë që përputhet me versionin në prodhim.
• Një deklaratë e qartë licencimi: kush e zotëron kodin e shkruar posaçërisht për ty, dhe cilat komponentë open-source përdoren e me çfarë licence.

Kërko transferim të repository-s ose akses administratori, jo një eksport të vetëm. Platforma si GitHub e mbështesin këtë drejtpërdrejt; shih dokumentimin e tyre për transferimin e një repository-je. Historiku ka rëndësi: shpjegon pse janë marrë vendimet dhe e bën shumë më të lirë zgjidhjen e gabimeve në të ardhmen.

2. Llogaritë, kredencialet dhe mjediset

• Hosting-u, cloud-i, DNS-ja, regjistruesi i domenit, dërgimi i email-eve dhe llogaritë e pagesave të regjistruara në emër të kompanisë tënde.
• Lista e çdo shërbimi të palës së tretë nga i cili varet sistemi (harta, SMS, analitika, API-t e AI-së), me pronarin e llogarisë për secilin.
• Mjedise të ndara për prodhim, testim (staging) dhe zhvillim, secili me kredencialet e veta të ruajtura në një password manager, kurrë në mesazhe chat-i ose në vetë kodin.
• Çelësat API të ndryshuar gjatë dorëzimit, që zhvilluesi të mos ketë më akses funksional në prodhim, përveç nëse një marrëveshje mirëmbajtjeje e parashikon.

3. Dokumentim që e ndjek edhe një i huaj

Dokumentimi i mirë është i shkurtër dhe praktik. Nuk të duhet një manual 200-faqesh; të duhet aq sa një zhvillues i aftë që nuk e ka parë kurrë projektin të jetë produktiv brenda pak ditësh.

• Një README me arkitekturën në një faqe: komponentët kryesorë, rrjedha e të dhënave dhe ku funksionon secili.
• Udhëzime hap pas hapi për ngritjen e projektit në kompjuterin lokal.
• Procesi i publikimit (deployment), i shkruar si runbook që e ekzekuton dikush tjetër.
• Variablat e mjedisit dhe konfigurimi, të listuara me emër dhe qëllim (jo vlerat sekrete).
• Skema e databazës dhe një përshkrim i shkurtër i tabelave dhe lidhjeve kryesore.
• Çdo punë e planifikuar, radhë (queue), webhook dhe integrim, dhe çfarë ndodh kur dështojnë.

4. Të dhënat, kopjet rezervë dhe rikuperimi

• Konfirmim se ku ruhen të dhënat e prodhimit dhe kush ka akses.
• Kopje rezervë automatike me periudhë ruajtjeje të dokumentuar.
• Një rikthim i testuar. Një kopje rezervë që nuk është rikthyer kurrë është supozim, jo mbrojtje.
• Mundësi për të eksportuar të dhënat në format standard (CSV, SQL dump) në çdo kohë.

5. Cilësia dhe testimet

• Testet automatike, nëse ekzistojnë, dhe udhëzimet për t’i ekzekutuar.
• Një listë e problemeve të njohura, shkurtoreve dhe borxhit teknik, e shkruar me ndershmëri. Është shenjë profesionalizmi, jo dobësie.
• Rezultatet e testimit të pranimit (UAT) ose një shënim pranimi i nënshkruar, në përputhje me objektin e rënë dakord.

6. Materialet e dizajnit dhe të përmbajtjes

• Skedarët burimorë të dizajnit (Figma ose ekuivalent), fontet, ikonat dhe materialet e brandit me licencat e tyre.
• Imazhet origjinale, tekstet dhe media në formën e ngarkuar, jo vetëm versionet e kompresuara për web.

7. Transferimi i njohurive dhe mbështetja e mëtejshme

• Të paktën një prezantim, i regjistruar ose live, për arkitekturën, deployment-in dhe pikat më të mundshme të dështimit.
• Një periudhë garancie për gabimet e gjetura pas lansimit, dhe çfarë mbulon ajo.
• Opsionalisht një marrëveshje mirëmbajtjeje mujore me kohë përgjigjeje, që dorëzimi të mos nënkuptojë braktisje.

Tabelë e shpejtë referimi

Si ta kërkosh pa krijuar fërkim

Koha më e mirë për ta përcaktuar dorëzimin e projektit softuerik është para se të nisë puna. Shto në kontratë një klauzolë të shkurtër dorëzimi me artikujt e mësipërm dhe lidhe pagesën e fundit me përmbushjen e tyre. Nëse projekti është tashmë në vazhdim, e njëjta listë funksionon si kërkesë miqësore: “Para se ta mbyllim, ju lutem konfirmoni secilin nga këta artikuj që ta administrojmë sistemin në mënyrë të pavarur.”

Dy këshilla praktike:

• Kërko një provë dorëzimi gjatë projektit. Kërkoji një zhvilluesi të dytë, ose një koleg me njohuri teknike, ta ngrejë projektin vetëm nga dokumentimi. Çdo pyetje që bën është një boshllëk për t’u mbushur sa zhvilluesi origjinal është ende i angazhuar.
• Mbaje pronësinë e llogarive që nga dita e parë. Është shumë më e lehtë ta ftosh një zhvillues në llogaritë e tua sesa t’i transferosh jashtë më vonë.

Kujdes: rregullat mbi pronësinë intelektuale ndryshojnë sipas juridiksionit dhe kontratës. Ky udhëzues është praktik dhe nuk përbën këshillë juridike; marrëveshjet e rëndësishme duhet t’i shqyrtojë një jurist.

Pyetje të shpeshta

Kush e zotëron kodin kur një zhvillues ndërton softuer me porosi për mua?

Varet nga kontrata dhe ligji në fuqi. Pronësia duhet të shkruhet shprehimisht, përfshirë nëse transferimi bëhet në dorëzim apo me pagesën përfundimtare, dhe si trajtohen komponentët open-source. Mos u mbështet te supozimet.

A mjafton një skedar ZIP me kodin?

Rrallë. ZIP-i humb historikun e ndryshimeve, vjetrohet shpejt dhe nuk thotë asgjë për deployment-in apo kredencialet. Një repository në llogarinë tënde, plus dokumentimi, është minimumi praktik.

Kur duhet ta planifikoj dorëzimin?

Në fillim. Vendosi kërkesat e dorëzimit në objektin e punës, rishikoji në mes të projektit dhe verifikoji para pagesës së fundit.

Çfarë bëj nëse zhvilluesi aktual nuk përgjigjet?

Fillo me inventarin e asaj që mund të aksesosh sot: repository-të, hosting-un, domenet dhe kopjet rezervë. Edhe aksesi i pjesshëm mjafton që një zhvillues i pavarur ta auditojë sistemin dhe të planifikojë një marrje të sigurt në dorë.

Merr sërish kontrollin e softuerit tënd

Nëse ke një sistem të ndërtuar nga dikush tjetër dhe nuk je i sigurt çfarë zotëron vërtet, ose po planifikon një projekt të ri dhe do që dorëzimi të bëhet siç duhet që nga dita e parë, ekipi ynë mund të ndihmojë. Ofrojmë audite dorëzimi, dokumentim, marrje në dorë të kodeve ekzistuese dhe mirëmbajtje të vazhdueshme. Kontakto Shkulaku për të kërkuar një konsultë dhe për të diskutuar projektin tënd.