
Kadr nga filmi "Harry Potter dhe Këndi i Azkabanit"
Problemi i këtij dunia është se njerëzit e edukuar janë plot dyshime, ndërsa idiotët janë plot besim.
Charles Bukowski
Së fundmi, zhvillova një mësim individual rreth programimit. Ndryshe nga mësimet e zakonshme, tema nuk ishte struktura e gjuhës as problemi i zgjidhjes së një detyre. Studentin e shqetësonte e ardhmja e punësimit. Ai vetë ishte mjaft i zgjuar. Një nga ata që vijnë në kurse, përfundon programin më shpejt se të tjerët dhe me zgjidhje origjinale, por gjithmonë e nënvlerëson veten. Në opinionin tim, këto dyshime dalin vetëm nga mungesa e informacionit. Unë përpiqesha ta plotësoj këtë boshllëk spontanisht gjatë mësimit.
Pyetjet ishin përafërsisht këto:
- Çdo vit, shumë studentë dalin nga universitetet dhe të gjithë shkojnë të kërkojnë punë. Kjo është një shumë njerëzish. Sigurisht, do të marrin më të mirët, dhe unë nuk do të kem vend.
- Çfarë nëse bëj ndonjë gabim dhe më shkarkojnë menjëherë?
- Çfarë nëse gjatë punës ata kuptojnë se jam budalla dhe më përzënë?
Ky student nuk ishte personi i parë që iu përgjigja pyetjeve të tilla. Ato dalin te shumë njerëz, dhe zakonisht duhet të flas pa përgatitje. Këtë herë vendosa të regjistroj mendimet e mia në një blloknot. Mendova se do të dalin disa paragrafë, por mblodha një artikull të tërë.
Në artikull është përshkruar një pikëpamje nga këndvështrimi im dhe në bazë të përvojës sime. Megjithatë, bota jonë është shumë e larmishme dhe ndodhin gjëra befasuese. Nëse nuk jeni dakord me diçka ose përvoja juaj është ndryshe, ju lutem shkruani një koment.
Artikulli është shkruar nga një zhvillues për zhvilluesit. Megjithatë, nëse planifikoni të merreshi me testimin, administrimin ose diçka tjetër në IT, disa nga këshillat do t'ju bien në përdorim.
Në përgjithësi nuk do të punësojnë
Kur imagjinoni se çdo vit, shumë universitete dalin qindra studentë, ndiheni paksa të pakëndshme. Si mund të konkurrosh me një tur kështu të madh?
Fatkeq, jo të gjithë të diplomuarit kanë përgatitjen teknike të mjaftueshme. Provoni të pyesni ndonjë njohur student nga universiti: si e arrijnë ata që të kalojnë provimet për disiplina si "bazat e të dhënave" ose "themelët e algoritmizimit dhe programimit"? Në një grup prej 30 personash, në rastin më të mirë do të ketë 3-5 djem "të avancuar", që kanë bërë gjithçka vetë. Të tjerët thjesht kopjojnë nga ata, mësojnë përgjigje për pyetje dhe kalojnë.
Kështu ndodhte kur isha dhe unë në shkollë. Megjithatë, përvoja ime mund të mos jetë reprezentative. Prandaj, këtë pyetje ia kam bërë disa studentëve të ndryshëm. Përgjigjja ka qenë përafërsisht e njëjtë. Të anketuarit ishin nga universitete dhe kolegje të ndryshme. Arsyet që qëndrojnë pas kësaj, do t'i lë jashtë këtij shkrimi. Një hulumtim të plotë nuk do të mund ta realizoj, prandaj do të nxjerr përfundime nga faktet ekzistuese.
Ndër qindra të diplomuar, vetëm disa dhjetëra përbëjnë interes për punëdhënësit.
Pak të diplomuar mund të krijojnë një konkurrencë reale për një student të talentuar me përgatitje të mirë. Megjithatë, edhe nëse keni studiuar me ndershmëri, është shumë e mundshme që pas intervistës së parë të mos ju punësojnë. Pas të dytës, ndoshta po ashtu. Mund të shkojnë gjërat mirë, megjithatë është më mirë të përgatiteni jo për një sulm, por për një rrethim. Një përpjekje e dështuar për t'u punësuar është vetëm një arsye për të bërë analiza të gabimeve dhe për të provuar përsëri. Nuk do të flas për përgatitjen për intervista. Ka shumë informacion për këtë në internet. Thjesht do të them se në kalimin e intervistave ka nuanca, për shpjegimin e të cilave në programin tuaj të studimeve s'ka pasur kohë. Kërkoni këtë informacion vetë, mund të zvogëloni numrin e përpjekjeve.
Çmenduri është përsëritja e saktë e veprimit të njëjtë. Herë pas here, me shpresën për ndryshim.
Albert Einstein
Që kalimi i intervistave të mos shndërrohet në çmenduri, pas çdo përpjekjeje të re duhet të bëheni më mirë. Mbani mend ose shkruani pyetjet që ju bënë gjatë intervistës. Kur të keni arritur në shtëpi, shqyrtoni këtë listë dhe kontrolloni veten me ndihmën e internetit. Kështu do të kuptoni se ku gabuat ju, dhe ku – intervistuesi. Kjo ndodh ndonjëherë. Rregulloni ose mësoni temat, në të cilat keni përgjigjur dobët, dhe provoni përsëri.
Për më tepër, ekziston një sezon të theksuar në tregun e punës. Kompanitë e mençura planifikojnë rekrutimin duke marrë parasysh datat e diplomimit nga institucionet arsimore. Në pranverë, ka më shumë vende pune për fillestarët sesa në kohë të tjera. Megjithatë, konkurrenca është gjithashtu më e lartë në këtë kohë.
I paditur – do të largohen
Kur pranojnë një person pa përvojë në punë, ekzistojnë pritshmëri përkatëse ndaj tij.
Nga një fillestar në punë pritet:
- Njohuri të bazës teknike të përgjithshme
- Studimi i veçorive të fushës së specializimit të kompanisë
- Zhvillimi i mjeteve dhe praktikave të përdorura
Në disa organizata, ofrohen kurse trajnimi për fillestarët mbi teknologjitë, mjetet dhe rregullat lokale që përdoren. Për shembull, rregullat e mirësjelljes në përdorimin e postës elektronike të kompanisë, procedurat për ndryshimin e dokumenteve në wiki, veçoritë lokale të punës me VCS dhe sistemin e ndjekjes së defekteve.
Ekzistojnë gjithashtu kurse teknike hyrëse, por dobia e tyre është e dyshimtë. Nëse arriti deri te punësimi, kjo do të thotë që punëdhënësit janë bindur se keni një nivel të mjaftueshëm njohurish. Më mirë do të ishte thjesht t'i kaloni ato kurse me ndershmëri, si një formalitet të vogël. Ndoshta do të ketë diçka të dobishme në to.
Kur të filloni punën, mbani mend se fillestarët sigurisht nuk do t’u ngarkohen detyra urgjente, komplekse dhe njëkohësisht të rëndësishme. Probabilisht do të ketë vetëm një nga këto veti. Ose e thjeshtë, por urgjente: të korigjoni layoutin, të dërgoni ndonjë skedar, të riprodhoni një problem. Ose komplekse, por pa asnjë shpresë për përfundim — për t'i dhënë fillestarit një grumbull përvojash. Ose e rëndësishme, por eksperimentale. Për shembull, një projekt që të gjithë e kanë dëshiruar për një kohë të gjatë, por nuk kanë mundur të gjejnë kohë për ta realizuar.
Detyrat për zotërimin e mjeteve do të jenë 'të komplikuara' dhe artificiale. Probabilisht do të jetë një variant i thjeshtëzuar i sistemit kryesor. Në detyra të tilla, përdoren të njëjtat grumbuj teknologjish dhe terminologji nga fusha e specializimit, ashtu si në të gjithë projektin. Megjithatë, rezultati i realizimit nuk do t’i dorëzohet përdoruesit përfundimtar. Kjo mund të demotivon, por është më mirë të përballeni me këtë ndjenjë. Një detyrë artificiale duhet të bëhet me përkushtim, sikur të varet fati i projektit nga ajo.
Rezultati i zgjidhjes së detyrës tuaj të parë do të bëjë një përshtypje të parë te kolegët tuaj që nuk ishin në intervistë.
Një tjetër variant i detyrës për të mësuar mjetet është "të nisni një projekt në makinën lokale / ambientin testues". Ndonjëherë ky proces përshkruhet në udhëzime. Por ato, zakonisht, janë të vjetra dhe në disa vende joaktuale. Mund të sjellë përfitim të vërtetë për projektin, nëse shkruani një udhëzim të ri me sqarime për problemet që kanë lindur. Sigurisht që në universitet keni pasur raste kur keni shkruar raporte për ndonjë disiplinë. Këtu është pothuajse e njëjtë. Dokumenti duhet të përmbajë veprimet që duhet të kryhen për të nisur.
Zakonisht veprimet për të nisur produktin në ambientin testues janë afërsisht këto:
- klononi depozitat, kaloni në ndonjë degë ose etiketë
- përgatitni ndonjë skedë konfigurimi
- përgatitni strukturën e databazës
- mbusheni atë me të dhëna testuese
- kryeni ndërtimin ose kompilimin e projektit,
- nisni një set skenarësh konsolë në një rend të caktuar
Në procesin e lançimit të sistemit lokal, padyshim do të shfaqen probleme të paparashikuara.
Zgjidhjet e gjetura të problemeve duhet të shtohen në udhëzimin për vendosjen. Kështu që herën tjetër, duke ndjekur udhëzimin, këto probleme nuk do të shfaqen më. Kur plotësoni skedat e konfigurimit dhe thërrisni skenarët, duhet të vëreni se çfarë vlera përdoret ku dhe me çfarë duhet të përputhet. Për shembull, nëse projekti ndërtuohet me ndihmën e sistemit CI dhe pastaj niset me një skenar, është e rëndësishme të kuptohet ku të shkruhet emri i degës ose numri i komitit. Ka raste kur skenari nënkupton kalimin Adresa IP ose emrit DNS të databazës, emrit të saj dhe fjalëkalimit. Në këtë rast, duhen ditur se cili adresë duhet të përdoret për ambientin testues, cilat janë emrat e atje dhe cilat janë fjalëkalimet për to.
Disa detyra mund të duken të thjeshta për zhvilluesit e përvojshëm dhe të shkaktojnë vështirësi për stazhierët. Kjo është një dukuri normale.
Zhvilluesit përballen çdo ditë me probleme teknike. Punonjësit me përvojë kanë zgjidhur shumë probleme më parë, ndërsa të rinjtë vetëm se do të përballen me to. Taktika më e mirë do të ishte të regjistroni të gjitha gabimet e hasura në dokumentin "zgjidhja e problemeve me ${emrin e detyrës}". Për çdo problem, duhet formuluar një hipotezë për shkakun, të kërkohen zgjidhje në internet dhe të provohen ato një pas një. Rezultati i çdo përpjekjeje duhet gjithashtu të regjistrohet.
Formalizimi i hulumtimeve tuaja në formë dokumenti do të lejojë:
- të shkarkoni detajet e vogla nga mendja. Për shembull parametrat e konfigurimit, adresat DNS/IP, komandat e konsolës dhe pyetjet SQL.
- të kujtoni "çfarë kam bërë dje" kur detyra shtrihet në disa ditë
- të mos endesh rreth e rrotull. Ju gjithmonë mund të lexoni atë që keni bërë më parë dhe të kuptoni se keni rikthyer në problemin fillestar
- të përgjigjeni qartë në pyetjen: "çfarë ke bërë sot?" edhe nëse nuk kemi ende një zgjidhje të gatshme.
Ju duhet të jeni në gjendje të tregoni statusin e detyrave tuaja kolegëve
Herë pas here, kolegët do të jenë të interesuar për arritjet tuaja dhe do të ndajnë të tjerat. Për këtë, çdo ditë ose çdo javë jepni pak kohë.
Nëse nuk ndjekni problemet e hasura dhe të zgjidhura, përshkrimi i arritjeve tuaja do të duket si: "provova të bëj detyrën, por nuk e arrita. Aktualisht po kërkoj zgjidhje." Nga ky përshkrim nuk është e qartë nëse stazhi po bënte ndonjë gjë ose thjesht po lexonte Habra. A ka nevojë për ndihmë? A ka ndryshuar situata nga dje?
Nëse mbani një dokument me kërkimin e zgjidhjeve, do të mund të thoni "po përpiqem të bëj këtë detyrë. Kam hasur këto gabime. Këto i zgjidhja kështu. Për këtë akoma nuk kam përfunduar. Kam këto hipoteza dhe mundësi zgjidhjeje. Tani po i kontrolloj."
Nëse detyra mund të matet në ndonjë mënyrë, atëherë në status duhet të përmenden numra. Për shembull për detyrën "të shkruaj teste njësite për modul" mund të thuhet "planifikoj të bëj 20 teste, aktualisht kam shkruar 10".
Sa më shumë detaje të komunikoni, aq më mirë kolegët tuaj do të kuptojnë çfarë keni bërë. Kjo do të formojë një qëndrim pozitiv ndaj jush dhe do t'u lejojë atyre të kuptojnë nëse ju nevojitet ndihmë apo jo.
Mos hezitoni të kërkoni ndihmë
Më parë kam shkruar se kur ndodhin probleme, ju nevojitet të formuloni një hipotezë rreth shkaqeve të saj dhe opsioneve për zgjidhje. Sidoqoftë, ndodh që hipotezat nuk realizohen dhe zgjidhjet e gjetura nga vetja nuk funksionojnë. Në atë rast, është më mirë të kërkoni ndihmë. Për të mos keqinterpretuar vëmendjen e kolegëve, duhet të përqendroheni gjithmonë në çdo problem nga vetja. Nëse pas disa orësh nuk keni arritur të gjeni një zgjidhje, është koha të kërkoni këshilla nga kolegë më të përvojshëm.
Mënyra më e mirë për të filluar është me pyetjen: "A ka përballur ndokush më parë me këtë problem?" me një përshkrim të shkurtër të problemit. Preferohet të bashkëngjitni një pjesë të mesazhit të gabimit ose një skrinë. Ky mesazh për herë të parë është më mirë të dërgohet në ndonjë bisedë të përgjithshme në punë. Kështu nuk e ndërprisni punën e atyre që vërtet janë të angazhuar. Koleget e lirë do ta shohin mesazhin tuaj dhe do të mund të ndihmojnë.
Nëse pas mesazhit në bisedën e përgjithshme askush nuk ka ndihmuar, provo të kapësh një koleg të përvojshëm gjatë një pushimi: në drekë, kur shkon për çaj/kafe, gjatë një loje tenisi ose një pushimi për duhan. Nëse kjo nuk funksionon, atëherë thuaj për vështirësitë e tua gjatë takimit ose qëndrës së përbashkët.
Për zgjidhjen e problemeve të njohura, kështu mund të mbyllet gjithçka. Nëse problemi është i ri, atëherë do të fillojë një hetim, ku do të duhet të veproni sipas rrethanave.
"Detyrat e ' rëndësishme' për fillestarët, të cilat nevojiten për përdoruesit e fundit, do të jenë të mërzitshme dhe të vogla. Për shembull, "shto një kolonë shtesë në raport" ose "korigjo një gabim në formatin e printuar" ose "implemento një metodë modeli për të ngarkuar atributet e klientit nga DBMS". Qëllimi i këtyre detyrave është që fillestari të njohë fushën e subjektit dhe të integrovë në punën e përditshme.
Është e rëndësishme jo vetëm të zgjidhni teknikisht problemin, por edhe të zgjerojeni njohuritë e fushës.
Në përshkrimin e detyrave, në biseda dhe në bisedat do të hasni terma. Ato mund të duken si emra të njohur që prej kohësh. Megjithatë, brenda sistemit informacioni, ato marrin një kuptim të veçantë dhe më të saktë. Mënyra më e mirë për të regjistruar kuptimin e terma të zbuluar është të krijoni një dokument të veçantë — fjalorin e terma. Kur e shtoni në fjalor, mjafton të shkruani kuptimin tuaj të fjalës, ndërsa për një shpjegim të saktë është më mirë të kërkoni te analisti. Nëse ai nuk është i pranishëm, atëherë te veteranët e projektit. Mbajtja e fjalorit të terma është një nga mënyrat më të thjeshta për t'u njohur me fushën e projektit.
Sapo të gjeni një gjuhë të përbashkët me kolegët, ata do të fillojnë t'ju shohin si një specialist të barabartë dhe jo si një fillestar.
Ka detyra të veçanta, për shembull "shkruaj testet e njësisë për modul". Ajo në të vërtetë nuk ndihmon shumë në kërkimin e zgjidhjeve për një kohë të gjatë. Megjithatë, ajo është mjaft serioze dhe jepet jo vetëm për trajnimin e praktikantëve. Testet e shkruara rrisin stabilitetin e projektit duke reduktuar defektet në aplikacion dhe duke ulur kohën e testimit nga njerëzit. Në një botë ideale, testet e njësisë shkruhen menjëherë gjatë zhvillimit, por realiteti është gjithnjë ndryshe. Ndonjëherë zhvilluesi i modulit e mban plotësisht në mendje atë dhe nuk sheh nevojën për t'i shkruar. "Është e qartë se çfarë duhet testuar këtu?" Ndonjëherë modulet shkruhen në një gjendje emergjente dhe nuk ka kohë për testet e njësisë. Pra, në botën reale, mund të mos ketë teste të njësisë. Prandaj, detyra për të shkruar testet e njësisë i besohet fillestarit. Kështu, praktikanti mund të integruar më shpejt në projekt, ndërsa projekti mund të kursejë kohë e burime të specialisteve më të paguar.
Ndonjëherë praktikantëve dhe fillestarëve u jepen rolet si testues të plotë. Normalisht, para kësaj është e nevojshme të zhvilloni produktin lokal dhe të lexoni kërkesat. Si rezultat nga punonjësi i ri priten:
- pyetje si "nëse bëmë kështu, atëherë do të ndodhte kështu. Kjo nuk është në kërkesa. Si duhet të jetë?"
- detyrat në sistemin e ndjekjes së defekteve "në kërkesa shkruhet kështu, ndërsa në të vërtetë është ndryshe".
Testimi është një fushë tepër e gjerë për këtë artikull. Nëse ju është dhënë një detyrë e tillë, kërkoni në internet se si ta kryeni atë më mirë.
Nëse bëni gabime, do të pushoheni.
Në një organizatë normale, nëse ndodh që një punonjës i paekspert të ketë akses në diçka kritike dhe të bëjë një gabim, faji do të bjerë mbi atë që e lejoi këtë. Sepse një newcomeri zakonisht nuk ka akses në infrastrukturën kritike. Me drejtimin e duhur, askush nuk do të vendosë përgjegjësinë mbi një praktikant të paekspert.
Nëse ndodh ndonjë incident, nuk do të përjashtojnë për një incident të vetëm. Nga gabimet njerëzit mësojnë. Një praktikant që bëri një gabim mori një mësim të çmuar dhe kështu ndryshon ndjeshëm nga praktikantët e tjerë. Nëse përjashtoni atë që gaboi, dikush tjetër do të vijë dhe do të bëjë po të njëjtin gabim.
Gjëja kryesore është të mësojmë nga gabimet dhe të mos i përsërisim ato më.
Nëse ndonjëherë një person nuk nxjerr përfundime nga gabimet e tij, atëherë do të mundohemi të ndahemi me të. Megjithatë, bota është e ndryshme. Në një organizatë banditësh, mund të ndodhi që për një gabim të parë ta hedhin menjëherë nga dritarja. Por është më mirë të evitoni kompani të tilla, për të cilat duhet të bëni disa pyetje ose të mësoni më shumë gjatë intervistës.
Incidentet është më mirë të mos ndodhin.
Edhe nëse nuk do të hiqni dorë personalisht për një gabim, një incident të tillë do të sjellë probleme të padëshiruara për ekipin tuaj dhe për projektin përgjithësisht. Prandaj, jini veçanërisht të kujdesshëm me operacionet e fshirjes ose krijimit të tabelave në bazën e të dhënave, skedarëve, instancave të shërbimeve dhe dokumenteve në bazën e njohurive për projektin. Nëse hasni një adresë të re për lidhje, sqarohuni të paktën me dy njerëz të ndryshëm se çfarë është e mundur të bëni aty. Kontrolloni të drejtat tuaja në ambientet e punës jo me metodën e provave dhe gabimeve, por me komandat përkatëse. Për shembull, të drejtat për fshirjen e skedareve me komandën `ls`, të drejtat për punë me tabelat në mysql me komandën `SHOW GRANTS FOR ‘user’@’host’;` dhe të ngjashme. Praktikisht në çdo mjet do të keni një mundësi të tillë.
Kur editojmë skedarë, për çdo rast, ruani një kopje origjinale për vete.
Në mes të praktikantit dhe konsumatorit përfundimtar vendosen disa barrierë.
Nëse do të ishit në gjendje ta jepnit produktin tuaj menjëherë te konsumatori, do të kishit mundur të mos punoni, por të niseshit në 'lundrimin e lirë'. Por derisa nuk keni një mundësi të tillë (dhe gjithashtu përgjegjësinë), ju duhet të kaloni disa faza kontrolli në projekt.
E para e parë është kontrolli nga mentori. Ai vlerëson zgjidhjen e fillestarit nga një këndvështrim teknik. Nëse mentori nuk është emëruar, duhet ta gjesh atë. Për këtë, duhet të zgjedhësh dikë nga veteranët e projektit dhe gjatë pauzës ta pyesësh të shohë zgjidhjen: a është zgjidhur problemi saktë? Nëse fillon të shikojë dhe të përgjigjet, atëherë mentori është gjetur. Nëse e injoron, atëherë duhet të pyesësh dikë tjetër.
Faza tjetër është Sigurimi i Cilësisë. Në shqip, testuesit. Në mënyrë sovjetike, normalizimi dhe KTK. Ata duhet të sigurohen që rezultati i punës së praktikantit përputhet me detyrën e caktuar për të. Rrallë do të thellohem në kod. Më së shpeshti, testuesit do të kontrollojnë projektin e mbledhur që zhvilluesi ruan në sistemin e kontrollit të versioneve.
Faza e tretë është menaxheri i lançimit. Ndoshta nuk do të ketë një person të veçantë për këtë detyrë, por dikush do ta luajë rolin. Ai kontrollon që testuesit të konfirmojnë se projekti mund të lëshohet. Pas kësaj, ai kryen veprimet për dorëzimin e produktit te përdoruesit e fundit.
Në organizatat e vogla, këto barriera mund të mungojnë për shkak të arsyeve të ndryshme. Megjithatë, ata nuk do t'i japin fillestarit një detyrë për të ndryshuar diçka të rëndësishme. Sepse ky rrezik nuk është i nevojshëm për askënd.
Duhet së pari të përfshihesh në betejë, dhe pastaj do të duket.
Napoleon Bonaparte
Shpresoj që artikulli të ndihmojë të kapërceni pasigurinë tuaj dhe të dërgoni CV-në tuaj të parë. Natyrisht, duhet të përgatiteni më parë. Por nuk duhet ta zgjatni shumë. Ndoshta keni studiuar tashmë disa vjet në universitet ose kolegj. Sa më shumë të presësh? Në fund të fundit, është më mirë të dëgjosh një "jo" nga një specialist dhe të punosh mbi gabimet, sesa të thuash çdo ditë "jo" vetes dhe të ndalesh në rritjen profesionale.
Pasi të punësohesh, duhet të përqendrohesh në kalimin nga praktikant në një anëtar të plotë të ekipit. Një rritje e tillë zakonisht shoqërohet me rritjen e pagës tuaj.
Të uroj durim dhe këmbëngulje.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
Cilat ishin detyrat tuaja të para në punën e parë në IT?
Të komplikuara
Të rëndësishme
Të menjëhershme
Asnjë nga të mësipërmet
75 përdorues kanë votuar. 20 përdorues janë abstenuar.
Çfarë përllogaritje keni bërë në fillim në punën tuaj të parë?
Instaloni produktin lokalisht
Testoni produktin ekzistues
Kryeni një detyrë provuese, jo të vërtetë
Merrni pjesë në një projekt eksperimental, të vërtetë për klientin
63 përdorues votuan. 25 përdorues përmbahen.
Sa studentë në grupin tuaj gjatë mësimit kishin mundësi të bënin detyrat e lëndëve teknike vetë?
1 nga 10
1 nga 5
Çdo i dyti
Të gjithë, me disa përjashtime
70 përdorues votuan. 19 përdorues përmbahen.
Burimi: habr.com
