Skirta projektų vadovams (ir tiems, kurie svajoja tapti viršininkais).
Rašyti daugybę kodų sunku, bet valdyti žmones dar sunkiau! Taigi jums tereikia šios knygos, kad išmoktumėte daryti abu.
Ar įmanoma derinti linksmas istorijas ir rimtas pamokas? Michael Lopp (taip pat žinomas siauruose sluoksniuose kaip Rands) pavyko. Rasite išgalvotų istorijų apie išgalvotus žmones, turinčius neįtikėtinai naudingos (nors ir išgalvotos) patirties. Taip Randsas dalijasi įvairiapusiška, kartais keista patirtimi, įgyta per ilgus metus dirbant didelėse IT korporacijose: Apple, Pinterest, Palantir, Netscape, Symantec ir kt.
Ar esate projektų vadovas? Arba norite suprasti, ką jūsų prakeiktas viršininkas veikia visą dieną? Rands išmokys jus išgyventi toksiškame pripūstų kalakutų pasaulyje ir klestėti bendrame nefunkciškai žaismingų žmonių beprotybėje. Šioje keistoje maniakiškų protų bendruomenėje yra dar keistesnių būtybių – vadybininkų, kurie per mistišką organizacinį ritualą įgavo valdžią daugelio žmonių planams, mintims ir banko sąskaitoms.
Ši knyga nepanaši į jokį valdymo ar vadovavimo rankraštį. Michaelas Loppas nieko neslepia, tik pasakoja taip, kaip yra (galbūt ne visas istorijas reikėtų viešinti: P). Bet tik taip suprasite, kaip išgyventi su tokiu viršininku, kaip valdyti geikus ir niekšus ir kaip užbaigti „tą prakeiktą projektą“ iki laimingos pabaigos!
Ištrauka. Inžinerinis mentalitetas
Mintys apie tai: ar turėtumėte toliau rašyti kodą?
Randso knygoje apie taisykles vadovams pateikiamas labai trumpas šiuolaikinių vadybinių „privalomų dalykų“ sąrašas. Šio sąrašo lakoniškumas kyla iš to, kad sąvoka „privalo“ yra tam tikras absoliutas, o kalbant apie žmones, absoliučių sąvokų yra labai mažai. Sėkmingas valdymo metodas vienam darbuotojui bus tikra katastrofa kitam. Ši mintis yra pirmasis elementas vadovo privalomųjų darbų sąraše:
Likite lankstūs!
Galvoti, kad jau viską žinai, yra labai bloga mintis. Situacijoje, kai vienintelis pastovus faktas yra tai, kad pasaulis nuolat keičiasi, lankstumas tampa vienintele teisinga pozicija.
Paradoksalu, bet antrasis sąrašo punktas yra stebėtinai nelankstus. Tačiau šis punktas yra mano asmeninis mėgstamiausias, nes manau, kad jis padeda sukurti pagrindą vadovų augimui. Šioje pastraipoje rašoma:
Nustokite rašyti kodą!
Teoriškai, jei nori būti vadybininku, turi išmokti pasitikėti tais, kurie tau dirba, ir visą kodavimą perduoti jiems. Šis patarimas dažniausiai sunkiai įsisavinamas, ypač naujai nukaldintiems vadovams. Tikriausiai viena iš priežasčių, kodėl jie tapo vadovais, yra dėl jų produktyvumo tobulinant, o kai viskas klostosi ne taip, pirmoji jų reakcija yra grįžti į įgūdžius, kuriais jie visiškai pasitiki, ty gebėjimą rašyti kodą.
Kai pamatau, kad naujai nukaldintas vadybininkas „paskęsta“ į kodo rašymą, sakau jam: „Žinome, kad kodą rašyti gali. Kyla klausimas: ar gali vadovauti? Jūs nebeatsakote vienas už save, esate atsakingas už visą komandą; ir noriu įsitikinti, kad galite priversti savo komandą savarankiškai išspręsti problemas, jums nereikės rašyti kodo. Jūsų darbas yra išsiaiškinti, kaip save padidinti. Nenoriu, kad būtum vienas, noriu, kad tokių kaip tu būtų daug.
Geras patarimas, tiesa? Skalė. Valdymas. Atsakomybė. Tokie dažni madingi žodžiai. Gaila, kad patarimas klaidingas.
Neteisingai?
Taip. Patarimas neteisingas! Ne visiškai neteisinga, bet pakankamai neteisinga, kad turėjau paskambinti kai kuriems buvusiems kolegoms ir atsiprašyti: „Prisimeni tą mano mėgstamiausią teiginį, kaip nustoti rašyti kodą? Tai neteisinga! Taip... Pradėkite programuoti iš naujo. Pradėkite nuo Python ir Ruby. Taip, aš rimtai! Nuo to priklauso jūsų karjera!
Kai pradėjau programinės įrangos kūrėjo karjerą įmonėje Borland, dirbau „Paradox Windows“ komandoje, kuri buvo didžiulė komanda. Vien programų kūrėjų buvo 13. Jei pridėsite žmonių iš kitų komandų, kurie taip pat nuolat dirbo su pagrindinėmis šio projekto technologijomis, pvz., pagrindiniu duomenų bazės varikliu ir pagrindinėmis taikomųjų programų paslaugomis, gausite 50 inžinierių, tiesiogiai dalyvaujančių šio produkto kūrime.
Jokia kita komanda, kurioje aš niekada nedirbau, net nepriartėjo prie tokio dydžio. Tiesą sakant, su kiekvienais metais komandoje, kurioje dirbu, pamažu mažėja žmonių. Kas vyksta? Ar mes, kūrėjai, kartu tampame protingesni ir protingesni? Ne, mes tik dalijamės krūviu.
Ką kūrėjai veikė pastaruosius 20 metų? Per tą laiką parašėme begalę kodo. Kodo jūra! Parašėme tiek daug kodo, kad nusprendėme, kad būtų gera idėja viską supaprastinti ir pereiti prie atvirojo kodo.
Laimei, dėl interneto šis procesas tapo kuo paprastesnis. Jei esate programinės įrangos kūrėjas, galite tai patikrinti dabar! Ieškokite savo vardo „Google“ arba „Github“ ir pamatysite kodą, kurį jau seniai pamiršote, bet kurį gali rasti bet kas. Baisu, tiesa? Ar nežinojote, kad kodas gyvas amžinai? Taip, jis gyvena amžinai.
Kodas gyvuoja amžinai. Ir geras kodas ne tik gyvuoja amžinai, bet ir auga, nes jį vertinantys nuolat užtikrina, kad jis išliktų šviežias. Ši aukštos kokybės, gerai prižiūrimo kodo krūva padeda sumažinti vidutinį inžinierių komandos dydį, nes leidžia sutelkti dėmesį į esamą kodą, o ne rašyti naują kodą ir atlikti darbą su mažiau žmonių ir per trumpesnį laiką.
Šis samprotavimas skamba slegiančiai, bet idėja ta, kad mes visi esame tik krūva integravimo automatų, naudojančių lipnią juostą, kad sujungtų skirtingus esamų dalykų fragmentus, kad sukurtume šiek tiek skirtingą to paties dalyko versiją. Tai klasikinis vyresniųjų vadovų, mėgstančių užsakomųjų paslaugų teikimą, mąstymo būdas. „Kiekvienas, kuris moka naudotis Google ir turi lipnios juostos, gali tai padaryti! Tai kodėl mes mokame daug pinigų už savo mašinas?
Mes mokame šiems vadovams tikrai didelius pinigus, bet jie galvoja tokias nesąmones. Dar kartą norėčiau pasakyti, kad mūsų planetoje yra daug puikių ir labai darbščių kūrėjų; jie tikrai šaunūs ir darbštūs, nors nė minutės nepraleido sėdėdami akredituotuose universitetuose. O taip, dabar jų daugėja!
Nesiūlau pradėti nerimauti dėl savo vietos vien todėl, kad kai kurie genialūs bendražygiai tariamai jos medžioja. Siūlau pradėti dėl to nerimauti, nes programinės įrangos kūrimo evoliucija tikriausiai juda greičiau nei jūs. Dirbate dešimt metų, iš kurių penkerius – vadybininku, ir galvojate: „Aš jau žinau, kaip kuriama programinė įranga“. Taip, tu žinai. Ate…
Nustokite rašyti kodą, bet...
Jei laikysitės mano pirminio patarimo ir nustosite rašyti kodą, taip pat savo noru nustosite dalyvauti kūrimo procese. Būtent dėl šios priežasties aš aktyviai nesinaudoju išorės paslaugomis. Automatai nekuria, o gamina. Gerai suplanuoti procesai sutaupo daug pinigų, tačiau nieko naujo mūsų pasauliui neatneša.
Jei turite mažą komandą, kuri daug daro už mažus pinigus, mintis nustoti rašyti kodą man atrodo blogas karjeros sprendimas. Net monstrinėse įmonėse, kuriose yra nesibaigiančių taisyklių, procesų ir politikos, jūs neturite teisės pamiršti, kaip patys kurti programinę įrangą. O programinės įrangos kūrimas nuolat keičiasi. Šiuo metu tai keičiasi. Po tavo kojomis! Šią sekundę!
Jūs turite prieštaravimų. Suprask. Paklausykime.
„Randai, aš pakeliui į direktoriaus kėdę! Jei ir toliau rašysiu kodą, niekas nepatikės, kad galiu augti.
Noriu jūsų paklausti: ar pastebėjote, kad programinės įrangos kūrimo aplinka keičiasi net ir jūsų įmonėje, kai sėdėjote savo kėdėje „Tuoju būsiu CEO!“? Jei atsakymas yra teigiamas, aš užduosiu jums dar vieną klausimą: kaip tiksliai tai keičiasi ir ką ketinate daryti dėl šių pokyčių? Jei į mano pirmąjį klausimą atsakėte „ne“, tuomet turite pereiti į kitą kėdę, nes (galiu lažintis!) programinės įrangos kūrimo sritis keičiasi būtent šią sekundę. Kaip jūs kada nors ketinate augti, jei lėtai, bet užtikrintai pamiršite, kaip kurti programinę įrangą?
Mano patarimas – neįsipareigokite diegti daugybės funkcijų kitame gaminyje. Turite nuolat imtis veiksmų, kad žinotumėte, kaip jūsų komanda kuria programinę įrangą. Tai galite padaryti ir kaip direktorius, ir kaip viceprezidentas. Kažkas kito?
„Oho, Randai! Bet kas nors turi būti arbitras! Kažkas turi matyti bendrą vaizdą. Jei parašysiu kodą, prarasiu perspektyvą.
Jūs vis tiek turite būti teisėjas, jūs vis tiek turite transliuoti sprendimus ir vis tiek turite kiekvieną pirmadienio rytą keturis kartus apeiti pastatą su vienu iš savo inžinierių, kad už 30 metų pasiklausytumėte jo savaitės „Mes visi pasmerkti“. minučių.! Tačiau be viso to, jūs turite išlaikyti inžinerinį mąstymą ir nebūtina būti visą darbo dieną dirbančiu programuotoju, kad tai padarytumėte.
Mano patarimai, kaip išlaikyti inžinerinį mentalitetą:
- Naudokite kūrimo aplinką. Tai reiškia, kad turėtumėte būti susipažinę su savo komandos įrankiais, įskaitant kodo kūrimo sistemą, versijų valdymą ir programavimo kalbą. Dėl to jūs įvaldysite kalbą, kurią jūsų komanda vartoja kalbėdama apie produkto kūrimą. Tai taip pat leis toliau naudoti mėgstamą teksto rengyklę, kuri puikiai veikia.
- Jūs turite turėti galimybę bet kuriuo metu nubraižyti išsamią architektūrinę schemą, apibūdinančią jūsų gaminį ant bet kurio paviršiaus. Dabar aš neturiu omenyje supaprastintos versijos su trimis langeliais ir dviem rodyklėmis. Turite žinoti išsamią gaminio schemą. Pats sunkiausias. Ne bet kokia miela diagrama, bet diagrama, kurią sunku paaiškinti. Tai turėtų būti žemėlapis, tinkantis visiškai suprasti produktą. Ji nuolat keičiasi, todėl visada turėtumėte žinoti, kodėl įvyko tam tikri pokyčiai.
- Perimti vienos iš funkcijų įgyvendinimą. Rašydamas tai tiesiog krūpteliu, nes šis punktas turi daug paslėptų pavojų, bet tikrai nesu tikras, ar galite pasiekti 1 ir 2 punktus neįsipareigodami įdiegti bent vienos funkcijos . Įdiegę vieną iš funkcijų patys ne tik aktyviai dalyvausite kūrimo procese, bet ir leis periodiškai pereiti nuo „vadovo, atsakingo už viską“ vaidmens į „žmogaus, atsakingo už vieno įgyvendinimą“. funkcijų“. Šis nuolankus ir nepretenzingas požiūris primins mažų sprendimų svarbą.
- Vis dar drebu visa galva. Panašu, kad kažkas ant manęs jau šaukia: „Vadovas, kuris pats ėmėsi funkcijos įgyvendinimo?“ (Ir aš jam pritariu!) Taip, jūs vis dar esate vadovas, vadinasi, tai turėtų būti nedidelė funkcija, gerai? Taip, jūs dar turite daug ką nuveikti. Jei tiesiog negalite įgyvendinti funkcijos, turiu jums keletą atsarginių patarimų: ištaisykite kai kurias klaidas. Tokiu atveju nejausite kūrybos džiaugsmo, bet turėsite supratimą, kaip kuriamas produktas, vadinasi, niekada neliksite be darbo.
- Parašykite vienetinius testus. Aš vis dar tai darau gamybos ciklo pabaigoje, kai žmonės pradeda išprotėti. Pagalvokite apie tai kaip apie savo produkto sveikatos kontrolinį sąrašą. Darykite tai dažnai.
Vėl prieštaravimas?
„Randai, jei parašysiu kodą, supainiosiu savo komandą. Jie nežinos, kas aš esu – vadovas ar kūrėjas.
Gerai.
Taip, aš pasakiau: "Gerai!" Džiaugiuosi, kad manote, kad galite suklaidinti savo komandą vien maudydamiesi kūrėjų tvenkinyje. Tai paprasta: ribos tarp skirtingų vaidmenų programinės įrangos kūrimo srityje šiuo metu yra labai neryškios. UI vaikinai daro tai, ką apskritai galima pavadinti JavaScript ir CSS programavimu. Kūrėjai vis daugiau sužino apie vartotojo patirties dizainą. Žmonės bendrauja tarpusavyje ir sužino apie klaidas, apie svetimo kodo vagystes, taip pat apie tai, kad vadovui nėra rimtos priežasties nedalyvauti šioje didžiulėje, globalioje, kryžmadulkėje informacinėje bakchanalijoje.
Be to, ar norite būti komandos, kurią sudaro lengvai keičiami komponentai, dalimi? Tai ne tik padarys jūsų komandą judresnę, bet ir suteiks galimybę kiekvienam komandos nariui pamatyti produktą ir įmonę iš įvairių perspektyvų. Kaip galite gerbti Franką, ramų vaikiną, atsakingą už konstravimus, nei pamačius paprastą jo kūrimo scenarijų eleganciją?
Nenoriu, kad jūsų komanda taptų pasimetusi ir chaotiška. Priešingai, noriu, kad jūsų komanda bendrautų efektyviau. Tikiu, kad jei dalyvausite kuriant produktą ir dirbsite su funkcijomis, būsite arčiau savo komandos. Ir dar svarbiau, jūs būsite arčiau nuolatinių programinės įrangos kūrimo proceso pokyčių savo organizacijoje.
Nenustokite tobulėti
Mano kolega iš Borland kartą mane žodžiu užpuolė, kad pavadinau ją „koduotoja“.
„Randai, koderis yra be proto mašina! Beždžionė! Koderis nedaro nieko svarbaus, išskyrus rašo nuobodžias nenaudingo kodo eilutes. Aš ne programuotojas, o programinės įrangos kūrėjas!
Ji buvo teisi, ji būtų nekentusi mano pirminio patarimo naujiems generaliniams direktoriams: „Nustok rašyti kodą! Ne todėl, kad teigiu, kad jie yra programuotojai, o labiau todėl, kad aktyviai siūlau jiems pradėti ignoruoti vieną iš svarbiausių savo darbo dalių – programinės įrangos kūrimą.
Taigi aš atnaujinau savo patarimą. Jei norite būti geru lyderiu, galite nustoti rašyti kodą, bet...
Būkite lankstūs. Prisiminkite, ką reiškia būti inžinieriumi, ir nenustokite kurti programinės įrangos.
Apie Autorius:
Michaelas Loppas yra programinės įrangos kūrėjas veteranas, kuris vis dar nepaliko Silicio slėnio. Per pastaruosius 20 metų Michaelas dirbo įvairiose naujoviškose įmonėse, įskaitant „Apple“, „Netscape“, „Symantec“, „Borland“, „Palantir“, „Pinterest“, taip pat dalyvavo startuolyje, kuris pamažu nuplaukė į užmarštį.
Ne darbo metu Michaelas slapyvardžiu Rands veda populiarų tinklaraštį apie technologijas ir vadybą, kuriame su skaitytojais aptarinėja idėjas vadybos srityje, reiškia susirūpinimą dėl nuolatinio poreikio laikytis ant pulso ir aiškina, kad, nepaisant dosnus atlygis už produkto sukūrimą, jūsų sėkmė įmanoma tik jūsų komandos dėka. Tinklaraštį rasite čia .
Michaelas su šeima gyvena Redvude, Kalifornijoje. Jis visada randa laiko važinėtis kalnų dviračiu, žaisti ledo ritulį ir išgerti raudonojo vyno, nes sveikata yra svarbiau nei užimtumas.
» Daugiau informacijos apie knygą rasite adresu
»
»
Khabrozhiteley 20% nuolaida naudojant kuponą - Žmonių valdymas
Sumokėjus už popierinę knygos versiją, elektroninis knygos variantas bus išsiųstas el.
PS: 7% nuo knygos kainos atiteks naujų kompiuterinių knygų vertimui, knygų sąrašas, perduotas spaustuvei .
Šaltinis: www.habr.com