Una software house che rifiuta un progetto perché il team è pieno perde due volte: il progetto e il cliente, che va da un altro e spesso ci resta. Un partner esterno che prende i lavori periferici — il front-end, un'integrazione, un modulo isolato — libera il team interno per la parte che nessun altro può fare.
Cosa si può dare fuori senza creare problemi
| Tipo di lavoro | Si affida bene? | Perché |
|---|---|---|
| Front-end su API già definite | Molto bene | Il contratto è esplicito, il confine netto |
| Un modulo isolato con interfaccia chiara | Bene | Si integra senza toccare il resto |
| Integrazione con un servizio esterno | Bene | Lavoro delimitato e verificabile |
| Migrazione o aggiornamento tecnologico | Bene | Meccanico, tedioso, con criteri di successo chiari |
| Il cuore del vostro prodotto | No | È la conoscenza che vi distingue: non va fuori |
| Un progetto senza specifiche | No | Non è un problema di chi lo fa, è un problema di cosa |
La regola pratica: si affida bene ciò che ha un confine definibile in una pagina. Dove il confine non si riesce a scrivere, il lavoro esterno costa più di quello interno.
Come si lavora accanto a un team esistente
- 01
Le vostre regole, non le nostre
Repository, convenzioni, processo di revisione, stile: ci adattiamo. Un partner che impone il proprio modo di lavorare crea un secondo codice dentro il vostro.
- 02
Un referente tecnico da parte vostra
Una persona che risponde alle domande. È il fattore che determina se il lavoro esterno riesce, molto più della bravura di chi scrive.
- 03
Consegne piccole e frequenti
Meglio dieci consegne verificabili che una grande alla fine: gli scostamenti si vedono presto, quando costano poco.
- 04
Test e documentazione inclusi
Perché il codice resti manutenibile dal vostro team dopo che noi siamo usciti. È il criterio con cui si giudica un lavoro affidato fuori.
Il vostro sito serve a essere verificati
Chi valuta una software house lo fa con criteri tecnici e di rischio: vuole sapere su cosa lavorate, da quanto, quante persone siete e cosa succede se il progetto vi supera. Un sito costruito su parole generiche — «soluzioni digitali innovative» — fallisce esattamente questa verifica, perché non contiene nessuna delle informazioni cercate.
Quello che un valutatore cerca in tre minuti
- Le tecnologie, dette per nome. È un filtro, e va bene che filtri.
- La dimensione del team e da quanto esistete.
- Progetti simili al suo, anche anonimizzati, con l'ordine di grandezza.
- Come gestite manutenzione, incidenti e continuità.
- Certificazioni e pratiche di sicurezza, se vendete a clienti strutturati.
- Chi sono le persone tecniche di riferimento.
I contenuti tecnici, che qui hanno un doppio scopo
Un articolo su un problema tecnico reale — una migrazione difficile, un'integrazione con un gestionale diffuso, una scelta di architettura e perché — porta due tipi di persone: clienti che hanno quel problema e sviluppatori che stanno valutando dove andare a lavorare. Per una software house il secondo effetto vale spesso quanto il primo.
Da dove si parte
Di solito da un modulo o da un front-end delimitato, per vedere come funziona la collaborazione su qualcosa di poco rischioso. Le web app partono a partire da 690 €, le app mobile a partire da 890 €. Se serve invece rifare il vostro sito perché regga una verifica, si parte a partire da 390 €.
Domande frequenti
- Cosa conviene affidare a un partner esterno?
- Ciò che ha un confine definibile in una pagina: front-end su API già definite, un modulo isolato, un'integrazione, una migrazione. Il cuore del vostro prodotto no — è la conoscenza che vi distingue e non va fuori.
- Vi adattate al nostro modo di lavorare?
- Sì: repository, convenzioni, revisione e stile sono i vostri. Un partner che impone il proprio modo di lavorare crea un secondo codice dentro il vostro, ed è un problema che si paga per anni.
- Cosa determina la riuscita di un lavoro affidato fuori?
- Avere un vostro referente tecnico che risponde alle domande, più delle capacità di chi scrive il codice. Subito dopo: consegne piccole e frequenti, così gli scostamenti si vedono quando costano poco.
- Come si gestisce la proprietà del codice?
- Per iscritto e prima di iniziare, insieme a riservatezza e accesso ai dati del vostro cliente finale. Se lavoriamo su dati di terzi, i ruoli formali e le misure vanno definiti con i vostri consulenti.
- A cosa serve il sito di una software house?
- A essere verificati. Chi valuta cerca tecnologie dette per nome, dimensione del team, progetti simili e come gestite manutenzione e incidenti: un sito di parole generiche fallisce quella verifica perché non contiene nessuna di quelle informazioni.