Tehniline juht Skyeng Kirill Rogovoy () peab konverentsidel ettekande, milles räägib oskustest, mida peaks iga hea arendaja arendama, et saada parimaks. Palusin tal seda lugu Habra lugejatega jagada, annan sõna Kirillile.
Müüt hea arendaja kohta on see, et ta:
- Kirjutab puhta koodi
- Tunneb palju tehnoloogiaid
- Kodeerimisülesannete kiirem
- Teab hunnikut algoritme ja disainimustreid
- Saab mis tahes koodi ümber kujundada, kasutades puhast koodi
- Ei raiska aega programmeerimisega mitteseotud ülesannetele
- 100% teie lemmiktehnoloogia meister
Nii näeb HR ideaalseid kandidaate ja vastavalt sellele näevad ka vabad töökohad välja sellised.
Kuid minu kogemus ütleb, et see pole väga tõsi.
Esiteks kaks olulist lahtiütlemist:
1) minu kogemus on tootetiimid, st. ettevõtted oma tootega, mitte allhankega; allhanke puhul võib kõik olla väga erinev;
2) kui olete juunior, siis kõik nõuanded ei kehti ja teie asemel keskenduksin praegu programmeerimisele.
Hea arendaja: tegelikkus
1: keskmisest parem kood
Hea arendaja teab, kuidas luua lahedat arhitektuuri, kirjutada lahedat koodi ja mitte teha liiga palju vigu; Üldiselt läheb tal keskmisest paremini, kuid ta ei kuulu spetsialistide esi 1% hulka. Enamik lahedamaid arendajaid, keda ma tean, ei ole nii suurepärased kodeerijad: nad on selles suurepärased, mida nad teevad, kuid nad ei suuda teha midagi ülimalt erakordset.
2: lahendab probleeme, mitte ei loo neid
Kujutagem ette, et peame projekti integreerima välisteenuse. Saame tehnilised kirjeldused, vaatame dokumentatsiooni, näeme, et seal on midagi vananenud, saame aru, et peame läbima lisaparameetrid, tegema mõned kohandused, proovime seda kõike kuidagi rakendada ja paneme mõne kõvera meetodi õigesti tööle, lõpuks paari pärast päevade jooksul saame aru, et me ei saa niimoodi jätkata. Arendaja tavakäitumine selles olukorras on äri juurde naasmine ja öelda: „Ma tegin seda ja teist, see ei tööta nii ja see ei tööta üldse, nii et mine mõtle ise välja. ” Ettevõttel on probleem: peate juhtunusse süvenema, kellegagi suhtlema ja püüdma seda kuidagi lahendada. Katkine telefon hakkab tööle: "Ütle talle, ma saadan talle sõnumi, vaata, mis nad vastasid."
Hea arendaja leiab sellise olukorraga silmitsi seistes ise kontaktid, võtab temaga telefoni teel ühendust, arutab probleemi ja kui midagi ei aita, siis kogub õiged inimesed kokku, selgitab kõike ja pakub alternatiive (tõenäoliselt on mõni muu). parema toega välisteenus). Selline arendaja näeb äriprobleemi ja lahendab selle. Tema ülesanne on suletud, kui ta lahendab äriprobleemi, mitte siis, kui ta millegi otsa satub.
3: Püüab kulutada minimaalseid jõupingutusi maksimaalse tulemuse saavutamiseks, isegi kui see tähendab karkude kirjutamist
Tarkvaraarendus tootefirmades on peaaegu alati suurim kuluartikkel: arendajad on kallid. Ja hea arendaja mõistab, et ettevõte tahab minimaalselt kulutades saada maksimaalselt raha. Tema abistamiseks soovib hea arendaja kulutada minimaalselt oma kallist aega, et saada tööandjale maksimaalset kasumit.
Siin on kaks äärmust. Üks on see, et üldiselt saab karguga kõik probleemid ära lahendada, ilma arhitektuuriga jändama, ilma refaktoreerimata jne. Me kõik teame, kuidas see tavaliselt lõpeb: miski ei tööta, kirjutame projekti nullist ümber. Teine on see, kui inimene püüab iga nupu jaoks ideaalse arhitektuuri välja mõelda, kulutades ülesandele tund ja ümbertöötamisele neli. Sellise töö tulemus tundub suurepärane, kuid probleem on selles, et äripoolel kulub nupu valmimiseks kümme tundi, nii esimesel kui ka teisel juhul lihtsalt erinevatel põhjustel.
Hea arendaja teab, kuidas nende äärmuste vahel tasakaalu hoida. Ta mõistab konteksti ja teeb optimaalse otsuse: selles ülesandes lõikan ma kargu, sest see on kood, mida puudutatakse kord poole aasta jooksul. Kuid selles ma viitsin ja teen kõik võimalikult õigesti, sest sada uut funktsiooni, mis on veel arendamata, sõltuvad sellest, mis mul õnnestub.
4. Omab oma ärijuhtimissüsteemi ja suudab selles töötada igasuguse keerukusega projektidega.
Põhimõtete järgi töötamine – kui paned kõik oma ülesanded mingisse tekstisüsteemi kirja, ära unusta kokkuleppeid, surud kõik peale, ilmud õigel ajal kõikjale, tead, mis on hetkel oluline ja mis mitte, ei kaota sa kunagi ülesandeid. Selliste inimeste üldine tunnus on see, et kui sa nendega milleski kokku lepid, ei muretse sa kunagi, et nad unustavad; ja sa tead ka, et nad kirjutavad kõik üles ja ei esita siis tuhat küsimust, mille vastused on juba läbi arutatud.
5. Küsib ja täpsustab tingimusi ja tutvustusi
Ka siin on kaks äärmust. Ühest küljest võite olla skeptiline kogu sissejuhatava teabe suhtes. Inimesed enne sind mõtlesid välja mõned lahendused, aga sa arvad, et saad paremini ja hakkad uuesti arutama kõike, mis enne sind oli: disain, ärilahendused, arhitektuur jne. See raiskab palju aega nii arendaja kui ka teda ümbritsevate inimeste jaoks ning avaldab negatiivset mõju ettevõttesisesele usaldusele: teised inimesed ei taha otsuseid langetada, sest nad teavad, et see mees tuleb tagasi ja rikub kõik. Teine äärmus on see, kui arendaja tajub igasugust sissejuhatavat, tehnilist spetsifikatsiooni ja ärisoovi kui midagi kivisse raiutud ning alles lahendamatu probleemiga silmitsi seistes hakkab ta mõtlema, kas ta üldse teeb seda, mida teeb. Hea arendaja leiab siit ka kuldse kesktee: ta püüab aru saada enne või ilma temata tehtud otsustest, enne kui ülesanne arendusse läheb. Mida äri tahab? Kas me lahendame tema probleemid? Tootedisainer mõtles välja lahenduse, aga kas ma saan aru, miks lahendus tööle hakkab? Miks meeskonna juht selle konkreetse arhitektuuriga välja tuli? Kui midagi jääb arusaamatuks, siis tuleb minna küsima. Selle selgitamise käigus võib hea arendaja näha alternatiivset lahendust, mis lihtsalt polnud varem kellelegi pähe tulnud.
6. Parandab protsesse ja inimesi enda ümber
Meie ümber toimub palju protsesse – igapäevased koosolekud, kohtumised, kokkutulekud, tehnikaülevaatused, koodiülevaatused jne. Hea arendaja tõuseb püsti ja ütleb: näe, saame kokku ja arutame iga nädal sama asja, ma ei saa aru, miks, võiksime selle tunni ka Contra peale kulutada. Või: kolmandat ülesannet järjest ei saa ma koodi sisse, midagi pole selge, arhitektuur on auke täis; Võib-olla on meie ülevaatuse kood labane ja me peame seda ümber tegema. Refaktoreerime kohtumist iga kahe nädala tagant. Või näeb inimene koodi ülevaatuse ajal, et üks tema kolleegidest ei kasuta teatud vahendit piisavalt tõhusalt, mis tähendab, et ta peab hiljem tulema ja nõu andma. Heal arendajal on see instinkt, ta teeb selliseid asju automaatselt.
7. Suurepärane teiste juhtimises, isegi kui mitte juht
See oskus haakub hästi teemaga "probleemide lahendamine, mitte loomine". Tihti pole selle vaba ametikoha tekstis, kuhu kandideerime, juhtimisest midagi kirjas, kuid siis tuleb sinust mitteoleneva probleemiga silmitsi seistes ikkagi ühel või teisel moel teisi juhtida, neilt midagi saavutada, kui unustasin – lükake, veenduge, et nad kõigest aru said. Hea arendaja teab, keda mis huvitab, oskab nende inimestega kohtumisele kutsuda, kokkulepped kirja panna, lõdvaks saata, õigel päeval meelde tuletada, veenduda, et kõik on valmis, isegi kui ta isiklikult ei vastuta. see ülesanne, kuid selle tulemus sõltub selle elluviimisest.
8. Ei taju oma teadmisi dogmana, on pidevalt avatud kriitikale
Igaüks mäletab kolleegi eelmisest töökohast, kes ei suuda oma tehnoloogias järeleandmisi teha ja karjub, et kõik põlevad põrgus mingite valede mutatsioonide pärast. Hea arendaja, kui ta töötab 5, 10, 20 aastat tööstuses, saab aru, et pool tema teadmistest on mäda ja ülejäänud pooles ei tea ta kümme korda rohkem, kui teab. Ja iga kord, kui keegi temaga ei nõustu ja pakub alternatiivi, pole see rünnak tema ego vastu, vaid võimalus midagi õppida. See võimaldab tal kasvada palju kiiremini kui teda ümbritsevad.
Võrrelgem minu ideed ideaalsest arendajast üldtunnustatud ideega:
Sellel pildil on näha, kui paljud ülalkirjeldatud punktidest on koodiga seotud ja kui paljud mitte. Arendus tootefirmas on vaid kolmandik programmeerimine, ülejäänud 2/3 on koodiga vähe seotud. Ja kuigi me kirjutame palju koodi, sõltub meie tõhusus suuresti neist "ebaolulistest" kahest kolmandikust.
Spetsialiseerumine, üldistus ja 80-20 reegel
Kui inimene õpib lahendama mõnd kitsast probleemi, õpib kaua ja kõvasti, kuid lahendab need siis lihtsalt ja lihtsalt, kuid ei oma asjatundlikkust seotud valdkondades, on see spetsialiseerumine. Üldistus on see, kui pool koolitusajast investeeritakse enda kompetentsivaldkonda ja teine pool sellega seotud valdkonda. Vastavalt sellele teen esimesel juhul ühe asja ideaalselt ja ülejäänu halvasti ning teisel juhul enam-vähem hästi.
80-20 reegel ütleb meile, et 80% tulemusest tuleb 20% pingutusest. 80% tulust tuleb 20% klientidelt, 80% kasumist 20% töötajatest jne. Õppetöös tähendab see, et 80% teadmistest saame esimese 20% ajakuluga.
On idee: kodeerijad peaksid ainult kodeerima, disainerid ainult kujundama, analüütikud analüüsima ja juhid ainult juhtima. Minu arvates on see idee mürgine ja ei tööta eriti hästi. See ei tähenda, et kõik peavad olema universaalsed sõdurid, vaid ressursside säästmine. Kui arendaja mõistab vähemalt natukenegi juhtimist, disaini ja analüütikat, suudab ta paljusid probleeme lahendada teisi inimesi kaasamata. Kui teil on vaja luua mingi funktsioon ja seejärel kontrollida, kuidas kasutajad sellega teatud kontekstis töötavad, mis nõuab kahte SQL-päringut, siis on suurepärane, kui saate sellega analüütikut mitte häirida. Kui teil on vaja nuppu manustada analoogia põhjal olemasolevatega ja te mõistate üldpõhimõtteid, saate seda teha ilma disainerit kaasamata ja ettevõte tänab teid selle eest.
Kokku: võite kulutada 100% oma ajast oskuse lõpuni õppimisele või kulutada sama aja viiele alale, saavutades mõlemas kuni 80%. Seda naiivset matemaatikat järgides võime sama ajaga omandada neli korda rohkem oskusi. See on liialdus, kuid illustreerib ideed.
Seotud oskusi saab treenida mitte 80%, vaid 30-50%. Pärast 10-20 tunni möödumist paranete märgatavalt seotud valdkondades, saate palju aru nendes toimuvatest protsessidest ja muutute palju autonoomsemaks.
Tänapäeva IT-ökosüsteemis on parem omada võimalikult palju oskusi ja mitte olla üheski neist ekspert. Sest esiteks tuhmuvad kõik need oskused kiiresti, eriti mis puudutab programmeerimist, ja teiseks seetõttu, et 99% ajast ei kasuta me mitte ainult elementaarseid, vaid kindlasti mitte kõige keerukamaid oskusi ja sellest piisab isegi kodeerimisel, isegi lahedad firmad.
Ja lõpuks on koolitus investeering ja investeeringute puhul on oluline mitmekesistamine.
Mida õpetada
Mida siis õpetada ja kuidas? Tüüpiline tugeva ettevõtte arendaja kasutab regulaarselt:
- suhtlemist
- iseorganiseerumine
- planeerimine
- disain (tavaliselt kood)
- ja mõnikord juhtimis-, juhtimis-, andmeanalüüsi-, kirjutamis-, värbamis-, juhendamis- ja palju muid oskusi
Ja praktiliselt ükski neist oskustest ei ristu koodi endaga. Neid tuleb eraldi õpetada ja täiendada ning kui seda ei tehta, jäävad nad väga madalale tasemele, mis ei võimalda neid efektiivselt kasutada.
Millistes valdkondades tasub areneda?
-
Pehmed oskused on kõik, mis ei puuduta redaktoris nuppude vajutamist. Nii kirjutame sõnumeid, käitume koosolekutel, suhtleme kolleegidega. Need kõik tunduvad olevat ilmsed asjad, kuid sageli alahinnatakse neid.
-
Iseorganiseerumise süsteem. Minu jaoks isiklikult on see viimase aasta jooksul muutunud ülioluliseks teemaks. Kõigi lahedate IT-töötajate seas, keda tean, on see üks arenenumaid oskusi: nad on ülimalt organiseeritud, teevad alati seda, mida ütlevad, teavad täpselt, mida nad homme, nädala, kuu pärast teevad. Enda ümber on vaja üles ehitada süsteem, milles kõik asjad ja kõik küsimused salvestatakse, see hõlbustab oluliselt tööd ennast ja aitab oluliselt teiste inimestega suhelda. Tunnen, et viimase aasta jooksul on sellesuunaline areng mind palju rohkem parandanud kui tehniliste oskuste parandamine, hakkasin tegema oluliselt rohkem tööd ajaühiku kohta.
-
Proaktiivne, avatud ja planeeriv. Teemad on väga üldised ja elulised, mitte ainult IT-le omased ning igaüks peaks neid arendama. Proaktiivsus tähendab seda, et ei oota tegutsemiseks signaali. Sa oled sündmuste allikas, mitte reaktsioon neile. Avameelsus on oskus käsitleda uut teavet objektiivselt, hinnata olukorda oma maailmavaatest ja vanadest harjumustest eraldatuna. Planeerimine on selge nägemus sellest, kuidas tänane ülesanne nädala, kuu, aasta probleemi lahendab. Kui näete tulevikku konkreetsest ülesandest kaugemale, on palju lihtsam teha seda, mida vajate, ja ärge kartke aja möödudes mõista, et see oli raisatud. See oskus on karjääri jaoks eriti oluline: võid aastaid edukalt tulemusi saavutada, kuid vales kohas ja lõpuks kaotada kogu kogunenud pagasi, kui selgub, et liikusid vales suunas.
-
Kõik seotud alad algtasemeni. Igaühel on oma spetsiifilised valdkonnad, kuid oluline on mõista, et kulutades 10-20 tundi aega mõne “võõra” oskuse tasandamiseks, võid avastada oma igapäevatöös palju uusi võimalusi ja kokkupuutepunkte ning need tunnid võivad Piisab kuni karjääri lõpuni.
Mida lugeda
Iseorganiseerumise kohta on palju raamatuid; see on terve tööstusharu, kus mingid kummalised tüübid kirjutavad nõuandekogumikke ja koguvad koolitusi. Samas jääb arusaamatuks, mida nad ise elus saavutanud on. Seetõttu on oluline panna autoritele filtrid peale, vaadata, kes nad on ja mis neil taga on. Minu arengut ja silmaringi mõjutasid enim neli raamatut, mis kõik olid ühel või teisel moel seotud ülalkirjeldatud oskuste täiendamisega.
1. Dale Carnegie "Kuidas võita sõpru ja mõjutada inimesi". Kultusraamat pehmete oskuste kohta. Kui te ei tea, kust alustada, on selle valimine kasulik kõigile. See on üles ehitatud näidetele, on kergesti loetav, loetu mõistmine ei nõua palju pingutust ning omandatud oskusi saab kohe rakendada. Üldiselt käsitleb raamat inimestega suhtlemise teemat.
2. Stephen R. Covey "7 väga tõhusate inimeste harjumust". Erinevate oskuste segu, alates proaktiivsusest kuni pehmete oskusteni, rõhuasetusega sünergia saavutamisel, kui teil on vaja muuta väike meeskond tohutuks jõuks. Seda on ka lihtne lugeda.
3. Ray Dalio "Põhimõtted". Avab avameelsuse ja proaktiivsuse teemasid, tuginedes autori ehitatud ettevõtte ajaloole, mida ta juhtis 40 aastat. Paljud raskelt võidetud näited elust näitavad, kui eelarvamuslik ja sõltuv inimene võib olla ning kuidas sellest lahti saada.
4. David Allen, "Asjade tegemine". Kohustuslik lugemine eneseorganiseerumise õppimiseks. Seda ei ole nii lihtne lugeda, kuid see pakub terviklikku tööriistakomplekti elu ja asjade korraldamiseks, uurib üksikasjalikult kõiki aspekte ja aitab teil otsustada, mida täpselt vajate. Tema abiga ehitasin üles oma süsteemi, mis võimaldab mul alati teha kõige olulisemad asjad, unustamata ülejäänut.
Peate mõistma, et ainult lugemisest ei piisa. Nädalas võite alla neelata vähemalt raamatu, kuid mõju kestab mitu päeva ja siis naaseb kõik oma kohale. Raamatuid tuleks kasutada nõuandeallikana, mida kohe praktikas katsetatakse. Kui te seda ei tee, avardavad nad ainult teie silmaringi.
Allikas: www.habr.com