--- title: "Domande da fare prima di scegliere un partner software" description: "Cosa chiedere a un partner prima di firmare: chi fa il lavoro, esperienza, perimetro, proprietà del codice, sicurezza, passaggio di consegne, segnali d'allarme." canonical: https://sdk.enterprises/it/insights/choosing-a-software-partner language: it --- # Domande da fare prima di scegliere un partner software Aggiornato il: 2026-09-25 > Prima di affidarvi a un partner di sviluppo software, scoprite esattamente chi scriverà il codice, quali sistemi simili ha già consegnato, come vengono definiti perimetro e collaudo, e a chi appartiene il codice fin dal primo giorno. Risposte vaghe a una qualsiasi di queste domande sono un segnale d'allarme più serio di un prezzo alto. ## Scoprite chi scriverà davvero il codice Le persone presenti all'incontro commerciale spesso non sono quelle che costruiranno il vostro sistema. Chiedete nomi, ruoli ed esperienza degli ingegneri che lavoreranno al progetto, e chiedete di parlare con il responsabile tecnico prima di firmare. Chiedete se una parte del lavoro è subappaltata o affidata a freelance. Entrambe le cose possono funzionare bene, ma dovete saperlo, e il partner deve garantire per ogni persona che coinvolge. Chiedete anche che cosa succede se un ingegnere chiave se ne va a metà progetto, e chi paga il tempo che serve al sostituto per entrare nel lavoro. - Chi è il responsabile tecnico, e quanta parte del suo tempo dedica a questo progetto? - Quali ingegneri sono dipendenti, e quali subappaltatori o freelance? - Come selezionate e verificate gli specialisti che coinvolgete? - Qual è la procedura se qualcuno se ne va o non è la persona giusta? ## Chiedete esperienze che somiglino al vostro problema Un lungo elenco di clienti dimostra poco se nessun progetto somiglia al vostro. Chiedete esempi con vincoli simili: lo stesso tipo di sistema, un traffico o una sensibilità dei dati paragonabili, un contesto normativo analogo. Poi chiedete che cosa ha fatto questo team in ciascun caso, non che cosa ha ottenuto l'intero programma del cliente. Siate precisi su quale esperienza state comprando. Alcune società presentano il percorso individuale dei propri ingegneri, cosa legittima se dichiarata con onestà. Chiedete quando è stata fondata l'azienda, quali lavori sono stati svolti con contratti propri e se potete parlare con un cliente passato. ## Mettete per iscritto perimetro, milestone e criteri di collaudo Molte controversie nascono da un perimetro che non è mai stato scritto con precisione. Una buona proposta elenca i deliverable, suddivide il lavoro in milestone e definisce come viene accettata ciascuna milestone: per esempio test che passano, una demo su un ambiente di staging o una documentazione consegnata. Chiedete come vengono gestite e quotate le richieste di modifica, e qual è il modello commerciale. Il prezzo fisso (a corpo) è adatto a un lavoro ben definito, mentre il modello a consumo (time and material) è adatto alla fase di discovery e a requisiti che evolvono. In entrambi i casi dovete vedere le ipotesi alla base della stima. ## Chiarite proprietà del codice e passaggio di consegne prima di iniziare Il contratto deve stabilire che il codice e la relativa proprietà intellettuale sono vostri, e da quando la proprietà passa a voi. Chiedete che repository, account cloud e domini vengano creati nella vostra organizzazione fin dal primo giorno, con il partner invitato come collaboratore, così non dipenderete mai da lui per gli accessi. Pianificate il passaggio di consegne all'inizio, non alla fine. Chiedete che cosa riceverete: documentazione, registri delle decisioni di architettura, runbook operativi e sessioni di lavoro con il vostro team. Verificate quali licenze di terze parti e open source userà il progetto, perché comportano degli obblighi. ## Concordate come vedrete i progressi Non dovreste mai dover chiedere se il progetto è nei tempi. Concordate un ritmo fisso, per esempio una demo settimanale di software funzionante e un breve aggiornamento scritto su avanzamento, rischi e decisioni che spettano a voi. Chiedete l'accesso diretto al sistema di tracciamento delle issue e al repository, e un referente con nome e cognome che risponde della consegna. Chiarite come vengono segnalati i problemi e in quanto tempo potete aspettarvi una risposta. ## Mettete alla prova le loro pratiche di sicurezza, non i loro bollini Chiedete come gli ingegneri accedono ai vostri sistemi e ai vostri dati, come vengono conservati i segreti, come viene revisionato il codice prima del rilascio e come vengono controllate le dipendenze rispetto alle vulnerabilità note. Le risposte concrete contano più di una slide piena di loghi. Se il partner tratterà dati personali per vostro conto, vi serve un accordo sul trattamento dei dati conforme ai requisiti del GDPR. Se un fornitore dichiara una certificazione, chiedete il certificato e il suo ambito, e verificate che copra il team e i servizi che state acquistando. ## Campanelli d'allarme che dovrebbero chiudere la trattativa Un singolo segnale d'allarme può avere una spiegazione. Diversi segnali insieme di solito significano che il progetto sarà più difficile del necessario. - Non sanno indicare i nomi degli ingegneri che faranno il lavoro. - I casi di studio mostrano risultati, ma non che cosa ha fatto concretamente questo team. - La stima arriva prima che qualcuno abbia fatto domande dettagliate sul vostro sistema. - Repository e account cloud restano sotto il controllo del partner. - Le milestone non hanno criteri di collaudo scritti. - Alle domande sulla sicurezza si risponde con rassicurazioni generiche invece che con pratiche precise. ## Punti chiave - Incontrate il responsabile tecnico e scoprite chi scriverà il codice prima di firmare. - Valutate l'esperienza in base a quanto somiglia ai vostri vincoli e a ciò che il team ha fatto in prima persona. - Milestone scritte con criteri di collaudo chiari evitano molte controversie sul perimetro. - Tenete repository e account cloud nella vostra organizzazione fin dal primo giorno. - Chiedete pratiche di sicurezza precise e prove per qualsiasi certificazione dichiarata da un fornitore. ## Domande frequenti ### Con quanti partner parlare prima di sceglierne uno? Abbastanza da confrontare differenze reali di approccio, cioè, per la maggior parte dei progetti, pochi. Date a ciascuno lo stesso brief e le stesse domande, così le risposte sono confrontabili. ### Meglio un contratto a prezzo fisso o a consumo? Il prezzo fisso è adatto a un lavoro che potete specificare nel dettaglio prima che inizi. Il modello a consumo è adatto alla fase di discovery, a requisiti che evolvono e allo sviluppo continuativo, a patto di avere un reporting trasparente e demo regolari. ### Di che cosa parlare nella prima call con un potenziale partner? Del vostro obiettivo, dei vincoli, delle tempistiche e dei sistemi esistenti, e delle domande che il partner vi rivolge a sua volta. Un partner che fa domande dettagliate sul vostro sistema fin dalla prima call di solito è uno che lo stimerà con onestà. In SDK Enterprises quella prima call è una conversazione di 30 minuti, in francese o in inglese. ## Partite dalla vostra esigenza - [Realizzazione di siti web](https://sdk.enterprises/it/website-development) - [CTO a tempo parziale](https://sdk.enterprises/it/fractional-cto) ## Servizi correlati - [Audit tecnico e consulenza](https://sdk.enterprises/it/services/consulting) - [Software su misura](https://sdk.enterprises/it/services/product-engineering)