Ovvero: perché dopo anni non esistono interventi “dovuti”
Nel mondo dello sviluppo software c’è una figura mitologica che compare puntualmente quando un progetto ha qualche anno sulle spalle: il bug fantasma.
Nessuno lo ha mai visto chiaramente, non è riproducibile con precisione, non è documentato, ma c’è.
E, soprattutto, qualcuno è convinto che debba essere sistemato gratuitamente.
Questo articolo nasce da un caso reale (molto reale) e vuole chiarire alcuni concetti fondamentali che, sorprendentemente, non sono ancora così scontati.
- Ovvero: perché dopo anni non esistono interventi “dovuti”
- Un progetto non nasce nel vuoto (e non vive per sempre)
- “C’è un bug” non è una diagnosi
- No, la “verifica gratuita” non esiste
- L’intervento recente non crea una garanzia eterna
- Cliente finale ≠ cliente contrattuale
- Dopo anni, si parla solo di nuova assistenza
- Conclusione
Un progetto non nasce nel vuoto (e non vive per sempre)
Ogni software nasce in un contesto preciso:
- una versione specifica di WordPress
- una versione di PHP
- un set di plugin attivi
- un’infrastruttura server
- requisiti chiari (si spera)
Nel nostro caso, il plugin in questione è stato progettato nel novembre 2021, su richiesta di un cliente intermediario, con cui esistevano rapporti contrattuali diretti.
Il cliente finale era un altro soggetto, che oggi — anni dopo — segnala un presunto malfunzionamento.
Ed è qui che iniziano i problemi.
“C’è un bug” non è una diagnosi
Dire “c’è un bug” non equivale a:
- dimostrare che il bug esista
- dimostrare che dipenda dal plugin
- dimostrare che fosse presente all’origine
- dimostrare che sia coperto da precedenti accordi
Un comportamento anomalo può dipendere da decine di fattori:
- aggiornamenti di WordPress
- aggiornamenti PHP
- altri plugin
- temi
- modifiche server
- utilizzi diversi da quelli originari
Senza evidenze tecniche oggettive, il bug resta un’ipotesi.
E le ipotesi, nel mondo reale, non sono attività correttive dovute.
No, la “verifica gratuita” non esiste
Un altro grande classico:
“Chiediamo solo di verificare se è un bug”
La verifica è lavoro.
Richiede tempo, competenze, accesso agli ambienti, analisi del contesto attuale e confronto con quello originario.
Pretendere che sia gratuita equivale a chiedere a un medico:
“Dottore, può solo guardare, senza visitarmi?”
Spoiler: no.
L’intervento recente non crea una garanzia eterna
Nel nostro caso, era stato effettuato un intervento puntuale il mese precedente, sulla base di indicazioni ricevute in modo non strutturato.
Quel tipo di intervento:
- non certifica l’esistenza di un bug
- non valida l’intero plugin
- non riapre progetti chiusi anni prima
- non crea una garanzia implicita
È assistenza spot. Punto.
Cliente finale ≠ cliente contrattuale
Altro tema spesso sottovalutato:
se i rapporti commerciali sono intercorsi con un intermediario, è lì che risiedono obblighi e responsabilità.
Il cliente finale:
- è legittimato a segnalare problemi
- non è automaticamente titolare di diritti contrattuali diretti
- non può ridefinire retroattivamente ambiti e garanzie
Questo non è cinismo. È diritto commerciale.
Dopo anni, si parla solo di nuova assistenza
Riassumendo:
- il progetto ha anni
- il contesto è cambiato
- il bug non è dimostrato
- non esistono garanzie attive
- non esistono interventi “dovuti”
L’unico terreno possibile è quello della nuova assistenza tecnica, con:
- ambito definito
- stime chiare
- costi trasparenti
E sì: anche solo per capire se c’è davvero un problema.
Conclusione
Il software non è una pianta grassa:
non lo annaffi una volta e poi sopravvive per anni senza manutenzione.
E soprattutto:
se un progetto è chiuso, consegnato e pagato,
non torna improvvisamente in garanzia perché “qualcosa ora non va”.
Da Sferica non abbiamo nulla contro i bug.
Ma abbiamo molto contro le leggende metropolitane.
