Věnováno projektovým manažerům (a těm, kteří sní o tom, že se stanou šéfy).
Psaní tuny kódu je těžké, ale řízení lidí je ještě těžší! Takže tuto knihu potřebujete, abyste se naučili obojí.
Je možné skloubit vtipné historky a vážné ponaučení? Michael Lopp (v úzkých kruzích známý také jako Rands) uspěl. Najdete fiktivní příběhy o fiktivních lidech s neuvěřitelně obohacujícími (i když fiktivními) zážitky. Takto Rands sdílí své pestré, někdy podivné zkušenosti získané za léta působení ve velkých IT korporacích: Apple, Pinterest, Palantir, Netscape, Symantec atd.
Jste projektový manažer? Nebo chcete pochopit, co váš zatracený šéf celý den dělá? Rands vás naučí, jak přežít v Toxickém světě nafoukaných krůt a prospívat ve všeobecném šílenství dysfunkčně okázalých lidí. V této podivné komunitě šílených brainiaků jsou ještě podivnější stvoření - manažeři, kteří mystickým organizačním rituálem získali moc nad plány, myšlenkami a bankovními účty mnoha lidí.
Tato kniha se nepodobá žádnému rukopisu managementu nebo vedení. Michael Lopp nic neskrývá, jen to říká tak, jak to je (možná by se neměly zveřejňovat všechny příběhy: P). Ale jen tak pochopíte, jak s takovým šéfem přežít, jak zvládnout geeky a nerdy a jak dotáhnout „ten zatracený projekt“ do šťastného konce!
Výňatek. Inženýrská mentalita
Myšlenky na: Měli byste pokračovat v psaní kódu?
Randsova kniha o pravidlech pro manažery obsahuje velmi krátký seznam moderních manažerských „nezbytností“. Lakoničnost tohoto seznamu pramení ze skutečnosti, že pojem „musí“ je jakýmsi absolutním, a pokud jde o lidi, existuje jen velmi málo absolutních pojmů. Úspěšná metoda řízení pro jednoho zaměstnance bude pro jiného skutečnou katastrofou. Tato myšlenka je první položkou na manažerově „povinném“ seznamu:
Zůstaňte flexibilní!
Myslet si, že už všechno víte, je velmi špatný nápad. V situaci, kdy jediným stálým faktem je, že svět se neustále mění, se flexibilita stává jediným správným postojem.
Paradoxně druhá položka na seznamu je překvapivě nepružná. Tento bod je však můj osobní favorit, protože věřím, že pomáhá vytvořit základ pro manažerský růst. Tento odstavec zní:
Přestaňte psát kód!
Teoreticky, pokud chcete být manažerem, musíte se naučit důvěřovat těm, kteří pro vás pracují, a předat kódování zcela jim. Tato rada je obvykle těžko stravitelná, zvláště pro nově ražené manažery. Pravděpodobně jedním z důvodů, proč se stali manažery, je jejich produktivita ve vývoji, a když se něco pokazí, jejich první reakcí je vrátit se k dovednostem, kterým plně důvěřují, což je jejich schopnost psát kód.
Když vidím, že se nově vyražený manažer „ponoří“ do psaní kódu, říkám mu: „Víme, že umíš psát kód. Otázka zní: umíš vést? Už nejste odpovědní sami za sebe, jste odpovědní za celý tým; a chci se ujistit, že dokážete přimět svůj tým, aby řešil problémy sám, aniž byste museli sami psát kód. Vaším úkolem je přijít na to, jak se škálovat. Nechci, abys byl jen jeden, chci, aby takových jako ty bylo mnoho."
Dobrá rada, že? Měřítko. Řízení. Odpovědnost. Takové běžné hlášky. Škoda, že ta rada je špatná.
Nesprávný?
To jo. Rada je špatná! Ne úplně špatně, ale natolik špatně, že jsem musel zavolat některým bývalým kolegům a omluvit se: „Pamatujete si na můj oblíbený výrok o tom, jak byste měli přestat psát kód? Je to špatné! Ano... Začněte znovu programovat. Začněte s Pythonem a Ruby. Ano, myslím to vážně! Závisí na tom vaše kariéra!"
Když jsem začínal svou kariéru jako softwarový vývojář ve společnosti Borland, pracoval jsem v týmu Paradox Windows, což byl obrovský tým. Jen vývojářů aplikací bylo 13. Pokud přidáte lidi z jiných týmů, kteří také neustále pracovali na klíčových technologiích pro tento projekt, jako je základní databázový stroj a základní aplikační služby, získáte 50 inženýrů přímo zapojených do vývoje tohoto produktu.
Žádný jiný tým, pro který jsem kdy pracoval, se této velikosti ani nepřibližuje. Vlastně s každým dalším rokem postupně ubývá lidí v týmu, ve kterém pracuji. Co se děje? Jsme společně vývojáři stále chytřejší? Ne, jen sdílíme zátěž.
Co dělali vývojáři posledních 20 let? Během této doby jsme napsali hromadu kódu. Moře kódu! Napsali jsme tolik kódu, že jsme se rozhodli, že by bylo dobré vše zjednodušit a přejít na open source.
Naštěstí se tento proces díky internetu stal co nejjednodušší. Pokud jste vývojář softwaru, můžete se na to podívat právě teď! Vyhledejte své jméno na Googlu nebo Github a uvidíte kód, na který jste už dávno zapomněli, ale který může najít kdokoli. Děsivé, že? To jste nevěděli, že kód žije věčně? Ano, žije věčně.
Kód žije věčně. A dobrý kód nejen žije věčně, ale roste, protože ti, kdo si ho váží, neustále zajišťují, aby zůstal čerstvý. Tato hromada vysoce kvalitního a dobře udržovaného kódu pomáhá zmenšit průměrnou velikost inženýrského týmu, protože nám umožňuje soustředit se na stávající kód spíše než psát nový kód a provést práci s menším počtem lidí a v kratším časovém rámci.
Tato úvaha zní depresivně, ale myšlenka je taková, že jsme všichni jen shluk integračních automatů, které používají lepicí pásku k propojení různých částí existujících věcí dohromady a vytvářejí trochu jinou verzi stejné věci. Toto je klasický způsob myšlení mezi vedoucími pracovníky, kteří milují outsourcing. „Každý, kdo ví, jak používat Google a má nějakou lepicí pásku, to dokáže! Tak proč za naše stroje platíme spoustu peněz?"
Platíme těmto manažerům opravdu velké peníze, ale myslí si takové nesmysly. Ještě jednou, můj klíčový bod je, že na naší planetě je mnoho skvělých a velmi tvrdě pracujících vývojářů; jsou skutečně brilantní a pilní, i když nestrávili ani minutu sezením na akreditovaných univerzitách. Ach ano, teď je jich čím dál víc!
Nenavrhuji, abyste se začali bát o své místo jen proto, že po něm údajně pátrají nějací brilantní soudruzi. Navrhuji, abyste si s tím začali dělat starosti, protože vývoj vývoje softwaru pravděpodobně postupuje rychleji než vy. Pracujete deset let, z toho pět jako manažer, a říkáte si: "Už vím, jak se vyvíjí software." Ano víš. Sbohem…
Přestaňte psát kód, ale...
Pokud se budete řídit mými původními radami a přestanete psát kód, přestanete se také dobrovolně podílet na procesu tvorby. Z tohoto důvodu outsourcing aktivně nevyužívám. Automaty netvoří, ale vyrábějí. Dobře navržené procesy ušetří spoustu peněz, ale nepřinesou do našeho světa nic nového.
Pokud máte malý tým, který dělá hodně za málo peněz, pak mi myšlenka přestat psát kód připadá jako špatné kariérní rozhodnutí. Ani v příšerných společnostech s jejich nekonečnými předpisy, procesy a politikami nemáte právo zapomenout, jak si software vyvíjet sami. A vývoj softwaru se neustále mění. Právě teď se to mění. Pod nohama! V tuto chvíli!
Máte námitky. Rozumět. Poslouchejme.
"Randsi, jsem na cestě k ředitelskému křeslu!" Pokud budu dál psát kód, nikdo mi neuvěří, že mohu růst.“
Chci se vás zeptat na toto: od té doby, co jste seděl ve svém křesle „Chystám se být CEO!“, všimli jste si, že se prostředí vývoje softwaru mění, dokonce i ve vaší společnosti? Pokud je vaše odpověď ano, pak vám položím další otázku: jak přesně se to mění a co s těmito změnami hodláte dělat? Pokud jste na mou první otázku odpověděli „ne“, musíte se přesunout na jinou židli, protože (vsadím se!) oblast vývoje softwaru se právě v tuto chvíli mění. Jak budete někdy růst, když pomalu, ale jistě zapomenete, jak vyvíjet software?
Moje rada je nezavazovat se k implementaci spousty funkcí pro svůj další produkt. Musíte neustále podnikat kroky, abyste měli přehled o tom, jak váš tým vytváří software. Můžete to udělat jako ředitel i jako viceprezident. Něco jiného?
„Uf, Randsi! Ale někdo musí být rozhodčí! Někdo musí vidět celkový obraz. Když napíšu kód, ztratím perspektivu.“
Stále musíte být rozhodčím, stále musíte vysílat rozhodnutí a stále musíte každé pondělí ráno čtyřikrát projít kolem budovy s jedním ze svých inženýrů, abyste poslouchali jeho týdenní hlášky „Všichni jsme odsouzeni“ za 30 minut. ! Ale kromě toho všeho si musíte zachovat inženýrské myšlení a nemusíte být programátorem na plný úvazek, abyste to zvládli.
Moje tipy pro udržení inženýrské mentality:
- Použijte vývojové prostředí. To znamená, že byste měli znát nástroje svého týmu, včetně systému vytváření kódu, správy verzí a programovacího jazyka. Díky tomu budete plynule mluvit jazykem, který váš tým používá, když mluví o vývoji produktu. To vám také umožní nadále používat váš oblíbený textový editor, který funguje perfektně.
- Musíte být schopni kdykoli nakreslit detailní architektonický diagram popisující váš produkt na jakémkoli povrchu. Teď nemám na mysli zjednodušenou verzi se třemi buňkami a dvěma šipkami. Musíte znát podrobné schéma produktu. Ten nejtěžší. Ne jen tak nějaké roztomilé schéma, ale schéma, které se těžko vysvětluje. Měla by to být mapa vhodná pro úplné pochopení produktu. Neustále se mění a vždy byste měli vědět, proč k určitým změnám došlo.
- Převzít implementaci jedné z funkcí. Když to píšu, doslova cuknu, protože tento bod má spoustu skrytých nebezpečí, ale opravdu si nejsem jistý, zda můžete dosáhnout bodu #1 a bodu #2, aniž byste se zavázali implementovat alespoň jednu funkci. Tím, že sami implementujete jednu z funkcí, nejen že se aktivně zapojíte do procesu vývoje, umožní vám to také pravidelně přecházet z role „Manažera, který má všechno na starosti“ do role „Muž odpovědný za implementaci jedné“. funkcí." Tento skromný a nenáročný postoj vám připomene důležitost malých rozhodnutí.
- Pořád se celý třesu. Zdá se, že už na mě někdo křičí: "Manažer, který na sebe vzal realizaci funkce?!" (A souhlasím s ním!) Ano, stále jste manažer, což znamená, že by to měla být nějaká malá funkce, ano? Ano, máte toho ještě hodně před sebou. Pokud se prostě nemůžete ujmout implementace funkce, pak pro vás mám pár náhradních rad: opravte některé chyby. V tomto případě nepocítíte radost z tvorby, ale budete mít pochopení pro to, jak produkt vzniká, což znamená, že nikdy nezůstanete bez práce.
- Napište jednotkové testy. Stále to dělám pozdě ve výrobním cyklu, když lidé začnou šílet. Berte to jako zdravotní kontrolní seznam pro váš produkt. Dělejte to často.
Opět námitka?
„Randsi, když napíšu kód, zmást svůj tým. Nebudou vědět, kdo jsem – manažer nebo vývojář.“
Dobrá.
Ano, řekl jsem: "Dobře!" Jsem rád, že si myslíš, že můžeš zmást svůj tým jen tím, že se koupeš v developerském rybníku. Je to jednoduché: hranice mezi různými rolemi ve vývoji softwaru jsou v současnosti velmi nejasné. Kluci z uživatelského rozhraní dělají to, co lze obecně nazvat programováním JavaScript a CSS. Vývojáři se stále více učí o designu uživatelského prostředí. Lidé spolu komunikují a dozvídají se o chybách, o krádežích cizího kódu a také o tom, že neexistuje žádný dobrý důvod, aby se manažer nezúčastnil této masivní, globální, křížově opylující informační bakchanálie.
Kromě toho chcete být součástí týmu skládajícího se ze snadno vyměnitelných komponent? Váš tým tak bude nejen svižnější, ale každému členu týmu to dá příležitost vidět produkt a společnost z různých úhlů pohledu. Jak si můžete vážit Franka, klidného chlapíka, který má na starosti sestavování, víc než poté, co jste viděli jednoduchou eleganci jeho skriptů sestavování?
Nechci, aby byl váš tým zmatený a chaotický. Naopak chci, aby váš tým komunikoval efektivněji. Věřím, že pokud se budete podílet na tvorbě produktu a práci na funkcích, budete svému týmu blíž. A co je důležitější, budete blíže neustálým změnám v procesu vývoje softwaru ve vaší organizaci.
Nepřestávejte se vyvíjet
Moje kolegyně z Borlandu mě jednou slovně napadla, že jsem ji nazval „kodérkou“.
„Randsi, kodér je bezduchý stroj! Opice! Kodér nedělá nic důležitého, kromě psaní nudných řádků zbytečného kódu. Nejsem kodér, jsem softwarový vývojář!“
Měla pravdu, nenáviděla by mou první radu novým generálním ředitelům: „Přestaňte psát kód!“ Ne proto, že naznačuji, že jsou kodéry, ale spíše proto, že proaktivně navrhuji, aby začali ignorovat jednu z nejdůležitějších částí své práce: vývoj softwaru.
Tak jsem aktualizoval svou radu. Pokud chcete být dobrým vůdcem, můžete přestat psát kód, ale...
Být flexibilní. Pamatujte si, co to znamená být inženýrem, a nepřestávejte vyvíjet software.
O autorovi
Michael Lopp je zkušený softwarový vývojář, který stále neopustil Silicon Valley. Během posledních 20 let Michael pracoval pro různé inovativní společnosti, včetně Apple, Netscape, Symantec, Borland, Palantir, Pinterest, a podílel se také na startupu, který pomalu upadl do zapomnění.
Mimo práci vede Michael pod pseudonymem Rands oblíbený blog o technologiích a managementu, kde se čtenáři diskutuje o nápadech v oblasti managementu, vyjadřuje obavy z neustálé potřeby držet palce a vysvětluje, že navzdory štědré odměny za vytvoření produktu, váš úspěch je možný pouze díky vašemu týmu. Blog najdete zde .
Michael žije se svou rodinou v Redwoodu v Kalifornii. Vždy si najde čas na horské kolo, hrát hokej a pít červené víno, protože být zdravý je důležitější než být zaneprázdněný.
» Více podrobností o knize naleznete na
»
»
Pro Khabrozhiteley 20% slevu pomocí kupónu - Řízení lidí
Při platbě za papírovou verzi knihy bude elektronická verze knihy zaslána e-mailem.
PS: 7% z ceny knihy půjde na překlad nových počítačových knih, seznam knih předaný do tiskárny .
Zdroj: www.habr.com