“Universale” nel team di sviluppo: vantaggio o danno?

Ciao a tutti! Mi chiamo Lyudmila Makarova, sono una responsabile dello sviluppo presso UBRD e un terzo del mio team è composto da "generalisti".

Ammettilo: ogni responsabile tecnico sogna la funzionalità incrociata all'interno del proprio team. È fantastico quando una persona è in grado di sostituirne tre e lo fa anche in modo efficiente, senza ritardare le scadenze. E, soprattutto, fa risparmiare risorse!
Sembra molto allettante, ma è davvero così? Proviamo a capirlo.

Chi è lui, il nostro precursore delle aspettative?

Il termine “generalista” si riferisce solitamente ai 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.

Tutto è chiaro sulle hard skills, ma le soft skills meritano un’attenzione particolare. Aiutano a trovare un approccio con un dipendente e lo indirizzano al compito in cui sarà più utile.

Esistono molti articoli su tutti i tipi di personalità nel settore IT. In base alla mia esperienza, dividerei i generalisti IT in quattro categorie:

1. “Universale – onnipotente”

Questi sono ovunque. Sono sempre molto attivi, vogliono essere al centro dell'attenzione, chiedono costantemente ai colleghi se hanno bisogno del loro aiuto e talvolta possono anche essere fastidiosi. Sono interessati solo a compiti significativi, la cui partecipazione darà spazio alla creatività e potrà divertire il loro orgoglio.

In cosa sono forti:

• sono in grado di risolvere problemi complessi;
• immergersi profondamente nel problema, “scavare” e ottenere risultati;
• avere una mente curiosa.

ma:

• emotivamente labile;
• mal gestito;
• hanno il loro punto di vista incrollabile, che è molto difficile da cambiare;
• È difficile convincere qualcuno a fare una cosa semplice. I compiti facili feriscono l’ego dell’Onnipotente.

2. “Universale: lo scoprirò e lo farò”

Queste persone hanno solo bisogno di un manuale e di un po' di tempo e risolveranno il problema. Di solito hanno una solida esperienza in DevOps. Questi generalisti non si preoccupano del design e preferiscono utilizzare un metodo di sviluppo basato esclusivamente sulla loro esperienza. Possono facilmente discutere con il responsabile tecnico sull'opzione scelta per l'implementazione dell'attività.

In cosa sono forti:

• indipendente;
• resistente allo stress;
• competente in molte questioni;
• erudito: c'è sempre qualcosa di cui parlare con loro.

ma:

• spesso violano gli obblighi;
• tendono a complicare tutto: risolvi la tavola pitagorica integrando per parti;
• la qualità del lavoro è bassa, tutto funziona 2-3 volte;
• Spostano costantemente le scadenze, perché in realtà tutto risulta non essere così semplice.

3. “Universale – okay, lasciamelo fare, visto che non c’è nessun altro”

Il dipendente è esperto in diversi settori e ha esperienza rilevante. Ma non riesce a diventare un professionista in nessuno di essi, perché viene spesso utilizzato come ancora di salvezza, tappando i buchi nei compiti attuali. Flessibile, efficiente, si considera richiesto, ma non lo è.

Un impiegato ideale pratico. Molto probabilmente, ha una direzione che gli piace di più, ma a causa della confusione delle competenze, lo sviluppo non avviene. Di conseguenza, una persona rischia di diventare non reclamata ed emotivamente esaurita.

In cosa sono forti:

• responsabile;
• orientata al risultato;
• calma;
• completamente controllato.

ma:

• mostrare risultati medi a causa di un basso livello di competenze;
• non è in grado di risolvere problemi complessi e astratti.

4. “Un tuttofare è un maestro del suo mestiere”

Una persona con un background serio come sviluppatore ha un pensiero sistemico. Pedante, esigente con se stesso e con la sua squadra. Qualsiasi compito che lo coinvolga può crescere indefinitamente se i confini non vengono definiti.

Conosce bene l'architettura, seleziona un metodo di implementazione tecnica, analizzando attentamente l'impatto della soluzione scelta sull'architettura attuale. Modesto, non ambizioso.

In cosa sono forti:

• mostrare un'alta qualità del lavoro;
• capace di risolvere qualsiasi problema;
• molto efficiente.

ma:

• intollerante alle opinioni degli altri;
• massimalisti. Cercano di fare tutto bene e questo aumenta i tempi di sviluppo.

Cosa abbiamo in pratica?

Vediamo come i ruoli e le competenze vengono più spesso combinati. Prendiamo come punto di partenza un team di sviluppo standard: PO, responsabile dello sviluppo (responsabile tecnico), analisti, programmatori, tester. Non prenderemo in considerazione il proprietario del prodotto e il responsabile tecnico. Il primo è dovuto alla mancanza di competenze tecniche. Il secondo, se ci sono problemi in squadra, dovrebbe poter fare tutto.

L'opzione più comune per combinare/unire/combinare le competenze è sviluppatore-analista. Anche l’analista di test e il “tre in uno” sono molto comuni.

Usando la mia squadra come esempio, ti mostrerò i pro e i contro dei miei colleghi generalisti. Ce ne sono un terzo nella mia squadra e li amo moltissimo.

PO ha ricevuto l'incarico urgente di introdurre nuove tariffe su un prodotto esistente. Il mio team ha 4 analisti. A quel tempo uno era in vacanza, l'altro era malato e gli altri erano impegnati nell'attuazione di compiti strategici. Se li ritirassi, ciò comprometterebbe inevitabilmente le scadenze di attuazione. C'era solo una via d'uscita: usare l '"arma segreta": un versatile analista-sviluppatore che padroneggiava l'area tematica richiesta. Chiamiamolo Anatoly.

Il suo tipo di personalità è “universale – lo scoprirò e lo farò”. Naturalmente, ha cercato a lungo di spiegare che "ha un intero arretrato di compiti", ma con la mia decisione volitiva è stato inviato a risolvere un problema urgente. E Anatoly lo ha fatto! Ha eseguito l'allestimento e completato l'implementazione in tempo, e i clienti sono rimasti soddisfatti.

A prima vista, tutto ha funzionato. Ma dopo alcune settimane sono emerse nuovamente esigenze di miglioramento per questo prodotto. Ora la formulazione di questo problema è stata effettuata da un analista “puro”. Nella fase di test del nuovo sviluppo, per molto tempo non siamo riusciti a capire perché si verificassero errori nel collegamento delle nuove tariffe e solo allora, dopo aver svelato l'intero groviglio, siamo arrivati ​​​​al fondo della verità. Abbiamo perso molto tempo e non abbiamo rispettato le scadenze.

Il problema era che molti momenti nascosti e insidie ​​rimanevano solo nella testa della nostra station wagon e non venivano trasferiti su carta. Come spiegò in seguito Anatoly, aveva troppa fretta. Ma l'opzione più probabile è che abbia riscontrato problemi già durante lo sviluppo e li abbia semplicemente aggirati senza rifletterlo da nessuna parte.

C'era un'altra situazione. Ora abbiamo un solo tester, quindi alcuni compiti devono essere testati da analisti, compresi quelli generalisti. Pertanto, ho assegnato un compito al condizionale Fedor: “universale – okay, lasciamelo fare, visto che non c’è nessun altro”.
Fedor è un “tre in uno”, ma per questo compito è già stato assegnato uno sviluppatore. Ciò significa che Fedya ha dovuto combinare solo un analista e un tester.

I requisiti sono stati raccolti, le specifiche sono state sottoposte allo sviluppo, è tempo di testare. Fedor conosce le modifiche del sistema “come le sue tasche” e ha elaborato a fondo i requisiti attuali. Pertanto non si è preoccupato di scrivere script di test, ma ha effettuato dei test su “come dovrebbe funzionare il sistema”, per poi trasmetterli agli utenti.
Il test è stato completato, la revisione è andata in produzione. Successivamente si è scoperto che il sistema non solo ha sospeso i pagamenti su determinati conti di saldo, ma ha anche bloccato i pagamenti da conti interni molto rari che non avrebbero dovuto parteciparvi.

Ciò è accaduto a causa del fatto che Fedor non ha verificato come “il sistema non dovrebbe funzionare”, non ha redatto un piano di test o liste di controllo. Ha deciso di risparmiare sui tempi e di affidarsi al proprio istinto.

Come affrontiamo i problemi?

Situazioni come queste influiscono sulle prestazioni del team, sulla qualità del rilascio e sulla soddisfazione del cliente. Pertanto, non possono essere lasciati senza attenzione e analisi delle ragioni.

1. Per ogni attività che ha causato difficoltà, ti chiedo di compilare un modulo unificato: una mappa degli errori, che permette di identificare la fase in cui si è verificato il “drawdown”:

2. Dopo aver identificato i colli di bottiglia, viene tenuta una sessione di brainstorming con ciascun dipendente che ha influenzato il problema: “Cosa cambiare?” (non consideriamo casi particolari in retrospettiva), a seguito delle quali nascono azioni specifiche (specifiche per ogni tipo di personalità) con scadenze.

3. Abbiamo introdotto regole per l'interazione all'interno del team. Ad esempio, abbiamo concordato di registrare necessariamente tutte le informazioni sullo stato di avanzamento di un'attività nel sistema di gestione del progetto. Quando gli artefatti vengono modificati/identificati durante il processo di sviluppo, ciò deve riflettersi nella base di conoscenza e nella versione finale delle specifiche tecniche.

4. Il controllo ha iniziato ad essere effettuato in ogni fase (particolare attenzione è prestata alle fasi problematiche del passato) e automaticamente in base ai risultati dell'attività successiva.

5. Se il risultato del compito successivo non è cambiato, non metto in discussione il generalista nel ruolo in cui se la cava male. Cerco di valutare la sua capacità e voglia di sviluppare competenze in questo ruolo. Se non trovo risposta lo lascio nel ruolo che gli è più vicino.

Cosa è successo 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. Stiamo gradualmente migliorando la qualità delle nostre pubblicazioni.

risultati

I dipendenti generalisti hanno i loro pro e contro.

vantaggi:

• puoi chiudere un'attività rallentata in qualsiasi momento o risolvere un bug urgente in breve tempo;
• un approccio integrato alla risoluzione di un problema: l'esecutore lo guarda dalla prospettiva di tutti i ruoli;
• i generalisti possono fare quasi tutto ugualmente bene.

Svantaggi:

• Aumenta il fattore BUS;
• le competenze chiave inerenti al ruolo vengono erose. Per questo motivo la qualità del lavoro diminuisce;
• aumenta la probabilità di uno spostamento delle scadenze, perché non c'è controllo in ogni fase. Ci sono anche i rischi di far crescere una “stella”: il dipendente è sicuro 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 puoi vedere, ci sono più carenze. Pertanto, utilizzo i generalisti solo se non ci sono abbastanza risorse e il compito è piuttosto urgente. Oppure una persona ha competenze che mancano ad altri, ma è in gioco la qualità.

Se si osserva la regola di distribuzione dei ruoli nel lavoro congiunto su un compito, la qualità del lavoro aumenta. Osserviamo i problemi da diverse angolazioni, la nostra visione non è offuscata, appaiono sempre pensieri nuovi. Allo stesso tempo, ogni membro del team ha tutte le opportunità di crescita professionale e di ampliamento delle proprie competenze.

Credo che la cosa più importante sia sentirsi coinvolti nel processo, fare il proprio lavoro, aumentando gradualmente l'ampiezza delle proprie competenze. Tuttavia, i generalisti in una squadra apportano vantaggi: l’importante è garantire che combinino efficacemente ruoli diversi.

Auguro a tutti un team auto-organizzato di “maestri universali del loro mestiere”!

Fonte: habr.com