Hvem er hvem i IT?

I den moderne utviklingen av industriell programvareutvikling kan man observere mangfoldet av produksjonsroller. Antallet vokser, og klassifiseringen blir mer komplisert hvert år, noe som naturligvis kompliserer prosessene for å finne spesialister og arbeide med menneskelige ressurser. Informasjonsteknologi (IT) er en sektor med høyt kvalifiserte arbeidsressurser og mangel på arbeidskraft. Her kan prosessen med å utvikle talenter og det behovet for systematisk arbeid med menneskelige ressurser ofte være betydelig mer effektivt enn direkte rekruttering via internettressurser.

Artikkelen tar for seg spørsmål som er relevante for HR-spesialister i IT-selskaper: årsakene til endringene i produksjonsroller, konsekvensene av feilaktig tolkning av innholdet i rollene for det generelle arbeidet med ansatte, samt mulige alternativer for å øke effektiviteten i rekrutteringen av spesialister.

IT-produksjon for de uinnvidde

Hvem er hvem i IT – dette er et tema for diskusjon på forskjellige plattformer. Det har eksistert like lenge som hele IT-industrien, det vil si siden de første programvareutviklingsselskaper dukket opp på forbrukermarkedet tidlig på 90-tallet. Og like lenge har det ikke vært noen enhetlig oppfatning av dette spørsmålet, noe som skaper vanskeligheter og reduserer effektiviteten i arbeidet med ansatte. La oss prøve å finne ut av det.

Temaet produksjonsroller i IT-sektoren har blitt aktuelt og interessant for meg siden jeg begynte i et IT-selskap. Jeg har brukt mye tid og nerveenergi på å forstå produksjonsprosessen. Disse kostnadene har overgått mine forventninger og kostnadene for å tilpasse meg prosessene i andre sektorer: utdanning, materiell produksjon, småbedrifter. Jeg hadde en forståelse av at prosessene er kompliserte og uvante, siden mennesker generelt er mer tilpasset den materielle verden enn den virtuelle. Men det var en intuitiv motstand: det virket som om noe ikke stemte, det burde ikke være slik. Tilpassingsprosessen tok omtrent et år, noe jeg anser som en enorm tid. Til slutt fikk jeg et ganske klart bilde av nøkkelrollene i IT-produksjonen.

Jeg jobber for tiden videre med dette temaet, men på et annet nivå. Som leder for utviklingssenteret i et IT-selskap har jeg ofte samtaler med studenter, lærere ved universiteter, framtidige studenter, skoleelever og andre som ønsker å delta i utviklingen av et IT-produkt for å fremme arbeidsgiverens merkevare i arbeidsmarkedet i det nye området (by. Yaroslavl). Disse samtalene kan være utfordrende på grunn av den lave informasjonsgraden blant samtalepartnerne om hvordan utviklingsprosessen for programvare (SE) er organisert, noe som resulterer i at de ikke forstår temaet for diskusjonen. Etter 5-10 minutter med dialog slutter man å få tilbakemelding og begynner å føle seg som en utlending hvis tale krever oversettelse. Vanligvis er det alltid noen blant samtalepartnerne som setter en stopper for diskusjonen og nevner den folkefantasien fra 90-tallet: "Uansett, alle IT-folk er programmerere." Kildene til denne myten er:

• IT-bransjen utvikler seg raskt, og under disse forholdene er alle grunnleggende betydninger og prinsipper fortsatt i ferd med å formes;
• i en usikker situasjon er det vanskelig å eksistere, derfor prøver man å lette forståelsen av det ukjente ved å skape myter;
• mennesker er mer vant til å oppfatte den materielle verden enn den virtuelle, og det er derfor vanskelig for dem å definere begrepene som ligger utenfor deres persepsjon.

Forsøk på å bekjempe denne myten minner noen ganger om å kjempe mot vindmøller, siden det er flere aspekter ved problemet som trenger å bli behandlet. En HR-spesialist må, for det første, ha et klart bilde av produksjonsrollene i IT-selskapet i både ideell og reell forstand; for det andre, forstå hvordan og når det interne ressursene i selskapet kan utnyttes mest effektivt; for det tredje, hvilke reelle metoder som kan hjelpe til med å øke bevisstheten blant deltakerne på arbeidsmarkedet og bidra til utviklingen av arbeidsgiverens merkevare. La oss se nærmere på disse aspektene.

Livssyklusen til programvare som grunnlag for produksjonsroller

Det er ingen hemmelighet at alle produksjonsroller i en hvilken som helst IT-bedrift generelt har programvarelivssyklusen som kilde. Derfor, hvis vi skal sette opp et konseptuelt mål om å bli enige om en felles forståelse av dette spørsmålet innen hele IT-bransjen, må vi bygge på programvarelivssyklusen som den anerkjente og entydig forståtte meningsfulle basis. Diskusjonen om konkrete implementeringsalternativer for produksjonsroller ligger i vår kreative tilnærming til programvarelivssyklusen.

La oss derfor se på de stadiene som programvarelivssyklusen inkluderer, med RUP-metodologi som eksempel. Disse stadiene utgjør godt etablerte ledd når det gjelder innhold og terminologi. Produksjonsprosessen begynner alltid og overalt med forretningsmodellering og kravformulering, og avsluttes (for enkelhets skyld) med brukeretterretning og forbedringer av programvaren basert på brukerens «ønsker».

Hvis vi tar en historisk tilnærming til slutten av forrige århundre (som kjent var dette perioden med «isolert automatisering»), kan vi se at hele prosessen med programvareutvikling ble utført av utvikleren som programmerer. Her ligger røttene til myten om at hver IT-ansatt er en programmert utvikler.

Med kompleksiteten av produksjonsprosesser, fremkomsten av integrerte plattformer og overgangen til omfattende automatisering av fagområder, med reingeniøriing av forretningsprosesser, blir det uunngåelig at spesialiserte roller knyttet til stadier av livssyklusen dukker opp. Slik er analytikeren, testeren og teknisk supportspesialisten født.

Mangfoldet av stillinger med analytikeren som eksempel

Analytik (også kalt ingeniør-analytiker, spesifikasjonsansvarlig, metodolog, forretningsanalytiker, systemanalytiker osv.) hjelper med å «forene» forretningsoppgaver og teknologiene for deres implementering. Beskrivelsen av oppgaveformuleringen for utvikleren er en beskrivelse av den primære funksjonen til den abstrakte analytikeren. Han fungerer som et bindeledd mellom kunden og utvikleren i prosessene for kravformulering, analyse og programvareutforming. I reelle produksjonsforhold bestemmes oppgavelisten for analytikeren av måten produksjonen organiseres, spesialistens kvalifikasjoner og spesifisiteten til det simulerte fagområdet.

En del av analytikerne er nærmere kunden. Dette er forretningsanalytikere (Business Analyst). De har dyp forståelse av forretningsprosessene i fagområdet og er selv eksperter på de automatiserte prosessene. Det er veldig viktig å ha slike spesialister i selskapets stab, særlig ved automatisering av metodologisk komplekse fagområder. Spesielt for oss som automatiserer budsjettprosessen i staten er det helt nødvendig at det blant analytikerne finnes eksperter innen fagområdet. Dette er høyt kvalifiserte medarbeidere med god finans- og økonomiutdanning og erfaring fra finansielle organer, helst i rollen som ledende spesialister. Erfaring fra ikke-IT-sektoren, men nettopp fra fagområdet, er ekstremt viktig.

En annen gruppe analytikere er nærmere utviklerne. Dette er systemanalytikere (System Analyst). Deres hovedoppgave er å avdekke, systematisere og analysere kundens krav med hensyn til muligheten for å imøtekomme dem, forberede tekniske spesifikasjoner og beskrive oppgaveformuleringer. De har ikke bare kunnskap om forretningsprosesser, men også om informasjonsteknologi, de har god forståelse for mulighetene til programvaren som leveres til kunden, har designferdigheter og forstår derfor hvordan de best kan formidle kundens interesser til utvikleren. Disse medarbeiderne har nødvendigvis utdanning innen IKT og en ingenierteknisk tankegang, og det er ønskelig med erfaring fra IT. Når man velger slike spesialister, vil det være en tydelig fordel å ha designferdigheter ved bruk av moderne verktøy.

En annen type analytikere er tekniske skribenter (Technical Writer). De dokumenterer prosessene i programvareutvikling, lager brukermanualer og administratorhåndbøker, tekniske instruksjoner, opplæringsvideoer osv. Deres hovedoppgave er å formidle informasjon om programmet til brukere og andre interesserte, samt å beskrive teknisk komplekse emner på en klar og forståelig måte. I sin helhet behersker tekniske skribenter norsk utmerket, samtidig som de har teknisk utdanning og analytisk tankegang. For disse spesialistene er det avgjørende å kunne formulere klare, forståelige og detaljerte tekniske tekster i henhold til standarder, samt å ha kunnskap og ferdigheter i dokumentasjonsverktøy.

Dermed ser vi den samme rollen (og for øvrig stillingen i stillingsplanen) – analytiker, men i ulike konkret-applikatoriske former. Å finne spesialister for hver av dem har sine egne særegenheter. Det er viktig å vite at disse typene analytikere ofte må ha sammenstøtende ferdigheter og kunnskaper i én person. Den ene er en humanist, tilbøyelig til analytisk arbeid med store volum tekstdokumenter, med utviklet tale og kommunikasjonsevner; den andre er en 'tekniker' med ingeniørtenkning og interesser innen IT.

Skal vi ta inn folk fra utsiden eller utvikle dem selv?

For en stor aktør innen IT-industrien reduseres effektiviteten av direkte rekruttering fra internettressurser når prosjektene vokser. Dette skjer blant annet av følgende grunner: rask tilpasning til komplekse prosesser i selskapet er ikke mulig, og hastigheten for å lære spesifikke verktøy er lavere enn prosjektets utviklingshastighet. Derfor er det viktig for HR-spesialisten å vite ikke bare hvem de skal lete etter utenfor, men også hvordan de kan utnytte selskapets interne ressurser, og hvordan man kan utvikle spesialisten.

For business analysts, it is crucial to have experience within real processes of the subject area, which makes hiring from outside more effective than cultivating talent internally. In this case, it is important for HR specialists to know the list of organizations that can be sources of this talent pool and to focus on looking for resumes from them during the recruitment process.

In contrast, for filling positions such as system analyst and software architect, the process of developing talent within the company is of great importance. These specialists need to be formed in the context of the operational environment and the specifics of a particular organization. System analysts develop from business analysts, technical writers, and technical support engineers. Software architects evolve from system designers and software developers as they gain experience and broaden their horizons. This allows HR specialists to effectively utilize the internal resources of the company.

Intersection, integration, and evolution of production roles

There is another complex issue from the perspective of implementation in the production process – establishing clear boundaries between roles. At first glance, it may seem obvious: the implementation has ended, documents for the introduction of the software into industrial operation have been signed, and everything has been handed over to technical support. This is true, however, situations often arise where the client, being accustomed to close contact with the analyst and seeing them as a 'magic wand,' continues to actively communicate with them, even though the system has already been implemented, and the support phase is formally underway. Yet from the client's perspective, who better and faster than the analyst, who set the task together with them, can answer questions about working with the system? This raises the question of a partial overlap between the roles of the technical support engineer and the analyst. Over time, everything settles, and the client gets used to communicating with the technical support service, but in the very beginning of software operation, such an 'internal transition' is not always successfully carried out without stress on both sides.

Krysset mellom rollene til analytikeren og supportingeniøren oppstår også når kravet om utvikling kommer i løpet av oppfølgingsfasen. Når vi ser tilbake på programvarelivssyklusen, ser vi en uoverensstemmelse mellom de faktiske produksjonsforholdene og de formelle oppstillingene om at kravanalysen og oppgavesettingen kun kan utføres av analytikeren. En spesialist innen HR må absolutt forstå det ideelle bildet av roller i programvarelivssyklusen, da de har klare grenser. Men samtidig må det alltid tas høyde for at det kan oppstå overlapping. Når man vurderer kunnskapene og ferdighetene til en kandidat, bør man være oppmerksom på tilstedeværelse av relatert erfaring. Det vil si at når man leter etter supportingeniører, kan kandidater med erfaring som analytiker også vurderes, og omvendt.

I tillegg til overlapping, er det ofte sammenslåing av produksjonsroller. For eksempel kan en forretningsanalytiker og teknisk forfatter eksistere i én person. Tilstedeværelsen av en programvarearkitekt (Software Architect) er nødvendig i stor industriell utvikling, mens helt små prosjekter kan klare seg uten denne rollen: der utfører utviklerne (Software Developer) arkitektens funksjoner.

Endringene i historiske perioder, tilnærminger og utviklingsteknologier fører uunngåelig til at programvarelivssyklusen også utvikler seg. Globalt sett forblir de grunnleggende stadiene stort sett uendret, men detaljeringen skjer. For eksempel, med overgangen til web-løsninger og veksten i mulighetene for fjernkonfigurasjon, dukket det opp en rolle for programvarekonfigurasjonsspesialisten. I det tidlige historiske stadiet var dette implementeringsteknikere, det vil si ingeniører som tilbrakte mesteparten av arbeidstiden sine på kundens arbeidsplasser. Økte volum og kompleksitet i programvaren førte til opprettelsen av rollen som programvarearkitekt (Software Architect). Kravene til raskere versjonsutgivelser og økt programvarekvalitet har bidratt til utviklingen av automatisert testing og opprettelsen av en ny rolle - QA-ingeniør (Quality Assurance Engineer), osv. Evolusjonen av roller gjennom alle faser av produksjonsprosessen er betydelig knyttet til utviklingen av metoder, teknologier og verktøy.

Vi har nå sett på noen interessante aspekter av fordelingen av produksjonsroller i programvareutviklingsbedrifter innenfor programvarelivssyklusen. Det er åpenbart at dette er et internt perspektiv som er spesifikt for hver enkelt bedrift. For oss alle, som deltakere i arbeidsmarkedet innen IT-bransjen og ansvarlige for å fremme arbeidsgivermerket, er det også spesielt viktig å ha et eksternt perspektiv. Her eksisterer det en stor utfordring, ikke bare med å finne meninger, men også med å formidle denne informasjonen til målgruppen.

Hva er galt med "dyrehagen" av IT-stillinger?

Forvirringen i bevisstheten til HR-spesialister, produksjonsorganisatorer og mangfoldet av tilnærminger fører til et svært bredt spekter, rett og slett en "dyrehage" av IT-stillinger. Erfaringen fra intervjuer og profesjonelle kontakter viser at folk ofte ikke har en entydig forståelse av meningen som burde følge med stillingstittelen. For eksempel, i vår organisasjon innebærer stillinger med betegnelsen "ingeniør-analytiker" at personen setter opp oppgaver. Men det viser seg at det ikke alltid er slik: det finnes utviklingsorganisasjoner der ingeniør-analytikeren er en implementer. Helt annen forståelse, er du ikke enig?

For det første, "dyrehagen" av IT-stillinger reduserer utvilsomt effektiviteten i rekrutteringen. Hver arbeidsgiver som utvikler og fremmer sitt merke, ønsker å formidle alle meningene som finnes i produksjonen sin på en kort og presis måte. Hvis de selv ofte ikke kan si klart hvem som er hvem, vil det naturligvis resultere i usikkerhet i den eksterne kommunikasjonen.

For det andre skaper "dyrehagen" av IT-stillinger enorme problemer når det gjelder opplæring og utvikling av IT-arbeidskraft. Hver seriøs IT-virksomhet som har som mål å forme og utvikle sitt menneskelige potensial, i stedet for bare å "melke" jobbsider, møter etter hvert behovet for samarbeid med utdanningsinstitusjoner. For høyt kvalifiserte IT-arbeidere er dette segmentet av universiteter, helst de beste, minst rangert blant de 100 beste.

Problemet med integrasjon med høyere utdanning ved oppbygging av en kontinuerlig prosess for opplæring av IT-spesialister ligger omtrent halvparten i mangelen på forståelse fra universitetenes side om hvem som er hvem i IT-selskapet. De har en veldig overfladisk oppfatning av dette. Som regel har universitetene flere spesialiteter med ordet «informatikk» i navnet, og det skjer ofte at når de gjennomfører opptaksprosedyrer, bygger de på en tese om at alle spesialiteter i bunn og grunn handler om det samme. Det er omtrent som å lene seg på en folkslig myte om at alle IT-folk er programmerere.

Erfaringen fra vårt tette samarbeid med høyskolene viser at spesialiteten «Anvendt Informatikk (per bransje)» gir oss kandidater til avdelingene for metodikk og teknisk støtte, men ikke til utvikling. Mens «Fundamentalt Informatikk», «Programvareingeniør» utdanner utmerket personell for utviklere. For ikke å lede studenter ned en ubrukt vei fra starten av, er det nødvendig å «spres tåken» som omgir IT-produksjonen.

Kan alt bringes til en felles nevner?

Kan vi standardisere produksjonsrollene og komme til en felles forståelse av dem både innenfor og utenfor selskapet?

Selvfølgelig kan og må vi det, fordi den akkumulert kollektive erfaringen til alle utviklingsbedrifter demonstrerer eksistensen av felles, samlende konsepter for organiseringen av produksjonsprosessen. Dette er en konsekvens av at det faktisk finnes et entydig høydepunkt i livssyklusen til programvare som alle tolker likt, og de nye produksjonsrollene (DataScientist, QA-Engineer, MachineLearning Engineer, osv.) er et resultat av presiseringen og utviklingen av programvarelivssyklusen som sådan, som skjer med forbedring av teknologier og verktøy, samt med utviklingen og opphopning av forretningsoppgaver.

Samtidig er det vanskelig å standardisere produksjonsroller, fordi IT er en av de yngste og mest dynamiske næringene i økonomien. På en viss måte er dette et kaos, hvor universet har oppstått. En klar organisatorisk struktur er umulig og malplassert her, fordi IT er et intellektuelt, men også veldig kreativt felt. På den ene siden er IT-folk «fysikere» med utviklet algoritmisk og matematisk tenkning, på den annen side er de «lyriske» skapere, bærere og promotører av ideer. Akkurat som en kunstner har de ikke en klar plan for å male et bilde, de kan ikke dekomponere motivet, for så vil det slutte å eksistere. De er herskere over informasjonsprosesser som i seg selv er abstrakte, uhåndgripelige, vanskelig målbare, men hurtige.

Veier til effektiv rekruttering i IT-produksjon

Så, hva er viktig for HR-spesialister å vite for å bygge effektiv rekruttering i lys av mangfoldet av roller i IT-produksjonen.

For det første må enhver HR-spesialist i et IT-selskap ha en forståelse av situasjonen som er karakteristisk for sitt foretak: hvem som gjør hva, hvem som har hvilke titler, og viktigst av alt – hvilken mening som legges i disse rollene innenfor den spesifikke produksjonen.

For det andre må HR-spesialisten ha en fleksibel forståelse av produksjonsrollene. Det vil si at de i utgangspunktet danner seg et ideelt bilde av dem som gjør at de selv kan navigere gjennom alt. Deretter må det også være et realistisk bilde av produksjonen: hvor og hvordan rollene overlapper, forenes, og hvilket syn på disse rollene som eksisterer hos produksjonsledere. Utfordringen for HR-spesialisten ligger i å forene i sin bevissthet den reelle og ideelle situasjonen, ikke forsøke å tvinge prosessene til å tilpasse seg den ideelle forståelsen, men å hjelpe produksjonen i å tilfredsstille behovet for ressurser.

For det tredje er det viktig å ha en forståelse av mulige utviklingsbaner for ulike spesialister: når eksterne rekrutteringer kan være effektive, og når det er bedre å utvikle ansatte internt, og gi dem muligheter for vekst, hvilke egenskaper kandidater må ha for å utvikle seg i en bestemt retning, hvilke egenskaper som ikke kan være forenlige i én person, og hva som er viktig for å velge utviklingsbane.

For det fjerde, la oss gå tilbake til påstanden om at IT er et felt for høyt kvalifiserte medarbeidere, der tidlig integrering med universitetsutdanningsmiljøet er uunngåelig for mer effektiv personalarbeid. I denne situasjonen må hver HR-spesialist utvikle ikke bare ferdigheter innen direkte søk, arbeid med søknader og intervjuing, men også ha en god forståelse av universitetsutdanningen av fagfolk: hvilke universiteter utdanner kandidater for selskapet, hvilke spesialiteter innen de bestemte universitetene tilfredsstiller personalbehov, og hvem som står bak dette, hvem leder og sørger for utdanningen av spesialister ved universitetene.

Dermed, for målrettet å avkrefte myten om at alle IT-folk er programmerere, må et helt sett med tiltak gjøres i denne retningen, og særlig ta hensyn til våre universiteter, hvor grunnlaget for oppfatningen av fremtidige yrker legges. Med andre ord, det trengs kontinuerlig interaksjon med utdanningsmiljøet, for eksempel ved å bruke moderne former for samarbeid i co-working-sentre, 'sistykk-punkter', deltakelse i utdanningsintensiver. Dette vil bidra til å bryte ned feil oppfatninger om IT-virksomheter, øke effektiviteten av personalarbeidet og skape betingelser for samarbeid ved utdanning av ulike spesialister i vår bransje.

Jeg takker kollegene som deltok i forberedelsen og oppdateringen av denne artikkelen: Valentina Vershinina og Yuri Krupin.

Kilde: habr.com