A projektmenedzsereknek (és azoknak, akik arról álmodoznak, hogy főnökökké válnak) elkötelezett.
Rengeteg kódot írni nehéz, de az emberek kezelése még nehezebb! Tehát csak erre a könyvre van szüksége ahhoz, hogy megtanulja mindkettőt.
Lehetséges-e kombinálni vicces történeteket és komoly tanulságokat? Michael Lopp (szűk körökben Rands néven is ismert) sikerült. Találhatsz kitalált történeteket kitalált emberekről, akik hihetetlenül kifizetődő (bár kitalált) tapasztalatokkal rendelkeznek. Rands így osztja meg változatos, olykor furcsa tapasztalatait, amelyeket az évek során szerzett nagy informatikai vállalatoknál szerzett: Apple, Pinterest, Palantir, Netscape, Symantec stb.
Ön projektmenedzser? Vagy szeretnéd megérteni, mit csinál egész nap az átkozott főnököd? Rands megtanítja neked, hogyan élj túl a felfújt pulykák mérgező világában, és hogyan boldogulj a diszfunkcionálisan rikító emberek általános őrületében. A mániákus agyrémek ebben a furcsa közösségében vannak még furcsább lények - menedzserek, akik egy misztikus szervezeti rituálé révén sok ember tervei, gondolatai és bankszámlái felett szereztek hatalmat.
Ez a könyv nem hasonlít egyetlen vezetési vagy vezetői kézirathoz sem. Michael Lopp nem titkol semmit, csak úgy mesél, ahogy van (talán nem kellene minden sztorit nyilvánosságra hozni: P). De csak így fogod megérteni, hogyan lehet túlélni egy ilyen főnökkel, hogyan kell kezelni a strébereket és a nerdeket, és hogyan lehet boldog véget hozni „az átkozott projektet”!
Kivonat. Mérnöki mentalitás
Gondolatok a következőről: Folytatni kell a kódírást?
Rands menedzserekre vonatkozó szabályokról szóló könyve egy nagyon rövid listát tartalmaz a modern vezetői „kötelező dolgokról”. E lista lakonizmusa abból fakad, hogy a „kell” fogalma egyfajta abszolútum, és ha az emberekről van szó, nagyon kevés abszolút fogalom létezik. Egy sikeres irányítási módszer egy alkalmazott számára valódi katasztrófa lesz a másik számára. Ez a gondolat az első elem a menedzser „kötelező” listáján:
Maradj rugalmas!
Azt gondolni, hogy már mindent tudsz, nagyon rossz ötlet. Egy olyan helyzetben, ahol az egyetlen állandó tény az, hogy a világ folyamatosan változik, a rugalmasság válik az egyetlen helyes pozícióvá.
Paradox módon a lista második eleme meglepően rugalmatlan. Ez a pont azonban a személyes kedvencem, mert úgy gondolom, hogy ez segít megteremteni a vezetői növekedés alapjait. Ez a bekezdés így szól:
Hagyd abba a kódírást!
Elméletileg, ha menedzser akarsz lenni, meg kell tanulnod bízni azokban, akik neked dolgoznak, és a kódolást teljes egészében nekik kell átadnod. Ezt a tanácsot általában nehéz megemészteni, különösen az újonnan vert menedzserek számára. Valószínűleg az egyik oka annak, hogy menedzserek lettek, a fejlesztési termelékenységük miatt, és ha valami rosszul sül el, az első reakciójuk az, hogy visszavesznek azokhoz a készségekhez, amelyekben teljes mértékben megbíznak, vagyis a kódírási képességükben.
Amikor látom, hogy egy újonnan vert menedzser „elmerül” a kódírásba, azt mondom neki: „Tudjuk, hogy tudsz kódot írni. A kérdés az: tudsz vezetni? Már nem egyedül magadért vagy felelős, hanem az egész csapatért; és szeretném megbizonyosodni arról, hogy ráveheti csapatát a problémák önálló megoldására, anélkül, hogy magának kellene megírnia a kódot. A te feladatod az, hogy kitaláld, hogyan méretezheted magad. Nem akarom, hogy csak egy legyél, azt akarom, hogy sok olyan legyen, mint te."
Jó tanács, ugye? Skála. Menedzsment. Felelősség. Ilyen gyakori hívószavak. Kár, hogy rossz a tanács.
Helytelen?
Igen. A tanács rossz! Nem teljesen tévedés, de elég téves ahhoz, hogy fel kellett hívnom néhány korábbi kollégát, és bocsánatot kérnem: „Emlékszel arra a kedvenc kijelentésemre, hogy abba kell hagynod a kódírást? Ez rossz! Igen... Kezdje újra a programozást. Kezdje Pythonnal és Rubyval. Igen komoly vagyok! A karriered múlik rajta!”
Amikor szoftverfejlesztőként kezdtem a pályafutásomat a Borlandnál, a Paradox Windows csapatában dolgoztam, amely hatalmas csapat volt. Csak 13 alkalmazásfejlesztő volt. Ha hozzáadja azokat az embereket más csapatokból, akik szintén folyamatosan dolgoztak a projekt kulcsfontosságú technológiáin, például az alapvető adatbázis-motoron és az alapvető alkalmazásszolgáltatásokon, akkor 50 mérnök vesz részt közvetlenül a termék fejlesztésében.
Egyetlen másik csapat, amelynél dolgoztam, még csak meg sem közelíti ezt a méretet. Valójában évről évre fokozatosan csökken azoknak a csapatnak a száma, akiknél dolgozom. Mi történik? Mi, fejlesztők, együtt egyre okosabbak leszünk? Nem, csak megosztjuk a terhet.
Mit csináltak a fejlesztők az elmúlt 20 évben? Ezalatt egy barom kódot írtunk. Kódtenger! Annyi kódot írtunk, hogy úgy döntöttünk, jó ötlet lenne mindent leegyszerűsíteni, és nyílt forráskódot váltani.
Szerencsére az internetnek köszönhetően ez a folyamat a lehető legegyszerűbbé vált. Ha Ön szoftverfejlesztő, most azonnal megnézheti! Keressen rá a nevére a Google-on vagy a Githubon, és olyan kódot fog látni, amelyről már rég elfelejtett, de bárki megtalálhatja. Ijesztő, igaz? Nem tudtad, hogy a kód örökké él? Igen, örökké él.
A kód örökké él. A jó kód pedig nemcsak örökké él, hanem növekszik is, mert aki értékeli, folyamatosan gondoskodik róla, hogy friss maradjon. Ez a halom jó minőségű, jól karbantartott kód segít csökkenteni az átlagos mérnöki csapatlétszámot, mert lehetővé teszi számunkra, hogy a meglévő kódra összpontosítsunk az új kód írása helyett, és kevesebb emberrel és rövidebb időn belül elvégezzük a munkát.
Ez a gondolatmenet lehangolóan hangzik, de az ötlet az, hogy mindannyian csak egy csomó integrációs automata vagyunk, amelyek ragasztószalagot használnak a meglévő dolgok különböző darabjainak összekapcsolására, hogy ugyanannak a dolognak egy kissé eltérő változatát hozzuk létre. Ez egy klasszikus gondolkodásmód a felsővezetők körében, akik szeretik a kiszervezést. „Bárki, aki tudja, hogyan kell használni a Google-t, és rendelkezik ragasztószalaggal, megteheti! Akkor miért fizetünk sok pénzt a gépeinkért?”
Nagyon nagy pénzeket fizetünk ezeknek a vezetői srácoknak, de ilyen hülyeségeket gondolnak. Még egyszer, a legfontosabb megjegyzésem az, hogy bolygónkon sok zseniális és nagyon keményen dolgozó fejlesztő van; igazán zseniálisak és szorgalmasak, bár egyetlen percet sem töltöttek azzal, hogy akkreditált egyetemeken üldögéljenek. Ó igen, mostanra egyre többen vannak!
Nem javaslom, hogy kezdjen aggódni a helye miatt, csak azért, mert néhány zseniális elvtárs állítólag arra vadászik. Azt javaslom, kezdjen el aggódni emiatt, mert a szoftverfejlesztés evolúciója valószínűleg gyorsabban halad, mint Ön. Ön tíz éve dolgozik, ebből öt éve menedzserként, és azt gondolja: „Már tudom, hogyan készül a szoftver.” Igen tudod. Viszlát…
Hagyd abba a kódírást, de...
Ha követi az eredeti tanácsomat, és abbahagyja a kódírást, akkor önként abbahagyja a létrehozási folyamatban való részvételt is. Ez az oka annak, hogy nem használok aktívan kiszervezést. Az automaták nem alkotnak, hanem termelnek. A jól megtervezett folyamatok rengeteg pénzt takarítanak meg, de semmi újat nem hoznak világunkba.
Ha van egy kis csapatod, aki sokat csinál kevés pénzért, akkor a kódírás abbahagyásának gondolata rossz karrierdöntésnek tűnik számomra. Még a végtelen szabályozásokkal, folyamatokkal és szabályzatokkal rendelkező szörnyeteg cégeknél sincs joga elfelejteni, hogyan kell saját maga fejleszteni szoftvert. A szoftverfejlesztés pedig folyamatosan változik. Most éppen változik. A lábad alatt! Ebben a pillanatban!
Kifogásaid vannak. Megért. Hallgassunk.
„Rands, a rendezői szék felé tartok! Ha továbbra is kódot írok, senki sem fogja elhinni, hogy fejlődhetek.”
A következőt szeretném kérdezni: mióta a „Hamarosan vezérigazgató leszek!” székében ült, észrevette-e, hogy a szoftverfejlesztési környezet még az Ön cégén belül is változik? Ha a válasza igen, akkor még egy kérdést teszek fel: pontosan hogyan változik, és mit fog tenni ezekkel a változásokkal? Ha az első kérdésemre nemmel válaszolt, akkor át kell ülnie egy másik székbe, mert (fogadom!) a szoftverfejlesztés területe éppen ebben a másodpercben változik. Hogyan fog valaha is növekedni, ha lassan, de biztosan elfelejti, hogyan kell szoftvereket fejleszteni?
Azt tanácsolom, hogy ne kötelezze el magát a rengeteg funkció megvalósítása mellett a következő termékében. Folyamatosan lépéseket kell tennie, hogy lépést tartson csapata szoftverfejlesztésével. Ezt igazgatóként és alelnökként is megteheti. Valami más?
– Jaj, Rands! De valakinek döntőbírónak kell lennie! Valakinek látnia kell a nagy képet. Ha kódot írok, elveszítem a perspektívát."
Továbbra is játékvezetőnek kell lenned, közvetítened kell a döntéseket, és továbbra is minden hétfőn reggel négyszer kell körbejárnod az épületet az egyik mérnököddel, hogy meghallgasd a heti "Mindnyájan el vagyunk ítélve" 30-ért. perc.! De mindezeken túl meg kell őriznie a mérnöki gondolkodásmódot, és ehhez nem kell főállású programozónak lennie.
Tippjeim a mérnöki mentalitás megőrzéséhez:
- Használja a fejlesztői környezetet. Ez azt jelenti, hogy ismernie kell csapata eszközeit, beleértve a kódépítő rendszert, a verziókezelést és a programozási nyelvet. Ennek eredményeként jártas lesz abban a nyelvben, amelyet csapata a termékfejlesztésről beszél. Ez azt is lehetővé teszi, hogy továbbra is használja kedvenc szövegszerkesztőjét, amely tökéletesen működik.
- Bármikor képesnek kell lennie a termékét leíró részletes építészeti diagramot bármilyen felületre rajzolni. Most nem az egyszerűsített változatra gondolok, három cellával és két nyíllal. Ismernie kell a termék részletes diagramját. A legnehezebb. Nem akármilyen aranyos diagram, hanem egy nehezen megmagyarázható diagram. Olyan térképnek kell lennie, amely alkalmas a termék teljes megértésére. Folyamatosan változik, és mindig tudnia kell, miért történtek bizonyos változások.
- Vedd át az egyik funkció megvalósítását. Szó szerint összerándulok, amikor ezt írom, mert ez a pont sok rejtett veszélyt rejt magában, de nem vagyok benne biztos, hogy az 1. és 2. pontot teljesíteni tudja anélkül, hogy elkötelezné magát legalább egy szolgáltatás megvalósítása mellett. Ha saját maga implementálja az egyik funkciót, nemcsak aktívan részt vesz a fejlesztési folyamatban, hanem lehetővé teszi, hogy időszakonként átváltson a „Mindenért felelős menedzser” szerepkörből a „Minden megvalósításáért felelős ember” szerepkörre. a funkciókról.” Ez az alázatos és szerény hozzáállás emlékeztetni fogja a kis döntések fontosságára.
- Még mindig remegek az egész testemből. Úgy tűnik, valaki már kiabál velem: „A vezető, aki magára vállalta a funkció megvalósítását?! (És egyetértek vele!) Igen, még mindig te vagy a menedzser, ami azt jelenti, hogy valami kis funkciónak kell lennie, oké? Igen, még sok tennivalód van. Ha egyszerűen nem tudja vállalni a funkció megvalósítását, akkor van néhány tartalék tanácsom: javítson ki néhány hibát. Ebben az esetben nem az alkotás örömét fogja érezni, de megérti a termék létrejöttét, ami azt jelenti, hogy soha nem marad ki a munkából.
- Írjon egységteszteket. Még mindig a gyártási ciklus végén csinálom ezt, amikor az emberek kezdenek megőrülni. Tekintse ezt a termék egészségügyi ellenőrzőlistájának. Tedd ezt gyakran.
Már megint kifogás?
„Rands, ha kódot írok, összezavarom a csapatomat. Nem fogják tudni, ki vagyok – menedzser vagy fejlesztő.”
Rendben van.
Igen, azt mondtam: "Rendben!" Örülök, hogy úgy gondolja, hogy összezavarhatja csapatát azzal, hogy úszik a fejlesztő tóban. Egyszerű: jelenleg nagyon elmosódnak a határok a szoftverfejlesztésben betöltött különböző szerepek között. A felhasználói felület srácok azt csinálják, amit nagyjából JavaScript- és CSS-programozásnak nevezhetünk. A fejlesztők egyre többet tanulnak a felhasználói élmény kialakításáról. Az emberek kommunikálnak egymással és tanulnak a hibákról, mások kódjának ellopásáról, és arról is, hogy nincs jó ok arra, hogy egy menedzser ne vegyen részt ebben a hatalmas, globális, keresztbeporzó információs bakkanáliában.
Emellett szeretnél egy könnyen cserélhető alkatrészekből álló csapat tagja lenni? Ez nem csak a csapatát teszi fürgébbé, hanem minden csapattagnak lehetőséget ad arra, hogy a terméket és a vállalatot különböző nézőpontokból lássa. Hogyan lehet jobban tisztelni Franket, a higgadt fickót, aki az építésekért felelős, mint miután láttad az építési forgatókönyveinek egyszerű eleganciáját?
Nem akarom, hogy a csapatod összezavarodjon és kaotikussá váljon. Éppen ellenkezőleg, azt szeretném, ha csapata hatékonyabban kommunikálna. Úgy gondolom, hogy ha részt vesz a termék létrehozásában és a funkciókon dolgozik, akkor közelebb kerül a csapatához. És ami még fontosabb, közelebb kerülhet a szervezetén belüli szoftverfejlesztési folyamat állandó változásaihoz.
Ne hagyd abba a fejlődést
Egy kollégám a Borlandnál egyszer szóban támadt, amiért „kódolónak” neveztem.
„Rands, a kódoló egy esztelen gép! Majom! A kódoló nem csinál semmi fontosat, csak leírja a haszontalan kód unalmas sorait. Nem kódoló vagyok, hanem szoftverfejlesztő!”
Igaza volt, utálta volna az új vezérigazgatóknak adott kezdeti tanácsomat: „Hagyd abba a kódírást!” Nem azért, mert azt sugallnám, hogy kódolók, hanem inkább azért, mert proaktívan azt javaslom, kezdjék figyelmen kívül hagyni munkájuk egyik legfontosabb részét: a szoftverfejlesztést.
Szóval frissítettem a tanácsomat. Ha jó vezető akarsz lenni, abbahagyhatod a kódírást, de...
Legyen rugalmas. Ne feledje, mit jelent mérnöknek lenni, és ne hagyja abba a szoftverfejlesztést.
A szerzőről
Michael Lopp egy veterán szoftverfejlesztő, aki még mindig nem hagyta el a Szilícium-völgyet. Az elmúlt 20 évben Michael számos innovatív vállalatnál dolgozott, köztük az Apple-nél, a Netscape-nél, a Symantecnél, a Borlandnál, a Palantirnál, a Pinterestnél, és részt vett egy olyan startupban is, amely lassan a feledés homályába merült.
Michael a munkán kívül Rands álnéven népszerű blogot vezet a technológiáról és a menedzsmentről, ahol a menedzsmenttel kapcsolatos ötleteket vitatja meg az olvasókkal, aggodalmát fejezi ki amiatt, hogy folyamatosan figyelni kell, és elmagyarázza, hogy annak ellenére, hogy bőkezű jutalmak egy termék létrehozásáért, sikere csak a csapatának köszönhető. A blog itt található .
Michael a kaliforniai Redwoodban él családjával. Mindig jut ideje mountain bike-ozni, jégkorongozni és vörösbort inni, hiszen az egészség fontosabb, mint az elfoglaltság.
» A könyvvel kapcsolatos további információkért látogasson el ide
»
»
Khabrozhiteli esetében 20% kedvezmény a kuponból - Emberek kezelése
A könyv papíralapú változatának kifizetése után e-mailben elküldjük a könyv elektronikus változatát.
Ui: a könyv árának 7%-a az új számítógépes könyvek fordítására, a nyomdának átadott könyvek listájára megy .
Forrás: will.com