Gestionale per software house: cosa serve oltre al time tracking

Una software house che ha messo in piedi un buon time tracking pensa spesso di aver risolto il controllo di gestione. Il time tracking è solo l’ingresso dei dati: dice quante ore ha fatto una persona, su cosa, quando. Da solo resta un diario delle ore, non uno strumento che dice se un progetto sta guadagnando. I pezzi che mancano quasi sempre (timesheet collegato al costo reale, tempo e materiali gestito esplicitamente, una WBS con budget per ramo, scope creep intercettato in tempo) sono esattamente i temi su cui chi lavora in una software house si scontra ogni giorno, anche se nessuno li chiama “controllo di gestione”.

Il time tracking non è controllo di gestione

Un tracker delle ore, che sia un foglio, un’app dedicata o un buon timesheet integrato nel gestionale, risponde a una domanda sola: quante ore ha fatto una persona, su cosa, quando. È un dato necessario, ma da solo non dice se il progetto sta guadagnando. Per saperlo, quelle ore vanno collegate a due cose che il time tracking, da solo, non tocca: il prezzo a cui quel tempo è stato venduto (a corpo, a canone, a consumo) e il costo pieno dello sviluppatore che lo ha lavorato. Senza questo aggancio, un timesheet pieno e preciso convive benissimo con un progetto in perdita, e nessuno se ne accorge finché non è troppo tardi.

Il modello che una software house usa più spesso di quanto pensi

Anche un progetto venduto a corpo nasconde quasi sempre una parte a consumo: una change request, un’integrazione non prevista, manutenzione evolutiva fuori contratto. È fatturazione a tempo e materiali travestita da eccezione, quando in realtà è la normalità in un progetto software, dove i requisiti cambiano mentre il codice si scrive. Trattarla come un’eccezione, invece che come un modello da gestire esplicitamente, è il modo più comune in cui una software house regala ore che non fattura mai.

Una WBS che controlla il margine, non solo i task

Un progetto software non scomposto in fasi con un budget di ore proprio si controlla una volta sola: alla fine, quando ormai non si può più intervenire. Una WBS fatta bene non è solo un piano di lavoro per il team, è la struttura che permette di vedere, ramo per ramo, quanto budget resta prima che sia finito. Senza, lo scostamento lo scopri a sprint chiuso, o peggio a consegna, quando il margine del progetto è già una domanda retorica.

Scope creep: il modo silenzioso in cui il margine se ne va

Il cliente chiede “una piccola modifica” durante una call. Poi un’altra. Nessuna, singolarmente, sembra abbastanza per aprire una change request formale. Sommate, sono le ore che mancano al preventivo quando arrivi alla consegna. Lo scope creep è probabilmente la causa più comune di margine eroso nelle software house, proprio perché non è un evento che si vede: è un accumulo che emerge solo a posteriori, quando confronti ore lavorate e ore preventivate e la differenza non torna.

Un caso tipico

Un progetto venduto a corpo per una piattaforma web, due sviluppatori assegnati, tre fasi (analisi, sviluppo, collaudo) ciascuna con un budget di ore proprio. A metà sviluppo il cliente chiede due integrazioni non previste nel capitolato: vengono fatte “perché sono piccole”, senza aprire nulla di formale. Il timesheet registra tutte le ore, comprese quelle sulle integrazioni extra, ma non le distingue dal lavoro a corpo originale. A consegna il progetto ha consumato più ore del preventivato, e nessuno ha mai visto lo scostamento crescere, perché mancava l’aggancio tra ore lavorate, fase della WBS e perimetro originale.

Con quell’aggancio, lo stesso progetto avrebbe mostrato, già a metà sviluppo, che la fase di sviluppo stava sforando: le due integrazioni sarebbero diventate una change request a tempo e materiali, fatturata a parte, invece di lavoro assorbito in silenzio.

Cosa serve, in pratica, oltre al time tracking

Messi insieme, questi quattro pezzi (timesheet collegato al costo reale, tempo e materiali gestito esplicitamente, WBS con budget per ramo, scostamenti visibili prima che diventino scope creep sommerso) sono la differenza tra sapere quante ore ha fatto il team e sapere se un progetto sta marginando mentre è ancora in corso. Nessuno dei quattro, da solo, basta: un timesheet preciso senza WBS non sa dove va il tempo dentro il progetto, una WBS senza tempo e materiali gestito bene non vede il lavoro fuori perimetro, e tutto questo senza un costo reale per sviluppatore resta comunque un conteggio di ore, non un margine.

È il pezzo che manca alla maggior parte delle software house strutturate su Business Central: non un ennesimo tracker da affiancare, ma un’estensione che porta timesheet, tipi di fatturazione misti e marginalità per commessa nello stesso sistema in cui già vivono contabilità e fatturazione, con il margine che si aggiorna mentre il progetto procede, non al collaudo finale.

Il punto

Il time tracking risponde a “quante ore”. Il controllo di gestione di una software house risponde a “questo progetto sta guadagnando”, e la differenza sta in quattro pezzi che il time tracking da solo non copre: costo reale del lavoro, tempo e materiali gestito esplicitamente, una WBS con budget per ramo, scope creep intercettato mentre il progetto è ancora aperto.

Per il quadro dei pain specifici del settore, parti dalla pagina Software house. Per gli approfondimenti citati qui, timesheet, tempo e materiali, WBS di commessa e scope creep entrano nel dettaglio di ciascun pezzo.