Posvećeno projekt menadžerima (i onima koji sanjaju da postanu šefovi).
Pisanje tona koda je teško, ali upravljanje ljudima je još teže! Dakle, ova knjiga vam je potrebna samo da naučite kako da radite oboje.
Da li je moguće spojiti smiješne priče i ozbiljne lekcije? Michael Lopp (također poznat u uskim krugovima kao Rands) je uspio. Pronaći ćete izmišljene priče o izmišljenim ljudima sa nevjerovatno korisnim (iako izmišljenim) iskustvima. Ovako Rands dijeli svoja raznolika, ponekad čudna iskustva stečena tokom godina rada u velikim IT korporacijama: Apple, Pinterest, Palantir, Netscape, Symantec, itd.
Jeste li projekt menadžer? Ili želite da shvatite šta vaš prokleti šef radi po ceo dan? Rands će vas naučiti kako preživjeti u Toksičnom svijetu napuhanih ćuraka i napredovati u općem ludilu disfunkcionalno blistavih ljudi. U ovoj čudnoj zajednici manijakalnih pametnjaka postoje još čudnija stvorenja - menadžeri koji su kroz mistični organizacioni ritual stekli vlast nad planovima, mislima i bankovnim računima mnogih ljudi.
Ova knjiga nije nalik bilo kojem rukopisu rukovođenja ili rukovođenja. Michael Lopp ništa ne krije, samo priča onako kako jeste (možda ne bi trebalo sve priče javno objaviti: P). Ali samo tako ćete shvatiti kako preživjeti s takvim šefom, kako upravljati štreberima i štreberima i kako „taj prokleti projekat“ dovesti do sretnog kraja!
Izvod. Inženjerski mentalitet
Razmišljanja o: Trebate li nastaviti pisati kod?
Randsova knjiga o pravilima za menadžere sadrži vrlo kratku listu modernih menadžerskih „obaveznih obaveza“. Lakonizam ove liste proizilazi iz činjenice da je koncept „mora“ neka vrsta apsoluta, a kada su ljudi u pitanju, apsolutnih pojmova je vrlo malo. Uspješan način upravljanja za jednog zaposlenika bit će prava katastrofa za drugog. Ova misao je prva stavka na menadžerovoj listi "must do":
Ostanite fleksibilni!
Misliti da već sve znate je veoma loša ideja. U situaciji u kojoj je jedina stalna činjenica da se svijet stalno mijenja, fleksibilnost postaje jedina ispravna pozicija.
Paradoksalno, druga stavka na listi je iznenađujuće nefleksibilna. Međutim, ova tačka je moj lični favorit jer vjerujem da pomaže u stvaranju temelja za menadžerski rast. Ovaj paragraf glasi:
Prestani pisati kod!
U teoriji, ako želite da budete menadžer, morate naučiti da verujete onima koji rade za vas i da im u potpunosti predate kodiranje. Ovaj savjet je obično teško svariti, posebno za novopečene menadžere. Vjerovatno je jedan od razloga zašto su postali menadžeri njihova produktivnost u razvoju, a kada stvari krenu po zlu, njihova prva reakcija je da se vrate vještinama u koje imaju puno povjerenje, a to je njihova sposobnost pisanja koda.
Kada vidim da se novopečeni menadžer „tone“ u pisanje koda, kažem mu: „Znamo da možete pisati kod. Pitanje je: možete li voditi? Više niste odgovorni samo za sebe, odgovorni ste za cijeli tim; i želim biti siguran da možete natjerati svoj tim da samostalno rješava probleme, bez potrebe da sami pišete kod. Vaš posao je da shvatite kako se skalirati. Ne želim da budeš samo jedan, želim da bude mnogo poput tebe.”
Dobar savjet, zar ne? Scale. Menadžment. Odgovornost. Takve uobičajene riječi. Šteta što je savjet pogrešan.
Netačno?
Da. Savjet je pogrešan! Ne potpuno pogrešno, ali dovoljno pogrešno da sam morao nazvati neke bivše kolege i ispričati se: „Sjećate se one moje omiljene izjave o tome kako treba prestati pisati kod? Krivo je! Da... Počnite ponovo programirati. Počnite s Pythonom i Rubyjem. Da, ozbiljan sam! Vaša karijera zavisi od toga!”
Kada sam započeo svoju karijeru kao programer softvera u Borlandu, radio sam u Paradox Windows timu, koji je bio ogroman tim. Bilo je samo 13 programera aplikacija. Ako dodate ljude iz drugih timova koji su takođe stalno radili na ključnim tehnologijama za ovaj projekat, kao što su jezgro baze podataka i osnovne aplikacije, dobili ste 50 inženjera direktno uključenih u razvoj ovog proizvoda.
Nijedan drugi tim za koji sam ikada radio nije ni blizu ove veličine. Zapravo, svake godine se postepeno smanjuje broj ljudi u timu u kojem radim. Šta se dešava? Da li smo mi programeri zajedno sve pametniji i pametniji? Ne, mi samo dijelimo teret.
Šta su programeri radili u posljednjih 20 godina? Za to vrijeme napisali smo gomilu koda. More koda! Napisali smo toliko koda da smo odlučili da bi bilo dobro sve pojednostaviti i otići na otvoreni kod.
Na sreću, zahvaljujući internetu, ovaj proces je sada postao što jednostavniji. Ako ste programer softvera, možete to provjeriti odmah! Pretražite svoje ime na Google-u ili Githubu i vidjet ćete kod na koji ste odavno zaboravili, ali koji svako može pronaći. Strašno, zar ne? Zar niste znali da taj kod živi zauvek? Da, on živi zauvek.
Kod živi zauvek. A dobar kod ne samo da živi vječno, već i raste jer oni koji ga cijene stalno osiguravaju da ostane svjež. Ova gomila visokokvalitetnog, dobro održavanog koda pomaže u smanjenju prosječne veličine inženjerskog tima jer nam omogućava da se fokusiramo na postojeći kod umjesto da pišemo novi, i da posao obavimo s manje ljudi iu kraćem vremenskom okviru.
Ova linija rezonovanja zvuči depresivno, ali ideja je da smo svi mi samo gomila integracijskih automata koji koriste ljepljivu traku za povezivanje različitih dijelova postojećih stvari zajedno kako bismo stvorili malo drugačiju verziju iste stvari. Ovo je klasična linija razmišljanja među višim rukovodiocima koji vole outsourcing. “Svako ko zna da koristi Google i ima ljepljivu traku može to učiniti! Zašto onda plaćamo mnogo novca za naše mašine?”
Plaćamo ove momke iz menadžmenta stvarno velike pare, ali oni misle takve gluposti. Još jednom, moja ključna poenta je da na našoj planeti postoji mnogo briljantnih i vrlo vrijednih programera; oni su zaista briljantni i vrijedni, iako nisu proveli ni minut sedeći na akreditovanim univerzitetima. O da, sada ih je sve više!
Ne predlažem da počnete da brinete o svom mestu samo zato što ga neki sjajni drugovi navodno traže. Predlažem da počnete da brinete o tome jer se evolucija razvoja softvera verovatno kreće brže od vas. Radite deset godina, od toga pet kao menadžer, i mislite: „Ja već znam kako se razvija softver.“ Da, znaš. ćao…
Prestani pisati kod, ali...
Ako slijedite moj originalni savjet i prestanete pisati kod, također ćete dobrovoljno prestati da učestvujete u procesu kreiranja. Iz tog razloga ne koristim aktivno outsourcing. Automati ne stvaraju, oni proizvode. Dobro osmišljeni procesi štede mnogo novca, ali ne donose ništa novo u naš svijet.
Ako imate mali tim koji radi puno za malo novca, onda mi se ideja o prestanku pisanja koda čini lošom odlukom u karijeri. Čak i u monstruoznim kompanijama sa njihovim beskrajnim propisima, procesima i politikama, nemate pravo zaboraviti kako sami razvijati softver. A razvoj softvera se stalno mijenja. To se trenutno mijenja. Pod nogama! U ovoj sekundi!
Imate prigovore. Razumijem. Hajde da slušamo.
“Rands, na putu sam do direktorske fotelje! Ako nastavim pisati kod, niko neće vjerovati da mogu rasti.”
Želim da vas pitam ovo: otkako ste sedeli u svojoj fotelji „Uskoro ću biti CEO!”, da li ste primetili da se okruženje razvoja softvera menja, čak i unutar vaše kompanije? Ako je vaš odgovor potvrdan, onda ću vam postaviti još jedno pitanje: kako se to tačno mijenja i šta ćete učiniti u vezi s tim promjenama? Ako ste na moje prvo pitanje odgovorili sa „ne“, onda morate da pređete na drugu stolicu, jer (kladim se!) polje razvoja softvera se menja u ovoj sekundi. Kako ćete ikada rasti ako polako, ali sigurno zaboravite kako se razvija softver?
Moj savjet je da se ne obavezujete na implementaciju tona funkcija za vaš sljedeći proizvod. Morate stalno poduzimati korake kako biste ostali u toku s tim kako vaš tim gradi softver. To možete učiniti i kao direktor i kao potpredsjednik. Nešto drugo?
“Uf, Rands! Ali neko mora biti arbitar! Neko mora da vidi širu sliku. Ako napišem kod, izgubiću perspektivu."
I dalje morate da budete sudija, još uvek morate da prenosite odluke, i još uvek morate da obiđete zgradu četiri puta svakog ponedeljka ujutru sa jednim od svojih inženjera da biste slušali njegovu nedeljnu poruku "Svi smo osuđeni na propast" za 30 minuta.! Ali pored svega toga, morate zadržati inženjerski način razmišljanja i ne morate biti programer sa punim radnim vremenom da biste to učinili.
Moji savjeti za održavanje inženjerskog mentaliteta:
- Koristite razvojno okruženje. To znači da biste trebali biti upoznati sa alatima vašeg tima, uključujući sistem za pravljenje koda, kontrolu verzija i programski jezik. Kao rezultat toga, postaćete vešti jezikom koji vaš tim koristi kada govori o razvoju proizvoda. Ovo će vam također omogućiti da nastavite koristiti svoj omiljeni uređivač teksta, koji savršeno funkcionira.
- Morate biti u mogućnosti da nacrtate detaljan arhitektonski dijagram koji opisuje vaš proizvod na bilo kojoj površini u bilo koje vrijeme. Ne mislim na pojednostavljenu verziju sa tri ćelije i dvije strelice. Morate znati detaljan dijagram proizvoda. Najteži. Ne bilo kakav sladak dijagram, već dijagram koji je teško objasniti. To bi trebala biti mapa prikladna za potpuno razumijevanje proizvoda. Stalno se mijenja i uvijek treba znati zašto je došlo do određenih promjena.
- Preuzmi implementaciju jedne od funkcija. Bukvalno se trzam dok ovo pišem jer ova tačka ima mnogo skrivenih opasnosti, ali zaista nisam siguran da možete postići tačku #1 i tačku #2 bez obavezivanja da implementirate barem jednu funkciju. Samim implementiranjem jedne od funkcija, ne samo da ćete biti aktivno uključeni u proces razvoja, već će vam omogućiti i da povremeno prelazite s uloge „Menadžera koji je zadužen za sve“ na ulogu „Čovjeka zaduženog za implementaciju jedne funkcija.” Ovaj skroman i skroman stav podsjetit će vas na važnost malih odluka.
- Još uvijek se tresem. Čini se da mi već neko viče: “Menadžer koji je na sebe preuzeo sprovođenje funkcije?! (I slažem se s njim!) Da, ti si još uvijek menadžer, što znači da bi to trebala biti neka mala funkcija, u redu? Da, još uvijek imate puno posla. Ako jednostavno ne možete preuzeti implementaciju funkcije, onda imam nekoliko savjeta za rezervnu kopiju za vas: popravite neke greške. U tom slučaju nećete osjetiti radost stvaranja, ali ćete imati razumijevanje kako proizvod nastaje, što znači da nikada nećete ostati bez posla.
- Napišite jedinične testove. Ovo još uvijek radim kasno u proizvodnom ciklusu kada ljudi počnu ludovati. Razmislite o tome kao o zdravstvenoj kontrolnoj listi za vaš proizvod. Radite to često.
Opet prigovor?
“Rands, ako napišem kod, zbuniću svoj tim. Neće znati ko sam ja – menadžer ili programer.”
Dobro.
Da, rekao sam, "U redu!" Drago mi je što mislite da možete zbuniti svoj tim samo plivanjem u ribnjaku za razvojne programere. Jednostavno je: granice između različitih uloga u razvoju softvera trenutno su veoma zamagljene. UI momci rade ono što se široko može nazvati JavaScript i CSS programiranjem. Programeri uče sve više i više o dizajnu korisničkog iskustva. Ljudi komuniciraju jedni s drugima i uče o greškama, o krađi tuđeg koda, kao i o činjenici da nema dobrog razloga da menadžer ne učestvuje u ovoj masovnoj, globalnoj, unakrsnoj informacijskoj vakhanaliji.
Osim toga, želite li biti dio tima koji se sastoji od lako zamjenjivih komponenti? Ovo neće samo učiniti vaš tim okretnijim, već će svakom članu tima dati priliku da vidi proizvod i kompaniju iz različitih perspektiva. Kako možete početi da poštujete Franka, mirnog momka zaduženog za gradnje, više nego nakon što vidite jednostavnu eleganciju njegovih skripta za izradu?
Ne želim da vaš tim postane zbunjen i haotičan. Naprotiv, želim da vaš tim efikasnije komunicira. Vjerujem da ćete, ako ste uključeni u kreiranje proizvoda i rad na funkcijama, biti bliži svom timu. I što je još važnije, bićete bliže stalnim promjenama u procesu razvoja softvera unutar vaše organizacije.
Nemojte prestati da se razvijate
Moja koleginica iz Borlanda jednom me je verbalno napala jer sam je nazvao "koderom".
“Rands, koder je bezumna mašina! Majmun! Koder ne radi ništa važno osim što piše dosadne linije beskorisnog koda. Ja nisam koder, ja sam programer!"
Bila je u pravu, mrzela bi moj početni savet novim izvršnim direktorima: „Prestanite da pišete kod!“ Ne zato što sugeriram da su oni koderi, već više zato što proaktivno predlažem da počnu ignorirati jedan od najvažnijih dijelova svog posla: razvoj softvera.
Stoga sam ažurirao svoj savjet. Ako želite da budete dobar vođa, možete prestati pisati kod, ali...
Budite fleksibilni. Zapamtite šta znači biti inženjer i nemojte prestati razvijati softver.
O autoru
Michael Lopp je iskusni programer softvera koji još uvijek nije napustio Silicijumsku dolinu. Tokom proteklih 20 godina, Michael je radio za razne inovativne kompanije, uključujući Apple, Netscape, Symantec, Borland, Palantir, Pinterest, a također je učestvovao u startupu koji je polako odleteo u zaborav.
Izvan posla, Michael vodi popularni blog o tehnologiji i menadžmentu pod pseudonimom Rands, gdje s čitaocima raspravlja o idejama iz oblasti menadžmenta, izražava zabrinutost zbog stalne potrebe da drži prst na pulsu i objašnjava da, uprkos velikodušne nagrade za kreiranje proizvoda, vaš uspjeh je moguć samo zahvaljujući vašem timu. Blog možete pronaći ovdje .
Michael živi sa svojom porodicom u Redwoodu u Kaliforniji. Uvijek nađe vremena za brdski biciklizam, igranje hokeja i pijenje crnog vina, jer je važnije biti zdrav nego biti zauzet.
» Za više informacija o knjizi, posjetite
»
»
Za Khabrozhiteli 20% popusta na kupon - Upravljanje ljudima
Po uplati papirne verzije knjige, elektronska verzija knjige će biti poslana e-poštom.
PS: 7% od cene knjige ide za prevod novih kompjuterskih knjiga, spisak knjiga predatih u štampariju .
izvor: www.habr.com