Pühendatud projektijuhtidele (ja neile, kes unistavad saada ülemusteks).
Tonnide viisi koodi kirjutamine on raske, kuid inimeste haldamine on veelgi raskem! Nii et teil on vaja seda raamatut, et õppida mõlemat tegema.
Kas naljakaid lugusid ja tõsiseid õppetunde on võimalik ühendada? Michael Lopp (kitsas ringkonnas tuntud ka kui Rands) õnnestus. Leiate väljamõeldud lugusid väljamõeldud inimestest, kellel on uskumatult rahuldust pakkuvad (ehkki väljamõeldud) kogemused. Nii jagab Rands oma mitmekülgseid, kohati veidraid kogemusi, mis on saadud aastate jooksul töötades suurtes IT-korporatsioonides: Apple, Pinterest, Palantir, Netscape, Symantec jne.
Kas olete projektijuht? Või tahad aru saada, mida su neetud boss terve päeva teeb? Rands õpetab teile, kuidas ellu jääda täispuhutud kalkunite mürgises maailmas ja edeneda ebafunktsionaalselt toretsevate inimeste üldises hulluses. Selles kummalises maniakaalsete ajumeeste kogukonnas on veelgi võõramad olendid – juhid, kes on müstilise organisatsioonilise rituaali kaudu saanud võimu paljude inimeste plaanide, mõtete ja pangakontode üle.
See raamat ei sarnane ühelegi juhtimise või juhtimise käsikirjale. Michael Lopp ei varja midagi, ta lihtsalt räägib seda nii, nagu see on (võib-olla ei peaks kõiki lugusid avalikustama: P). Kuid ainult nii saate aru, kuidas sellise ülemusega ellu jääda, kuidas hallata nohikesi ja nohikuid ning kuidas "see neetud projekt" õnneliku lõpuni viia!
Väljavõte. Inseneri mentaliteet
Mõtted: kas peaksite koodi kirjutamist jätkama?
Randsi raamat juhtide reeglite kohta sisaldab väga lühikest loetelu kaasaegsetest juhtimiskohustustest. Selle loetelu lakoonilisus tuleneb sellest, et mõiste “peab” on omamoodi absoluut ja kui rääkida inimestest, siis absoluutseid mõisteid on väga vähe. Ühe töötaja edukas juhtimismeetod on teise jaoks tõeline katastroof. See mõte on esimene punkt juhi kohustuslike ülesannete loendis:
Jää paindlikuks!
Arvata, et tead juba kõike, on väga halb mõte. Olukorras, kus ainus püsiv tõsiasi on see, et maailm muutub pidevalt, saab ainsaks õigeks positsiooniks paindlikkus.
Paradoksaalsel kombel on loendi teine punkt üllatavalt paindumatu. See punkt on aga minu isiklik lemmik, sest usun, et see aitab luua aluse juhtimiskasvuks. See lõik kõlab järgmiselt:
Lõpetage koodi kirjutamine!
Teoreetiliselt, kui sa tahad olla juht, pead õppima usaldama neid, kes sinu heaks töötavad ja andma kodeerimise täielikult neile. Seda nõu on tavaliselt raske seedida, eriti äsja vermitud juhtide puhul. Tõenäoliselt on üks põhjusi, miks nad juhiks said, nende tootlikkus arenduses ja kui asjad lähevad valesti, on nende esimene reaktsioon langeda tagasi oskustele, millesse nad täielikult usaldavad, milleks on koodi kirjutamise oskus.
Kui näen, et äsja vermitud mänedžer “vajub” koodi kirjutama, ütlen talle: “Me teame, et sa oskad koodi kirjutada. Küsimus on: kas sa oskad juhtida? Sa ei vastuta enam üksi iseenda eest, vastutad kogu meeskonna eest; ja ma tahan olla kindel, et saate oma meeskonna probleeme iseseisvalt lahendada, ilma et peaksite ise koodi kirjutama. Teie ülesanne on välja mõelda, kuidas ennast skaleerida. Ma ei taha, et sa oleksid ainult üks, ma tahan, et sinusuguseid oleks palju.
Hea nõuanne, eks? Kaal. Juhtimine. Vastutus. Sellised levinud moesõnad. Kahju, et nõuanne on vale.
Vale?
Jah. Nõuanne on vale! Mitte küll täiesti vale, aga piisavalt vale, et pidin mõnele endisele kolleegile helistama ja vabandama: „Kas mäletate seda mu lemmikütlust, kuidas koodi kirjutamine lõpetada? See on vale! Jah... Alusta uuesti programmeerimist. Alusta Pythoni ja Rubyga. Jah, ma räägin tõsiselt! Sinu karjäär sõltub sellest!”
Kui alustasin Borlandis tarkvaraarendaja karjääri, töötasin Paradox Windowsi meeskonnas, mis oli tohutu meeskond. Ainuüksi rakenduste arendajaid oli 13. Kui lisada inimesi teistest meeskondadest, kes töötasid pidevalt ka selle projekti võtmetehnoloogiatega, nagu põhiandmebaasi mootor ja põhirakendusteenused, kaasati selle toote arendamisse otseselt 50 inseneri.
Ükski teine meeskond, kus ma kunagi töötanud olen, ei küündi selle suuruseni. Tegelikult väheneb iga aastaga inimeste arv meeskonnas, kus ma töötan. Mis toimub? Kas meie, arendajad, saame ühiselt targemaks ja targemaks? Ei, me lihtsalt jagame koormust.
Mida on arendajad viimase 20 aasta jooksul teinud? Selle aja jooksul kirjutasime sitatäie koodi. Koodimeri! Kirjutasime nii palju koodi, et otsustasime, et oleks hea mõte kõike lihtsustada ja minna avatud lähtekoodiga.
Õnneks on see protsess tänu Internetile nüüd võimalikult lihtsaks muutunud. Kui olete tarkvaraarendaja, saate seda kohe kontrollida! Otsige oma nime Google'ist või Githubist ja näete koodi, mille olete juba ammu unustanud, kuid mida igaüks võib leida. Õudne, eks? Kas te ei teadnud, et kood elab igavesti? Jah, ta elab igavesti.
Kood elab igavesti. Ja hea kood mitte ainult ei ela igavesti, vaid kasvab, sest need, kes seda hindavad, tagavad selle pidevalt värskena. See hunnik kvaliteetset ja hästi hooldatud koodi aitab vähendada keskmist insenerimeeskonna suurust, kuna see võimaldab meil keskenduda olemasolevale koodile, mitte uue koodi kirjutamisele, ning teha tööd vähemate inimestega ja lühema aja jooksul.
See arutluskäik kõlab masendav, kuid idee seisneb selles, et me kõik oleme lihtsalt hunnik integreerimisautomaate, mis kasutavad kleeplinti, et ühendada olemasolevatest asjadest erinevad osad, et luua samast asjast veidi erinev versioon. See on klassikaline mõtteviis tippjuhtide seas, kes armastavad allhanget. "Kõik, kes teavad, kuidas Google'it kasutada ja kellel on kleeplint, saavad seda teha! Miks me siis oma masinate eest palju raha maksame?
Me maksame neile juhtkonnameestele tõesti suuri rahasid, aga nad mõtlevad sellist jama. Veel kord, minu põhipunkt on see, et meie planeedil on palju säravaid ja väga töökaid arendajaid; nad on tõeliselt säravad ja püüdlikud, kuigi nad pole akrediteeritud ülikoolides istunud minutitki. Ah jaa, nüüd on neid aina rohkem!
Ma ei soovita teil hakata oma koha pärast muretsema lihtsalt sellepärast, et mõned geniaalsed seltsimehed väidetavalt seda jahtivad. Soovitan teil selle pärast muretsema hakata, sest tarkvaraarenduse areng liigub tõenäoliselt kiiremini kui teie. Olete töötanud kümme aastat, neist viis aastat juhina, ja mõtlete: "Ma juba tean, kuidas tarkvara arendatakse." Jah, tead. Hüvasti…
Lõpeta koodi kirjutamine, aga...
Kui järgite minu esialgset nõuannet ja lõpetate koodi kirjutamise, lõpetate ka vabatahtlikult loomisprotsessis osalemise. Just sel põhjusel ei kasuta ma aktiivselt allhanget. Automaadid ei loo, vaid toodavad. Hästi kavandatud protsessid säästavad palju raha, kuid ei too meie maailma midagi uut.
Kui teil on väike meeskond, kes teeb väikese raha eest palju, siis tundub koodi kirjutamise lõpetamise idee mulle halva karjääriotsusena. Isegi koletisettevõtetes, kus on lõputu regulatsioon, protsess ja poliitika, pole teil õigust unustada, kuidas ise tarkvara arendada. Ja tarkvaraarendus muutub pidevalt. See on praegu muutumas. Su jalge all! Sel hetkel!
Teil on vastuväiteid. Saage aru. Kuulame.
“Rands, ma olen teel direktoritooli! Kui ma jätkan koodi kirjutamist, ei usu keegi, et saan kasvada.
Ma tahan teilt küsida järgmist: kas olete pärast seda, kui istusite oma “Ma hakkan tegevjuhiks!” toolil, märganud, et tarkvaraarenduse maastik on muutumas isegi teie ettevõtte sees? Kui teie vastus on jaatav, siis esitan teile veel ühe küsimuse: kuidas see täpselt muutub ja mida te nende muudatustega ette võtate? Kui vastasid minu esimesele küsimusele “ei”, siis pead kolima teisele toolile, sest (vean kihla vedada!) tarkvaraarenduse valdkond on just sel hetkel muutumas. Kuidas te kunagi kasvate, kui unustate aeglaselt, kuid kindlalt, kuidas tarkvara arendada?
Minu nõuanne on, et ärge kohustuge rakendama oma järgmise toote jaoks palju funktsioone. Peate pidevalt astuma samme, et olla kursis teie meeskonna tarkvara loomisega. Saate seda teha nii direktori kui ka asepresidendina. Midagi muud?
„Uh, Rands! Aga keegi peab olema vahekohtunik! Keegi peab nägema suurt pilti. Kui ma koodi kirjutan, kaotan perspektiivi."
Peate ikka olema kohtunik, peate ikka otsuseid edastama ja ikkagi peate igal esmaspäeva hommikul koos ühe oma inseneriga neli korda hoones ringi käima, et kuulata tema iganädalast 30 eest häält "We're all doomed". minutit.! Kuid peale kõige selle peate säilitama inseneri mõtteviisi ja selleks ei pea te olema täiskohaga programmeerija.
Minu näpunäited insenerimentaliteedi säilitamiseks:
- Kasutage arenduskeskkonda. See tähendab, et peaksite olema tuttav oma meeskonna tööriistadega, sealhulgas koodi koostamise süsteemi, versioonikontrolli ja programmeerimiskeelega. Selle tulemusena omandate keele, mida teie meeskond tootearendusest rääkides kasutab. See võimaldab teil ka jätkata oma lemmiktekstiredaktoriga, mis töötab ideaalselt.
- Peate suutma igal ajal joonistada üksikasjaliku arhitektuurse diagrammi, mis kirjeldab teie toodet mis tahes pinnal. Nüüd ei pea ma silmas kolme lahtri ja kahe noolega lihtsustatud versiooni. Peate teadma toote üksikasjalikku diagrammi. Kõige raskem. Mitte lihtsalt üks armas diagramm, vaid diagramm, mida on raske seletada. See peaks olema toote täielikuks mõistmiseks sobiv kaart. See muutub pidevalt ja peaksite alati teadma, miks teatud muutused toimusid.
- Võtke üle ühe funktsioonide rakendamine. Ma võpatan seda kirjutades sõna otseses mõttes, sest sellel punktil on palju varjatud ohte, kuid ma pole tõesti kindel, kas suudate punktid 1 ja 2 täita, ilma et peaksite rakendama vähemalt ühte funktsiooni. Rakendades ühte funktsioonidest ise, ei osale te mitte ainult aktiivselt arendusprotsessis, vaid võimaldab teil ka perioodiliselt lülituda rollilt "Kõige eest vastutav juht" rollile "Mees, kes vastutab selle rakendamise eest". funktsioonidest." See alandlik ja tagasihoidlik suhtumine tuletab teile meelde väikeste otsuste tähtsust.
- Ma värisen ikka veel üleni. Tundub, et keegi juba karjub minu peale: “Juhataja, kes võttis funktsiooni teostamise enda peale?! (Ja ma olen temaga nõus!) Jah, sa oled endiselt juht, mis tähendab, et see peaks olema väike funktsioon, eks? Jah, sul on veel palju teha. Kui te lihtsalt ei saa funktsiooni juurutamist enda peale võtta, siis annan teile mõned nõuanded: parandage mõned vead. Sel juhul ei tunne te loomisrõõmu, kuid teil on arusaam toote loomisest, mis tähendab, et te ei jää kunagi tööst ilma.
- Kirjutage ühikutestid. Teen seda ikka veel tootmistsükli lõpus, kui inimesed hakkavad hulluks minema. Mõelge sellele kui oma toote tervisekontrolli nimekirjale. Tehke seda sageli.
Jälle vastuväide?
"Rands, kui ma koodi kirjutan, siis ajan oma meeskonna segadusse. Nad ei tea, kes ma olen – juht või arendaja.
Hea küll.
Jah, ma ütlesin: "Olgu!" Mul on hea meel, et arvate, et saate oma meeskonna segadusse ajada lihtsalt arendajate tiigis ujudes. See on lihtne: piirid erinevate rollide vahel tarkvaraarenduses on praegu väga hägused. Kasutajaliidese poisid teevad seda, mida üldiselt võib nimetada JavaScripti ja CSS-i programmeerimiseks. Arendajad õpivad üha rohkem kasutajakogemuse kujundamise kohta. Inimesed suhtlevad omavahel ja saavad teada vigadest, teiste inimeste koodivargustest ja ka sellest, et juhil pole ühtegi mõjuvat põhjust mitte osaleda selles massilises, globaalses, risttolmlevas infobakhhanaalias.
Pealegi, kas soovite olla osa meeskonnast, mis koosneb kergesti vahetatavatest komponentidest? See ei muuda teie meeskonda lihtsalt krapsakamaks, vaid annab igal meeskonnaliikmel võimaluse näha toodet ja ettevõtet erinevatest vaatenurkadest. Kuidas saab hakata Franki, rahulikku ehituste eest vastutavat meest austama rohkem kui pärast tema ehitusskriptide lihtsat elegantsi nägemist?
Ma ei taha, et teie meeskond muutuks segaseks ja kaootiliseks. Vastupidi, ma tahan, et teie meeskond suhtleks tõhusamalt. Usun, et kui oled kaasatud toote loomisesse ja töötad funktsioonide kallal, oled oma meeskonnale lähemal. Ja mis veelgi olulisem, olete lähemal pidevatele muutustele oma organisatsiooni tarkvaraarenduse protsessis.
Ärge lõpetage arengut
Üks mu kolleeg Borlandist ründas mind kunagi verbaalselt, kuna kutsusin teda "kodeerijaks".
“Rands, kooder on arutu masin! Ahv! Kodeerija ei tee midagi olulist peale asjatu koodi igavate ridade kirjutamise. Ma ei ole kodeerija, ma olen tarkvaraarendaja!
Tal oli õigus, ta oleks vihkanud minu esialgset nõuannet uutele tegevjuhtidele: "Lõpetage koodi kirjutamine!" Mitte sellepärast, et ma väidan, et nad on kodeerijad, vaid pigem sellepärast, et soovitan ennetavalt, et nad hakkaksid ignoreerima oma töö üht kõige olulisemat osa: tarkvaraarendust.
Nii et värskendasin oma nõuandeid. Kui tahad olla hea juht, võid koodi kirjutamise lõpetada, aga...
Ole paindlik. Pidage meeles, mida tähendab olla insener ja ärge lõpetage tarkvara arendamist.
Teave Autor
Michael Lopp on vana tarkvaraarendaja, kes pole ikka veel Silicon Valleyst lahkunud. Viimase 20 aasta jooksul on Michael töötanud mitmesugustes uuenduslikes ettevõtetes, sealhulgas Apple, Netscape, Symantec, Borland, Palantir, Pinterest, ning osalenud ka idufirmas, mis aeglaselt unustuse hõlma vajus.
Töövälisel ajal peab Michael pseudonüümi Rands all populaarset tehnoloogia- ja juhtimisblogi, kus ta arutleb lugejatega juhtimisvaldkonna ideede üle, väljendab muret pideva vajaduse pärast kätt pulsil hoida ning selgitab, et vaatamata heldeid tasusid toote loomise eest, teie edu on võimalik ainult tänu teie meeskonnale. Blogi leiab siit .
Michael elab koos perega Californias Redwoodis. Ta leiab alati aega maastikurattaga sõitmiseks, hokit mängimiseks ja punast veini juua, sest tervislikkus on tähtsam kui kiire.
» Lisateavet raamatu kohta leiate aadressilt
»
»
Khabrozhiteley jaoks 20% allahindlus kupongi abil - Inimeste juhtimine
Raamatu paberversiooni eest tasumisel saadetakse e-postiga raamatu elektrooniline versioon.
PS: 7% raamatu hinnast läheb uute arvutiraamatute tõlkimiseks, trükikojale üle antud raamatute nimekiri .
Allikas: www.habr.com