Il rischio non inizia con la lettera di dimissioni. Inizia settimane prima, quando l'ingegnere è ancora connesso a ogni repository, ha ancora accesso completo ai documenti di progettazione, e ha già iniziato a pensare al passo successivo. Quella finestra di tempo è silenziosa, non segnalata, e sembra un martedi qualunque. Ed è anche il momento in cui una startup perde la traccia piu chiara di chi ha effettivamente costruito cosa.
Cosa esce davvero dalla porta
Raramente e il prodotto finito. Il repository di produzione di solito e a posto: ha una cronologia dei commit, un registro modifiche reale, e piu di una persona che puo garantirne l'autenticita. Cio che sparisce e tutto cio che gli sta intorno. Un repository privato creato per un primo prototipo prima ancora che esistesse quello "ufficiale". Un documento di progettazione incollato in una email personale perche quel giorno Slack non funzionava. Un branch che nessuno ha unito perche la funzionalita e stata rimandata, ma che contiene ancora la prima versione funzionante di un'idea che l'azienda ha poi lanciato sotto un altro nome. Niente di tutto questo sembra importante finche la persona fa parte del team. Tutto questo diventa contestato il giorno in cui non ne fa piu parte.
Un co-fondatore tecnico che se ne va dopo un dissenso e la versione piu netta di questo problema. Due persone possono ricordare gli stessi sei mesi in modo completamente diverso, e una volta che il rapporto si e rotto, non esiste piu un racconto condiviso di chi ha scritto quale riga per primo, di chi ha disegnato lo schizzo diventato architettura, o di quando un'idea ha effettivamente preso forma. Cio che resta e memoria contro memoria, e questo non e una prova.
Non riguarda solo i fondatori. Un collaboratore esterno che ha costruito la prima versione di una funzionalita prima di essere assunto a tempo pieno. Uno stagista il cui progetto estivo e diventato silenziosamente un elemento centrale del prodotto. Un freelance che ha disegnato lo schema architetturale originale. Tutti loro lasciano lo stesso tipo di vuoto, di solito senza che nessuno se ne accorga finche una controversia non costringe qualcuno a cercare una prova che non e mai stata conservata.
Perche sigillare "alle tappe principali" lascia la falla aperta
La maggior parte dei team tecnici che ci pensa, ci pensa nel momento sbagliato. Una release viene taggata. Un contratto viene firmato. Quello viene sigillato, ammesso che qualcosa lo venga. Il branch esplorativo che ha dato forma alla release, il primo prototipo che ha dimostrato che l'idea era anche solo realizzabile, il documento di progettazione interno su cui la release si basa davvero: tutto questo raramente riceve lo stesso trattamento, perche nessuno pensava a un addio mentre si scriveva ancora codice insieme. Questo e esattamente al contrario. Il materiale con la traccia documentale piu debole e proprio quello di cui un ingegnere in uscita ha il ricordo piu chiaro, e spesso l'istinto piu forte di rivendicare il merito.
Cosa stabilisce davvero la sigillatura continua
La soluzione non e un team legale piu grande. E trattare la sigillatura come parte ordinaria di come viene salvato il lavoro tecnico, non come un passaggio riservato a lanci e firme. In pratica significa un'abitudine semplice come un merge sul branch principale: codice sorgente sigillato con cadenza regolare invece che solo al momento della release, un documento di progettazione sigillato il giorno in cui viene condiviso con il team invece del giorno in cui viene finalizzato, un primo prototipo sigillato nella settimana in cui gira per la prima volta invece che mesi dopo, ammesso che accada. Niente di tutto questo dipende dal ricordarsi che un addio potrebbe verificarsi. Deve solo essere gia il modo in cui il team lavora. Ai sensi dell'articolo 41 del regolamento eIDAS, una marca temporale elettronica qualificata gode di una presunzione di accuratezza della data e dell'ora che riporta, e dell'integrita dei dati che copre. In Svizzera, una firma rilasciata tramite un fornitore accreditato ZertES ha lo stesso valore giuridico di una firma autografa. Nessuno dei due quadri normativi si preoccupa di chi sia ancora dipendente quando alla fine emerge una controversia. Entrambi si preoccupano di cosa e stato registrato e quando, che e proprio la parte della storia che non cambia a seconda di chi la racconta.
Si immaginino due fondatori che costruiscono insieme la prima versione funzionante di un prodotto, e poi si separano male diciotto mesi dopo. Se il primo prototipo e il documento di progettazione che vi ha portato sono stati sigillati la settimana in cui sono stati scritti, esiste una registrazione datata e a prova di manomissione, indipendente dalla memoria o dal rapporto attuale di entrambi. Se non lo sono stati, la controversia si riduce a chi risulta piu convincente, una posizione in cui nessuno dei due fondatori dovrebbe voler trovarsi.
Cosa non fa
La sigillatura non sostituisce un contratto di lavoro o una clausola di cessione della proprieta intellettuale, e non decide da sola una controversia. Un'azienda ha comunque bisogno degli accordi di base che stabiliscono innanzitutto a chi appartiene il lavoro prodotto. Cio che la sigillatura aggiunge e la registrazione probatoria di cui una controversia ha davvero bisogno una volta che quegli accordi sono in vigore: la prova di cosa esisteva, in quale forma, e quando, che nessuna delle due parti puo riscrivere silenziosamente dopo la fine del rapporto.
Renderlo un'abitudine prima dell'addio, non dopo
Nel momento in cui qualcuno da le dimissioni, e gia troppo tardi per iniziare a sigillare il lavoro che contava di piu. Le startup che evitano questo scontro sono quelle che hanno reso la sigillatura parte del modo in cui salvano il lavoro tecnico fin dall'inizio, cosi come hanno reso il controllo di versione parte del modo in cui lo scrivono. Si veda come funziona questo per i team software e IP prima che il prossimo addio, previsto o meno, renda la domanda urgente.
