Dedikeret til projektledere (og dem, der drømmer om at blive chefer).
Det er svært at skrive tonsvis af kode, men det er endnu sværere at administrere mennesker! Så du har bare brug for denne bog for at lære at gøre begge dele.
Er det muligt at kombinere sjove historier og seriøse lektioner? Michael Lopp (også kendt i snævre kredse som Rands) lykkedes. Du finder fiktive historier om fiktive mennesker med utroligt givende (omend fiktive) oplevelser. Sådan deler Rands ud af sine varierede, til tider mærkelige erfaringer, han har fået gennem årene med at arbejde i store it-selskaber: Apple, Pinterest, Palantir, Netscape, Symantec osv.
Er du projektleder? Eller vil du gerne forstå, hvad din pokkers chef gør hele dagen? Rands vil lære dig, hvordan du overlever i den giftige verden af oppustede kalkuner og trives i den generelle vanvid hos dysfunktionelt flamboyante mennesker. I dette mærkelige fællesskab af maniske hjernekloge er der endnu mærkeligere skabninger - ledere, der gennem et mystisk organisatorisk ritual har fået magt over mange menneskers planer, tanker og bankkonti.
Denne bog er ulig noget ledelses- eller ledelsesmanuskript. Michael Lopp lægger ikke skjul på noget, han fortæller det bare, som det er (måske ikke alle historier skal offentliggøres:P). Men kun på denne måde vil du forstå, hvordan man overlever med sådan en chef, hvordan man styrer nørder og nørder, og hvordan man bringer "det forbandede projekt" til en lykkelig slutning!
Uddrag. Ingeniør mentalitet
Tanker om: Skal du fortsætte med at skrive kode?
Rands' bog om regler for ledere indeholder en meget kort liste over moderne ledelsesmæssige "must-dos". Lakonismen i denne liste stammer fra det faktum, at begrebet "skal" er en slags absolut, og når det kommer til mennesker, er der meget få absolutte begreber. En succesfuld ledelsesmetode for en medarbejder vil være en virkelig katastrofe for en anden. Denne tanke er det første punkt på lederens "must-do"-liste:
Forbliv fleksibel!
At tro, at du allerede ved alt, er en meget dårlig idé. I en situation, hvor det eneste konstante faktum er, at verden konstant ændrer sig, bliver fleksibilitet den eneste rigtige position.
Paradoksalt nok er det andet punkt på listen overraskende ufleksibel. Dette punkt er dog min personlige favorit, fordi jeg tror på, at det er med til at skabe grundlaget for ledelsesmæssig vækst. Dette afsnit lyder:
Stop med at skrive kode!
I teorien, hvis du vil være leder, skal du lære at stole på dem, der arbejder for dig, og overlade kodningen helt til dem. Dette råd er normalt vanskeligt at fordøje, især for nyslåede ledere. En af grundene til, at de blev ledere, er nok på grund af deres produktivitet i udviklingen, og når det går galt, er deres første reaktion at falde tilbage på de færdigheder, de har fuld tillid til, som er deres evne til at skrive kode.
Da jeg ser, at en nyslået leder "synker" ned i at skrive kode, siger jeg til ham: "Vi ved, at du kan skrive kode. Spørgsmålet er: kan du lede? Du er ikke længere ansvarlig for dig selv alene, du er ansvarlig for hele teamet; og jeg vil gerne sikre mig, at du kan få dit team til at løse problemer på egen hånd, uden at du selv skal skrive koden. Din opgave er at finde ud af, hvordan du skalerer dig selv. Jeg vil ikke have, at du kun er én, jeg vil have, at der er mange som dig."
Gode råd, ikke? Vægt. Ledelse. Ansvar. Sådanne almindelige buzzwords. Det er ærgerligt, at rådet er forkert.
Ukorrekt?
Ja. Rådene er forkerte! Ikke helt forkert, men forkert nok til, at jeg måtte ringe til nogle tidligere kollegaer og undskylde: “Husker du min yndlingserklæring om, hvordan du skal stoppe med at skrive kode? Det er forkert! Ja... Begynd at programmere igen. Start med Python og Ruby. Ja, jeg mener det alvorligt! Din karriere afhænger af det!"
Da jeg startede min karriere som softwareudvikler hos Borland, arbejdede jeg på Paradox Windows-teamet, som var et kæmpe team. Der var alene 13 applikationsudviklere. Hvis du tilføjer folk fra andre teams, som også konstant arbejdede på nøgleteknologier til dette projekt, såsom kernedatabasemotoren og kerneapplikationstjenester, fik du 50 ingeniører direkte involveret i udviklingen af dette produkt.
Intet andet hold, jeg nogensinde har arbejdet for, kommer i nærheden af denne størrelse. Faktisk falder antallet af personer på det team, jeg arbejder på, gradvist for hvert år, der går. Hvad sker der? Bliver vi udviklere tilsammen klogere og klogere? Nej, vi deler bare byrden.
Hvad har udviklere lavet i de sidste 20 år? I løbet af denne tid skrev vi en masse kode. Hav af kode! Vi skrev så meget kode, at vi besluttede, at det ville være en god idé at forenkle alt og gå til open source.
Heldigvis, takket være internettet, er denne proces nu blevet så enkel som muligt. Hvis du er softwareudvikler, kan du tjekke det ud lige nu! Søg dit navn på Google eller Github, og du vil se kode, som du længe har glemt, men som alle kan finde. Skræmmende, ikke? Vidste du ikke, at koden lever for evigt? Ja, han lever for evigt.
Koden lever for evigt. Og god kode lever ikke kun for evigt, den vokser, fordi de, der værdsætter den konstant, sikrer, at den forbliver frisk. Denne bunke af højkvalitets, velholdt kode hjælper med at reducere den gennemsnitlige ingeniørteamstørrelse, fordi den giver os mulighed for at fokusere på eksisterende kode i stedet for at skrive ny kode og få arbejdet gjort med færre mennesker og inden for en kortere tidsramme.
Denne tankegang lyder deprimerende, men tanken er, at vi alle bare er en flok integrationsautomater, der bruger gaffatape til at forbinde forskellige dele af eksisterende ting sammen for at skabe en lidt anderledes version af den samme ting. Dette er en klassisk tankegang blandt ledende medarbejdere, der elsker outsourcing. "Enhver, der ved, hvordan man bruger Google og har noget gaffatape, kan gøre dette! Hvorfor betaler vi så mange penge til vores maskiner?”
Vi betaler disse ledelsesfolk rigtig mange penge, men de synes sådan noget vrøvl. Endnu en gang er min nøglepointe, at der er mange geniale og meget hårdtarbejdende udviklere på vores planet; de er virkelig geniale og flittige, selvom de ikke har brugt et eneste minut på at sidde på akkrediterede universiteter. Åh ja, nu bliver der flere og flere af dem!
Jeg foreslår ikke, at du begynder at bekymre dig om dit sted, bare fordi nogle geniale kammerater angiveligt er på jagt efter det. Jeg foreslår, at du begynder at bekymre dig om det, fordi udviklingen af softwareudvikling sandsynligvis går hurtigere, end du gør. Du har arbejdet i ti år, fem af dem som leder, og du tænker: "Jeg ved allerede, hvordan software udvikles." Ja, du ved. Farvel…
Stop med at skrive kode, men...
Hvis du følger mit oprindelige råd og holder op med at skrive kode, stopper du også frivilligt med at deltage i oprettelsesprocessen. Det er derfor, at jeg ikke aktivt bruger outsourcing. Automater skaber ikke, de producerer. Veldesignede processer sparer mange penge, men de bringer ikke noget nyt til vores verden.
Hvis du har et lille team, der laver meget for få penge, så virker tanken om at stoppe med at skrive kode som en dårlig karrierebeslutning for mig. Selv i monstervirksomheder med deres endeløse regler, processer og politikker har du ingen ret til at glemme, hvordan du selv udvikler software. Og softwareudviklingen ændrer sig konstant. Det ændrer sig lige nu. Under dine fødder! I dette øjeblik!
Du har indvendinger. Forstå. Lad os lytte.
“Rands, jeg er på vej til direktørstolen! Hvis jeg bliver ved med at skrive kode, vil ingen tro på, at jeg kan vokse.”
Jeg vil gerne spørge dig dette: siden du sad i din "Jeg er ved at blive administrerende direktør!"-stol, har du bemærket, at softwareudviklingslandskabet ændrer sig, selv inden for din virksomhed? Hvis dit svar er ja, så vil jeg stille dig et andet spørgsmål: hvordan ændrer det sig præcist, og hvad vil du gøre ved disse ændringer? Hvis du svarede "nej" til mit første spørgsmål, så er du nødt til at flytte til en anden stol, fordi (jeg vædde på!) feltet for softwareudvikling ændrer sig i dette øjeblik. Hvordan vil du nogensinde vokse, hvis du langsomt, men sikkert glemmer, hvordan man udvikler software?
Mit råd er ikke at forpligte dig til at implementere tonsvis af funktioner til dit næste produkt. Du skal hele tiden tage skridt til at holde dig på forkant med, hvordan dit team bygger software. Det kan du både som direktør og som vicepræsident. Noget andet?
"Åh, Rands! Men nogen skal være dommeren! Nogen skal se det store billede. Hvis jeg skriver kode, mister jeg perspektivet."
Du skal stadig være dommeren, du skal stadig udsende beslutningerne, og du skal stadig gå rundt i bygningen fire gange hver mandag morgen med en af dine ingeniører for at lytte til hans ugentlige "Vi er alle dømt"-råben i 30 minutter.! Men ud over alt det skal du bevare en ingeniør-tankegang, og du behøver ikke at være fuldtidsprogrammør for at gøre det.
Mine tips til at bevare en ingeniørmentalitet:
- Brug udviklingsmiljøet. Det betyder, at du skal være fortrolig med dit teams værktøjer, herunder kodeopbygningssystemet, versionskontrol og programmeringssprog. Som et resultat vil du blive dygtig til det sprog, dit team bruger, når de taler om produktudvikling. Dette vil også give dig mulighed for at fortsætte med at bruge din foretrukne teksteditor, som fungerer perfekt.
- Du skal være i stand til at tegne et detaljeret arkitektonisk diagram, der beskriver dit produkt på enhver overflade til enhver tid. Nu mener jeg ikke den forenklede version med tre celler og to pile. Du skal kende det detaljerede diagram af produktet. Den sværeste. Ikke et hvilket som helst sødt diagram, men et diagram, der er svært at forklare. Det skal være et kort, der er egnet til en fuldstændig forståelse af produktet. Det ændrer sig konstant, og du bør altid vide, hvorfor visse ændringer opstod.
- Overtage implementeringen af en af funktionerne. Jeg ryster bogstaveligt talt, mens jeg skriver dette, fordi dette punkt har en masse skjulte farer, men jeg er virkelig ikke sikker på, at du kan opnå punkt #1 og punkt #2 uden at forpligte dig til at implementere mindst én funktion. Ved at implementere en af funktionerne selv, vil du ikke kun være aktivt involveret i udviklingsprocessen, det vil også give dig mulighed for periodisk at skifte fra rollen som "Manager med ansvar for alt" til rollen som "Mand med ansvar for at implementere en af funktionerne." Denne ydmyge og beskedne holdning vil minde dig om vigtigheden af små beslutninger.
- Jeg ryster stadig over det hele. Det lader til, at nogen allerede råber ad mig: "Lederen, der påtog sig implementeringen af funktionen?!" (Og jeg er enig med ham!) Ja, du er stadig lederen, hvilket betyder, at det burde være en lille funktion, okay? Ja, du har stadig meget at gøre. Hvis du bare ikke kan påtage dig implementeringen af funktionen, så har jeg nogle ekstra råd til dig: ret nogle fejl. I dette tilfælde vil du ikke føle glæden ved at skabe, men du vil have en forståelse for, hvordan produktet er skabt, hvilket betyder, at du aldrig vil stå uden arbejde.
- Skriv enhedstest. Jeg gør det stadig sent i produktionscyklussen, når folk begynder at blive skøre. Tænk på det som en sundhedstjekliste for dit produkt. Gør dette ofte.
Indvending igen?
“Rands, hvis jeg skriver kode, vil jeg forvirre mit hold. De ved ikke, hvem jeg er – en leder eller en udvikler.”
Ok.
Ja, jeg sagde: "Okay!" Jeg er glad for, at du tror, du kan forvirre dit hold bare ved at svømme i udviklerdammen. Det er enkelt: Grænserne mellem forskellige roller i softwareudvikling er i øjeblikket meget udviskede. UI-fyrene laver, hvad man i store træk kan kalde JavaScript og CSS-programmering. Udviklere lærer mere og mere om design af brugeroplevelser. Folk kommunikerer med hinanden og lærer om fejl, om tyveri af andres kode, og også om det faktum, at der ikke er nogen god grund for en leder til ikke at deltage i denne massive, globale, krydsbestøvende informationsbacchanalia.
Vil du desuden være en del af et team bestående af let udskiftelige komponenter? Dette vil ikke bare gøre dit team mere smidigt, det vil give hvert teammedlem mulighed for at se produktet og virksomheden fra en række forskellige perspektiver. Hvordan kan du komme til at respektere Frank, den rolige fyr, der har ansvaret for byggeriet, mere end efter at have set den enkle elegance i hans byggemanuskripter?
Jeg ønsker ikke, at dit hold bliver forvirret og kaotisk. Tværtimod ønsker jeg, at dit team kommunikerer mere effektivt. Jeg tror på, at hvis du er med til at skabe produktet og arbejde med funktioner, vil du være tættere på dit team. Og endnu vigtigere, vil du være tættere på konstante ændringer i softwareudviklingsprocessen i din organisation.
Lad være med at udvikle dig
En kollega af mig på Borland angreb mig engang verbalt for at have kaldt hende en "koder".
“Rands, koderen er en tankeløs maskine! Abe! Koderen gør ikke noget vigtigt udover at skrive kedelige linjer med ubrugelig kode. Jeg er ikke en koder, jeg er en softwareudvikler!"
Hun havde ret, hun ville have hadet mit første råd til nye administrerende direktører: "Stop med at skrive kode!" Ikke fordi jeg foreslår, at de er kodere, men mere fordi jeg proaktivt foreslår, at de begynder at ignorere en af de vigtigste dele af deres job: softwareudvikling.
Så jeg har opdateret mit råd. Hvis du vil være en god leder, kan du lade være med at skrive kode, men...
Vær fleksibel. Husk, hvad det vil sige at være ingeniør, og stop ikke med at udvikle software.
Om forfatteren
Michael Lopp er en veteran softwareudvikler, som stadig ikke har forladt Silicon Valley. I løbet af de sidste 20 år har Michael arbejdet for en række innovative virksomheder, herunder Apple, Netscape, Symantec, Borland, Palantir, Pinterest, og også deltaget i en startup, der langsomt svævede i glemmebogen.
Uden for arbejdet driver Michael en populær blog om teknologi og ledelse under pseudonymet Rands, hvor han diskuterer ideer på ledelsesområdet med læserne, udtrykker bekymring over det konstante behov for at holde fingeren på pulsen og forklarer, at på trods af generøse belønninger for at skabe et produkt, din succes er kun mulig takket være dit team. Bloggen kan findes her .
Michael bor med sin familie i Redwood, Californien. Han finder altid tid til at cykle mountainbike, spille hockey og drikke rødvin, da det at være sund er vigtigere end at have travlt.
» Flere detaljer om bogen kan findes på
»
»
For Khabrozhiteley 20% rabat ved brug af kupon - Ledelse af mennesker
Ved betaling for papirudgaven af bogen fremsendes en elektronisk udgave af bogen på e-mail.
PS: 7% af bogens pris går til oversættelse af nye computerbøger, en liste over bøger afleveret til trykkeriet .
Kilde: www.habr.com