Dopo ormai 10 anni di lavoro in campo mobile posso dire di aver creato da zero 4 team mobile e/o team Android. In questo articolo dunque voglio individuare 5 fattori critici per la creazione di un team software di successo, con particolare attenzione a un team mobile. Molti fattori però a mio avviso si possono traslare anche in altri contesti.

E’ naturale che purtroppo per imparare ho dovuto sbagliare direttamente o indirettamente quasi tutti di questi punti. Quindi se anche tu sei nelle sabbie mobili per aver pescato una delle carte imprevisti qui di seguito, sappi che sei in buona compagnia 🙂 anche io ci sono entrato più volte purtroppo.

Vediamo però come poter schivare queste potenziali bombe atomiche e cercare di sopravvivere se devi creare un team da zero.

Riscrivi o cambia il meno possibile

Questo è decisamente l’errore più comune e anche con conseguenze potenzialmente più nefaste che puoi incontrare.

Diciamo che raramente entri in un’azienda e si parte veramente da “zero”. C’è sempre un pregresso di altre applicazioni già esistenti. Fatte o da programmatori che sapientemente si sono dati alla fuga vista la mal parata o da consulenti il cui interesse nella qualità e gestione del debito tecnico era prossima allo zero.

Il risultato è che chi non ha avuto questa nefasta esperienza pregressa parte subito in quinta con la frase potenzialmente peggiore per la tua azienda: “riscriviamo l’app!!” O, più in piccolo, “riscriviamo la schermata X!” o il “flusso Y!”. Oppure: “cambiamo totalmente architettura! Questa è molto meglio!”

Bene o male la morale è la stessa e prevede un Big Bang Refactor che impatta su tutta l’applicazione. A volte al punto persino di doverne creare una nuova.

Naturalmente io qui ho portato questa problematica fino allo stremo. Tanto che quando lavoravo in CenterVue i colleghi mi chiamavano scherzosamente “Unfortunately has stopped”.

Questo perché ero solito fare refactoring importanti che portavano inevitabilmente l’app a instabilità che ne comportavano poi il crash quando venivano utilizzate. Oltre a non saper usare in modo efficace i test per limitare questa problematica.

Questa problematica in realtà nasconde varie insidie e vari scenari che il programmatore stesso non vuole affrontare. Nel pratico:

• “sporcarsi” le mani con codice poco chiaro, probabilmente buggato, non testato e organizzato male. Dovendo dunque “adeguarsi” a questo modo di lavorare temporaneamente per far funzionare le cose.
• imparare tecnologie magari ormai vetuste che non danno un grande beneficio a livello di curriculum e che quindi sono viste come poco interessanti, specialmente da elementi junior del team.
• rischiare di introdurre importanti regressioni e quindi problematiche prima non esistenti visto che i requisiti su cui è stata creata l’app sono ignoti e i test magari mancanti. E venire anche accusati dunque di aver “peggiorato” la situazione ed essere persino dei programmatori peggiori dei precedenti.
• paura di sentirsi dire di essere una “scelta peggiore” rispetto al programmatore precedente. In questo caso, è naturale essere meno performanti di qualcuno che magari conosceva quella codebase dall’inizio. “Screditare” un programmatore precedente può sembrare una buona idea per porsi come “superiore”, il risultato invece è che fai solo brutte figure.
• paura di vergognarsi di fronte ad un altro programmatore esterno che vede quel codice e che quindi giudichi la capacità del programmatore suddetto in base a quanto vede. Sembra assurdo, ma molti programmatori si identificano con il codice che scrivono.
• convinzione che si può un po’ “migliorare” il codice legacy ma è impensabile cambiarne l’architettura di base magari già nata male.
• incapacità di affrontare il codice legacy in modo efficace minimizzando i problemi e massimizzando gli effetti positivi.
• ecc.

Per questo motivo, a prima vista, per il programmatore sembra molto più sensato e anche più conveniente riscrivere tutto da zero e togliersi il pensiero invece che mettersi a sistemare un progetto già nato male in partenza.

Ti piacciono questi argomenti? Seguimi su instagram per non perdere i prossimi articoli 🙂

Tuttavia non sta tenendo in considerazione varie problematiche fondamentali:

• se sono stati necessari 5 anni per scrivere un dato software, non ci vorranno meno di 4 anni per riscriverlo “fatto bene”. E tu potresti avere solo 6 mesi di tempo per sistemare la codebase e lavorare su quel codice.
• anche avessi quei 5 anni, ti ritroveresti a mantenere due codebase distinte. Una “vecchia” che deve ancora avere bugfix ed eventuali aggiornamenti e una “nuova”.
• La nuova app non riuscirà mai a prendere il sopravvento perché ci saranno sempre più funzionalità da “portare” nella nuova architettura man mano che il tempo avanza. Pertanto non stai cessando il codice vecchio, lo stai facendo diventare una spada di Damocle.
• Stai “giustificando” il fatto di lavorare “male” nella vecchia app perché stai facendo la nuova. Acuendo ulteriormente le problematiche già esistenti.
• La “vecchia app” diverrà sempre più complessa da mantenere nel tempo, con sempre più librerie deprecate che smettono di funzionare quando ormai è “troppo tardi”. Richiedendo un effort sia di tempo che economico sempre più difficile da giustificare.
• Ecc.

Fare questo errore può persino portare la tua azienda al fallimento per l’incapacità di riuscire a colmare il gap tra “app vecchia” e “app nuova” in tempo utile, portando a una grande frustrazione da parte di clienti e management e impedendoti di portare funzionalità nuove sul mercato in tempo.

Queste sono solo alcune delle motivazioni per cui questa scelta potrebbe non essere oculata. In questo post si trova una descrizione più puntuale ed estesa del problema.

L’approccio migliore invece è proprio quello di cercare di toccare il meno possibile e partire con il coprire l’applicazione con più test di accettazione possibile. Nel caso di un’app mobile, parliamo di test ui end to end.

L’obiettivo che vogliamo è dunque quello di andare a individuare quelli che sono i requisiti fondamentali del nostro prodotto software. E che sappiamo con assoluta certezza che devono funzionare a tutti i costi.

Il problema infatti di non avere dei test non è solo una questione “estetica” (ovvero “non avere i test fa brutto”). E’ un grande problema perché vuol dire che non abbiamo i “criteri di accettazione” del software che è stato scritto. Dunque non sappiamo cosa dovrebbe fare e come dovrebbe farlo.

Per esempio, se abbiamo un’app che gestisce l’apertura delle auto in sharing e il loro utilizzo, se l’auto non si apre è un requisito di accettazione fondamentale. Dunque andrà gestito e mappato con un test ui end to end.

Successivamente si andrà a riscrivere l’applicazione in modo da poter inserire step by step dei test sempre di più a granularità fine man mano che si procede. Tutto ciò è descritto in dettaglio nel libro Working Effectively with Legacy Code che ci spiega l’approccio corretto al refactoring in modo da essere il meno distruttivi possibile. Fino a poter anche smantellare gli ui test lasciandone solo il numero minimo indispensabile, seguendo il principio del testing pyramid.

Un video magari più “veloce” del libro che ho citato può anche essere questo video di Mancuso che ci mostra come affrontare una codebase legacy per poter aggiungere dei test e verificarne il comportamento:

Si possono trovare molte altre risorse sul tema nel repo di XPeppers sotto la sezione Refactoring e TDD.

Un ragionamento simile si può naturalmente estendere anche al team. Nel caso di un cambio di gestione dell’app è sempre conveniente fare le cose in modo graduale e limitare il più possibile il turnover all’interno del team. Spesso si dice che tutti sono utili ma nessuno è indispensabile.. ecco, non è vero.

Perdere uno sviluppatore che magari lavora al progetto da 5 anni vuol dire perdere moltissimo in termini di conoscenza del prodotto, requisiti e dinamiche. Specialmente se è l’unico rimasto ad avere certe informazioni. Per questo è fondamentale assumere le persone giuste, in modo da trattenere gli elementi chiave nel team il più possibile.

Assumi le persone “giuste”

Le assunzioni, ahimè, sono sempre un grave dilemma. Trovare qualcuno di competente ma allo stesso tempo anche in gamba come persona è una sfida notevole. Non per niente l’obiettivo di questo sito è proprio quello di creare una community di persone veramente capaci a 360° per aiutare sia noi sviluppatori a trovare colleghi in gamba, sia le aziende a trovare specialisti in questo settore.

A mio avviso ci sono due requisiti fondamentali quando si cerca una persona nuova. Più il nuovo innesto è forte in queste due aree, più performerà bene all’interno del team.

Capacità di ricevere feedback e applicare le indicazioni

E’ una qualità molto difficile da sviluppare e ho fatto anni e anni di esercizi su questa cosa. A livello di “improvvisazione teatrale” si chiamerebbe la capacità di non controllare la scena.

Anni fa feci un workshop di improvvisazione al Festival di Tolfama, il cui coach era Mico Pugliares, il cui tema era la differenza tra Ruolo e Status. Un workshop a mio avviso eccezionale che consiglierei a qualunque professionista.

Molto in breve, il ruolo è quello che hai scritto sulla job description su LinkedIn. Avvocato, Programmatore, Personal Trainer, ecc. Lo status è se hai davvero potere decisionale su una certa persona e hai la capacità di dargli ordini e quella persona li esegue.

Per fare un esempio pratico, la moglie di un importante politico potrebbe fare anche la casalinga. E quindi avere un ruolo “basso”. Però potrebbe avere uno status maggiore del marito quando lui è a casa e quindi fargli fare ciò che vuole alla lettera. Nell’improvvisazione teatrale personaggi con ruolo e status molto contrastante sono i personaggi più difficili da fare ma anche i più divertenti.

Pensiamo a un bambino che urla e dà gli ordini alla madre. Pensiamo a Dudley, il cugino di Harry Potter, che aveva totale potere decisionale in casa nonostante fosse appena un infante.

A livello aziendale, molti cercano di aumentare al massimo il loro ruolo non perché realmente se lo meritano o “ha senso” che abbiano un certo ruolo aziendale, ma per una loro incapacità a gestire e ricoprire un ruolo che comporta spesse volte di avere uno status basso. Vogliono dunque “sbagliare con la loro testa” invece che “fare giusto con la testa degli altri”.

La cosa per me è stata particolarmente evidente quando sono passato dall’università al lavoro. All’università nessuno vuole essere il “responsabile” del gruppo, perché implica solo rogne e hai zero potere decisionale. Nella vita reale invece tutti vogliono essere CEO.

E’ anche il motivo per cui ho accettato di buon grado di fare l’IT Manager anche quando obiettivamente era, per me, troppo presto. Ed è anche il motivo per cui nell’improvvisazione teatrale è frequente vedere persone che vogliono sempre fare il re, il comandante, il generale, ecc.

Infatti, mi è venuto in mente quel workshop proprio perché mi fu chiesto di fare una scena in cui ero un umile schiavo al servizio del re. E dovevo aggiornare il re su quanto era avvenuto al fronte. Il dialogo che feci fu qualcosa di questo genere: “gli unni sono alle porte. Dovremmo predisporre delle squadre per fermarli prima che prendano il castello. Ci sono già dei cavalieri sul portone principali ma bisognerebbe aumentarne il numero ecc.”

Ti piacciono questi argomenti? Seguimi su instagram per non perdere i prossimi articoli 🙂

Fui quasi subito interrotto da Mico che mi disse: “scusa, ma tu sei solo uno schiavo o sei il generale capo dell’esercito?”. E’ questo il punto: io stavo cercando di assumere uno status alto con il re, dicendogli cosa fare, quando in realtà dovevo fare una scena a status basso e limitarmi a “prendere gli ordini”.

Avere una persona che fa molta fatica ad assumere uno status basso, è una persona che:

• non sa recepire i feedback e cerca di fare di tutto per proiettarsi come migliore di quanto non è per evitare che venga intaccata la sua autostima. Il risultato sarà che tenderà ad imporre ciò che vuole sugli altri “forzandoli” a seguire le sue decisioni. Al netto che siano intelligenti o meno.
• non esegue quanto deciso quando gli viene chiesto di fare qualcosa. Il che comporta che il suo atteggiamento è imprevedibile e inaffidabile. Per esempio, viene scelto di fare una certa lavorazione, ma a suo avviso non è così importante e invece si mette a lavorare ad altro.
• non si prende la responsabilità delle sue azioni. Volendo proiettarsi come a status alto a tutti i costi, farà molta difficoltà ad ammettere un suo errore o sarà totalmente incapace nel chiedere “scusa” ai colleghi.
• farà sentire inferiori gli altri. Non volendo mai stare a status basso, cercherà di “schiacciare” gli altri facendoli sentire inferiori o sbagliati per non affrontare lo scenario in cui sono gli altri a dirgli cosa fare.
• ecc.

Nota: ho fatto tutte queste cose esasperandole al massimo in certe situazioni. Non ne vado fiero, ma allo stesso tempo è necessario sbagliare per rendersi conto che certi atteggiamenti non sono efficaci.

Tutte queste problematiche, ed altre, si possono trovare nel libro The Five Dysfunctions of a Team e sono proprio il sintomo di questa problematica basilare. Infatti:

• La mancanza di fiducia deriva appunto dal fatto che questa persona non esegue quanto gli viene richiesto.
• La paura del conflitto nasce dal fatto che volendo tutti porsi come status alto, nessuno vuole “perdere” e passare a status basso. Pertanto, si preferisce evitare lo scontro per mantenere intatta l’autostima dei membri del team. A discapito dell’efficacia delle discussioni.
• La mancanza di focus deriva appunto, come dicevamo, dal voler seguire il proprio istinto che non quanto è stato deciso dal team. Perdendo di vista le priorità e ciò che è necessario per i clienti.
• La mancanza di responsabilità deriva proprio dalla sfiducia che poi hanno i membri nel team in decisioni che poi puntualmente non verranno mantenute e portate a termine. O dove tutto è lasciato al caos. Pertanto, gli altri membri del team non vogliono sentirsi responsabili per decisioni che non condividono.
• E infine il mancare gli obiettivi è semplicemente un risultato inevitabile quando si hanno membri del team con queste problematiche.

E’ naturale che non è una problematica totalmente risolvibile. Anche io non mi ritengo perfetto in quest’ambito, nonostante ci abbia lavorato molto. E ci sta anche saper “tollerare” qualche sbavatura dei colleghi per far funzionare un team.

Però è anche vero che esistono soggetti molto bloccati su questo fronte. Sono tutte persone che con l’esercizio e l’impegno possono migliorare, com’è stato anche per me. Tuttavia, sono persone molto complesse da gestire, che possono allungare notevolmente i tempi di sviluppo e complicare di molto la gestione del team.

Puoi trovare qualche ulteriore considerazione al riguardo in questo mio video dedicato all’argomento:

Capacità tecniche di base

A mio avviso le capacità nella programmazione non si possono improvvisare. Specialmente in Kotlin e Java o si ha una forte conoscenza degli elementi base del linguaggio o si finirà inevitabilmente per scrivere codice fragile e scarsamente mantenibile.

In questo alcuni includono anche avere una laurea in informatica, altri meno. Io personalmente mi sono trovato tendenzialmente meglio con chi la possedeva. Anche se conosco persone competenti che non hanno una laurea. Dipende molto dal singolo, ma certo averla è un plus importante in fase di colloquio. Una trattazione più ampia la puoi trovare qui dove parlo anche della differenza tra la laurea e altri percorsi più brevi.

Allo stesso tempo, quando ho iniziato il mio lavoro nella mia attuale azienda, ovvero Neato Robotics, il primo anno è stato davvero difficile perché dopo un anno e mezzo di programmazione back-end e un anno di fatto da “manager”, ero rimasto decisamente indietro rispetto alle tecnologie utilizzate nello sviluppo Android.

Il lato positivo è che in questo caso dopo un anno / anno e mezzo la problematica si è ridotta notevolmente fino a risolversi. Con altri colleghi, utilizzando PR e pair programming, i tempi si sono ridotti anche in meno di 6 mesi. Nel caso invece di lacune importanti sui fondamenti del linguaggio potrebbe essere molto complesso risolvere la situazione.

Come anticipato, uno di questi metodi è sicuramente il pair programming. E’ vero che se il soggetto è particolarmente indietro a livello tecnologico inizialmente potrebbe essere molto complesso lavorarci assieme.

Tuttavia, è un metodo molto rapido per far acquisire conoscenza a un nostro collega. Se il team è abbastanza ampio e non siamo solo in 2, ruotarlo sui vari membri senior del team potrebbe farlo crescere rapidamente.

Un altro modo è utilizzare le Pull Request e revisionare il codice fatto. Preferibilmente da tutti i componenti del team, in questo caso almeno dal collega che deve riallinearsi. Fornire poi dei branch di esempio con soluzioni alternative o migliorative è un ottimo modo per trovare tutti lo stesso ritmo e un approccio simile.

Molte volte tuttavia si vuole già un dipendente “perfetto” sulla parte tecnica, sacrificando quella relazionale, più che altro perché non si sa gestire la sua formazione in modo veloce ed efficace. E si ha paura che il nuovo dipendente possa introdurre disfunzionalità dovute all’inesperienza.

Se invece si ha un corretto approccio a livello di formazione, si può spingere molto di più su avere persone forti a livello di interazione con gli altri e poter eventualmente chiudere un occhio su alcune mancanze tecniche sulle ultime mode.

Il leader è fondamentale

Si suol dire che le persone cambiano azienda principalmente per colpa del manager. Posso dire che nel 90% dei casi questo è vero. Se anche ci sono altri problemi all’interno dell’azienda, un manager esperto sa dare consigli su come gestirli e risolverli.

In altre parole, un manager valido sa “far funzionare” l’azienda anche quando ci sono numerosi problemi. Se invece c’è un forte turnover, è un chiaro segnale che il management non sa gestire i propri dipendenti.

Anche nel coaching mi sono accorto che la totalità dei ragazzi che ho “perso” è perché non ero in grado di gestire la loro situazione. Idem quelli che ho allontanato, a posteriori, ho capito di averlo fatto perché non ero capace di gestire la loro problematica. Lo stesso vale a livello relazionale. Si fugge da situazioni che non si riesce a gestire.

Ti piacciono questi argomenti? Seguimi su instagram per non perdere i prossimi articoli 🙂

Per questo motivo:

• il ruolo del manager è a dir poco fondamentale e a livello aziendale è la figura che bisognerebbe valutare più attentamente.
• quando un’azienda fallisce e viene acquisita, spesse volte viene licenziato in blocco il management.

Quando mi è capitato di fare l’IT Manager di una startup mi sono reso conto di quante capacità trasversali siano indispensabili per un buon team leader:

• Forti capacità relazionali sia nel comprendere le paure, i dubbi e le aspirazioni dei propri dipendenti. Sia per poter dare ai livelli superiori feedback realistici resistendo alle pressioni.
• Capacità tecniche poliedriche per riuscire a capire anche ambienti con cui non si ha una grande esperienza. Mi è capitato di confrontarmi persino su problematiche di configurazione di AWS, back-end in PHP+Laravel o in Grails. Quanto di più lontano possibile da un’app Android.
• Forti capacità organizzative. Fare stime e piani di sviluppo sarà il lavoro quotidiano. Oltre a discutere su fattibilità anche di cose che magari si conoscono in modo relativo. Non sempre saper programmare bene implica anche saper organizzare bene il proprio lavoro e fornire stime attendibili.
• Capacità nel motivare i propri sviluppatori. E’ inutile essere bravi se non riesci a mostrare ai tuoi dev la vision del progetto, perché si devono impegnare e soprattutto tracciare gli obiettivi in termini di performance di ognuno. Se un dev non ha chiaro perché si deve fare in quattro e non c’è un percorso di crescita definito, potrebbe perdere la voglia nel cercare di aiutare il team.
• Filtrare e riorganizzare lo stress del management. La parte difficile di un IT Manager è quella sia di attutire i colpi di scadenze, priorità, pressioni e rotture varie. Sia quella di convincere i “piani alti” che siano necessarie cose come refactoring, tempo per imparare nuove tecnologie, budget formazione, ecc. sia concordare tempistiche di sviluppo realistiche e in linea con il team.
• Forti capacità diplomatiche. Sia per i punti precedenti, sia per il contatto con vari consulenti o aziende esterne, è fondamentale saper trattare con le persone e aver un ottimo ecosistema per rimanere sereni e brillanti anche in situazioni di altissimo stress.
• Ecc.

Se guardiamo, sono caratteristiche quasi opposte rispetto a un dev senior. Un dev senior deve avere forti competenze specifiche e non poliedriche. Deve sapere molto bene il suo lavoro, non un po’ di tutto. E deve essere molto bravo a ricevere ordini, eseguirli e dare feedback, più che organizzare il lavoro di altre persone e dare priorità.

Gabriele Lana, nel 2011, fece infatti questo intervento bellissimo proprio per “ridare dignità” al programmatore. Quasi che l’unico modo per fare carriera fosse diventare manager. Quando, nel pratico, sono due carriere totalmente diverse e per certi versi anche agli antipodi.

In sostanza, un team leader non è un “dev senior bravo”. Sono proprio caratteristiche totalmente diverse. Anzi, opposte. E ci sono molti programmatori che NON vogliono fare i manager. E viceversa, manager che proprio non vogliono più vedere una riga di codice. Ed è giusto che sia così.

Per questo dico che sono un programmatore e mi va benissimo esserlo. Potenzialmente avrei le capacità per propormi per ruoli da manager, ma non mi interessa fare il manager. Come non mi interessa fare il personal trainer anche se ho 2 certificazioni per poterlo fare. Idem il fotografo ecc.

Questo tuttavia non vuol dire che uno sviluppatore senior non possa fare il team leader (o IT Manager o qualsiasi figura manageriale “tecnica”) ma che è normale e naturale che un team leader esperto magari sono 8 anni che non vede una riga di codice. Viceversa, andare “al risparmio” prendendo un dev senior per fargli fare un po’ il dev e un po’ il manager, è molto rischioso e potenzialmente controproducente.

Sia perché per forza di cose uno dei due ruoli potrebbe non piacergli granché. Sia perché come team leader sarà molto inesperto. Sarebbe come prendere Buffon e fargli fare sia l’allenatore che il portiere. Si, certo, essendo a fine carriera ha molta esperienza… ma ha zero pratica come allenatore. Probabilmente finirebbe per fare male entrambi i ruoli.

Nella mia esperienza come IT Manager infatti posso dire di essere transizionato da “tuttofare” (quando ero l’unico sviluppatore) a dev senior che riorganizzava le storie. Il ruolo vero e proprio dell’IT Manager di fatto l’ho ricoperto solo parzialmente. Visto che in parte il management e in parte vari Agile Coach hanno contribuito a “colmare” molte mie lacune in merito. Sia di management che meramente tecniche.

Da parte mia posso dire di essermi proposto come dev senior al tempo ma è stata l’azienda a chiedermi se potessi essere interessato a ricoprire il ruolo di IT Manager se supportato adeguatamente. Infatti l’esperienza, per quanto non sia continuata a lungo, è stata molto positiva.

Nel caso di un “dev senior potenziato” è dunque naturale che o ci sono altre figure che lo aiutano nella transizione a manager e quindi gli permettono di entrare nel ruolo gradualmente, o il rischio di scelte molto poco accorte è dietro l’angolo. Ma appunto, è come se si fosse “manager junior” e hai bisogno di figure “manager senior” per apprendere il mestiere e venire guidato nel nuovo ruolo.

Certo, uno può anche imparare da solo sbagliando e sbattendoci la testa. Sicuramente però sarà difficile che tutte le decisioni saranno perfette e immacolate.

Inutile dunque dire che un Team Leader forte attrae dev forti. Proprio perché un leader carismatico e capace ha sia molti contatti magari di sviluppatori in gamba. Sia ha un curriculum che può attirare l’interesse di altri sviluppatori. E inoltre, sarà anche capace di gestirli, renderli felici e mantenerli il più a lungo possibile all’interno dell’azienda capitalizzando l’investimento fatto per assumerli.

La principale difficoltà che ho riscontrato facendo l’IT Manager era infatti la grande difficoltà nell’attrarre profili senior che volessero credere in un progetto guidato da un, allora, 28enne con meno di 10 anni di esperienza lavorativa alle spalle. Se poi la tua startup vuole scalare molto velocemente in termini di sviluppatori assunti, potrebbe diventare una cosa molto difficile da gestire.

Per questo motivo a mio avviso se uno ha budget conviene prendere il leader più forte possibile senza andare necessariamente a guardare se sa ancora programmare o meno. Proprio perché non è quello il suo compito. E’ naturale tuttavia che spesso ci si debba scontrare con budget risicati o magari con l’incertezza di spendere tanti soldi in un profilo che non conosciamo bene.

Ti piacciono questi argomenti? Seguimi su instagram per non perdere i prossimi articoli 🙂

Per questo a volte viene preferito il promuovere profili senior internamente. Decisione che sul breve magari può risultare problematica, ma nel lungo premiare chi ci ha mostrato fedeltà potrebbe diventare motivo di ispirazione per chi entra. Certo però che avremo davanti un “manager junior” e, come tale, andrebbe seguito e supportato.

Si ma e le startupp??? Ammetto che vedo sensato il creare una startup (seriamente) quando si ha già una fortissima esperienza tecnica alle spalle. Diventare CTO appena uscito dall’università non la ritengo una scelta lungimirante. A meno di essere un mezzo genio come Zuckerberg.

Un esempio di questo si vede molto bene in The Playlist, il documentario di Netflix su Spotify. Vediamo infatti come il CTO di Spotify è stato capace di creare una squadra di immenso valore proprio perché lui è un ragazzo dalle capacità straordinarie. E aveva esattamente i nomi di chi assumere, programmatori esperti che si fidavano totalmente di lui. Ed è stata principalmente la sua leadership a traghettare il prodotto al successo.

Automatizza il processo produttivo il più possibile

Sia in termini di meeting, sia in termini di produzione del software, vuoi automatizzare e “ritualizzare” il più possibile i vari passaggi che conducono alla creazione di una build da poter consegnare a clienti e/o tester.

In questo video ho parlato in dettaglio di come organizzare il processo produttivo aziendale, e anche quello personale, in modo che sia efficace e ti permetta di avere sempre sotto mano quali sono i task prioritari da affrontare:

Un’altra cosa sicuramente interessante da approfondire è il metodo di Alberto Brandolini, Eventstorming che è una delle metodologie per fare analisi dei requisiti. Anche avere un’ottima comprensione degli UML e riuscire a modellare gli scenari da mettere in atto poi nel software è un’ottima skill utile per riuscire ad avere molto chiare le specifiche tecniche.

Comunque, al netto di SCRUM, Eventstorming, UML, ecc… la cosa importante è decidere una serie di metodologie efficaci per i vari ambiti e usare sempre quelle. In modo tale da poter dare stabilità e continuità all’azienda. Certo, è possibile introdurre lievi miglioramenti man mano, ma l’asse portante dovrà essere costruito da buone pratiche che ci permettono di avere chiaro il cosa dobbiamo fare e con che priorità.

Inoltre, sarà necessario costruire un sistema di Continuous Delivery e Continuous Integration basato su suite di test automatizzate che ci permettano di rilasciare in modo continuo e automatico quantomeno una volta alla fine di ogni sprint. Quindi circa ogni 1-2 settimane a seconda della dimensione dello sprint.

Mi è capitato di lavorare in aziende che per rilasciare impiegano anche 2 mesi di code freeze per cercare di chiudere tutti i bug e le regressioni che vengono introdotte con un rilascio. Inutile dire che, arrivati nel 2023, è una pratica inaccettabile.

Specialmente per ambienti come quello bancario o sanitario che dovrebbero garantire totale affidabilità da un punto di vista software o, quantomeno, la miglior qualità possibile.

Questo ci permetterà dunque di poter testare rapidamente ogni nuova modifica e, soprattutto, avere un feedback loop molto veloce con i nostri clienti che potranno quindi beneficiare di rilasci frequenti e costanti nuove funzionalità.

Conclusioni

Inutile dire che ci sono tanti altri fattori importanti da tenere in considerazione. I 1:1, le retrospective o la capacità di sincronizzare il lavoro sono solo alcune di altri fattori fondamentali. Magari però ne parleremo in qualche altro articolo dedicato.

Spero di averti dato un po’ di idee su come creare un team software di successo, in particolare un team mobile. Dovessi avere domande o curiosità non esitare a chiedermele nei commenti e per non perderti i prossimi articoli ricordati di seguirmi su instagram 🙂