Namenjeno vodjem projektov (in tistim, ki sanjajo o tem, da bi postali šefi).
Pisanje na tone kode je težko, a upravljanje ljudi je še težje! Torej potrebujete to knjigo, da se naučite, kako narediti oboje.
Ali je mogoče združiti smešne zgodbe in resne lekcije? Michaelu Loppu (v ožjih krogih znan tudi kot Rands) je uspelo. Našli boste izmišljene zgodbe o izmišljenih ljudeh z neverjetno nagrajujočimi (čeprav izmišljenimi) izkušnjami. Tako Rands deli svoje raznolike, včasih nenavadne izkušnje, pridobljene v letih dela v velikih IT korporacijah: Apple, Pinterest, Palantir, Netscape, Symantec itd.
Ste vodja projekta? Ali želite razumeti, kaj vaš prekleti šef počne ves dan? Rands vas bo naučil, kako preživeti v strupenem svetu napihnjenih puranov in uspevati v splošni norosti disfunkcionalno razkošnih ljudi. V tej nenavadni skupnosti maničnih pametnjakovičev so še bolj nenavadna bitja - menedžerji, ki so z mističnim organizacijskim ritualom pridobili oblast nad načrti, mislimi in bančnimi računi mnogih ljudi.
Ta knjiga ni podobna nobenemu rokopisu o upravljanju ali vodenju. Michael Lopp ničesar ne skriva, samo pove, kot je (mogoče ne bi smele biti vse zgodbe javne: P). Toda le tako boste razumeli, kako preživeti s takšnim šefom, kako obvladati geeke in piflarje ter kako "ta prekleti projekt" pripeljati do srečnega konca!
Izvleček. Inženirska mentaliteta
Razmišljanje o tem: Ali bi morali nadaljevati s pisanjem kode?
Randsova knjiga o pravilih za menedžerje vsebuje zelo kratek seznam sodobnih vodstvenih "must-dos". Lakonizem tega seznama izhaja iz dejstva, da je koncept "mora" neke vrste absolut, in ko gre za ljudi, je absolutnih konceptov zelo malo. Uspešna metoda vodenja za enega zaposlenega bo prava katastrofa za drugega. Ta misel je prva točka na upraviteljevem seznamu stvari, ki jih je treba narediti:
Ostanite prilagodljivi!
Misliti, da že vse veš, je zelo slaba ideja. V situaciji, ko je edino stalno dejstvo, da se svet nenehno spreminja, postane fleksibilnost edina pravilna pozicija.
Paradoksalno je, da je druga postavka na seznamu presenetljivo neprilagodljiva. Vendar je ta točka moja osebno najljubša, ker verjamem, da pomaga ustvariti temelje za managersko rast. Ta odstavek se glasi:
Nehajte pisati kodo!
Teoretično, če hočeš biti menedžer, se moraš naučiti zaupati tistim, ki delajo zate in jim v celoti predati kodiranje. Ta nasvet je običajno težko prebavljiv, zlasti za novopečene menedžerje. Verjetno je eden od razlogov, zakaj so postali menedžerji, njihova produktivnost pri razvoju in ko gredo stvari narobe, je njihova prva reakcija ta, da se vrnejo k veščinam, ki jim popolnoma zaupajo, to je njihovi sposobnosti pisanja kode.
Ko vidim, da se novopečeni menedžer »potopi« v pisanje kode, mu rečem: »Vemo, da znaš pisati kodo. Vprašanje je: ali lahko vodite? Niste več odgovorni sami zase, odgovorni ste za celotno ekipo; in želim se prepričati, da lahko svojo ekipo pripravite do tega, da sama rešuje težave, ne da bi morali sami napisati kodo. Vaša naloga je ugotoviti, kako se povečati. Nočem, da si samo eden, hočem, da je takšnih kot ti veliko.”
Dober nasvet, kajne? Lestvica. Upravljanje. Odgovornost. Tako pogoste modne besede. Škoda, da je nasvet napačen.
Napačno?
ja Nasvet je napačen! Ni povsem napačno, a dovolj napačno, da sem moral poklicati nekaj nekdanjih sodelavcev in se opravičiti: »Se spomnite tiste moje najljubše izjave o tem, kako bi morali prenehati pisati kodo? Narobe je! Ja ... Začnite znova programirati. Začnite s Pythonom in Rubyjem. Ja, resno mislim! Tvoja kariera je odvisna od tega!«
Ko sem začel svojo kariero kot razvijalec programske opreme pri Borlandu, sem delal v ekipi Paradox Windows, ki je bila ogromna ekipa. Samo razvijalcev aplikacij je bilo 13. Če dodate ljudi iz drugih skupin, ki so prav tako nenehno delali na ključnih tehnologijah za ta projekt, kot so osrednji motor baze podatkov in osrednje storitve aplikacij, dobite 50 inženirjev, ki so neposredno sodelovali pri razvoju tega izdelka.
Nobena druga ekipa, za katero sem kdaj delal, ni niti blizu te velikosti. Pravzaprav se z vsakim letom število ljudi v ekipi, v kateri delam, postopoma zmanjšuje. Kaj se dogaja? Ali razvijalci skupaj postajamo pametnejši in pametnejši? Ne, samo breme si deliva.
Kaj so razvijalci počeli zadnjih 20 let? V tem času smo napisali kup kode. Morje kode! Napisali smo toliko kode, da smo se odločili, da bi bilo dobro vse poenostaviti in preiti na odprto kodo.
Na srečo je po zaslugi interneta ta postopek postal kar se da enostaven. Če ste razvijalec programske opreme, jo lahko preverite takoj! Poiščite svoje ime na Googlu ali Githubu in videli boste kodo, na katero ste že dolgo pozabili, a jo lahko najde vsak. Strašljivo, kajne? Ali niste vedeli, da koda živi večno? Ja, živi večno.
Koda živi večno. In dobra koda ne le živi večno, ampak raste, ker tisti, ki jo cenijo, nenehno skrbijo, da ostane sveža. Ta kup visokokakovostne, dobro vzdrževane kode pomaga zmanjšati povprečno velikost inženirske ekipe, ker nam omogoča, da se osredotočimo na obstoječo kodo, namesto da pišemo novo kodo, ter opravimo delo z manj ljudmi in v krajšem časovnem okviru.
To razmišljanje zveni depresivno, a ideja je, da smo vsi le kup integracijskih avtomatov, ki uporabljajo lepilni trak za povezovanje različnih delčkov obstoječih stvari skupaj, da ustvarijo nekoliko drugačno različico iste stvari. To je klasična linija razmišljanja med višjimi vodstvenimi delavci, ki obožujejo zunanje izvajanje. »To zmore vsak, ki zna uporabljati Google in ima lepilni trak! Zakaj potem našim strojem plačujemo veliko denarja?«
Tem vodstvom plačujemo res veliko denarja, oni pa mislijo takšne neumnosti. Še enkrat, moja ključna točka je, da je na našem planetu veliko briljantnih in zelo pridnih razvijalcev; res so briljantni in marljivi, čeprav niso niti minute preživeli na akreditiranih univerzah. O ja, zdaj jih je vedno več!
Ne predlagam, da začnete skrbeti za svoje mesto samo zato, ker ga domnevno lovijo neki briljantni tovariši. Predlagam, da začnete skrbeti zaradi tega, ker se razvoj programske opreme verjetno odvija hitreje kot vi. Deset let delate, od tega pet kot vodja, in si mislite: »Jaz že vem, kako se razvija programska oprema.« Ja, veš. adijo...
Nehaj pisati kodo, ampak...
Če boste upoštevali moj prvotni nasvet in prenehali pisati kodo, boste tudi prostovoljno prenehali sodelovati v procesu ustvarjanja. Iz tega razloga se zunanjega izvajanja ne poslužujem aktivno. Avtomati ne ustvarjajo, proizvajajo. Dobro načrtovani procesi prihranijo veliko denarja, vendar v naš svet ne prinesejo nič novega.
Če imate majhno ekipo, ki dela veliko za malo denarja, potem se mi ideja o prenehanju pisanja kode zdi slaba karierna odločitev. Tudi v pošastnih podjetjih z neskončnimi predpisi, procesi in politikami nimate pravice pozabiti, kako sami razvijati programsko opremo. In razvoj programske opreme se nenehno spreminja. Trenutno se spreminja. Pod noge! V tej sekundi!
Imate ugovore. Razumeti. Prisluhnimo.
»Rands, sem na poti do režiserskega stolčka! Če bom še naprej pisal kodo, nihče ne bo verjel, da lahko rastem.”
Rad bi vas vprašal naslednje: odkar ste sedeli na svojem stolu »Postal bom CEO!«, ali ste opazili, da se krajina razvoja programske opreme spreminja, tudi v vašem podjetju? Če je vaš odgovor pritrdilen, vam bom zastavil še eno vprašanje: kako točno se spreminja in kaj boste storili glede teh sprememb? Če ste na moje prvo vprašanje odgovorili z "ne", potem se morate presesti na drug stol, ker (stavim!) se področje razvoja programske opreme prav v tem trenutku spreminja. Kako boste sploh rasli, če počasi, a vztrajno pozabljate na razvoj programske opreme?
Moj nasvet je, da se ne zavežite implementaciji množice funkcij za svoj naslednji izdelek. Nenehno morate sprejemati korake, da ostanete na tekočem s tem, kako vaša ekipa gradi programsko opremo. To lahko storite tako kot direktor kot podpredsednik. Nekaj drugega?
»Uf, Rands! Ampak nekdo mora biti razsodnik! Nekdo mora videti veliko sliko. Če pišem kodo, bom izgubil perspektivo."
Še vedno moraš biti sodnik, še vedno moraš predvajati odločitve in še vedno moraš vsak ponedeljek zjutraj štirikrat hoditi okoli zgradbe z enim od svojih inženirjev, da poslušaš njegovo tedensko tarnanje "Vsi smo obsojeni" za 30 minut.! Toda poleg vsega tega morate ohraniti inženirsko miselnost in za to vam ni treba biti programer s polnim delovnim časom.
Moji nasveti za ohranjanje inženirske miselnosti:
- Uporabite razvojno okolje. To pomeni, da morate poznati orodja vaše ekipe, vključno s sistemom za gradnjo kode, nadzorom različic in programskim jezikom. Posledično boste postali vešči jezika, ki ga vaša ekipa uporablja, ko govori o razvoju izdelkov. Tako boste lahko še naprej uporabljali svoj najljubši urejevalnik besedil, ki deluje brezhibno.
- Morate biti sposobni kadar koli narisati podroben arhitekturni diagram, ki opisuje vaš izdelek, na katero koli površino. Zdaj ne mislim na poenostavljeno različico s tremi celicami in dvema puščicama. Poznati morate podroben diagram izdelka. Najtežji. Ne kar ljubek diagram, ampak diagram, ki ga je težko razložiti. To mora biti zemljevid, primeren za popolno razumevanje izdelka. Nenehno se spreminja in vedno morate vedeti, zakaj je do določenih sprememb prišlo.
- Prevzemite izvajanje ene od funkcij. Ko to pišem, se dobesedno stresam, ker ima ta točka veliko skritih nevarnosti, vendar res nisem prepričan, da lahko dosežete točko #1 in točko #2, ne da bi se zavezali implementaciji vsaj ene funkcije. Če sami implementirate eno od funkcij, ne boste le aktivno vključeni v razvojni proces, ampak vam bo tudi omogočilo, da občasno preklopite iz vloge »vodje, ki je zadolžen za vse« v vlogo »človeka, ki je zadolžen za implementacijo funkcij." Ta skromen in nezahteven odnos vas bo spomnil na pomen majhnih odločitev.
- Še vedno se vsa tresem. Zdi se, da mi že nekdo vpije: »Menadžer, ki je nase prevzel opravljanje funkcije?! (In strinjam se z njim!) Da, še vedno ste vodja, kar pomeni, da bi morala biti to majhna funkcija, v redu? Ja, še veliko moraš postoriti. Če preprosto ne morete prevzeti implementacije funkcije, potem imam nekaj rezervnih nasvetov za vas: odpravite nekaj napak. V tem primeru ne boste čutili veselja do ustvarjanja, boste pa razumeli, kako izdelek nastaja, kar pomeni, da ne boste nikoli ostali brez dela.
- Napišite teste enot. To še vedno počnem pozno v proizvodnem ciklu, ko ljudje začnejo noreti. Na to pomislite kot na zdravstveni kontrolni seznam za vaš izdelek. Počnite to pogosto.
Spet ugovor?
»Rands, če bom napisal kodo, bom zmedel svojo ekipo. Ne bodo vedeli, kdo sem – upravitelj ali razvijalec.«
Vse je v redu.
Da, rekel sem, "V redu!" Veseli me, da misliš, da lahko zmedeš svojo ekipo samo s plavanjem v jezeru za razvijalce. Preprosto: meje med različnimi vlogami pri razvoju programske opreme so trenutno zelo zabrisane. Fantje z uporabniškim vmesnikom delajo tisto, kar lahko na splošno imenujemo programiranje JavaScript in CSS. Razvijalci se čedalje več učijo o oblikovanju uporabniške izkušnje. Ljudje komunicirajo med seboj in se učijo o hroščih, o kraji kode drugih ljudi in tudi o dejstvu, da ni nobenega dobrega razloga, da vodja ne bi sodeloval v tej množični, globalni informacijski bakanaliji navzkrižnega opraševanja.
Poleg tega želite biti del ekipe, sestavljene iz enostavno zamenljivih komponent? To ne bo samo naredilo vašo ekipo bolj spretno, ampak bo vsakemu članu ekipe dalo priložnost, da vidi izdelek in podjetje iz različnih perspektiv. Kako lahko spoštuješ Franka, umirjenega fanta, ki je odgovoren za gradnje, nič bolj kot potem, ko vidiš preprosto eleganco njegovih scenarijev za gradnjo?
Nočem, da vaša ekipa postane zmedena in kaotična. Nasprotno, želim si, da bi vaša ekipa bolj učinkovito komunicirala. Verjamem, da če sodelujete pri ustvarjanju izdelka in delate na funkcijah, boste bližje svoji ekipi. In kar je še pomembneje, bližje boste nenehnim spremembam v procesu razvoja programske opreme v vaši organizaciji.
Ne nehajte se razvijati
Moja kolegica pri Borlandu me je nekoč verbalno napadla, ker sem jo imenovala »koderka«.
»Rands, kodirnik je brezglav stroj! opica! Kodirnik ne počne ničesar pomembnega, razen piše dolgočasne vrstice neuporabne kode. Nisem koder, sem razvijalec programske opreme!«
Imela je prav, sovražila bi moj začetni nasvet novim izvršnim direktorjem: "Nehajte pisati kodo!" Ne zato, ker trdim, da so kodirniki, ampak bolj zato, ker proaktivno predlagam, da začnejo ignorirati enega najpomembnejših delov svojega dela: razvoj programske opreme.
Zato sem posodobil svoj nasvet. Če želite biti dober vodja, lahko prenehate pisati kodo, toda ...
Bodite prilagodljivi. Ne pozabite, kaj pomeni biti inženir, in ne nehajte razvijati programske opreme.
O avtorju
Michael Lopp je veteran razvijalec programske opreme, ki še vedno ni zapustil Silicijeve doline. Michael je v zadnjih 20 letih delal za različna inovativna podjetja, med drugim Apple, Netscape, Symantec, Borland, Palantir, Pinterest, sodeloval pa je tudi pri startupu, ki je počasi odplaval v pozabo.
Michael izven dela vodi priljubljen blog o tehnologiji in managementu pod psevdonimom Rands, kjer z bralci razpravlja o idejah na področju managementa, izraža zaskrbljenost zaradi nenehne potrebe po spremljanju in razlaga, da kljub velikodušne nagrade za ustvarjanje izdelka, je vaš uspeh mogoč samo zahvaljujoč vaši ekipi. Blog najdete tukaj .
Michael živi z družino v Redwoodu v Kaliforniji. Vedno najde čas za gorsko kolo, igranje hokeja in pitje rdečega vina, saj je zdravje pomembnejše od dela.
» Več o knjigi najdete na
»
»
Za Khabrozhiteley 20% popust z uporabo kupona - Upravljanje z ljudmi
Ob plačilu papirne različice knjige vam po elektronski pošti pošljemo elektronsko različico knjige.
PS: 7% cene knjige gre za prevode novih računalniških knjig, seznam knjig, predanih v tiskarno .
Vir: www.habr.com