Chi è chi nel settore IT?

Nella fase attuale dello sviluppo dell'industria del software, si può osservare una varietà di ruoli produttivi. Il loro numero sta crescendo, la classificazione si complica di anno in anno e, naturalmente, complicano i processi di selezione dei professionisti e di gestione del potenziale umano. Le tecnologie dell'informazione (IT) sono un settore di risorse lavorative altamente qualificate e di carenza di personale. Qui il processo di sviluppo delle competenze e la necessità di un lavoro sistematico con il potenziale umano sono spesso significativamente più efficaci rispetto alla selezione diretta tramite risorse online.

L'articolo tratta temi rilevanti per i professionisti delle risorse umane nelle aziende IT: le relazioni di causa ed effetto nell'evoluzione dei ruoli produttivi, le conseguenze di un'errata interpretazione del contenuto dei ruoli per il lavoro delle risorse umane nel suo complesso, così come le possibili opzioni per aumentare l'efficacia nella selezione dei professionisti.

Produzione IT per i neofiti

Chi è chi nell'IT è un tema di discussione in diverse sedi. Esiste da quando è nata l'intera industria IT, cioè dall'apparizione dei primi sviluppatori di software sul mercato di consumo all'inizio degli anni '90 del secolo scorso. E da allora non esiste una visione unitaria su questa questione, il che crea difficoltà e riduce l'efficienza del lavoro sulle risorse umane. Cerchiamo di fare chiarezza.

Per me, il tema dei ruoli produttivi nel settore IT è diventato rilevante e interessante sin dal mio ingresso in un'azienda IT. Ho speso molto tempo ed energia nervosa per comprendere il processo produttivo. Questi sforzi hanno superato le mie aspettative e i costi per l'adattamento ai processi in altri settori: istruzione, produzione materiale, piccole imprese. Avevo la consapevolezza che i processi sono complessi e inusuali, poiché, in generale, l'individuo è più adattato al mondo materiale rispetto a quello virtuale. Ma c'era una resistenza intuitiva: sembrava che qualcosa non andasse, non dovesse essere così. Il processo di adattamento ha richiesto, probabilmente, un anno, che, nella mia concezione, è una dimensione semplicemente cosmica. Alla fine, ho sviluppato un'idea abbastanza chiara dei ruoli chiave nella produzione IT.

Attualmente continuo a lavorare su questo tema, ma a un altro livello. Nel ruolo di responsabile del centro di sviluppo di un'azienda IT, mi capita spesso di interagire con studenti, docenti universitari, aspiranti studenti, ragazzi delle scuole e altri interessati a partecipare alla creazione di un prodotto IT per promuovere il brand del datore di lavoro nel mercato del lavoro di un nuovo territorio (città di Jaroslavl). Questa comunicazione non è semplice a causa della scarsa informazione degli interlocutori su come è organizzato il processo di sviluppo del software (SW) e, di conseguenza, della loro mancanza di comprensione dell'argomento della conversazione. Dopo 5-10 minuti di dialogo smetti di ricevere feedback e inizi a sentirti un forestiero, la cui lingua richiede traduzione. Di solito, tra gli interlocutori c'è qualcuno che tira le somme del dialogo e pronuncia il mito popolare degli anni '90: «In ogni caso, tutti gli informatici sono programmatori». Le fonti di origine di questo mito sono le seguenti:

• Il settore IT sta vivendo una rapida evoluzione, in queste condizioni tutti i significati e principi fondamentali sono in fase di formazione;
• in condizioni di incertezza è difficile esistere, quindi le persone cercano di semplificare la loro comprensione dell'ignoto creando miti;
• l'essere umano è più abituato a percepire il mondo materiale piuttosto che quello virtuale, rendendo difficile per lui definire concetti che vanno oltre la sua percezione.

I tentativi di combattere questo mito a volte sembrano una battaglia contro i mulini a vento, poiché ci sono diversi aspetti del problema che necessitano di essere affrontati. È necessario per uno specialista delle risorse umane avere, prima di tutto, un quadro chiaro dei ruoli produttivi all'interno dell'azienda IT, sia nella sua forma ideale che reale; in secondo luogo, comprendere come e quando può essere meglio utilizzata la risorsa interna dell'azienda; in terzo luogo, quali metodi pratici possono aiutare ad aumentare la consapevolezza dei partecipanti nel mercato del lavoro e contribuire allo sviluppo del brand del datore di lavoro. Esaminiamo questi aspetti più nel dettaglio.

Il ciclo di vita del software come base dei ruoli produttivi

Non è un segreto che, in generale, tutti i ruoli produttivi in qualsiasi azienda IT si basino sul ciclo di vita del software. Pertanto, se si vuole affrontare concettualmente l'idea di raggiungere un'unità di comprensione su questo tema all'interno dell'intero settore IT, è necessario fare riferimento proprio al ciclo di vita del software come base semantica accettata e chiaramente compresa da tutti. La discussione di varianti specifiche relative ai ruoli produttivi si colloca nel contesto della nostra relazione creativa con il ciclo di vita del software.

Consideriamo ora le fasi che compongono il ciclo di vita del software, utilizzando come esempio la metodologia RUP. Queste rappresentano collegamenti abbastanza consolidati riguardo al contenuto e alla terminologia. Il processo produttivo inizia sempre e ovunque con la modellazione del business e la definizione dei requisiti, e si conclude (ovviamente in modo convenzionale) con la consulenza agli utenti e le modifiche al software basate sulle "richieste" degli utenti.

Se facciamo un excursus storico verso la fine del secolo scorso (come è noto, un periodo di "automazione a isola"), possiamo vedere che tutto il processo di creazione del software era gestito da un programmatore sviluppatore. Qui si radica il mito secondo cui ogni informatico è un programmatore.

Con la complessità crescente dei processi produttivi, l'emergere di piattaforme integrate e il passaggio a un'automazione complessiva delle aree tematiche, insieme al reingegnerizzazione dei processi aziendali, diventa inevitabile l'emergere di ruoli specializzati legati alle fasi del ciclo di vita. È così che nascono l'analista, il tester e lo specialista di supporto tecnico.

La varietà di posizioni prendendo come esempio il ruolo dell'analista

L'analista (anche ingegnere analista, anche formulatore, metodologo, analista di business, analista di sistema, ecc.) aiuta a "far incontrare" le esigenze aziendali e le tecnologie per la loro realizzazione. La descrizione della formulazione del compito per lo sviluppatore è il modo in cui si può caratterizzare la funzione principale di un analista astratto. Funziona come un collegamento tra il cliente e lo sviluppatore nei processi di raccolta dei requisiti, analisi e progettazione del software. Nelle condizioni di produzione reale, l'elenco delle funzioni di un analista è determinato dal modo in cui è organizzata la produzione, dalla qualifica dello specialista e dalla specificità del dominio oggetto di modellazione.

Una parte degli analisti è più vicina al cliente. Questi sono gli analisti di business (Business Analyst). Comprendono profondamente i processi aziendali del dominio oggetto e sono esperti nei processi da automatizzare. È molto importante avere specializzazioni del genere nel personale dell'azienda, soprattutto quando si automatizzano domini oggetto metodologicamente complessi. In particolare, per noi come automatori del processo di bilancio dello Stato è assolutamente necessario che tra gli analisti ci siano esperti del dominio oggetto. Si tratta di dipendenti altamente qualificati con una buona formazione in ambito finanziario-economico e esperienza di lavoro negli organi finanziari, preferibilmente come specialisti senior. È estremamente importante avere esperienza non nel settore IT, ma specificamente nel dominio oggetto.

L'altra parte degli analisti è più vicina agli sviluppatori. Questi sono gli analisti di sistema (System Analyst). Il loro compito principale è identificare, sistematizzare e analizzare i requisiti del cliente per comprendere la possibilità di soddisfarli, preparare specifiche tecniche e descrivere le formulazioni dei compiti. Comprendono non solo i processi aziendali, ma anche le tecnologie dell'informazione, hanno una buona comprensione delle capacità del software fornito al cliente, possiedono competenze di progettazione e, di conseguenza, capiscono come trasmettere al meglio gli interessi del cliente allo sviluppatore. Questi dipendenti hanno sicuramente un'istruzione nel campo delle ICT e un orientamento ingegneristico-tecnico, preferibilmente con esperienza lavorativa nel settore IT. Quando si selezionano tali specialisti, sarà un evidente vantaggio avere competenze di progettazione utilizzando strumenti moderni.

Un'altra tipologia di analisti sono gli scrittori tecnici (Technical Writer). Si occupano della documentazione all'interno dei processi di sviluppo software, preparano manuali per l'utente e l'amministratore, istruzioni tecnologiche, materiali video formativi, ecc. Il loro compito principale è riuscire a comunicare agli utenti e ad altre parti interessate le informazioni sul funzionamento del programma, descrivere concetti tecnici complessi in modo conciso e comprensibile. La maggior parte degli scrittori tecnici ha una padronanza eccellente della lingua russa, avendo al contempo un'istruzione tecnica e una mentalità analitica. Per questi specialisti, le competenze nella redazione di testi tecnici chiari, accurati e dettagliati in conformità agli standard, nonché la conoscenza e l'uso degli strumenti di documentazione, sono di fondamentale importanza.

Pertanto, vediamo lo stesso ruolo (e, per inciso, il posto nell'organigramma) – analista, ma nelle sue varie incarnazioni pratiche. La ricerca di specialisti per ciascuno di essi ha le proprie peculiarità. È importante sapere che queste varietà di analisti devono spesso possedere competenze e conoscenze che non sono sempre compatibili in una sola persona. Uno è un umanista, incline al lavoro analitico con grandi volumi di documenti testuali, con una buona capacità di espressione e comunicazione, l'altro è un "tecnico" con una mentalità ingegneristica e interessi nel settore IT.

Prendere da fuori o coltivare internamente?

Per un grande rappresentante dell'industria IT, l'efficacia della selezione diretta tramite risorse online diminuisce man mano che i progetti crescono. Questo accade, in particolare, per i seguenti motivi: la rapida adattabilità a processi complessi all'interno dell'azienda non è possibile, e la velocità di apprendimento degli strumenti specifici risulta inferiore alla velocità di sviluppo del progetto. Pertanto, per lo specialista HR è importante sapere non solo chi cercare all'esterno, ma anche come sfruttare le risorse interne dell'azienda, per forgiare e far crescere uno specialista.

Per gli analisti aziendali, è molto importante avere esperienza lavorativa all'interno di processi reali del settore, quindi la loro selezione "da fuori" è più efficace rispetto alla loro crescita all'interno dell'azienda. In questo contesto, è fondamentale che il professionista HR conosca l'elenco delle organizzazioni che possono essere fonti di tale risorsa umana e si concentri sulla ricerca di curriculum tra di esse durante il reclutamento.

Per coprire posizioni come analista di sistema e architetto software, al contrario, il processo di formazione delle risorse umane all'interno dell'azienda è di enorme importanza. Questi specialisti devono formarsi in un ambiente produttivo attivo e secondo le specifiche di una determinata organizzazione. Gli analisti di sistema (System Analyst) si sviluppano da analisti aziendali (Business Analyst), scrittori tecnici (Technical Writer) e ingegneri di supporto tecnico (Technical Support Engineer). Gli architetti software (Software Architect) provengono da progettisti (System Designer) e sviluppatori software (Software Developer) man mano che accumulano esperienza e ampliano le loro conoscenze. Questo aspetto consente al professionista HR di utilizzare efficacemente le risorse interne dell'azienda.

Intersezione, fusione ed evoluzione dei ruoli produttivi

C'è anche un'altra questione complessa da realizzare nel processo produttivo: stabilire confini chiari tra i ruoli. A prima vista, potrebbe sembrare tutto ovvio: è terminata l'implementazione, sono stati firmati i documenti per l'entrata in produzione del software e tutto è stato trasferito al supporto tecnico. È corretto, tuttavia frequentemente si verificano situazioni in cui il cliente, abituato a mantenere un contatto stretto con l'analista e percependo in lui una "bacchetta magica", continua a comunicare attivamente con lui, anche se il sistema è già stato implementato e formalmente si trova nella fase di supporto. Tuttavia, dal punto di vista del cliente, chi potrebbe rispondere meglio e più velocemente alle domande sul funzionamento del sistema se non l'analista che ha collaborato con lui nell'impostare il compito? Ed è qui che sorge la questione della parziale duplicazione dei ruoli dell'ingegnere di supporto tecnico e dell'analista. Col passare del tempo, tutto si sistema; il cliente si abitua a comunicare con il servizio di supporto tecnico, ma all'inizio dell'uso del software, questo "passaggio interno" non sempre riesce a essere effettuato senza stress da entrambe le parti.

L'intersezione dei ruoli dell'analista e dell'ingegnere di supporto tecnico si verifica anche quando il flusso di requisiti per lo sviluppo avviene all'interno della fase di supporto. Tornando al ciclo di vita del software, notiamo una discrepanza tra le condizioni produttive reali e le impostazioni formali secondo cui l'analisi dei requisiti e la definizione del compito possono essere svolte esclusivamente da un analista. Un esperto di gestione delle risorse umane deve certamente avere una chiara visione ideale dei ruoli all'interno del ciclo di vita del software, poiché essi hanno confini definiti. Tuttavia, è importante considerare che può esserci un'intersezione. Nella valutazione delle conoscenze e competenze di un candidato, è fondamentale prestare attenzione alla presenza di esperienze affini; quindi, nella ricerca di ingegneri di supporto tecnico, è possibile prendere in considerazione anche candidati con esperienza da analisti e viceversa.

Oltre all'intersezione, si osserva spesso la fusione dei ruoli produttivi. Ad esempio, un business analyst e un technical writer possono coesistere nella stessa persona. La presenza di un architetto software (Software Architect) è imprescindibile nello sviluppo industriale di grandi dimensioni, mentre i progetti molto piccoli possono fare a meno di questo ruolo: in quel caso, le funzioni dell'architetto sono svolte dagli sviluppatori (Software Developer).

Il cambiamento dei periodi storici nelle metodologie e tecnologie di sviluppo porta inevitabilmente all'evoluzione del ciclo di vita del software. Globalmente, i suoi principali passaggi rimangono invariati, ma c'è una maggiore dettagliatura. Ad esempio, con il passaggio a soluzioni web e l'aumento delle possibilità di configurazioni remote, è emerso il ruolo dello specialista in configurazione software. Nella fase iniziale della storia, questi erano i programmatori, cioè ingegneri che trascorrevano la maggior parte del loro tempo lavorativo presso le postazioni dei clienti. L'aumento dei volumi e della complessità del software ha portato all'emergere del ruolo di architetto software (Software Architect). Le richieste di accelerare il rilascio delle versioni e di migliorare la qualità del software hanno favorito lo sviluppo del testing automatizzato e l'emergere di un nuovo ruolo: quello di QA Engineer (Quality Assurance Engineer), e così via. L'evoluzione dei ruoli in tutte le fasi dell'organizzazione del processo produttivo è strettamente legata allo sviluppo di metodi, tecnologie e strumenti.

Quindi, abbiamo esaminato alcuni aspetti interessanti relativi alla distribuzione dei ruoli produttivi all'interno di un'azienda di sviluppo software nel contesto del ciclo di vita del software. È evidente che questa è una prospettiva interna, specifica per ogni azienda. Per tutti noi, come partecipanti al mercato del lavoro nell'industria IT e responsabili della promozione del marchio del datore di lavoro, è altrettanto importante avere una prospettiva esterna. E qui esiste un grande problema, non solo nella ricerca di significato, ma anche nella comunicazione di queste informazioni al pubblico target.

Qual è il problema del "zoo" delle posizioni IT?

La confusione nella mente degli HR, dei responsabili della produzione e la varietà di approcci portano a una diversità molto ampia, che risulta in un vero e proprio "zoo" delle posizioni IT. L'esperienza di colloqui e semplici contatti professionali dimostra che spesso le persone non hanno una chiara comprensione del significato che deve derivare dai nomi delle posizioni. Ad esempio, nella nostra organizzazione, le posizioni che includono il concetto di "ingegnere-analista" si riferiscono a chi definisce i compiti. Tuttavia, risulta che non è così ovunque: ci sono aziende di sviluppo dove l'ingegnere-analista è un implementatore. Comprensione completamente diversa, siete d'accordo?

In primo luogo, il "zoo" delle posizioni IT riduce sicuramente l'efficacia del reclutamento. Ogni datore di lavoro, nello sviluppare e promuovere il proprio marchio, desidera comunicare in breve tutti i significati esistenti nella sua produzione. E se spesso nemmeno lui riesce a dire chiaramente chi è chi, è naturale che trasmetterà all'esterno incertezze.

In secondo luogo, il "zoo" delle posizioni IT crea enormi problemi nella formazione e nello sviluppo delle risorse IT. Ogni azienda IT seria, orientata a formare e sviluppare il potenziale umano, e non semplicemente a sfruttare i siti di lavoro, si trova presto o tardi di fronte alla necessità di interagire con gli istituti di istruzione. Per le risorse IT altamente qualificate, questo segmento di università è formato dai migliori, che si trovano almeno nella classifica delle TOP-100.

Il problema dell'integrazione con le università nella creazione di un processo continuo di formazione degli specialisti IT risiede per circa metà nell'assenza da parte delle università di una comprensione chiara di chi sia chi all'interno di un'azienda IT. Hanno solo una conoscenza superficiale in merito. In genere, le università hanno alcune specializzazioni che includono il termine "informatica" nei loro nomi, e spesso accade che durante la campagna di ammissione si faccia riferimento all'idea che tutte le specializzazioni siano in sostanza la stessa cosa. E questo appare come se si sostenesse il mito popolare che tutti gli informatici siano programmatori.

L'esperienza della nostra stretta collaborazione con le università mostra che la specializzazione "Informatica applicata (per settori)" fornisce risorse per i dipartimenti di metodologie e supporto tecnico, ma non per lo sviluppo. Mentre "Informatica fondamentale" e "Ingegneria del software" preparano un'eccellente risorsa umana per gli sviluppatori. Per non indirizzare gli studenti a un percorso inadeguato, è necessario "dissipare la nebbia" che circonda la produzione IT.

Si può ridurre tutto a un comune denominatore?

È possibile unificare i ruoli produttivi e arrivare a una comprensione comune di essi sia dall'interno che dall'esterno dell'azienda?

Certo, è possibile e necessario, perché l'esperienza collettiva accumulata da tutte le aziende sviluppatrici dimostra l'esistenza di concetti comuni che unificano l'organizzazione del processo produttivo. Ciò deriva dal fatto che esiste un concetto di ciclo di vita del software che è interpretato in modo univoco da tutti, e i ruoli produttivi recentemente emersi (Data Scientist, QA Engineer, Machine Learning Engineer, ecc.) sono una conseguenza della precisazione e dello sviluppo del ciclo di vita del software stesso, che avviene con il miglioramento delle tecnologie e degli strumenti, così come lo sviluppo e l'ingrandimento delle sfide aziendali.

Allo stesso tempo, è difficile uniformare i ruoli di produzione, poiché l'IT è uno dei settori più giovani e in rapida espansione dell'economia. In un certo senso, è un caos da cui è emerso l'universo. Una chiara struttura organizzativa qui è impossibile e inappropriata, perché l'IT è un ambito intellettuale ma molto creativo. Da un lato, un informatico è un «fisico» intellettuale con un pensiero algoritmico e matematico sviluppato, dall'altro, è un «lirico» creatore, portatore e promotore di idee. Proprio come un artista, non ha un piano chiaro per scrivere un'opera, non può scomporre l'immagine in parti, poiché quest'ultima smetterebbe di esistere. È il padrone dei processi informativi, che di per sé sono astratti, intangibili, difficili da misurare, ma rapidi.

Strategie per costruire un'efficace gestione delle risorse umane nell'IT

Quindi, cosa è importante sapere per un esperto HR per costruire un'efficace gestione delle risorse umane in un contesto di diversità dei ruoli nell'IT?

In primo luogo, qualsiasi specialista HR in un'azienda IT deve avere una comprensione della situazione specifica per la sua impresa: chi fa cosa, chi e come si chiama e, soprattutto, quale significato viene attribuito a questi ruoli nel contesto della produzione specifica.

In secondo luogo, l'esperto HR deve avere una visione flessibile dei ruoli di produzione. Cioè, inizialmente deve formarsi un'idea ideale di essi, che gli permetta di orientarsi. Poi, deve esserci un quadro reale della produzione: dove e in che modo i ruoli si sovrappongono e si uniscono, quale percezione di questi ruoli hanno i dirigenti di produzione. La difficoltà per lo specialista delle risorse umane consiste nel conciliare nella propria mente le situazioni reale e ideale, senza tentare forzatamente di riorganizzare i processi secondo la loro comprensione ideale, ma aiutando la produzione a soddisfare il bisogno di risorse.

In terzo luogo, è fondamentale avere un'idea delle possibili traiettorie di sviluppo per determinate figure professionali: in quali casi può essere efficace un reclutamento esterno e quando è meglio investire nella crescita interna dei dipendenti, offrendo loro opportunità di sviluppo, quali qualità dei candidati consentiranno loro di progredire in un determinato ambito, quali qualità non possono coesistere in una sola persona, cosa è inizialmente importante per la scelta della traiettoria di sviluppo.

In quarto luogo, torniamo al punto secondo cui l'IT è un campo di personale altamente qualificato, dove per un lavoro del personale più efficace è inevitabile una precoce integrazione con l'ambiente educativo universitario. In questa situazione, ogni specialista HR deve sviluppare non solo competenze nel reclutamento diretto, nella gestione dei curricula e nell'intervista, ma anche necessariamente orientarsi nel contesto della formazione universitaria dei professionisti: quali università formano personale per le aziende, quali corsi all'interno di specifiche università soddisfano le esigenze del personale e, cosa importante, chi c'è dietro, chi dirige e realizza la formazione dei professionisti nelle università.

Pertanto, se si desidera smontare deliberatamente il mito che tutti gli informatici siano programmatori, è necessario compiere una serie di passi in questa direzione e prestare particolare attenzione alle nostre università, dove si gettano le basi della percezione della futura professione. In altre parole, è necessaria una continua interazione con l'ambiente educativo, ad esempio, mediante l'utilizzo di formati moderni di lavoro collaborativo in centri di coworking, 'punti di ebollizione', partecipazione a intensivi educativi. Questo permetterà di distruggere le false rappresentazioni delle imprese IT, aumenterà l'efficacia del lavoro del personale e creerà condizioni per attività congiunte nella preparazione di diversi specialisti del nostro settore.

Esprimo gratitudine ai colleghi che hanno partecipato alla preparazione e al mantenimento della pertinenza di questo articolo: Valentina Vershinina e Yuri Krupin.

Fonte: habr.com