Grande software house o piccolo studio: cosa cambia

Per una micro o piccola impresa che deve far sviluppare un gestionale, un portale o una web app, la differenza tra una grande software house e un piccolo studio raramente sta nelle competenze tecniche disponibili. Sta in tre cose più concrete: chi lavora davvero sul progetto, quanto resta lo stesso nel tempo e quanto pesa il tuo progetto per chi lo segue.

C'è anche un dato utile da tenere a mente. Secondo il CHAOS Report 2015 dello Standish Group, che ha analizzato oltre 25.000 progetti software tra il 2011 e il 2015, i progetti piccoli si sono conclusi con successo nel 61% dei casi, quelli grandi nell'11%. Il dato riguarda la dimensione del progetto, non quella del fornitore, ma dice una cosa importante: progetti contenuti, seguiti da gruppi piccoli, hanno più probabilità di arrivare in fondo nei tempi e nei costi previsti.

Chi lavora davvero sul tuo progetto

Una software house con cento sviluppatori ha persone molto brave, persone nella media e persone alle prime armi. È inevitabile: più il gruppo è grande, più la qualità media si avvicina a quella del mercato. Il punto è che tu non scegli chi seguirà il tuo progetto. Lo decide l'organizzazione in base a chi è libero in quel momento, e per un progetto di piccole dimensioni non è detto che siano i più esperti.

Spesso, poi, tra te e chi scrive il codice ci sono più passaggi: il commerciale che raccoglie la richiesta, l'analista che la traduce in specifiche, il project manager che la assegna. Ogni passaggio è un'occasione per perdere un dettaglio, e i dettagli in un gestionale sono quelli che fanno la differenza tra uno strumento usato e uno sopportato.

In un piccolo studio o con un libero professionista la qualità ha un nome e un cognome. Chi ti ascolta in riunione è chi progetta e scrive il software, e la sua reputazione dipende direttamente da come funziona quello che consegna. Non c'è un altro reparto su cui scaricare un problema. Per molti professionisti del settore conta anche la passione per il mestiere: è difficile misurarla, ma la si riconosce nella cura per le cose che il cliente non vede.

Il turnover e la conoscenza che si perde

Un problema che chi lavora nel settore vede spesso: nello stesso progetto gli sviluppatori cambiano più volte, perché vengono spostati su altri clienti o lasciano l'azienda. Mi capita di frequente di lavorare su progetti passati di mano in mano, e quasi sempre senza un vero passaggio di consegne. Chi arriva deve ricostruire da solo perché una funzione è stata scritta in un certo modo, e nel frattempo il cliente paga ore che non producono niente di nuovo.

Il fenomeno è noto da decenni. Frederick Brooks, nel libro The Mythical Man-Month del 1975, ha formulato quella che oggi è chiamata legge di Brooks: aggiungere persone a un progetto software in ritardo lo fa ritardare ancora di più. I nuovi arrivati devono essere formati da chi c'era già, e i canali di comunicazione crescono molto più in fretta delle persone: in un gruppo di 3 le coppie che devono parlarsi sono 3, in un gruppo di 10 sono 45.

Quanto pesa il tuo progetto

Un progetto da 15.000 euro è marginale nel fatturato di un'azienda con duecento dipendenti. Per uno studio di tre persone è un cliente importante. Questo si traduce in cose pratiche: tempi di risposta, disponibilità a una telefonata, attenzione alle piccole modifiche che per te sono urgenti.

Anche i processi seguono la dimensione. Una grande azienda è organizzata per clienti grandi: ogni modifica passa da un ticket, una richiesta formale e un preventivo. È un metodo corretto per progetti complessi, ma per una piccola impresa che deve aggiungere un campo a una scheda cliente diventa un costo sproporzionato. A questo si aggiungono i costi di struttura (sedi, rete commerciale, livelli di gestione) che finiscono nella tariffa oraria.

Supporto 24/7 e contratti: cosa serve davvero

Le grandi software house possono offrire assistenza ventiquattr'ore su ventiquattro, sette giorni su sette. È un servizio prezioso per chi ha sistemi che lavorano di notte, come un e-commerce con volumi importanti o un impianto di produzione a ciclo continuo. Molte micro e piccole imprese lavorano invece negli orari d'ufficio: a loro serve una risposta rapida in quella fascia e un monitoraggio automatico che segnali se qualcosa si blocca.

Sui contratti le grandi aziende sono in genere più strutturate: livelli di servizio scritti, penali, procedure definite. Un piccolo studio a volte lavora con accordi più leggeri. La soluzione non è rinunciare al piccolo studio, ma chiedere che le stesse cose siano messe per iscritto: tempi di risposta, garanzia sui difetti, proprietà del codice.

Cosa offre davvero una grande azienda

Ci sono casi in cui la grande software house è la scelta giusta:

progetti molto estesi, che richiedono molte persone in parallelo per mesi;
certificazioni richieste dal cliente o dal settore, come la ISO 27001 sulla sicurezza delle informazioni;
integrazioni con sistemi enterprise già presenti in azienda, che la software house spesso conosce e rivende;
un gruppo che copre design, sicurezza e infrastruttura sotto lo stesso contratto.

Alcune offrono anche consulenza su ambiti vicini, come privacy o aspetti legali, ma non è una regola, e molti professionisti indipendenti lavorano in rete con consulenti specializzati.

Il limite vero del freelance: la continuità

Il rischio principale di affidarsi a un singolo professionista è la continuità: se si ferma, chi porta avanti il progetto? Nel software questo rischio ha un nome, truck factor: il numero di persone che, se uscissero dal progetto, lo bloccherebbero. Per un freelance è 1 per definizione.

Non è però un problema solo dei piccoli. Uno studio del 2016 su 133 progetti open source molto popolari su GitHub ha stimato che il 65% ha un truck factor pari o inferiore a 2. Anche in strutture più grandi la conoscenza di un sistema tende a concentrarsi in poche persone, e quando queste cambiano progetto il problema è lo stesso.

La differenza la fanno le contromisure, che valgono con qualsiasi fornitore:

codice sorgente in un repository di proprietà tua, non del fornitore;
accessi a server, domini e servizi intestati alla tua azienda;
documentazione essenziale su come installare e far funzionare il sistema;
tecnologie diffuse, che un altro sviluppatore può riprendere senza ripartire da zero.

Le domande da fare a qualsiasi fornitore

Che tu stia parlando con una software house o con un professionista, queste domande aiutano a capire con chi hai a che fare:

Chi scriverà concretamente il codice, e posso parlarci?
Se quella persona cambia progetto o lascia, come avviene il passaggio di consegne?
Il codice e gli accessi saranno intestati alla mia azienda?
Quali tempi di risposta sono garantiti, e in quali orari?
Come vengono gestite e quotate le piccole modifiche dopo la consegna?
Posso vedere un progetto simile, di dimensioni simili al mio?

Se stai ancora decidendo se partire da un software pronto o da uno sviluppato su misura, l'articolo su gestionale pronto o su misura aiuta a impostare il confronto.

In sintesi

Per la maggior parte delle micro e piccole imprese il fornitore giusto non è il più grande, ma quello che garantisce continuità, attenzione e responsabilità diretta sul proprio progetto. Un piccolo studio o un professionista esperto offrono spesso proprio questo, a patto di mettere per iscritto proprietà del codice, tempi di risposta e passaggio di consegne. La grande software house resta la scelta sensata quando il progetto è davvero grande o il settore richiede certificazioni e strutture che un piccolo studio non ha.