På det nåværende utviklingsstadiet av industriell programvareutvikling kan man observere en rekke produksjonsroller. Antallet deres vokser, klassifiseringen blir mer komplisert hvert år, og naturlig nok blir prosessene med å velge spesialister og arbeid med menneskelige ressurser mer kompliserte. Informasjonsteknologi (IT) er et område med høyt kvalifisert arbeidskraft og mangel på personell. Her er prosessen med å utvikle personell og behovet for systematisk arbeid med personellpotensial mye mer effektivt enn direkte utvelgelse ved bruk av internettressurser.
Artikkelen diskuterer problemstillinger som er relevante for HR-spesialister i IT-bedrifter: årsak-virkning-relasjoner i utviklingen av produksjonsroller, konsekvensene av feiltolkning av rollens innhold for HR-arbeid generelt, samt mulige alternativer for å øke effektivitet ved rekruttering av spesialister.
IT-produksjon for uinnvidde
Hvem er hvem i IT er et tema for diskusjon på ulike plattformer. Det har eksistert like lenge som hele IT-bransjen, det vil si siden de første programvareutviklingsselskapene dukket opp på forbrukermarkedet på begynnelsen av 90-tallet av forrige århundre. Og i like lang tid har det ikke vært noe felles syn på dette spørsmålet, noe som skaper vanskeligheter og reduserer effektiviteten i personalarbeidet. La oss prøve å finne ut av det.
For meg har temaet produksjonsroller i IT-sektoren blitt aktuelt og interessant siden jeg begynte i IT-selskapet. Jeg brukte mye tid og nervøs energi på å prøve å forstå produksjonsprosessen. Disse kostnadene overgikk mine forventninger og kostnadene ved tilpasning til prosesser på andre områder: utdanning, materialproduksjon, småbedrifter. Jeg hadde en forståelse av at prosessene er komplekse og uvanlige, siden en person generelt er mer tilpasset den materielle verden enn til den virtuelle. Men det var intuitiv motstand: det så ut til at noe var galt her, det burde ikke være slik. Tilpasningsprosessen tok sannsynligvis et år, som etter min forståelse rett og slett er kosmisk. Som et resultat hadde jeg en ganske klar forståelse av nøkkelrollene i IT-produksjon.
Foreløpig fortsetter jeg å jobbe med dette temaet, men på et annet nivå. Som leder for utviklingssenteret til en IT-bedrift må jeg ofte kommunisere med studenter, universitetslærere, søkere, skoleelever og andre som ønsker å være med på å lage et IT-produkt for å fremme arbeidsgivermerket på arbeidsmarkedet av et nytt territorium (Yaroslavl). Denne kommunikasjonen er ikke lett på grunn av den lave bevisstheten til samtalepartnerne om hvordan programvareutviklingsprosessen er organisert, og som et resultat av deres manglende forståelse av emnet for samtalen. Etter 5–10 minutter med dialog slutter du å motta tilbakemeldinger og begynner å føle deg som en utlending hvis tale krever oversettelse. Som regel er det blant samtalepartnerne noen som trekker en linje i dialogen og gir uttrykk for en folkemyte fra 90-tallet: "I alle fall, alle IT-spesialister er programmerere." Opprinnelsen til myten er:
- IT-industrien er i rask utvikling, under disse forholdene er alle de grunnleggende betydningene og prinsippene på dannelsesstadiet;
- Det er vanskelig å eksistere i forhold med usikkerhet, så en person prøver å gjøre det lettere for seg selv å forstå det ukjente ved å skape myter;
- en person er mer vant til oppfatningen av den materielle verden enn den virtuelle, og derfor er det vanskelig for ham å definere konsepter som ligger utenfor hans oppfatning.
Å prøve å bekjempe denne myten kan noen ganger føles som å vippe ved vindmøller, siden det er flere aspekter ved problemet som må løses. En HR-spesialist trenger for det første å ha et klart bilde av produksjonsrollene i en IT-bedrift i en ideell og reell legemliggjøring, for det andre å forstå hvordan og når selskapets interne ressurser kan brukes mest effektivt, og for det tredje, hvilke reelle metoder vil bidra til å øke bevisstheten hos arbeidsmarkedets aktører og vil bidra til utviklingen av arbeidsgivermerket. La oss se nærmere på disse aspektene.
Programvarens livssyklus som grunnlag for produksjonsroller
Det er ingen hemmelighet at generelt har alle produksjonsroller i et IT-selskap programvarens livssyklus som kilde. Derfor, hvis vi setter den konseptuelle oppgaven med å bli enige om en enhetlig oppfatning av dette problemet innenfor hele IT-bransjen, må vi stole spesifikt på programvarens livssyklus som et semantisk grunnlag akseptert og klart forstått av alle. Diskusjon av spesifikke alternativer for å implementere spørsmålet om produksjonsroller ligger i planet av vår kreative holdning til programvarens livssyklus.
Så la oss se på stadiene som programvarens livssyklus inkluderer, ved å bruke RUP-metodikken som et eksempel. De er ganske modne lenker når det gjelder innhold og terminologi. Produksjonsprosessen begynner alltid og overalt med forretningsmodellering og dannelsen av krav, og ender (selvfølgelig betinget) med å konsultere brukere og modifisere programvaren basert på brukernes "ønsker".
Hvis du tar en historisk ekskursjon til slutten av forrige århundre (som du vet, var dette perioden med "øyautomatisering"), kan du se at hele prosessen med å lage programvare ble utført av en programmerer-utvikler. Her er røttene til myten om at enhver IT-spesialist er programmerer.
Med den økende kompleksiteten til produksjonsprosesser, fremveksten av integrerte plattformer og overgangen til kompleks automatisering av fagområder, med omstrukturering av forretningsprosesser, blir fremveksten av spesialiserte roller knyttet til livssyklusstadier uunngåelig. Slik fremstår en analytiker, tester og teknisk støttespesialist.
Mangfold av stillinger ved å bruke eksemplet med rollen som analytiker
En analytiker (aka analytisk ingeniør, aka regissør, metodolog, forretningsanalytiker, systemanalytiker, etc.) hjelper til med å "bli venner" med forretningsoppgaver og teknologier for deres implementering. Beskrivelse av problemstillingen for utvikleren - slik kan man karakterisere hovedfunksjonen til en abstrakt analytiker. Han fungerer som et bindeledd mellom oppdragsgiver og utvikler i prosessene med kravdannelse, analyse og programvaredesign. Under reelle produksjonsforhold bestemmes listen over analytikerfunksjoner av metoden for å organisere produksjonen, kvalifikasjonene til spesialisten og spesifikasjonene til det modellerte fagområdet.
Noen analytikere befinner seg nærmere kunden. Dette er forretningsanalytikere (Business Analyst). De har dyp forståelse for forretningsprosessene i fagområdet og er selv eksperter på automatiserte prosesser. Det er svært viktig å ha slike spesialister på ansatte i en bedrift, spesielt når man automatiserer metodisk komplekse fagområder. Spesielt for oss, som automatiserere av statsbudsjettprosessen, er det rett og slett nødvendig at det er fageksperter blant analytikerne. Dette er høyt kvalifiserte medarbeidere med god finansiell og økonomisk utdannelse og erfaring fra finansmyndigheter, gjerne i rollen som ledende spesialister. Erfaring ikke innen IT-feltet, men spesifikt innen fagområdet er ekstremt viktig.
Den andre delen av analytikerne er nærmere utviklerne. Dette er systemanalytikere (System Analyst). Deres hovedoppgave er å identifisere, systematisere og analysere klientkrav for muligheten for å tilfredsstille dem, utarbeide tekniske spesifikasjoner og beskrive problemstillinger. De forstår ikke bare forretningsprosesser, men også informasjonsteknologier, har en god forståelse av egenskapene til programvaren som leveres til kunden, har designferdigheter og forstår følgelig hvordan de best kan formidle kundens interesser til utvikleren. Disse ansatte må ha utdanning innen IKT og ingeniør- og teknisk tankesett, gjerne erfaring innen IT. Når du velger slike spesialister, vil det være en klar fordel å ha designferdigheter ved hjelp av moderne verktøy.
En annen type analytiker er tekniske forfattere. De er engasjert i dokumentasjon som en del av programvareutviklingsprosesser, utarbeidelse av bruker- og administratormanualer, teknologiske instruksjoner, opplæringsvideoer, etc. Deres hovedoppgave er å kunne formidle informasjon om driften av programmet til brukere og andre interesserte, for å beskrive teknisk komplekse ting kort og tydelig. Tekniske forfattere har for det meste en utmerket beherskelse av det russiske språket, og har samtidig en teknisk utdannelse og et analytisk sinn. For slike spesialister er ferdighetene til å kompilere klare, kompetente, detaljerte tekniske tekster i samsvar med standarder, samt kunnskap og mestring av dokumentasjonsverktøy av største betydning.
Dermed ser vi den samme rollen (og, forresten, posisjon i bemanningstabellen) - analytiker, men i dens forskjellige spesifikke applikasjonsinkarnasjoner. Søket etter spesialister for hver av dem har sine egne egenskaper. Det er viktig å vite at denne typen analytikere må ha ferdigheter og kunnskaper som ofte er uforenlige hos én person. Den ene er en humanioraspesialist, utsatt for analytisk arbeid med store mengder tekstdokumenter, med utviklede tale- og kommunikasjonsevner, den andre er en "techie" med ingeniørtenkning og interesser innen IT-feltet.
Tar vi fra utsiden eller vokser?
For en stor representant for IT-bransjen avtar effektiviteten av direkte valg fra Internett-ressurser etter hvert som prosjekter vokser. Dette skjer spesielt av følgende grunner: rask tilpasning til komplekse prosesser i selskapet er umulig, hastigheten på å mestre spesifikke verktøy er lavere enn hastigheten på prosjektutvikling. Derfor er det viktig for en HR-spesialist å vite ikke bare hvem man skal se etter eksternt, men også hvordan man bruker selskapets interne ressurser, fra hvem og hvordan man kan utvikle en spesialist.
For forretningsanalytikere er erfaring med å jobbe innenfor reelle prosesser i fagområdet svært viktig, så å rekruttere dem «fra utsiden» er mer effektivt enn å vokse dem i bedriften. Samtidig er det viktig for en HR-spesialist å kjenne til listen over organisasjoner som kan være kilder til denne menneskelige ressursen, og når du velger, fokusere på å søke etter CV fra dem.
For å fylle ledige stillinger som systemanalytiker og programvarearkitekt er tvert imot prosessen med opplæring i selskapet av stor betydning. Disse spesialistene må dannes i det nåværende produksjonsmiljøet og spesifikasjonene til en bestemt organisasjon. Systemanalytikere utvikler seg fra forretningsanalytikere, tekniske skribenter og tekniske støtteingeniører. Software Architects - fra designere (System Designer) og programvareutviklere (Software Developer) ettersom de får erfaring og utvider horisonten. Denne omstendigheten lar en HR-spesialist effektivt bruke selskapets interne ressurser.
Kryss, integrasjon og utvikling av produksjonsroller
Det er en annen vanskelig sak med tanke på implementering i produksjonsprosessen - å etablere klare grenser mellom rollene. Ved første øyekast kan det virke som om alt er åpenbart: implementeringen er fullført, dokumentene om å sette programvaren i kommersiell drift er signert, og alt er overlevert til teknisk support. Det er riktig, men det oppstår ofte situasjoner når klienten av vane er i nær kontakt med analytikeren og ser ham som en "tryllestav", fortsetter å aktivt kommunisere med ham, til tross for at systemet allerede er implementert og den formelle støttefasen er i gang. Men fra klientens synspunkt, hvem vil bedre og raskere enn analytikeren som satte oppgaven sammen med ham svare på spørsmål om arbeidet med systemet. Og her oppstår spørsmålet om delvis duplisering av rollene til en teknisk støtteingeniør og en analytiker. Over tid blir alt bedre, klienten blir vant til å kommunisere med den tekniske støttetjenesten, men helt i begynnelsen av programvaren kan en slik "intern overgang" ikke alltid oppnås uten stress på begge sider.
Skjæringspunktet mellom rollene som analytiker og teknisk støtteingeniør oppstår også når flyten av utviklingskrav oppstår som en del av støttestadiet. Tilbake til programvarens livssyklus ser vi et avvik mellom reelle produksjonsforhold og formelle holdninger om at kravanalyse og problemformulering utelukkende kan utføres av en analytiker. En HR-spesialist må selvfølgelig forstå det ideelle bildet av roller innenfor programvarens livssyklus; de har klare grenser. Men samtidig bør du absolutt huske på at kryss er mulig. Når du vurderer kunnskapen og ferdighetene til en søker, bør du være oppmerksom på tilstedeværelsen av relatert erfaring, det vil si at når du søker etter tekniske støtteingeniører, kan kandidater med analytikererfaring godt vurderes og omvendt.
I tillegg til overlapping skjer det ofte en konsolidering av produksjonsroller. For eksempel kan en forretningsanalytiker og en teknisk skribent eksistere som én person. Tilstedeværelsen av en programvarearkitekt (Software Architect) er obligatorisk i stor industriell utvikling, mens svært små prosjekter kan klare seg uten denne rollen: der utføres arkitektens funksjoner av utviklere (Software Developer).
Endringer i historiske perioder i utviklingstilnærminger og teknologier fører uunngåelig til at programvarens livssyklus også utvikler seg. Globalt forblir selvfølgelig hovedfasene uendret, men de blir mer detaljerte. For eksempel, med overgangen til nettbaserte løsninger og veksten av fjernkonfigurasjonsevner, har rollen som en programvarekonfigurasjonsspesialist dukket opp. På et tidlig historisk stadium var dette implementere, det vil si ingeniører som tilbrakte mesteparten av arbeidstiden på kundenes arbeidsplasser. Det økte volumet og kompleksiteten til programvare har ført til fremveksten av rollen som Software Architect. Krav til å akselerere versjonsutgivelser og forbedre programvarekvaliteten bidro til utviklingen av automatisert testing og fremveksten av en ny rolle - QA-ingeniør (Quality Assurance Engineer), etc. Utviklingen av roller i alle stadier av produksjonsprosessen er vesentlig knyttet til utviklingen av metoder, teknologier og verktøy.
Så langt har vi sett på noen interessante punkter angående fordelingen av produksjonsroller i et programvareselskap i sammenheng med programvarens livssyklus. Dette er åpenbart et insidersyn som er spesifikt for hvert selskap. For oss alle, som aktører i IT-bransjens arbeidsmarked og ansvarlige for å fremme arbeidsgivermerke, vil synet utenfor være spesielt viktig. Og her er det et stort problem ikke bare med å finne mening, men også å formidle denne informasjonen til målgruppen.
Hva er galt med "zoo" av IT-stillinger?
Forvirring i hodet til HR-spesialister, produksjonsledere og mangfoldet av tilnærminger fører til et veldig stort utvalg, en veritabel "zoo" av IT-stillinger. Opplevelsen av intervjuer og rett og slett profesjonelle kontakter viser at folk ofte ikke har en klar forståelse av betydningen som skal følge av stillingsbetegnelser. For eksempel, i vår organisasjon, antar stillinger som inkluderer begrepet "analytikkingeniør" at dette er en oppgavesett. Det viser seg imidlertid at dette ikke er tilfelle overalt: Det finnes utviklingsorganisasjoner der en analytisk ingeniør er en implementer. En helt annen forståelse, er du enig?
For det første reduserer "zoo" av IT-stillinger utvilsomt effektiviteten av rekruttering. Hver arbeidsgiver, når han utvikler og markedsfører merkevaren sin, ønsker å formidle i en kortfattet form alle betydningene som finnes i produksjonen hans. Og hvis han selv ofte ikke klart kan si hvem som er hvem, er det naturlig at han sender ut usikkerhet til det ytre miljø.
For det andre skaper "zoo" av IT-stillinger enorme problemer i opplæring og utvikling av IT-personell. Ethvert seriøst IT-selskap, rettet mot å danne og utvikle menneskelige ressurser, og ikke bare "melke" arbeidsplasser, møter før eller litt senere behovet for å samhandle med utdanningsinstitusjoner. For høyt kvalifisert IT-personell er dette et segment av universiteter, og de beste på det, i hvert fall de i TOP-100-rangeringen.
Problemet med integrasjon med universiteter når man bygger en kontinuerlig prosess med opplæring av IT-spesialister er omtrent halvparten av mangelen på universitetets forståelse av hvem som er hvem i IT-selskapet. De har en veldig overfladisk forståelse av dette. Universiteter har som regel flere spesialiteter med ordet "datavitenskap" i navnet, og det hender ofte at når de gjennomfører en opptakskampanje, stoler de på tesen om at alle spesialiteter i hovedsak handler om det samme. Og det ser det samme ut som om vi stoler på den populære myten om at alle IT-spesialister er programmerere.
Erfaringen fra vårt nære samarbeid med universiteter viser at spesialiteten «Anvendt informatikk (etter industri)» forsyner oss med personell til metodikk- og teknisk støtteavdelinger, men ikke utvikling. Mens "Fundamental Informatics", "Software Engineering" forbereder en utmerket menneskelig ressurs for utviklere. For ikke i utgangspunktet å lede søkeren langs en vei som er uegnet for ham, er det nødvendig å "fjerne tåken" som omgir IT-produksjonen.
Er det mulig å bringe alt til en fellesnevner?
Er det mulig å forene produksjonsroller og komme til en felles forståelse av dem i og utenfor selskapet?
Selvfølgelig er det mulig og nødvendig, fordi den akkumulerte kollektive erfaringen fra alle utviklingsbedrifter viser tilstedeværelsen av vanlige, samlende konsepter for organisering av produksjonsprosessen. Dette er en konsekvens av det faktum at det fortsatt er et unikt tolket konsept for programvarens livssyklus, og de nye produksjonsrollene (DataScientist, QA-Engineer, MachineLearning Engineer, etc.) er en konsekvens av klargjøringen og utviklingen av programvarens livssyklus som sådan, som skjer med forbedring av teknologier og verktøy, samt utvikling og utvidelse av forretningsoppgaver.
Samtidig er det vanskelig å forene produksjonsrollene, fordi IT er en av de yngste og raskest voksende sektorene i økonomien. På en måte er dette kaoset som universet dukket opp fra. En tydelig organisasjonsstruktur er umulig og uhensiktsmessig her, fordi IT er et intellektuelt, men veldig kreativt felt. På den ene siden er en IT-spesialist en «fysiker»-intellektuell med utviklet algoritmisk og matematisk tenkning, på den andre siden er han en «lyriker»-skaper, bærer og fremmer av ideer. Han, akkurat som kunstneren, har ikke en klar plan for å male, han kan ikke dekomponere bildet i deler, siden sistnevnte vil slutte å eksistere. Han er herskeren over informasjonsprosesser, som i seg selv er abstrakte, immaterielle, vanskelige å måle, men raske.
Måter å bygge effektivt personalarbeid innen IT-produksjon
Så, hva er viktig for en HR-spesialist å vite for å bygge effektivt HR-arbeid i sammenheng med mangfoldet av IT-produksjonsroller.
For det første må enhver HR-spesialist i et IT-selskap ha en ide om situasjonen som er typisk spesifikt for bedriften hans: hvem gjør hva, hvem kalles hva, og viktigst av alt, hva er meningen med disse rollene i forholdene til en bestemt produksjon.
For det andre må HR-profesjonelle ha en fleksibel forståelse av produksjonsroller. Det vil si at han i utgangspunktet danner en ideell forståelse av dem, som lar ham finne ut av alt selv. Da må det være et reelt bilde av produksjonen: hvor og på hvilke måter rollene krysser hverandre og kombinerer, hvilken oppfatning av disse rollene finnes blant produksjonsledere. Vanskeligheten for en personellspesialist er å kombinere de virkelige og ideelle situasjonene i sinnet, ikke å prøve å tvinge ombygging av prosesser for å passe deres ideelle forståelse, men å hjelpe produksjonen med å møte behovet for ressurser.
For det tredje bør du definitivt ha en ide om mulige utviklingsbaner til visse spesialister: i hvilke tilfeller eksternt utvalg kan være effektivt, og når er det bedre å vokse en ansatt i teamet ditt, gi ham muligheter for utvikling, hvilke egenskaper av kandidater vil tillate dem å utvikle seg i en bestemt retning, hvilke egenskaper ikke kan være kompatible i en person, noe som i utgangspunktet er viktig for å velge en utviklingsbane.
For det fjerde, la oss gå tilbake til tesen om at IT er et felt med høyt kvalifisert personell, hvor tidlig integrasjon med universitetets utdanningsmiljø er uunngåelig for mer effektivt personalarbeid. I denne situasjonen må hver HR-spesialist utvikle ikke bare ferdighetene til direkte søk, arbeid med spørreskjemaer og intervjuer, men også sørge for å navigere i miljøet for universitetstrening av spesialister: hvilke universiteter forbereder personell for selskapet, hvilke spesialiteter innen spesifikke universiteter dekke personellbehov, og hva Det er viktig hvem som står bak, hvem som leder og utdanner spesialister på universiteter.
Derfor, hvis vi målrettet avliver myten om at alle IT-spesialister er programmerere, er det nødvendig å ta en rekke skritt i denne retningen og være spesielt oppmerksom på universitetene våre, der grunnlaget for oppfatningen av det fremtidige yrket legges. Med andre ord, vi trenger konstant samhandling med det pedagogiske miljøet, for eksempel ved å bruke det moderne samarbeidsformen i coworking-sentre, "kokepunkter" og deltakelse i pedagogiske intensiver. Dette vil bidra til å ødelegge misoppfatninger om IT-bedriften, øke effektiviteten i personalarbeidet og legge forholdene til rette for felles aktiviteter i opplæring av ulike spesialister i vår bransje.
Jeg uttrykker min takknemlighet til kollegene som deltok i utarbeidelsen og støtten til relevansen av denne artikkelen: Valentina Vershinina og Yuri Krupin.
Kilde: www.habr.com