Opgedra aan projekbestuurders (en diegene wat daarvan droom om base te word).
Dit is moeilik om tonne kode te skryf, maar om mense te bestuur is selfs moeiliker! So jy het net hierdie boek nodig om te leer hoe om albei te doen.
Is dit moontlik om snaakse stories en ernstige lesse te kombineer? Michael Lopp (ook bekend in noue kringe as Rande) het daarin geslaag. Jy sal fiktiewe stories vind oor fiktiewe mense met ongelooflike lonende (alhoewel fiktiewe) ervarings. Só deel Rands sy uiteenlopende, soms vreemde ervarings wat hy opgedoen het oor die jare van werk in groot IT-korporasies: Apple, Pinterest, Palantir, Netscape, Symantec, ens.
Is jy 'n projekbestuurder? Of wil jy verstaan wat jou verdomde baas heeldag doen? Rande sal jou leer hoe om te oorleef in die Toxic World of Inflated Turkeys en te floreer in die algemene waansin van disfunksioneel flambojante mense. In hierdie vreemde gemeenskap van maniese breinbrekers is daar selfs vreemder wesens – bestuurders wat deur 'n mistieke organisatoriese ritueel mag oor die planne, gedagtes en bankrekeninge van baie mense verkry het.
Hierdie boek is anders as enige bestuurs- of leierskapmanuskrip. Michael Lopp steek niks weg nie, hy vertel dit net soos dit is (miskien moet nie alle stories openbaar gemaak word nie: P). Maar net op hierdie manier sal jy verstaan hoe om saam met so 'n baas te oorleef, hoe om geeks en nerds te bestuur, en hoe om "daardie verdomde projek" tot 'n gelukkige einde te bring!
Uittreksel. Ingenieursmentaliteit
Gedagtes oor: Moet jy aanhou om kode te skryf?
Rands se boek oor reëls vir bestuurders bevat 'n baie kort lys van moderne bestuurs-"moet-doen". Die lakonisme van hierdie lys spruit uit die feit dat die konsep van "moet" 'n soort absoluut is, en wanneer dit by mense kom, is daar baie min absolute konsepte. 'n Suksesvolle bestuursmetode vir een werknemer sal 'n ware ramp vir 'n ander wees. Hierdie gedagte is die eerste item op die bestuurder se "moet-doen"-lys:
Bly buigsaam!
Om te dink dat jy reeds alles weet, is 'n baie slegte idee. In 'n situasie waar die enigste konstante feit is dat die wêreld voortdurend verander, word buigsaamheid die enigste korrekte posisie.
Paradoksaal genoeg is die tweede item op die lys verbasend onbuigsaam. Hierdie punt is egter my persoonlike gunsteling omdat ek glo dit help om die grondslag vir bestuursgroei te skep. Hierdie paragraaf lees:
Hou op om kode te skryf!
In teorie, as jy 'n bestuurder wil wees, moet jy leer om diegene wat vir jou werk te vertrou en die kodering geheel en al aan hulle oor te gee. Hierdie raad is gewoonlik moeilik om te verteer, veral vir nuwe bestuurders. Waarskynlik een van die redes waarom hulle bestuurders geword het, is vanweë hul produktiwiteit in ontwikkeling, en wanneer dinge verkeerd loop, is hul eerste reaksie om terug te val op die vaardighede waarin hulle volle vertroue het, wat hul vermoë is om kode te skryf.
Toe ek sien dat 'n nuwe bestuurder "sink" om kode te skryf, sê ek vir hom: "Ons weet dat jy kode kan skryf. Die vraag is: kan jy lei? Jy is nie meer verantwoordelik vir jouself alleen nie, jy is verantwoordelik vir die hele span; en ek wil seker maak dat jy jou span kan kry om probleme op hul eie op te los, sonder dat jy self die kode hoef te skryf. Jou taak is om uit te vind hoe om jouself te skaal. Ek wil nie hê jy moet net een wees nie, ek wil hê daar moet baie soos jy wees.”
Goeie raad, reg? Skaal. Bestuur. Verantwoordelikheid. Sulke algemene gonswoorde. Dit is jammer dat die raad verkeerd is.
Verkeerd?
Ja. Die raad is verkeerd! Nie heeltemal verkeerd nie, maar verkeerd genoeg dat ek ’n paar oud-kollegas moes bel en om verskoning moes vra: “Onthou jy daardie gunsteling-stelling van my oor hoe jy moet ophou kode skryf? Dis verkeerd! Ja... Begin weer programmeer. Begin met Python en Ruby. Ja, ek is ernstig! Jou loopbaan hang daarvan af!”
Toe ek my loopbaan as 'n sagteware-ontwikkelaar by Borland begin het, het ek op die Paradox Windows-span gewerk, wat 'n groot span was. Daar was 13 toepassingsontwikkelaars alleen. As jy mense van ander spanne byvoeg wat ook voortdurend aan sleuteltegnologieë vir hierdie projek gewerk het, soos die kerndatabasisenjin en kerntoepassingsdienste, het jy 50 ingenieurs direk betrokke by die ontwikkeling van hierdie produk.
Geen ander span waarvoor ek nog ooit gewerk het, kom selfs naby aan hierdie grootte nie. Trouens, met elke jaar wat verbygaan, neem die aantal mense in die span waaraan ek werk geleidelik af. Wat gaan aan? Word ons ontwikkelaars gesamentlik slimmer en slimmer? Nee, ons deel net die las.
Wat het ontwikkelaars die afgelope 20 jaar gedoen? Gedurende hierdie tyd het ons 'n klomp kode geskryf. See van kode! Ons het soveel kode geskryf dat ons besluit het dit sou 'n goeie idee wees om alles te vereenvoudig en oopbron te gaan.
Gelukkig, danksy die internet, het hierdie proses nou so eenvoudig as moontlik geword. As jy 'n sagteware-ontwikkelaar is, kan jy dit dadelik nagaan! Soek jou naam op Google of Github en jy sal kode sien waarvan jy lankal vergeet het, maar wat enigiemand kan vind. Scary, reg? Het jy nie geweet dat die kode vir ewig lewe nie? Ja, hy leef vir ewig.
Die kode leef vir ewig. En goeie kode leef nie net vir ewig nie, dit groei omdat diegene wat dit waardeer voortdurend verseker dat dit vars bly. Hierdie stapel van hoë-gehalte, goed onderhou kode help om die gemiddelde ingenieurspan grootte te verminder omdat dit ons in staat stel om te fokus op bestaande kode eerder as om nuwe kode te skryf, en die werk gedoen te kry met minder mense en in 'n korter tydraamwerk.
Hierdie redenasie klink neerdrukkend, maar die idee is dat ons almal net 'n klomp integrasie-outomatiese is wat plakband gebruik om verskillende stukke bestaande goed aan mekaar te verbind om 'n effens ander weergawe van dieselfde ding te skep. Dit is 'n klassieke denkrigting onder senior bestuurders wat lief is vir uitkontraktering. "Enigiemand wat weet hoe om Google te gebruik en 'n bietjie plakband het, kan dit doen! Hoekom betaal ons dan baie geld aan ons masjiene?”
Ons betaal hierdie bestuur ouens baie groot geld, maar hulle dink sulke nonsens. Weereens, my sleutelpunt is dat daar baie briljante en baie hardwerkende ontwikkelaars op ons planeet is; hulle is werklik briljant en ywerig, hoewel hulle nog nie 'n enkele minuut aan geakkrediteerde universiteite gesit het nie. O ja, nou is daar meer en meer van hulle!
Ek stel nie voor dat jy jou oor jou plek begin bekommer net omdat sommige briljante kamerade na bewering daarna jag nie. Ek stel voor jy begin jou daaroor bekommer, want die evolusie van sagteware-ontwikkeling beweeg waarskynlik vinniger as wat jy is. Jy werk al tien jaar, vyf van hulle as 'n bestuurder, en jy dink: "Ek weet reeds hoe sagteware ontwikkel word." Ja, jy weet. Totsiens…
Hou op om kode te skryf, maar...
As jy my oorspronklike raad volg en ophou om kode te skryf, sal jy ook vrywillig ophou om aan die skeppingsproses deel te neem. Dit is om hierdie rede dat ek nie aktief uitkontraktering gebruik nie. Outomatiese skep nie, hulle produseer. Goed ontwerpte prosesse spaar baie geld, maar dit bring niks nuuts na ons wêreld nie.
As jy 'n klein span het wat baie vir min geld doen, lyk die idee om op te hou om kode te skryf vir my na 'n slegte loopbaanbesluit. Selfs in monstermaatskappye met hul eindelose regulasies, prosesse en beleide, het jy geen reg om te vergeet hoe om sagteware self te ontwikkel nie. En sagteware-ontwikkeling verander voortdurend. Dit is nou besig om te verander. Onder jou voete! Op hierdie einste sekonde!
Jy het besware. Verstaan. Kom ons luister.
“Rands, ek is op pad na die regisseurstoel toe! As ek aanhou kode skryf, sal niemand glo dat ek kan groei nie.”
Ek wil jou dit vra: sedert jy in jou “Ek is op die punt om CEO te word!” stoel gesit het, het jy opgelet dat die sagteware-ontwikkelingslandskap verander, selfs binne jou maatskappy? As jou antwoord ja is, dan sal ek jou nog 'n vraag vra: hoe presies verander dit en wat gaan jy omtrent hierdie veranderinge doen? As jy "nee" op my eerste vraag geantwoord het, moet jy na 'n ander stoel beweeg, want (ek wed!) die veld van sagteware-ontwikkeling verander op hierdie einste tweede. Hoe gaan jy ooit groei as jy stadig maar seker vergeet hoe om sagteware te ontwikkel?
My raad is om nie jouself te verbind tot die implementering van tonne funksies vir jou volgende produk nie. Jy moet voortdurend stappe doen om op hoogte te bly van hoe jou span sagteware bou. Jy kan dit beide as 'n direkteur en as 'n vise-president doen. Iets anders?
“Ugh, Rande! Maar iemand moet die arbiter wees! Iemand moet die groot prentjie sien. As ek kode skryf, sal ek perspektief verloor."
Jy moet steeds die skeidsregter wees, jy moet nog die besluite uitsaai, en jy moet nog elke Maandagoggend vier keer in die gebou rondloop saam met een van jou ingenieurs om na sy weeklikse "Ons is almal gedoem" rant vir 30 te luister. minute. ! Maar behalwe dit alles, moet jy 'n ingenieursingesteldheid handhaaf, en jy hoef nie 'n voltydse programmeerder te wees om dit te doen nie.
My wenke om 'n ingenieursmentaliteit te handhaaf:
- Gebruik die ontwikkelingsomgewing. Dit beteken dat jy vertroud moet wees met jou span se gereedskap, insluitend die kodeboustelsel, weergawebeheer en programmeertaal. Gevolglik sal jy vlot raak in die taal wat jou span gebruik wanneer hulle oor produkontwikkeling praat. Dit sal jou ook toelaat om voort te gaan om jou gunsteling teksredigeerder te gebruik, wat perfek funksioneer.
- Jy moet enige tyd 'n gedetailleerde argitektoniese diagram kan teken wat jou produk op enige oppervlak beskryf. Nou bedoel ek nie die vereenvoudigde weergawe met drie selle en twee pyle nie. Jy moet die gedetailleerde diagram van die produk ken. Die moeilikste een. Nie sommer enige oulike diagram nie, maar 'n diagram wat moeilik is om te verduidelik. Dit moet 'n kaart wees wat geskik is vir 'n volledige begrip van die produk. Dit verander voortdurend, en jy moet altyd weet hoekom sekere veranderinge plaasgevind het.
- Neem die implementering van een van die funksies oor. Ek krimp letterlik terwyl ek dit skryf, want hierdie punt het baie verborge gevare, maar ek is regtig nie seker dat jy punt #1 en punt #2 kan bereik sonder om te verbind tot die implementering van ten minste een kenmerk nie. Deur self een van die kenmerke te implementeer, sal jy nie net aktief betrokke wees by die ontwikkelingsproses nie, dit sal jou ook toelaat om periodiek oor te skakel van die rol van "Bestuurder in beheer van alles" na die rol van "Man in beheer van die implementering van een van die funksies.” Hierdie nederige en beskeie houding sal jou herinner aan die belangrikheid van klein besluite.
- Ek bewe nog oraloor. Dit blyk dat iemand reeds vir my skree: “Die bestuurder wat die implementering van die funksie op hom geneem het?! (En ek stem saam met hom!) Ja, jy is steeds die bestuurder, wat beteken dit moet een of ander klein funksie wees, okay? Ja, jy het nog baie om te doen. As jy net nie die implementering van die funksie kan aanpak nie, dan het ek 'n bietjie raad vir jou: maak 'n paar foute reg. In hierdie geval sal jy nie die vreugde van skepping voel nie, maar jy sal 'n begrip hê van hoe die produk geskep word, wat beteken dat jy nooit sonder werk gelaat sal word nie.
- Skryf eenheidstoetse. Ek doen dit steeds laat in die produksiesiklus wanneer mense begin mal word. Dink daaraan as 'n gesondheidskontrolelys vir jou produk. Doen dit gereeld.
Weer beswaar?
“Rands, as ek kode skryf, sal ek my span verwar. Hulle sal nie weet wie ek is nie—’n bestuurder of ’n ontwikkelaar.”
Alle regte.
Ja, ek het gesê: "Goed!" Ek is bly jy dink jy kan jou span verwar deur net in die ontwikkelaardam te swem. Dit is eenvoudig: die grense tussen verskillende rolle in sagteware-ontwikkeling is tans baie vaag. Die UI-ouens doen wat in die algemeen JavaScript en CSS-programmering genoem kan word. Ontwikkelaars leer meer en meer oor gebruikerservaring-ontwerp. Mense kommunikeer met mekaar en leer oor goggas, oor diefstal van ander mense se kode, en ook oor die feit dat daar geen goeie rede is vir 'n bestuurder om nie aan hierdie massiewe, globale, kruisbestuiwende inligtingsbacchanalia deel te neem nie.
Wil jy boonop deel wees van 'n span wat uit maklik vervangbare komponente bestaan? Dit sal nie net jou span meer rats maak nie, dit sal elke spanlid die geleentheid gee om die produk en maatskappy vanuit 'n verskeidenheid perspektiewe te sien. Hoe kan jy meer respekteer vir Frank, die rustige ou in beheer van die bouwerk, enigsins as nadat jy die eenvoudige elegansie van sy bou-skrifte gesien het?
Ek wil nie hê jou span moet verward en chaoties raak nie. Inteendeel, ek wil hê jou span moet meer effektief kommunikeer. Ek glo dat as jy betrokke is by die skep van die produk en werk aan kenmerke, jy nader aan jou span sal wees. En nog belangriker, jy sal nader wees aan konstante veranderinge in die sagteware-ontwikkelingsproses binne jou organisasie.
Moenie ophou ontwikkel nie
'n Kollega van my by Borland het my eenkeer verbaal aangeval omdat ek haar 'n "kodeerder" genoem het.
“Rands, die kodeerder is 'n verstandlose masjien! Aap! Die kodeerder doen niks belangrik nie, behalwe om vervelige reëls van nuttelose kode te skryf. Ek is nie ’n kodeerder nie, ek is ’n sagteware-ontwikkelaar!”
Sy was reg, sy sou my aanvanklike raad aan nuwe HUB's gehaat het: "Hou op om kode te skryf!" Nie omdat ek voorstel dat hulle kodeerders is nie, maar meer omdat ek proaktief voorstel dat hulle een van die belangrikste dele van hul werk begin ignoreer: sagteware-ontwikkeling.
So ek het my raad opgedateer. As jy 'n goeie leier wil wees, kan jy ophou om kode te skryf, maar...
Wees buigsaam. Onthou wat dit beteken om 'n ingenieur te wees en moenie ophou sagteware ontwikkel nie.
Oor die skrywer
Michael Lopp is 'n veteraan sagteware-ontwikkelaar wat steeds nie Silicon Valley verlaat het nie. Oor die afgelope 20 jaar het Michael vir 'n verskeidenheid innoverende maatskappye gewerk, insluitend Apple, Netscape, Symantec, Borland, Palantir, Pinterest, en het ook deelgeneem aan 'n begin wat stadig in die vergetelheid gedryf het.
Buiten sy werk bestuur Michael 'n gewilde blog oor tegnologie en bestuur onder die skuilnaam Rands, waar hy idees op die gebied van bestuur met lesers bespreek, kommer uitspreek oor die voortdurende behoefte om sy vinger op die pols te hou, en verduidelik dat, ten spyte van die ruim belonings vir die skep van 'n produk, jou sukses is slegs moontlik danksy jou span. Die blog kan hier gevind word .
Michael woon saam met sy gesin in Redwood, Kalifornië. Hy kry altyd tyd om bergfiets te ry, hokkie te speel en rooiwyn te drink, want gesond is belangriker as besig wees.
» Vir meer inligting oor die boek, besoek asseblief
»
»
Vir Khabrozhiteli 20% afslag op die koepon - Mense bestuur
By betaling vir die papierweergawe van die boek sal 'n elektroniese weergawe van die boek per e-pos gestuur word.
NS: 7% van die prys van die boek gaan na die vertaling van nuwe rekenaarboeke, 'n lys van boeke wat aan die drukkery oorhandig word .
Bron: will.com