
In de huidige fase van de ontwikkeling van industriële software kunnen we een grote verscheidenheid aan productierollen waarnemen. Hun aantal groeit, de classificatie wordt elk jaar complexer en uiteraard worden ook de processen voor het selecteren van specialisten en de samenwerking met personeelszaken complexer. De informatietechnologie (IT) is een sector met een tekort aan hooggekwalificeerde arbeidskrachten en personeel. Hierbij kan het proces van personeelsontwikkeling en de noodzaak van systematisch werken met personeelsbronnen veel effectiever zijn dan directe selectie met behulp van internetbronnen.
In het artikel worden kwesties besproken die relevant zijn voor HR-specialisten bij IT-bedrijven: oorzaak-gevolgrelaties in de evolutie van productiefuncties, de gevolgen van verkeerde interpretaties van de inhoud van functies voor HR-werkzaamheden in het algemeen en mogelijke opties om de efficiëntie van het werven van specialisten te vergroten.
IT-productie voor de niet-ingewijden
Wie is wie in de IT? Dat is een onderwerp van discussie op verschillende platforms. Het bestaat al net zo lang als de hele IT-industrie, dat wil zeggen sinds de komst van de eerste softwareontwikkelingsbedrijven op de consumentenmarkt, begin jaren negentig van de vorige eeuw. Bovendien is er al die tijd geen eenduidige visie op dit onderwerp, wat problemen oplevert en de effectiviteit van het personeelswerk vermindert. Laten we proberen het uit te zoeken.
Voor mij is het onderwerp productiefuncties in de IT-sector relevant en interessant geworden sinds ik bij het IT-bedrijf ben begonnen. Ik heb veel tijd en energie gestoken in het proberen te begrijpen van het productieproces. Deze kosten overtroffen mijn verwachtingen en de kosten voor aanpassing aan processen op andere gebieden: onderwijs, materiaalproductie, kleinbedrijf. Ik besefte dat de processen complex en ongewoon waren, omdat een mens over het algemeen beter is aangepast aan de materiële wereld dan aan de virtuele. Maar er was een intuïtieve weerstand: het leek alsof er iets niet klopte, dat het niet zo hoorde te zijn. Het aanpassingsproces duurde waarschijnlijk een jaar, wat naar mijn mening een kosmische tijd is. Hierdoor heb ik een redelijk helder beeld van de sleutelrollen in de IT-productie.
Momenteel werk ik nog steeds aan dit onderwerp, maar op een ander niveau. Als hoofd van het ontwikkelingscentrum van een IT-bedrijf moet ik vaak communiceren met studenten, hoogleraren, sollicitanten, schoolkinderen en anderen die willen meewerken aan de creatie van een IT-product om het werkgeversmerk te promoten op de arbeidsmarkt van een nieuw gebied (Jaroslavl). Deze communicatie verloopt moeizaam omdat de gesprekspartners niet goed op de hoogte zijn van de organisatie van het softwareontwikkelingsproces en daardoor het onderwerp van het gesprek niet goed begrijpen. Na 5 tot 10 minuten dialoog krijgt u geen feedback meer en begint u zich te voelen als een buitenlander wiens toespraak vertaald moet worden. Meestal is er wel iemand onder de gesprekspartners die een grens trekt in de dialoog en een populaire mythe uit de jaren negentig verkondigt: “Toch zijn alle IT-specialisten programmeurs.” De bronnen van de mythe zijn als volgt:
- De IT-industrie ontwikkelt zich snel en onder deze omstandigheden bevinden alle fundamentele betekenissen en principes zich in een stadium van vorming;
- Het is moeilijk om te bestaan in omstandigheden van onzekerheid. Daarom proberen mensen het voor zichzelf gemakkelijker te maken om het onbekende te begrijpen door mythes te creëren;
- Omdat de mens gewend is de materiële wereld waar te nemen, is hij meer gewend de virtuele wereld waar te nemen. Daarom is het voor hem moeilijk om concepten te definiëren die buiten zijn waarnemingsvermogen liggen.
Het bestrijden van deze mythe kan soms voelen als vechten tegen windmolens. Er zijn namelijk meerdere aspecten van het probleem die aangepakt moeten worden. Een HR-specialist moet ten eerste een helder beeld hebben van de productiefuncties in een IT-bedrijf in een ideale en reële belichaming, ten tweede moet hij begrijpen hoe en wanneer de interne middelen van het bedrijf het meest effectief kunnen worden ingezet en ten derde moet hij weten welke reële methoden kunnen helpen om de bekendheid van arbeidsmarktdeelnemers te vergroten en bij te dragen aan de ontwikkeling van het werkgeversmerk. Laten we deze aspecten eens nader bekijken.
Softwarelevenscyclus als basis voor productierollen
Het is geen geheim dat in principe alle productiefuncties in elk IT-bedrijf de softwarelevenscyclus als bron hebben. Als we een conceptuele taak stellen om binnen de gehele IT-sector tot een uniforme visie op dit probleem te komen, moeten we uitgaan van de softwarelevenscyclus als een geaccepteerde en duidelijk begrepen semantische basis voor iedereen. Het bespreken van specifieke opties voor het implementeren van de kwestie van productierollen ligt in het vlak van onze creatieve benadering van de softwarelevenscyclus.
Laten we eens kijken naar de fasen in de levenscyclus van software, waarbij we de RUP-methodologie als voorbeeld gebruiken. Het zijn redelijk goed geformuleerde links wat betreft inhoud en terminologie. Het productieproces begint altijd en overal met het opstellen van het bedrijfsmodel en het formuleren van de eisen, en eindigt (onder voorwaarden natuurlijk) met gebruikersconsultatie en softwareaanpassingen op basis van de ‘wensen’ van de gebruiker.

Als we een historische excursie maken naar het einde van de vorige eeuw (zoals bekend was dit de periode van de ‘eilandautomatisering’), dan zien we dat het hele proces van softwarecreatie werd uitgevoerd door een programmeur-ontwikkelaar. Hieruit ontstaat de mythe dat elke IT-specialist een programmeur is.
Naarmate productieprocessen complexer worden, er geïntegreerde platformen ontstaan en er een transitie plaatsvindt naar uitgebreide automatisering van vakgebieden, en bedrijfsprocessen opnieuw worden vormgegeven, ontstaan er onvermijdelijk gespecialiseerde rollen die gekoppeld zijn aan levenscyclusfasen. Zo zien een analist, een tester en een specialist in technische ondersteuning eruit.
Diversiteit van banen: een analistenrol als voorbeeld
Een analist (ook wel bekend als een ingenieur-analist, een directeur, methodoloog, bedrijfsanalist, systeemanalist, enz.) helpt zakelijke taken en technologieën voor hun implementatie 'vrienden te maken'. Beschrijving van de taakstelling voor de ontwikkelaar – zo kan de hoofdfunctie van een abstracte analist worden gekarakteriseerd. Hij fungeert als schakel tussen de opdrachtgever en de ontwikkelaar in de processen van eisenformulering, analyse en softwareontwerp. Onder reële productieomstandigheden wordt de lijst met analytische functies bepaald door de manier waarop de productie is georganiseerd, de kwalificaties van de specialist en de specifieke kenmerken van het vakgebied dat wordt gemodelleerd.

Sommige analisten werken dichter bij de klant. Dit zijn bedrijfsanalisten (Business Analyst). Ze hebben diepgaand inzicht in de bedrijfsprocessen in het vakgebied en zijn zelf experts op het gebied van geautomatiseerde processen. Het is van groot belang om dergelijke specialisten in dienst te hebben bij een onderneming, vooral bij het automatiseren van methodologisch complexe vakgebieden. Voor ons, als automatiseerders van het staatsbegrotingsproces, is het met name noodzakelijk dat er onder de analisten inhoudelijke deskundigen zitten. Het gaat om hooggekwalificeerde medewerkers met een goede financiële en economische opleiding en werkervaring bij financiële instellingen, bij voorkeur in de rol van leidinggevende specialist. Ervaring in het vakgebied, en niet in de IT-sector, is van groot belang.
Een ander deel van de analisten staat dichter bij de ontwikkelaars. Dit zijn systeemanalisten (System Analyst). Hun belangrijkste taak is het identificeren, systematiseren en analyseren van de eisen van de klant om aan de mogelijkheden te voldoen, technische specificaties op te stellen en de probleemstelling te beschrijven. Zij begrijpen niet alleen bedrijfsprocessen, maar ook informatietechnologieën, hebben een goed inzicht in de mogelijkheden van de software die aan de klant wordt geleverd, beschikken over ontwerpvaardigheden en begrijpen dienovereenkomstig hoe de belangen van de klant het beste aan de ontwikkelaar kunnen worden overgebracht. Deze medewerkers dienen een opleiding in de ICT-richting te hebben en een technische mindset, bij voorkeur met ervaring in de ICT. Bij het selecteren van dergelijke specialisten zal de aanwezigheid van ontwerpvaardigheden met behulp van moderne hulpmiddelen een duidelijk voordeel zijn.

Een ander type analist is een technisch schrijver. Zij houden zich bezig met de documentatie binnen de softwareontwikkelingsprocessen en bereiden handleidingen voor gebruikers en beheerders, procesinstructies, trainingsvideo's, enzovoort voor. Hun belangrijkste taak is om informatie over de werking van het programma over te brengen aan gebruikers en andere belanghebbenden en om technisch complexe zaken beknopt en duidelijk te beschrijven. Technisch schrijvers beheersen over het algemeen de Russische taal uitstekend, hebben een technische opleiding en een analytische geest. Voor dergelijke specialisten zijn de belangrijkste vaardigheden het vermogen om duidelijke, deskundige en gedetailleerde technische teksten te schrijven die voldoen aan de normen, evenals kennis en beheersing van documentatiehulpmiddelen.
We zien dus dezelfde rol (en trouwens ook dezelfde positie in de personeelsbezetting) – analist, maar dan in verschillende specifieke toegepaste vormen. De zoektocht naar specialisten voor elk van deze vakgebieden heeft zijn eigen kenmerken. Het is belangrijk om te weten dat dit soort analisten vaak over onverenigbare vaardigheden en kennis in één persoon beschikken. De een is een student geesteswetenschappen, die geneigd is om analytisch te werken met grote hoeveelheden tekstdocumenten en over ontwikkelde spraak- en communicatievaardigheden beschikt. De ander is een 'techneut' met een technische mindset en interesse in het IT-veld.
Moeten we van buitenaf nemen of zelf groeien?
Voor een belangrijke 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 onder de knie krijgen van specifieke tools ligt lager dan de snelheid van de projectontwikkeling. Daarom is het voor een HR-specialist belangrijk om niet alleen te weten wie hij van buitenaf moet zoeken, maar ook hoe hij de interne middelen van het bedrijf moet gebruiken, bij wie en hoe hij een specialist kan opleiden.
Voor bedrijfsanalisten is ervaring met het werken binnen echte processen binnen het vakgebied erg belangrijk, dus hun selectie ‘van buitenaf’ is effectiever dan hen binnen het bedrijf te laten groeien. Tegelijkertijd is het belangrijk dat de HR-specialist op de hoogte is van de lijst met organisaties die deze menselijke hulpbronnen kunnen leveren en dat hij zich bij zijn selectie richt op het vinden van cv's van deze organisaties.
Om vacatures als systeemanalist en softwarearchitect in te vullen, is het opleiden van personeel binnen het bedrijf juist van groot belang. Deze specialisten moeten worden opgeleid in de omstandigheden van de huidige productieomgeving en de specifieke kenmerken van een specifieke organisatie. Systeemanalisten zijn afkomstig van bedrijfsanalisten, technische schrijvers en technische ondersteuningstechnici. Softwarearchitecten - van ontwerpers (systeemontwerper) tot softwareontwikkelaars (softwareontwikkelaar) naarmate ze ervaring opdoen en hun horizon verbreden. Deze omstandigheid stelt de HR-specialist in staat om de interne middelen van het bedrijf effectief te gebruiken.
Kruising, samenvoeging en evolutie van productierollen
Er is nog een lastig probleem vanuit het oogpunt van implementatie in het productieproces: het vaststellen van duidelijke grenzen tussen rollen. Op het eerste gezicht lijkt alles duidelijk: de implementatie is voltooid, de documenten voor de ingebruikname van de software zijn ondertekend en alles is overgedragen aan de technische ondersteuning. Dat is allemaal waar, maar er doen zich vaak situaties voor waarin een klant, uit gewoonte en omdat hij nauw contact heeft met een analist en hem als een 'toverstaf' beschouwt, actief met hem blijft communiceren, ondanks het feit dat het systeem al is geïmplementeerd en de ondersteuningsfase formeel is gestart. Maar wie kan vanuit het oogpunt van de klant beter en sneller vragen beantwoorden over het werken met het systeem dan de analist die de opdracht aan hem heeft gegeven? En hier rijst de vraag of de rollen van technisch support engineer en analist gedeeltelijk worden gedupliceerd. Na verloop van tijd gaat 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 zo'n 'interne overgang' niet altijd zonder stress aan beide kanten worden gerealiseerd.

De overlapping tussen de rollen van analist en technisch support engineer ontstaat ook wanneer de stroom van ontwikkelingsvereisten plaatsvindt binnen de supportfase. Als we terugkijken naar de levenscyclus van software, zien we een discrepantie tussen de werkelijke productieomstandigheden en de formele houding dat de analyse van de vereisten en het vaststellen van taken alleen door een analist kunnen worden uitgevoerd. Een HR-specialist moet zeker inzicht hebben in het ideale plaatje van rollen binnen de softwarelevenscyclus; ze hebben duidelijke grenzen. Maar tegelijkertijd is het belangrijk om in gedachten te houden dat kruising mogelijk is. Bij het beoordelen van de kennis en vaardigheden van een sollicitant moet er gelet worden op de aanwezigheid van relevante ervaring. Dat wil zeggen dat bij het zoeken naar technische ondersteuningstechnici kandidaten met ervaring als analist goed in aanmerking kunnen komen, en vice versa.
Naast kruispunten is er vaak ook sprake van samenvoeging van productiefuncties. Zo kunnen een businessanalist en een technisch schrijver in één persoon bestaan. Bij grote industriële ontwikkelingen is de aanwezigheid van een softwarearchitect verplicht, terwijl bij heel kleine projecten deze rol overbodig is: daar worden de functies van de architect vervuld door ontwikkelaars (Software Developer).
De verandering in historische periodes in ontwikkelingsbenaderingen en technologieën leidt er onvermijdelijk toe dat ook de levenscyclus van software evolueert. Wereldwijd blijven de belangrijkste fasen natuurlijk ongewijzigd, maar ze worden wel nader uitgewerkt. Met de overgang naar weboplossingen en de groei van mogelijkheden voor configuratie op afstand is bijvoorbeeld de rol van softwareconfiguratiespecialist ontstaan. In de vroege historische fase waren dit uitvoerders, dat wil zeggen ingenieurs die het grootste deel van hun werktijd op de werkplekken van de klanten doorbrachten. De toegenomen omvang en complexiteit van software heeft geleid tot de opkomst van de rol van softwarearchitect. De vraag naar snellere releases en verbeterde softwarekwaliteit heeft bijgedragen aan de ontwikkeling van geautomatiseerd testen en de opkomst van een nieuwe rol - QA-engineer (Quality Assurance Engineer), enz. De evolutie van rollen in alle stadia van de organisatie van het productieproces is in belangrijke mate verbonden met de ontwikkeling van methoden, technologieën en hulpmiddelen.
We hebben dus een aantal interessante punten besproken met betrekking tot de verdeling van productierollen binnen een softwareontwikkelingsbedrijf in de context van de softwarelevenscyclus. Uiteraard is dit een kijkje binnenin, specifiek voor elk bedrijf. Voor ons allemaal, als deelnemers aan de IT-arbeidsmarkt en degenen die verantwoordelijk zijn voor het promoten van het werkgeversmerk, is de blik van buitenaf extra belangrijk. En hier ligt een groot probleem: niet alleen bij het vinden van betekenissen, maar ook bij het overbrengen van deze informatie aan de doelgroep.
Wat is er mis met de 'dierentuin' van IT-banen?
Verwarring in de hoofden van HR-specialisten, productieorganisatoren en de diversiteit aan benaderingen leiden tot een zeer grote verscheidenheid, een echte 'dierentuin' van IT-functies. Uit ervaring, zowel uit interviews als uit professionele contacten, blijkt dat mensen vaak geen duidelijk beeld hebben van de betekenis die uit de titel van een functie zou moeten voortvloeien. In onze organisatie wordt bijvoorbeeld bij functies waarin de term 'ingenieur-analist' voorkomt, ervan uitgegaan dat het om een taakinsteller gaat. Het blijkt echter niet overal het geval te zijn: er zijn ontwikkelorganisaties waar de analytisch ingenieur een implementator is. Dat is een heel andere interpretatie, vindt u ook niet?
Ten eerste vermindert de ‘dierentuin’ van IT-functies ongetwijfeld de effectiviteit van personeelsselectie. Elke werkgever wil bij de ontwikkeling en promotie van zijn merk in het kort alle betekenissen overbrengen die in zijn product zitten. En als hij zelf vaak niet duidelijk kan zeggen wie wie is, dan is het logisch dat hij onzekerheid overbrengt op de buitenwereld.
Ten tweede zorgt de ‘dierentuin’ van IT-functies voor enorme problemen bij de opleiding en ontwikkeling van IT-personeel. Elk serieus IT-bedrijf dat zich richt op het vormen en ontwikkelen van personeel, en niet alleen op het ‘melken’ van vacaturesites, krijgt vroeg of laat te maken met de noodzaak om samen te werken met onderwijsinstellingen. Voor hooggekwalificeerd IT-personeel is dit het segment van de universiteiten, en wel de beste, in ieder geval die in de TOP-100-ranglijst.
Het probleem van integratie met universiteiten bij het opbouwen van een continu proces van het opleiden van IT-specialisten bestaat voor ongeveer de helft uit het gebrek aan inzicht van de universiteiten in wie wie is binnen een IT-bedrijf. Ze hebben er een heel oppervlakkig begrip van. In de regel hebben universiteiten meerdere specialismen met het woord ‘computerwetenschappen’ in hun naam, en het gebeurt vaak dat ze bij een toelatingscampagne vertrouwen op de stelling dat alle specialismen in wezen over hetzelfde gaan. En het lijkt erop dat het hetzelfde is als wanneer je uitgaat van de populaire mythe dat alle IT-specialisten programmeurs zijn.
Onze ervaring met nauwe samenwerking met universiteiten leert dat de specialisatie “Toegepaste Informatica (door de industrie)” ons personeel levert voor de afdelingen methodologie en technische ondersteuning, maar niet voor ontwikkeling. Terwijl fundamentele computerwetenschappen en software-engineering een uitstekende personeelsbron voor ontwikkelaars vormen. Om te voorkomen dat een sollicitant in eerste instantie een pad opgaat dat niet bij hem past, is het noodzakelijk om de ‘mist’ die de IT-productie omringt, op te heffen.
Is het mogelijk om alles onder één noemer te brengen?
Is het mogelijk om productierollen te standaardiseren en tot een gemeenschappelijk begrip hiervan te komen, zowel binnen als buiten het bedrijf?
Dat is natuurlijk mogelijk en noodzakelijk, want de gezamenlijke ervaring van alle ontwikkelingsbedrijven toont aan dat er gemeenschappelijke, verenigende concepten bestaan voor de organisatie van het productieproces. Dit is een gevolg van het feit dat er immers een duidelijk begrepen concept is van de softwarelevenscyclus, en dat nieuwe productiefuncties (Data Scientist, QA Engineer, Machine Learning Engineer, etc.) een gevolg zijn van de verduidelijking en ontwikkeling van de softwarelevenscyclus als zodanig, die plaatsvindt met de verbetering van technologieën en hulpmiddelen, maar ook met de ontwikkeling en uitbreiding van bedrijfstaken.
Tegelijkertijd is het lastig om productierollen te standaardiseren, omdat IT een van de jongste en snelst groeiende sectoren van de economie is. In zekere zin is dit de chaos waaruit het heelal is ontstaan. Een heldere organisatiestructuur is hier onmogelijk en niet passend, omdat IT een intellectueel maar zeer creatief vakgebied is. Enerzijds is een IT-specialist een ‘fysicus’-intellectueel met een ontwikkeld algoritmisch en wiskundig denkvermogen, anderzijds is hij een ‘tekstschrijver’-schepper, drager en promotor van ideeën. Hij heeft, net als de kunstenaar, geen duidelijk plan voor het schilderen van een schilderij; Hij kan het beeld niet in stukken opsplitsen, want dan houden de laatste op te bestaan. Hij is de meester van informatieprocessen, die op zichzelf abstract, ongrijpbaar en moeilijk te meten zijn, maar wel snel.
Manieren om effectief HR-werk in IT-productie op te zetten
Wat is dus belangrijk voor een HR-specialist om te weten om effectief personeelswerk te creëren in de context van de diversiteit aan rollen in de IT-productie?
Ten eerste moet elke HR-specialist bij een IT-bedrijf een idee hebben van de situatie die kenmerkend is voor zijn onderneming: wie doet wat, wie wordt wat genoemd en vooral welke betekenis wordt gegeven aan deze rollen binnen de omstandigheden van een specifieke productie.
Ten tweede moet de HR-specialist een flexibele kijk hebben op productiefuncties. Dat wil zeggen dat hij aanvankelijk een ideaal begrip ervan ontwikkelt, waardoor hij alles zelf kan uitzoeken. Dan moet er sprake zijn van een reëel beeld van de productie: waar en hoe rollen elkaar kruisen, samenkomen, welke perceptie van deze rollen er bestaat onder productiemanagers. De moeilijkheid voor een HR-specialist is om in zijn hoofd de werkelijke en de ideale situatie te combineren. Hij probeert niet om processen op een geforceerde manier te herstructureren naar het ideale inzicht, maar om de productie te helpen bij het bevredigen van de behoefte aan middelen.
Ten derde is het essentieel om een idee te hebben van de mogelijke ontwikkelingstrajecten van bepaalde specialisten: in welke gevallen kan externe werving effectief zijn en wanneer is het beter om een werknemer in uw team te ontwikkelen en hem ontwikkelingsmogelijkheden te bieden, welke kwaliteiten van kandidaten hen in staat stellen om zich in een specifieke richting te ontwikkelen, welke kwaliteiten niet verenigbaar zijn in één persoon, wat is in eerste instantie belangrijk bij het kiezen van een ontwikkelingstraject.
Ten vierde moeten we terugkeren naar de stelling dat IT een sector is met hooggekwalificeerd personeel, waarbij een vroege integratie in de universitaire onderwijsomgeving onvermijdelijk is voor effectiever personeelswerk. In deze situatie moet elke HR-specialist niet alleen vaardigheden ontwikkelen op het gebied van direct search, het werken met vragenlijsten en het voeren van interviews, maar moet hij ook weten hoe hij moet omgaan met de omgeving van de universitaire opleiding van specialisten: welke universiteiten leiden personeel op voor het bedrijf, welke specialismen binnen specifieke universiteiten voorzien in de personeelsbehoeften en, nog belangrijker, wie zit hierachter en wie beheert en verzorgt de opleiding van specialisten op universiteiten.
Als we de mythe dat alle ICT-specialisten programmeurs zijn, doelbewust willen ontkrachten, moeten we een aantal stappen in die richting zetten en speciale aandacht besteden aan onze universiteiten, waar de basis voor de perceptie van het toekomstige beroep wordt gelegd. Met andere woorden, er is een constante interactie met de onderwijsomgeving nodig, bijvoorbeeld door gebruik te maken van het moderne format van gezamenlijk werken in coworkingcentra, ‘boiling points’ en deelname aan educatieve intensives. Hiermee willen we misverstanden over IT-ondernemingen uit de wereld helpen, de efficiëntie van het personeelswerk vergroten en de voorwaarden scheppen voor gezamenlijke activiteiten op het gebied van de opleiding van verschillende specialisten in onze sector.
Ik wil graag mijn collega's bedanken die hebben meegewerkt aan de voorbereiding en ondersteuning van de relevantie van dit artikel: Valentina Vershinina en Yuri Krupin.
Bron: www.habr.com
