PoC di un progetto IT: una guida su come farlo al meglio

Creare il PoC di un progetto IT significa strutturare in modo corretto e funzionale qualsiasi iniziativa legata allo sviluppo informatico prima di scendere in campo e disperdere energie e risorse di fronte alle tante incognite che possono insorgere in fase di effettiva realizzazione. È il caso dei progetti software, la cui necessità spinge le organizzazioni ad accelerare il raggiungimento degli obiettivi fronteggiando complessità crescenti.

PoC di un progetto IT: che cos’è e perché è importante

Le risorse aziendali sono limitate e le nuove iniziative ICT possono essere costose. Un Proof of Concept è una metodologia che consente alle aziende di determinare la fattibilità di un’idea quando si tratta ancora di un’ipotesi non testata. L’approccio, infatti, piuttosto che concentrarsi sull’attuazione dell’idea, punta a dimostrare, testare o convalidare gli elementi essenziali del progetto tecnologico aziendale quando è ancora nella fase di proposta. Il progetto IT in questione potrebbe essere di qualsiasi tipo come, ad esempio:

• lo sviluppo e l’implementazione di nuovo software
• l’aggiunta o la sostituzione di hardware
• la prova di un nuovo servizio aziendale
• la modifica dei flussi di lavoro o delle piattaforme aziendali

Il PoC di un progetto IT consente a coloro che sono coinvolti nell’esercizio di prova del concetto di esplorarne tutti gli aspetti, compreso il suo potenziale finanziario, aiutando a definire un più corretto business plan e un coordinamento tra tutto il personale coinvolto. Certo è che richiede tempo, risorse fisiche e tecnologie di supporto.

Gli obiettivi di un Proof of Concept

I team IT si rivolgono sempre più ai PoC per testare e convalidare nuove iniziative. Se utilizzato con giudizio, il PoC di un progetto IT aiuta le organizzazioni a perfezionare le idee, individuare problemi, stimolare la creatività e massimizzare il successo dell’iniziativa. Concentrandosi sulla fattibilità di un progetto, il PoC dovrebbe dimostrare che l’idea o il concetto iniziale soddisfano sia i requisiti aziendali che le esigenze degli utenti. Ecco perché i team che creano i POC dovrebbero anche raccogliere feedback degli utenti come parte integrante del loro lavoro, per finalizzare meglio il progetto IT.

Quali sono gli obiettivi del Poc di un progetto IT

Riassumendo, un PoC di un progetto IT è un processo che aiuta a raccogliere informazioni importanti, tra cui:

• Il punto di vista dell’utente. I PoC aiutano a raccogliere il percepito degli utenti aiutando a perfezionare il progetto IT grazie a indicazioni circa nuove funzionalità o cambiamenti importanti che possono migliorare non solo la sua accettazione, ma anche il suo valore, traducendosi in maggiore competitività e più significative quote di mercato.
• Metodologie. Un’azienda che sviluppa nuovo software potrebbe voler provare nuovi metodi. I progetti PoC prototipano il codice funzionale e l’infrastruttura hardware su una scala limitata per convalidare la nuova metodologia, garantire la sicurezza, valutare le prestazioni e formulare piani pratici di applicazione più estesi.
• Compatibilità/interoperabilità. Una pianificazione aziendale finalizzata ad aggiornare il software aziendale potrebbe avviare il PoC di un progetto IT per garantire che la nuova piattaforma possa interoperare con l’infrastruttura in essere, identificare le eccezioni, determinare soluzioni alternative e valutare la compatibilità complessiva del nuovo elemento.
• Prestazioni. Le aziende possono utilizzare i PoC per convalidare le relative performance. Ad esempio, un PoC di un progetto IT può prototipare un’API e la relativa infrastruttura hardware sotto carico simulato per convalidare le prestazioni o valutare la sostituzione di un server obsoleto per garantire che i carichi di lavoro mission-critical funzionino adeguatamente sul nuovo server.
• Flussi di lavoro. Una pianificazione aziendale per implementare un nuovo workflow può eseguire un PoC per convalidare la disponibilità del provider, testare la funzionalità di backup e ripristino e raccogliere informazioni essenziali.

Poc di un progetto IT: vantaggi e opportunità

I PoC sono utili a tutti: utenti, stakeholder, investitori e team di progetto. Un PoC ben ponderato può offrire una serie di vantaggi, tra cui:

Mitigazione del rischio. Il costo dei moderni progetti legati all’IT ha reso molte aziende più restie ad accettare il rischio. È ovvio che sia più facile spendere soldi quando l’aspettativa di successo è alta. L’approccio preventivo, garantisce la risoluzione delle criticità e il successo del progetto prima del suo rilascio, aiutando i leader aziendali a giustificare l’investimento in progetti IT mission-critical o ad alto rischio.

Feedback anticipato e reindirizzamento. Alcuni risultati del PoC spesso indicano che il progetto proposto presenta delle criticità. In questo modo si ha l’opportunità di correggere i problemi prima che vengano investite risorse significative nel perseguimento del progetto. Se il progetto non è recuperabile, i team possono accantonarlo, reindirizzarlo per fare un nuovo PoC o abortire l’idea.

Identificare nuove opportunità. I progetti PoC possono dare un grande contributo all’innovazione dell’organizzazione o del business. Ad esempio, la valutazione di una nuova funzione software potrebbe generare un ripensamento completo su come finalizzarla e implementarla. Alcuni PoC dimostrano nuove tecnologie e prototipi che possono essere preziosi per le discussioni con gli investitori, ad esempio per garantire il budget di supporto a una nuova iniziativa tecnologica.

Inconvenienti della dimostrazione del concetto

Nonostante tutti i potenziali benefici, gli sforzi PoC possono anche comportare possibili inconvenienti:

• Costo. I progetti PoC portano via tempo al personale IT, che non può occuparsi di altri progetti perché impegnato a dare supporto, scegliere e acquistare strumenti e risorse cloud e via dicendo. Anche se i costi PoC dovrebbero rappresentare solo una piccola frazione dei costi associati a un progetto IT completamente realizzato, deve essere messo a preventivo un certo budget.
• Limitazioni della creatività. Le parti interessate e i membri del team PoC possono facilmente cadere nella trappola di supportare solo ed esclusivamente il PoC e non tutto il contesto in cui sarà inserito a livello operativo e organizzativo reale. Il che porta a una certa rigidità con forzature come, ad esempio: “X è ciò che volevamo vedere, quindi X è l’unica cosa di cui discuteremo”. Tali limiti sprecano preziose opportunità per un approccio più elastico e creativo.
• Scope creep. I progetti IT tendono a cambiare man mano che progrediscono. Se un progetto è stato effettivamente definito all’inizio, approvare e gestire queste modifiche sarà più semplice. Quando si documenta l’ambito di un progetto, le parti interessate dovrebbero essere il più specifiche possibile per evitare lo spostamento dell’ambito (detto scope creep), vale a dire una situazione in cui una o più parti di un progetto finiscono per richiedere più lavoro, tempo o impegno a causa di una pianificazione inadeguata o di problemi di comunicazione. Lo spostamento dell’ambito sposta gli obiettivi del completamento del progetto PoC, portando a un consumo maggiore di risorse rispetto a quanto previsto.

6 passaggi per un progetto PoC di successo

Le iniziative PoC in genere condividono sei fasi:

1. Validazione

Il primo passo in qualsiasi approccio PoC è determinare le esigenze, allocando gli strumenti, i talenti e il tempo necessari. Alcuni leader aziendali e IT potrebbero chiedersi se i rischi derivanti dalla rinuncia a un PoC siano maggiori dell’investimento richiesto per attivarlo.

2. Finalità

Il passaggio successivo si concentra su obiettivi, criteri specifici per il successo e parametri che il team può rivedere e condividere con le parti interessate. Le discussioni sull’ambito si concentrano anche sulla creazione di un team PoC che presume il coinvolgimento delle parti interessate più idonee e del personale tecnico con le giuste capacità.

3. Progettazione

Questa è la vera e propria fase di pianificazione del progetto, declinando la finalità del PoC in un piano attuabile che può essere rivisto, approvato, eseguito e misurato. La fase di progettazione può essere breve, ma è importante coinvolgere le parti interessate e i membri del team PoC per sviluppare fiducia nel piano e garantire una più forte motivazione al suo perseguimento.

4. Esecuzione

È a questo punto che il team costruisce e realizza il PoC di un progetto IT in conformità con le sue modalità di pianificazione. Il che potrebbe essere semplice, come chiedere a un grafico di disegnare dei modelli, o complesso, come creare un ambiente operativo funzionale per una valutazione completa della piattaforma. La fase di esecuzione potrebbe durare da ore a settimane a seconda della portata e della complessità del progetto PoC.

5. Feedback

L’esecuzione genera dei feedback che i team possono utilizzare per apportare ulteriori correzioni e perfezionamenti. I feedback che, secondo un approccio Agile dovrebbe essere parte integrante di un PoC, possono derivare dalle opinioni degli utenti ma anche da altri parametri, dai benchmark o ulteriori indicatori. Questo passaggio consente ai membri del team di ampliare le vision in modo da rivisitare l’ambito operativo e definire i passaggi utili ad apportare specifiche modifiche. Ad esempio, se una nuova interfaccia o delle funzionalità non hanno senso per gli utenti, il team può modificare il design, cercando soluzioni e approcci diversi.

6. Reporting

Una volta concluso il PoC di un progetto IT, i risultati e i dati dei test devono essere condivisi con tutte le parti interessate. Il reporting spesso include dati relativi a costi e budget che devono essere correlati poi all’implementazione completa del progetto. Qualsiasi preoccupazione o problema può essere discusso, in modo da verificare se sia il caso di esplorare PoC nuovi o alternativi. Le parti interessate in genere utilizzano la rendicontazione finale come base per la pianificazione e l’approvazione completa del progetto o, come già accennato, alla sua modifica o al suo annullamento.

Best practice per azionare un PoC per un progetto software a valore aggiunto

Qualsiasi tipo di PoC di un progetto IT richiede una corretta pianificazione ed esecuzione in un ambiente controllato, generalmente isolato dalle operazioni di produzione. Di conseguenza, esistono alcune best practice PoC a cui dare priorità. Per i PoC basati su software, le migliori pratiche includono quanto segue:

• Dati/applicazioni duplicati. I software moderni si basano in genere sull’accesso ai dati aziendali. Pertanto, i PoC necessitano di dati duplicati e persino di piattaforme software, come database SQL o NoSQL ridondati per garantire il funzionamento senza toccare i dati di produzione effettivi.
• Infrastruttura duplicata. Il software di un PoC richiede l’installazione su uno o più server e l’accesso alla rete aziendale. Ciò significa duplicare l’infrastruttura in modo che il traffico di rete PoC non interagisca con il traffico di produzione. A tal fine, gli sviluppatori utilizzano regolarmente tecniche DevOps o collaborano con il personale operativo IT per implementare gli asset necessari.
• Acquisire nuovi strumenti/flussi di lavoro. Il nuovo software richiede nuovi strumenti di sviluppo, test e distribuzione. Come prerequisito, i team devono acquisire e distribuire questi elementi.
• Comprendere le metriche/KPI. I pianificatori PoC devono comprendere le metriche e i KPI del software che saranno coinvolti nel progetto e garantire che sia installata tutta la strumentazione software necessaria per misurare e documentare i comportamenti del programma.

I PoC hardware prevedono anche una serie di best practice che, anche se non sono applicabili a qualsiasi PoC, saranno più efficaci se questi fattori verranno considerati in anticipo. Di seguito una lista delle indicazioni più utili:

• Comprendere i requisiti di sistema. Il nuovo hardware aziendale potrebbe comportare alimentazione, raffreddamento, montaggio, connessione o altri requisiti fisici. I team dovrebbero garantire che l’ambiente di distribuzione del PoC li soddisfi.
• Comprendere l’ambiente. Il nuovo hardware ha sempre uno scopo specifico. Un PoC deve essere in grado di garantire che il nuovo hardware sia effettivamente valido per un test. Ad esempio, se l’azienda desidera provare il PoC su un dispositivo di storage PCIe NVMe, deve essere disponibile un server non di produzione con un’interfaccia interna adeguata in cui sia possibile effettuare l’installazione.
• Prova al banco. Una volta stabilito un ambiente operativo, il personale IT dovrebbe testare il nuovo hardware per acquisire familiarità con la gestione dell’hardware. Quindi, è opportuno verificare le integrazioni con le piattaforme di gestione esistenti e altre principali applicazioni aziendali per convalidare l’interoperabilità. Infine, è consigliato esaminare l’hardware per quanto riguarda il suo funzionamento, le sue prestazioni e la sua idoneità allo scopo.
• Garantire l’isolamento dell’hardware. I test PoC non dovrebbero mai toccare le operazioni di produzione. Per ciò, è opportuno pianificare un supporto hardware duplicato che esisterà al di fuori della produzione, come un server isolato, uno storage e un segmento di rete.
• Comprendere i benchmark. Come per le metriche e i KPI del software, le prestazioni dell’hardware vengono spesso quantificate tramite strumenti di benchmarking basati su software. Per questo dovrebbero essere disponibili strumenti di benchmarking adeguati per i test e la convalida dell’hardware.