Dedikerad till projektledare (och de som drömmer om att bli chefer).
Att skriva massor av kod är svårt, men att hantera människor är ännu svårare! Så du behöver bara den här boken för att lära dig hur man gör båda.
Går det att kombinera roliga historier och seriösa lärdomar? Michael Lopp (även känd i snäva kretsar som Rands) lyckades. Du hittar fiktiva berättelser om fiktiva människor med otroligt givande (om än fiktiva) upplevelser. Så här delar Rands med sig av sina varierande, ibland märkliga erfarenheter som han fått under åren av att arbeta i stora IT-företag: Apple, Pinterest, Palantir, Netscape, Symantec, etc.
Är du projektledare? Eller vill du förstå vad din jäkla chef gör hela dagen? Rands kommer att lära dig hur du överlever i den giftiga världen av uppblåsta kalkoner och trivs i den allmänna galenskapen hos dysfunktionellt flamboyanta människor. I denna märkliga gemenskap av galna brainiacs finns ännu märkligare varelser - chefer som genom en mystisk organisatorisk ritual har fått makt över många människors planer, tankar och bankkonton.
Den här boken liknar inte något management- eller ledarskapsmanuskript. Michael Lopp döljer ingenting, han bara berättar som det är (alla historier borde kanske inte offentliggöras:P). Men bara på detta sätt kommer du att förstå hur man överlever med en sådan chef, hur man hanterar nördar och nördar och hur man får "det där jäkla projektet" till ett lyckligt slut!
Utdrag. Ingenjörsmentalitet
Tankar om: Ska du fortsätta skriva kod?
Rands bok om regler för chefer innehåller en mycket kort lista över moderna ledarskaps "måsten". Lakonismen i denna lista härrör från det faktum att begreppet "måste" är ett slags absolut, och när det kommer till människor finns det väldigt få absoluta begrepp. En framgångsrik ledningsmetod för en anställd kommer att vara en riktig katastrof för en annan. Denna tanke är den första punkten på chefens "måste-göra"-lista:
Var flexibel!
Att tro att du redan vet allt är en väldigt dålig idé. I en situation där det enda konstanta faktumet är att världen ständigt förändras, blir flexibilitet den enda korrekta positionen.
Paradoxalt nog är den andra punkten på listan förvånansvärt oflexibel. Den här punkten är dock min personliga favorit eftersom jag tror att den bidrar till att skapa grunden för chefsutveckling. Detta stycke lyder:
Sluta skriva kod!
I teorin, om du vill bli chef måste du lära dig att lita på de som arbetar för dig och lämna över kodningen helt och hållet till dem. Dessa råd är vanligtvis svårsmälta, särskilt för nyblivna chefer. Förmodligen är en av anledningarna till att de blev chefer på grund av deras produktivitet i utvecklingen, och när det går fel är deras första reaktion att falla tillbaka på de färdigheter de har fullt förtroende för, vilket är deras förmåga att skriva kod.
När jag ser att en nybliven chef ”sjunker” in i att skriva kod säger jag till honom: ”Vi vet att du kan skriva kod. Frågan är: kan du leda? Du är inte längre ensam ansvarig för dig själv, du ansvarar för hela laget; och jag vill se till att du kan få ditt team att lösa problem på egen hand, utan att du behöver skriva koden själv. Ditt jobb är att ta reda på hur du kan skala dig själv. Jag vill inte att du bara ska vara en, jag vill att det ska finnas många som du.”
Bra råd, eller hur? Skala. Förvaltning. Ansvar. Sådana vanliga modeord. Det är synd att rådet är fel.
Felaktig?
Ja. Råden är fel! Inte helt fel, men fel nog att jag var tvungen att ringa några före detta kollegor och be om ursäkt: ”Kommer du ihåg det där favorituttalandet av mig om hur du ska sluta skriva kod? Det är fel! Ja... Börja programmera igen. Börja med Python och Ruby. Ja jag är seriös! Din karriär beror på det!"
När jag började min karriär som mjukvaruutvecklare på Borland arbetade jag på Paradox Windows-teamet som var ett enormt team. Det fanns bara 13 applikationsutvecklare. Om du lägger till personer från andra team som också ständigt arbetade med nyckelteknologier för detta projekt, såsom kärndatabasmotorn och kärnapplikationstjänster, fick du 50 ingenjörer direkt involverade i utvecklingen av denna produkt.
Inget annat team jag någonsin har jobbat för kommer ens i närheten av den här storleken. Faktum är att för varje år som går minskar antalet personer i teamet jag arbetar med gradvis. Vad pågår? Blir vi utvecklare tillsammans smartare och smartare? Nej, vi delar bara på lasten.
Vad har utvecklare gjort de senaste 20 åren? Under den här tiden skrev vi en massa kod. Hav av kod! Vi skrev så mycket kod att vi bestämde oss för att det skulle vara en bra idé att förenkla allt och gå med öppen källkod.
Lyckligtvis, tack vare Internet, har denna process nu blivit så enkel som möjligt. Om du är en mjukvaruutvecklare kan du kolla in det redan nu! Sök ditt namn på Google eller Github så ser du kod som du länge har glömt, men som vem som helst kan hitta. Skrämmande, eller hur? Visste du inte att koden lever för evigt? Ja, han lever för evigt.
Koden lever för evigt. Och bra kod lever inte bara för evigt, den växer eftersom de som värdesätter den hela tiden ser till att den förblir fräsch. Denna hög med högkvalitativ, väl underhållen kod hjälper till att minska den genomsnittliga storleken på ingenjörsteamet eftersom den tillåter oss att fokusera på befintlig kod istället för att skriva ny kod, och få jobbet gjort med färre personer och på kortare tidsram.
Detta resonemang låter deprimerande, men tanken är att vi alla bara är ett gäng integrationsautomater som använder tejp för att koppla ihop olika bitar av befintliga saker för att skapa en lite annorlunda version av samma sak. Detta är en klassisk tankegång bland ledande befattningshavare som älskar outsourcing. "Alla som vet hur man använder Google och har tejp kan göra det här! Varför betalar vi då mycket pengar till våra maskiner?”
Vi betalar de här managementkillarna riktigt stora pengar, men de tycker sånt dumheter. Återigen, min nyckelpoäng är att det finns många briljanta och mycket hårt arbetande utvecklare på vår planet; de är verkligen briljanta och flitiga, även om de inte har tillbringat en enda minut på ackrediterade universitet. Åh ja, nu blir det fler och fler av dem!
Jag föreslår inte att du börjar oroa dig för din plats bara för att några briljanta kamrater påstås jaga efter den. Jag föreslår att du börjar oroa dig för det eftersom utvecklingen av mjukvaruutveckling förmodligen går snabbare än du gör. Du har arbetat i tio år, fem av dem som chef, och du tänker: "Jag vet redan hur mjukvara utvecklas." Ja du vet. Hejdå…
Sluta skriva kod, men...
Om du följer mina ursprungliga råd och slutar skriva kod kommer du också frivilligt att sluta delta i skapelseprocessen. Det är av denna anledning som jag inte aktivt använder outsourcing. Automater skapar inte, de producerar. Väl utformade processer sparar mycket pengar, men de tillför inget nytt till vår värld.
Om du har ett litet team som gör mycket för lite pengar, så verkar idén att sluta skriva kod som ett dåligt karriärbeslut för mig. Även i monsterföretag med sina oändliga regler, processer och policyer har du ingen rätt att glömma hur du själv utvecklar mjukvara. Och mjukvaruutvecklingen förändras ständigt. Det håller på att förändras just nu. Under dina fötter! Just i denna sekund!
Du har invändningar. Förstå. Låt oss höra.
”Rands, jag är på väg till regissörsstolen! Om jag fortsätter skriva kod kommer ingen att tro att jag kan växa.”
Jag vill fråga dig detta: sedan du satt i din "Jag ska bli VD!"-stol, har du märkt att mjukvaruutvecklingslandskapet förändras, även inom ditt företag? Om ditt svar är ja, kommer jag att ställa en annan fråga till dig: exakt hur förändras det och vad ska du göra åt dessa förändringar? Om du svarade "nej" på min första fråga, måste du flytta till en annan stol, eftersom (jag slår vad om!) området för mjukvaruutveckling förändras just nu. Hur kommer du någonsin att växa om du sakta men säkert glömmer hur man utvecklar mjukvara?
Mitt råd är att inte förbinda dig att implementera massor av funktioner för din nästa produkt. Du måste hela tiden vidta åtgärder för att hålla koll på hur ditt team bygger mjukvara. Du kan göra detta både som direktör och som vice vd. Något annat?
"Usch, Rands! Men någon måste vara domaren! Någon måste se helheten. Om jag skriver kod tappar jag perspektivet."
Du måste fortfarande vara domare, du måste fortfarande sända besluten, och du måste fortfarande gå runt byggnaden fyra gånger varje måndag morgon med en av dina ingenjörer för att lyssna på hans veckovisa "We're all doomed" rant i 30 minuter.! Men utöver allt detta måste du ha ett ingenjörstänk, och du behöver inte vara programmerare på heltid för att göra det.
Mina tips för att behålla en ingenjörsmentalitet:
- Använd utvecklingsmiljön. Det betyder att du bör vara bekant med ditt teams verktyg, inklusive kodbyggesystemet, versionskontroll och programmeringsspråk. Som ett resultat kommer du att bli skicklig i det språk ditt team använder när de pratar om produktutveckling. Detta gör att du också kan fortsätta använda din favorittextredigerare, som fungerar perfekt.
- Du måste kunna rita ett detaljerat arkitektoniskt diagram som beskriver din produkt på vilken yta som helst när som helst. Nu menar jag inte den förenklade versionen med tre celler och två pilar. Du måste känna till det detaljerade diagrammet över produkten. Den svåraste. Inte vilket gulligt diagram som helst, utan ett diagram som är svårt att förklara. Det bör vara en karta som lämpar sig för en fullständig förståelse av produkten. Det förändras ständigt, och du bör alltid veta varför vissa förändringar inträffade.
- Ta över implementeringen av en av funktionerna. Jag ryser bokstavligen när jag skriver detta eftersom den här punkten har många dolda faror, men jag är verkligen inte säker på att du kan uppnå punkt #1 och punkt #2 utan att åta dig att implementera minst en funktion. Genom att implementera en av funktionerna själv, kommer du inte bara att vara aktivt involverad i utvecklingsprocessen, det kommer också att tillåta dig att periodvis byta från rollen som "Manager med ansvar för allt" till rollen som "Man med ansvar för att implementera en av funktionerna." Denna ödmjuka och anspråkslösa attityd kommer att påminna dig om vikten av små beslut.
- Jag skakar fortfarande i hela kroppen. Det verkar som att någon redan skriker åt mig: "Handaren som tog på sig genomförandet av funktionen?!" (Och jag håller med honom!) Ja, du är fortfarande chef, vilket betyder att det borde vara någon liten funktion, okej? Ja, du har fortfarande mycket att göra. Om du bara inte kan ta på dig implementeringen av funktionen, så har jag några extra råd till dig: fixa några buggar. I det här fallet kommer du inte att känna glädjen i att skapa, men du kommer att ha en förståelse för hur produkten skapas, vilket gör att du aldrig kommer att stå utan arbete.
- Skriv enhetstester. Jag gör fortfarande detta sent i produktionscykeln när folk börjar bli galna. Se det som en hälsochecklista för din produkt. Gör detta ofta.
Invändning igen?
"Rands, om jag skriver kod kommer jag att förvirra mitt lag. De kommer inte att veta vem jag är – en chef eller en utvecklare.”
Okej.
Ja, jag sa, "Okej!" Jag är glad att du tror att du kan förvirra ditt lag bara genom att simma i utvecklardammen. Det är enkelt: gränserna mellan olika roller inom mjukvaruutveckling är för närvarande mycket suddiga. UI-killarna gör vad som i stora drag kan kallas JavaScript och CSS-programmering. Utvecklare lär sig mer och mer om design av användarupplevelser. Människor kommunicerar med varandra och lär sig om buggar, om stöld av andras kod, och även om det faktum att det inte finns någon bra anledning för en chef att inte delta i denna massiva, globala, korspollinerande informationsbakgrund.
Vill du dessutom vara en del av ett team bestående av lätt utbytbara komponenter? Detta kommer inte bara att göra ditt team piggare, det kommer att ge varje teammedlem möjlighet att se produkten och företaget från en mängd olika perspektiv. Hur kan du komma att respektera Frank, den lugna killen som ansvarar för byggen, mer än efter att ha sett den enkla elegansen i hans byggmanus?
Jag vill inte att ditt lag ska bli förvirrat och kaotiskt. Tvärtom vill jag att ditt team ska kommunicera mer effektivt. Jag tror att om du är med och skapar produkten och arbetar med funktioner kommer du att vara närmare ditt team. Och ännu viktigare, du kommer att vara närmare ständiga förändringar i mjukvaruutvecklingsprocessen inom din organisation.
Sluta inte utvecklas
En kollega till mig på Borland attackerade mig en gång verbalt för att jag kallade henne en "kodare".
"Rands, kodaren är en tanklös maskin! Apa! Kodaren gör inget viktigt förutom att skriva tråkiga rader med värdelös kod. Jag är inte en kodare, jag är en mjukvaruutvecklare!"
Hon hade rätt, hon skulle ha hatat mitt första råd till nya VD:ar: "Sluta skriva kod!" Inte för att jag föreslår att de är kodare, utan mer för att jag proaktivt föreslår att de börjar ignorera en av de viktigaste delarna av sitt jobb: mjukvaruutveckling.
Så jag har uppdaterat mitt råd. Om du vill bli en bra ledare kan du sluta skriva kod, men...
Vara rörlig. Kom ihåg vad det innebär att vara ingenjör och sluta inte utveckla mjukvara.
Om författaren
Michael Lopp är en erfaren mjukvaruutvecklare som fortfarande inte har lämnat Silicon Valley. Under de senaste 20 åren har Michael arbetat för en mängd olika innovativa företag, inklusive Apple, Netscape, Symantec, Borland, Palantir, Pinterest, och även deltagit i en startup som långsamt svävade i glömska.
Utanför jobbet driver Michael en populär blogg om teknik och management under pseudonymen Rands, där han diskuterar idéer inom managementområdet med läsare, uttrycker oro över det ständiga behovet av att hålla fingret på pulsen och förklarar att trots generösa belöningar för att skapa en produkt, din framgång är bara möjlig tack vare ditt team. Bloggen hittar du här .
Michael bor med sin familj i Redwood, Kalifornien. Han hinner alltid med att cykla mountainbike, spela hockey och dricka rödvin, eftersom det är viktigare att vara frisk än att vara upptagen.
» Mer information om boken finns på
»
»
För Khabrozhiteley 20% rabatt med kupong - Hantera folk
Vid betalning för pappersversionen av boken skickas en elektronisk version av boken via e-post.
PS: 7% av priset för boken går till översättning av nya datorböcker, en lista över böcker som överlämnas till tryckeriet .
Källa: will.com