«Universale» nel team di sviluppo: vantaggio o svantaggio?

Ciao a tutti! Mi chiamo Lyudmila Makarova, sono manager dello sviluppo in UBRiR e un terzo del mio team è composto da "universali".

Ammettiamolo: ogni Tech Lead sogna la cross-funzionalità all'interno del proprio team. È così fantastico quando una persona è in grado di sostituire tre, e farlo bene senza ritardare le scadenze. E, cosa non da poco, questo garantisce un risparmio di risorse!
Sembra molto allettante, ma è davvero così? Vediamo di capirlo.

Chi è il nostro precursore delle aspettative?

Con il termine "universale" si intendono generalmente membri del team che combinano più di un ruolo, ad esempio sviluppatore-analista.

L'interazione del team e il risultato del suo lavoro dipendono dalle qualità professionali e personali dei partecipanti.

Sui hard skills è tutto chiaro, ma i soft skills meritano un'attenzione particolare. Aiutano a trovare l'approccio giusto al collaboratore e ad indirizzarlo verso quel compito in cui sarà più utile.

Esistono molti articoli su vari tipi di personalità degli operatori del settore IT. Basandomi sulla mia esperienza, dividerei gli universali IT in quattro categorie:

1. "Universale – onnipotente"

Ce ne sono ovunque. Mostrano sempre grande attivismo, vogliono essere al centro dell'attenzione, chiedono continuamente ai colleghi se hanno bisogno del loro aiuto, a volte possono persino risultare fastidiosi. Sono interessati solo a compiti significativi, la cui partecipazione offre spazio alla creatività e può soddisfare il loro amor proprio.

Punti di forza:

• capaci di risolvere compiti complessi;
• si immergono profondamente nel problema, "scavano" e ottengono risultati;
• hanno una mente curiosa.

Ma:

• emotivamente labili;
• difficilmente gestibili;
• hanno un punto di vista molto fermo, difficile da cambiare;
• è difficile convincerli a svolgere un compito semplice. I compiti leggeri colpiscono l'orgoglio degli onnipotenti.

2. "Universale – mi informerò e lo farò"

Per queste persone un manuale e un po' di tempo sono sufficienti per risolvere il problema. Di solito hanno un ampio background come DevOps. Questi universali non si affaticano nella progettazione e preferiscono usare un metodo di sviluppo basato esclusivamente sulla propria esperienza. Possono facilmente avere delle discussioni accese con il tech lead riguardo alla scelta del metodo di implementazione del compito.

Punti di forza:

• indipendenti;
• resistenti allo stress;
• competenti in molte questioni;
• sono eruditi: c'è sempre qualcosa di cui parlare con loro.

Ma:

• spesso violano gli impegni;
• tendono a complicare tutto: risolvono la tabellina moltiplicando per parti;
• la qualità del lavoro è bassa, tutto richiede 2-3 tentativi;
• spostano costantemente le scadenze, perché in realtà tutto si rivela più difficile del previsto.

3. «Universale – va bene, faccio io, visto che non c'è nessun altro»

Il dipendente ha una buona conoscenza in diverse aree e ha esperienze pertinenti. Ma non riesce a diventare un professionista in nessuna di esse, perché viene spesso usato come una ruota di scorta, per tappare i buchi nei compiti attuali. È malleabile, esecutivo, si considera richiesto, ma in realtà non lo è.

Dipendente praticamente ideale. È probabile che abbia un settore che preferisce di più, ma a causa dell'annebbiamento delle competenze, lo sviluppo non avviene. Di conseguenza, la persona rischia di diventare non richiesta e di esaurirsi emotivamente.

Punti di forza:

• sono responsabili;
• sono orientati ai risultati;
• sono tranquilli;
• sono completamente controllabili.

Ma:

• mostrano risultati medi a causa di un basso livello di competenze;
• non possono risolvere compiti complessi e astratti.

4. «Universale – maestro del suo mestiere»

Una persona con un solido background da sviluppatore, possiede un pensiero sistemico. È pedante, esigente con se stesso e con il team. Qualsiasi compito che lo coinvolge può espandersi all'infinito, se non si delimitano i confini.

Conosce bene l'architettura, sceglie il metodo di implementazione tecnica, analizzando attentamente l'impatto della soluzione scelta sull'architettura attuale. È modesto, non ambizioso.

Punti di forza:

• mostrano un'alta qualità del lavoro;
• sono in grado di risolvere qualsiasi compito;
• sono molto laboriosi.

Ma:

• sono intolleranti verso le opinioni altrui;
• sono massimalisti. Cercano di fare tutto nel modo giusto, e questo allunga i tempi di sviluppo.

Cosa abbiamo nella pratica?

Vediamo come ruoli e competenze si uniscono più spesso. Prendiamo come punto di partenza un team di sviluppo standard: PO, manager di sviluppo (team lead), analisti, programmatori, tester. Non considereremo il proprietario del prodotto e il team lead. Il primo per mancanza di competenze tecniche. Il secondo, se ci sono problemi nel team, dovrebbe essere in grado di fare tutto.

La variante più comune di combinazione/fusione/sovrapposizione delle competenze è lo sviluppatore-analista. Molto frequentemente si incontrano anche l'analista-tester e il «tre in uno».

Condividerò i punti di forza e di debolezza dei colleghi polivalenti prendendo come esempio il mio team. Un terzo del mio team è composto da loro e li apprezzo molto.

Un compito urgente è stato assegnato dal PO per l'implementazione di nuove tariffe nel prodotto esistente. Nel mio team ci sono 4 analisti. In quel momento, uno era in ferie, un altro era malato e gli altri stavano affrontando compiti strategici. Se li avessi distolti, sarebbe stato inevitabile compromettere i tempi di realizzazione. L'unica possibilità rimasta era usare l'«arma segreta» – uno sviluppatore-analista polivalente, che conosceva l'area tematica necessaria. Chiamiamolo Anatolij.

Il suo tipo di personalità è «polivalente – me ne occupo e lo faccio». Certo, ha cercato a lungo di spiegare che aveva «un backlog completo delle sue attività», ma con una mia decisione risoluta è stato inviato a risolvere il compito urgente. E Anatolij ha fatto un ottimo lavoro! Ha condotto l'assegnazione e ha completato la realizzazione nei tempi previsti, e i clienti sono rimasti soddisfatti.

A prima vista, tutto è andato bene. Ma dopo alcune settimane, sono riemerse le richieste di rielaborazione per questo prodotto. Ora l'assegnazione per questo compito era gestita da un «analista puro». Durante la fase di test del nuovo sviluppo, non riuscivamo a capire perché si verificassero errori nell'associazione delle nuove tariffe e solo in seguito, districando l'intera matassa, siamo giunti alla verità. Abbiamo speso una quantità enorme di tempo e abbiamo compromesso i tempi.

Il problema era che molti aspetti nascosti e insidie erano rimasti solo nella mente del nostro polivalente e non erano stati trasferiti su carta. Come ha spiegato Anatolij in seguito, si era dato una mossa. Ma è molto probabile che si fosse imbattuto in problemi già durante lo sviluppo e semplicemente li avesse elusi, senza riflettere su di essi.

C'era un'altra situazione. Ora abbiamo solo un testatore, quindi alcuni compiti devono essere testati dagli analisti, compresi i polivalenti. Perciò ho assegnato un compito al condizionale Fëdor – «polivalente – va bene, lascio fare a me, visto che non c'è nessun altro».
Fëdor è un «tre in uno», ma per questo compito era già stato designato uno sviluppatore. Significa che Fëdor doveva unire in sé solo le funzioni di analista e tester.

I requisiti sono stati raccolti, la specifica è stata inviata allo sviluppo, è tempo di testare. Fedor conosce il sistema in fase di revisione «come le sue cinque dita» e ha esaminato dettagliatamente i requisiti attuali. Pertanto, non si è gravato della scrittura di scenari di test, ma ha condotto i test su «come il sistema dovrebbe funzionare», poi ha passato ai clienti.
Il test è terminato, le modifiche sono andate in produzione. Successivamente, si è scoperto che il sistema non solo sospende i pagamenti su determinati conti di bilancio, ma blocca anche i pagamenti da conti interni molto rari che non avrebbero dovuto partecipare a questo processo.

Questo è accaduto perché Fedor non ha effettuato controlli su «come il sistema non dovrebbe funzionare», non ha redatto un piano di test, checklist. Ha deciso di risparmiare tempo e ha fatto affidamento sul proprio intuito.

Come affrontiamo i problemi?

Situazioni come questa influenzano l'efficacia del lavoro del team, la qualità delle versioni rilasciate e la soddisfazione dei clienti. Pertanto, non possono essere trascurate senza un'analisi delle cause.

1. Per ogni compito che ha causato difficoltà, chiedo di compilare un modulo unificato: una mappa degli errori che permette di identificare la fase in cui si è verificato il «collasso»:

2. Dopo aver identificato i colli di bottiglia, viene condotto un brainstorming con ogni dipendente che ha influito sul problema su «Cosa cambiare?» (i casi particolari non vengono esaminati nel retro), da cui emergono azioni concrete (per ogni tipo di personalità le proprie) con scadenze.

3. Abbiamo introdotto delle regole di interazione all'interno del team. Ad esempio, ci siamo accordati di registrare necessariamente tutte le informazioni sul progresso del compito nel sistema di gestione dei progetti. In caso di modifiche/identificazione di artefatti durante lo sviluppo, è necessario rifletterlo nella base di conoscenza e nella versione finale del documento di specifica.

4. Il controllo è stato attuato in ogni fase (un'attenzione particolare è riservata alle fasi problematiche del passato) e automaticamente in base ai risultati dell'esecuzione del compito successivo.

5. Se il risultato del compito successivo non è cambiato, non nomino il candidato universale nella posizione in cui ha avuto difficoltà. Cerco di valutare la sua capacità e desiderio di sviluppare competenze in quel ruolo. Se non vedo riscontri, lo lascio nel ruolo a lui più vicino.

Cosa è emerso alla fine?

Il processo di sviluppo è diventato più trasparente. Il fattore BUS è diminuito. I membri del team, lavorando sugli errori, diventano più motivati e migliorano il loro karma. Aumentiamo gradualmente la qualità delle nostre release.

Conclusioni

I dipendenti che ricoprono vari ruoli hanno i loro pro e contro.

Vantaggi:

• si può chiudere in qualsiasi momento un compito in sospeso o risolvere un bug urgente in breve tempo;
• un approccio complessivo nella risoluzione dei problemi: chi esegue guarda il compito da tutte le prospettive;
• i polivalenti possono praticamente fare quasi tutto bene.

Svantaggi:

• cresce il fattore BUS;
• le competenze principali tipiche di un ruolo si sfumano. Di conseguenza, la qualità del lavoro diminuisce;
• aumenta la probabilità di slittamenti nelle scadenze, poiché manca un controllo in ogni fase. Inoltre, si corrono rischi di creare una "star": il dipendente è convinto di sapere meglio, di essere un professionista;
• aumenta il rischio di burnout professionale;
• molte informazioni importanti sul progetto possono rimanere solo "nella testa" del dipendente.

Come vedete, ci sono più svantaggi. Pertanto, utilizzo i polivalenti solo quando le risorse scarseggiano e il compito è abbastanza urgente. Oppure quando una persona possiede competenze che mancano ad altri, e la qualità è in gioco.

Se si rispetta la regola della distribuzione dei ruoli nel lavoro collaborativo su un compito, la qualità del lavoro aumenta. Guardiamo ai problemi da angolazioni diverse, la visione non si fa appannata, emergono sempre idee fresche. In questo modo, ogni membro del team ha tutte le possibilità per la crescita professionale e l'espansione delle proprie competenze.

Ritengo che la cosa più importante sia sentire di far parte del processo, svolgere il proprio lavoro, aumentando gradualmente l'ampiezza delle proprie competenze. Tuttavia, i polivalenti nel team portano valore: l'importante è far sì che possano combinare efficacemente diversi ruoli.

Auguro a tutti una squadra auto-organizzata di "polivalenti–maestri del proprio mestiere"!

Fonte: habr.com