Cosa puoi aspettarti dal tuo team di sviluppo e cosa no nello sviluppo di software personalizzato

Il software personalizzato è assolutamente fondamentale in molti ambiti ma allo stesso tempo è difficile, complesso e costoso.

Vi sono rischi tecnologici, finanziari e di prodotto.

Cosa dovresti aspettarti a questo riguardo dal tuo team di sviluppo, e cosa invece no?

Ne parlo in questa puntata del podcast (sotto è disponibile anche la trascrizione completa).

Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.

Trascrizione

Ciao da Alex Pagnoni e benvenuto nel podcast del CTO Podcast, il podcast dedicato ai CTO e ai responsabili dei team di sviluppo, a chi vorrebbe diventarlo e a Founder e imprenditori digitali.

La puntata di oggi è molto utile sia ai CTO che alle persone che si devono relazionare con un team di sviluppo con il quale lavorano assieme nella costruzione di un prodotto digitale, come ad esempio un Founder, un imprenditore digitale, un cliente o un Product Owner e che vogliono ottenere prestazioni elevate dal team.

Nel corso degli anni ho infatti visto persone con questi ruoli diventare molto frustrati dall’interazione con gli sviluppatori che realizzano il software su misura per loro.

E questo è del tutto comprensibile, perché poche persone sono preparate per il loro primo progetto di software personalizzato.

Si lanciano in questo tipo di impresa con molto entusiasmo e mettono a disposizione la loro competenza in materia lato business e prodotto, però a volte questo processo va benissimo e altre volte invece va male.

Da questo punto di vista penso che la chiave per uscirne vivi sia quella di comprendere cosa il tuo team può fare e cosa non può fare per te.

Perché è più complicato di quanto pensi

Il software personalizzato è complesso

Innanzitutto cerchiamo di capire perché è più complicato di quanto potresti pensare.

Il software personalizzato è infatti difficile, complesso e costoso. A volte, le parti coinvolte in un progetto di questo tipo non comprendono adeguatamente quanto possa essere difficile, complesso e costoso. Perché?

Credo che sia perché oggigiorno la maggior parte delle persone interagisce sempre con software personalizzato. Presumono che, poiché possono vederlo, interagire con esso e (in una certa misura) capirlo, deve essere facile da progettare e realizzare. Confondono il prodotto di massa che tengono in mano con lo sforzo necessario in primo luogo per inventare quell’oggetto.

Ad esempio, uno smartphone è una specie di super computer che sta in una tasca che si può connettere a qualsiasi informazione accumulata in migliaia di anni.

Il numero di ore uomo che sono state necessarie per arrivare a questo tipo di risultato sono incalcolabili, ma allo stesso tempo si tratta di un oggetto che nelle versioni più economiche costa poche centinaia di Euro per unità per essere fabbricato.

Quando creiamo software su misura, non lavoriamo però in termini di produzione di massa. Stiamo infatti lavorando sull’invenzione in sé.

E’ come dire che non stiamo costruendo un’automobile in serie, ma che stiamo costruendo proprio la prima automobile, con tutto ciò che serve per arrivarci.

Il software su misura è rischioso

Inoltre, esistono molti tipi di rischi inerenti alla creazione di software personalizzato.

Per esempio:

  • Il rischio tecnologico, dove alcuni team arrivano a produrre l’80% di un progetto e poi si rendono conto che le decisioni architetturali iniziali o la mancanza di test automatizzati rendono impossibile completare il prodotto nei modi previsti. Oppure l’integrazione fondamentale con un sistema esterno necessario per il successo del progetto si rivela impossibile.
  • Il rischio finanziario: stimare e definire un budget per il software su misura è molto difficile, anche se in Axelerant siamo diventati piuttosto bravi nel farlo. Se il budget è troppo basso, un progetto può non raggiungere un livello sufficiente di funzionalità per il primo rilascio, mentre se il budget è eccessivo è possibile che non si ottenga un adeguato ritorno dall’investimento.
  • Il rischio di prodotto, dove potresti essere in grado di costruire il prodotto giusto con il giusto approccio allo sviluppo e con il budget giusto, ma fallire lo stesso perché nessuno vuole usarlo e quindi hai fatto la cosa sbagliata nel modo giusto.

Il team di sviluppo

Idealmente, il team di sviluppo del prodotto dovrebbe essere composto da un gruppo di sviluppatori con competenze articolate e multi disciplinari.

Potresti ad esempio avere da due a dieci sviluppatori software con vari gradi di esperienza.

Dovrebbe anche esserci almeno un Software Architect e magari un Interaction Designer.

Inoltre raccomando vivamente di avere un responsabile del prodotto (chiamato Product Owner) o comunque del team per aiutare a tenere il gruppo di progetto nella rotta giusta sfruttando le pratiche di gestione e sviluppo agili.

Cosa il team non può fare per te?

Per quanto eccellente possa essere un team di sviluppo di un prodotto digitale, certamente non può eliminare i rischi di progetto o rendere il software personalizzato facile, semplice ed economico contemporaneamente.

Se uno degli stakeholder del prodotto inizia a sentire la pressione di quei rischi o vuole cambiare in modo importante la natura del prodotto in corso di sviluppo, ho cattive notizie.

Può infatti essere che non ci sia il bisogno di quel prodotto o che non ci sia il budget sufficiente. O potrebbe esserci il caso che la dimensione e la complessità del progetto sia stata sottostimata.

Anche il miglior team di sviluppo non può cambiare questo fatto.

Cosa invece può fare per te?

1. Un team di sviluppo può e deve comunicarti le informazioni sul progetto in modo accessibile e comprensibile.

La maggior parte delle persone coinvolte nello sviluppo del prodotto come stakeholder hanno bisogno di sapere a che punto è il progetto e quando sarà realizzato il loro software su misura.

Un team di sviluppo di un prodotto digitale può aiutarti in questo senso utilizzando un grafico di burn up e aggiornando la roadmap di progetto.

Può inoltre darti un’indicazione di quanti sprint saranno necessari affinché il progetto raggiunga un certo stato di avanzamento.

Può inoltre aiutarti a decidere se ridurre lo scope del progetto o se aggiungere budget.

2. Un team di sviluppo può aiutarti a identificare il rischio, suggerire delle opzioni per mitigarlo, contenerlo, evitarlo oppure ignorarlo.

Come dicevo prima, il rischio è insito nello sviluppo di software custom in sé. Quello che può fare un buon team di sviluppo è identificarlo e renderlo evidente il più presto possibile e in modo frequente.

Cercherà inoltre di affrontare questi rischi prima invece che dopo.

Ovviamente non lo fanno per farti venire un infarto, ma per evitare che il rischio diventi un problema critico o bloccante che impedisce di far progredire il progetto.

A sua volta il team ha bisogno di te come stakeholder ed esperto in materia per aiutarlo a far comprendere il valore del progetto, in modo da prendere in carico per prime le parti più rischiose e di valore del prodotto da costruire.

3. Un team di sviluppo può darti informazioni accurate al meglio delle sue conoscenze.

Un team di sviluppo serio dovrebbe dirti la verità sullo stato del progetto e del budget, anche se si tratta di informazioni che non vorresti sentire.

La maggior parte dei team di prodotto è incentivato a fornire informazioni accurate ai propri referenti.

Questo perché le informazioni non precise promuovo un dissallineamento delle aspettative e aumentano la possibilità che il progetto fallisca.

E il team di sviluppo non vuole che questo si verifichi quanto te.

L’importanza della fiducia

Una relazione di fiducia è essenziale per ottenere un progetto di successo.

La responsabilità del tuo team è quella di forniti informazioni accurate in modo da poter prendere decisioni aziendali intelligenti.

Ad esempio, il tuo team potrebbe dirti che una certa funzionalità è molto più complessa di quanto pensassero inizialmente. Ciò potrebbe significare che il prossimo rilascio non includerà tutte le funzionalità che desideri. Potrebbe quindi essere necessario trovare un modo per aumentare il budget o ritardare il rilascio se si desidera avere tutte queste funzionalità.

Questa è sempre una notizia difficile da dare, ma conoscerla è meglio che non sapere perché in questo modo sei in grado di prendere provvedimenti per risolvere i problemi e mitigare i rischi.

Il tuo team deve affrontare il rischio, offrendoti delle opzioni per mitigarlo, chiedendo aiuto per risolvere i problemi che li stanno bloccando e informandoti sui progressi man mano che il tempo passa e che il budget si consuma.

Fai attenzione a quando la fiducia diminuisce

Se come CTO, imprenditore o comunque come Product Owner inizi ad avere l’impressione che il tuo team non ti stia dicendo tutta la verità e che ci sia meno fiducia, allora dovresti chiederti il perché.

Ci sono molte risposte a questa domanda. Il team potrebbe nascondere una mancanza di conoscenze tecniche. Potrebbero non volerti deludere. Potrebbero avere paura per il loro lavoro.

Pensa però anche a come li hai trattati (e sii onesto con te stesso). C’è qualcosa che hai fatto per impedire loro di dirti la verità sullo stato del progetto? C’è qualcosa che potresti fare ora per incoraggiarli a dirti la verità?

Ad esempio, hai forzato un po’ troppo le stime per far consegnare qualcosa più rapidamente? Questa è una strategia a breve termine che mette in pericolo il successo a lungo termine.

Con questo tipo di pressione, potresti ottenere uno sviluppo di un buon 80% del prodotto un po’ più veloce, ma molto probabilmente finirai con problemi tecnici che ti impediscono di arrivare al 100% e certamente accumulerai molto debito tecnico, di cui ho già parlato in alcune puntate precedenti e in forma più strutturata nel report gratuito che puoi scaricare all’indirizzo www.debitotecnico.com.

Dopo un po’ di autoriflessione, fai al tuo team queste stesse domande. Assicurati però di fare tutto il possibile per mettere a proprio agio il tuo team quando fai questo genere di approfondimento. Avere questo tipo di conversazioni aperte e oneste può ricreare la giusta connessione con il tuo team e ristabilire la fiducia.

Questo è molto importante, perché la fiducia promuove la comunicazione di informazioni accurate sul tuo progetto.

Il software personalizzato può essere uno strumento incredibile per le aziende, in particolare quelle che sviluppano un prodotto o una piattaforma digitale core business. Può sbloccare modelli di business, efficienza e profitti che prima non erano neanche immaginabili.

Se non funzionasse, la gente non ne farebbero l’uso che ne fa! Ma non è senza pericolo.

Se hai intenzione di sviluppare software personalizzato, sfrutta efficacemente un team di sviluppo per garantire il successo. Trova una squadra di cui ti puoi fidare, non sottovalutare la difficoltà inerente al software personalizzato e fidati del tuo team.

Grazie per avere ascoltato questa puntata del podcast dedicata alle performance dei team di sviluppo.

Grazie di nuovo e al prossimo episodio, ciao da Alex.

Connettiti e confrontati con i tuoi pari

Entra in CTO Mastermind, dal 2018 la Community originale dei Tech Executive italiani. Connettiti con i tuoi pari, confrontati sulle tue priorità, prendi decisioni migliori e accedi a strumenti, contenuti ed eventi esclusivi.

Tags: axelerant, performance, project & team management, team

More Similar Posts

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Compila questo campo
Compila questo campo
Inserisci un indirizzo email valido.
Devi accettare i termini per procedere