Azienda italiana che realizza soluzioni informatiche per professionisti

[Versione italiana di seguito]

Disclaimer: Many of our customers have confidentiality agreements safeguarding their brand names from commercial purposes. Hence, you may encounter references such as “Client Name Confidential”, or the customer’s industry instead of the customer’s brand name.

In this article I will talk about the "IT Protocol", but beware - it's not a protocol any developer would think of, such as HTTP, TCP or SMTP... No, I mean the digital document flow management, registration and archiving.

In the last two years and a half, we worked on a challenging project for an Italian Company Building IT Solutions for Professionals. The project wasn't big it was huge! The whole team was made of about 27 people - divided in sub-teams, and each sub-team was assigned to a product module.

The most challenging thing? A strict deadline, very important for the customer: the end of April.

When I was assigned as Product Owner to this project (only for the IT Protocol module) things were very hard. Out of all modules, the Protocol one was the only one having the backlog still empty. So... First of all I had to roll my sleeves up, get outside my comfort zone and study the domain. I started reading books like "Il protocollo informatico per la pubblica amministrazione" or similar. articles, laws, AgID guidelines... I made charts, drawings, sketches for to understand the flow.

Then - after having gained some domain knowledge - I was able to speak the language of the Customer and started to write "product specifications". Yes, for this project I had to write formal specifications and requirements, rather than simple and agile user stories. And these requirements had to be formally approved by the customer before being able to start working on them, and every change to them had to be motivated, traced and approved once again! rather than "user stories" and that's what I did. I wrote how I expected things to work, look like, behave. And then asked the customer to approve them.

But what happened during the way? How were we supposed to deal with a strict deadline? Well... Using the most valuable tool a Product Owner has: prioritization!

First of all, we had to understand what requirements were legal - yes we had to comply with Italian laws - and so we focused on developing all features concerning legal requirements. And then we split the specifications in smaller requirements, some of them needed to be delivered before the deadline, while some other could be delivered in the next release.

And thanks to this incremental (I would also say "start-up like") approach, we were able to deliver all main and legally required feature before the deadline.

For the next release, we will build the missing features and make some adjustments... But for now, one more point scored thanks to our Agile approach!

Avviso: Molti dei nostri clienti hanno accordi di riservatezza che proteggono l'uso dei loro marchi per scopi commerciali. Pertanto, potreste incontrare riferimenti come "Nome Cliente Riservato" o indicazioni sull'industria del cliente anziché il nome del marchio.

In questo articolo parlerò del "Protocollo Informatico", ma attenzione: non è il tipo di protocollo che un qualsiasi sviluppatore potrebbe immaginare, come HTTP, TCP o SMTP... No, mi riferisco alla gestione del flusso della documentale digitale, alla registrazione e all'archiviazione!

Negli ultimi due anni e mezzo, abbiamo lavorato su un progetto impegnativo per un’azienda italiana che sviluppa soluzioni IT per professionisti. Non si trattava di un progetto grande, no... Era ENORME!! Il team era composto da circa 27 persone, suddivise in sotto-team, e a ciascuno di essi era stato assegnato un modulo di prodotto specifico.

La sfida più grande? Una scadenza strettissima, molto importante per il cliente: la fine di aprile.

Quando mi è stato assegnato il ruolo di Product Owner per questo progetto (in particolare solo per il modulo del Protocollo Informatico), la situazione era piuttosto complicata. Di tutti i moduli, quello del Protocollo era l'unico con un backlog ancora vuoto. Quindi, la prima cosa da fare è stata rimboccarmi le maniche, uscire dalla mia zona di comfort e studiare il dominio. Ho iniziato a leggere libri come "Il protocollo informatico per la pubblica amministrazione", articoli, leggi e linee guida dell'AgID... Ho realizzato schemi, disegni e bozzetti per capire a fondo il flusso.

Dopo aver acquisito una discreta conoscenza del dominio, ho potuto dialogare con il cliente utilizzando il loro linguaggio e ho iniziato a scrivere le "specifiche di prodotto". Sì, per questo progetto ho dovuto redigere specifiche formali e requisiti, piuttosto che semplici e agili user stories. E questi requisiti dovevano essere formalmente approvati dal cliente prima di poter iniziare a lavorarci, e ogni modifica doveva essere motivata, tracciata e approvata di nuovo!

Ma cosa è successo lungo il percorso? Come abbiamo affrontato una scadenza così rigida? Beh... Utilizzando lo strumento più prezioso a disposizione di un Product Owner: la prioritizzazione!

Prima di tutto, dovevamo capire quali di questi requisiti erano legali - sì, dovevamo rispettare le leggi italiane - e ci siamo quindi concentrati sullo sviluppo di tutte le funzionalità relative ad essi. Successivamente, abbiamo suddiviso le specifiche in requisiti più piccoli, alcuni dei quali dovevano essere consegnati entro la scadenza, mentre altri potevano essere rilasciati nella versione successiva.

Grazie a questo approccio incrementale (oserei dire in stile da "start-up"), siamo riusciti a consegnare tutte le funzionalità principali e legalmente richieste prima della scadenza.

Per la prossima release, costruiremo le funzionalità mancanti e faremo alcuni aggiustamenti... Ma per ora, possiamo segnare un altro punto a favore del nostro approccio Agile!