mennesker er mer vant til \u00e5 oppfatte den materielle verden enn den virtuelle, og det er derfor vanskelig for dem \u00e5 definere begrepene som ligger utenfor deres persepsjon.<\/li>\n<\/ul>\n\nFors\u00f8k p\u00e5 \u00e5 bekjempe denne myten minner noen ganger om \u00e5 kjempe mot vindm\u00f8ller, siden det er flere aspekter ved problemet som trenger \u00e5 bli behandlet. En HR-spesialist m\u00e5, for det f\u00f8rste, ha et klart bilde av produksjonsrollene i IT-selskapet i b\u00e5de ideell og reell forstand; for det andre, forst\u00e5 hvordan og n\u00e5r det interne ressursene i selskapet kan utnyttes mest effektivt; for det tredje, hvilke reelle metoder som kan hjelpe til med \u00e5 \u00f8ke bevisstheten blant deltakerne p\u00e5 arbeidsmarkedet og bidra til utviklingen av arbeidsgiverens merkevare. La oss se n\u00e6rmere p\u00e5 disse aspektene.<\/p>\n
Livssyklusen til programvare som grunnlag for produksjonsroller<\/h2>\n \nDet 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\u00e5l om \u00e5 bli enige om en felles forst\u00e5else av dette sp\u00f8rsm\u00e5let innen hele IT-bransjen, m\u00e5 vi bygge p\u00e5 programvarelivssyklusen som den anerkjente og entydig forst\u00e5tte meningsfulle basis. Diskusjonen om konkrete implementeringsalternativer for produksjonsroller ligger i v\u00e5r kreative tiln\u00e6rming til programvarelivssyklusen.<\/p>\n
La oss derfor se p\u00e5 de stadiene som programvarelivssyklusen inkluderer, med RUP-metodologi som eksempel. Disse stadiene utgj\u00f8r godt etablerte ledd n\u00e5r 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\u00e5 brukerens \u00ab\u00f8nsker\u00bb. <\/p>\n
Med kompleksiteten av produksjonsprosesser, fremkomsten av integrerte plattformer og overgangen til omfattende automatisering av fagomr\u00e5der, med reingeni\u00f8riing av forretningsprosesser, blir det uunng\u00e5elig at spesialiserte roller knyttet til stadier av livssyklusen dukker opp. Slik er analytikeren, testeren og teknisk supportspesialisten f\u00f8dt. <\/p>\n
Mangfoldet av stillinger med analytikeren som eksempel<\/h2>\n \nAnalytik (ogs\u00e5 kalt ingeni\u00f8r-analytiker, spesifikasjonsansvarlig, metodolog, forretningsanalytiker, systemanalytiker osv.) hjelper med \u00e5 \u00abforene\u00bb forretningsoppgaver og teknologiene for deres implementering. Beskrivelsen av oppgaveformuleringen for utvikleren er en beskrivelse av den prim\u00e6re 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\u00e5ten produksjonen organiseres, spesialistens kvalifikasjoner og spesifisiteten til det simulerte fagomr\u00e5det.<\/p>\n
En annen gruppe analytikere er n\u00e6rmere utviklerne. Dette er systemanalytikere (System Analyst). Deres hovedoppgave er \u00e5 avdekke, systematisere og analysere kundens krav med hensyn til muligheten for \u00e5 im\u00f8tekomme dem, forberede tekniske spesifikasjoner og beskrive oppgaveformuleringer. De har ikke bare kunnskap om forretningsprosesser, men ogs\u00e5 om informasjonsteknologi, de har god forst\u00e5else for mulighetene til programvaren som leveres til kunden, har designferdigheter og forst\u00e5r derfor hvordan de best kan formidle kundens interesser til utvikleren. Disse medarbeiderne har n\u00f8dvendigvis utdanning innen IKT og en ingenierteknisk tankegang, og det er \u00f8nskelig med erfaring fra IT. N\u00e5r man velger slike spesialister, vil det v\u00e6re en tydelig fordel \u00e5 ha designferdigheter ved bruk av moderne verkt\u00f8y.<\/p>\n
Dermed ser vi den samme rollen (og for \u00f8vrig stillingen i stillingsplanen) \u2013 analytiker, men i ulike konkret-applikatoriske former. \u00c5 finne spesialister for hver av dem har sine egne s\u00e6regenheter. Det er viktig \u00e5 vite at disse typene analytikere ofte m\u00e5 ha sammenst\u00f8tende ferdigheter og kunnskaper i \u00e9n person. Den ene er en humanist, tilb\u00f8yelig til analytisk arbeid med store volum tekstdokumenter, med utviklet tale og kommunikasjonsevner; den andre er en 'tekniker' med ingeni\u00f8rtenkning og interesser innen IT.<\/p>\n
Skal vi ta inn folk fra utsiden eller utvikle dem selv?<\/h2>\n \nFor en stor akt\u00f8r innen IT-industrien reduseres effektiviteten av direkte rekruttering fra internettressurser n\u00e5r prosjektene vokser. Dette skjer blant annet av f\u00f8lgende grunner: rask tilpasning til komplekse prosesser i selskapet er ikke mulig, og hastigheten for \u00e5 l\u00e6re spesifikke verkt\u00f8y er lavere enn prosjektets utviklingshastighet. Derfor er det viktig for HR-spesialisten \u00e5 vite ikke bare hvem de skal lete etter utenfor, men ogs\u00e5 hvordan de kan utnytte selskapets interne ressurser, og hvordan man kan utvikle spesialisten.<\/p>\n
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.<\/p>\n
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. <\/p>\n
Intersection, integration, and evolution of production roles<\/h2>\n \nThere is another complex issue from the perspective of implementation in the production process \u2013 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.<\/p>\n
I tillegg til overlapping, er det ofte sammensl\u00e5ing av produksjonsroller. For eksempel kan en forretningsanalytiker og teknisk forfatter eksistere i \u00e9n person. Tilstedev\u00e6relsen av en programvarearkitekt (Software Architect) er n\u00f8dvendig i stor industriell utvikling, mens helt sm\u00e5 prosjekter kan klare seg uten denne rollen: der utf\u00f8rer utviklerne (Software Developer) arkitektens funksjoner. <\/p>\n
Endringene i historiske perioder, tiln\u00e6rminger og utviklingsteknologier f\u00f8rer uunng\u00e5elig til at programvarelivssyklusen ogs\u00e5 utvikler seg. Globalt sett forblir de grunnleggende stadiene stort sett uendret, men detaljeringen skjer. For eksempel, med overgangen til web-l\u00f8sninger 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\u00f8rer som tilbrakte mesteparten av arbeidstiden sine p\u00e5 kundens arbeidsplasser. \u00d8kte volum og kompleksitet i programvaren f\u00f8rte til opprettelsen av rollen som programvarearkitekt (Software Architect). Kravene til raskere versjonsutgivelser og \u00f8kt programvarekvalitet har bidratt til utviklingen av automatisert testing og opprettelsen av en ny rolle - QA-ingeni\u00f8r (Quality Assurance Engineer), osv. Evolusjonen av roller gjennom alle faser av produksjonsprosessen er betydelig knyttet til utviklingen av metoder, teknologier og verkt\u00f8y.<\/p>\n
Vi har n\u00e5 sett p\u00e5 noen interessante aspekter av fordelingen av produksjonsroller i programvareutviklingsbedrifter innenfor programvarelivssyklusen. Det er \u00e5penbart 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 \u00e5 fremme arbeidsgivermerket, er det ogs\u00e5 spesielt viktig \u00e5 ha et eksternt perspektiv. Her eksisterer det en stor utfordring, ikke bare med \u00e5 finne meninger, men ogs\u00e5 med \u00e5 formidle denne informasjonen til m\u00e5lgruppen.<\/p>\n
Hva er galt med \"dyrehagen\" av IT-stillinger?<\/h2>\n \nForvirringen i bevisstheten til HR-spesialister, produksjonsorganisatorer og mangfoldet av tiln\u00e6rminger f\u00f8rer til et sv\u00e6rt 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\u00e5else av meningen som burde f\u00f8lge med stillingstittelen. For eksempel, i v\u00e5r organisasjon inneb\u00e6rer stillinger med betegnelsen \"ingeni\u00f8r-analytiker\" at personen setter opp oppgaver. Men det viser seg at det ikke alltid er slik: det finnes utviklingsorganisasjoner der ingeni\u00f8r-analytikeren er en implementer. Helt annen forst\u00e5else, er du ikke enig?<\/p>\n
For det f\u00f8rste, \"dyrehagen\" av IT-stillinger reduserer utvilsomt effektiviteten i rekrutteringen. Hver arbeidsgiver som utvikler og fremmer sitt merke, \u00f8nsker \u00e5 formidle alle meningene som finnes i produksjonen sin p\u00e5 en kort og presis m\u00e5te. Hvis de selv ofte ikke kan si klart hvem som er hvem, vil det naturligvis resultere i usikkerhet i den eksterne kommunikasjonen. <\/p>\n
For det andre skaper \"dyrehagen\" av IT-stillinger enorme problemer n\u00e5r det gjelder oppl\u00e6ring og utvikling av IT-arbeidskraft. Hver seri\u00f8s IT-virksomhet som har som m\u00e5l \u00e5 forme og utvikle sitt menneskelige potensial, i stedet for bare \u00e5 \"melke\" jobbsider, m\u00f8ter etter hvert behovet for samarbeid med utdanningsinstitusjoner. For h\u00f8yt kvalifiserte IT-arbeidere er dette segmentet av universiteter, helst de beste, minst rangert blant de 100 beste. <\/p>\n
Problemet med integrasjon med h\u00f8yere utdanning ved oppbygging av en kontinuerlig prosess for oppl\u00e6ring av IT-spesialister ligger omtrent halvparten i mangelen p\u00e5 forst\u00e5else 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 \u00abinformatikk\u00bb i navnet, og det skjer ofte at n\u00e5r de gjennomf\u00f8rer opptaksprosedyrer, bygger de p\u00e5 en tese om at alle spesialiteter i bunn og grunn handler om det samme. Det er omtrent som \u00e5 lene seg p\u00e5 en folkslig myte om at alle IT-folk er programmerere.<\/p>\n
Erfaringen fra v\u00e5rt tette samarbeid med h\u00f8yskolene viser at spesialiteten \u00abAnvendt Informatikk (per bransje)\u00bb gir oss kandidater til avdelingene for metodikk og teknisk st\u00f8tte, men ikke til utvikling. Mens \u00abFundamentalt Informatikk\u00bb, \u00abProgramvareingeni\u00f8r\u00bb utdanner utmerket personell for utviklere. For ikke \u00e5 lede studenter ned en ubrukt vei fra starten av, er det n\u00f8dvendig \u00e5 \u00abspres t\u00e5ken\u00bb som omgir IT-produksjonen.<\/p>\n
Kan alt bringes til en felles nevner?<\/h2>\n \nKan vi standardisere produksjonsrollene og komme til en felles forst\u00e5else av dem b\u00e5de innenfor og utenfor selskapet? <\/p>\n
Selvf\u00f8lgelig kan og m\u00e5 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\u00f8ydepunkt 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\u00e5dan, som skjer med forbedring av teknologier og verkt\u00f8y, samt med utviklingen og opphopning av forretningsoppgaver.<\/p>\n
Samtidig er det vanskelig \u00e5 standardisere produksjonsroller, fordi IT er en av de yngste og mest dynamiske n\u00e6ringene i \u00f8konomien. P\u00e5 en viss m\u00e5te er dette et kaos, hvor universet har oppst\u00e5tt. En klar organisatorisk struktur er umulig og malplassert her, fordi IT er et intellektuelt, men ogs\u00e5 veldig kreativt felt. P\u00e5 den ene siden er IT-folk \u00abfysikere\u00bb med utviklet algoritmisk og matematisk tenkning, p\u00e5 den annen side er de \u00ablyriske\u00bb skapere, b\u00e6rere og promot\u00f8rer av ideer. Akkurat som en kunstner har de ikke en klar plan for \u00e5 male et bilde, de kan ikke dekomponere motivet, for s\u00e5 vil det slutte \u00e5 eksistere. De er herskere over informasjonsprosesser som i seg selv er abstrakte, uh\u00e5ndgripelige, vanskelig m\u00e5lbare, men hurtige. <\/p>\n
Veier til effektiv rekruttering i IT-produksjon<\/h2>\n \nS\u00e5, hva er viktig for HR-spesialister \u00e5 vite for \u00e5 bygge effektiv rekruttering i lys av mangfoldet av roller i IT-produksjonen.<\/p>\n
For det f\u00f8rste m\u00e5 enhver HR-spesialist i et IT-selskap ha en forst\u00e5else av situasjonen som er karakteristisk for sitt foretak: hvem som gj\u00f8r hva, hvem som har hvilke titler, og viktigst av alt \u2013 hvilken mening som legges i disse rollene innenfor den spesifikke produksjonen.<\/p>\n
For det andre m\u00e5 HR-spesialisten ha en fleksibel forst\u00e5else av produksjonsrollene. Det vil si at de i utgangspunktet danner seg et ideelt bilde av dem som gj\u00f8r at de selv kan navigere gjennom alt. Deretter m\u00e5 det ogs\u00e5 v\u00e6re et realistisk bilde av produksjonen: hvor og hvordan rollene overlapper, forenes, og hvilket syn p\u00e5 disse rollene som eksisterer hos produksjonsledere. Utfordringen for HR-spesialisten ligger i \u00e5 forene i sin bevissthet den reelle og ideelle situasjonen, ikke fors\u00f8ke \u00e5 tvinge prosessene til \u00e5 tilpasse seg den ideelle forst\u00e5elsen, men \u00e5 hjelpe produksjonen i \u00e5 tilfredsstille behovet for ressurser.<\/p>\n
For det tredje er det viktig \u00e5 ha en forst\u00e5else av mulige utviklingsbaner for ulike spesialister: n\u00e5r eksterne rekrutteringer kan v\u00e6re effektive, og n\u00e5r det er bedre \u00e5 utvikle ansatte internt, og gi dem muligheter for vekst, hvilke egenskaper kandidater m\u00e5 ha for \u00e5 utvikle seg i en bestemt retning, hvilke egenskaper som ikke kan v\u00e6re forenlige i \u00e9n person, og hva som er viktig for \u00e5 velge utviklingsbane.<\/p>\n
For det fjerde, la oss g\u00e5 tilbake til p\u00e5standen om at IT er et felt for h\u00f8yt kvalifiserte medarbeidere, der tidlig integrering med universitetsutdanningsmilj\u00f8et er uunng\u00e5elig for mer effektiv personalarbeid. I denne situasjonen m\u00e5 hver HR-spesialist utvikle ikke bare ferdigheter innen direkte s\u00f8k, arbeid med s\u00f8knader og intervjuing, men ogs\u00e5 ha en god forst\u00e5else av universitetsutdanningen av fagfolk: hvilke universiteter utdanner kandidater for selskapet, hvilke spesialiteter innen de bestemte universitetene tilfredsstiller personalbehov, og hvem som st\u00e5r bak dette, hvem leder og s\u00f8rger for utdanningen av spesialister ved universitetene.<\/p>\n
Dermed, for m\u00e5lrettet \u00e5 avkrefte myten om at alle IT-folk er programmerere, m\u00e5 et helt sett med tiltak gj\u00f8res i denne retningen, og s\u00e6rlig ta hensyn til v\u00e5re universiteter, hvor grunnlaget for oppfatningen av fremtidige yrker legges. Med andre ord, det trengs kontinuerlig interaksjon med utdanningsmilj\u00f8et, for eksempel ved \u00e5 bruke moderne former for samarbeid i co-working-sentre, 'sistykk-punkter', deltakelse i utdanningsintensiver. Dette vil bidra til \u00e5 bryte ned feil oppfatninger om IT-virksomheter, \u00f8ke effektiviteten av personalarbeidet og skape betingelser for samarbeid ved utdanning av ulike spesialister i v\u00e5r bransje.<\/p>\n
Jeg takker kollegene som deltok i forberedelsen og oppdateringen av denne artikkelen: Valentina Vershinina og Yuri Krupin.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041d\u0430 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u043f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u043e\u0439 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0431\u043b\u044e\u0434\u0430\u0442\u044c \u043c\u043d\u043e\u0433\u043e\u043e\u0431\u0440\u0430\u0437\u0438\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0445 \u0440\u043e\u043b\u0435\u0439. \u0418\u0445 \u0447\u0438\u0441\u043b\u043e \u0440\u0430\u0441\u0442\u0435\u0442, \u043a\u043b\u0430\u0441\u0441\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u0435\u0442\u0441\u044f \u0441 \u043a\u0430\u0436\u0434\u044b\u043c \u0433\u043e\u0434\u043e\u043c, \u0438, \u0435\u0441\u0442\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u044e\u0442\u0441\u044f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b \u043f\u043e\u0434\u0431\u043e\u0440\u0430 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043a\u0430\u0434\u0440\u043e\u0432\u044b\u043c \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u043e\u043c. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 (\u0418\u0422) \u2013 \u044d\u0442\u043e \u0441\u0444\u0435\u0440\u0430 \u0432\u044b\u0441\u043e\u043a\u043e\u043a\u0432\u0430\u043b\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0442\u0440\u0443\u0434\u043e\u0432\u044b\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0438 \u043a\u0430\u0434\u0440\u043e\u0432\u043e\u0433\u043e \u0434\u0435\u0444\u0438\u0446\u0438\u0442\u0430. \u0417\u0434\u0435\u0441\u044c \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0432\u044b\u0440\u0430\u0449\u0438\u0432\u0430\u043d\u0438\u044f \u043a\u0430\u0434\u0440\u043e\u0432, \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u044c \u043f\u043b\u0430\u043d\u043e\u043c\u0435\u0440\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u043a\u0430\u0434\u0440\u043e\u0432\u044b\u043c \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b\u043e\u043c \u0431\u044b\u0432\u0430\u044e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-52799","post","type-post","status-publish","format-standard","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Hvem](\"\/wp-content\/uploads\/2019\/11\/87c543e0ad54a289a116a78d0eba6430.jpeg\")