Il progetto consisteva nel realizzare un nuovo prodotto core in Kraken per gestire le letture nei diversi mercati e supportare l'espansione internazionale.
Kraken è un sistema operativo tutto in uno per le utilities. Gestisce e automatizza tutti gli aspetti operativi di un'azienda energetica.
Sebbene Kraken sia nato come una tecnologia del gruppo Octopus Energy, è un sistema venduto a decine di altri operatori, in diversi paesi del mondo (come puoi vedere dal sito, sono inclusi nomi come Plenitude, Origin, EDF, Tokyo Gas, EON)
Contesto
La situazione iniziale, per quanto riguarda la gestione delle letture, era piuttosto frammentata. Il software utilizzato era di alta qualità, ma spesso veniva "ripetuto" in mercati diversi.
Molte funzionalità comuni erano infatti state scritte, e continuavano a essere mantenute, in punti diversi del sistema: per esempio in due paesi diversi.
Questo è comprensibile, perché la gestione delle letture è molto legata al territorio: ogni paese ha i suoi formati e i suoi processi.
Tuttavia, moltissime esigenze rimangono simili: interrogare il sistema, effettuare azioni di correzione, visualizzare grafici di consumo, applicare validazioni sulle letture in ingresso, ecc. Sono tutte necessità comuni.
Si è quindi deciso di creare un prodotto core e un nuovo team. L'obiettivo era realizzare un pannello di controllo centrale che:
- centralizzasse tutte le funzionalità comuni
- rimanesse estendibile e personalizzabile dai team locali
In questo modo si sarebbe ottenuto il meglio dei due mondi: da un lato si sarebbe smesso di sviluppare e mantenere più volte le stesse funzionalità, usando invece un unico prodotto core. Anche l'affidabilità ne avrebbe beneficiato: riusare un prodotto core battle-tested, già diffuso in tanti paesi, è più stabile che riscrivere una nuova funzione da zero. Dall'altro lato non si sarebbe rinunciato a personalizzare il pannello secondo le peculiarità di ogni paese.
Abbiamo quindi dato il via a questo prodotto e, nel mio nuovo ruolo da Tech Lead dedicato, abbiamo iniziato a costruire da zero un team internazionale e a gettare le fondamenta tecniche del sistema.
Sfide
Come menzionato sopra, non volevamo togliere ai team locali la possibilità di personalizzare il pannello di controllo.
Ogni paese ha le sue peculiarità, ed è quindi giusto che i team locali possano effettuare personalizzazioni ad-hoc: azioni custom, formato e proprietà dei dati visualizzati, raggruppamenti, filtri specifici per paese, e altro.
Inoltre, parliamo di una grande quantità di dati gestiti dal sistema. Per fare un esempio: in Italia si possono avere letture elettriche con una granularità di 15 minuti, quindi 96 letture al giorno. In Australia addirittura ogni 5 minuti, quindi 288 letture al giorno.
Su 1.000.000 di punti di fornitura del genere, significherebbe: - 96.000.000 di letture al giorno nel caso italiano - 288.000.000 di letture al giorno nel caso australiano
Kraken ha dei sistemi di elaborazione e storage per gestire questa mole di dati egregiamente. Tuttavia, come puoi immaginare, non è banale permettere filtri, raggruppamenti e grafici su una tale quantità di dati in modo dinamico.
Le funzionalità del pannello, inoltre, non devono coprire solo le esigenze del mercato retail, ma anche quelle del B2B. Questo introduce diverse difficoltà, soprattutto perché nel mercato energetico B2B si inizia a ragionare su gruppi di punti di fornitura anche molto grandi, e non più sul singolo punto. Di conseguenza cambiano anche le esigenze e gli obiettivi.
Un'altra sfida importante era a livello organizzativo: dovevo creare un team internazionale da zero.
Non era la prima volta che mi trovavo ad assumere e gestire un nuovo team (lo avevo già fatto in iliad, con iliadbusiness), ma questo comunque non rende le cose facili: fare colloqui, mentoring, introdurre persone nuove in un ecosistema complesso e renderle produttive rimane una sfida ardua.
Inoltre, tutto questo deve talvolta avvenire coordinandosi con timezone non favorevoli, dal momento che il team è distribuito globalmente. Per quanto riguarda i paesi europei, non ci sono grosse frizioni. Per quanto riguarda la cosiddetta "APAC timezone", invece, è più complesso.
Ad esempio, per l'Australia, parliamo (dall'Italia) di 8 ore di differenza nel migliore dei periodi e di 10 nel peggiore. L'overlap sugli orari di lavoro è praticamente inesistente e questo richiede adattabilità. Onestamente, non credo sia per tutti.
Obiettivi raggiunti
Ho avuto grosse soddisfazioni da questo progetto.
Ad oggi (2026) il team è distribuito tra UK, Germania, Italia e Australia.
Il nostro prodotto è utilizzato su scala globale, in oltre 9 paesi diversi. Per quanto riguarda i clienti che lo usano, ormai ho perso anche il conto.
I feedback ricevuti dagli utenti sono ottimi, e continuiamo con costanza a condurre user interview per rimanere a contatto con loro e farli contenti.
Anche da un punto di vista tecnico, siamo arrivati a un punto dove gli altri dev usano il nostro prodotto quasi come fosse un vero e proprio framework: lo abilitano sui nuovi clienti, lo personalizzano e lo estendono senza che nemmeno il team se ne accorga, perché sono totalmente autonomi.
I nostri sforzi nel fornire APIs semplici da usare e una documentazione tecnica chiara hanno ripagato.
Se guardiamo all'affidabilità, anche qui i numeri sono molto buoni. Le uniche vere preoccupazioni arrivano dalle nuove funzionalità all'avanguardia che continuiamo a introdurre, ma che rilasciamo comunque con gradualità, in modo da raggiungere la piena stabilità prima dell'adozione completa.