In het huidige stadium van de ontwikkeling van industriële softwareontwikkeling kan men een verscheidenheid aan productierollen waarnemen. Hun aantal groeit, de classificatie wordt elk jaar ingewikkelder en natuurlijk worden de processen van het selecteren van specialisten en het werken met human resources steeds ingewikkelder. Informatietechnologie (IT) is een gebied met hooggekwalificeerde arbeidskrachten en personeelstekorten. Hier zijn het proces van personeelsontwikkeling en de behoefte aan systematisch werken met personeelspotentieel veel effectiever dan directe selectie met behulp van internetbronnen.
Het artikel bespreekt kwesties die relevant zijn voor HR-specialisten in IT-bedrijven: oorzaak-en-gevolgrelaties in de evolutie van productierollen, de gevolgen van een verkeerde interpretatie van de inhoud van rollen voor HR-werk in het algemeen, evenals mogelijke opties om de efficiëntie van het werven van specialisten.
IT-productie voor niet-ingewijden
Wie is wie in de IT is een onderwerp van discussie op verschillende platforms. Het bestaat al zo lang als de hele IT-industrie, dat wil zeggen sinds het verschijnen van de eerste softwareontwikkelingsbedrijven op de consumentenmarkt begin jaren negentig van de vorige eeuw. En gedurende dezelfde tijd was er geen gemeenschappelijke visie op deze kwestie, wat problemen veroorzaakt en de efficiëntie van personeelswerk vermindert. Laten we proberen het uit te zoeken.
Voor mij is het onderwerp productierollen in de IT-sector relevant en interessant geworden sinds ik bij het IT-bedrijf kwam. Ik heb veel tijd en nerveuze energie besteed aan het proberen het productieproces te begrijpen. Deze kosten overtroffen mijn verwachtingen en de kosten van aanpassing aan processen op andere gebieden: onderwijs, materiële productie, kleine bedrijven. Ik begreep dat de processen complex en ongebruikelijk zijn, omdat een persoon over het algemeen meer aangepast is aan de materiële wereld dan aan de virtuele. Maar er was intuïtieve weerstand: het leek erop dat hier iets mis was, het zou niet zo mogen zijn. Het aanpassingsproces heeft waarschijnlijk een jaar geduurd, wat naar mijn mening eenvoudigweg kosmisch is. Het resultaat was dat ik een vrij duidelijk inzicht kreeg in de sleutelrollen in de IT-productie.
Momenteel blijf ik aan dit onderwerp werken, maar op een ander niveau. Als hoofd van het ontwikkelingscentrum van een IT-bedrijf moet ik vaak communiceren met studenten, universiteitsdocenten, sollicitanten, schoolkinderen en anderen die willen deelnemen aan de creatie van een IT-product om het werkgeversmerk op de arbeidsmarkt te promoten van een nieuw gebied (Jaroslavl). Deze communicatie is niet gemakkelijk vanwege het lage bewustzijn van de gesprekspartners over hoe het softwareontwikkelingsproces is georganiseerd, en als gevolg daarvan hun gebrek aan begrip van het onderwerp van het gesprek. Na 5 tot 10 minuten dialoog krijg je geen feedback meer en begin je je een buitenlander te voelen wiens toespraak vertaling vereist. In de regel is er onder de gesprekspartners iemand die een grens trekt in de dialoog en een volksmythe uit de jaren 90 verwoordt: “Hoe dan ook, alle IT-specialisten zijn programmeurs.” De oorsprong van de mythe is:
- De IT-industrie ontwikkelt zich snel, onder deze omstandigheden bevinden alle fundamentele betekenissen en principes zich in het stadium van vorming;
- Het is moeilijk om te bestaan in omstandigheden van onzekerheid, dus probeert iemand het voor zichzelf gemakkelijker te maken het onbekende te begrijpen door mythen te creëren;
- een persoon is meer gewend aan de perceptie van de materiële wereld dan aan de virtuele, en daarom is het moeilijk voor hem om concepten te definiëren die buiten zijn perceptie liggen.
Proberen deze mythe te bestrijden kan soms aanvoelen als het aanvallen van windmolens, omdat er verschillende aspecten van het probleem zijn die moeten worden aangepakt. Een HR-specialist moet in de eerste plaats een duidelijk beeld hebben van de productierollen in een IT-bedrijf in een ideale en reële vorm, in de tweede plaats begrijpen hoe en wanneer de interne middelen van het bedrijf het meest effectief kunnen worden gebruikt, en in de derde plaats welke echte methoden daarvoor nodig zijn. helpen het bewustzijn van deelnemers op de arbeidsmarkt te vergroten en zullen bijdragen aan de ontwikkeling van het werkgeversmerk. Laten we deze aspecten eens nader bekijken.
Softwarelevenscyclus als basis voor productierollen
Het is geen geheim dat over het algemeen alle productierollen in elk IT-bedrijf de softwarelevenscyclus als bron hebben. Als we ons daarom de conceptuele taak stellen om overeenstemming te bereiken over een uniforme perceptie van dit onderwerp binnen de hele IT-industrie, moeten we specifiek vertrouwen op de levenscyclus van software als een semantische basis die door iedereen wordt geaccepteerd en duidelijk begrepen. De discussie over specifieke opties voor het implementeren van de kwestie van productierollen ligt op het vlak van onze creatieve houding ten opzichte van de softwarelevenscyclus.
Laten we dus eens kijken naar de fasen die de softwarelevenscyclus omvat, waarbij we de RUP-methodologie als voorbeeld gebruiken. Het zijn redelijk volwassen links qua inhoud en terminologie. Het productieproces begint altijd en overal met businessmodellering en het formuleren van eisen, en eindigt (uiteraard voorwaardelijk) met het raadplegen van gebruikers en het aanpassen van de software op basis van de ‘wensen’ van gebruikers.
Als je een historische excursie maakt naar het einde van de vorige eeuw (zoals je weet was dit de periode van ‘eilandautomatisering’), kun je zien dat het hele proces van het maken van software werd uitgevoerd door een programmeur-ontwikkelaar. Dit zijn de wortels van de mythe dat elke IT-specialist een programmeur is.
Met de toenemende complexiteit van productieprocessen, de opkomst van geïntegreerde platforms en de overgang naar complexe automatisering van vakgebieden, met de re-engineering van bedrijfsprocessen, wordt de opkomst van gespecialiseerde rollen die verband houden met levenscyclusfasen onvermijdelijk. Zo verschijnen een analist, tester en specialist voor technische ondersteuning.
Diversiteit van posities met behulp van het voorbeeld van de rol van analist
Een analist (ook bekend als analytisch ingenieur, ook wel directeur, methodoloog, bedrijfsanalist, systeemanalist, enz.) helpt 'vrienden te maken' met zakelijke taken en technologieën voor de implementatie ervan. Beschrijving van de probleemstelling voor de ontwikkelaar - zo kan men de hoofdfunctie van een abstracte analist karakteriseren. Hij fungeert als schakel tussen opdrachtgever en ontwikkelaar in de processen van eisenvorming, analyse en softwareontwerp. In echte productieomstandigheden wordt de lijst met analistenfuncties bepaald door de methode voor het organiseren van de productie, de kwalificaties van de specialist en de specifieke kenmerken van het gemodelleerde vakgebied.
Sommige analisten zitten dichter bij de klant. Dit zijn bedrijfsanalisten (Business Analyst). Zij begrijpen de bedrijfsprocessen van het vakgebied diepgaand en zijn zelf experts op het gebied van geautomatiseerde processen. Het is erg belangrijk om dergelijke specialisten in het personeel van een onderneming te hebben, vooral bij het automatiseren van methodologisch complexe vakgebieden. In het bijzonder is het voor ons, als automatiseerders van het staatsbegrotingsproces, eenvoudigweg noodzakelijk dat er onder de analisten vakdeskundigen zijn. Het gaat om hoogopgeleide medewerkers met een goede financieel-economische opleiding en ervaring binnen de financiële overheid, bij voorkeur in de rol van leidende specialisten. Ervaring niet op IT-gebied, maar specifiek op het vakgebied, is van groot belang.
Het andere deel van de analisten staat dichter bij de ontwikkelaars. Dit zijn systeemanalisten (Systeemanalist). Hun hoofdtaak is het identificeren, systematiseren en analyseren van de eisen van de klant om te zien of ze daaraan kunnen voldoen, het opstellen van technische specificaties en het beschrijven van probleemstellingen. Ze begrijpen niet alleen bedrijfsprocessen, maar ook informatietechnologieën, hebben een goed inzicht in de mogelijkheden van de aan de klant geleverde software, beschikken over ontwerpvaardigheden en begrijpen daarom hoe ze de belangen van de klant het beste op de ontwikkelaar kunnen overbrengen. Deze medewerkers dienen een opleiding op het gebied van ICT en een bouwkundige en technische mentaliteit te hebben, bij voorkeur ervaring in de IT. Bij het selecteren van dergelijke specialisten zal het hebben van ontwerpvaardigheden met behulp van moderne tools een duidelijk voordeel zijn.
Een ander type analist zijn technische schrijvers. Ze houden zich bezig met documentatie als onderdeel van softwareontwikkelingsprocessen, het opstellen van gebruikers- en beheerdershandleidingen, technologische instructies, trainingsvideo's, enz. Hun belangrijkste taak is om informatie over de werking van het programma aan gebruikers en andere geïnteresseerden over te kunnen brengen, om technisch complexe zaken beknopt en duidelijk te beschrijven. Technische schrijvers hebben voor het grootste deel een uitstekende beheersing van de Russische taal en hebben tegelijkertijd een technische opleiding en een analytische geest. Voor dergelijke specialisten zijn de vaardigheden van het samenstellen van duidelijke, competente en gedetailleerde technische teksten in overeenstemming met normen, evenals kennis en beheersing van documentatietools van het grootste belang.
We zien dus dezelfde rol (en trouwens positie in de personeelstabel) - analist, maar in zijn verschillende specifieke applicatie-incarnaties. De zoektocht naar specialisten voor elk van hen heeft zijn eigen kenmerken. Het is belangrijk om te weten dat dit soort analisten over vaardigheden en kennis moeten beschikken die vaak onverenigbaar zijn in één persoon. De een is een specialist in de geesteswetenschappen, gevoelig voor analytisch werk met grote hoeveelheden tekstdocumenten, met ontwikkelde spraak- en communicatievaardigheden, de ander is een 'techneut' met technisch denken en interesses op IT-gebied.
Nemen we van buitenaf of groeien we?
Voor een grote vertegenwoordiger van de IT-industrie neemt de effectiviteit van directe selectie uit internetbronnen af naarmate projecten groeien. Dit gebeurt met name om de volgende redenen: snelle aanpassing aan complexe processen binnen het bedrijf is onmogelijk, de snelheid van het beheersen van specifieke tools is lager dan de snelheid van projectontwikkeling. Daarom is het belangrijk dat een HR-specialist niet alleen weet naar wie hij extern moet zoeken, maar ook hoe hij de interne middelen van het bedrijf moet gebruiken, van wie en hoe hij een specialist kan ontwikkelen.
Voor bedrijfsanalisten is ervaring met het werken binnen echte processen in het vakgebied erg belangrijk, dus het werven van hen “van buitenaf” is effectiever dan het laten groeien binnen het bedrijf. Tegelijkertijd is het belangrijk dat een HR-specialist de lijst kent van organisaties die een bron van dit personeel kunnen zijn, en zich bij het selecteren concentreert op het zoeken naar cv's van hen.
Voor het vervullen van vacatures als systeemanalist en softwarearchitect is daarentegen het opleidingsproces binnen het bedrijf van groot belang. Deze specialisten moeten gevormd worden in de huidige productieomgeving en de specifieke kenmerken van een bepaalde organisatie. Systeemanalisten ontwikkelen zich van bedrijfsanalisten, technische schrijvers en technische ondersteuningsingenieurs. Software Architecten - van ontwerpers (Systeemontwerper) en softwareontwikkelaars (Softwareontwikkelaar) terwijl ze ervaring opdoen en hun horizon verbreden. Deze omstandigheid stelt de HR-specialist in staat de interne middelen van het bedrijf effectief te gebruiken.
Snijpunt, integratie en evolutie van productierollen
Er is nog een moeilijk probleem vanuit het oogpunt van implementatie in het productieproces: het vaststellen van duidelijke grenzen tussen rollen. Op het eerste gezicht lijkt alles vanzelfsprekend: de implementatie is voltooid, de documenten voor het commercieel in gebruik nemen van de software zijn ondertekend en alles is overgedragen aan de technische ondersteuning. Dat klopt, maar er doen zich vaak situaties voor waarin de cliënt, uit gewoonte, in nauw contact staat met de analist en hem als een "toverstaf" ziet, actief met hem blijft communiceren, ondanks het feit dat het systeem al is geïmplementeerd en de formele ondersteuningsfase is aan de gang. Maar wie, vanuit het perspectief van de klant, beter en sneller dan de analist die samen met hem de taak opstelde, zal vragen over het werken met het systeem beantwoorden. En hier rijst de vraag over de gedeeltelijke duplicatie van de rollen van een technische ondersteuningsingenieur en een analist. Na verloop van tijd wordt alles beter, de klant raakt gewend aan de communicatie met de technische ondersteuningsdienst, maar helemaal aan het begin van het gebruik van de software kan een dergelijke “interne transitie” niet altijd worden bereikt zonder stress aan beide kanten.
Het snijpunt van de rollen van analist en technisch ondersteuningsingenieur ontstaat ook wanneer de stroom van ontwikkelingsvereisten plaatsvindt als onderdeel van de ondersteuningsfase. Terugkerend naar de levenscyclus van software zien we een discrepantie tussen werkelijke productieomstandigheden en de formele houding dat analyse van vereisten en probleemformulering uitsluitend door een analist kan worden uitgevoerd. Een HR-specialist moet natuurlijk het ideale beeld begrijpen van rollen binnen de softwarelevenscyclus; ze hebben duidelijke grenzen. Maar tegelijkertijd moet je er zeker rekening mee houden dat kruising mogelijk is. Bij het beoordelen van de kennis en vaardigheden van een sollicitant moet u letten op de aanwezigheid van gerelateerde ervaring, dat wil zeggen dat bij het zoeken naar technische ondersteuningsingenieurs kandidaten met analistenervaring heel goed in aanmerking kunnen komen en omgekeerd.
Naast overlap is er vaak sprake van consolidatie van productierollen. Een bedrijfsanalist en een technisch schrijver kunnen bijvoorbeeld als één persoon bestaan. De aanwezigheid van een software-architect (Software Architect) is verplicht bij grote industriële ontwikkeling, terwijl zeer kleine projecten deze rol kunnen missen: daar worden de functies van de architect uitgevoerd door ontwikkelaars (Software Developer).
Veranderingen in historische perioden in ontwikkelingsbenaderingen en technologieën leiden onvermijdelijk tot het feit dat de levenscyclus van software ook evolueert. Globaal gezien blijven de hoofdfasen uiteraard ongewijzigd, maar ze worden steeds gedetailleerder. Met de transitie naar webgebaseerde oplossingen en de groei van de mogelijkheden voor configuratie op afstand is bijvoorbeeld de rol van een softwareconfiguratiespecialist ontstaan. In een vroeg historisch stadium waren dit uitvoerders, dat wil zeggen ingenieurs die het grootste deel van hun werktijd op de werkplek van klanten doorbrachten. Het toegenomen volume en de complexiteit van software heeft geleid tot de opkomst van de rol van Software Architect. Vereisten voor het versnellen van versiereleases en het verbeteren van de softwarekwaliteit hebben bijgedragen aan de ontwikkeling van geautomatiseerd testen en de opkomst van een nieuwe rol: QA-ingenieur (Quality Assurance Engineer), enz. De evolutie van rollen in alle stadia van het productieproces houdt in belangrijke mate verband met de ontwikkeling van methoden, technologieën en hulpmiddelen.
Tot nu toe hebben we gekeken naar enkele interessante punten met betrekking tot de verdeling van productierollen binnen een softwarebedrijf in de context van de softwarelevenscyclus. Uiteraard is dit een insidervisie die specifiek is voor elk bedrijf. Voor ons allemaal, als deelnemers aan de arbeidsmarkt van de IT-industrie en degenen die verantwoordelijk zijn voor het promoten van het werkgeversmerk, zal de blik van buitenaf bijzonder belangrijk zijn. En hier is er niet alleen een groot probleem bij het vinden van betekenis, maar ook bij het overbrengen van deze informatie naar de doelgroep.
Wat is er mis met de ‘dierentuin’ van IT-functies?
Verwarring in de hoofden van HR-specialisten, productiemanagers en de diversiteit aan benaderingen leiden tot een zeer grote verscheidenheid, een ware ‘dierentuin’ aan IT-functies. De ervaring met sollicitatiegesprekken en louter professionele contacten leert dat mensen vaak geen duidelijk inzicht hebben in de betekenis die uit functietitels zou moeten voortvloeien. In onze organisatie gaan functies waarin de term 'analytisch ingenieur' voorkomt er bijvoorbeeld van uit dat dit een taakbepaler is. Dit blijkt echter niet overal het geval te zijn: er zijn ontwikkelingsorganisaties waar een analytisch ingenieur een uitvoerder is. Een heel ander begrip, bent u het daar mee eens?
Ten eerste vermindert de ‘dierentuin’ van IT-functies ongetwijfeld de effectiviteit van rekrutering. Elke werkgever wil bij het ontwikkelen en promoten van zijn merk in een beknopte vorm alle betekenissen overbrengen die in zijn productie bestaan. En als hij zelf vaak niet duidelijk kan zeggen wie wie is, is het normaal dat hij onzekerheid naar de externe omgeving zal uitzenden.
Ten tweede zorgt de ‘dierentuin’ van IT-functies voor enorme problemen bij de opleiding en ontwikkeling van IT-personeel. Elk serieus IT-bedrijf, gericht op het vormen en ontwikkelen van menselijke hulpbronnen, en niet alleen op het 'melken' van werkplekken, wordt vroeg of laat geconfronteerd met de noodzaak om met onderwijsinstellingen te communiceren. Voor hooggekwalificeerd IT-personeel is dit een segment van universiteiten, en bovendien de beste, tenminste die in de TOP-100-ranglijst.
Het probleem van de integratie met universiteiten bij het opbouwen van een continu proces van het opleiden van IT-specialisten is ongeveer de helft van het gebrek aan inzicht bij universiteiten over wie wie is binnen het IT-bedrijf. Zij hebben hier een zeer oppervlakkig inzicht in. In de regel hebben universiteiten verschillende specialismen met het woord ‘computerwetenschappen’ in hun naam, en het komt vaak voor dat ze bij het voeren van een toelatingscampagne uitgaan van de stelling dat alle specialismen in wezen over hetzelfde gaan. En het lijkt hetzelfde alsof we vertrouwen op de populaire mythe dat alle IT-specialisten programmeurs zijn.
Uit de ervaring van onze nauwe samenwerking met universiteiten blijkt dat het specialisme “Toegepaste Informatica (per sector)” ons wel personeel levert voor de afdelingen methodologie en technische ondersteuning, maar niet voor ontwikkeling. Terwijl “Fundamentele Informatica” en “Software Engineering” een uitstekend personeelsbestand vormen voor ontwikkelaars. Om de sollicitant in eerste instantie niet op een pad te sturen dat niet bij hem past, is het noodzakelijk om “de mist te verdrijven” die rond de IT-productie hangt.
Is het mogelijk om alles onder één noemer te brengen?
Is het mogelijk om productierollen te verenigen en tot een gemeenschappelijk begrip daarvan te komen, zowel binnen als buiten het bedrijf?
Natuurlijk is dit mogelijk en noodzakelijk, omdat de verzamelde collectieve ervaring van alle ontwikkelingsbedrijven de aanwezigheid aantoont van gemeenschappelijke, verenigende concepten voor het organiseren van het productieproces. Dit is een gevolg van het feit dat er nog steeds een uniek geïnterpreteerd concept van de softwarelevenscyclus bestaat, en dat de nieuw opkomende productierollen (DataScientist, QA-Engineer, MachineLearning Engineer, enz.) een gevolg zijn van de verduidelijking en ontwikkeling van de de levenscyclus van software als zodanig, die plaatsvindt met de verbetering van technologieën en hulpmiddelen, evenals de ontwikkeling en uitbreiding van zakelijke taken.
Tegelijkertijd is het moeilijk om productierollen te verenigen, omdat IT een van de jongste en snelst groeiende sectoren van de economie is. In zekere zin is dit de chaos waaruit het universum is ontstaan. Een duidelijke organisatiestructuur is hier onmogelijk en ongepast, omdat IT een intellectueel, maar zeer creatief vakgebied is. Aan de ene kant is een IT-specialist een ‘natuurkundige’-intellectueel met ontwikkeld algoritmisch en wiskundig denken, aan de andere kant is hij een ‘tekstschrijver’-schepper, drager en promotor van ideeën. Hij heeft, net als de kunstenaar, geen duidelijk plan voor het schilderen; hij kan het beeld niet in delen ontbinden, aangezien deze ophouden te bestaan. Hij is de heerser van informatieprocessen, die op zichzelf abstract, ongrijpbaar, moeilijk te meten, maar snel zijn.
Manieren om effectief personeelswerk in de IT-productie op te bouwen
Wat is dus belangrijk voor een HR-specialist om te weten om effectief HR-werk op te bouwen in de context van de diversiteit van IT-productierollen.
Ten eerste moet elke HR-specialist bij een IT-bedrijf een idee hebben van de situatie die specifiek kenmerkend is voor zijn onderneming: wie doet wat, wie wordt hoe genoemd, en vooral: wat is de betekenis van deze rollen in de omstandigheden van een bepaalde productie.
Ten tweede moet de HR-professional een flexibel begrip hebben van productierollen. Dat wil zeggen, in eerste instantie vormt hij een ideaal begrip van hen, waardoor hij alles zelf kan uitzoeken. Dan moet er een reëel beeld van de productie zijn: waar en op welke manieren de rollen elkaar kruisen en combineren, welke perceptie van deze rollen bestaat onder productiemanagers. De moeilijkheid voor een personeelsspecialist is om de werkelijke en ideale situaties in de geest te combineren, niet om te proberen processen met geweld opnieuw op te bouwen om aan hun ideale begrip te voldoen, maar om de productie te helpen tegemoet te komen aan de behoefte aan middelen.
Ten derde moet je zeker een idee hebben van de mogelijke ontwikkelingstrajecten van bepaalde specialisten: in welke gevallen kan externe selectie effectief zijn, en wanneer is het beter om een medewerker in je team te laten groeien, hem ontwikkelingsmogelijkheden te bieden, welke kwaliteiten van kandidaten zal hen in staat stellen zich in een bepaalde richting te ontwikkelen, welke kwaliteiten niet in één persoon verenigbaar zijn, wat in eerste instantie belangrijk is bij het kiezen van een ontwikkelingstraject.
Laten we in de vierde plaats terugkeren naar de stelling dat IT een terrein is van hooggekwalificeerd personeel, waar vroegtijdige integratie met de universitaire onderwijsomgeving onvermijdelijk is voor effectiever personeelswerk. In deze situatie moet elke HR-specialist niet alleen de vaardigheden ontwikkelen van direct zoeken, werken met vragenlijsten en interviewen, maar ook zeker omgaan met de omgeving van universitaire opleiding van specialisten: welke universiteiten bereiden personeel voor op het bedrijf, welke specialiteiten binnen specifieke universiteiten personeelsbehoeften dekken, en wat Het is belangrijk wie hierachter zit, wie specialisten aan universiteiten leidt en opleidt.
Als we dus doelbewust de mythe ontkrachten dat alle IT-specialisten programmeurs zijn, is het noodzakelijk om een aantal stappen in deze richting te zetten en speciale aandacht te besteden aan onze universiteiten, waar de basis wordt gelegd voor de perceptie van het toekomstige beroep. Met andere woorden, we hebben constante interactie nodig met de onderwijsomgeving, bijvoorbeeld door gebruik te maken van het moderne formaat van samenwerking in coworking-centra, ‘kookpunten’ en deelname aan onderwijsintensives. Dit zal helpen misvattingen over de IT-onderneming te vernietigen, de efficiëntie van personeelswerk te vergroten en voorwaarden te scheppen voor gezamenlijke activiteiten bij de opleiding van verschillende specialisten in onze branche.
Ik spreek mijn dank uit aan de collega's die hebben deelgenomen aan de voorbereiding en ondersteuning van de relevantie van dit artikel: Valentina Vershinina en Yuri Krupin.
Bron: www.habr.com