A Skyeng fejlesztőcsapata, amely több mint 100 főből áll, szinte teljes mértékben távmunkában dolgozik, és a szakemberekkel szembeni elvárások mindig magasak voltak: szeniorokat, fullstack fejlesztőket és középszintű szakembereket kerestünk. De 2019 elején először három junior fejlesztőt vettünk fel. Ennek több oka volt: csakis szuperképzett szakemberek felvétele nem oldja meg minden problémát, emellett az egészséges fejlesztési légkör megteremtéséhez szükség van a különböző szakmai szintű emberekre.
Amikor távmunkában dolgozik, rendkívül fontos, hogy az új ember azonnal hasznot hozzon a projekthez, hosszú tanulási és beilleszkedési folyamatok nélkül. A juniorok esetében ez nem mindig lehetséges, ráadásul a beillesztéshez a csapatba is alapos integráció szükséges, hiszen számukra minden új. Ez már külön feladat a csapatvezető számára. Ezért a tapasztaltabb és már bevált fejlesztők keresésére és felvételére összpontosítottunk. De idővel kiderült, hogy a csupán szeniorokból és fullstack fejlesztőkből álló csapatoknak is vannak saját problémái. Például ki foglalkozik azzal a rutinfeladattal, amelyhez nem szükséges a szuperképzettség és különleges tudás?
Régen, juniorok felvétele helyett, szabadúszókkal dolgoztunk.
Amíg csak kevés feladat akadt, szeniorjaink foggal-körömmel elvállalták ezeket az unalmas feladatokat, hiszen a fejlesztésnek haladnia kell. De ez nem tarthatott sokáig: a projektek növekedtek, és a rutinfeladatok száma egyre csak nőtt. A helyzet egyre inkább hasonlítani kezdett ahhoz a vicchez, amelyben a szögeket mikroszkóppal ütögetik a kalapács helyett. A példa kedvéért vegyük az aritmetikát: ha egy olyan embert von be, akinek a díja 50$/órás, olyan munkákhoz, amelyekhez egy 10$/órás munkatárs is elegendő lenne, az problémákat jelent.
A legfontosabb dolog, amit ebből a helyzetből levontunk, az az, hogy a jelenlegi paradigma, amely a legjobb szakemberek alkalmazására összpontosít, nem oldja meg a rutinfeladatainkkal kapcsolatos problémáinkat. Olyan valakire van szükségünk, aki hajlandó elvégezni azokat a munkákat, amelyeket a tapasztalt munkatársak büntetésként élnek meg, és amelyek delegálása egyszerűen nem hatékony számukra. Például Slack-chatokhoz botokat írni oktatóink és kurzusaink összeállítói számára, vagy kisebb fejlesztési projektekkel foglalkozni, amelyek belső igényeinket szolgálnák, de amelyekre a fejlesztőknek állandóan hiányzik az idejük, pedig az életet sokkal kellemesebbé tenné.
Ebben a pillanatban egy köztes megoldást dolgoztunk ki. Elkezdett szabadúszókat bevonni a projektjeinkhez. Éppen az ilyen típusú kiszolgálásra kerültek a sima és nem sürgős feladatok: valamit kijavítani, valamit ellenőrizni, valamit újraírni. A szabadúszó részlegünk elég dinamikusan fejlődött. Az egyik projektmenedzserünk összegyűjtötte a különböző projektek feladatait, és a szabadúszók között osztotta szét azokat, a meglévő teljesítési bázisunk alapján. Akkor ez jónak tűnt: eltávolítottuk a terheket a tapasztaltaktól, és ők ismét a teljes kapacitásukkal alkothattak, ahelyett, hogy alapvető dolgokkal bíbelődtek volna. Nyilvánvalóan voltak olyan feladatok, amelyeket a kereskedelmi titok miatt nem lehetett külső teljesítőkre bízni, de ezek a kérdések sokkal kisebb számban fordultak elő az összes szabadúszóra delegált feladathoz képest.
De ez nem tarthatott örökké. A cégünk szembesült azzal, hogy a szabadúszó részleg egy nehezen kezelhető szörnyeteggé alakult. A rutinfeladatok száma együtt nőtt a projektekkel, és egy idő után túl sok lett ahhoz, hogy hatékonyan elosszuk őket a külső teljesítők között. Ráadásul a szabadúszók nincsenek elmélyülve a projektek sajátosságaiban, ami folyamatos időveszteséget jelent az onboarding során. Nyilvánvaló, hogy amikor a csapatában 100+ szakmai fejlesztő van, nem tud akár ötven szabadúszót is felvenni a segítségükre, és hatékonyan irányítani a tevékenységüket. Ezen kívül a szabadúszókkal való együttműködés mindig bizonyos kockázatokkal jár, például a határidők megszegésével és más szervezési problémákkal.
Fontos megjegyezni, hogy a távmunkás és a szabadúszó két különböző entitás. A távmunkás teljes mértékben be van jegyezve a vállalatnál, kijelölt munkaidővel, csapattal, felettessel és így tovább. A szabadúszó projektmunka, amelyet elsősorban csak határidők szabályoznak. A szabadúszó, a távmunkással ellentétben, jellemzően magára van utalva, és gyengén kommunikál a csapattal. Ezért potenciális kockázatok merülhetnek fel az ilyen szolgáltatókkal való együttműködés során.
Hogyan jutottunk el a „könnyű feladatok osztályának” létrehozásához, és mi lett az eredmény?
A kialakult helyzet elemzése után arra a következtetésre jutottunk, hogy alacsonyabb képzettségű munkatársakra van szükségünk. Nem építettünk illúziókat arról, hogy az összes juniorból jövő szupersztárt nevelünk, vagy hogy tíz junior felvételének költségei néhány fillérbe kerülnek. A valóság a juniorokkal kapcsolatban a következő:
- Rövid távon gazdaságilag nem éri meg őket felvenni. Az öt-tíz junior „most” helyett inkább vegyünk fel egy senior-t, és fizessünk neki milliókat a minőségi munkáért, mintsem a költségvetést kezdőkön pazarolni.
- A junioroknak hosszú belépési és tanulási időszakuk van a projektekbe.
- Abban a pillanatban, amikor egy junior megtanul valamit és már a „befektetéseket” kellene elkezdenie megtéríteni az első hat hónap munkája alatt, fel kell emelni a mid szintre, vagy másik céghez távozik ezen a pozíción. Tehát a juniorok felvétele csak érett szervezetek számára megfelelő, akik hajlandók befektetni beléjük anyagilag anélkül, hogy rövid távon nyereségre számítanának.
De elértük azt a szintet, amikor a csapatban juniorok nélkül nem tudunk előre lépni: a rutinfeladatok száma nő, és vétek szakmai órákat pazarolni rájuk. Ezért hoztunk létre egy osztályt kifejezetten a junior fejlesztők számára.
A könnyű feladatok osztályában végzett munka időtartama három hónapra korlátozódik, vagyis ez a standard próbaidő. Három hónap teljes mértékben megfizetett munka után az újoncot vagy beosztják abba a csapatba, amely szeretné látni junior fejlesztőként, vagy elválunk tőle.
A tapasztalt projektmenedzser irányítja a létrehozott részlegünket, aki felelős a munkafeladatok elosztásáért a juniorok között és a csapatok közötti együttműködésért. A junior egy feladatot kap, elvégzi azt, majd visszajelzést kap a csapattól és a vezetőjétől is. Az egyszerű feladatok megoldásának szakaszában nem rendeljük a kezdőket konkrét csapatokhoz vagy projektekhez — hozzáférést kapnak az összes munkafeladathoz a képességeik alapján (jelenleg AngularJS front-end fejlesztőket és PHP back-end fejlesztőket keresünk, illetve webfejlesztői pozícióra jelölteket, akik mindkét nyelven jártasak) és dolgozhatnak egyszerre több projekten is.
De a juniorok alkalmazása nem merül ki ennyiben — számukra megfelelő munkakörülményeket is kell teremteni, ami már egy egészen másik feladatsor.
Az első dolog, amiben egyetértettünk — az a szabadon választható mentori rendszer ésszerű keretek között. Vagyis azon túl, hogy senkit sem kényszerítettünk a mentori szerepre a meglévő szakemberek közül, világosan meg lett határozva, hogy az új kolléga képzése nem helyettesítheti az alapfeladatait. Nincs „50% időt dolgozunk, 50% időt tanítunk juniorokat”. Annak érdekében, hogy világos képet kapjunk arról, mennyi időt igényel a mentorálás, egy kis „tantervet” állítottunk össze: a feladatok listája, amelyet minden mentorának el kellett végeznie a tanítványával. Ugyanezt elvégeztük a juniorok projektmenedzserével is, és végül egy nagyon sima és érthető forgatókönyvet kaptunk az újoncok felkészítésére és a munkába való beilleszkedésük elősegítésére.
A következő szempontokat vettük figyelembe: a elméleti tudás ellenőrzése, készítettünk egy anyagokból álló csomagot, ha a juniornak még szüksége van valamire, és hogy a mentorok számára egységes kódellenőrzési elveket hagytunk jóvá. Minden lépésnél a vezetők visszajelzést adnak az újoncnak, ami rendkívül fontos. A fiatal munkavállaló érti, hogy mely területeken erős, és melyekben kell jobban figyelnie. Az oktatási folyamat megkönnyítése érdekében juniorok és tapasztalt fejlesztők számára közös csevegőszobát hoztunk létre a Slack-en, így a mentor helyett más munkatársak is csatlakozhatnak az oktatási folyamatba, és válaszolhatnak kérdésekre. Mindez a juniorokkal való munka előrejelezhetővé és, ami nem mellékes, kontrollálható folyamattá teszi.
A három hónapos próbaidő letelte után a mentor végzi el a juniorral az utolsó technikai interjút, ennek eredménye alapján dől el, hogy a junior átkerülhet-e a csapatok egyikéhez, vagy sem.
Összesen
Első ránézésre a juniorok számára létrehozott részlegünk inkubátornak vagy egy különösen kialakított homokozónak tűnhet. Valójában azonban ez egy igazi részleg, teljes harci csapat összes attribútumával, amely valós, nem pedig edző jellegű feladatokat old meg.
De a legfontosabb, hogy konkrét időkeretet adunk az embereknek. Az egyszerű feladatok részlege nem egy végtelen limbo, ahol örökre meg lehet ragadni. Három hónap van kijelölve, amíg a junior egyszerű feladatokat old meg a projekteken, de lehetősége van arra is, hogy megmutassa magát és átkerüljön egy csapatba. Az új munkatársaink tudják, hogy lesz saját projektmenedzserük, mentora a szeniorok közül (vagy akár több is), valamint hogy teljesen beilleszkedhetnek egy olyan közösségbe, ahol örömmel fogadják őket és várják.
Az év eleje óta 12 junior dolgozót vettek fel az egyszerű feladatok részlegébe, és csak kettőjüket nem fogadták el a próbaidő végén. Egy másik fiú nem tudott beilleszkedni a csapatba, de mivel a munkában nagyon tehetséges — visszakerült az egyszerű feladatok részlegébe egy újabb időszakra, amely alatt reméljük, megtalálja az új csapatát. A juniorokkal való munka pozitívan hatott a tapasztalt fejlesztőinkre is. Néhányan a mentorálás időszaka után felfedezték magukban az erőt és a vágyat, hogy kipróbálják magukat csapatvezetői szerepben, mások pedig, nézve a juniorokat, fejlesztették saját tudásukat és átkerültek a középosztályból a szenior pozícióba.
Csak szélesítjük a fiatal fejlesztők toborzására irányuló gyakorlatunkat, mert ennek számos előnye van a csapat számára. A junior fejlesztők teljes mértékben távmunkában dolgozhatnak, függetlenül lakóhelyük régiójától: a fejlesztői csapataink tagjai Rigától Vlagyivosztokig élnek, és nagyszerűen boldogulnak az időeltolódással, köszönhetően a vállalaton belüli jól működő folyamatoknak. Mindez utat nyit a tehetséges emberek előtt, akik távoli városokban és falvakban élnek. Ráadásul nemcsak a szakképzés előtt álló fiatalok és diákok kerülnek szóba, hanem azok is, akik valami okból szeretnének szakmát váltani. A mi juniorunk lehet 18 vagy akár 35 éves is, hiszen a junior a tapasztalatról és a készségekről szól, nem pedig a korról.
Biztosak vagyunk benne, hogy a megközelítésünket nyugodtan alkalmazhatják más cégek is, amelyek távoli fejlesztési modellt használnak. Ez egyszerre lehetővé teszi, hogy pontosan toborozzunk tehetséges juniorokat Oroszország vagy a FÁK bármely pontjáról, miközben fejlesztjük a tapasztalt fejlesztők mentorálási készségeit is. Pénzügyileg ez a megoldás rendkívül költséghatékony, így mindenki nyer: a cég, a fejlesztőink, és természetesen a juniorok, akiknek nem kell nagyvárosokba vagy fővárosokba költözniük ahhoz, hogy tapasztalt csapat részesévé váljanak és érdekes projekteken dolgozhassanak.
Forrás: habr.com
