Chi è chi in IT?

Nello sviluppo attuale del software industriale, possiamo osservare una varietà di ruoli professionali. Il loro numero cresce, la classificazione diventa più complessa ogni anno e, naturalmente, anche i processi di reclutamento di specialisti e la gestione del potenziale umano si complicano. Le tecnologie dell'informazione (IT) rappresentano un campo di risorse umane altamente qualificate e carenza di personale. Qui, il processo di formazione del personale e la necessità di lavorare in modo mirato con il potenziale umano possono essere significativamente più efficaci rispetto al reclutamento diretto tramite risorse online.

L'articolo affronta questioni rilevanti per i professionisti delle risorse umane nelle aziende IT: le relazioni causa-effetto nell'evoluzione dei ruoli professionali, le conseguenze di una cattiva interpretazione del contenuto dei ruoli per il lavoro delle risorse umane in generale, nonché possibili modi per migliorare l'efficacia del reclutamento di specialisti.

Produzione IT per i non addetti ai lavori

Chi è chi nell'IT - questo è un tema di discussione su diverse piattaforme. Esiste da tanto quanto tutta l'industria IT, cioè dall'emergere delle prime aziende sviluppatrici di software sul mercato dei consumatori all'inizio degli anni '90. E da altrettanto tempo manca una visione univoca su questa questione, il che crea difficoltà e riduce l'efficacia del lavoro delle risorse umane. Proveremo a chiarirlo.

Per me, il tema dei ruoli professionali nel settore IT è diventato rilevante e interessante dal momento in cui sono entrato in un'azienda IT. Ho dedicato molto tempo e nervi per comprendere il processo produttivo. Questi investimenti hanno superato le mie aspettative e i costi di adattamento ai processi in altri settori: educazione, produzione materiale, piccole aziende. Sapevo che i processi erano complessi e poco familiari, poiché, in generale, l'uomo è più adattato al mondo materiale che a quello virtuale. Ma c'era una resistenza intuitiva: sembrava che ci fosse qualcosa di strano, che non dovesse essere così. Il processo di adattamento ha richiesto quasi un anno, che nella mia percezione è una durata enorme. Alla fine, ho sviluppato un'idea abbastanza chiara sui ruoli chiave nella produzione IT.

Attualmente continuo a lavorare su questo tema, ma a un altro livello. In qualità di responsabile di un centro di sviluppo di un'azienda IT, spesso mi trovo a parlare con studenti, docenti universitari, aspiranti universitari, scolari e altri desiderosi di partecipare alla creazione di un prodotto IT al fine di promuovere il marchio del datore di lavoro nel mercato del lavoro di un nuovo territorio (città di Yaroslavl). Questo tipo di comunicazione è difficile a causa della scarsa informazione degli interlocutori su come è organizzato il processo di sviluppo del software (SW) e, di conseguenza, della loro incomprensione dell'argomento della conversazione. Dopo 5-10 minuti di dialogo, smetti di ricevere feedback e inizi a sentirti straniero, come se avessi bisogno di un interprete. Di solito, tra gli interlocutori c'è qualcuno che chiude il dialogo e pronuncia il mito popolare degli anni '90: "Comunque, tutti gli informatici sono programmatori". Le fonti di questo mito sono:

• L'industria IT si sta sviluppando rapidamente, e 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 comprensione dell'ignoto creando miti;
• le persone sono più abituate a percepire il mondo materiale piuttosto che quello virtuale, rendendo difficile fornire definizioni a concetti che esulano dalla loro percezione.

Tentare di combattere questo mito a volte ricorda una battaglia contro i mulini a vento, poiché ci sono diversi aspetti del problema che necessitano di elaborazione. Gli specialisti delle risorse umane devono, in primo luogo, avere un quadro chiaro dei ruoli professionali in un'azienda IT sia nell'ideale che nella realtà, in secondo luogo, comprendere come e quando può essere più efficacemente coinvolto il potenziale interno dell'azienda, e in terzo luogo, quali metodi concreti possono aiutare a migliorare l'informazione dei partecipanti al mercato del lavoro e a favorire lo sviluppo del marchio del datore di lavoro. Esaminiamo questi aspetti più nel dettaglio.

Il ciclo di vita del software come base dei ruoli professionali

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 stabilire un accordo concettuale sull'unità di percezione di questa questione all'interno dell'intero settore IT, è necessario basarsi proprio sul ciclo di vita del software come fondamento semantico accettato e chiaramente compreso da tutti. La discussione delle concrete varianti di attuazione della questione dei ruoli produttivi si colloca nell'ambito del nostro approccio creativo al ciclo di vita del software.

Dunque, esaminiamo le fasi incluse nel ciclo di vita del software, utilizzando l'esempio della metodologia RUP. Esse rappresentano anelli ben definiti in termini di contenuto e terminologia. Il processo produttivo inizia sempre e ovunque con la modellazione del business e la definizione dei requisiti, e si conclude (in modo convenzionale, certo) con la consulenza agli utenti e con le modifiche del software in base alle "richieste" degli utenti.

Se si compie un excursus storico alla fine del secolo scorso (come noto, questo fu il periodo dell'"automazione a isola"), si può osservare che l'intero processo di creazione del software veniva gestito da un programmatore-sviluppatore. Qui ha origine il mito secondo cui ogni professionista IT è un programmatore.

Con la complessità crescente dei processi produttivi, l'emergere di piattaforme integrate e il passaggio all'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ì, appaiono analisti, tester e specialisti di supporto tecnico.

La varietà delle posizioni attraverso l'esempio del ruolo dell'analista

L'analista (noto anche come ingegnere-analista, redattore, metodologo, analista di business, analista sistemico, ecc.) aiuta a "fare amicizia" tra le sfide aziendali e le tecnologie per la loro realizzazione. La descrizione della formulazione del compito per lo sviluppatore può caratterizzare la funzione principale dell'analista astratto. Egli funge da collegamento tra il cliente e lo sviluppatore nei processi di definizione dei requisiti, analisi e progettazione del software. In condizioni produttive reali, l'elenco delle funzioni dell'analista è determinato in base al modo di organizzazione della produzione, alla qualificazione dello specialista, e alla specificità dell'area tematica in fase di modellazione.

Una parte degli analisti si trova più vicina al cliente. Questi sono gli analisti di business (Business Analyst). Comprendono profondamente i processi aziendali dell'area tematica e sono esperti nei processi automatizzati. È molto importante avere tali specialisti nel personale dell'azienda, specialmente quando si automatizzano aree tematiche metodologicamente complesse. In particolare, per noi come automatizzatori del processo di bilancio dello Stato è imprescindibile che tra gli analisti vi siano esperti dell'area tematica. Questi sono collaboratori altamente qualificati con un buon background formativo economico-finanziario e con esperienza lavorativa nelle autorità finanziarie, preferibilmente come specialisti senior. È estremamente importante avere esperienza non nel settore IT, ma proprio nell'area tematica.

L'altra parte degli analisti è più vicina agli sviluppatori. Questi sono gli analisti sistemici (System Analyst). Il loro compito principale è identificare, sistematizzare e analizzare i requisiti del cliente per determinarne la soddisfazione, preparare specifiche tecniche e descrivere le formulazioni dei compiti. Essi comprendono non solo i processi aziendali, ma anche le tecnologie dell'informazione, e hanno una buona comprensione delle possibilità del software fornito al cliente, possiedono competenze di progettazione e, di conseguenza, sanno come meglio comunicare gli interessi del cliente allo sviluppatore. Questi collaboratori devono avere un'istruzione nel campo delle ICT e una mentalità ingegneristica, preferibilmente con esperienza nel settore IT. Quando si selezionano tali specialisti, è un chiaro vantaggio avere competenze progettuali utilizzando strumenti moderni.

Un altro tipo di specialisti è rappresentato dagli scrittori tecnici (Technical Writer). Si occupano della documentazione all'interno dei processi di sviluppo software, preparano guide per utenti e amministratori, istruzioni tecnologiche, video didattici e altro ancora. Il loro compito principale è quello di comunicare agli utenti e ad altre parti interessate come funziona il programma, descrivendo concetti tecnici complessi in modo chiaro e conciso. Gli scrittori tecnici, in generale, hanno un'ottima padronanza della lingua russa e possiedono una formazione tecnica e una mentalità analitica. Per questi specialisti, è fondamentale avere abilità nella redazione di testi tecnici chiari, corretti e dettagliati secondo gli standard, oltre a conoscenze e competenze specifiche negli strumenti di documentazione.

In questo modo, vediamo un unico ruolo (e, tra l'altro, una posizione nel personale) - analista, ma in diverse incarnazioni specifiche e pratiche. La ricerca di specialisti per ciascuna di esse presenta le proprie peculiarità. È importante sapere che queste varietà di analisti devono spesso possedere abilità e conoscenze che possono risultare incompatibili in una sola persona. Uno è un umanista, incline al lavoro analitico con grandi volumi di documenti testuali, con una buona eloquenza e capacità comunicative, l'altro è un "tecnico" con una mentalità ingegneristica e interessi nel campo IT.

Prendiamo da fuori o facciamo crescere internamente?

Per un grande attore dell'industria IT, l'efficacia della ricerca diretta attraverso risorse internet diminuisce con l'aumento dei progetti. Ciò avviene, in particolare, per le seguenti ragioni: non è possibile adattarsi rapidamente a processi complessi all'interno dell'azienda, la velocità di apprendimento degli strumenti specifici risulta inferiore a quella dello sviluppo del progetto. Pertanto, per uno specialista HR è fondamentale sapere non solo chi cercare all'esterno, ma anche come è possibile sfruttare le risorse interne dell'azienda, da chi e in che modo formare un esperto.

Per gli analisti di business, è molto importante avere esperienza di lavoro all'interno dei reali processi dell'area tematica; perciò, la loro assunzione "da fuori" è più efficace rispetto alla crescita interna nell'azienda. È essenziale che lo specialista HR conosca l'elenco delle organizzazioni che possono fungere da fonti per questo capitale umano e, nella ricerca, si concentri su come trovare curriculum vitae da queste fonti.

Per chiudere posizioni come analista di sistema e architetto software, al contrario, il processo di formazione del personale all'interno dell'azienda riveste un'importanza enorme. Questi specialisti devono formarsi in condizioni di un ambiente produttivo attivo e in base alle specificità di una determinata organizzazione. Gli analisti di sistema (System Analyst) si sviluppano dagli analisti di business (Business Analyst), dagli scrittori tecnici (Technical Writer) e dagli ingegneri di supporto tecnico (Technical Support Engineer). Gli architetti software (Software Architect) provengono dai progettisti (System Designer) e dai programmatori (Software Developer) man mano che accumulano esperienza e ampliano le loro conoscenze. Questa situazione consente allo specialista HR di utilizzare efficacemente le risorse interne dell'azienda.

Intersezione, fusione ed evoluzione dei ruoli produttivi

C'è anche un'altra questione difficile da attuare nel processo produttivo: stabilire confini chiari tra i ruoli. A prima vista può sembrare che sia tutto evidente: una volta completata l'implementazione, firmati i documenti per la messa in esercizio del software e trasferito tutto al supporto tecnico. È tutto corretto, tuttavia, spesso si verificano situazioni in cui il cliente, per abitudine, mantiene un contatto stretto con l'analista e lo vede come una 'bacchetta magica', continuando a comunicare attivamente con lui nonostante la sistemazione avvenga già e formalmente sia in corso la fase di supporto. Tuttavia, dal punto di vista del cliente, chi meglio e più velocemente può rispondere alle domande sull'uso del sistema se non l'analista che insieme a lui ha definito il compito? Qui insorge la questione della parziale duplicazione dei ruoli tra l'ingegnere di supporto tecnico e l'analista. Con il passare del tempo, tutto si stabilizza; 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 svolgersi senza stress per entrambe le parti.

L'incrocio tra i ruoli di analista e ingegnere del supporto tecnico si verifica anche quando il flusso di requisiti per lo sviluppo avviene durante la fase di assistenza. Ritornando al ciclo di vita del software, vediamo un'incongruenza tra le reali condizioni produttive e le disposizioni formali secondo cui l'analisi dei requisiti e la definizione delle specifiche possono essere eseguite esclusivamente da un analista. Un esperto in risorse umane deve certamente comprendere l'immagine ideale dei ruoli all'interno del ciclo di vita del software, che hanno confini ben definiti. Tuttavia, è importante tenere presente che potrebbe esserci sovrapposizione. Quando si valutano le competenze e le conoscenze dei candidati, è fondamentale considerare la presenza di esperienze correlate, e quindi, nella ricerca di ingegneri del supporto tecnico, potrebbero essere presi in considerazione candidati con esperienza da analista e viceversa.

Oltre alla sovrapposizione, si osserva spesso una fusione dei ruoli produttivi. Ad esempio, un analista aziendale e un tecnico della scrittura possono coesistere nella stessa persona. La presenza di un architetto software (Software Architect) è essenziale nello sviluppo industriale su larga scala, mentre i progetti molto piccoli possono fare a meno di questo ruolo: in questi casi, le funzioni dell'architetto sono ricoperte dagli sviluppatori (Software Developer).

Il cambiamento dei periodi storici nei metodi e nelle tecnologie di sviluppo porta inevitabilmente all'evoluzione del ciclo di vita del software. Globalmente, naturalmente, le sue fasi principali rimangono inalterate, ma si verifica una loro articolazione. Ad esempio, con il passaggio a soluzioni web e l'aumento delle possibilità di configurazione remota, è emerso il ruolo dello specialista nella configurazione del software. Nei primi periodi storici, questi erano i consulenti, ossia ingegneri che trascorrevano la maggior parte del loro tempo di lavoro presso i clienti. L'aumento delle dimensioni e della complessità del software ha portato all'emergere della figura dell'architetto software (Software Architect). Le esigenze di accelerare il rilascio delle versioni e migliorare la qualità del software hanno favorito lo sviluppo di test automatizzati e l'emergere di un nuovo ruolo: ingegnere QA (Quality Assurance Engineer), ecc. L'evoluzione dei ruoli in tutte le fasi dell'organizzazione del processo produttivo è strettamente legata allo sviluppo di metodi, tecnologie e strumenti.

Abbiamo esaminato alcuni aspetti interessanti riguardanti la distribuzione dei ruoli produttivi all'interno di un'azienda di sviluppo software nel contesto del ciclo di vita del software. È chiaro che questo è uno sguardo interno, specifico per ogni azienda. Per tutti noi, partecipanti al mercato del lavoro nel settore IT e responsabili della promozione del marchio del datore di lavoro, è particolarmente importante avere una visione esterna. Qui emerge un grande problema non solo nella ricerca di significati, ma anche nella comunicazione di queste informazioni al pubblico di riferimento.

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

La confusione nella mente degli esperti HR, negli organizzatori di produzione e la varietà di approcci conducono a una grande diversità, proprio a un 'zoo' delle posizioni IT. L'esperienza di colloqui e semplici contatti professionali mostra che spesso le persone non hanno una chiara comprensione del significato che dovrebbe derivare dai nomi delle posizioni. Ad esempio, nella nostra organizzazione, le posizioni che includono il concetto di 'ingegnere-analista' implicano che si tratti di uno specificatore di compiti. Tuttavia, in realtà, non è così ovunque: ci sono aziende di sviluppo dove l'ingegnere-analista è un consulente. Una comprensione completamente diversa, non credi?

In primo luogo, il 'zoo' delle posizioni IT riduce sicuramente l'efficacia nel reclutamento. Ogni datore di lavoro, nello sviluppo e nella promozione del proprio marchio, desidera comunicare in modo conciso tutti i significati presenti nella sua produzione. E se spesso non riesce a dire chiaramente chi è chi, è naturale che trasmetterà all'esterno incertezza.

In secondo luogo, il 'zoo' delle posizioni IT crea enormi problemi nella formazione e nello sviluppo delle risorse IT. Ogni azienda IT seria, che punta a formare e sviluppare il potenziale dei dipendenti e non solo a 'mungere' siti di lavoro, incontra prima o poi la necessità di collaborare con istituti di istruzione. Per il personale IT altamente qualificato, questo segmento comprende atenei, soprattutto i migliori, che si trovano almeno nella classifica delle TOP-100.

Il problema dell'integrazione con le università nel costruire un processo continuo di formazione di specialisti IT risiede in gran parte nell'assenza di una chiara comprensione, da parte delle università, di chi sono i professionisti all'interno di un'azienda IT. Hanno una visione molto superficiale della situazione. Di solito, le università offrono alcune specializzazioni con la parola "informatica" nel nome, e spesso accade che, durante le campagne di ammissione, ci si basi sull'idea che tutte le specializzazioni siano sostanzialmente simili. Questo è analogo a far riferimento al mito popolare che tutti gli informatici siano programmatori.

L'esperienza della nostra stretta collaborazione con le università dimostra che il corso di studio "Informatica Applicata (per settori)" fornisce professionisti per i reparti di metodologia e supporto tecnico, ma non per la parte di sviluppo. Mentre "Informatica Fondamentale" e "Ingegneria del software" formano un'ottima risorsa umana per gli sviluppatori. Per non indirizzare gli studenti con candidature inadatte, è necessario "dissipare la nebbia" che circonda l'industria IT.

È possibile trovare un denominatore comune?

È possibile unificare i ruoli di produzione e raggiungere un'intesa comune interna ed esterna all'azienda?

Certo, è possibile e necessario, perché l'esperienza collettiva accumulata da tutte le aziende di sviluppo dimostra la presenza di concetti comuni e unificanti per l'organizzazione del processo produttivo. Questo è il risultato di un concetto di ciclo di vita del software chiaramente definito e universalmente interpretato, e i ruoli produttivi emergenti (Data Scientist, QA Engineer, Machine Learning Engineer, ecc.) sono il risultato della definizione e dello sviluppo del ciclo di vita del software in quanto tale, che avvengono con il miglioramento delle tecnologie e degli strumenti, nonché con l'espansione e il consolidamento delle esigenze aziendali.

Allo stesso tempo, risulta difficile unificare i ruoli produttivi, poiché l'IT è uno dei settori più giovani e in rapida espansione dell'economia. In un certo senso, è il caos da cui è emerso l'universo. Una struttura organizzativa chiara qui è impossibile e inappropriata, poiché l'IT è un campo altamente intellettuale, ma anche molto creativo. Da un lato, l'informatico è un "fisico" intellettuale con un pensiero algoritmico e matematico sviluppato, dall'altro lato, è un "poeta" creativo, portatore e promotore di idee. Come un artista, non ha un piano chiaro per dipingere un quadro, non può scomporre l'immagine in parti, poiché quest'ultima smetterebbe di esistere. È il padrone dei processi informatici, i quali sono di per sé astratti, intangibili, difficilmente misurabili, ma rapidi.

Modalità di costruzione di un'efficace gestione delle risorse umane nell'industria IT

Quindi, cosa deve sapere un HR specialist per costruire un'efficace gestione delle risorse umane in un contesto di diversità dei ruoli dell'industria IT.

In primo luogo, ogni specialista delle risorse umane di un'azienda IT deve avere una chiara comprensione della situazione specifica della propria azienda: chi fa cosa, chi e come è chiamato e, soprattutto, quale significato è attribuito a questi ruoli in un contesto produttivo specifico.

In secondo luogo, l'HR specialist deve avere una visione flessibile dei ruoli produttivi. Quindi, inizialmente deve formarsi un'idea ideale di essi che gli consenta di orientarsi. Successivamente, deve esserci un'immagine reale della produzione: dove e in cosa i ruoli si sovrappongono, si uniscono e quale percezione di questi ruoli hanno i manager di produzione. La complessità per lo specialista delle risorse umane sta nel combinare nella propria mente la realtà e l'ideale, senza cercare di forzare la ristrutturazione dei processi secondo una loro interpretazione ideale, ma aiutando la produzione a soddisfare le proprie esigenze di risorse.

In terzo luogo, è fondamentale avere una comprensione delle possibili traiettorie di sviluppo per determinati specialisti: in quali casi può essere efficace il reclutamento esterno e quando è meglio far crescere un dipendente all'interno del proprio team, fornendo opportunità di sviluppo, quali qualità dei candidati consentiranno loro di svilupparsi in una direzione specifica, quali caratteristiche non possono coesistere in una sola persona, ciò che è inizialmente importante per la scelta di una traiettoria di sviluppo.

In quarto luogo, torniamo al punto che l'IT è un settore di professionisti altamente qualificati, dove per un lavoro più efficace con il personale è 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 curriculum e nell'intervista, ma anche avere una buona conoscenza dell'ambiente universitario in termini di formazione dei professionisti: quali università formano il personale per l'azienda, quali corsi specifici all'interno delle università rispondono alle esigenze del personale e, cosa importante, chi ne è responsabile, chi dirige e gestisce la preparazione dei professionisti nelle università.

Pertanto, se si vuole sfatare intenzionalmente 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 pongono le basi per la percezione della futura professione. In altre parole, è necessario un’interazione costante con l'ambiente educativo, ad esempio utilizzando moderni formati di lavoro condiviso in centri di coworking, 'punti di ebollizione', partecipazione a intensivi educativi. Questo permetterà di abbattere le false rappresentazioni sulle aziende IT, aumenterà l'efficacia del lavoro con il personale e creerà condizioni per attività collaborative nella formazione di vari specialisti nel nostro settore.

Desidero ringraziare i colleghi che hanno partecipato alla preparazione e al mantenimento della rilevanza di questo articolo: Valentina Vershinina e Yuri Krupin.

Fonte: habr.com