Il software dipende da una sola persona: come proteggere l’azienda in tempo

Se il software dipende da una sola persona, il rischio non è il programma ma cosa succede se quella persona non c’è. Il momento giusto per agire è quando è ancora disponibile: va verificato dove sono codice e accessi, fatte scrivere le procedure critiche e affiancata da qualcun altro. Sono interventi poco costosi, che diventano molto difficili il giorno dopo le dimissioni.

Tra gli sviluppatori c’è un modo un po' brutale per chiamarlo: quante persone dovrebbero essere investite da un autobus perché il progetto si fermi? Se la risposta è una, sei nella situazione di molte piccole e medie aziende. Può essere un dipendente, il consulente storico o un socio che ha scritto il programma anni fa.

Un punto di metodo: questo non è un problema della persona, che anzi spesso ha tenuto in piedi l’azienda per anni. Va affrontato con rispetto. Presentarlo come un controllo sul suo lavoro è il modo più sicuro per ottenere poca collaborazione.

Cosa recuperare subito

Questa lista richiede poco tempo e protegge da quasi tutti gli scenari peggiori. Ti serve anche se non pensi affatto che possa andarsene.

1. Il codice sorgente. Dove si trova? È su un sistema di controllo delle versioni o sul computer di una persona? Corrisponde a ciò che è in uso?
2. Le password. Database, server, dominio, servizi cloud, certificati. Devono stare in un archivio aziendale protetto, non nella testa di qualcuno o su un suo account personale.
3. Gli intestatari. Dominio, hosting e account dei fornitori devono essere intestati all’azienda. Controllalo: è frequente trovare servizi attivati con un indirizzo email personale.
4. I contratti. Chi paga cosa e dove arrivano le scadenze, compresi i rinnovi automatici e i certificati.
5. I backup. Chi li controlla? Quando è stato provato l’ultimo ripristino?
6. La prova del nove. Fai generare il programma da zero su un computer pulito. Se ci riesce solo su un vecchio portatile, è un’informazione importantissima.

Di chi sono davvero il codice e i diritti?

Dipende dal rapporto con chi l’ha scritto. Per i dipendenti, l’articolo 12-bis della legge sul diritto d’autore attribuisce al datore di lavoro, salvo patto contrario, i diritti economici sui programmi creati nell’esecuzione delle mansioni. Per un consulente esterno, la situazione è meno lineare e dipende molto dagli accordi presi. Se non c’è nulla di scritto, questo è il momento di sistemare le cose con un legale, finché il rapporto è buono.

Come far uscire le conoscenze dalla testa

Chiedere a un programmatore impegnato di “scrivere tutta la documentazione” è un ottimo modo per non ottenere nulla. Funzionano molto meglio richieste piccole e concrete.

Le procedure di emergenza

Prima di tutto ciò che servirebbe se si bloccasse tutto, in una pagina:

• come si riavvia il sistema e come si controlla che funzioni;
• come si ripristina un backup;
• cosa si fa nelle operazioni di fine mese e fine anno;
• quali errori capitano spesso e come si risolvono.

Le regole che nessuno sa

Qui c’è il vero valore: gli arrotondamenti particolari, i clienti con condizioni speciali, i motivi di certe scelte. Il metodo migliore è fare domande durante il lavoro, e registrare le risposte. Bastano sessioni brevi e regolari, anche di un’ora a settimana, in cui si parte da un problema vero.

Gli schermi registrati

Far registrare lo schermo mentre esegue un’operazione, spiegandola a voce, richiede pochi minuti e conserva moltissime informazioni. In un secondo momento, si può trascrivere e organizzare il contenuto. L’importante è che la registrazione esista.

Affiancare qualcuno

Nessun documento sostituisce un’altra persona che abbia già messo le mani nel sistema. Si può fare in tre modi:

La regola pratica è di far fare a un’altra persona il prossimo intervento, con la persona esperta che controlla, invece del contrario.

Se le dimissioni sono già arrivate

Il tempo è poco, quindi concentra lo sforzo. Ecco le priorità nelle settimane che restano:

1. Prima settimana: accessi, codice sorgente, prova di generazione del programma e ripristino di un backup.
2. Poi: procedure di emergenza e di fine periodo, con registrazioni.
3. Poi: un elenco dei problemi noti e delle cose rimaste a metà.
4. Infine: passaggio guidato alla persona o al fornitore che subentrerà.

Verifica anche la possibilità di una consulenza dopo l’uscita, per qualche mese: spesso costa poco, in confronto a ciò che evita. Quando la persona lascia l’azienda, disattiva le sue utenze e cambia le password condivise, con ordine e senza drammi.

Se invece la persona non è più raggiungibile, la situazione è simile a quando il fornitore del software ha chiuso: la prima cosa è mettere al sicuro i dati e ricostruire il funzionamento del sistema.

La domanda dietro la domanda

A volte il problema non si può risolvere con la documentazione, perché è la tecnologia stessa a restringere il campo: chi lavora ancora con linguaggi fuori produzione è difficile da trovare, e il rischio si ripresenterà con la persona successiva. In questo caso, vale la pena di ragionare sul debito tecnico accumulato e su quanto il sistema sia ormai legacy.

Se decidi di sostituire il programma, la persona che lo conosce è la risorsa più preziosa del progetto, non un ostacolo. Il metodo graduale della guida alla modernizzazione del software legacy funziona molto meglio con il suo aiuto, finché è possibile. E ricorda di evitare di ricreare lo stesso rischio con il nuovo fornitore: ecco le domande da fare.

Domande frequenti

Come ne parlo senza che si senta sotto accusa?

Parti dal rischio per l’azienda, non dalla persona: “se ti ammali per un mese, come facciamo?”. Riconosci il valore di ciò che ha fatto e dagli tempo vero per farlo, togliendo qualcos’altro dalla sua lista. Se lo aggiungi soltanto al lavoro di sempre, non succederà.

La persona rifiuta di condividere le informazioni. Cosa posso fare?

Se è un dipendente, gli accessi e il codice appartengono di norma all’azienda: chiedi consiglio a chi segue i rapporti di lavoro. Se è un fornitore, guarda il contratto. In entrambi i casi, muoviti presto.

Quanta documentazione serve davvero?

Meno di quanto si pensi: procedure di emergenza, schema generale, regole non evidenti. Una documentazione breve e aggiornata vale più di un manuale enorme che nessuno legge.