Dediĉite al projektestroj (kaj tiuj, kiuj revas fariĝi estroj).
Skribi tunojn da kodo estas malfacile, sed administri homojn estas eĉ pli malfacila! Do vi nur bezonas ĉi tiun libron por lerni kiel fari ambaŭ.
Ĉu eblas kombini amuzajn rakontojn kaj seriozajn lecionojn? Michael Lopp (ankaŭ konata en mallarĝaj cirkloj kiel Rands) sukcesis. Vi trovos fikciajn rakontojn pri fikciaj homoj kun nekredeble rekompencaj (kvankam fikciaj) spertoj. Tiel Rands dividas siajn diversajn, foje strangajn spertojn akiritajn dum la jaroj de laboro en grandaj IT-kompanioj: Apple, Pinterest, Palantir, Netscape, Symantec, ktp.
Ĉu vi estas projektestro? Aŭ ĉu vi volas kompreni, kion faras via malbenita estro la tutan tagon? Rands instruos vin kiel travivi en la Toksa Mondo de Ŝveligitaj Melagroj kaj prosperi en la ĝenerala frenezo de malfunkcie ekstravagancaj homoj. En ĉi tiu stranga komunumo de maniaj cerbuloj estas eĉ pli strangaj estaĵoj - administrantoj, kiuj per mistika organiza rito akiris potencon super la planoj, pensoj kaj bankkontoj de multaj homoj.
Ĉi tiu libro estas malsimila al iu ajn administrado aŭ gvida manuskripto. Michael Lopp kaŝas nenion, li nur rakontas ĝin tia, kia ĝi estas (eble ne ĉiuj rakontoj estu publikigitaj: P). Sed nur tiamaniere vi komprenos kiel travivi kun tia estro, kiel administri geeks kaj nerdojn, kaj kiel alporti "tiun malbenitan projekton" al feliĉa fino!
Eltiraĵo. Inĝenieristiko-penso
Pensoj pri: Ĉu Vi Daŭri Skriban Kodon?
La libro de Rands pri reguloj por manaĝeroj enhavas tre mallongan liston de modernaj administraj "nepraj". La lakonismo de ĉi tiu listo devenas de la fakto, ke la koncepto "devas" estas speco de absoluta, kaj kiam temas pri homoj, estas tre malmultaj absolutaj konceptoj. Sukcesa administra metodo por unu dungito estos vera katastrofo por alia. Ĉi tiu penso estas la unua aĵo en la listo de "nepraĵoj" de la administranto:
Restu fleksebla!
Pensi, ke vi jam scias ĉion, estas tre malbona ideo. En situacio, kie la sola konstanta fakto estas, ke la mondo konstante ŝanĝiĝas, fleksebleco fariĝas la sola ĝusta pozicio.
Paradokse, la dua ero de la listo estas surprize nefleksebla. Tamen, ĉi tiu punkto estas mia persona plej ŝatata ĉar mi kredas, ke ĝi helpas krei la fundamenton por administra kresko. Ĉi tiu alineo legas:
Ĉesu skribi kodon!
En teorio, se vi volas esti administranto, vi devas lerni fidi tiujn, kiuj laboras por vi kaj transdoni la kodigon tute al ili. Ĉi tiu konsilo estas kutime malfacile digestebla, precipe por lastatempe monfaritaj administrantoj. Verŝajne unu el la kialoj, ke ili fariĝis administrantoj, estas pro sia produktiveco en evoluo, kaj kiam aferoj misfunkcias, ilia unua reago estas rebati la kapablojn, kiujn ili havas plenan konfidon, kiu estas ilia kapablo skribi kodon.
Kiam mi vidas, ke nove monfarita administranto "enprofundiĝas" en skribkodon, mi diras al li: "Ni scias, ke vi povas skribi kodon. La demando estas: ĉu vi povas gvidi? Vi ne plu respondecas pri vi sola, vi respondecas pri la tuta teamo; kaj mi volas certigi, ke vi povas igi vian teamon solvi problemojn memstare, sen ke vi mem devas skribi la kodon. Via tasko estas eltrovi kiel grimpi vin mem. Mi ne volas, ke vi estu nur unu, mi volas ke estu multaj kiel vi.”
Bona konsilo, ĉu ne? Skalo. Administrado. Respondeco. Tiaj oftaj zumvortoj. Domaĝe, ke la konsilo estas malĝusta.
Malkorekta?
Jes. La konsilo estas malĝusta! Ne tute malĝusta, sed sufiĉe malĝusta, ke mi devis voki kelkajn iamajn kolegojn kaj peti pardonon: “Memoras tiun mian ŝatatan deklaron pri tio, kiel vi devus ĉesi skribi kodon? Estas malĝuste! Jes... Komencu programon denove. Komencu per Python kaj Ruby. Jes, mi estas serioza! Via kariero dependas de ĝi!"
Kiam mi komencis mian karieron kiel programisto ĉe Borland, mi laboris en la teamo de Paradox Windows, kiu estis grandega teamo. Estis 13 programistoj sole. Se vi aldonas homojn de aliaj teamoj, kiuj ankaŭ konstante laboris pri ŝlosilaj teknologioj por ĉi tiu projekto, kiel la kerna datumbaza motoro kaj kernaj aplikaĵservoj, vi ricevis 50 inĝenierojn rekte implikitajn en la disvolviĝo de ĉi tiu produkto.
Neniu alia teamo, por kiu mi iam laboris, eĉ proksimiĝas al ĉi tiu grandeco. Fakte, kun ĉiu jaro, la nombro da homoj en la teamo, pri kiu mi laboras, iom post iom malpliiĝas. Kio okazas? Ĉu ni programistoj kolektive fariĝas pli kaj pli inteligentaj? Ne, ni nur dividas la ŝarĝon.
Kion faris programistoj dum la lastaj 20 jaroj? Dum ĉi tiu tempo ni skribis aĉan kodon. Maro de kodo! Ni skribis tiom da kodo, ke ni decidis, ke estus bona ideo simpligi ĉion kaj iri malferman fonton.
Feliĉe, danke al Interreto, ĉi tiu procezo nun fariĝis kiel eble plej simpla. Se vi estas programisto, vi povas kontroli ĝin nun! Serĉu vian nomon en Guglo aŭ Github kaj vi vidos kodon, pri kiu vi longe forgesis, sed kiun iu ajn povas trovi. Timiga, ĉu ne? Ĉu vi ne sciis, ke tiu kodo vivas eterne? Jes, li vivas eterne.
La kodo vivas eterne. Kaj bona kodo ne nur vivas eterne, ĝi kreskas ĉar tiuj, kiuj taksas ĝin konstante, certigas, ke ĝi restu freŝa. Ĉi tiu amaso da altkvalita, bone prizorgata kodo helpas redukti la mezan inĝenieran teamgrandecon ĉar ĝi permesas al ni koncentriĝi sur ekzistanta kodo prefere ol skribi novan kodon, kaj fari la laboron kun malpli da homoj kaj en pli mallonga tempokadro.
Ĉi tiu rezonado sonas deprimiĝema, sed la ideo estas, ke ni ĉiuj estas nur amaso da integrigaj aŭtomatoj uzantaj glubendon por kunligi malsamajn pecojn de ekzistantaj aferoj kune por krei iomete malsaman version de la sama afero. Ĉi tio estas klasika pensado inter altrangaj oficuloj, kiuj amas subkontraktadon. "Ĉiu, kiu scipovas uzi Guglon kaj havas iun glubendon, povas fari ĉi tion! Kial do ni pagas multe da mono al niaj maŝinoj?"
Ni pagas al ĉi tiuj administraduloj vere grandan monon, sed ili opinias tian sensencaĵon. Denove, mia ŝlosila punkto estas, ke ekzistas multaj brilaj kaj tre laboremaj programistoj sur nia planedo; ili estas vere brilaj kaj diligentaj, kvankam ili ne pasigis eĉ unu minuton sidante en akredititaj universitatoj. Ho jes, nun estas pli kaj pli da ili!
Mi ne proponas, ke vi komencu zorgi pri via loko nur ĉar iuj brilaj kamaradoj supozeble ĉasas ĝin. Mi sugestas, ke vi komencu zorgi pri tio, ĉar la evoluo de programaro verŝajne moviĝas pli rapide ol vi. Vi laboras dum dek jaroj, kvin el ili kiel manaĝero, kaj vi pensas: "Mi jam scias kiel la programaro estas disvolvita." Jes, vi scias. Adiaŭ…
Ĉesu skribi kodon, sed...
Se vi sekvas mian originalan konsilon kaj ĉesos skribi kodon, vi ankaŭ libervole ĉesos partopreni en la krea procezo. Estas tial ke mi ne aktive uzas subkontraktadon. Aŭtomatoj ne kreas, ili produktas. Bone dezajnitaj procezoj ŝparas multe da mono, sed ili alportas nenion novan al nia mondo.
Se vi havas malgrandan teamon, kiu faras multon por malmulte da mono, tiam la ideo ĉesi skribi kodon ŝajnas al mi malbona kariera decido. Eĉ en monstraj kompanioj kun iliaj senfinaj regularoj, procezoj kaj politikoj, vi ne rajtas forgesi kiel mem disvolvi programaron. Kaj evoluado de programaro konstante ŝanĝiĝas. Ĝi ŝanĝas nun. Sub viaj piedoj! En ĉi tiu sama sekundo!
Vi havas obĵetojn. Komprenu. Ni aŭskultu.
“Rands, mi iras al la seĝo de la direktoro! Se mi daŭre skribas kodon, neniu kredos, ke mi povas kreski."
Mi volas demandi vin ĉi tion: ĉar vi sidis en via seĝo “Mi tuj estos ĉefoficisto!”, ĉu vi rimarkis, ke la pejzaĝo pri programaro disvolvas, eĉ ene de via kompanio? Se via respondo estas jesa, tiam mi demandos al vi alian demandon: kiel ĝuste ĝi ŝanĝiĝas kaj kion vi faros pri ĉi tiuj ŝanĝoj? Se vi respondis "ne" al mia unua demando, tiam vi devas translokiĝi al alia seĝo, ĉar (mi vetas!) la kampo de programaro evoluas en ĉi tiu sama sekundo. Kiel vi iam kreskos se vi malrapide sed certe forgesas kiel disvolvi programaron?
Mia konsilo estas ne devontigi vin efektivigi tunojn da funkcioj por via sekva produkto. Vi devas konstante fari paŝojn por resti sur la supro kiel via teamo konstruas programaron. Vi povas fari tion kaj kiel direktoro kaj kiel vicprezidanto. Io alia?
“Uf, Rands! Sed iu devas esti la arbitro! Iu devas vidi la grandan bildon. Se mi skribas kodon, mi perdos perspektivon."
Vi ankoraŭ devas esti la arbitraciisto, vi ankoraŭ devas elsendi la decidojn, kaj vi ankoraŭ devas ĉirkaŭpaŝi la konstruaĵon kvar fojojn ĉiun lundon matene kun unu el viaj inĝenieroj por aŭskulti lian semajnan "We're all doomed" rabadon por 30. minutoj. ! Sed preter ĉio tio, vi devas konservi inĝenieran pensmanieron, kaj vi ne devas esti plentempa programisto por fari tion.
Miaj konsiloj por konservi inĝenieran menson:
- Uzu la evoluan medion. Ĉi tio signifas, ke vi devus koni la ilojn de via teamo, inkluzive de la koda konstrusistemo, versio-kontrolo kaj programlingvo. Kiel rezulto, vi iĝos flua en la lingvo, kiun via teamo uzas kiam vi parolas pri produkta disvolviĝo. Ĉi tio ankaŭ permesos al vi daŭre uzi vian plej ŝatatan tekstredaktilon, kiu funkcias perfekte.
- Vi devas povi desegni detalan arkitekturan diagramon priskribantan vian produkton sur ajna surfaco iam ajn. Nun mi ne celas la simpligitan version kun tri ĉeloj kaj du sagoj. Vi devas scii la detalan diagramon de la produkto. La plej malfacila. Ne nur ajna bela diagramo, sed diagramo malfacile klarigebla. Ĝi devus esti mapo taŭga por kompleta kompreno de la produkto. Ĝi konstante ŝanĝiĝas, kaj vi ĉiam devus scii kial iuj ŝanĝoj okazis.
- Prenu la efektivigon de unu el la funkcioj. Mi laŭvorte svingas dum mi skribas ĉi tion ĉar ĉi tiu punkto havas multajn kaŝitajn danĝerojn, sed mi vere ne certas, ke vi povas plenumi punkton #1 kaj punkton #2 sen devontiĝi al efektivigo de almenaŭ unu funkcio. Efektivigante unu el la funkcioj mem, vi ne nur aktive partoprenos en la evoluprocezo, ĝi ankaŭ permesos al vi periode ŝanĝi de la rolo de "Manaĝero respondeca pri ĉio" al la rolo de "Viro komisiita de efektivigo de unu". de la funkcioj.” Ĉi tiu humila kaj modesta sinteno memorigos vin pri la graveco de malgrandaj decidoj.
- Mi ankoraŭ tremas ĉie. Ŝajnas, ke iu jam krias al mi: "La administranto, kiu prenis sur sin la efektivigon de la funkcio?!" (Kaj mi konsentas kun li!) Jes, vi ankoraŭ estas la manaĝero, kio signifas, ke ĝi devus esti iu malgranda funkcio, ĉu bone? Jes, vi ankoraŭ havas multon por fari. Se vi simple ne povas preni sur sin la efektivigon de la funkcio, tiam mi havas kelkajn rezervajn konsilojn por vi: ripari kelkajn erarojn. En ĉi tiu kazo, vi ne sentos la ĝojon de kreado, sed vi komprenos kiel la produkto estas kreita, kio signifas, ke vi neniam restos sen laboro.
- Skribu unuotestojn. Mi ankoraŭ faras tion malfrue en la produktadociklo kiam homoj komencas freneziĝi. Pensu pri ĝi kiel sankontrolisto por via produkto. Faru ĉi tion ofte.
Denove protesto?
"Rands, se mi skribas kodon, mi konfuzos mian teamon. Ili ne scios, kiu mi estas—manaĝero aŭ programisto."
Bone.
Jes, mi diris: "Bone!" Mi ĝojas, ke vi pensas, ke vi povas konfuzi vian teamon nur naĝante en la ellaboranto-lageto. Ĝi estas simpla: la limoj inter malsamaj roloj en programaro-disvolviĝo estas nuntempe tre malklaraj. La UI-uloj faras tion, kion oni povas larĝe nomi JavaScript kaj CSS-programadon. Programistoj lernas pli kaj pli pri uzanta sperto-dezajno. Homoj komunikas unu kun la alia kaj lernas pri cimoj, pri ŝtelo de alies kodo, kaj ankaŭ pri tio, ke ne ekzistas bona kialo por administranto ne partopreni en ĉi tiu amasa, tutmonda, krucpolenanta informa bakanalo.
Krome, ĉu vi volas esti parto de teamo konsistanta el facile anstataŭeblaj komponantoj? Ĉi tio ne nur igos vian teamon pli lerta, ĝi donos al ĉiu teamano la ŝancon vidi la produkton kaj kompanion el diversaj perspektivoj. Kiel vi povas respekti Frank, la trankvilan ulon, kiu respondecas pri la konstruoj, same ol post vidi la simplan elegantecon de siaj konstruskriptoj?
Mi ne volas, ke via teamo fariĝu konfuzita kaj kaosa. Male, mi volas, ke via teamo komunikiĝu pli efike. Mi kredas, ke se vi okupiĝas pri kreado de la produkto kaj pri laboro pri funkcioj, vi estos pli proksima al via teamo. Kaj pli grave, vi estos pli proksima al konstantaj ŝanĝoj en la procezo de disvolvado de programaro ene de via organizo.
Ne ĉesu disvolviĝi
Mia kolego ĉe Borland unufoje parole atakis min pro tio, ke li nomis ŝin "kodisto".
“Rands, la kodilo estas sensenca maŝino! Simio! La kodilo faras nenion gravan krom skribi enuigajn liniojn de senutila kodo. Mi ne estas kodisto, mi estas programisto!”
Ŝi pravis, ŝi malamus mian komencan konsilon al novaj ĉefoficistoj: "Ĉesu skribi kodon!" Ne ĉar mi sugestas, ke ili estas kodistoj, sed pli ĉar mi proaktive sugestas, ke ili komencu ignori unu el la plej gravaj partoj de sia laboro: programaro.
Do mi ĝisdatigis mian konsilon. Se vi volas esti bona gvidanto, vi povas ĉesi skribi kodon, sed...
Estu fleksebla. Memoru, kion signifas esti inĝeniero kaj ne ĉesu disvolvi programaron.
Pri la aŭtoro
Michael Lopp estas veterana programisto, kiu ankoraŭ ne forlasis Silicon Valley. Dum la pasintaj 20 jaroj, Mikaelo laboris por diversaj novigaj kompanioj, inkluzive de Apple, Netscape, Symantec, Borland, Palantir, Pinterest, kaj ankaŭ partoprenis noventreprenon, kiu malrapide flosis en forgeson.
Ekster laboro, Mikaelo prizorgas popularan blogon pri teknologio kaj administrado sub la pseŭdonimo Rands, kie li diskutas ideojn en la kampo de administrado kun legantoj, esprimas zorgon pri la konstanta bezono teni la fingron sur la pulso, kaj klarigas tion, malgraŭ la malavaraj rekompencoj por krei produkton, via sukceso nur eblas danke al via teamo. La blogo troviĝas ĉi tie .
Mikaelo vivas kun sia familio en Redwood, Kalifornio. Li ĉiam trovas tempon por montbiciklo, ludi hokeon kaj trinki ruĝan vinon, ĉar esti sana estas pli grava ol esti okupata.
» Pliaj detaloj pri la libro troveblas ĉe
»
»
Por Khabrozhiteley 20% rabato uzante kuponon - Administrado de Homoj
Post pago de la papera versio de la libro, elektronika versio de la libro estos sendita retpoŝte.
PS: 7% de la prezo de la libro iros al la traduko de novaj komputilaj libroj, listo de libroj transdonitaj al la presejo .
fonto: www.habr.com