Come offrire sviluppo software senza un team interno

Ci sono tre modi per offrire sviluppo software senza avere sviluppatori in azienda: assumere una persona, affidare l'intero progetto a un partner tecnico che lavora dietro al tuo marchio, oppure affiancare sviluppatori esterni alle persone che hai già. Per un progetto isolato con una scadenza vicina la strada praticabile è quasi sempre la seconda, perché sposta il lavoro tecnico su chi lo fa tutti i giorni e ti lascia il rapporto con il cliente. L'assunzione diventa sensata quando il lavoro di sviluppo è continuativo e prevedibile per almeno un anno.

Se un cliente ti ha chiesto un gestionale o un'app e stai decidendo se rifiutare, assumere di corsa o cercare un partner, alla fine di questa guida saprai quale strada regge nel tuo caso, come si passa un progetto e cosa mettere per iscritto.

Cosa serve prima di iniziare

• Una richiesta del cliente messa per iscritto, anche grezza: due pagine su cosa non funziona oggi, chi lo subisce e con che frequenza. Senza, nessun partner può stimare.
• Il quadro dei sistemi che il software dovrà toccare: gestionale, e-commerce, fatturazione, posta. Le integrazioni sono la voce che sposta di più le stime.
• Una scadenza reale del cliente, per esempio una fiera o un rinnovo di contratto, e cosa succede se non viene rispettata.
• Il nome di chi, nella tua agenzia, seguirà il progetto: mezza giornata a settimana anche quando lo sviluppo è tutto all'esterno.
• Una posizione decisa su chi parla col cliente, altrimenti lo decide il caso alla prima riunione tecnica.

Le tre strade e quando conviene ciascuna

La domanda che scioglie il dubbio non è "quanto costa", ma "quante giornate di sviluppo mi servono nei prossimi dodici mesi e quanto sono prevedibili". Se il numero è alto e stabile l'assunzione entra in gioco; altrimenti molte agenzie tengono all'interno analisi e relazione col cliente e affidano all'esterno la parte di sviluppo software su misura.

Variante 1: il progetto una tantum

È il caso più frequente: un cliente storico chiede un software che tu non sai fare, e rifiutare significa aprirgli la porta di un'altra agenzia anche per il resto.

Riscrivi la richiesta in forma di problema. Non "vuole un'app", ma "i suoi quattordici tecnici compilano rapportini su carta e li ridigitano in ufficio, circa sessanta a settimana". Il risultato è mezza pagina che un tecnico legge senza chiamarti.

Chiedi al partner una stima a fasce, non un numero. Una stima seria arriva come intervallo di giornate con le ipotesi dichiarate: quanti utenti, quante integrazioni, quali dati da migrare. Se un'ipotesi cade, la fascia si sposta, e lo sai prima di aver promesso qualcosa.

Fai fare un'analisi breve e pagata prima del preventivo definitivo. Due o tre giornate in cui il partner parla col cliente, guarda i sistemi esistenti e produce un documento che resta tuo: come si struttura è nella guida sul capitolato per software su misura.

Fissa un punto di controllo ogni due settimane con una versione provabile, non un aggiornamento a voce. È l'unico modo di sapere a che punto è il progetto quando il codice non lo scrivi tu.

Variante 2: la collaborazione continuativa

Quando i progetti diventano ricorrenti, il rapporto a progetto singolo costa tempo: ogni volta si rinegozia tutto.

Passa a un accordo quadro con ordini di lavoro separati. Un documento definisce riservatezza, proprietà del codice, tempi di risposta e modalità di lavoro; poi ogni progetto entra con un ordine di due pagine. Il tempo fra "il cliente ha detto sì" e "si comincia" scende da settimane a giorni.

Riserva una capacità concordata, per esempio un numero di giornate al mese: serve a te per promettere date e al partner per pianificare. Va scritto cosa succede se in un mese non la usi.

Standardizza ciò che si ripete: repository condiviso, ambienti di prova e produzione, strumento di gestione progetti, formato del brief. E metti un referente tecnico fisso da entrambe le parti, così alla prima urgenza nessuno ricostruisce il contesto da capo.

Variante 3: affiancare sviluppatori a un team interno

Qui non manca la competenza ma la capacità: hai due sviluppatori e un progetto che ne richiederebbe quattro per tre mesi.

Definisci prima chi comanda tecnicamente. Le decisioni di architettura restano al tuo responsabile interno oppure passano al partner: entrambe funzionano, quello che non funziona è lasciarlo implicito.

Concorda le regole del codice prima di iniziare: come si nominano i rami, chi approva le modifiche, quali test sono obbligatori. Il risultato atteso è che a sei mesi di distanza non si distingua chi ha scritto cosa.

Dividi il lavoro per area, non per singola attività. Un modulo intero con confini chiari produce meno attrito che due compiti al giorno dalla stessa lista: le dipendenze incrociate sono il costo nascosto dell'affiancamento.

Prevedi una fase di ingresso di qualche giorno per accessi, ambienti e lettura del codice, e decidi da subito come si esce: consegna documentata e ore di passaggio di conoscenza. Se il team è già sotto pressione, valuta di affidare all'esterno anche la gestione continuativa del software.

Come si presenta il partner davanti al cliente finale

Le impostazioni sono tre e si scelgono prima del primo incontro, non durante.

1. Dietro al marchio dell'agenzia. Il partner non compare: parla solo con te e le riunioni col cliente le fai tu. Massimo controllo sul rapporto commerciale, in cambio fai da traduttore su ogni dettaglio tecnico: regge solo se qualcuno da te capisce di cosa si parla.
2. In trasparenza, come parte del gruppo di lavoro. Il cliente sa che c'è un partner tecnico e lo incontra nelle riunioni tecniche, ma contratto e responsabilità restano dell'agenzia. Sui progetti complessi funziona meglio, perché elimina il telefono senza fili sulle specifiche.
3. Come fornitore dichiarato con contratto diretto. L'agenzia resta con un ruolo di coordinamento o creativo: si riduce il rischio economico, si riducono anche margine e controllo.

Tre punti vanno comunque scritti: chi può contattare chi, quali documenti portano quale marchio, e cosa si risponde se il cliente chiede esplicitamente chi sviluppa. Su quest'ultima l'unica risposta che non crea problemi è quella vera, detta nella forma concordata. Un partner abituato a lavorare con le agenzie ha già una posizione su questi punti: la pagina dedicata al ruolo di partner di sviluppo per agenzie descrive come si imposta una collaborazione di questo tipo.

Come si passa un progetto a un partner

Il brief decide come andrà il progetto: se è povero, il partner produce ipotesi, e le ipotesi diventano varianti in corso d'opera.

Il brief minimo contiene sei blocchi: il problema del cliente in forma narrativa, chi userà il software e quanti sono, i processi passo per passo, i sistemi da integrare con l'indicazione se hanno API, i dati esistenti con un campione anonimizzato, i vincoli di data e budget. Due pagine scritte bene valgono più di venti generiche.

Dal cliente ti servono tre cose prima di cominciare: una persona che possa dire sì e no, gli accessi ai sistemi, un campione dei dati veri. Chiedile insieme, con una data: è il passaggio in cui i progetti si fermano più spesso, e non per motivi tecnici.

Il capitolato lo scrive chi conosce il problema. Processi e vincoli nascono dal cliente con il tuo aiuto, la parte tecnica la propone il partner. Se il partner scrive anche i requisiti, stai comprando la descrizione di quello che sa fare.

Usa dati di fantasia nei materiali che giri, con nomi inventati e indirizzi tipo ordini@esempio.it, finché l'accordo di riservatezza non è firmato.

Concorda come si comunica: un canale scritto per le richieste, un repository condiviso per il codice, uno strumento di gestione progetti con lo stato delle attività visibile a entrambi.

Come stimare e presentare il lavoro al cliente

Quando il cliente chiede quanto costa e tu non hai ancora parlato col partner, la risposta che regge è che serve un'analisi prima di dare un numero, e che si fa in pochi giorni.

Le stime si strutturano in tre modi, e la scelta sposta il rischio. A giornate il cliente paga il lavoro effettivo: adatto quando il perimetro non è definibile in anticipo, come nell'affiancamento o nell'evoluzione di un software esistente. A progetto, con perimetro chiuso e procedura di variazione scritta, il rischio sta su chi sviluppa e regge solo se l'analisi è stata fatta davvero. A canone, per manutenzione ed evoluzioni dopo il rilascio.

Nella proposta al cliente compaiono perimetro, fasi, date, criteri di accettazione e cosa serve da lui, non la composizione interna del lavoro fra te e il partner. Una data di primo rilascio ravvicinata aiuta a far accettare un progetto grande, perché il cliente vede qualcosa funzionare prima di aver impegnato tutto.

Cosa mettere per iscritto fra agenzia e partner

Le voci da definire sono cinque, e conviene affrontarle una volta sola, non progetto per progetto. La proprietà del codice scritto per il cliente, con la distinzione fra codice su misura e librerie di terzi, che restano dei rispettivi autori con la loro licenza. La riservatezza su dati, documenti e informazioni commerciali che passano fra le parti. La non sollecitazione, cioè l'impegno reciproco a non rivolgersi direttamente ai clienti e alle persone dell'altra parte, per una durata definita. L'assistenza dopo il rilascio: cosa è difetto, in quanto tempo si interviene, per quanti mesi. Il passaggio di consegne in caso di interruzione.

Sono indicazioni generali, utili per sapere quali argomenti mettere sul tavolo: formulazione, durata e validità delle clausole vanno preparate con un legale di fiducia prima della firma.

La manutenzione dopo la consegna

Il rilascio non è la fine del rapporto: è il momento in cui il software comincia a cambiare con i processi del cliente.

Proponi la manutenzione insieme al progetto, non dopo. A rilascio avvenuto sembra un costo aggiuntivo, all'inizio è parte del progetto. Comprende aggiornamenti di sicurezza, correzione dei difetti, monitoraggio e ore per le evoluzioni minori.

Definisci il livello di servizio in modo verificabile: tempi di presa in carico distinti per gravità, orari di copertura, canale unico per le segnalazioni. E tieni traccia delle richieste: dopo sei mesi quella lista è il documento più utile che hai per proporre la fase due.

Errori comuni

Dare un numero al cliente prima di aver sentito il partner. Il preventivo dato al volo diventa un impegno, e la differenza fra quanto promesso e il lavoro reale la copre l'agenzia. Se serve una risposta subito, si dà una fascia dichiarata come provvisoria con la data della stima confermata.

Fare da semplice ponte fra cliente e partner. Un'agenzia che gira mail senza aggiungere nulla accumula un ritardo a ogni passaggio: il ruolo che regge è tradurre il bisogno in requisito, tenere le priorità e decidere cosa entra nel primo rilascio.

Rimandare l'accordo scritto a dopo il primo progetto. Riservatezza, proprietà del codice e non sollecitazione servono quando qualcosa va storto, ed è il momento in cui non si scrivono più con calma.

Quanto tempo serve e qual è il passo successivo

Dalla richiesta del cliente alla firma, con un partner già selezionato, passano da due a quattro settimane: qualche giorno per il brief, una settimana per l'analisi, una per stima e proposta, il resto per le decisioni del cliente. Se il partner devi ancora trovarlo, aggiungi due o tre settimane fra selezione e accordo quadro.

Il passo successivo è preparare i due documenti che ti serviranno con qualunque partner: un modello di brief e la lista delle cinque voci da concordare per iscritto. I criteri per valutare chi hai davanti sono poi gli stessi che userebbe un cliente finale, e la guida sulla scelta di un'agenzia di sviluppo, collegata qui sotto, li elenca uno per uno.