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. È fantastico quando una persona è in grado di sostituirne tre, e lo fa anche in modo qualitativo, senza ritardi. E, cosa non da poco, questo garantisce un risparmio di risorse!
Sembra molto allettante, ma è davvero così? Cerchiamo di capirlo.
Chi è il nostro anticipatore delle aspettative?
Il termine «universale» di solito si riferisce a membri del team che combinano più di un ruolo, come sviluppatore-analista.
L'interazione del team e i risultati del suo lavoro dipendono dalle qualità professionali e personali dei membri.
Per quanto riguarda le hard skills è tutto chiaro, mentre le soft skills meritano un'attenzione particolare. Aiutano a trovare l'approccio giusto per il collaboratore e a indirizzarlo verso il compito nel quale sarà più utile.
Ci sono molti articoli sui vari tipi di personalità nel settore IT. Basandomi sulla mia esperienza, dividerei gli universali dell'IT in quattro categorie:
1. "Universale – onnipotente"
Queste persone sono ovunque. Mostrano sempre una grande attività, vogliono essere al centro dell'attenzione, e chiedono costantemente ai colleghi se hanno bisogno del loro aiuto; a volte possono anche risultare irritanti. Sono interessati solo a compiti significativi, la cui partecipazione darà spazio alla creatività e soddisferà il loro ego.
Punti di forza:
- in grado di affrontare compiti complessi;
- si immergono a fondo nel problema, "indagano" e ottengono risultati;
- hanno una mente curiosa.
Ma:
- sono emotivamente labili;
- difficili da gestire;
- hanno un'opinione ferma che è molto complicato cambiare;
- è difficile farli svolgere anche compiti semplici. Anche i lavori leggeri colpiscono l'ego degli onnipotenti.
2. "Universale – mi organizzo e faccio"
Per queste persone basta un manuale e un po' di tempo per risolvere la questione. Di solito hanno una solida esperienza come DevOps alle spalle. Questi professionisti versatili non si complicano la vita progettando, ma preferiscono utilizzare un metodo di sviluppo basato esclusivamente sulla loro esperienza personale. Possono facilmente discutere con il team leader riguardo alla soluzione scelta per l'attività.
Punti di forza:
- indipendenti;
- resilienti allo stress;
- competenti in molti aspetti;
- colti – hanno sempre qualcosa da dire.
Ma:
- spesso non rispettano gli impegni;
- tendono a complicare tutto: risolvono la tabellina del 2 con integrazioni per parti;
- la qualità del lavoro è bassa, ci riescono solo al secondo o terzo tentativo;
- spostano continuamente le scadenze, perché in realtà tutto si rivela più complicato del previsto.
3. "Versatile – va bene, faccio io, dato che non c'è nessun altro"
Il dipendente ha una buona comprensione di diversi ambiti e possiede l'esperienza adeguata. Tuttavia, non riesce a diventare un professionista in nessuno di essi, poiché viene spesso utilizzato come una soluzione temporanea per colmare le lacune nelle attività correnti. È flessibile, esecutivo, si considera richiesto, ma in realtà non lo è.
Un dipendente praticamente ideale. Probabilmente ha un'area di specializzazione che gli piace di più, ma a causa della dispersione delle competenze, non si sviluppa. Di conseguenza, rischia di diventare non richiesto e di esaurirsi emotivamente.
Punti di forza:
- responsabili;
- orientati ai risultati;
- tranquilli;
- completamente controllati.
Ma:
- mostrano risultati medi a causa del basso livello di competenze;
- non riescono a risolvere compiti complessi e astratti.
4. "Il tuttofare è un maestro nel suo campo"
Una persona con un solido background da sviluppatore, possiede un pensiero sistemico. È pignolo, esigente con se stesso e con il team. Qualsiasi compito in cui è coinvolto può espandersi all'infinito se non vengono definite delle limiti.
Ben conosce bene l'architettura, sceglie il metodo di realizzazione tecnica analizzando attentamente l'impatto della soluzione scelta sull'architettura attuale. È modesto e non ambizioso.
Punti di forza:
- mostrano un'elevata qualità del lavoro;
- sono in grado di risolvere qualsiasi compito;
- sono molto laboriosi.
Ma:
- sono intolleranti verso le opinioni altrui;
- sono massimalisti. Si sforzano di fare tutto correttamente, il che aumenta i tempi di sviluppo.
Cosa abbiamo nella pratica?
Vediamo come si combinano più frequentemente ruoli e competenze. Prendiamo come punto di partenza un team di sviluppo standard: PO, manager di sviluppo (tech lead), analisti, programmatori, tester. Non considereremo il proprietario del prodotto e il tech lead. Il primo – per la mancanza di competenze tecniche. Il secondo, se ci sono problemi nel team, deve poter fare tutto.
La combinazione/ fusione/ accorpamento più comune di competenze è lo sviluppatore-analista. Molto spesso si trovano anche analista-tester e 'tre in uno'.
Prenderò come esempio il mio team per mostrare i pro e i contro dei colleghi universali. Un terzo del mio team è composto da loro, e li apprezzo molto.
Ho ricevuto una richiesta urgente da PO per l'implementazione di nuove tariffe in un prodotto esistente. Nel mio team ci sono 4 analisti. In quel momento, uno era in ferie, un altro era malato, e gli altri erano impegnati nell'attuazione di compiti strategici. Se li avessi distolti, avremmo inevitabilmente compromesso i tempi di realizzazione. L'unica soluzione rimasta era quella di utilizzare il mio "arma segreta": un universale sviluppatore-analista, che conosceva l'argomento necessario. Chiamiamolo Anatolij.
Il suo tipo di personalità è "universale – mi muovo e faccio". Certo, ha cercato a lungo di spiegare che aveva "un backlog completo delle sue mansioni", ma con la mia decisione risoluta è stato mandato a risolvere l'incarico urgente. E Anatolij ce l'ha fatta! Ha eseguito l'assegnazione e ha completato l'implementazione nei tempi previsti, e i clienti sono rimasti soddisfatti.
A prima vista tutto sembrava riuscito. Ma dopo alcune settimane sono emerse nuove richieste per questa soluzione. Ora a occuparsi di questo compito era un analista 'puro'. Durante la fase di test del nuovo sviluppo, non riuscivamo a capire perché ci fossero errori nella configurazione dei nuovi piani fino a quando, dopo aver districato tutto, non siamo arrivati alla verità. Abbiamo perso un sacco di tempo e abbiamo sforato le scadenze.
Il problema era che molti momenti nascosti e insidie erano rimasti solo nella mente del nostro 'tuttofare' e non erano stati messi per iscritto. Come ha spiegato poi Anatolij, si era affrettato troppo. Ma è più probabile che si sia imbattuto in problemi già durante lo sviluppo e li abbia semplicemente elusi, senza riflettere su di essi.
C'era anche un'altra situazione. Attualmente abbiamo solo un tester, quindi alcune attività devono essere testate anche dagli analisti, tra cui i 'tuttofare'. Per questo motivo, ho assegnato un compito al presunto Fëdor – «tuttofare – va bene, lo faccio io, visto che non c'è nessun altro».
Fëdor è un "tre in uno", ma per questo compito è già stato assegnato uno sviluppatore. Quindi, Fëdor doveva integrare solo le funzioni di analista e tester.
I requisiti sono stati raccolti, la specifica è stata inviata allo sviluppo, è tempo di testare. Fëdor conosce il sistema in fase di sviluppo "come le sue cinque dita" e ha dettagliatamente esaminato i requisiti attuali. Pertanto, non si è affaticato a scrivere scenari di test, ma ha effettuato i test su "come il sistema dovrebbe funzionare" e poi ha trasmesso i risultati agli utenti.
Il test si è concluso, le modifiche sono state inviate alla produzione. Successivamente, è emerso che il sistema non solo sospende l'esecuzione di pagamenti su determinati conti di bilancio, ma blocca anche i pagamenti da conti interni molto rari che non avrebbero dovuto essere coinvolti.
Questo è successo perché Fëdor non ha condotto un controllo su "come il sistema non dovrebbe funzionare", non ha redatto un piano di test né delle checklist. Ha deciso di risparmiare tempo e ha fatto affidamento sul proprio istinto.
Come affrontiamo i problemi?
Situazioni come queste influenzano l'efficienza del lavoro del team, la qualità delle versioni rilasciate e la soddisfazione dei clienti. Pertanto, non possono essere trascurate né lasciate senza un'analisi delle cause.
1. Per ogni compito che ha creato difficoltà, chiedo di compilare un modulo unificato: una scheda degli errori, che permette di identificare il passaggio in cui si è verificato un "calo":
2. Dopo aver identificato i punti critici, si svolge un brainstorming con ogni dipendente coinvolto nel problema per discutere "Cosa cambiare?" (i casi specifici non vengono considerati durante il retro), al termine del quale vengono formulate azioni concrete (ognuno ha necessità diverse) con scadenze.
3. Abbiamo introdotto regole di interazione all'interno del team. Ad esempio, ci siamo accordati di registrare tutte le informazioni sul progresso dei compiti nel sistema di gestione dei progetti. In caso di modifiche o identificazione di artefatti durante il processo di sviluppo, è necessario rifletterlo nella base di conoscenza e nella versione finale del documento di requisiti.
4. Il controllo è ora effettuato in ogni fase (prestando particolare attenzione alle fasi problematiche del passato) e automaticamente sulla base dei risultati ottenuti dalla fase successiva.
5. Se il risultato per il compito successivo non è cambiato, non assegno il candidato universale al ruolo per cui non si dimostra adeguato. Cerco di valutare la sua capacità e volontà di sviluppare competenze in quel ruolo. Se non trovo riscontro, lo lascio nel ruolo che gli è più congeniale.
Cosa è stato il risultato finale?
Il processo di sviluppo è diventato più trasparente. Il fattore BUS si è ridotto. I membri del team, lavorando sugli errori, diventano più motivati e migliorano la loro reputazione. Stiamo gradualmente aumentando la qualità delle nostre pubblicazioni.
Conclusioni
I dipendenti universali hanno i loro vantaggi e svantaggi.
Vantaggi:
- è possibile chiudere un compito in sospeso in qualsiasi momento o risolvere un bug urgente in tempi brevi;
- un approccio complesso nella risoluzione del compito: l'esecutore lo guarda da tutte le prospettive;
- gli universali possono praticamente fare tutto bene allo stesso modo.
Svantaggi:
- il fattore BUS cresce;
- le competenze principali del ruolo si sfocano. Questo diminuisce la qualità del lavoro;
- aumenta la probabilità di slittamenti nei tempi, poiché manca il controllo su ogni fase. Inoltre, ci sono rischi di far emergere una «stella»: il dipendente è convinto di sapere meglio, considerando di essere un professionista;
- aumenta il rischio di burnout professionale;
- molte informazioni importanti sul progetto possono rimanere solo "nella mente" del dipendente.
Come vedete, ci sono più svantaggi. Pertanto, utilizzo i generalisti solo quando le risorse scarseggiano e il compito è abbastanza urgente. Oppure quando la persona possiede competenze che mancano agli altri e la qualità è in gioco.
Se durante il lavoro collaborativo si rispetta la regola della distribuzione dei ruoli, la qualità del lavoro aumenta. Guardiamo ai problemi da diverse angolazioni, la nostra visione non si appiattisce, emergono sempre idee fresche. Ogni membro del team ha la possibilità di crescita professionale e di ampliare le proprie competenze.
Ritengo che la cosa più importante sia sentire la propria appartenenza al processo, occuparsi del proprio lavoro, ampliando gradualmente le proprie competenze. Tuttavia, i generalisti nel team portano beneficio: l'importante è far sì che possano efficacemente combinare diversi ruoli.
Auguro a tutti team auto-organizzati di "generalisti-maestri del proprio mestiere"!
Fonte: habr.com
