Contacts
Cominciamo da qui
Close

CONTATTAMI

UK, Londra, E20 1DF, 13 Calla House, 7 Anthems Way

Whatsapp UK: +44 7843134934
Whatsapp ITA: +39 3338634639
Whatsapp VE: +58 4127828069

info@andreaberretti.com

Contattami su Whatsapp: +44 7843 134934

Come scegliere una software house per un progetto aziendale senza perdere tempo e budget

Come scegliere una software house per un progetto aziendale senza perdere tempo e budget

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.

tracce: il mio metodo di marketingIl Buio nasconde anche i migliori

per scalare il tuo business
0 step

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

Scrivere i requisiti

Prepara un perimetro comune per ricevere proposte realmente confrontabili.

Calcolare il budget

Distingui costruzione, integrazioni, avvio, manutenzione e cambiamenti.

Validare con un MVP

Riduci l’incertezza con un percorso completo e criteri decisi in anticipo.

Evitare il fallimento

Collega i rischi del progetto a controlli, responsabilita e gate verificabili.

Low-code o custom

Valuta se la proposta tecnologica rispetta davvero processo e vincoli.

Sviluppo personalizzato

Confronta il progetto con un percorso costruito intorno ai processi aziendali.

Lunedì – Sabato : 9:30 am – 21:00 pm

Domande sulla scelta della software house

Una rosa ristretta di candidati qualificati permette incontri approfonditi. Il numero conta meno dell’uso dello stesso perimetro, degli stessi criteri e di evidenze confrontabili.
La conoscenza del dominio aiuta, ma va verificata insieme a metodo, capacita tecnica e comprensione del processo specifico. Un portfolio nello stesso settore non sostituisce queste prove.
La risposta dipende dal contratto e dai componenti, ma accesso, diritti d’uso, repository, dipendenze e condizioni di consegna devono essere espliciti prima dell’avvio.
Si normalizzano per perimetro, assunzioni, esclusioni, team, test, rilascio e manutenzione. Senza questa lettura, i totali non rappresentano lo stesso lavoro.
No. Può essere un’indicazione organizzativa, ma servono evidenze applicate al progetto: persone, pratiche, artefatti, test, rilascio e gestione degli incidenti.
Quando requisiti, integrazioni o rischi sono ancora incerti. La discovery deve produrre risultati utilizzabili, confini chiari e una decisione motivata sulla fase successiva.

Lunedì – Sabato : 9:30 am – 21:00 pm

Un fornitore si valuta sulle prove di lavoro, non sulle promesse della presentazione 
Un fornitore si valuta sulle prove di lavoro, non sulle promesse della presentazione 

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

Fammi conoscere i dettagli del tuo progetto e i tuoi obiettivi, al resto penserò io.
Scrivi qui le tue necessità e i tuoi obiettivi

Lunedì – Sabato : 9:30 am – 21:00 pm