CARRIERA · FIRMWARE · STIMA · CONSULENTE · MANAGEMENT

Perché le Stime del Firmware Sono Sempre Sbagliate (E Come Risolvere)

2026-06-27 · Davide Carrese

Ogni sviluppatore embedded ci è passato. Un project manager chiede: "Quanto ci vuole per aggiungere il supporto CAN bus?" Ci pensi un attimo, dai un numero, e poi passi tre settimane a combattere errata, una versione buggata dell'HAL, e un analizzatore logico che si rifiuta di triggerare sull'ID giusto. La stima era sbagliata per un fattore tre. Di nuovo.

La stima del firmware è notoriamente inaffidabile perché il lavoro embedded ha modalità di fallimento che i progetti puramente software non hanno: bug hardware, incompatibilità della toolchain, sonde oscilloscopio che misteriosamente smettono di funzionare alle 4 del venerdì pomeriggio, e l'immancabile momento "sulla dev board funzionava" quando deployi sull'hardware reale. Come consulente, stime inaccurate non infastidiscono solo il team — ti costano soldi e erodono la fiducia del cliente.

Questo articolo copre il framework di stima che ho sviluppato in oltre dieci anni di consulenza embedded. Non è una pallottola d'argento, ma ti porterà entro un ±20% la maggior parte delle volte. E questo è un miglioramento enorme rispetto alla media del settore.

Il Sistema dei Tre Secchi

Non stimare in ore. Gli esseri umani sono terribili nella stima granulare del tempo, specialmente per lavoro tecnico. Invece, classifica ogni task in uno di tre secchi:

SecchioDefinizioneBufferRange tipico
NotoL'ho già fatto esattamente, su hardware simile, con la stessa toolchain× 1.3Mezza giornata a 3 giorni
AdattaHo fatto qualcosa di simile, ma su hardware diverso, periferica diversa, o SDK diverso× 2.03 giorni a 2 settimane
EsploraNon l'ho mai fatto. Nessuno nel team l'ha fatto. La documentazione è incompleta o contraddittoria× 4.02 settimane a 8 settimane

Se la tua sensazione per un task è "circa quattro giorni" e cade nel secchio Adatta, impegnati per otto giorni. Il buffer copre l'inevitabile: un layout di registri confusionario, un'errata non documentata, un conflitto di canale DMA con una periferica esistente, o i tre giorni che passerai a far compilare l'SDK del vendor con la tua versione della toolchain.

Non negoziare il secchio Esplora. Se un task è genuinamente sconosciuto — un nuovo protocollo wireless, una famiglia di chip che non hai mai toccato, un bootloader custom senza referenze pubbliche — quota un range e insisti su un approccio a tempo e materiali o a fasi. Prezzo fisso su lavoro Esplora è come i consulenti falliscono.

Il Fattore Hardware: Aggiungi Sempre 30%

Ecco l'errore di stima più comune nell'embedded: assumere che l'hardware funzioni. La dev board funziona. Il design di riferimento a pagina 42 del datasheet funziona. Ma il tuo PCB vero ha un errore di layout, un valore di pull-up sbagliato, o un condensatore di disaccoppiamento piazzato 12 millimetri troppo lontano dal pin. Il silicio del tuo lotto specifico ha un comportamento sottile che contraddice il manuale di riferimento.

Aggiungi 30% a ogni stima per il bring-up e debug hardware. Questo include:

Nei miei progetti, separo la valutazione della "confidenza hardware" in una voce a sé nella stima. Se il cliente ha un PCB Rev A senza firmware precedente, raddoppio il fattore hardware. Se è una terza produzione con firmware collaudato, lo riduco al 15%.

La Trappola della Comunicazione

I clienti non vogliono sentire che una semplice configurazione GPIO richiede tre giorni. Loro pensano che GPIO sia una riga di codice e che scrivere un registro richieda un microsecondo. Non hanno torto — la scrittura in sé è istantanea. Quello che richiede tre giorni è capire quale numero di funzione alternativa mappa a quale pin in quale variante di package, leggere il manuale di riferimento per confermare che l'impostazione di velocità GPIO non interferisca con l'ADC, testare tutti i 16 pin della porta per verificare che il routing del PCB corrisponda allo schematico, e scoprire che il pin che ti serve è anche usato dal debugger JTAG.

Ecco come presento le stime ai clienti:

"Aggiungere il controllo GPIO per il LED utente richiede 3 giorni:
- 1 giorno: revisione dello schematico, datasheet e mappatura funzioni alternative
- 1 giorno: implementazione e test sull'hardware reale
- 1 giorno: buffer per interazioni impreviste (condivide un canale timer con la PWM, o il pin è in un domino di tensione diverso)

Se vuole che mi impegni per 1 giorno, posso — ma il rischio di trovare un problema che richiede una revisione del PCB è suo, non mio."

Non è difensivo. È onesto. Ogni consulente embedded ha una storia sulla "modifica di una riga" che si è trasformata in due settimane di debug perché il nuovo pin GPIO era sul domino VBAT e il pull-up di reset era sbagliato. Cita il rischio esplicitamente, e il cliente ti rispetterà per questo.

Il Framework Che Uso

Per ogni progetto firmware, costruisco un foglio di calcolo con tre colonne: task, secchio (Noto/Adatta/Esplora), e tempo tecnico grezzo. Poi applico i moltiplicatori e aggiungo il fattore hardware sopra:

task                      secchio   grezzo  ×mult    hw 1.3   totale
──────────────────────────────────────────────────────────────────────
Bootloader UART           Adatta     5g      ×2       ×1.3     13g
Driver I2C EEPROM         Noto       1g      ×1.3     ×1.3     ~1.7g
Accoppiamento BLE         Esplora    —       —        —        quota T&M

Totale stimato:           14.7 giorni → arrotondo a 3 settimane
                          (assumendo nessun blocco, ferie, o ritardi FAE)

Poi aggiungo un buffer di progetto del 25% sopra per test di integrazione, documentazione, e l'inevitabile conversazione "già che ci sei, puoi anche…". Per l'esempio sopra, ottengo 3.7 settimane — e quota 4 settimane.

Il cliente vede 4 settimane ed è contento quando ci vogliono 3.5. È infinitamente meglio che quotare 2 settimane, impiegarne 4, e avere un cliente insoddisfatto che pensa tu sia inaffidabile.

Cosa Ha Funzionato per Me

Negli anni ho imparato alcune verità dure sulla stima del firmware:

Checklist Pratica

Fonti

📬 Commenti / discussione

Preferisci email: comments@carrese.eu — includi l'URL dell'articolo così posso seguire. Per correzioni o domande più approfondite, di solito rispondo entro 48 ore.