Pazīstams gadījums: sadarbība ar aģentūru beidzas mierīgi. Pēdējais rēķins ir apmaksāts, un aģentūra atsūta zip failu un paroļu sarakstu. Pēc diviem mēnešiem jaunā komanda mēģina ieviest nelielu izmaiņu un atklāj, ka zip fails neatbilst tam, kas darbojas dzīvajā vidē, maksājumu integrācijas paroles nav, un neviens nezina, kāpēc katru nakti trijos tiek palaists kāds ieplānots darbs. Nodošana notikusi, bet tā nav bijusi pilnīga.

Īsumā#

Laba nodošana nodod četras lietas:

piekļuvi un īpašumtiesības uz katru kontu;
precīzu kodu un konfigurāciju, kas darbojas dzīvajā vidē;
zināšanas, kas vajadzīgas, lai sistēmu droši mainītu;
sarakstu ar to, kas ir nepabeigts vai viegli sabojājams.

Prasiet tās šādā secībā: kontus vēlāk atgūt ir visgrūtāk, bet zināšanas pazūd visātrāk, tiklīdz cilvēki sāk strādāt citur. Pirms pēdējā rēķina vai uzteikuma termiņa beigām pārbaudiet, vai nodošana ir pilnīga: lai kāds cits, nevis aizejošais izstrādātājs, ievieš dzīvajā vidē nelielu izmaiņu un atjauno rezerves kopiju testa vidē. Ja abas lietas izdodas, izmantojot tikai nodoto, nodošana ir pilnīga. Ja kaut kas trūkst, nodošana nav pabeigta, lai cik laba būtu dokumentācija.

Vispirms: konti un īpašumtiesības#

Visam jāpieder jūsu uzņēmumam, bet aizejošais izstrādātājs jānoņem vai jāatstāj tikai kā lietotājs.

Domēna reģistrators un DNS.
Hostinga vai mākoņpakalpojumu konts un maksājumi par to.
Koda repozitoriji.
Satura pārvaldības sistēmas vai veikala administratoru konti.
Trešo pušu pakalpojumi: maksājumi, e-pastu sūtīšana, piegādes integrācijas, analītika, kļūdu uzraudzība.
API atslēgas un piekļuves dati katrai integrācijai.
Maksas tēmu, spraudņu un bibliotēku licences.

Pilnu sarakstu un to, kā notiek katra konta nodošana, skatiet rakstā kam pieder jūsu mājaslapa.

Otrkārt: kods un konfigurācija, kas patiešām darbojas#

Repozitorijs ar visu vēsturi, ne tikai jaunākie faili.
Apstiprinājums, kurš zars vai kura versija šobrīd darbojas dzīvajā vidē.
Vides konfigurācija: mainīgie, slepenās atslēgas un iestatījumi, kas glabāti droši, nevis e-pastā.
Deploy: kā izmaiņa nonāk dzīvajā vidē, tostarp skripti, automatizētie procesi (CI/CD) un darbības, kas jāveic ar roku.
Ieplānotie darbi: kas tiek izpildīts, kad un kāpēc.
Piekļuve datubāzei un nesena rezerves kopija.
Infrastruktūras dati: serveri, pakalpojumi un to versijas.

Treškārt: zināšanas#

Arhitektūras pārskats: sistēmas galvenās daļas un to savstarpējie savienojumi.
Kā palaist projektu lokālā vidē.
Integrācijas: ko katra dara, kas ir kontaktpersona otrā pusē un kādas ir zināmās īpatnības.
Zināmās problēmas, apvedceļi un vietas, kas sabojājas, ja tām pieskaras.
Nepabeigtais darbs un viss, kas lietotājiem solīts, bet nav piegādāts.
Ierakstīta saruna, kurā aizejošais izstrādātājs parāda sistēmu un atbild uz jautājumiem.

Nodošanas dokumentam nav jābūt garam. Tam jābūt precīzam.

Ceturtkārt: risku saraksts#

Pajautājiet tieši: kas jūs uztrauc? Aizejošais izstrādātājs parasti zina, kuras daļas ir trauslas, kuras atkarības ir novecojušas un kādi saīsinājumi izdarīti termiņu spiediena dēļ. Pierakstiet atbildes.

Pārbaude pirms sadarbības beigām#

Kāds no jūsu puses vai jaunā komanda noklonē repozitoriju un palaiž projektu, izmantojot tikai nodošanas dokumentus.
Šis cilvēks ievieš dzīvajā vidē nelielu, nekaitīgu izmaiņu.
Viņš atjauno rezerves kopiju testa vidē un palaiž lietotni.
Viņš piesakās katrā saraksta kontā ar uzņēmuma piekļuves datiem.

Viss, kas neizdodas, ir robs, ko jānovērš, kamēr aizejošais izstrādātājs vēl ir sasniedzams.

Nākamreiz iekļaujiet to līgumā#

Nodošanas pienākumi jāiekļauj sākotnējā līgumā: kontu īpašumtiesības uzņēmumam no paša sākuma, dokumentācija visā sadarbības laikā un noteikts nodošanas periods beigās.

Ja izstrādātājs jau pārstājis atbildēt, situācija ir citāda un steidzamāka. Pirmie soļi aprakstīti rakstā kam pieder jūsu mājaslapa, sadaļā par nesasniedzamu izstrādātāju.

Nevo pārņem sistēmas no iepriekšējiem izstrādātājiem un aģentūrām. Kā šis darbs sākas, aprakstīts lapā koda pārņemšana.

Projekta pārņemšana no izstrādātāja, kurš aiziet