Namijenjeno voditeljima projekata (i onima koji sanjaju postati šefovi).
Teško je napisati gomilu koda, ali još je teže upravljati ljudima! Dakle, samo vam treba ova knjiga da naučite kako raditi oboje.
Je li moguće spojiti smiješne priče i ozbiljne lekcije? Michael Lopp (u uskim krugovima poznat i kao Rands) je uspio. Naći ćete izmišljene priče o izmišljenim ljudima s nevjerojatno korisnim (iako izmišljenim) iskustvima. Ovako Rands iznosi svoja raznolika, ponekad čudna iskustva stečena tijekom godina rada u velikim IT korporacijama: Apple, Pinterest, Palantir, Netscape, Symantec itd.
Jeste li voditelj projekta? Ili želite razumjeti što vaš prokleti šef radi cijeli dan? Rands će vas naučiti kako preživjeti u Toksičnom svijetu napuhanih purana i napredovati u općem ludilu disfunkcionalno kitnjastih ljudi. U ovoj neobičnoj zajednici manijakalnih pametnjakovića postoje još čudnija stvorenja - menadžeri koji su mističnim organizacijskim ritualom zagospodarili planovima, mislima i bankovnim računima mnogih ljudi.
Ova je knjiga drugačija od bilo kojeg rukopisa upravljanja ili vodstva. Michael Lopp ne skriva ništa, on samo priča kako jest (možda ne bi sve priče trebale izlaziti u javnost :P). Ali samo tako ćete shvatiti kako preživjeti s takvim šefom, kako upravljati štreberima i štreberima i kako “taj prokleti projekt” privesti sretnom kraju!
Izvod. Inženjerski mentalitet
Razmišljanja o: Trebate li nastaviti pisati kod?
Randsova knjiga o pravilima za menadžere sadrži vrlo kratak popis modernih menadžerskih "obaveznih radnji". Lakonizam ovog popisa proizlazi iz činjenice da je pojam “mora” neka vrsta apsoluta, a kada su ljudi u pitanju, apsolutnih pojmova je vrlo malo. Uspješna metoda upravljanja za jednog zaposlenika bit će prava katastrofa za drugog. Ova je misao prva stavka na menadžerovom popisu stvari koje treba učiniti:
Ostanite fleksibilni!
Misliti da već sve znate vrlo je loša ideja. U situaciji kada je jedina stalna činjenica da se svijet neprestano mijenja, fleksibilnost postaje jedino ispravno stajalište.
Paradoksalno, druga stavka na popisu je iznenađujuće nefleksibilna. Međutim, ova je točka moj osobni favorit jer vjerujem da pomaže u stvaranju temelja za menadžerski rast. Ovaj paragraf glasi:
Prestanite pisati kod!
U teoriji, ako želite biti menadžer, morate naučiti vjerovati onima koji rade za vas i u potpunosti im prepustiti kodiranje. Ovaj savjet je obično teško probaviti, posebno za novopečene menadžere. Vjerojatno je jedan od razloga zašto su postali menadžeri njihova produktivnost u razvoju, a kada stvari krenu po zlu, prva reakcija im je da se vrate vještinama u koje imaju puno povjerenje, a to je njihova sposobnost pisanja koda.
Kad vidim da novopečeni menadžer “tone” u pisanje koda, kažem mu: “Mi znamo da ti znaš pisati kod. Pitanje je: možete li voditi? Više niste odgovorni sami za sebe, odgovorni ste za cijeli tim; i želim biti siguran da možete natjerati svoj tim da sam rješava probleme, a da sami ne morate pisati kod. Vaš je posao shvatiti kako se povećati. Ne želim da budeš samo jedan, želim da ih bude mnogo poput tebe.”
Dobar savjet, zar ne? Skala. Upravljanje. Odgovornost. Tako uobičajene poštapalice. Šteta što je savjet pogrešan.
Netočno?
Da. Savjet je pogrešan! Nije 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 biste trebali prestati pisati kod? Pogrešno je! Da... Počni ponovno programirati. Počnite s Pythonom i Rubyjem. Da, ozbiljan sam! Vaša karijera ovisi o tome!”
Kad sam započeo svoju karijeru kao programer softvera u Borlandu, radio sam u Paradox Windows timu, koji je bio ogroman tim. Samo programera aplikacija bilo je 13. Ako dodate ljude iz drugih timova koji su također neprestano radili na ključnim tehnologijama za ovaj projekt, kao što je jezgreni motor baze podataka i jezgrene aplikacijske usluge, dobili ste 50 inženjera izravno uključenih u razvoj ovog proizvoda.
Nijedan drugi tim za koji sam ikada radio nije ni blizu ove veličine. Zapravo, sa svakom godinom broj ljudi u timu u kojem radim postupno se smanjuje. Što se događa? Postajemo li mi programeri kolektivno sve pametniji i pametniji? Ne, samo dijelimo teret.
Što su programeri radili zadnjih 20 godina? Za to vrijeme napisali smo hrpu koda. More kodova! Napisali smo toliko koda da smo odlučili da bi bilo dobro sve pojednostaviti i otvoriti kod.
Srećom, zahvaljujući internetu, ovaj je proces sada postao maksimalno jednostavan. Ako ste programer softvera, možete to provjeriti upravo sada! Pretražite svoje ime na Googleu ili Githubu i vidjet ćete kod na koji ste odavno zaboravili, ali ga svatko može pronaći. Zastrašujuće, zar ne? Niste znali da šifra živi vječno? Da, živi vječno.
Šifra živi vječno. A dobar kod ne samo da živi vječno, on raste jer oni koji ga cijene neprestano osiguravaju da ostane svjež. Ova hrpa visokokvalitetnog, dobro održavanog koda pomaže u smanjenju prosječne veličine inženjerskog tima jer nam omogućuje da se usredotočimo na postojeći kod umjesto na pisanje novog koda, te obavimo posao s manje ljudi i u kraćem vremenskom roku.
Ovakvo rezoniranje zvuči deprimirajuće, ali ideja je da smo svi mi samo hrpa integracijskih automata koji koriste ljepljivu traku za spajanje različitih dijelova postojećih stvari kako bi stvorili nešto drugačiju verziju iste stvari. Ovo je klasična linija razmišljanja među višim rukovoditeljima koji vole outsourcing. “Ovo može svatko tko zna koristiti Google i ima malo ljepljive trake! Zašto onda plaćamo puno novca našim strojevima?"
Mi ovim menadžerima plaćamo stvarno velike novce, ali oni misle takve gluposti. Još jednom, moja ključna poenta je da postoji mnogo briljantnih i vrlo marljivih programera na našem planetu; doista su briljantni i marljivi, iako nisu proveli niti jednu minutu sjedeći na akreditiranim sveučilištima. O da, sada ih je sve više!
Ne predlažem da se počnete brinuti za svoje mjesto samo zato što ga neki briljantni drugovi navodno traže. Predlažem da počnete brinuti o tome jer se evolucija razvoja softvera vjerojatno kreće brže od vas. Radite deset godina, od toga pet kao menadžer, i mislite: “Već znam kako se razvija softver.” Da, znaš. Pozdrav…
Prestanite pisati kod, ali...
Ako slijedite moj izvorni savjet i prestanete pisati kod, također ćete dobrovoljno prestati sudjelovati u procesu stvaranja. 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 našem svijetu.
Ako imate mali tim koji radi puno za malo novca, onda mi se ideja o prestanku pisanja koda čini kao loša odluka u karijeri. Čak ni u čudovišnim tvrtkama s njihovim beskrajnim propisima, procesima i politikama, nemate pravo zaboraviti kako sami razviti softver. A razvoj softvera se stalno mijenja. Upravo se mijenja. Pod noge! U ovoj sekundi!
Imate prigovora. razumjeti. Poslušajmo.
“Rands, na putu sam prema direktorskoj stolici! Ako nastavim pisati kod, nitko neće vjerovati da mogu rasti.”
Želim vas pitati ovo: otkako ste sjedili u svojoj stolici tipa "Uskoro ću postati CEO!", jeste li primijetili da se krajolik razvoja softvera mijenja, čak i unutar vaše tvrtke? Ako je vaš odgovor potvrdan, onda ću vam postaviti još jedno pitanje: kako se to točno mijenja i što ćete učiniti u vezi s tim promjenama? Ako ste odgovorili s "ne" na moje prvo pitanje, onda se morate preseliti na drugu stolicu, jer (kladim se!) polje razvoja softvera se mijenja ove sekunde. Kako ćete ikada rasti ako polako, ali sigurno zaboravite kako razvijati softver?
Moj savjet je da se ne obvezujete na implementaciju tona značajki za svoj sljedeći proizvod. Morate stalno poduzimati korake kako biste bili u tijeku s tim kako vaš tim izrađuje softver. To možete raditi i kao direktor i kao potpredsjednik. Nešto drugo?
“Uh, Rands! Ali netko mora biti arbitar! Netko mora vidjeti širu sliku. Ako napišem kod, izgubit ću perspektivu."
Još uvijek moraš biti sudac, još uvijek moraš emitirati odluke, i još uvijek moraš hodati oko zgrade četiri puta svakog ponedjeljka ujutro s jednim od svojih inženjera kako bi slušao njegovu tjednu dreku "Svi smo osuđeni" za 30 minuta.! Ali osim svega toga, morate zadržati inženjerski način razmišljanja, a ne morate biti programer s 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 s alatima svog tima, uključujući sustav za izradu koda, kontrolu verzija i programski jezik. Kao rezultat toga, postat ćete vješti u jeziku koji vaš tim koristi kada govori o razvoju proizvoda. To će vam također omogućiti da nastavite koristiti svoj omiljeni uređivač teksta, koji savršeno funkcionira.
- Morate biti u mogućnosti nacrtati detaljan arhitektonski dijagram koji opisuje vaš proizvod na bilo kojoj površini u bilo koje vrijeme. Ne mislim na pojednostavljenu verziju s tri ćelije i dvije strelice. Morate znati detaljan dijagram proizvoda. Onaj najteži. Ne bilo kakav slatki dijagram, već dijagram koji je teško objasniti. To bi trebala biti karta prikladna za potpuno razumijevanje proizvoda. Stalno se mijenja, a uvijek treba znati zašto je došlo do određenih promjena.
- Preuzeti provedbu jedne od funkcija. Doslovno se grčim dok ovo pišem jer ova točka ima mnogo skrivenih opasnosti, ali stvarno nisam siguran da možete postići točku #1 i točku #2 bez obvezivanja na implementaciju barem jedne značajke. Ako sami implementirate jednu od značajki, ne samo da ćete biti aktivno uključeni u razvojni proces, već će vam omogućiti i da se povremeno prebacite iz uloge „Upravitelja zaduženog za sve“ u ulogu „Čovjeka zaduženog za implementaciju jednog funkcija." Ovaj skroman i skroman stav podsjetit će vas na važnost malih odluka.
- Još uvijek se cijelim tijelom tresem. Čini mi se da mi već netko viče: “Menadžer koji je na sebe preuzeo obnašanje funkcije?!” (I slažem se s njim!) Da, još uvijek ste menadžer, što znači da bi to trebala biti neka mala funkcija, u redu? Da, još imaš puno toga za napraviti. Ako jednostavno ne možete preuzeti implementaciju funkcije, onda imam rezervni savjet za vas: popravite neke greške. U tom slučaju nećete osjetiti radost stvaranja, ali ćete razumjeti kako proizvod nastaje, što znači da nikada nećete ostati bez posla.
- Napišite jedinične testove. Još uvijek to radim kasno u proizvodnom ciklusu kad ljudi počnu luditi. Zamislite to kao zdravstveni popis za svoj proizvod. Činite to često.
Opet prigovor?
“Rands, ako napišem kod, zbunit ću svoj tim. Neće znati tko sam ja - menadžer ili programer."
U redu.
Da, rekao sam, "U redu!" Drago mi je što misliš da možeš zbuniti svoj tim samo plivanjem u jezercu za razvojne programere. Jednostavno je: granice između različitih uloga u razvoju softvera trenutno su vrlo nejasne. Dečki iz korisničkog sučelja rade ono što se općenito može nazvati JavaScript i CSS programiranje. Programeri sve više uče o dizajnu korisničkog iskustva. Ljudi komuniciraju jedni s drugima i uče o greškama, o krađi koda drugih ljudi, kao io činjenici da nema dobrog razloga da menadžer ne sudjeluje u ovoj masovnoj, globalnoj informacijskoj bakanaliji koja se međusobno oprašuje.
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 tvrtku iz raznih perspektiva. Kako možeš početi poštovati Franka, mirnog tipa zaduženog za izgradnju, više nego nakon što vidiš jednostavnu eleganciju njegovih skripti za izgradnju?
Ne želim da vaš tim postane zbunjen i kaotičan. Naprotiv, želim da vaš tim učinkovitije komunicira. Vjerujem da ako ste uključeni u kreiranje proizvoda i rad na značajkama, bit ćete bliže svom timu. I što je još važnije, bit ćete bliže stalnim promjenama u procesu razvoja softvera unutar vaše organizacije.
Nemojte prestati razvijati se
Moja kolegica u Borlandu jednom me verbalno napala jer sam je nazvao "koderom".
“Rands, koder je bezumni stroj! Majmun! Koder ne radi ništa važno osim što piše dosadne retke beskorisnog koda. Ja nisam programer, ja sam programer!”
Bila je u pravu, mrzila bi moj početni savjet novim izvršnim direktorima: "Prestanite pisati kod!" Ne zato što sugeriram da su programeri, već više zato što im proaktivno sugeriram da počnu ignorirati jedan od najvažnijih dijelova svog posla: razvoj softvera.
Stoga sam ažurirao svoj savjet. Ako želite biti dobar vođa, možete prestati pisati kod, ali...
Budite fleksibilni. Zapamtite što znači biti inženjer i nemojte prestati razvijati softver.
O autoru
Michael Lopp veteran je programer softvera koji još uvijek nije napustio Silicijsku dolinu. U proteklih 20 godina Michael je radio za razne inovativne tvrtke, uključujući Apple, Netscape, Symantec, Borland, Palantir, Pinterest, a također je sudjelovao u startupu koji je polako otišao u zaborav.
Izvan posla, Michael vodi popularan blog o tehnologiji i menadžmentu pod pseudonimom Rands, gdje s čitateljima raspravlja o idejama na polju menadžmenta, izražava zabrinutost zbog stalne potrebe da drži prst na pulsu i objašnjava da, unatoč velikodušne nagrade za stvaranje proizvoda, vaš uspjeh moguć je samo zahvaljujući vašem timu. Blog možete pronaći ovdje .
Michael živi sa svojom obitelji u Redwoodu u Kaliforniji. Uvijek nađe vremena za brdski biciklizam, igranje hokeja i ispijanje crnog vina jer je važnije biti zdrav nego imati posla.
» Više detalja o knjizi možete pronaći na
»
»
Za Khabrozhiteley 20% popusta korištenjem kupona - Upravljanje ljudima
Po uplati papirnate verzije knjige, elektronička verzija knjige bit će poslana e-mailom.
PS: 7% od cijene knjige ide na prijevod novih računalnih knjiga, popis knjiga predanih u tiskaru .
Izvor: www.habr.com