Kniha „Ako riadiť intelektuálov. Ja, šprti a geekovia"

Kniha „Ako riadiť intelektuálov. Ja, šprti a geekovia" Venované projektovým manažérom (a tým, ktorí snívajú o tom, že sa stanú šéfmi).

Písanie ton kódu je ťažké, ale riadenie ľudí je ešte ťažšie! Takže potrebujete len túto knihu, aby ste sa naučili, ako robiť oboje.

Je možné spojiť vtipné príbehy a vážne poučenie? Michael Lopp (v úzkych kruhoch známy aj ako Rands) uspel. Nájdete tu fiktívne príbehy o fiktívnych ľuďoch s neskutočne obohacujúcim (aj keď fiktívnym) zážitkom. Takto sa Rands delí o svoje pestré, miestami zvláštne skúsenosti získané za roky pôsobenia vo veľkých IT korporáciách: Apple, Pinterest, Palantir, Netscape, Symantec atď.

Ste projektový manažér? Alebo chcete pochopiť, čo váš prekliaty šéf celý deň robí? Rands vás naučí, ako prežiť v Toxickom svete nafúknutých moriek a prekvitať vo všeobecnom šialenstve dysfunkčne okázalých ľudí. V tejto podivnej komunite maniakálnych brainiakov sú ešte podivnejšie bytosti - manažéri, ktorí prostredníctvom mystického organizačného rituálu získali moc nad plánmi, myšlienkami a bankovými účtami mnohých ľudí.

Táto kniha sa nepodobá žiadnemu rukopisu manažmentu alebo vedenia. Michael Lopp nič neskrýva, len to hovorí tak, ako to je (možno nie všetky príbehy by sa mali zverejňovať: P). Ale len tak pochopíte, ako prežiť s takým šéfom, ako riadiť geekov a nerdov a ako doviesť „ten prekliaty projekt“ do šťastného konca!

Úryvok. Inžinierska mentalita

Úvahy o: Mali by ste pokračovať v písaní kódu?

Randsova kniha o pravidlách pre manažérov obsahuje veľmi krátky zoznam moderných manažérskych „povinných vecí“. Lakonickosť tohto zoznamu vyplýva zo skutočnosti, že pojem „musím“ je akýmsi absolútnym, a pokiaľ ide o ľudí, existuje len veľmi málo absolútnych pojmov. Úspešná metóda riadenia pre jedného zamestnanca bude pre iného skutočnou katastrofou. Táto myšlienka je prvou položkou na manažérovom „povinnom“ zozname:

Zostaňte flexibilní!

Myslieť si, že už všetko viete, je veľmi zlý nápad. V situácii, keď jediným stálym faktom je, že svet sa neustále mení, jediným správnym postojom sa stáva flexibilita.

Paradoxne, druhá položka na zozname je prekvapivo nepružná. Tento bod je však môj osobný favorit, pretože verím, že pomáha vytvárať základy pre manažérsky rast. Tento odsek znie:

Prestaňte písať kód!

Teoreticky, ak chcete byť manažérom, musíte sa naučiť dôverovať tým, ktorí pre vás pracujú, a odovzdať kódovanie úplne im. Táto rada je zvyčajne ťažko stráviteľná, najmä pre nových manažérov. Pravdepodobne jedným z dôvodov, prečo sa stali manažérmi, je ich produktivita vo vývoji, a keď sa niečo pokazí, ich prvou reakciou je vrátiť sa späť k zručnostiam, ktorým plne dôverujú, čo je ich schopnosť písať kód.

Keď vidím, že novovytvorený manažér sa „zaborí“ do písania kódu, poviem mu: „Vieme, že viete písať kód. Otázka znie: dokážete viesť? Už nie si zodpovedný sám za seba, zodpovedáš za celý tím; a chcem sa uistiť, že svoj tím dokážete prinútiť vyriešiť problémy sám, bez toho, aby ste museli písať kód sami. Vašou úlohou je zistiť, ako sa škálovať. Nechcem, aby si bol len jeden, chcem, aby takých ako ty bolo veľa."

Dobrá rada, však? Mierka. Zvládanie. Zodpovednosť. Také bežné hlášky. Škoda, že rada je nesprávna.

nesprávne?

Áno. Rada je nesprávna! Nie úplne nesprávne, ale natoľko nesprávne, že som musel zavolať niekoľkým bývalým kolegom a ospravedlniť sa: „Pamätáš si na moje obľúbené vyhlásenie o tom, ako by si mal prestať písať kód? je to zle! Áno... Začnite znova programovať. Začnite s Pythonom a Ruby. Áno, myslím to vážne! Závisí od toho vaša kariéra!“

Keď som začal svoju kariéru ako softvérový vývojár v Borlande, pracoval som v tíme Paradox Windows, čo bol obrovský tím. Len vývojárov aplikácií bolo 13. Ak k tomu pridáte ľudí z iných tímov, ktorí tiež neustále pracovali na kľúčových technológiách pre tento projekt, ako je základný databázový stroj a základné aplikačné služby, získate 50 inžinierov priamo zapojených do vývoja tohto produktu.

Žiadny iný tím, pre ktorý som kedy pracoval, sa ani len nepribližuje k tejto veľkosti. V skutočnosti s každým rokom postupne klesá počet ľudí v tíme, v ktorom pracujem. Čo sa deje? Sme vývojári spoločne čoraz múdrejší? Nie, len sa delíme o záťaž.

Čo robili vývojári za posledných 20 rokov? Počas tejto doby sme napísali hromadu kódu. More kódu! Napísali sme toľko kódu, že sme sa rozhodli, že by bolo dobré všetko zjednodušiť a prejsť na open source.

Našťastie, vďaka internetu je tento proces teraz čo najjednoduchší. Ak ste vývojár softvéru, môžete si to pozrieť práve teraz! Vyhľadajte svoje meno na Google alebo Github a uvidíte kód, na ktorý ste už dávno zabudli, ale môže ho nájsť ktokoľvek. Strašidelné, však? Nevedeli ste, že kód žije večne? Áno, žije večne.

Kód žije večne. A dobrý kód nielenže žije večne, ale rastie, pretože tí, ktorí si ho vážia, neustále zabezpečujú, aby zostal čerstvý. Táto hromada vysokokvalitného a dobre udržiavaného kódu pomáha znižovať priemernú veľkosť inžinierskeho tímu, pretože nám umožňuje sústrediť sa na existujúci kód, a nie na písanie nového kódu, a robiť prácu s menším počtom ľudí a v kratšom časovom rámci.

Táto línia uvažovania znie depresívne, ale myšlienka je taká, že všetci sme len zhluk integračných automatov, ktoré používajú lepiacu pásku na spojenie rôznych kúskov existujúcich vecí dohromady, aby sme vytvorili trochu odlišnú verziu tej istej veci. Toto je klasický spôsob myslenia medzi vedúcimi pracovníkmi, ktorí milujú outsourcing. „Každý, kto vie, ako používať Google a má nejakú lepiacu pásku, to dokáže! Prečo potom platíme veľa peňazí za naše stroje?

Týchto manažérov platíme naozaj veľké peniaze, ale oni si myslia také nezmysly. Ešte raz, môj kľúčový bod je, že na našej planéte je veľa skvelých a veľmi pracovitých vývojárov; sú skutočne brilantní a usilovní, hoci nestrávili ani minútu sedením na akreditovaných univerzitách. Ach áno, teraz ich je stále viac!

Nenavrhujem, aby ste sa začali obávať o svoje miesto len preto, že ho údajne hľadajú nejakí brilantní súdruhovia. Navrhujem, aby ste sa tým začali obávať, pretože vývoj vývoja softvéru pravdepodobne napreduje rýchlejšie ako vy. Pracujete desať rokov, z toho päť ako manažér, a myslíte si: „Už viem, ako sa vyvíja softvér.“ Áno, ty vieš. Zbohom…

Prestaňte písať kód, ale...

Ak sa budete riadiť mojou pôvodnou radou a prestanete písať kód, prestanete sa tiež dobrovoľne podieľať na procese tvorby. Z tohto dôvodu aktívne nevyužívam outsourcing. Automaty nevytvárajú, oni vyrábajú. Dobre navrhnuté procesy šetria veľa peňazí, ale neprinášajú do nášho sveta nič nové.

Ak máte malý tím, ktorý robí veľa za málo peňazí, potom sa mi myšlienka zastaviť písanie kódu zdá ako zlé kariérne rozhodnutie. Ani v monster spoločnostiach s ich nekonečnými nariadeniami, procesmi a politikami nemáte právo zabúdať, ako si sami vyvíjate softvér. A vývoj softvéru sa neustále mení. Práve teraz sa to mení. Pod nohami! V tejto sekunde!

Máte námietky. Rozumieť. Poďme počúvať.

„Rands, som na ceste k riaditeľskej stoličke! Ak budem pokračovať v písaní kódu, nikto mi neuverí, že môžem rásť.“

Chcem sa vás spýtať toto: odkedy ste sedeli na stoličke „Chystám sa byť generálnym riaditeľom!“, všimli ste si, že prostredie vývoja softvéru sa mení, dokonca aj vo vašej spoločnosti? Ak je vaša odpoveď áno, potom vám položím ďalšiu otázku: ako presne sa to mení a čo s týmito zmenami urobíte? Ak ste na moju prvú otázku odpovedali „nie“, potom musíte prejsť na inú stoličku, pretože (stavím sa!) oblasť vývoja softvéru sa práve v tejto chvíli mení. Ako budete rásť, ak pomaly, ale isto zabudnete na vývoj softvéru?

Moja rada je nezaviazať sa k implementácii množstva funkcií pre váš ďalší produkt. Musíte neustále podnikať kroky, aby ste mali prehľad o tom, ako váš tím vytvára softvér. Môžete to urobiť ako riaditeľ aj ako viceprezident. Niečo iné?

„Fuj, Rands! Ale niekto musí byť rozhodca! Niekto musí vidieť celkový obraz. Ak napíšem kód, stratím perspektívu.“

Stále musíte byť rozhodcom, stále musíte vysielať rozhodnutia a stále musíte chodiť po budove štyrikrát každý pondelok ráno s jedným z vašich inžinierov, aby ste si vypočuli jeho týždenný chválospev „Všetci sme odsúdení na 30“. minúty.! Okrem toho všetkého si však musíte zachovať inžinierske myslenie a na to nemusíte byť programátorom na plný úväzok.

Moje tipy na udržanie inžinierskej mentality:

  1. Použite vývojové prostredie. To znamená, že by ste mali byť oboznámení s nástrojmi vášho tímu vrátane systému tvorby kódu, riadenia verzií a programovacieho jazyka. V dôsledku toho sa naučíte jazyk, ktorý váš tím používa, keď hovorí o vývoji produktov. To vám tiež umožní pokračovať v používaní vášho obľúbeného textového editora, ktorý funguje perfektne.
  2. Musíte byť schopní kedykoľvek nakresliť podrobný architektonický diagram popisujúci váš produkt na akomkoľvek povrchu. Teraz nemám na mysli zjednodušenú verziu s tromi bunkami a dvoma šípkami. Musíte poznať podrobnú schému produktu. Ten najťažší. Nie hocijaký roztomilý diagram, ale diagram, ktorý sa ťažko vysvetľuje. Mala by to byť mapa vhodná na úplné pochopenie produktu. Neustále sa mení a vždy by ste mali vedieť, prečo k určitým zmenám došlo.
  3. Prevezmite implementáciu jednej z funkcií. Pri písaní tohto článku sa doslova trhám, pretože tento bod má veľa skrytých nebezpečenstiev, ale naozaj si nie som istý, či môžete dosiahnuť bod #1 a bod #2 bez toho, aby ste sa zaviazali implementovať aspoň jednu funkciu. Ak sami implementujete jednu z funkcií, nielenže sa aktívne zapojíte do procesu vývoja, ale tiež vám to umožní pravidelne sa prepínať z role „manažéra zodpovedného za všetko“ na úlohu „človeka zodpovedného za implementáciu jednej funkcie“. z funkcií“. Tento skromný a nenáročný postoj vám pripomenie dôležitosť malých rozhodnutí.
  4. Ešte stále sa celá trasiem. Zdá sa, že už na mňa niekto kričí: „Konateľ, ktorý si zobral na seba realizáciu funkcie?! (A súhlasím s ním!) Áno, stále ste manažér, čo znamená, že by to mala byť nejaká malá funkcia, dobre? Áno, stále máte veľa práce. Ak jednoducho nemôžete prevziať implementáciu funkcie, potom mám pre vás niekoľko náhradných rád: opravte niektoré chyby. V tomto prípade nepocítite radosť z tvorby, ale pochopíte, ako produkt vzniká, čo znamená, že nikdy nezostanete bez práce.
  5. Napíšte testy jednotiek. Stále to robím neskoro vo výrobnom cykle, keď ľudia začnú šalieť. Berte to ako kontrolný zoznam zdravia vášho produktu. Robte to často.

Opäť námietka?

„Rands, ak napíšem kód, zmiatim svoj tím. Nebudú vedieť, kto som – manažér alebo vývojár.“

Dobrá.

Áno, povedal som: "Dobre!" Som rád, že si myslíš, že môžeš zmiasť svoj tím len tým, že budeš plávať v developerskom rybníku. Je to jednoduché: hranice medzi rôznymi rolami vo vývoji softvéru sú v súčasnosti veľmi nejasné. Chlapci s používateľským rozhraním robia to, čo sa dá vo všeobecnosti nazvať programovaním JavaScript a CSS. Vývojári sa stále viac dozvedajú o dizajne používateľského prostredia. Ľudia medzi sebou komunikujú a dozvedajú sa o chybách, o krádeži cudzieho kódu a tiež o tom, že neexistuje dobrý dôvod, aby sa manažér nezúčastnil tejto masívnej globálnej, krížovo opeľujúcej informačnej bakchanálie.

Okrem toho, chcete byť súčasťou tímu zloženého z ľahko vymeniteľných komponentov? Váš tím tak bude nielen svižnejší, ale každému členovi tímu to poskytne príležitosť vidieť produkt a spoločnosť z rôznych perspektív. Ako môžete rešpektovať Franka, pokojného chlapíka, ktorý má na starosti zostavovanie, o nič viac, ako keď ste videli jednoduchú eleganciu jeho skriptov na zostavovanie?

Nechcem, aby bol váš tím zmätený a chaotický. Naopak, chcem, aby váš tím komunikoval efektívnejšie. Verím, že ak sa budete podieľať na tvorbe produktu a práci na funkciách, budete bližšie k svojmu tímu. A čo je dôležitejšie, budete bližšie k neustálym zmenám v procese vývoja softvéru vo vašej organizácii.

Neprestávajte sa rozvíjať

Moja kolegyňa v Borlande ma raz verbálne napadla, že som ju nazval „kódovačkou“.

„Rands, kodér je bezduchý stroj! Opica! Kóder nerobí nič dôležité okrem písania nudných riadkov zbytočného kódu. Nie som programátor, som vývojár softvéru!“

Mala pravdu, moju prvotnú radu novým generálnym riaditeľom by nenávidela: „Prestaňte písať kód!“ Nie preto, že by som im naznačoval, že sú programátori, ale skôr preto, že im proaktívne navrhujem, aby začali ignorovať jednu z najdôležitejších súčastí svojej práce: vývoj softvéru.

Tak som aktualizoval svoje rady. Ak chcete byť dobrým vodcom, môžete prestať písať kód, ale...

Buďte flexibilní. Pamätajte si, čo to znamená byť inžinierom, a neprestávajte vyvíjať softvér.

O autorovi

Michael Lopp je skúsený vývojár softvéru, ktorý stále neopustil Silicon Valley. Za posledných 20 rokov Michael pracoval pre rôzne inovatívne spoločnosti vrátane Apple, Netscape, Symantec, Borland, Palantir, Pinterest a podieľal sa aj na startupe, ktorý pomaly upadal do zabudnutia.

Michael mimo práce vedie pod pseudonymom Rands populárny blog o technológiách a manažmente, kde s čitateľmi diskutuje o nápadoch v oblasti manažmentu, vyjadruje obavy z neustálej potreby držať palec na pulze a vysvetľuje, že napriek štedré odmeny za vytvorenie produktu, váš úspech je možný len vďaka vášmu tímu. Blog nájdete tu www.randsinrepose.com.

Michael žije so svojou rodinou v Redwoode v Kalifornii. Vždy si nájde čas na horský bicykel, hokej a červené víno, pretože byť zdravý je dôležitejšie ako byť zaneprázdnený.

» Viac podrobností o knihe nájdete na webová stránka vydavateľa
» obsah
» Úryvok

Pre Khabrozhitely zľavu 20 % pomocou kupónu - Riadenie ľudí

Po zaplatení papierovej verzie knihy bude elektronická verzia knihy zaslaná e-mailom.

PS: 7% z ceny knihy pôjde na preklad nových počítačových kníh, zoznam kníh odovzdaných do tlačiarne tu.

Zdroj: hab.com

Pridať komentár