Team augmentation vs outsourcing completo: come scegliere per una software house

Il problema concreto

Una software house con 12 sviluppatori vince un appalto che richiede tre figure senior su stack React/Node che internamente non ha. Il delivery è tra 90 giorni. Il CEO chiede: "Prendiamo qualcuno in staff augmentation o affidiamo il modulo a un partner esterno?"

La risposta sbagliata non dipende dal modello in sé. Dipende dal non aver analizzato tre variabili: accoppiamento architetturale, ownership del codice e velocità di feedback richiesta.

---

Definire i termini senza ambiguità

Team augmentation (o staff augmentation): risorse esterne che lavorano dentro i tuoi processi, con i tuoi tool, sotto la tua direzione tecnica. Il tuo CTO assegna i ticket, fa i code review, decide l'architettura. Il partner fornisce la capacità esecutiva.

Outsourcing completo: deleghi un perimetro funzionale a un team esterno. Loro gestiscono il backlog di quel perimetro, decidono l'architettura interna, consegnano deliverable concordati. Tu definisci i requisiti e validi l'output.

Non sono due varianti dello stesso modello. Hanno strutture di comunicazione, rischio e costo radicalmente diverse.

---

Quando ha senso il team augmentation

1. Il codice è strettamente accoppiato

Se il modulo da sviluppare chiama direttamente servizi interni non documentati, accede a database condivisi, o dipende da convenzioni non scritte note solo al team core, separare il lavoro in un perimetro outsourced è costoso. Ogni decisione richiede una riunione di allineamento.

In questo scenario, un developer esterno che entra nel tuo Jira, partecipa ai daily stand-up e fa PR su GitHub seguendo le tue branch convention è molto più produttivo.

2. Hai già un'architettura definita

Se hai ADR (Architecture Decision Records) scritti, un tech lead disponibile a fare onboarding e code review, e una test suite che funziona come rete di sicurezza, il costo di integrare una risorsa esterna è basso. Il rischio di deviazione qualitativa è contenuto.

3. Il fabbisogno è temporaneo e misurabile

"Mi servono 2 senior React per 4 mesi" è un caso perfetto per l'augmentation. Il perimetro è chiaro, la fine è definita, non vuoi trasferire know-how architetturale a un terzo.

---

Quando ha senso l'outsourcing completo

1. Il modulo è disaccoppiato o disaccoppiabile

Un servizio di notifiche, un sistema di reportistica, un'integrazione con un ERP di terze parti: sono tutti candidati naturali all'outsourcing perché comunicano via API ben definite. Se puoi scrivere un contratto d'interfaccia (un OpenAPI spec, un contratto Pact, uno schema GraphQL), puoi outsourcare il modulo.

# Esempio: contratto minimo per un servizio di notifiche outsourcato
openapi: 3.1.0
info:
  title: Notification Service
  version: 1.0.0
paths:
  /notifications:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [userId, channel, payload]
              properties:
                userId: { type: string }
                channel: { type: string, enum: [email, sms, push] }
                payload: { type: object }
      responses:
        '202': { description: Accepted }

Se riesci a scrivere questo spec prima di ingaggiare il partner, l'outsourcing funzionerà. Se non riesci, probabilmente il modulo non è abbastanza disaccoppiato.

2. Non hai bandwidth manageriale

L'augmentation richiede che qualcuno in casa gestisca le risorse esterne: onboarding, code review, feedback quotidiano. Se il tuo tech lead è già al 100% sul progetto principale, aggiungere persone da gestire non scala. In quel caso, delegare la gestione a un partner esterno ha senso.

3. Vuoi trasferire il rischio operativo

Con un contratto di outsourcing ben scritto (SLA, definition of done, ownership dei bug post-delivery), il rischio di slittamento si sposta sul partner. Con l'augmentation, il rischio resta tuo perché le risorse lavorano sotto tua direzione.

---

La matrice decisionale

| Criterio | Team Augmentation | Outsourcing Completo | |---|---|---| | Accoppiamento del codice | Alto | Basso / API-first | | Bandwidth del tech lead | Disponibile | Scarsa o assente | | Ownership del codice | Vuoi mantenerla | Accetti di condividerla | | Fabbisogno | Picco temporaneo | Perimetro funzionale stabile | | Rischio di qualità | Controllato internamente | Governato da contratto | | Velocità di feedback | Alta (daily) | Media (sprint review) |

---

L'errore più comune

Scegliere l'outsourcing completo su un modulo altamente accoppiato perché "così non devo gestire le persone". Risultato: il partner consegna codice che non si integra, le riunioni di allineamento si moltiplicano, i costi esplodono. In pratica si paga il peggio di entrambi i modelli.

L'altro errore speculare: usare l'augmentation su un perimetro che potrebbe essere autonomo, senza mai investire nel disaccoppiamento. Il team esterno diventa dipendente dalle decisioni del team interno su ogni piccola cosa, la velocità crolla.

---

Take-away operativo

Prima di scegliere il modello, fai questa verifica:

1. Scrivi l'interfaccia del modulo che devi sviluppare. Se riesci a farlo in meno di un'ora, il modulo è candidato all'outsourcing. Se non riesci, probabilmente hai bisogno di augmentation.
2. Conta le ore settimanali che il tuo tech lead può dedicare alla supervisione esterna. Sotto le 5 ore/settimana, l'augmentation non è sostenibile senza degradare la qualità.
3. Definisci chi possiede il backlog: se vuole tenerlo tu, augmentation. Se sei disposto a delegarlo con i criteri di accettazione, outsourcing.

Non esiste il modello universalmente migliore. Esiste quello giusto per il contesto specifico del tuo progetto in questo momento.

---

Evviva Group lavora con software house in entrambe le modalità, white-label. Se stai valutando quale modello applicare al tuo prossimo progetto, possiamo aiutarti a fare l'analisi.