Dedikert til prosjektledere (og de som drømmer om å bli sjefer).
Det er vanskelig å skrive tonnevis med kode, men det er enda vanskeligere å administrere mennesker! Så du trenger bare denne boken for å lære å gjøre begge deler.
Er det mulig å kombinere morsomme historier og seriøse lærdommer? Michael Lopp (også kjent i snevre kretser som Rands) lyktes. Du finner fiktive historier om fiktive mennesker med utrolig givende (riktignok fiktive) opplevelser. Dette er hvordan Rands deler sine varierte, noen ganger merkelige erfaringer han har fått gjennom årene med å jobbe i store IT-selskaper: Apple, Pinterest, Palantir, Netscape, Symantec, etc.
Er du prosjektleder? Eller vil du forstå hva sjefen din gjør hele dagen? Rands vil lære deg hvordan du kan overleve i den giftige verden av oppblåste kalkuner og trives i den generelle galskapen til dysfunksjonelt flamboyante mennesker. I dette merkelige fellesskapet av galne hjernevitere er det enda merkeligere skapninger – ledere som gjennom et mystisk organisasjonsritual har fått makt over mange menneskers planer, tanker og bankkontoer.
Denne boken er ulik noe ledelses- eller ledermanuskript. Michael Lopp legger ikke skjul på noe, han bare forteller det som det er (kanskje ikke alle historier bør offentliggjøres:P). Men bare på denne måten vil du forstå hvordan du overlever med en slik sjef, hvordan du administrerer nerder og nerder, og hvordan du bringer "det jævla prosjektet" til en lykkelig slutt!
Utdrag. Ingeniørmentalitet
Tanker om: Bør du fortsette å skrive kode?
Rands bok om regler for ledere inneholder en veldig kort liste over moderne ledelsesmessige «må-doser». Lakonismen til denne listen stammer fra det faktum at konseptet "må" er en slags absolutt, og når det kommer til mennesker, er det svært få absolutte konsepter. En vellykket ledelsesmetode for en ansatt vil være en virkelig katastrofe for en annen. Denne tanken er det første elementet på lederens "må-gjøre"-liste:
Vær fleksibel!
Å tenke at du allerede vet alt er en veldig dårlig idé. I en situasjon der det eneste konstante faktum er at verden er i konstant endring, blir fleksibilitet den eneste riktige posisjonen.
Paradoksalt nok er det andre punktet på listen overraskende lite fleksibelt. Dette punktet er imidlertid min personlige favoritt fordi jeg tror det bidrar til å skape grunnlaget for ledervekst. Dette avsnittet lyder:
Slutt å skrive kode!
I teorien, hvis du vil være leder, må du lære å stole på de som jobber for deg og overlate kodingen helt til dem. Dette rådet er vanligvis vanskelig å fordøye, spesielt for nyslåtte ledere. En av grunnene til at de ble ledere er sannsynligvis på grunn av produktiviteten deres i utviklingen, og når ting går galt, er deres første reaksjon å falle tilbake på ferdighetene de har full tillit til, som er deres evne til å skrive kode.
Når jeg ser at en nyslått manager «synker» ned i å skrive kode, sier jeg til ham: «Vi vet at du kan skrive kode. Spørsmålet er: kan du lede? Du er ikke lenger ansvarlig for deg selv alene, du er ansvarlig for hele laget; og jeg vil sørge for at du kan få teamet ditt til å løse problemer på egenhånd, uten at du trenger å skrive koden selv. Din jobb er å finne ut hvordan du skalerer deg selv. Jeg vil ikke at du bare skal være én, jeg vil at det skal være mange som deg.»
Gode råd, ikke sant? Skala. Ledelse. Ansvar. Slike vanlige buzzwords. Det er synd at rådet er feil.
Stemmer ikke?
Ja. Rådene er feil! Ikke helt feil, men feil nok til at jeg måtte ringe noen tidligere kolleger og be om unnskyldning: «Husker du det favorittutsagnet mitt om hvordan du skal slutte å skrive kode? Det er feil! Ja... Begynn å programmere igjen. Start med Python og Ruby. Ja, jeg mener det seriøst! Din karriere avhenger av det!»
Da jeg startet min karriere som programvareutvikler i Borland, jobbet jeg på Paradox Windows-teamet, som var et stort team. Det var 13 applikasjonsutviklere alene. Hvis du legger til folk fra andre team som også hele tiden jobbet med nøkkelteknologier for dette prosjektet, slik som kjernedatabasemotoren og kjerneapplikasjonstjenester, fikk du 50 ingeniører direkte involvert i utviklingen av dette produktet.
Ingen andre lag jeg noen gang har jobbet for kommer i nærheten av denne størrelsen. Faktisk, for hvert år som går, reduseres antallet personer i teamet jeg jobber med gradvis. Hva skjer? Blir vi utviklere til sammen smartere og smartere? Nei, vi deler bare belastningen.
Hva har utviklere gjort de siste 20 årene? I løpet av denne tiden skrev vi en hel masse kode. Hav av kode! Vi skrev så mye kode at vi bestemte at det ville være en god idé å forenkle alt og gå med åpen kildekode.
Heldigvis, takket være Internett, har denne prosessen nå blitt så enkel som mulig. Hvis du er en programvareutvikler, kan du sjekke det ut nå! Søk på navnet ditt på Google eller Github og du vil se kode som du lenge har glemt, men som alle kan finne. Skremmende, ikke sant? Visste du ikke at koden lever for alltid? Ja, han lever evig.
Koden lever evig. Og god kode lever ikke bare evig, den vokser fordi de som verdsetter den hele tiden sørger for at den forblir fersk. Denne haugen med høykvalitets, godt vedlikeholdt kode bidrar til å redusere den gjennomsnittlige ingeniørteamstørrelsen fordi den lar oss fokusere på eksisterende kode i stedet for å skrive ny kode, og få jobben gjort med færre personer og i en kortere tidsramme.
Dette resonnementet høres deprimerende ut, men ideen er at vi alle bare er en gjeng med integrasjonsautomater som bruker gaffatape for å koble forskjellige biter av eksisterende ting sammen for å lage en litt annen versjon av den samme tingen. Dette er en klassisk tankegang blant toppledere som elsker outsourcing. «Alle som vet hvordan man bruker Google og har gaffatape kan gjøre dette! Hvorfor betaler vi så mye penger til maskinene våre?»
Vi betaler disse ledelsesgutta veldig store penger, men de synes sånt tull. Nok en gang, mitt hovedpoeng er at det er mange strålende og veldig hardtarbeidende utviklere på planeten vår; de er virkelig geniale og flittige, selv om de ikke har brukt et eneste minutt på akkrediterte universiteter. Å ja, nå blir det flere og flere av dem!
Jeg foreslår ikke at du begynner å bekymre deg for plassen din bare fordi noen geniale kamerater angivelig jakter på den. Jeg foreslår at du begynner å bekymre deg for det fordi utviklingen av programvareutvikling sannsynligvis går raskere enn du gjør. Du har jobbet i ti år, fem av dem som leder, og du tenker: "Jeg vet allerede hvordan programvare utvikles." Ja du vet. Ha det…
Slutt å skrive kode, men...
Hvis du følger mine opprinnelige råd og slutter å skrive kode, slutter du også frivillig å delta i opprettelsesprosessen. Det er av denne grunn at jeg ikke aktivt bruker outsourcing. Automater skaper ikke, de produserer. Godt utformede prosesser sparer mye penger, men de bringer ikke noe nytt til vår verden.
Hvis du har et lite team som gjør mye for lite penger, virker ideen om å slutte å skrive kode som en dårlig karriereavgjørelse for meg. Selv i monsterselskaper med deres endeløse reguleringer, prosesser og policyer, har du ingen rett til å glemme hvordan du utvikler programvare selv. Og programvareutvikling er i stadig endring. Det endrer seg akkurat nå. Under føttene dine! I dette sekundet!
Du har innvendinger. Forstå. La oss høre.
«Rands, jeg er på vei til direktørstolen! Hvis jeg fortsetter å skrive kode, vil ingen tro at jeg kan vokse.»
Jeg vil spørre deg dette: Siden du satt i stolen "Jeg er i ferd med å bli administrerende direktør!", har du lagt merke til at utviklingslandskapet for programvare er i endring, selv i din bedrift? Hvis svaret ditt er ja, vil jeg stille deg et annet spørsmål: hvordan endrer det seg, og hva skal du gjøre med disse endringene? Hvis du svarte "nei" på det første spørsmålet mitt, må du flytte til en annen stol, fordi (jeg vedder på!) feltet for programvareutvikling endrer seg akkurat nå. Hvordan skal du noen gang vokse hvis du sakte men sikkert glemmer hvordan du utvikler programvare?
Mitt råd er ikke å forplikte deg til å implementere tonnevis av funksjoner for ditt neste produkt. Du må hele tiden ta skritt for å holde deg oppdatert på hvordan teamet ditt bygger programvare. Du kan gjøre dette både som direktør og som visepresident. Noe annet?
«Åh, Rands! Men noen må være dommeren! Noen må se det store bildet. Hvis jeg skriver kode, mister jeg perspektivet."
Du må fortsatt være dommeren, du må fortsatt kringkaste avgjørelsene, og du må fortsatt gå rundt i bygningen fire ganger hver mandag morgen sammen med en av ingeniørene dine for å lytte til hans ukentlige "We're all doomed" rant i 30 minutter. ! Men utover alt det, må du opprettholde en ingeniørtankegang, og du trenger ikke å være programmerer på heltid for å gjøre det.
Mine tips for å opprettholde en ingeniørmentalitet:
- Bruk utviklingsmiljøet. Dette betyr at du bør være kjent med teamets verktøy, inkludert kodebyggesystemet, versjonskontroll og programmeringsspråk. Som et resultat vil du bli dyktig i språket ditt team bruker når de snakker om produktutvikling. Dette vil også tillate deg å fortsette å bruke din favoritt tekstredigerer, som fungerer perfekt.
- Du må kunne tegne et detaljert arkitektonisk diagram som beskriver produktet ditt på hvilken som helst overflate når som helst. Nå mener jeg ikke den forenklede versjonen med tre celler og to piler. Du må kjenne det detaljerte diagrammet av produktet. Den vanskeligste. Ikke et hvilket som helst søtt diagram, men et diagram som er vanskelig å forklare. Det bør være et kart egnet for en fullstendig forståelse av produktet. Det er i konstant endring, og du bør alltid vite hvorfor visse endringer skjedde.
- Ta over implementeringen av en av funksjonene. Jeg kryper bokstavelig talt når jeg skriver dette fordi dette punktet har mange skjulte farer, men jeg er virkelig ikke sikker på at du kan oppnå punkt #1 og punkt #2 uten å forplikte seg til å implementere minst én funksjon. Ved å implementere en av funksjonene selv, vil du ikke bare være aktivt involvert i utviklingsprosessen, det vil også tillate deg å med jevne mellomrom bytte fra rollen som "Manager med ansvar for alt" til rollen som "Mann med ansvar for å implementere en av funksjonene." Denne ydmyke og upretensiøse holdningen vil minne deg om viktigheten av små avgjørelser.
- Jeg skjelver fortsatt i hele kroppen. Det ser ut til at noen allerede roper på meg: «Lederen som tok på seg implementeringen av funksjonen?! (Og jeg er enig med ham!) Ja, du er fortsatt lederen, noe som betyr at det burde være en liten funksjon, ok? Ja, du har fortsatt mye å gjøre. Hvis du bare ikke kan ta på deg implementeringen av funksjonen, så har jeg noen ekstra råd til deg: fiks noen feil. I dette tilfellet vil du ikke kjenne på skapergleden, men du vil ha en forståelse for hvordan produktet er skapt, noe som betyr at du aldri vil stå utenfor arbeidet.
- Skriv enhetstester. Jeg gjør fortsatt dette sent i produksjonssyklusen når folk begynner å bli gale. Tenk på det som en helsesjekkliste for produktet ditt. Gjør dette ofte.
Innvending igjen?
"Rands, hvis jeg skriver kode, vil jeg forvirre laget mitt. De vil ikke vite hvem jeg er – en leder eller en utvikler.»
OK.
Ja, jeg sa: "Ok!" Jeg er glad du tror du kan forvirre laget ditt bare ved å svømme i utviklerdammen. Det er enkelt: Grensene mellom ulike roller i programvareutvikling er for tiden veldig uklare. UI-gutta gjør det som i grove trekk kan kalles JavaScript og CSS-programmering. Utviklere lærer mer og mer om design av brukeropplevelse. Folk kommuniserer med hverandre og lærer om feil, om tyveri av andres kode, og også om det faktum at det ikke er noen god grunn for en leder til ikke å delta i denne massive, globale, kryssbestøvende informasjonsbacchanaliaen.
Dessuten, vil du være en del av et team bestående av lett utskiftbare komponenter? Dette vil ikke bare gjøre teamet ditt mer kvikk, det vil gi hvert teammedlem muligheten til å se produktet og selskapet fra en rekke perspektiver. Hvordan kan du komme til å respektere Frank, den rolige fyren som har ansvaret for byggene, mer enn etter å ha sett den enkle elegansen i byggemanusene hans?
Jeg vil ikke at teamet ditt skal bli forvirret og kaotisk. Tvert imot, jeg vil at teamet ditt skal kommunisere mer effektivt. Jeg tror at hvis du er med på å lage produktet og jobbe med funksjoner, vil du være nærmere teamet ditt. Og enda viktigere, vil du være nærmere konstante endringer i programvareutviklingsprosessen i din organisasjon.
Ikke slutt å utvikle deg
En kollega av meg på Borland angrep meg en gang verbalt for å ha kalt henne en «koder».
«Rands, koderen er en tankeløs maskin! Ape! Koderen gjør ikke noe viktig bortsett fra å skrive kjedelige linjer med ubrukelig kode. Jeg er ikke en koder, jeg er en programvareutvikler!"
Hun hadde rett, hun ville ha hatet mitt første råd til nye administrerende direktører: "Slutt å skrive kode!" Ikke fordi jeg antyder at de er kodere, men mer fordi jeg proaktivt foreslår at de begynner å ignorere en av de viktigste delene av jobben deres: programvareutvikling.
Så jeg har oppdatert rådene mine. Hvis du vil være en god leder, kan du slutte å skrive kode, men...
Vær fleksibel. Husk hva det vil si å være ingeniør og ikke slutt å utvikle programvare.
Om forfatteren
Michael Lopp er en erfaren programvareutvikler som fortsatt ikke har forlatt Silicon Valley. I løpet av de siste 20 årene har Michael jobbet for en rekke innovative selskaper, inkludert Apple, Netscape, Symantec, Borland, Palantir, Pinterest, og også deltatt i en oppstart som sakte fløt inn i glemselen.
Utenom jobben driver Michael en populær blogg om teknologi og ledelse under pseudonymet Rands, der han diskuterer ideer innen ledelse med leserne, uttrykker bekymring for det konstante behovet for å holde fingeren på pulsen, og forklarer at til tross for sjenerøse belønninger for å lage et produkt, suksessen din er bare mulig takket være teamet ditt. Bloggen finner du her .
Michael bor med familien sin i Redwood, California. Han finner alltid tid til å sykle terreng, spille hockey og drikke rødvin, siden det å være sunn er viktigere enn å ha det travelt.
» For mer informasjon om boken, vennligst besøk
»
»
For Khabrozhiteli 20% rabatt på kupongen - Administrere mennesker
Ved betaling for papirutgaven av boken sendes en elektronisk versjon av boken på e-post.
PS: 7 % av prisen på boken går til oversettelse av nye databøker, en liste over bøker overlevert til trykkeriet .
Kilde: www.habr.com