Come scegliere una software house per un progetto aziendale senza perdere tempo e budget
Preparare il progetto prima di confrontare i fornitori
La selezione di una software house comincia prima della richiesta di preventivo. Se l’azienda invia una descrizione generica, ricevera proposte basate su ipotesi diverse e non potra confrontarle. Occorre preparare un documento breve ma concreto con obiettivo, utenti, processo attuale, problemi, sistemi coinvolti, dati, vincoli e risultato atteso. Non serve decidere in anticipo l’architettura: serve permettere a ogni candidato di capire lo stesso problema.
Indica che cosa deve restare fuori dalla prima fase e quali condizioni non sono negoziabili. Un’integrazione con il gestionale, il funzionamento offline o la conservazione di una cronologia non sono dettagli da aggiungere dopo il contratto. Allegare esempi anonimi di documenti, schermate e casi eccezionali aiuta a distinguere chi comprende il lavoro da chi propone soltanto una soluzione gia pronta.
Definisci inoltre il processo di selezione. Stabilisci quante aziende incontrare, chi partecipa alla decisione, quali domande usare e come attribuire i punteggi. Il gruppo dovrebbe comprendere il proprietario del processo, una persona che lo esegue ogni giorno e un referente tecnico capace di valutare integrazioni e sicurezza. Il modello multidisciplinare indicato dal Service Standard britannico e utile proprio perché mantiene insieme esigenze operative, utenti e sistemi.
La prima chiamata non deve diventare una demo commerciale. Chiedi al candidato di ricostruire il flusso con parole proprie, evidenziare le informazioni mancanti e spiegare come organizzerebbe la discovery. Le domande che pone sono una prima evidenza: chi accetta ogni richiesta senza esaminare eccezioni, responsabilita e dati sta stimando qualcosa che ancora non conosce.
Verificare team, metodo e proprieta degli artefatti
Chiedi chi lavorera davvero al progetto e con quale disponibilita. I profili presentati in gara devono corrispondere alle persone assegnate o a ruoli equivalenti. Per ogni ruolo chiarisci responsabilita: analisi, progettazione dell’esperienza, architettura, sviluppo, test, sicurezza, rilascio e coordinamento. Un unico interlocutore commerciale non sostituisce un team capace di prendere decisioni tecniche e operative.
Fatti mostrare come viene trasformato un requisito in lavoro verificabile. Una risposta concreta descrive backlog, criteri di accettazione, prototipi, revisioni frequenti e dimostrazioni su funzionalita eseguibili. Chiedi un esempio anonimo di documento di analisi, una definizione di completato e un rapporto di test. Non occorre ottenere materiale riservato di altri clienti: basta vedere il livello di precisione degli strumenti usati.
Repository, codice sorgente, configurazioni, schema dei dati e procedure di distribuzione devono avere una proprieta e un accesso definiti nel contratto. Chiarisci dove risiede il repository, chi amministra gli account, come vengono consegnate le versioni e che cosa accade alla conclusione del rapporto. Se tutto rimane in un ambiente controllato esclusivamente dal fornitore, l’azienda deve conoscere tempi, costi e condizioni per ricevere una copia utilizzabile.
Controlla anche la gestione delle dipendenze. Domanda come vengono scelte librerie e servizi esterni, come si registrano licenze e versioni e chi interviene quando emerge una vulnerabilita. Una lista di tecnologie non dimostra manutenzione. Servono un inventario aggiornabile, un processo per gli aggiornamenti e responsabilita contrattuali durante il periodo di assistenza.
Esigere evidenze su sicurezza, test e rilascio
La sicurezza non si valuta chiedendo se il software sara sicuro. Il NIST SSDF offre un vocabolario utilizzabile anche negli acquisti: preparare l’organizzazione, proteggere il software, produrre rilasci sicuri e rispondere alle vulnerabilita. Chiedi quindi quali pratiche vengono applicate al tuo progetto, quali prove restano disponibili e come vengono gestite le eccezioni. OWASP SAMM permette inoltre di discutere la maturita delle attivita senza imporre un unico processo a organizzazioni diverse.
Verifica gestione degli accessi, segreti, dipendenze, revisione del codice e tracciamento delle vulnerabilita. Le credenziali non devono essere incorporate nel repository; gli ambienti devono essere separati; i dati reali non vanno copiati indiscriminatamente nei test. Chiedi chi può accedere alla produzione e come viene registrata un’operazione amministrativa. La guida Secure by Demand di CISA suggerisce agli acquirenti di domandare esplicitamente come il produttore assume responsabilita per gli esiti di sicurezza.
Il piano di test deve coprire funzionalita, permessi, integrazioni, errori e regressioni. Per i flussi critici servono casi concordati con l’azienda e risultati leggibili, non soltanto la dichiarazione che i test sono passati. Chiedi come vengono ripetuti dopo una modifica e chi accetta il rilascio. Un collaudo concentrato alla fine rende costosa ogni correzione e nasconde per mesi interpretazioni sbagliate.
Esamina infine la procedura di distribuzione: ambienti attraversati, approvazioni, backup dei dati, migrazioni, monitoraggio e rollback. CISA raccomanda fasi definite e una strategia robusta per ridurre il rischio che aggiornamenti difettosi raggiungano i clienti. Il candidato dovrebbe saper spiegare che cosa accade dal momento in cui una modifica viene approvata fino alla verifica successiva al rilascio.
Confrontare stime, cambiamenti e assistenza
Una stima utile esplicita assunzioni, esclusioni e livello di incertezza. Confronta le offerte per perimetro e risultati, non solo per totale. Controlla se includono analisi, design, integrazioni, migrazione, test, avvio, formazione e periodo di stabilizzazione. Una cifra piu bassa può semplicemente lasciare fuori attivita che emergeranno come varianti.
Chiedi come viene gestito un cambiamento. Deve esistere un modo per descriverlo, valutarne impatto su tempi e costo, decidere se sostituisce una priorita e conservarne approvazione. Il processo non deve impedire di apprendere durante il progetto, ma rendere visibile l’effetto delle decisioni. Pretendere un prezzo fisso su requisiti ancora incerti sposta spesso il rischio in margini elevati, esclusioni o conflitti.
L’assistenza va definita con scenari concreti. Distingui difetto, richiesta evolutiva, incidente e domanda operativa; indica canali, orari, priorita, tempi di presa in carico e responsabilita di ripristino. Verifica chi mantiene infrastruttura, certificati, backup e servizi esterni. Chiedi anche come avviene il passaggio a un altro team: documentazione, affiancamento, accessi e stato delle segnalazioni aperte.
Le referenze devono essere pertinenti per complessita e metodo, non necessariamente per settore. Con il consenso del cliente, domanda come sono stati gestiti una modifica difficile, un problema in produzione e la fase successiva al primo rilascio. Le risposte sulle difficolta sono spesso piu informative dei casi presentati come perfetti.
Hai mai provato la sensazione di essere il migliore in quello che fai, ma allo stesso tempo di:
👉 gridare ma la voce non esce
👉 urlare ma non ottenere risposta
👉 sudare molto e ottenere poco
Adesso aiuto gli altri ad emergere dando una voce a chi non riesce a gridare:
👉 facendoli primeggiare
👉 creando loro un identità forte
👉 rendendoli i migliori del settore
tracce: il mio metodo di marketingIl Buio nasconde anche i migliori
Crea una griglia con criteri e pesi prima di ricevere le offerte. Inserisci comprensione del processo, qualita della discovery, team, architettura, sicurezza, test, proprieta degli artefatti, rilascio, assistenza e costo totale. Per ogni criterio specifica quale evidenza assegna il punteggio: un esempio di piano di test vale piu di una risposta affermativa.
Invia lo stesso materiale ai candidati e concedi lo stesso tempo per le domande. Organizza un incontro operativo su un caso reale, chiedendo di individuare rischi, informazioni mancanti e prima fase. Registra separatamente ciò che è dimostrato, ciò che è dichiarato e ciò che resta da chiarire. Richiedi poi un’offerta revisionata che incorpori le risposte emerse.
Prima della firma esegui un controllo contrattuale con responsabile tecnico e consulente legale: perimetro, accettazione, accesso al repository, proprieta intellettuale, dati, riservatezza, subfornitori, sicurezza, continuita, uscita e pagamenti. Se il progetto è ampio, finanzia una discovery o una prova tecnica delimitata con risultati riutilizzabili. La decisione finale deve includere il costo del rapporto nel tempo e la capacita dell’azienda di conservare controllo, non soltanto la data promessa per la prima versione.
Approfondimenti per preparare e controllare l'incarico
Lunedì – Sabato : 9:30 am – 21:00 pm
Domande sulla scelta della software house
Lunedì – Sabato : 9:30 am – 21:00 pm
parlami del tuo progettoFammi sapere i dettagli del tuo progetto e i tuoi obiettivi di Marketing
Studierò la strategia più adeguata per le tue esigenze e insieme al mio staff individueremo la Buyer Personas migliore per trasformare il tuo processo commerciale offline nella più efficace macchina di vendita online, e la strategia di comunicazione più convincente per convincere il pubblico che il tuo prodotto è quello che stanno cercando, anche se costa di più della concorrenza.
Cominciamo da qui
Lunedì – Sabato : 9:30 am – 21:00 pm




