Dietro le quinte, il lavoro di un team di sviluppo e di gestione dell’operatività di un prodotto digitale è caratterizzato da molte soddisfazioni così come da molti problemi frustranti.

Dal punto di vista delle soddisfazioni, una di quelle che personalmente mi stimolano di più è quella di poter creare, spesso da zero, qualcosa che genera un risultato anche molto rilevante per un cliente.

Tra le frustrazioni ci sono invece quelle relative al fatto che è impossibile produrre software senza difetti o riuscire a servire sempre correttamente una richiesta operativa di un utente, anche con le migliori intenzioni, così come riuscire a far sì che un’infrastruttura abbia un uptime del 100% in un anno è pressoché infattibile e, in ultima istanza, anti economico.

In generale molti di questi problemi rimangono poco visibili agli utenti finali e ai committenti, se il team è ben organizzato e ci sono dei processi di controllo adeguati.

Tuttavia, proprio per la natura del software e dei sistemi che lo fanno girare su Internet, e in generale della complessità di una piattaforma digitale, è inevitabile imbattersi in bug, incidenti e problemi di comunicazione.

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

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

Quando viene lanciata una startup basata su un prodotto o servizio digitale, le prime settimane sono dedicate ad assicurarsi di procedere nella giusta direzione.

Tramite brevi iterazioni di programmazione, si parte sviluppando il set minimo di funzionalità necessarie per lanciare l’applicazione/servizio nel mercato; questo avviene al fine di validare il più presto possibile l’idea al minor costo e correggere la rotta da subito.

Continua a leggere

Alcuni dati confermano che i team di piccola dimensione (massimo 7/9 persone) sono più efficienti ed efficaci di quelli più grandi nel realizzare progetti.

Eppure, quando un progetto software è in ritardo rispetto alle attese, nel management tradizionale uno dei principi rimedi applicati è quello di aggiungere altri sviluppatori.

Continua a leggere