Tawiisd oan projektmanagers (en dyjingen dy't dreame fan baas wurde).
Tonnen koade skriuwe is dreech, mar minsken beheare is noch dreger! Dat jo dit boek gewoan nedich hawwe om te learen hoe't jo beide kinne dwaan.
Is it mooglik om grappige ferhalen en serieuze lessen te kombinearjen? Michael Lopp (ek yn smelle rûnten bekend as Rands) slagge. Jo sille fiktive ferhalen fine oer fiktive minsken mei ongelooflijk beleanjend (alhoewol fiktive) ûnderfiningen. Dit is hoe't Rands syn farieare, soms frjemde ûnderfiningen dielt dy't yn 'e rin fan' e jierren opdien hat fan wurkjen yn grutte IT-bedriuwen: Apple, Pinterest, Palantir, Netscape, Symantec, ensfh.
Binne jo in projektmanager? Of wolst begripe wat dyn ferrekte baas de hiele dei docht? Rands sil jo leare hoe't jo kinne oerlibje yn 'e Toxic World of Inflated Turkeys en bloeie yn' e algemiene waansin fan dysfunksjoneel flamboyante minsken. Yn dizze frjemde mienskip fan maniakale brainiacs binne d'r noch frjemder skepsels - managers dy't troch in mystyk organisatoarysk ritueel de macht krigen hawwe oer de plannen, tinzen en bankrekken fan in protte minsken.
Dit boek is oars as in manuskript fan management of liederskip. Michael Lopp ferberget neat, hy fertelt it gewoan sa't it is (miskien moatte net alle ferhalen iepenbier makke wurde: P). Mar allinich op dizze manier sille jo begripe hoe't jo kinne oerlibje mei sa'n baas, hoe't jo geeks en nerds beheare, en hoe't jo "dat ferdomde projekt" ta in lokkich ein bringe kinne!
Úttreksel. Engineering mentaliteit
Gedachten oer: Moatte jo trochgean mei skriuwen fan koade?
Rands syn boek oer regels foar managers befettet in hiel koarte list fan moderne bestjoerlike "must-dos." It lakonisme fan dizze list komt út it feit dat it begryp "moat" in soarte fan absolute is, en as it giet om minsken, binne d'r heul pear absolute begripen. In suksesfolle behearmetoade foar ien meiwurker sil in echte ramp wêze foar in oar. Dizze gedachte is it earste item op 'e "must-do" list fan de manager:
Bliuw fleksibel!
Tinke dat jo alles al witte is in heul min idee. Yn in situaasje dêr't it ienige konstante feit is dat de wrâld hieltyd feroaret, wurdt fleksibiliteit de ienige juste posysje.
Paradoksaal genôch is it twadde item op 'e list ferrassend net fleksibel. Dit punt is lykwols myn persoanlike favoryt, om't ik leau dat it helpt om de basis te meitsjen foar managementgroei. Dizze paragraaf lêst:
Stopje mei skriuwen fan koade!
Yn teory, as jo in manager wolle wêze, moatte jo leare om dejingen te fertrouwen dy't foar jo wurkje en de kodearring folslein oan har oerjaan. Dit advys is meastentiids lestich te fertarren, foaral foar nij minted managers. Wierskynlik is ien fan 'e redenen dat se managers wurden binne fanwegen har produktiviteit yn ûntwikkeling, en as dingen ferkeard geane, is har earste reaksje werom te fallen op 'e feardichheden wêryn se folslein fertrouwen hawwe, dat is har fermogen om koade te skriuwen.
As ik sjoch dat in nij slein manager "sinkt" yn it skriuwen fan koade, sis ik tsjin him: "Wy witte dat jo koade skriuwe kinne. De fraach is: kinne jo liede? Do bist net mear ferantwurdlik foar dysels allinne, do bist ferantwurdlik foar it hiele team; en ik wol der foar soargje dat jo jo team krije kinne om problemen op har eigen op te lossen, sûnder dat jo de koade sels moatte skriuwe. Jo taak is om út te finen hoe't jo sels skaalje kinne. Ik wol net dat jo mar ien binne, ik wol dat d'r in protte binne lykas jo."
Goed advys, krekt? Skaal. Behear. Ferantwurdlikens. Sokke gewoane buzzwords. It is spitich dat it advys ferkeard is.
Net goed?
Ja. It advys is ferkeard! Net hielendal ferkeard, mar ferkeard genôch dat ik wat âld-kollega's skilje moast en my ekskús meitsje moast: “Onthâld dy favorite útspraak fan my oer hoe’t je ophâlde moatte mei it skriuwen fan koade? It is ferkeard! Ja... Begjin wer mei programmearjen. Begjin mei Python en Ruby. Ja, ik bin serieus! Jo karriêre hinget derfan ôf!"
Doe't ik myn karriêre begon as softwareûntwikkelder by Borland, wurke ik oan it Paradox Windows-team, dat in enoarm team wie. D'r wiene allinich 13 applikaasje-ûntwikkelders. As jo minsken tafoegje fan oare teams dy't ek konstant wurken oan wichtige technologyen foar dit projekt, lykas de kearndatabasemotor en kearnapplikaasjetsjinsten, hawwe jo 50 yngenieurs direkt belutsen by de ûntwikkeling fan dit produkt.
Gjin oar team wêrfoar ik oait wurke haw, komt sels tichtby dizze grutte. Yn feite, mei elk jier foarby, it oantal minsken yn it team dêr't ik wurkje oan wurdt stadichoan ôfnimme. Wat is d'r oan 'e hân? Binne wy ûntwikkelders kollektyf slimmer en tûker? Nee, wy diele gewoan de lading.
Wat hawwe ûntwikkelders dien foar de lêste 20 jier? Yn dizze tiid hawwe wy in shitload koade skreaun. See fan koade! Wy hawwe safolle koade skreaun dat wy besletten dat it in goed idee soe wêze om alles te ferienfâldigjen en iepen boarne te gean.
Gelokkich, troch it ynternet, is dit proses no sa ienfâldich mooglik wurden. As jo in softwareûntwikkelder binne, kinne jo it no direkt kontrolearje! Sykje jo namme op Google of Github en jo sille koade sjen dy't jo lang fergetten binne, mar dy't elkenien kin fine. Scary, krekt? Wisten jo net dat koade foar altyd libbet? Ja, hy libbet foar altyd.
De koade libbet foar altyd. En goede koade libbet net allinich foar altyd, it groeit om't dejingen dy't it wurdearje konstant soargje dat it fris bliuwt. Dizze stapel fan heechweardige, goed ûnderhâlden koade helpt de gemiddelde grutte fan engineeringteam te ferminderjen, om't it ús yn steat stelt om te fokusjen op besteande koade ynstee fan nije koade te skriuwen, en it wurk dien te meitsjen mei minder minsken en yn in koartere tiidframe.
Dizze line fan redenearring klinkt deprimearjend, mar it idee is dat wy allegear gewoan in boskje yntegraasjeautomaten binne dy't duct tape brûke om ferskate bits fan besteande dingen byinoar te ferbinen om in wat oare ferzje fan itselde ding te meitsjen. Dit is in klassike tinkline ûnder senioaren dy't fan outsourcing hâlde. "Elkenien dy't wit hoe Google te brûken en wat ducttape hat, kin dit dwaan! Wêrom betelje wy dan in soad jild oan ús masines?"
Wy betelje dizze management guys echt grutte jild, mar se tinke sokke ûnsin. Nochris is myn kaaipunt dat d'r in protte briljante en heul hurd wurkjende ûntwikkelders op ús planeet binne; se binne wirklik briljant en iverich, hoewol se net ien minút hawwe bestege oan akkrediteare universiteiten. O ja, no binne der hieltyd mear!
Ik stel net foar dat jo begjinne te soargen oer jo plak krekt omdat guon briljante kameraden binne nei alle gedachten op jacht foar it. Ik stel foar dat jo der soargen oer begjinne, om't de evolúsje fan softwareûntwikkeling wierskynlik rapper beweecht dan jo binne. Jo wurkje al tsien jier, fiif fan harren as manager, en jo tinke: "Ik wit al hoe't software ûntwikkele wurdt." Ja, do witst wol. Doei…
Stopje mei skriuwen fan koade, mar ...
As jo myn orizjinele advys folgje en ophâlde mei it skriuwen fan koade, sille jo ek frijwillich stopje mei dielnimmen oan it skeppingsproses. It is om dizze reden dat ik outsourcing net aktyf brûke. Automaten meitsje net, se produsearje. Goed ûntwurpen prosessen besparje in soad jild, mar se bringe neat nij oan ús wrâld.
As jo in lyts team hawwe dat in soad docht foar lyts jild, dan liket it idee om te stopjen mei skriuwen fan koade foar my in min karriêrebeslút. Sels yn meunsterbedriuwen mei har einleaze regeljouwing, prosessen en belied, hawwe jo gjin rjocht om te ferjitten hoe't jo sels software ûntwikkelje. En softwareûntwikkeling feroaret konstant. It feroaret no. Under dyn fuotten! Op dizze sekonde!
Jo hawwe beswieren. Begripe. Litte wy harkje.
“Rands, ik bin ûnderweis nei de direkteurstoel! As ik koade skriuw, sil gjinien leauwe dat ik groeie kin."
Ik wol jo dit freegje: sûnt jo sieten yn jo "Ik bin op it punt CEO te wurden!" stoel, hawwe jo opmurken dat it lânskip foar softwareûntwikkeling feroaret, sels binnen jo bedriuw? As jo antwurd ja is, dan sil ik jo in oare fraach stelle: hoe feroaret it krekt en wat sille jo dwaan oan dizze feroarings? As jo "nee" antwurde op myn earste fraach, dan moatte jo ferhúzje nei in oare stoel, om't (ik wedde!) It fjild fan softwareûntwikkeling feroaret op dizze heul twadde. Hoe sille jo oait groeie as jo stadich mar wis ferjitte hoe't jo software ûntwikkelje kinne?
Myn advys is om josels net yn te setten foar it ymplementearjen fan tonnen funksjes foar jo folgjende produkt. Jo moatte konstant stappen nimme om op 'e hichte te bliuwen fan hoe't jo team software bouwt. Jo kinne dit dwaan sawol as direkteur en as fise-presidint. Wat oars?
"Och, Rands! Mar immen moat de skiedsrjochter wêze! Immen moat it grutte byld sjen. As ik koade skriuw, sil ik perspektyf ferlieze."
Jo moatte noch de skiedsrjochter wêze, jo moatte de besluten noch útstjoere, en jo moatte noch elke moandeitemoarn fjouwer kear om it gebou rinne mei ien fan jo yngenieurs om te harkjen nei syn wyklikse "We're all doomed" rant foar 30 minuten.! Mar boppe dat alles moatte jo in technysk tinken behâlde, en jo hoege gjin fulltime programmeur te wêzen om dat te dwaan.
Myn tips foar it behâld fan in technykmentaliteit:
- Brûk de ûntwikkelingsomjouwing. Dit betsjut dat jo bekend moatte wêze mei de ark fan jo team, ynklusyf it koadebouwsysteem, ferzjekontrôle en programmeartaal. As resultaat sille jo bekwaam wurde yn 'e taal dy't jo team brûkt as it praat oer produktûntwikkeling. Hjirmei kinne jo ek trochgean mei it brûken fan jo favorite tekstbewurker, dy't perfekt funksjonearret.
- Jo moatte op elk momint in detaillearre arsjitektoanysk diagram kinne tekenje dat jo produkt beskriuwt op elk oerflak. No bedoel ik net de ferienfâldige ferzje mei trije sellen en twa pylken. Jo moatte it detaillearre diagram fan it produkt kenne. De dreechste. Net allinich in leuk diagram, mar in diagram dat min te ferklearjen is. It moat in kaart wêze geskikt foar in folslein begryp fan it produkt. It feroaret konstant, en jo moatte altyd witte wêrom't bepaalde feroarings barde.
- Nim de útfiering fan ien fan 'e funksjes oer. Ik bin letterlik wincing as ik skriuw dit omdat dit punt hat in protte ferburgen gefaren, mar ik bin echt net wis op dat jo kinne berikke punt # 1 en punt # 2 sûnder commit nei in útfiere op syn minst ien funksje. Troch ien fan 'e funksjes sels te ymplementearjen, sille jo net allinich aktyf belutsen wêze by it ûntwikkelingsproses, it sil jo ek tastean om periodyk oer te skeakeljen fan' e rol fan "Manager yn lieding oer alles" nei de rol fan "Man dy't ferantwurdlik is foar it útfieren fan ien fan de funksjes." Dizze beskieden en beskieden hâlding sil jo herinnerje oan it belang fan lytse besluten.
- Ik trilje noch oeral. It liket derop dat immen al tsjin my ropt: "De manager dy't de útfiering fan 'e funksje op him naam?!" (En ik bin it mei him iens!) Ja, jo binne noch altyd de manager, wat betsjut dat it wat lytse funksje wêze moat, goed? Ja, jo hawwe noch in protte te dwaan. As jo de ymplemintaasje fan 'e funksje gewoan net kinne nimme, dan haw ik wat ekstra advys foar jo: reparearje wat bugs. Yn dit gefal sille jo de freugde fan 'e skepping net fiele, mar jo sille in begryp hawwe fan hoe't it produkt is makke, wat betsjut dat jo noait sûnder wurk wurde ferlitten.
- Skriuw ienheid tests. Ik doch dit noch let yn 'e produksjesyklus as minsken begjinne te wurden gek. Tink oan it as in sûnens checklist foar jo produkt. Doch dit faak.
Nochris beswier?
"Rands, as ik koade skriuw, sil ik myn ploech betize. Se sille net witte wa't ik bin - in manager as in ûntwikkelder.
Goed.
Ja, ik sei: "Oké!" Ik bin bliid dat jo tinke dat jo jo team kinne betize troch gewoan yn 'e ûntwikkelfiver te swimmen. It is ienfâldich: de grinzen tusken ferskate rollen yn softwareûntwikkeling binne op it stuit heul wazig. De UI-jonges dogge wat yn 't algemien JavaScript- en CSS-programmearring kin wurde neamd. Untwikkelders leare mear en mear oer ûntwerp fan brûkersûnderfining. Minsken kommunisearje mei elkoar en leare oer bugs, oer stellerij fan koade fan oare minsken, en ek oer it feit dat d'r gjin goede reden is foar in manager om net mei te dwaan oan dizze massale, globale, krúsbestuivende ynformaasjebacchanalia.
Trouwens, wolle jo diel útmeitsje fan in team besteande út maklik te ferfangen komponinten? Dit sil jo team net allinich flugger meitsje, it sil elk teamlid de kâns jaan om it produkt en bedriuw út in ferskaat oan perspektiven te sjen. Hoe kinne jo komme om Frank te respektearjen, de kalme man dy't ferantwurdlik is foar de bou, net mear dan nei't jo de ienfâldige elegânsje fan syn bouskripts sjoen hawwe?
Ik wol net dat jo team betize en chaotysk wurdt. Krektoarsom, ik wol dat jo team effektiver kommunisearje. Ik leau dat as jo belutsen binne by it meitsjen fan it produkt en wurkje oan funksjes, jo tichter by jo team sille wêze. En noch wichtiger, jo sille tichter by konstante feroaringen wêze yn it softwareûntwikkelingsproses binnen jo organisaasje.
Net ophâlde te ûntwikkeljen
In kollega fan my by Borland foel my ienris verbaal oan omdat ik har in "koder" neamde.
"Rands, de kodearder is in gedachteleaze masine! Aap! De kodearder docht neat wichtich, útsein it skriuwen fan saaie rigels fan nutteleaze koade. Ik bin gjin kodearder, ik bin in softwareûntwikkelder!"
Se hie gelyk, se soe myn earste advys oan nije CEO's haat hawwe: "Stopje mei skriuwen fan koade!" Net om't ik suggerearje dat se kodearders binne, mar mear om't ik proaktyf suggerearje dat se ien fan 'e wichtichste dielen fan har wurk begjinne te negearjen: softwareûntwikkeling.
Dat ik haw myn advys bywurke. As jo in goede lieder wolle wêze, kinne jo ophâlde mei skriuwen fan koade, mar ...
Wês fleksibel. Unthâld wat it betsjut om in yngenieur te wêzen en stopje net mei it ûntwikkeljen fan software.
Oer de skriuwer
Michael Lopp is in feteraan softwareûntwikkelder dy't Silicon Valley noch net hat ferlitten. Yn 'e ôfrûne 20 jier hat Michael wurke foar in ferskaat oan ynnovative bedriuwen, wêrûnder Apple, Netscape, Symantec, Borland, Palantir, Pinterest, en hat ek meidien oan in opstart dy't stadichoan yn it ferjit sweeve.
Bûten it wurk rint Michael in populêr blog oer technology en management ûnder it skûlnamme Rands, dêr't er ideeën op it mêd fan behear mei lêzers besprekt, soargen útdrukt oer de konstante needsaak om de finger oan 'e pols te hâlden, en ferklearret dat, nettsjinsteande de romhertich beleannings foar it meitsjen fan in produkt, dyn súkses is allinnich mooglik tank oan dyn ploech. It blog is hjir te finen .
Michael wennet mei syn famylje yn Redwood, Kalifornje. Hy fynt altyd tiid om te mountainbiken, hockey te spyljen en reade wyn te drinken, want sûn wêze is wichtiger as drok.
» Mear details oer it boek is te finen op
»
»
Foar Khabrozhiteley 20% koarting mei coupon - Behear fan minsken
By betelling foar de papieren ferzje fan it boek wurdt in elektroanyske ferzje fan it boek per e-post ferstjoerd.
PS: 7% fan de priis fan it boek giet nei de oersetting fan nije kompjûterboeken, in list mei boeken oerlevere oan de drukkerij .
Boarne: www.habr.com