Come assumere una software house: cosa valutare

Il Portfolio Attraente Nasconde Molto

Se stai cercando un fornitore per sviluppare un'app o un software su misura, la guida su chi sviluppa app mobile e software su misura in Italia ti aiuta a capire i diversi profili di fornitori disponibili e quale si adatta meglio alla tua situazione.

Ogni software house ha case study di successo sul sito. I progetti mostrati sono i migliori, fotografati dalla prospettiva migliore, con testimonianze selezionate con cura. Quello che non si vede sono i progetti consegnati con sei mesi di ritardo, i clienti rimasti senza accesso al proprio codice, o le manutenzioni diventate ostaggio di un'unica azienda.

Assumere una software house è una delle decisioni più importanti che un responsabile tecnologico può prendere. L'impatto si estende per anni — nel costo di manutenzione, nella capacità di evolvere il prodotto, nella qualità del codice che rimarrà nel tuo repository. Questa guida copre cosa valutare oltre alle belle immagini del portfolio.

Processo: Come Lavorano Quotidianamente

La metodologia di lavoro di una software house determina la sua capacità di consegnare in modo prevedibile. Chiedi direttamente:

Qual è il processo di raccolta dei requisiti? Un'azienda seria vorrà capire il tuo business prima di presentare qualsiasi proposta. Se ricevi una proposta dettagliata al primo incontro, senza interviste o questionari approfonditi, diffida — i requisiti sono stati inventati.

Come sono organizzati gli sprint e le consegne? Le metodologie agili come Scrum o Kanban funzionano bene quando ben applicate. Il problema è quando "siamo agili" significa solo "non documentiamo nulla". Chiedi quali cerimonie vengono svolte, con quale frequenza il cliente partecipa e come vengono prioritizzate le richieste.

Chi è il riferimento tecnico? Hai bisogno di qualcuno con autorità tecnica per rispondere alle domande di architettura e prendere decisioni. Se la risposta è "chiunque nel team", l'onere ricadrà su di te ogni volta che sorge una decisione difficile.

Come viene effettuato il code review? I team professionali hanno pull request, revisione del codice tra pari e standard di qualità documentati. Se non esiste un code review formale, il codice sarà inconsistente e difficile da mantenere.

Comunicazione: Frequenza, Canale e Accesso al Team

La comunicazione scadente è la causa numero uno dei progetti che falliscono nonostante il team tecnico sia competente. Stabilisci aspettative chiare prima di firmare qualsiasi contratto.

Qual è la frequenza dei report di avanzamento? Settimanale è il minimo ragionevole per i progetti in corso. Di più per quelli critici. I report che arrivano solo quando li chiedi sono un segnale d'allarme.

Qual è il canale ufficiale di comunicazione? Email, Slack, Teams — il canale conta meno della coerenza. Il problema nasce quando il progetto è gestito via WhatsApp personale, dove i messaggi si perdono e non c'è una cronologia organizzata.

Hai accesso diretto agli sviluppatori? Molte software house creano un layer di gestione che blocca l'accesso diretto al team tecnico. Questo può proteggere il team dalle interruzioni, ma può anche mascherare i problemi tecnici. Definisci quando e come puoi scalare le questioni tecniche direttamente.

Cosa succede quando uno sviluppatore lascia il team? Il turnover nelle software house è alto. Se l'intero progetto vive nella testa di un unico sviluppatore, sei a rischio permanente. Chiedi come viene documentato e trasferito il know-how.

Contratto: Proprietà del Codice e Clausole Critiche

Il contratto è dove le conversazioni amichevoli diventano impegni legali. Leggi attentamente e, se necessario, consulta un avvocato specializzato prima di firmare.

Chi è il proprietario del codice prodotto? Questa è la clausola più importante. Il codice deve appartenere al cliente — non alla software house. I contratti che mantengono la proprietà intellettuale con l'azienda fornitrice creano dipendenza permanente. Se un giorno vuoi cambiare fornitore, dovrai pagare nuovamente per ciò che è già stato sviluppato.

Il codice viene consegnato nel repository del cliente? Insisti su un repository Git proprio (GitHub, GitLab o Bitbucket della tua organizzazione) dal primo commit. Non accettare "consegniamo alla fine del progetto" — alla fine del progetto può significare mai, se il rapporto si deteriora.

Quali sono le clausole SLA per la manutenzione? Se il sistema cade alle 2 di notte, in quante ore hai supporto? Contratti vaghi come "risponderemo il prima possibile" non sono adatti a sistemi critici.

Come viene gestita la variazione di scope? Ogni progetto ha variazioni di scope. I contratti ben redatti descrivono il processo di valutazione dell'impatto e l'approvazione dei costi aggiuntivi. Attenzione ai fornitori che accettano qualsiasi modifica senza discussione — il costo apparirà da qualche parte.

Red Flag: 7 Segnali che Qualcosa Andrà Storto

Sulla base di pattern comuni di progetti che falliscono, attenzione a questi segnali:

1. Proposta inviata lo stesso giorno del primo incontro. I progetti seri richiedono tempo per essere stimati correttamente. La velocità qui è un segnale che lo scope è stato ignorato.

2. Nessuna domanda sulle regole di business. Se la software house non ha fatto domande difficili su come funziona il tuo business, non riuscirà a costruire un sistema che soddisfi le tue esigenze reali.

3. Prezzo significativamente inferiore alla concorrenza. Lo sviluppo software ha un costo. Un prezzo molto basso significa team meno esperti, meno ore dedicate, o peggio, codice riutilizzato da progetti precedenti senza adeguato adattamento.

4. Nessuna referenza di clienti precedenti. Chiedi il contatto diretto con due o tre clienti precedenti. Se l'azienda non può o non vuole fornirli, è un segnale negativo.

5. Codice non testato o senza documentazione di test. Chiedi qual è la copertura di test del progetto e se esiste un ambiente di staging separato dalla produzione.

6. Processo di consegna mal definito. "Consegniamo quando è pronto" non è una metodologia. Milestone di consegna, criteri di accettazione e processi di omologazione devono essere documentati.

7. Resistenza alle audit di codice. Un'azienda sicura della qualità del proprio lavoro non si opporrà a una revisione tecnica indipendente prima di firmare il contratto.

Checklist di Valutazione

Usa questa checklist quando valuti proposte di software house:

• Processo di raccolta requisiti documentato
• Metodologia agile con cerimonie definite
• Repository Git nell'account del cliente dal primo commit
• Contratto con proprietà intellettuale al cliente
• SLA di manutenzione e supporto definito
• Processo di change request con approvazione dei costi
• Referenze di clienti precedenti disponibili
• Ambiente di staging separato dalla produzione
• Code review formale nel processo di sviluppo
• Documentazione tecnica inclusa nello scope

Conclusione

Assumere una software house implica molto di più che valutare il portfolio e confrontare i prezzi. Il processo di lavoro, la struttura di comunicazione, le clausole contrattuali sulla proprietà del codice e i segnali d'allarme nel processo commerciale sono ugualmente importanti.

SystemForge è stata costruita su documentazione e processi trasparenti. Lavoriamo con repository del cliente dal primo commit, metodologia agile con cerimonie documentate e contratti che garantiscono il 100% della proprietà intellettuale al committente. Se vuoi capire come funziona nella pratica, parla con il nostro team.