In questo articolo tratto un argomento che mi sta molto a cuore che è anche uno di quelli più contro intuitivi, soprattutto nell’ambito del digitale e nella gestione appunto di piattaforme e prodotti digitali.

Un concetto che infatti ripeto spesso è che la tecnologia è tutto sommato facile, se la raffrontiamo al vero problema che è invece quello delle persone.

Inteso come: gestire gli aspetti tecnologici di una piattaforma digitale è il problema minore rispetto a quello di gestire le persone che lo fanno funzionare.

A dispetto di quello che pensano molti non addetti ai lavori, un prodotto digitale non sta in piedi da solo ed è necessario farlo evolvere e correggerlo continuamente.

Continua a leggere

Hai mai la sensazione che gestire lo sviluppo e la manutenzione del tuo prodotto digitale svolte dal tuo team (interno o esterno) sia come cercare di spegnere un palazzo in fiamme?

Mi riferisco al fatto che definire le priorità degli sviluppi, delle attività di supporto, degli incidenti e di tutte le altre operazioni digitali è un vero e proprio inferno dove si risolve una cosa e se ne rompe un’altra, si litiga continuamente nel definire delle scadenze che molto frequentemente non vengono rispettate e lo spazio per migliorare la situazione si fa sempre più ristretto.

E questo avviene in modo paradossale: più si cerca di pianificare le attività in modo esatto, tentando di mettere a punto anche il più piccolo dei dettagli, facendosi dare stime più precise possibili dagli sviluppatori e dagli altri specialisti, allineandosi il più frequentemente possibile con il team, più la situazione si aggrava invece di migliorare.

Continua a leggere

L’unicorno è un animale mitologico con un corno dai poteri magici che una volta si pensava esistesse davvero, tanto che nel medioevo si trovava persino nei testi “scientifici”.

Si diceva che fosse talmente prezioso che sulla terra se ne poteva trovare solo uno vivente per volta, ma l’impossibilità di trovarne un esemplare fece sì che diventasse definitivamente un mito.

Anche il digitale ha il suo unicorno: il CTO, un personaggio molto prezioso e ricercato ma così raro da essere introvabile, al punto che molti si chiedono se esista davvero (sì, esiste anche se pochi ne hanno uno).

Il CTO (sigla per “Chief Technology Officer”), in breve, è colui che sceglie e “governa” tutte le tecnologie e infrastrutture che fanno funzionare una piattaforma digitale.

Continua a leggere

Quando le aziende intendono affidare la realizzazione di un progetto software in outsourcing ad un team di sviluppo esterno, generalmente chiedono un preventivo di spesa per scegliere il fornitore.

Una delle tecniche usate per la richiesta di preventivo è la RFP (Request for Proposals), in alcuni casi necessaria per policy aziendale, nella convinzione che sia un modo efficace di scegliere il miglior fornitore.

Nel tempo ho letto molte RFP, tuttavia quasi sempre ho potuto verificare che sono realizzate in modo tale da produrre gli effetti opposti a quelli che il cliente desiderava ottenere, per questo motivo ti spiegherò un metodo più efficace per scegliere un fornitore di sviluppo software.

Mentre la maggior parte delle richieste di preventivo sono focalizzate sul software da costruire e sui costi, penso che sia meglio concentrarsi sul fornitore e il suo team di sviluppatori, scegliendo il migliore e lavorando collaborativamente con loro per costruire il miglior progetto possibile.

Continua a leggere

Una prassi comune lavorando nel mondo server-side è definire diversi ambienti di esecuzione e di deploy per le proprie applicazioni. Solitamente troviamo almeno un ambiente dedicato allo sviluppo ed un altro che rappresenta l’ambiente di produzione. I vari ambienti si differenziano utilizzando diversi valori per parametri comuni quali le credenziali di accesso al database, l’attivazione degli strumenti di log, il modello di autenticazione, ecc.

Uno dei primi ostacoli che si incontrano lavorando con un framework client-side come AngularJS è quello di trovare un meccanismo per poter differenziare l’ambiente di esecuzione della propria applicazione senza poter contare sugli strumenti abituali disponibili lato server.

In questo articolo mostreremo una possibile soluzione realizzata collaborando assieme a PhotoSì e Fabio Masini basata sulla riscrittura dei nostri file sorgenti tramite task Grunt che valorizza determinate variabili JavaScript a seconda che si voglia eseguire la nostra applicazione in un ambiente di sviluppo o in un ambiente test.

In particolare vedremo come utilizzare diversi endpoint REST a seconda dell’ambiente di esecuzione che vogliamo utilizzare.

Continua a leggere