Come Tohum AB ha trasformato i requisiti tecnici, affrontato il debito tecnico e trasformato l'apprendimento in un motore di crescita professionale

1. Perché abbiamo scritto questa storia

Ogni start-up scopre prima o poi che la sua tecnologia è solo metà del prodotto; l’altra metà è la conoscenza degli ingegneri che danno vita a quella tecnologia. In Tohum AB — che opera da Göteborg, Svezia, e İzmir, Turchia — progettiamo nodi di misura del suolo pronti per il campo che abbinano un MCU ESP32 a sensori NPK di precisione, batterie Li-ion, pannelli solari ad alta efficienza, backhaul via SIM e pipeline dati MQTT. Man mano che la lista delle funzionalità cresceva, ci siamo ritrovati a destreggiarci tra fork del firmware, revisioni affrettate del PCB e un backlog di “cose che sistemeremo dopo” sempre più lungo.

Questo articolo è una retrospettiva su come abbiamo:

1. Definito i nostri requisiti tecnici in modo da bilanciare accuratezza agronomica, esigenze di ultra-low-power e vincoli di produzione.

2. Verificato e quantificato il nostro debito tecnico, dai driver BLE buggati agli schematici dell’alimentazione duplicati.

3. Costruito un piano di apprendimento basato su una skill matrix che trasforma le lacune in opportunità di crescita anziché in punti di stress.

4. Integrato lo sviluppo di carriera nel nostro ritmo ingegneristico quotidiano, così che il futuro di ogni dipendente sia trattato con la stessa serietà del futuro di ogni prodotto.

Speriamo che il playbook sia utile sia che stiate progettando il vostro primo nodo sensore sia che stiate scalando una flotta di decine di migliaia di dispositivi.

2. Inquadrare la missione — Da “un gadget figo” a risultati misurabili

La nostra visione fondativa era semplice: Dare agli agricoltori una visione accessibile e ricca di telemetria sulla salute del suolo, così che possano ottimizzare fertilizzanti e irrigazione con precisione scientifica. Trasformare quella visione in un backlog ingegneristico richiedeva un linguaggio che tutti gli stakeholder potessero capire — marketing, agronomi di campo, firmware engineer e hardware designer allo stesso modo.

Abbiamo quindi scritto ogni requisito di alto livello come un risultato visibile all’utente seguito da metriche ingegneristiche:

• “Un tecnico di campo può installare una sonda e vedere i dati nella dashboard entro 5 min.”

  • Provisioning Wi-Fi a 2,4 GHz o BLE Soft-AP; fallback su APN precaricato per il cellulare.

  • I valori iniziali di pH, EC e temperatura del suolo devono apparire in Grafana entro 300 s.

• “I nodi devono operare incustoditi per un intero inverno nordico senza sostituzione della batteria.”

  • Assorbimento medio di corrente ≤ 80 µA su 24 h; quiescente in deep-sleep ≤ 5 µA.

  • Pannello da 6 W + 18650 da 3.500 mAh deve rispettare il budget energetico a 55° N con 2 h di insolazione.

• “I vuoti di dati causati da perdita di copertura devono essere riempiti automaticamente.”

  • Ring buffer LittleFS da 4 MiB; SD card opzionale.

  • Rinvio MQTT QoS 1 con exponential back-off alla riconnessione.

Con i risultati chiari, i compromessi sono diventati espliciti: un buffer locale più grande aggiunge costo alla BOM; un campionamento più frequente aumenta la risoluzione agronomica ma scarica la batteria. Poiché ogni requisito poteva essere ricondotto a numeri concreti, abbiamo evitato la trappola delle funzionalità “nice-to-have” che si intrufolano nelle schede di revisione A.

3. Scomporre lo stack tecnologico

Poi, abbiamo scomposto la soluzione in sei aree di focus, ciascuna guidata da un “tech steward” che possedeva requisiti, risk register ed epic Jira:

Una “Architecture Canvas” di una pagina visualizzava le dipendenze: la scheda del sensore del suolo alimenta dati I²C all’MCU; il sottosistema di alimentazione riporta lo SoC tramite coulomb counter; il modem condivide il bus UART con il debug RS-485; il rules engine del cloud smista i dati in InfluxDB per Grafana.

Questa canvas è diventata l’indice di tutti i documenti di design successivi, prevenendo il pensiero a silos e assicurando che ogni ingegnere sapesse chi contattare quando una specifica cambiava.

4. Quantificare il debito tecnico — Trasformare aneddoti in numeri

Come molte start-up, avevamo accumulato scorciatoie del tipo “lo sistemeremo dopo il demo day”:

• Firmware

  • APN hard-coded in tre diversi source tree.

  • Routine ADC copia-incollate con costanti di scala magiche.

• Hardware

  • Tre modifiche di valori di resistori rattoppate con filo blu nel lotto pilota.

  • Nessuna convenzione di naming coerente per i test point.

• Processo

  • Script Bash una tantum per flashare 50 unità sulla linea di produzione.

  • Conoscenza tribale su quale commit dell’SDK funzionasse con quale revisione della scheda.

Abbiamo adottato un audit in tre passi simile alla metafora del debito tecnico di Ward Cunningham:

1. Inventario – un “debt safari” di tutto il team ha prodotto 126 voci in una pagina Confluence.

2. Severità e tasso di interesse – ogni voce valutata 1-5 per impatto e 1-5 per costo di correzione futura.

3. Stima del capitale – ore richieste se corretto immediatamente.

Il risultato era così:

Le voci con punteggio alto sono state promosse ai backlog degli sprint. Quelle più basse sono rimaste nel “cumulo di neve” ma con date di scadenza esplicite. Questa lente quantitativa ha spersonalizzato le discussioni: i numeri decidevano la priorità, non la voce più alta.

5. Mappare le competenze sul prodotto — La matrice a T

Parallelamente all’audit del debito, ci siamo resi conto che parte del “debito” era in realtà un deficit di competenze. Abbiamo preso in prestito il framework a cinque livelli visto in precedenza (Principiante assoluto → Esperto) ed elencato 25 competenze (C/C++, ESP-IDF, FreeRTOS, Git, PlatformIO, Linux CLI, Unity Test, CI/CD, Jira/Confluence, Elettronica, PCB design, Power budgeting, Gestione batterie, Comunicazioni cellulari, Protocolli IoT, TLS, Calibrazione sensori, Data logging, OTA, Teoria del controllo, Python/Bash, Dashboard cloud, Conformità normativa, Strumenti di documentazione).

Ogni ingegnere si è autovalutato e un tech lead ha moderato per la calibrazione. I risultati hanno formato una heat map:

Name   C/C++ ESP‑IDF LTE  PCB  MQTT Cloud ...
Ali      4      3      2    5    4     2
Elif     2      2      4    3    3     5
Mert     5      4      1    2    3     2

La chiamiamo matrice a T — tutti profondi in una specializzazione, ampi nelle basi. Ha evidenziato istantaneamente il rischio: se Ali (LTE livello 2) andava in vacanza, i problemi di cellulare potevano bloccare uno sprint. Ha anche illuminato percorsi di crescita: Elif poteva fare da mentore sul cloud mentre imparava ESP-IDF da Mert.

6. Costruire il piano di apprendimento — Dalle lacune agli obiettivi

Un piano di apprendimento è credibile solo se si ricollega ai bisogni del prodotto e alla motivazione individuale. Abbiamo fatto tre passi concreti:

1. Bucket di competenze allineati alle milestone della roadmap
   Q3: secure boot e flash encryption → tutti al Livello 3 in mbedTLS.
   Q4: rollout di delta-OTA → due firmware dev al Livello 4 in data logging e partition design.

2. Pratica integrata
   – Sessioni di pair-programming due volte a settimana con rotazione mentor/mentee.
   – “Friday Spike”: sandbox di 4 ore per sperimentare qualsiasi cosa legata al tema settimanale — mock-up di Kalman filter, diagrammi di scheda in PlantUML, ecc.

3. Metriche di progresso visibili
   – Lightning talk mensili “mostra la cosa che hai imparato”.
   – Bacheca Jira Goals con epic personali come “Elif sale ESP-IDF a 3: esempio OTA rilasciato.”

Abbiamo allocato esplicitamente il 10% della velocity dello sprint ai task di apprendimento. La Finanza inizialmente ha messo in discussione il costo di capacità, ma i numeri di retention sono migliorati: il turnover volontario è sceso allo 0% in 18 mesi.

7. Il ciclo di sviluppo di carriera — Prima l’ingegneria, non le HR

I tradizionali cicli di valutazione ci sembravano inadeguati. Li abbiamo sostituiti con un leggero Career Kanban:

Gli ingegneri muovono le card al proprio ritmo; i lead intervengono solo per sbloccare o celebrare. Questa fluidità rispecchia come funzionano le pull request — l’apprendimento è solo un altro branch.

8. Risultati sul campo — Meno downtime, agricoltori più felici

Dodici mesi dopo il lancio del framework:

• Il backlog dei bug si è ridotto del 48%.

• La cadenza di rilascio del firmware è migliorata da trimestrale a mensile.

• L’autonomia della batteria ha superato l’obiettivo invernale originale del 18%.

• I ticket di supporto per cadute del cellulare sono scesi del 60%.

Cosa più significativa, il tempo dalla specifica al primo prototipo validato è passato da otto settimane a 4,5. Gli ingegneri hanno accreditato il cross-training: il PCB designer che ha raggiunto il Livello 3 in Python ha scritto uno script di calibrazione che ha risparmiato una settimana di lavoro al banco di test.

9. Prendersi cura del futuro — Perché l’apprendimento fa parte della nostra carta ESG

Posizioniamo l’apprendimento continuo non solo come un benefit HR ma come un imperativo ambientale e sociale:

• Ambientale – Un firmware progettato meglio significa meno visite sul campo e minore impronta di CO₂.

• Sociale – I dipendenti formati diventano ambasciatori tech locali, stimolando l’innovazione regionale.

• Governance – Skill matrix documentate e promozioni trasparenti riducono i pregiudizi e rafforzano la conformità.

Ogni trimestre pubblichiamo un “Learning Impact Report” interno che mostra le correlazioni tra ore di formazione e OKR chiave (densità di bug, efficienza energetica). Il board lo esamina insieme ai numeri di fatturato — prova che le metriche sulle persone guadagnano lo stesso spazio in sala consiglio.

10. Lezioni apprese e consigli per altri team

1. Scrivete prima requisiti guidati dai risultati; le scelte tecnologiche seguono naturalmente.

2. Quantificate il debito tecnico così le discussioni diventano matematica, non emozione.

3. Le skill matrix visive fanno emergere i colli di bottiglia di talento più velocemente degli organigrammi.

4. Allocate tempo dedicato (noi abbiamo scelto il 10%) per rendere credibile l’apprendimento.

5. Legate l’apprendimento al codice vivo — una PR mergiata insegna più di qualsiasi MOOC.

6. Celebrate le piccole vittorie; i lightning talk battono le slide deck per condividere il know-how tacito.

7. Collegate pubblicamente l’apprendimento ai KPI di prodotto per conquistare la sponsorizzazione dei dirigenti.

11. Cosa c’è dopo per Tohum AB

La nostra roadmap 2026 include connettività duale NB-IoT + LoRa, previsioni dei nutrienti guidate dall’AI e un robusto contenitore v6 con obiettivo IP69K per operazioni agricole con lavaggio a pressione. Ogni frontiera genera nuove colonne nella skill matrix — ML a ultra-low-power, approfondimenti sul MAC di LoRaWAN, laboratori di ingresso ad alta pressione. Il framework vive: ripeteremo il ciclo requisiti-debito-apprendimento a ogni salto.

12. Una parola finale sulle persone

I chip di silicio invecchiano; i pannelli solari degradano; persino il suolo più ricco alla fine ha bisogno di essere reintegrato. L’unico asset che accumula valore indefinitamente è il potenziale umano. Progettando il nostro processo di apprendimento con lo stesso rigore che applichiamo a schematici e codice, abbiamo scoperto un ciclo virtuoso: prodotti migliori finanziano più apprendimento, che produce carriere migliori, che a loro volta producono prodotti migliori.

Se portate a casa una cosa dalla nostra storia, sia questa: investite nei vostri ingegneri come investite nella chimica delle vostre batterie. Entrambe immagazzinano energia, ma solo una può inventare il futuro.