L'importanza del team in un progetto di sviluppo software

Noi esseri umani siamo per natura creature sociali. La nostra vita, privata e professionale, è influenzata dalle azioni che compiamo ogni giorno e da quelle che compiono le persone più o meno vicine a noi. Sapersi relazionare con gli altri è una qualità da non sottovalutare e da coltivare ogni giorno che diventa indispensabile nel mondo del lavoro, che rappresenta certamente una parte fondamentale delle nostre vite. Di conseguenza saper lavorare in squadra diventa un requisito essenziale se si vuole crescere a livello professionale e questo vale tanto per i lavori di routine quanto per i progetti più ambiziosi e visionari. Se ci riflettiamo per un momento infatti, ci accorgiamo di come la maggior parte dei grandi progetti e addirittura delle grandi opere compiute nella storia siano frutto di lavori fatti in team, gruppi straordinari di persone che insieme sono riuscite a raggiungere obiettivi comunemente ritenuti impossibili. È vero, molti artisti, ricercatori o scienziati lavorano da soli, ma in linea generale i grandi progetti sono portati a termine da team di lavoro in cui ogni membro ricopre un ruolo essenziale. Lavorare in team significa agire insieme ad altre persone per uno scopo condiviso e per il perseguimento di obiettivi comuni e, se la squadra lavora bene, ogni individuo raggiunge livelli di efficienza e di efficacia che non avrebbe mai potuto toccare se lasciato agire singolarmente. La capacità di collaborare e di lavorare insieme tipica dei team eccezionali è la carta vincente per arrivare al successo.

Riconoscere le competenze della singola persona, valorizzarle e metterle a disposizione del team è il primo passo da compiere per costruire una squadra vincente o, come si dice spesso, una squadra di talento. Il secondo passo è quello di responsabilizzare le persone, in modo che ognuno debba rispondere dei propri successi o insuccessi: non necessariamente al fine di ottenere un premio o una punizione, ma semplicemente per far percepire ad ognuno il proprio peso e il proprio valore all'interno della squadra.

La condivisione del metodo di lavoro con il team di sviluppo

Se pensiamo ad un team tradizionale, così come siamo abituati a immaginarcelo all'interno di una grande azienda o di una corporate ben strutturata, immaginiamo un gruppo di persone costruito sulla base di una chiara gerarchia, con un leader al vertice e a scendere una scala di risorse costruita su una serie di relazioni gerarchiche. Una struttura così concepita, se portata all'interno di ambiti particolari come quello dello sviluppo software, presenta diversi errori di fondo. Primo tra tutti, allontana il capo del progetto dalla squadra che effettivamente compie il lavoro e il rischio diventa quello di prendere le decisioni senza riuscire a vedere in maniera chiara quali sono i problemi concreti che la squadra deve affrontare tutti i giorni e di procedere quindi con uno sguardo miope, perseguendo obiettivi a medio-lungo termine senza vedere gli ostacoli più vicini. In questo modo, molto probabilmente si arriverà ad uno scollamento tra i vari livelli della gerarchia, ovvero tra i vertici e la squadra che opera il lavoro concreto. Lo stesso team di lavoro inoltre potrebbe sentirsi meno a suo agio, poiché le difficoltà in questo modo aumentano nel tempo facendo perdere di vista l'obiettivo finale.

Esistono però altri approcci, cari alle metodologie Agile e ad alcuni settori in particolare, in cui l'appiattimento della gerarchia, la valorizzazione dell'individuo e il coinvolgimento emotivo in ciò che si sta facendo, sono elementi fondamentali per creare rapporti di lavoro duraturi ed efficaci. A livello individuale questo aiuta a motivare le persone verso il raggiungimento di un obiettivo comune, rafforza e incoraggia ogni singolo membro del gruppo a dare il meglio e in maniera indiretta porterà benefici sulle prestazioni e sulla produttività dell'intera squadra. L'approccio di base è fare in modo che tutti i membri del team siano consapevoli di qual è il punto di arrivo e che vedano nel loro lavoro un contributo fondamentale per la costruzione del percorso che porterà al risultato finale. Tutti gli elementi della squadra devono avere chiaro in testa dove si vuole arrivare, qualunque sia il livello che ricoprono all'interno della gerarchia. La condivisione degli obiettivi e del metodo di lavoro è una scelta vincente che porta alla grandezza e in ambito di sviluppo software è fondamentale che questi valori siano percepiti da tutti i membri del team al fine di sviluppare prodotti eccellenti e portare a termine progetti impeccabili. Nei modelli di lavoro che si ispirano al metodo Agile si tende ad appiattire la struttura avvicinando chi ricopre il ruolo di gestione e controllo a chi esegue il lavoro, con l'obiettivo di permettere a entrambe le figure di capire il punto di vista dell'altro e di portare avanti gli obiettivi a medio-lungo termine del cliente senza trascurare gli ostacoli e le difficoltà che si presentano di volta in volta su percorso. Questa tipologia di approccio elimina la pianificazione iniziale troppo accurata dell’intero progetto e ci permette di apportare interventi e migliorie costanti attraverso feedback e revisioni continue.

Le figure coinvolte all'interno di un team di sviluppo software

Secondo i metodi adottati da chi si ispira ai modelli Agile (Come nel caso di BitBoss), all'interno del team si tende a eliminare la figura del capo o leader nel senso stretto del termine e non ci sono rigidi schemi pre impostati di lavoro, ma è il team stesso che, per superare gli ostacoli quotidiani, prende le decisioni in modo autonomo e organizzato in base a quelli che sono gli input dell’ambiente esterno. In questo modo ogni risorsa è responsabilizzata sulla propria area di competenza ed è tenuta a condividere con gli altri i risultati ottenuti, i successi e i fallimenti. Questo perché l'eccellenza non si può imporre attraverso degli obblighi, ma deve venire da dentro, deve essere sperimentata e, se stimolata nel modo giusto, porterà benefici all'intera squadra. Certo, è necessaria una figura che faccia da responsabile del corretto flusso del progetto, che assegni i task alla squadra e che si assicuri che questi vengono svolti correttamente ed infine che dimostri al cliente che le richieste sono state soddisfatte. In questo scenario è fondamentale che tutti lavorino secondo un piano organizzato e stabilito, in altre parole che seguano un metodo di lavoro.

La letteratura in ambito business è traboccante di esempi di metodologie e figure indispensabili quando tratta questo argomento. Si parla di ruoli fondamentali e ben definiti, ricoperti da figure diverse e necessarie per arrivare al successo di un progetto. Nella pratica però questi ruoli non sono così netti e definiti, ogni membro del team può ricoprire diversi ruoli e spostarsi anche da uno all'altro in base al momento specifico in cui ci si trova nel ciclo di vita del progetto o anche in base alla dimensione del progetto stesso. Così succede spesso che la stessa figura possa ricoprire il ruolo di architetto del software per un certo periodo, ad esempio quando si deve definire la struttura di un software, per poi arrivare a ricoprire il ruolo di project manager o di sviluppatore durante il restante arco di tempo. Esistono moltissime classificazioni diverse di questi ruoli e altrettanti modi in cui questi si relazionano con gli altri membri del team di lavoro. In questo articolo però vogliamo dare un'idea dei ruoli più comuni all'interno di un team che adotta la metodologia Agile Scrum o che si ispira ad essa, ben sapendo che la realtà non è così netta e che ogni progetto è unico e simile solamente a sé stesso, per cui i ruoli e le relazioni potrebbero variare a seconda della natura e della complessità del progetto.

Product owner

Il Product Owner è la figura che cura le relazioni, comprende le esigenze e i desideri del cliente e li traduce in obiettivi per il team interno. Si occupa di gestire gli Sprint e i Task da completare in ogni ciclo di sviluppo, gestisce i flussi del progetto e fornisce feedback al cliente: lo scopo principale è produrre valore per l'utilizzatore finale e l’azienda cliente. Si può dire che il Product Owner sia la bussola che indica al team la strada da percorrere, il rappresentante esterno e il collante interno, punto di incontro tra cliente e azienda. Si tratta di un ruolo poliedrico e molto vario che necessita di tre skill fondamentali:

Empatia: ha quotidianamente a che fare con persone che hanno un proprio punto di vista, idee molto spesso diverse e deve mettersi nei panni del cliente per interpretare i suoi problemi e capire come risolverli al meglio.

Leadership: Deve gestire da una parte il cliente con tutte le sue richieste e dall'altra un team di persone diverse, che vede nel product owner la figura di riferimento per fissare gli obiettivi degli sprint e dell'intero progetto.

Visione d'insieme: deve vedere e capire le connessioni che esistono tra ogni singolo obiettivo al fine di raggiungere il risultato finale.

Di fatto il product owner è letteralmente colui che possiede la proprietà del prodotto e in molti casi questo ruolo può essere incarnato dallo stesso cliente che dialoga direttamente con il team di sviluppo o con il PM tecnico, se ne ha le competenze adatte. In altri casi questo ruolo viene "diviso" tra il cliente e il referente della software house che ha il compito di interfacciarsi con lui e gestire il team interno. Anche in questo caso, questa figura può variare a seconda di dove ci si trova nel ciclo di vita del progetto.

Project manager

Il Project Manager, che può essere tecnico (avere cioè competenze tecniche in ambito sviluppo) o non tecnico, è il responsabile di progetto e ha il compito di monitorare tempi, costi e qualità del lavoro. Rappresenta il team di sviluppo e deve confrontarsi e dialogare con il product owner riguardo le difficoltà tecniche e la fattibilità pratica delle richieste avanzate dal cliente. Il PM svolge un ruolo fondamentale nella leadership di un team di progetto e rappresenta una figura chiave per tutta la durata del lavoro. Spesso gestisce il budget di sviluppo, si occupa di individuare i rischi di fattibilità ed è responsabile della risoluzione dei problemi e/o impedimenti che possono rallentare o fermare il progetto. Come già visto in precedenza, non è raro che il ruolo di PM e quello di product owner coincidano e convergano nella stessa persona. In questo caso chi svolge questo lavoro deve collaborare direttamente con il cliente per decidere la direzione che dovrà prendere il progetto e le future implementazioni da inserire.

Le tre skill fondamentali di un project manager sono:

Problem solving: deve essere in grado in ogni momento di aiutare un membro del team a risolvere i problemi tecnici che impediscono il completamento di un task

Time management: deve riuscire a stimare il tempo che ci metterà uno sviluppatore a risolvere un task e calcolarne il tempo effettivo per misurarne l'efficienza

Gestione del team: deve stabilire ordine, precisione e puntualità nel lavoro di ogni membro del team.

Software architect

Il software architect è la figura del team specializzata nella progettazione delle funzioni e delle specifiche tecniche del software che deve essere realizzato. Realizza il disegno logico delle singole componenti del software e progetta la migliore struttura per quanto riguarda le macchine, i server e il tipo di architettura su cui il software dovrà poggiare. L'Architet deve possedere un'importante competenza tecnica e deve tenersi in costante aggiornamento per trovare le soluzioni sempre migliori per permettere al software di poggiare su solide basi in una visione a lungo termine, anche una volta che sarà nelle mani del cliente: flessibilità, scalabilità, potenza della struttura.

Le skill fondamentali per un buon software architect sono:

Abilità coordinative e gestionali: deve assicurarsi che le sue direttive vengano rispettate durante tutto il processo di sviluppo

Pensiero analitico e creativo: Deve prevedere le future evoluzioni del prodotto e trovare soluzioni che siano adattabili e gestibili nel tempo

Orientamento alla formazione costante: l'architect non può mai sedersi sulle proprie conoscenze ma deve essere sempre aggiornato sulle migliori tecnologie da utilizzare

Per molti aspetti la figura del software architect è simile a quella del PM tecnico e spesso le due figure coincidono e non è raro che la stessa risorsa che nelle fasi iniziali del progetto ricopre il ruolo di software architect, ad un certo punto diventi PM o anche developer.

Team di sviluppatori

Il team dei developer è il vero cuore operativo del progetto. È l'area che si occupa dello sviluppo vero e proprio, quella che va ad implementare effettivamente il software. I developer che fanno parte del team di sviluppo devono avere la libertà di gestire i propri obiettivi giornalieri nel modo che ritengono opportuno, ma sono tenuti a condividere i loro risultati quasi in tempo reale con il resto del team, in modo che tutti siano allineati sull'avanzamento dei lavori. Sono quindi tenuti a partecipare ai meeting di allineamento e di condivisione dei risultati. Il loro lavoro richiede conoscenze approfondite ed è in continua evoluzione poiché emergono ogni giorno nuove tecnologie che devono essere esplorate e capite in funzione delle esigenze del cliente. Può capitare che all'interno di un progetto lungo, i developer del team di sviluppo cambino in base alle fasi in cui si trova il progetto. Alcuni sviluppatori possono subentrare ad altri per via delle competenze specifiche che servono all'interno di una fase piuttosto che un'altra. É compito del PM fare in modo che il flusso continui regolarmente anche in caso di ricambio di developer all'interno del team. Del team di sviluppo fanno parte diversi tipi di sviluppatori:

• Front-end: si occupa della parte "Front" di un'applicazione, ovvero quella visibile agi utenti. Implementa il design e codifica l'aspetto grafico con cui l'utente interagisce effettivamente sulla piattaforma.

• Back-end: si occupa del funzionamento lato server e di tutto ciò che sta dietro le quinte. Implementa le funzionalità che permettono al software di funzionare, ma che non sono visibili all'utente.

• Full Stack: è uno sviluppatore che ha competenze sia sulla parte di front-end che di back-end.

UI/UX team

Quest’area si occupa della parte visual del software, ovvero dell'interfaccia grafica che gli utenti finali vedranno e attraverso la quale interagiranno con il software. Gli utenti ricercano e amano l'esperienza di navigazione semplice e intuitiva, sia che si tratti di software destinati a utenti terzi che gestionali interni all'azienda.  Per tale motivo quest'area ha il compito di definire in che modo l'utente dovrà comunicare con il software, sia per quanto riguarda l'impatto grafico che l'usabilità. Questo implica un lavoro curato e attento di User Experience e User Interface che permettono il successo di un progetto.

• UI designer: studia e gestisce l’interazione tra uomo e dispositivo e ha lo scopo di rendere più invitante la navigazione, seguendo lo stile e la comunicazione del brand. Si occupa delle scelte a livello di linguaggio e stile (font, i colori, i bottoni e CTA) e lavora a stretto contatto con l'UX Designer

• UX designer:  ha il compito di studiare, comprendere e attuare funzioni ed elementi in grado di migliorare la facilità di navigazione di un sito o un'applicazione. Fondamentale in quei progetti dove la semplicità di utilizzo aumenta la possibilità di acquisto o di interazione con la piattaforma.

Il ruolo del cliente

Non bisogna mai dimenticare che, nell'ambito di un progetti che prevede tra le altre una forte attività di consulenza software, l'attore più importante in un progetto di sviluppo software è il cliente perché è lui il motore che da il via all'intero processo. Quello che nasce tra cliente e software house è più di un rapporto cliente-fornitore, si tratta di una partnership con cui iniziare un cammino di crescita che può durare anche anni. Dal cliente arrivano gli input che danno il via a tutto il ciclo di sviluppo, ma anche i feedback sul lavoro svolto fino a quel momento che sono fondamentali per decidere come si dovrà evolvere il progetto e cosa si potrà sviluppare nell'arco di tempo successivo. Questo discorso vale sia per software destinati a utenti terzi (e-commerce, web app destinate a clienti finali) che per software destinati all'uso interno da parte dell'azienda cliente (come i software gestionali).