20 sviluppatori, una tariffa oraria e nessuna idea di quanto avesse davvero reso il progetto
"Conoscevo la tariffa oraria di ogni sviluppatore. Conoscevo la tariffa contrattuale del cliente. Ho sottratto l'una dall'altra e pensavo di conoscere il margine. Poi ho costruito un conto economico per progetto e ho capito che per quattro anni avevo gestito un'azienda su una finzione."
La fondatrice di un'azienda IT di servizi e outstaffing — 20 sviluppatori, ₴36M di ricavi annuali, sette clienti attivi — ha descritto l'esercizio che ha cambiato il suo modo di fissare i prezzi e assumere.
Per quattro anni ha gestito l'azienda con ciò su cui si basa tutto il settore: la matematica della tariffa oraria. Ogni sviluppatore aveva un costo orario (₴550/ora, in media). Ogni cliente aveva una tariffa contrattuale (₴950/ora, media tra i clienti). Una semplice sottrazione dava ₴400/ora di margine lordo per sviluppatore, circa il 42% di margine. Estrapolato su tutto il team: confortevole, redditizio, in crescita.
Poi ha fatto l'esercizio. Prendere un progetto. Non il numero "abbiamo fatturato al cliente ₴X all'ora". Il vero conto economico del progetto. Ricavi del cliente per il mese. Tutti i costi direttamente attribuibili a quel progetto. Tutti i costi indirettamente attribuibili. Quello che resta.
Margine del progetto sul suo cliente di punta, negli ultimi 12 mesi: 14%. Non 42%.
Ventotto punti di margine erano scomparsi in una serie di costi che la matematica della tariffa oraria non toccava.
Cosa nasconde davvero la matematica della tariffa oraria
La tariffa oraria presuppone che uno sviluppatore sia utilizzato al 100% sul progetto, produttivo al 100% durante quel tempo, e che il progetto consumi solo il suo lavoro. Nessuna di queste cose è vera per un'azienda di servizi reale.
Bench e ramp-down (−5 punti). Quando un progetto finisce o un cliente si mette in pausa, lo sviluppatore è inattivo ma continua a essere pagato. Due settimane all'anno, in media, per sviluppatore. Non fatturabile. Esce dal margine.
Ferie e malattia (−4 punti). Gli sviluppatori a stipendio fisso ricevono ferie e malattia pagate. La tariffa contrattuale viene fatturata solo quando lavorano. Il divario è invisibile finché non lo conti.
Riunioni interne, processo, colloqui di assunzione (−6 punti). Standup, retrospettive, pianificazione, colloqui con i candidati, sync interni. Tutti pagati, nessuno fatturabile. In media 4–6 ore per sviluppatore a settimana.
Strumenti e licenze (−2 punti). Licenze IDE, infrastruttura cloud per ambienti interni, strumenti di project management, monitoraggio, piattaforme di comunicazione. Piccoli per unità; si sommano.
Recruiter e overhead di gestione (−7 punti). HR, delivery manager, project manager, il tempo stesso della fondatrice. Tutti vengono pagati. Quasi mai fatturabili. Questa era la falla singola più grande.
Sconti e straordinari non fatturati (−4 punti). Il cliente ha contrattato la tariffa al rinnovo, ottenendo uno sconto dell'8%. Il lavoro di emergenza nel weekend non sempre tracciato. Lo sforamento su parti a scope fisso assorbito.
Ventotto punti, sei categorie, nessuno nella matematica della tariffa oraria.
La ricostruzione — framework di conto economico per progetto
La fondatrice ha costruito il suo conto economico per progetto in un weekend. È diventato il documento singolo più importante della sua azienda. Il framework si applica a qualsiasi azienda di servizi.
Uno — Ricavi del progetto. Ore fatturate mensili × tariffa contrattuale del cliente. Non quanto impegnato nelle vendite; quanto effettivamente fatturato.
Due — Costo diretto dello sviluppatore, fully loaded. Stipendio + tasse + benefit + ammortamento delle attrezzature + ferie pagate, diviso per le ore di utilizzo (non le ore di calendario). Se uno sviluppatore è fatturabile per il 65% del tempo, il suo costo orario fully loaded è stipendio/(ore × 0,65).
Tre — Costo allocato di project management, delivery management e recruitment. Quota approssimativa per dimensione del progetto o per ricavi. Non deve essere perfetta. Deve essere coerente.
Quattro — Strumenti e licenze attribuibili al progetto.
Cinque — Allocazione del bench. Costo totale del bench per l'anno, diviso tra i progetti attivi.
Sei — Allocazione di riunioni interne e processo. Percentuale di ore pagate destinate a lavoro non di progetto × costo allocato.
Risultato — Margine reale del progetto. Per il suo cliente di punta: 14%. Per due clienti più piccoli: 21% e 8%. Per un cliente che pensava fosse il migliore: 3%.
Cosa ha fatto con la verità
Con il cliente al 3% ha avuto una conversazione sull'aumento della tariffa. È andata bene; il margine è salito al 12%. Il cliente all'8% aveva problemi di disciplina sullo scope (servizio eccessivo) risolvibili; il margine è salito al 15%. L'overhead di recruitment è stato rinegoziato con un retainer mensile fisso invece di commissioni per assunzione. Le riunioni interne sono state riviste — tre riunioni ricorrenti settimanali sono state eliminate. L'utilizzo di due dei suoi sviluppatori senior è passato dal 58% al 72% spostandoli dal lavoro interno da bench al lavoro sui clienti.
Il margine complessivo dell'azienda è passato dal 42% apparente (fittizio) al 19% reale (prima della ricostruzione) al 27% reale (sei mesi dopo). Più importante del numero: ora sapeva quale cliente era realmente redditizio, quale stava sovvenzionando il bench e quale le stava silenziosamente costando denaro.
Il framework — cosa tracciare
Sei numeri, mensili, per progetto:
- Ore fatturabili reali (non le ore impegnate; quelle effettive)
- Costo dello sviluppatore fully loaded per progetto
- Overhead di gestione allocato (tempo di PM/DM/recruiter/fondatrice come % del mese)
- Allocazione del bench (costo del bench di questo mese × quota di ricavi del progetto)
- Margine reale del progetto (ricavi − tutto quanto sopra)
- Utilizzo per sviluppatore, tracciato separatamente dal margine
Sei numeri, una dashboard, revisione mensile con il delivery lead. Due ore al mese, tengono lontana la finzione.
📌 Vuoi vedere se i tuoi progetti sono davvero redditizi quanto suggerisce la matematica della tariffa oraria? Inviaci tre mesi di dati di fatturazione e la ripartizione dei costi del team — costruiremo la waterfall del margine reale per progetto e te la spiegheremo in 15 minuti. [Richiedi la tua diagnosi gratuita Finmap →]
Domande frequenti
È entrambe le cose. Un utilizzo più alto aumenta direttamente il margine fully loaded perché il costo dello sviluppatore si distribuisce su più ore fatturabili. Un utilizzo più basso uccide silenziosamente il margine.
Alloca il suo tempo in base alle ore effettivamente lavorate su ciascuno. Il suo costo fully loaded si divide nella stessa proporzione. Ecco perché il time tracking, anche leggero, conta.
L'aggregato va bene per le realtà più piccole (sotto i 30 sviluppatori). Oltre quella soglia, per sviluppatore è più pulito perché il bench dei senior è molto più costoso di quello dei junior.
Stessa matematica, ma i ricavi sono la quota mensile maturata (valore del contratto × % di completamento). In questo modo i progetti in perdita emergono molto prima rispetto alla contabilità per cassa.
Testa l'alternativa — il progetto è abbastanza redditizio da mantenerlo alle tariffe attuali? Se il margine è negativo o sotto il 10%, valuta la riduzione dello scope, l'efficienza di delivery o una transizione graduale.
Il tuo commercialista produce il conto economico a livello aziendale. Questo è un conto economico a livello di progetto, che richiede allocazioni per cui il commercialista di solito non ha i dati operativi.
