Nell'attuale fase di sviluppo del software industriale, si possono osservare una varietà di ruoli di produzione. Il loro numero cresce, la classificazione diventa ogni anno più complicata e, naturalmente, i processi di selezione degli specialisti e di lavoro con le risorse umane stanno diventando sempre più complicati. La tecnologia dell'informazione (IT) è un'area con risorse di manodopera altamente qualificate e carenza di personale. Qui, il processo di sviluppo del personale e la necessità di un lavoro sistematico con il potenziale del personale sono molto più efficaci della selezione diretta utilizzando le risorse Internet.
L'articolo discute questioni rilevanti per gli specialisti delle risorse umane nelle aziende IT: relazioni di causa-effetto nell'evoluzione dei ruoli di produzione, le conseguenze di un'errata interpretazione del contenuto dei ruoli per il lavoro delle risorse umane in generale, nonché possibili opzioni per aumentare il efficienza nel reclutamento di specialisti.
Produzione IT per chi non lo sapesse
Who's who nell'IT è un argomento di discussione su varie piattaforme. Esiste da quando l'intero settore IT, cioè da quando sono apparse le prime società di sviluppo software sul mercato consumer all'inizio degli anni '90 del secolo scorso. E per lo stesso periodo non c'è stata una visione comune su questo tema, il che crea difficoltà e riduce l'efficienza del lavoro del personale. Proviamo a capirlo.
Per me, il tema dei ruoli di produzione nel settore IT è diventato rilevante e interessante da quando sono entrato a far parte dell'azienda IT. Ho passato molto tempo ed energia nervosa cercando di capire il processo di produzione. Questi costi hanno superato le mie aspettative e i costi di adattamento ai processi in altri settori: istruzione, produzione materiale, piccola impresa. Avevo capito che i processi sono complessi e insoliti, poiché, in generale, una persona è più adattata al mondo materiale che a quello virtuale. Ma c’era una resistenza intuitiva: sembrava che qui qualcosa non andasse, non dovrebbe essere così. Il processo di adattamento probabilmente ha richiesto un anno, il che, a mio avviso, è semplicemente cosmico. Di conseguenza, avevo una comprensione abbastanza chiara dei ruoli chiave nella produzione IT.
Attualmente continuo a lavorare su questo argomento, ma a un livello diverso. In qualità di capo del centro di sviluppo di un'azienda IT, devo spesso comunicare con studenti, docenti universitari, candidati, scolari e altri che desiderano partecipare alla creazione di un prodotto IT per promuovere l'employer brand nel mercato del lavoro di un nuovo territorio (Yaroslavl). Questa comunicazione non è facile a causa della scarsa consapevolezza degli interlocutori su come è organizzato il processo di sviluppo del software e, di conseguenza, della loro scarsa comprensione dell'argomento della conversazione. Dopo 5-10 minuti di dialogo, smetti di ricevere feedback e inizi a sentirti come uno straniero il cui discorso richiede una traduzione. Di norma, tra gli interlocutori c'è qualcuno che traccia una linea nel dialogo e dà voce a un mito popolare degli anni '90: "Comunque, tutti gli specialisti IT sono programmatori". Le origini del mito sono:
- Il settore IT si sta sviluppando rapidamente, in queste condizioni tutti i significati e i principi fondamentali sono in fase di formazione;
- È difficile esistere in condizioni di incertezza, quindi una persona cerca di rendersi più facile comprendere l'ignoto creando miti;
- una persona è più abituata alla percezione del mondo materiale che a quello virtuale, e quindi è difficile per lui definire concetti che vanno oltre la sua percezione.
Cercare di combattere questo mito a volte può sembrare come lottare contro i mulini a vento, poiché ci sono diversi aspetti del problema che devono essere affrontati. Uno specialista delle risorse umane deve, in primo luogo, avere un quadro chiaro dei ruoli di produzione in un'azienda IT in un'incarnazione ideale e reale, in secondo luogo, capire come e quando le risorse interne dell'azienda possono essere utilizzate in modo più efficace e, in terzo luogo, quali metodi reali saranno utilizzati contribuire ad aumentare la consapevolezza dei partecipanti al mercato del lavoro e contribuirà allo sviluppo dell’employer brand. Diamo un'occhiata più da vicino a questi aspetti.
Ciclo di vita del software come base per i ruoli di produzione
Non è un segreto che in generale tutti i ruoli di produzione in qualsiasi azienda IT abbiano come fonte il ciclo di vita del software. Pertanto, se ci poniamo il compito concettuale di concordare una percezione unificata di questo problema all'interno dell'intero settore IT, dobbiamo fare affidamento specificamente sul ciclo di vita del software come base semantica accettata e chiaramente compresa da tutti. La discussione di opzioni specifiche per implementare la questione dei ruoli di produzione si trova nel piano del nostro atteggiamento creativo nei confronti del ciclo di vita del software.
Vediamo quindi le fasi che comprende il ciclo di vita del software, utilizzando come esempio la metodologia RUP. Sono collegamenti abbastanza maturi in termini di contenuto e terminologia. Il processo di produzione inizia sempre e ovunque con la modellazione del business e la formazione dei requisiti e termina (condizionatamente, ovviamente) con la consultazione degli utenti e la modifica del software in base ai “desideri” degli utenti.
Se fai un'escursione storica fino alla fine del secolo scorso (come sai, questo era il periodo dell '"automazione delle isole"), puoi vedere che l'intero processo di creazione del software è stato eseguito da un programmatore-sviluppatore. Ecco le radici del mito secondo cui ogni specialista IT è un programmatore.
Con la crescente complessità dei processi produttivi, l'emergere di piattaforme integrate e la transizione verso una complessa automazione delle aree tematiche, con la reingegnerizzazione dei processi aziendali, diventa inevitabile l'emergere di ruoli specializzati legati alle fasi del ciclo di vita. Ecco come appaiono un analista, un tester e uno specialista del supporto tecnico.
Diversità di posizioni usando l'esempio del ruolo dell'analista
Un analista (ovvero un ingegnere analitico, ovvero un direttore, un metodologo, un analista aziendale, un analista di sistema, ecc.) Aiuta a "fare amicizia" con le attività aziendali e le tecnologie per la loro implementazione. Descrizione della dichiarazione del problema per lo sviluppatore: ecco come si può caratterizzare la funzione principale di un analista astratto. Agisce come collegamento tra il cliente e lo sviluppatore nei processi di formazione dei requisiti, analisi e progettazione del software. In condizioni di produzione reali, l'elenco delle funzioni dell'analista è determinato dal metodo di organizzazione della produzione, dalle qualifiche dello specialista e dalle specificità dell'area tematica modellata.
Alcuni analisti si trovano più vicini al cliente. Questi sono gli analisti aziendali (Business Analyst). Comprendono profondamente i processi aziendali dell'area tematica e sono essi stessi esperti in processi automatizzati. È molto importante avere tali specialisti nel personale di un'impresa, soprattutto quando si automatizzano aree tematiche metodologicamente complesse. In particolare, per noi, che automatizziamo il processo di bilancio dello Stato, è semplicemente necessario che tra gli analisti ci siano esperti in materia. Si tratta di dipendenti altamente qualificati con una buona formazione finanziaria ed economica ed esperienza di lavoro presso autorità finanziarie, preferibilmente nel ruolo di principali specialisti. L'esperienza non nel campo informatico, ma specificatamente nell'area tematica, è estremamente importante.
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 la possibilità di soddisfarli, preparare le specifiche tecniche e descrivere le dichiarazioni dei problemi. Comprendono non solo i processi aziendali, ma anche le tecnologie dell'informazione, hanno una buona conoscenza delle capacità del software fornito al cliente, hanno capacità di progettazione e, di conseguenza, capiscono come trasmettere al meglio gli interessi del cliente allo sviluppatore. Questi dipendenti devono avere una formazione nel campo delle TIC e una mentalità ingegneristica e tecnica, preferibilmente esperienza nel settore IT. Quando si selezionano tali specialisti, avere capacità di progettazione utilizzando strumenti moderni sarà un chiaro vantaggio.
Un altro tipo di analista sono gli scrittori tecnici. Sono impegnati nella documentazione nell'ambito dei processi di sviluppo del software, nella preparazione di manuali per l'utente e l'amministratore, nelle istruzioni tecnologiche, nei video di formazione, ecc. Il loro compito principale è essere in grado di trasmettere informazioni sul funzionamento del programma agli utenti e ad altre parti interessate, descrivere cose tecnicamente complesse in modo conciso e chiaro. Gli scrittori tecnici, per la maggior parte, hanno un'ottima padronanza della lingua russa e allo stesso tempo hanno una formazione tecnica e una mente analitica. Per tali specialisti, la massima importanza è la capacità di redigere testi tecnici chiari, competenti e dettagliati in conformità con gli standard, nonché la conoscenza e la padronanza degli strumenti di documentazione.
Pertanto, vediamo lo stesso ruolo (e, tra l'altro, posizione nella tabella del personale) - analista, ma nelle sue diverse incarnazioni applicative specifiche. La ricerca di specialisti per ciascuno di essi ha le sue caratteristiche. È importante sapere che questi tipi di analisti devono possedere competenze e conoscenze che spesso sono incompatibili in una sola persona. Uno è uno specialista in discipline umanistiche, incline al lavoro analitico con grandi volumi di documenti di testo, con capacità linguistiche e comunicative sviluppate, l'altro è un "tecnico" con pensiero ingegneristico e interessi nel campo IT.
Prendiamo dall'esterno o cresciamo?
Per un grande rappresentante del settore IT, l'efficacia della selezione diretta dalle risorse Internet diminuisce con la crescita dei progetti. Ciò accade, in particolare, per i seguenti motivi: è impossibile un rapido adattamento a processi complessi all'interno dell'azienda, la velocità di padronanza di strumenti specifici è inferiore alla velocità di sviluppo del progetto. Pertanto, è importante che uno specialista delle risorse umane sappia non solo chi cercare esternamente, ma anche come utilizzare le risorse interne dell'azienda, da chi e come sviluppare uno specialista.
Per gli analisti aziendali, l'esperienza di lavoro nell'ambito di processi reali nell'area tematica è molto importante, quindi reclutarli “dall'esterno” è più efficace che farli crescere all'interno dell'azienda. Allo stesso tempo, è importante che uno specialista delle risorse umane conosca l'elenco delle organizzazioni che possono essere fonti di questa risorsa umana e, durante la selezione, si concentri sulla ricerca di curriculum da esse.
Per coprire posti vacanti come analista di sistema e architetto software, invece, il processo di formazione all'interno dell'azienda è di grande importanza. Questi specialisti devono essere formati nell'attuale ambiente produttivo e nelle specificità di una particolare organizzazione. Gli analisti di sistema si sviluppano da analisti aziendali, scrittori tecnici e ingegneri del supporto tecnico. Architetti di software: da progettisti (System Designer) e sviluppatori di software (Software Developer) mentre acquisiscono esperienza e ampliano i propri orizzonti. Questa circostanza consente a uno specialista delle risorse umane di utilizzare in modo efficace le risorse interne dell'azienda.
Intersezione, integrazione ed evoluzione dei ruoli produttivi
C'è un'altra questione difficile dal punto di vista dell'implementazione nel processo di produzione: stabilire confini chiari tra i ruoli. A prima vista può sembrare che tutto sia ovvio: l'implementazione è stata completata, i documenti per la messa in esercizio commerciale del software sono stati firmati e tutto è stato consegnato al supporto tecnico. Esatto, però, spesso si verificano situazioni in cui il cliente, per abitudine, essendo a stretto contatto con l'analista e vedendolo come una “bacchetta magica”, continua a comunicare attivamente con lui, nonostante il sistema sia già stato implementato ed è in corso la fase di sostegno formale. Tuttavia, dal punto di vista del cliente, chi meglio e più velocemente dell’analista che ha impostato il compito insieme a lui risponderà alle domande sul lavoro con il sistema. E qui sorge la domanda sulla parziale duplicazione dei ruoli di ingegnere del supporto tecnico e analista. Col tempo tutto migliora, il cliente si abitua a comunicare con il servizio di supporto tecnico, ma all'inizio dell'utilizzo del software, una tale “transizione interna” non può sempre essere realizzata senza stress da entrambe le parti.
L'intersezione dei ruoli di analista e tecnico del supporto tecnico si verifica anche quando il flusso dei requisiti di sviluppo avviene come parte della fase di supporto. Ritornando al ciclo di vita del software, vediamo una discrepanza tra le reali condizioni di produzione e l'atteggiamento formale secondo cui l'analisi dei requisiti e la formulazione del problema possono essere eseguite esclusivamente da un analista. Uno specialista delle risorse umane, ovviamente, deve comprendere il quadro ideale dei ruoli all'interno del ciclo di vita del software; hanno confini chiari. Ma allo stesso tempo dovresti assolutamente tenere presente che l'intersezione è possibile. Quando si valutano le conoscenze e le competenze di un candidato, è necessario prestare attenzione alla presenza di esperienza correlata, ovvero quando si cercano ingegneri del supporto tecnico, potrebbero essere presi in considerazione candidati con esperienza di analista e viceversa.
Oltre alla sovrapposizione si verifica spesso un consolidamento dei ruoli produttivi. Ad esempio, un analista aziendale e uno scrittore tecnico possono esistere come un'unica persona. La presenza di un architetto del software (Software Architect) è obbligatoria nei grandi sviluppi industriali, mentre progetti molto piccoli possono fare a meno di questo ruolo: lì le funzioni dell'architetto sono svolte dagli sviluppatori (Software Developer).
I cambiamenti avvenuti nei periodi storici negli approcci e nelle tecnologie di sviluppo portano inevitabilmente al fatto che anche il ciclo di vita del software si evolve. A livello globale, ovviamente, le sue fasi principali rimangono invariate, ma stanno diventando più dettagliate. Ad esempio, con il passaggio alle soluzioni basate sul Web e la crescita delle capacità di configurazione remota, è emerso il ruolo di uno specialista di configurazione software. In una fase storica iniziale, questi erano implementatori, cioè ingegneri che trascorrevano la maggior parte del loro tempo lavorativo presso i luoghi di lavoro dei clienti. L'aumento del volume e della complessità del software ha portato all'emergere del ruolo di Software Architect. I requisiti per accelerare il rilascio delle versioni e migliorare la qualità del software hanno contribuito allo sviluppo di test automatizzati e all'emergere di un nuovo ruolo: ingegnere QA (ingegnere di controllo qualità), ecc. L'evoluzione dei ruoli in tutte le fasi del processo produttivo è significativamente correlata allo sviluppo di metodi, tecnologie e strumenti.
Finora abbiamo esaminato alcuni punti interessanti riguardanti la distribuzione dei ruoli di produzione all'interno di un'azienda di software nel contesto del ciclo di vita del software. Ovviamente si tratta di un punto di vista interno specifico per ciascuna azienda. Per tutti noi, in quanto partecipanti al mercato del lavoro del settore IT e responsabili della promozione dell'employer brand, il punto di vista esterno sarà particolarmente importante. E qui c'è un grosso problema non solo nel trovare il significato, ma anche nel trasmettere queste informazioni al pubblico di destinazione.
Cosa c'è che non va nello “zoo” delle posizioni IT?
La confusione nella mente degli specialisti HR, dei responsabili di produzione e la diversità degli approcci portano ad una varietà molto ampia, un vero e proprio “zoo” di posizioni IT. L'esperienza dei colloqui e dei contatti semplicemente professionali dimostra che spesso le persone non hanno una chiara comprensione del significato che dovrebbe derivare dai titoli di lavoro. Ad esempio, nella nostra organizzazione, le posizioni che includono il termine “ingegnere analitico” presuppongono che si tratti di un task setter. Tuttavia, si scopre che non è così ovunque: ci sono organizzazioni di sviluppo in cui un ingegnere analitico è l'implementatore. Una comprensione completamente diversa, sei d'accordo?
In primo luogo, lo “zoo” di posizioni IT riduce senza dubbio l’efficacia del reclutamento. Ogni datore di lavoro, nello sviluppo e nella promozione del proprio marchio, vuole trasmettere in forma concisa tutti i significati presenti nella sua produzione. E se lui stesso spesso non riesce a dire chiaramente chi è chi, è naturale che trasmetta incertezza all'ambiente esterno.
In secondo luogo, lo “zoo” di posizioni IT crea enormi problemi nella formazione e nello sviluppo del personale IT. Ogni azienda informatica seria, mirata alla formazione e allo sviluppo delle risorse umane, e non solo alla “mungitura” dei luoghi di lavoro, prima o poi incontra la necessità di interagire con le istituzioni educative. Per il personale IT altamente qualificato, questo è un segmento di università, e le migliori, almeno quelle nella classifica TOP-100.
Il problema dell'integrazione con le università quando si costruisce un processo continuo di formazione degli specialisti IT è circa la metà della mancanza di comprensione da parte delle università di chi è chi all'interno dell'azienda IT. Hanno una comprensione molto superficiale di questo. Di norma, le università hanno diverse specialità con la parola "informatica" nei loro nomi, e spesso accade che quando conducono una campagna di ammissione, si basino sulla tesi che tutte le specialità riguardano essenzialmente la stessa cosa. E sembra come se ci affidassimo al mito popolare secondo cui tutti gli specialisti IT sono programmatori.
L'esperienza della nostra stretta collaborazione con le università dimostra che la specialità "Informatica applicata (per settore)" ci fornisce personale per i dipartimenti di metodologia e supporto tecnico, ma non per lo sviluppo. Mentre “Informatica Fondamentale”, “Ingegneria del Software” preparano un'ottima risorsa umana per gli sviluppatori. Per non indirizzare inizialmente il richiedente lungo un percorso a lui inadatto, è necessario “dissipare la nebbia” che circonda la produzione informatica.
È possibile ricondurre tutto a un denominatore comune?
È possibile unificare i ruoli produttivi e arrivare ad una comprensione comune degli stessi all'interno e all'esterno dell'azienda?
Naturalmente, questo è possibile e necessario, perché l'esperienza collettiva accumulata da tutte le imprese di sviluppo dimostra la presenza di concetti comuni e unificanti per l'organizzazione del processo produttivo. Ciò è una conseguenza del fatto che esiste ancora un concetto interpretato in modo univoco del ciclo di vita del software, e i nuovi ruoli di produzione emergenti (DataScientist, QA-Engineer, MachineLearning Engineer, ecc.) sono una conseguenza del chiarimento e dello sviluppo del ciclo di vita del software in quanto tale, che avviene con il miglioramento delle tecnologie e degli strumenti, nonché con lo sviluppo e l'ampliamento delle attività aziendali.
Allo stesso tempo, è difficile unificare i ruoli produttivi, perché l’IT è uno dei settori più giovani e in più rapida crescita dell’economia. In un certo senso, questo è il caos da cui è emerso l'universo. Una struttura organizzativa chiara è qui impossibile e inappropriata, perché l'IT è un campo intellettuale, ma molto creativo. Da un lato, uno specialista IT è un “fisico” intellettuale con un pensiero algoritmico e matematico sviluppato, dall'altro è un “paroliere”-creatore, portatore e promotore di idee. Lui, proprio come l'artista, non ha un piano chiaro per la pittura, non può scomporre l'immagine in parti, poiché quest'ultima cesserà di esistere. È il sovrano dei processi informativi, che di per sé sono astratti, intangibili, difficili da misurare, ma rapidi.
Modi per creare un lavoro efficace del personale nella produzione IT
Quindi, cosa è importante sapere per uno specialista delle risorse umane per costruire un lavoro HR efficace nel contesto della diversità dei ruoli di produzione IT.
In primo luogo, qualsiasi specialista delle risorse umane presso un'azienda IT deve avere un'idea della situazione tipica della sua azienda: chi fa cosa, chi si chiama cosa e, soprattutto, qual è il significato di questi ruoli nelle condizioni di una particolare produzione.
In secondo luogo, il professionista delle risorse umane deve avere una comprensione flessibile dei ruoli di produzione. Cioè, inizialmente forma una comprensione ideale su di loro, che gli consente di capire tutto da solo. Poi ci deve essere un quadro reale della produzione: dove e in che modo i ruoli si intersecano e si combinano, quale percezione di questi ruoli esiste tra i responsabili di produzione. La difficoltà per uno specialista del personale è combinare nella mente le situazioni reali e ideali, non cercare di ricostruire forzatamente i processi per adattarli alla loro comprensione ideale, ma aiutare la produzione a soddisfare il bisogno di risorse.
In terzo luogo, dovresti assolutamente avere un'idea delle possibili traiettorie di sviluppo di alcuni specialisti: in quali casi la selezione esterna può essere efficace e quando è meglio far crescere un dipendente nella tua squadra, fornendogli opportunità di sviluppo, quali qualità dei candidati consentirà loro di svilupparsi in una direzione particolare, qualità che non possono essere compatibili in una persona, il che è inizialmente importante per scegliere una traiettoria di sviluppo.
In quarto luogo, torniamo alla tesi secondo cui l'IT è un campo di personale altamente qualificato, dove l'integrazione precoce con l'ambiente educativo universitario è inevitabile per un lavoro del personale più efficace. In questa situazione, ogni specialista delle risorse umane deve sviluppare non solo le capacità di ricerca diretta, lavorare con questionari e interviste, ma anche assicurarsi di navigare nell'ambiente della formazione universitaria degli specialisti: quali università preparano il personale per l'azienda, quali specialità all'interno di specifiche università coprire le esigenze del personale ed è importante chi c'è dietro, chi gestisce e forma gli specialisti nelle università.
Pertanto, se sfatamo intenzionalmente il mito secondo cui tutti gli specialisti IT sono programmatori, è necessario compiere una serie di passi in questa direzione e prestare particolare attenzione alle nostre università, dove vengono gettate le basi per la percezione della futura professione. In altre parole, abbiamo bisogno di un’interazione costante con l’ambiente educativo, ad esempio utilizzando il formato moderno di collaborazione nei centri di coworking, “punti di ebollizione” e partecipazione a corsi intensivi di formazione. Ciò contribuirà a distruggere le idee sbagliate sull'impresa IT, ad aumentare l'efficienza del lavoro del personale e a creare le condizioni per attività congiunte nella formazione di vari specialisti nel nostro settore.
Esprimo la mia gratitudine ai colleghi che hanno preso parte alla preparazione e al sostegno della rilevanza di questo articolo: Valentina Vershinina e Yuri Krupin.
Fonte: habr.com