Onshore, nearshore, offshore: che cosa significano i termini
I termini descrivono dove si trova il partner rispetto a voi. Onshore indica un partner nel vostro paese. Nearshore indica un partner in un paese vicino, di solito nello stesso fuso orario o in uno adiacente. Per un’azienda italiana si tratta, ad esempio, di un partner in Slovenia, in Austria o altrove nell’Europa centrale. Offshore indica un paese lontano con una forte differenza di fuso orario.
La localizzazione è solo metà della decisione. L’altra metà è il modello di collaborazione, cioè chi guida il lavoro e chi risponde del risultato:
| Modello | Chi guida il lavoro | Chi risponde del risultato | Uso tipico |
|---|---|---|---|
| Team interno | Voi | Voi | Prodotto centrale di lungo periodo |
| Team di sviluppo dedicato | Il responsabile del partner con il vostro product owner | Condivisa, secondo il contratto | Progetti più lunghi che richiedono un team stabile e scalabile |
| Staff augmentation | Voi | Voi | Colmare lacune di competenze o aggiungere capacità rapidamente |
| Outsourcing a progetto | Il partner | Il partner, per il perimetro concordato | Lavori ben specificati e limitati nel tempo |
Ogni modello di collaborazione può essere onshore, nearshore o offshore. Un team dedicato nearshore e un contratto di staff augmentation offshore sono accordi completamente diversi, anche se entrambi vengono chiamati «outsourcing».
Quando funziona ciascun modello
- Il team interno è la scelta migliore quando il software è il vostro vantaggio competitivo centrale, il lavoro è continuativo e dipende da una conoscenza di dominio approfondita. Il prezzo sono assunzioni più lente e minore flessibilità.
- Un team dedicato nearshore è adatto a progetti più lunghi con collaborazione regolare, spesso quotidiana, e a un team che può crescere o ridursi insieme al lavoro. Con orari sovrapposti, pianificazione comune, revisioni e domande rapide fanno parte della normale giornata lavorativa.
- La staff augmentation è il modo più rapido per aggiungere uno specialista, ad esempio un data engineer o uno sviluppatore mobile, ma solo se avete già una leadership tecnica solida. Senza, comprate ore, non risultati.
- L’outsourcing a progetto è adatto a un’integrazione, a una migrazione o a un modulo separato con requisiti chiari. Diventa difficile quando i requisiti cambiano continuamente.
- L’offshore può funzionare per lavori specificati con chiarezza, con poca conoscenza di dominio e senza bisogno di collaborazione in tempo reale.
Nella pratica le combinazioni sono frequenti: product ownership e architettura in azienda, un team dedicato per la maggior parte dello sviluppo e uno specialista esterno per una competenza specifica.
Valutare i partner sulla qualità, non sulla tariffa oraria
La tariffa oraria è il numero più facile da confrontare e il meno utile. Ciò che decide il risultato è se il partner consegna, con un ritmo costante, software funzionante e manutenibile. Nel confronto delle offerte guardi al costo totale di possesso: tempi di onboarding, impegno di gestione da parte vostra, rilavorazioni, ritardi e costo di un eventuale cambio di partner.
Concentri la valutazione sulle prove:
- referenze da progetti comparabili, con persone che può chiamare,
- seniority e stabilità del team effettivo, non di quello commerciale,
- pratiche di ingegneria: code review, test automatici, CI/CD e documentazione,
- pratiche di sicurezza e, dove pertinente, certificazioni come ISO/IEC 27001,
- comunicazione: un referente nominato, reporting regolare e padronanza della vostra lingua di lavoro, italiano o inglese.
Governance e comunicazione
La maggior parte dei problemi di outsourcing sono problemi di gestione. Stabilisca fin dall’inizio chi decide le priorità (il vostro product owner), chi approva l’architettura, che cosa significa «completato» e come si riferisce sull’avanzamento. Gli strumenti condivisi aiutano: il vostro repository, il vostro sistema di ticketing e la vostra pipeline CI, in modo che il lavoro sia visibile e resti a voi.
La sovrapposizione degli orari conta più di quanto sembri. Un team che condivide gran parte della vostra giornata lavorativa può partecipare agli stand-up, rispondere alle domande in pochi minuti e lavorare a fianco dei vostri sviluppatori. Con una forte differenza di fuso, ogni requisito poco chiaro costa un giorno.
GDPR, NIS2 e regole di settore
Se il partner può accedere a dati personali, ad esempio tramite dati di test, log o supporto alla produzione, agisce come responsabile del trattamento e serve un accordo sul trattamento ai sensi dell’articolo 28 del GDPR. Le regole del GDPR sui trasferimenti verso paesi terzi (capo V) si applicano quando i dati personali lasciano l’UE/SEE. Un partner con sede e trattamento nell’UE/SEE evita questa questione, purché vi si trovino anche i suoi sub-responsabili e i suoi strumenti, quindi ne chieda l’elenco.
Se la vostra organizzazione rientra nella direttiva NIS2 (UE) 2022/2555, recepita in Italia con il D.Lgs. 138/2024, la sicurezza della catena di approvvigionamento è una delle misure di gestione del rischio obbligatorie. La direttiva richiede di tenere conto delle vulnerabilità dei fornitori diretti e della qualità delle loro pratiche di cibersicurezza, comprese le procedure di sviluppo sicuro. Un partner di sviluppo è esattamente un fornitore di questo tipo: inserisca nel contratto requisiti di sicurezza, notifica degli incidenti e diritti di audit.
Nel settore finanziario il regolamento DORA (UE) 2022/2554 prevede requisiti specifici per i fornitori terzi di servizi TIC. Sanità e pubblica amministrazione hanno regole proprie. Le verifichi prima della firma, non dopo.
Contratto, proprietà intellettuale e uscita
Il diritto dell’UE attribuisce al datore di lavoro i diritti economici sul software creato dai dipendenti nell’esercizio delle loro mansioni. Per il lavoro svolto da un’azienda esterna non si affidi a supposizioni: il contratto deve cedervi chiaramente, o concedervi in esclusiva, i diritti su codice sorgente, documentazione e altri deliverable. Tutele pratiche:
- codice sorgente nel vostro repository fin dal primo giorno, con account intestati all’azienda,
- un elenco chiaro dei componenti open source e delle relative licenze,
- riservatezza che copra i vostri dati e la vostra logica di business,
- termini di preavviso e tempi concordati per ampliare o ridurre il team,
- un piano di uscita: consegna di codice, documentazione, credenziali e conoscenza, con l’obbligo del partner di supportare la transizione.
Validare il partner con un pilota di 30 giorni
Un’offerta mostra come un partner vende. Un pilota mostra come lavora. Affidi al partner selezionato un compito piccolo ma reale, concordi in anticipo i criteri di successo e lo svolga nel vostro ambiente: prima onboarding e un compito semplice, poi una consegna con code review e test, poi un compito che tocca il vostro dominio o un’integrazione e infine una retrospettiva con i vostri sviluppatori. Lo strumento qui sopra genera un piano di pilota e una checklist ponderata sulla vostra situazione.
Presti attenzione ai segnali d’allarme: non può conoscere le persone che faranno il lavoro, il partner vuole tenere il codice o la proprietà intellettuale, le referenze non sono raggiungibili, viene promesso un prezzo basso prima che qualcuno abbia compreso i requisiti, oppure le risposte su sicurezza e subappaltatori restano vaghe.
Se il progetto comprende integrazioni con l’ERP, consulti anche la checklist per la scelta del sistema ERP. Se desidera parlare del suo progetto software e del modello di delivery più adatto, ci contatti.
