Dedikuar menaxherëve të projektit (dhe atyre që ëndërrojnë të bëhen shefa).
Shkrimi i mijëra kodeve është i vështirë, por menaxhimi i njerëzve është edhe më i vështirë! Kështu që ju duhet vetëm ky libër për të mësuar se si t'i bëni të dyja.
A është e mundur të kombinohen histori qesharake dhe mësime serioze? Michael Lopp (i njohur gjithashtu në qarqe të ngushta si Rands) ia doli. Do të gjeni histori fiktive për njerëz të trilluar me përvoja tepër shpërblyese (megjithëse të trilluara). Kështu ndan Rands përvojat e tij të ndryshme, ndonjëherë të çuditshme, të fituara gjatë viteve të punës në korporatat e mëdha të IT: Apple, Pinterest, Palantir, Netscape, Symantec, etj.
Jeni menaxher projekti? Apo doni të kuptoni se çfarë bën shefi juaj i mallkuar gjatë gjithë ditës? Rands do t'ju mësojë se si të mbijetoni në botën toksike të gjelave të fryra dhe të lulëzoni në çmendurinë e përgjithshme të njerëzve jofunksionalë. Në këtë komunitet të çuditshëm të trurit maniakë ka krijesa edhe më të çuditshme - menaxherë që, përmes një rituali organizativ mistik, kanë fituar pushtet mbi planet, mendimet dhe llogaritë bankare të shumë njerëzve.
Ky libër është ndryshe nga çdo dorëshkrim i menaxhimit apo udhëheqjes. Michael Lopp nuk fsheh asgjë, thjesht e tregon ashtu siç është (ndoshta jo të gjitha historitë duhen bërë publike: P). Por vetëm në këtë mënyrë do të kuptoni se si të mbijetoni me një shef të tillë, si të menaxhoni magjepsësit dhe budallenjtë dhe si ta çoni "atë projekt të mallkuar" në një fund të lumtur!
Fragment. Mentaliteti inxhinierik
Mendime mbi: A duhet të vazhdoni të shkruani kodin?
Libri i Rands mbi rregullat për menaxherët përmban një listë shumë të shkurtër të "dus-dos" menaxheriale moderne. Lakonizmi i kësaj liste buron nga fakti se koncepti "duhet" është një lloj absolut, dhe kur bëhet fjalë për njerëzit, ka shumë pak koncepte absolute. Një metodë e suksesshme e menaxhimit për një punonjës do të jetë një fatkeqësi për një tjetër. Ky mendim është pika e parë në listën e menaxherit "të cilat duhet bërë":
Qëndroni fleksibël!
Të mendosh se tashmë di gjithçka është një ide shumë e keqe. Në një situatë ku i vetmi fakt konstant është se bota po ndryshon vazhdimisht, fleksibiliteti bëhet pozicioni i vetëm i saktë.
Në mënyrë paradoksale, pika e dytë në listë është çuditërisht jo fleksibël. Megjithatë, kjo pikë është e preferuara ime personale, sepse besoj se ndihmon në krijimin e bazës për rritjen menaxheriale. Ky paragraf thotë:
Ndaloni së shkruari kodin!
Në teori, nëse doni të jeni menaxher, duhet të mësoni t'u besoni atyre që punojnë për ju dhe t'ua dorëzoni kodimin tërësisht atyre. Kjo këshillë është zakonisht e vështirë për t'u tretur, veçanërisht për menaxherët e sapokrijuar. Ndoshta një nga arsyet që ata u bënë menaxherë është për shkak të produktivitetit të tyre në zhvillim, dhe kur gjërat shkojnë keq, reagimi i tyre i parë është të kthehen në aftësitë në të cilat kanë besim të plotë, që është aftësia e tyre për të shkruar kod.
Kur shoh që një menaxher i sapoformuar “zhytet” në shkrimin e kodit, i them: “Ne e dimë që mund të shkruash kod. Pyetja është: a mund të drejtosh? Ju nuk jeni më përgjegjës vetëm për veten tuaj, ju jeni përgjegjës për të gjithë ekipin; dhe unë dua të sigurohem që ju mund ta detyroni ekipin tuaj të zgjidhë problemet vetë, pa pasur nevojë të shkruani vetë kodin. Detyra juaj është të kuptoni se si të shkallëzoni veten. Unë nuk dua që ju të jeni vetëm një, unë dua që të ketë shumë si ju.”
Këshillë e mirë, apo jo? Shkalla. Menaxhimi. Përgjegjësia. Fjalë të tilla të zakonshme. Është për të ardhur keq që këshilla është e gabuar.
E pasaktë?
Po. Këshilla është e gabuar! Jo krejtësisht e gabuar, por mjaft e gabuar saqë m'u desh të telefonoja disa ish-kolegë dhe të kërkoja falje: “E mbani mend atë deklaratën time të preferuar se si duhet të ndaloni së shkruari kode? Është Gabim! Po... Filloni përsëri programimin. Filloni me Python dhe Ruby. Po, e kam seriozisht! Karriera juaj varet nga kjo!”
Kur fillova karrierën time si zhvillues softuerësh në Borland, punova në ekipin e Paradox Windows, i cili ishte një ekip i madh. Vetëm 13 zhvillues aplikacionesh ishin. Nëse shtoni njerëz nga ekipe të tjera të cilët gjithashtu po punonin vazhdimisht në teknologjitë kryesore për këtë projekt, si motori bazë i bazës së të dhënave dhe shërbimet e aplikacionit bazë, do të merrni 50 inxhinierë të përfshirë drejtpërdrejt në zhvillimin e këtij produkti.
Asnjë ekip tjetër për të cilin kam punuar ndonjëherë nuk i afrohet kësaj madhësie. Në fakt, me çdo vit që kalon, numri i njerëzve në ekipin ku unë punoj po zvogëlohet gradualisht. Çfarë po ndodh? A jemi ne zhvilluesit kolektivisht duke u bërë më të zgjuar dhe më të zgjuar? Jo, ne thjesht po ndajmë ngarkesën.
Çfarë kanë bërë zhvilluesit për 20 vitet e fundit? Gjatë kësaj kohe kemi shkruar një sasi të madhe kodesh. Deti i kodit! Shkruam aq shumë kod saqë vendosëm se do të ishte një ide e mirë të thjeshtonim gjithçka dhe të shkonim me burim të hapur.
Për fat të mirë, falë internetit, ky proces tani është bërë sa më i thjeshtë. Nëse jeni një zhvillues softuerësh, mund ta kontrolloni menjëherë! Kërkoni emrin tuaj në Google ose Github dhe do të shihni kodin që e keni harruar prej kohësh, por që çdokush mund ta gjejë. E frikshme, apo jo? A nuk e dinit që kodi jeton përgjithmonë? Po, ai jeton përgjithmonë.
Kodi jeton përgjithmonë. Dhe kodi i mirë jo vetëm që jeton përgjithmonë, por rritet sepse ata që e vlerësojnë vazhdimisht sigurohen që ai të mbetet i freskët. Ky grumbull kodi me cilësi të lartë, të mirëmbajtur mirë ndihmon në zvogëlimin e madhësisë mesatare të ekipit inxhinierik sepse na lejon të përqendrohemi në kodin ekzistues në vend që të shkruajmë kodin e ri dhe të kryejmë punën me më pak njerëz dhe në një afat më të shkurtër kohor.
Kjo linjë arsyetimi tingëllon dëshpëruese, por ideja është se ne të gjithë jemi vetëm një grumbull automatash integrimi që përdorin shirit ngjitës për të lidhur pjesë të ndryshme të gjërave ekzistuese së bashku për të krijuar një version paksa të ndryshëm të së njëjtës gjë. Kjo është një linjë klasike e të menduarit midis drejtuesve të lartë që e duan kontraktimin. “Kushdo që di të përdorë Google dhe ka disa shirit ngjitës mund ta bëjë këtë! Atëherë pse po paguajmë shumë para për makinat tona?”
Ne u paguajmë këtyre drejtuesve para shumë të mëdha, por ata mendojnë një marrëzi të tillë. Edhe një herë, pika ime kryesore është se ka shumë zhvillues të shkëlqyer dhe shumë punëtorë në planetin tonë; ata janë vërtet të shkëlqyeshëm dhe të zellshëm, megjithëse nuk kanë kaluar asnjë minutë ulur në universitetet e akredituara. Oh po, tani ka gjithnjë e më shumë prej tyre!
Unë nuk sugjeroj që të filloni të shqetësoheni për vendin tuaj vetëm sepse disa shokë të shkëlqyer gjoja po e kërkojnë atë. Unë sugjeroj që të filloni të shqetësoheni për këtë sepse evolucioni i zhvillimit të softuerit ndoshta po ecën më shpejt se ju. Ju keni punuar për dhjetë vjet, pesë prej tyre si menaxher, dhe mendoni: "Unë tashmë e di se si zhvillohet softueri." Po, ju e dini. Mirupafshim…
Ndaloni së shkruari kode, por...
Nëse ndiqni këshillën time origjinale dhe ndaloni së shkruari kodin, do të ndaloni gjithashtu vullnetarisht pjesëmarrjen në procesin e krijimit. Është për këtë arsye që unë nuk e përdor në mënyrë aktive kontraktimin. Automat nuk krijojnë, ato prodhojnë. Proceset e dizajnuara mirë kursejnë shumë para, por ato nuk sjellin asgjë të re në botën tonë.
Nëse keni një ekip të vogël që bën shumë për pak para, atëherë ideja e ndalimit të shkrimit të kodit më duket si një vendim i keq për karrierën. Edhe në kompanitë përbindësh me rregulloret, proceset dhe politikat e tyre të pafundme, nuk keni të drejtë të harroni se si të zhvilloni vetë softuer. Dhe zhvillimi i softuerit po ndryshon vazhdimisht. Po ndryshon tani. Nën këmbët tuaja! Në këtë sekondë!
Keni kundërshtime. Kuptoni. Le të dëgjojmë.
“Rands, po shkoj drejt karriges së drejtorit! Nëse vazhdoj të shkruaj kode, askush nuk do të besojë se mund të rritem.”
Unë dua t'ju pyes këtë: që kur jeni ulur në karrigen tuaj "Unë jam gati të jem CEO!", a e keni vënë re se peizazhi i zhvillimit të softuerit po ndryshon, edhe brenda kompanisë suaj? Nëse përgjigja juaj është po, atëherë unë do t'ju bëj një pyetje tjetër: si po ndryshon saktësisht dhe çfarë do të bëni për këto ndryshime? Nëse i jeni përgjigjur "jo" pyetjes sime të parë, atëherë duhet të kaloni në një karrige tjetër, sepse (vë bast!) fusha e zhvillimit të softuerit po ndryshon në këtë sekondë. Si do të rriteni ndonjëherë nëse harroni ngadalë por me siguri se si të zhvilloni softuer?
Këshilla ime është të mos angazhoheni për të zbatuar shumë veçori për produktin tuaj të ardhshëm. Ju duhet të ndërmerrni vazhdimisht hapa për të qëndruar në krye të mënyrës se si ekipi juaj po ndërton softuer. Këtë mund ta bëni edhe si drejtor edhe si nënkryetar. Diçka tjetër?
“Uh, Rands! Por dikush duhet të jetë arbitri! Dikush duhet të shohë pamjen e madhe. Nëse shkruaj kod, do të humbas perspektivën."
Ju ende duhet të jeni arbitri, ju duhet të transmetoni vendimet dhe duhet të ecni rreth ndërtesës katër herë çdo të hënë në mëngjes me një nga inxhinierët tuaj për të dëgjuar zhurmën e tij javore "Ne të gjithë jemi të dënuar" për 30. minuta. ! Por përtej gjithë kësaj, ju duhet të mbani një mentalitet inxhinierik dhe nuk duhet të jeni një programues me kohë të plotë për ta bërë këtë.
Këshillat e mia për të mbajtur një mentalitet inxhinierik:
- Përdorni mjedisin e zhvillimit. Kjo do të thotë që ju duhet të njiheni me mjetet e ekipit tuaj, duke përfshirë sistemin e krijimit të kodit, kontrollin e versionit dhe gjuhën e programimit. Si rezultat, do të bëheni të aftë në gjuhën që përdor ekipi juaj kur flet për zhvillimin e produktit. Kjo do t'ju lejojë gjithashtu të vazhdoni të përdorni redaktuesin tuaj të preferuar të tekstit, i cili funksionon në mënyrë të përsosur.
- Ju duhet të jeni në gjendje të vizatoni një diagram të detajuar arkitektonik që përshkruan produktin tuaj në çdo sipërfaqe në çdo kohë. Tani nuk e kam fjalën për versionin e thjeshtuar me tre qeliza dhe dy shigjeta. Ju duhet të dini diagramin e detajuar të produktit. Më e vështira. Jo vetëm një diagram i lezetshëm, por një diagram që është e vështirë të shpjegohet. Duhet të jetë një hartë e përshtatshme për një kuptim të plotë të produktit. Ai ndryshon vazhdimisht, dhe ju duhet të dini gjithmonë pse kanë ndodhur disa ndryshime.
- Merrni përsipër zbatimin e një prej funksioneve. Unë jam fjalë për fjalë gënjeshtar ndërsa e shkruaj këtë, sepse kjo pikë ka shumë rreziqe të fshehura, por nuk jam vërtet i sigurt se mund të përmbushni pikën #1 dhe pikën #2 pa u angazhuar për të zbatuar të paktën një veçori. Duke zbatuar vetë një nga veçoritë, jo vetëm që do të përfshiheni aktivisht në procesin e zhvillimit, por gjithashtu do t'ju lejojë të kaloni periodikisht nga roli i "Menaxherit përgjegjës për gjithçka" në rolin e "Njeriu përgjegjës për zbatimin e një të funksioneve.” Ky qëndrim modest dhe modest do t'ju kujtojë rëndësinë e vendimeve të vogla.
- Unë jam ende duke u dridhur i tëri. Duket se dikush po më bërtet tashmë: “Menaxheri që mori përsipër zbatimin e funksionit?!” (Dhe unë jam dakord me të!) Po, ju jeni ende menaxher, që do të thotë se duhet të jetë një funksion i vogël, mirë? Po, keni ende shumë për të bërë. Nëse thjesht nuk mund të merrni përsipër zbatimin e funksionit, atëherë unë kam disa këshilla rezervë për ju: rregulloni disa gabime. Në këtë rast, nuk do të ndjeni gëzimin e krijimit, por do të keni një kuptim se si krijohet produkti, që do të thotë se nuk do të mbeteni kurrë pa punë.
- Shkruani testet e njësive. Unë ende e bëj këtë vonë në ciklin e prodhimit kur njerëzit fillojnë të çmenden. Mendoni si një listë kontrolli shëndetësor për produktin tuaj. Bëjeni këtë shpesh.
Kundërshtim përsëri?
“Rands, nëse shkruaj kod, do të ngatërroj ekipin tim. Ata nuk do ta dinë se kush jam unë – menaxher apo zhvillues.”
Хорошо.
Po, thashë: "Mirë!" Më vjen mirë që mendoni se mund ta ngatërroni ekipin tuaj vetëm duke notuar në pellgun e zhvilluesve. Është e thjeshtë: kufijtë midis roleve të ndryshme në zhvillimin e softuerit janë aktualisht shumë të paqarta. Djemtë e UI bëjnë atë që në përgjithësi mund të quhet programim JavaScript dhe CSS. Zhvilluesit po mësojnë gjithnjë e më shumë rreth dizajnit të përvojës së përdoruesit. Njerëzit komunikojnë me njëri-tjetrin dhe mësojnë për gabimet, për vjedhjen e kodit të njerëzve të tjerë, si dhe për faktin se nuk ka asnjë arsye të mirë që një menaxher të mos marrë pjesë në këtë bacchanalia informacioni masive, globale, ndër-pjalmuese.
Përveç kësaj, a dëshironi të jeni pjesë e një ekipi të përbërë nga komponentë lehtësisht të zëvendësueshëm? Kjo jo vetëm që do ta bëjë ekipin tuaj më të shkathët, por do t'i japë çdo anëtari të ekipit mundësinë për të parë produktin dhe kompaninë nga një sërë këndvështrimesh. Si mund të arrish ta respektosh Frankun, djaloshin e qetë në krye të ndërtimeve, më shumë sesa të shohësh elegancën e thjeshtë të skenarëve të tij të ndërtimit?
Unë nuk dua që ekipi juaj të bëhet konfuz dhe kaotik. Përkundrazi, dua që ekipi juaj të komunikojë në mënyrë më efektive. Unë besoj se nëse jeni të përfshirë në krijimin e produktit dhe duke punuar në veçoritë, do të jeni më afër ekipit tuaj. Dhe më e rëndësishmja, do të jeni më afër ndryshimeve të vazhdueshme në procesin e zhvillimit të softuerit brenda organizatës suaj.
Mos ndaloni së zhvilluari
Një kolege ime në Borland një herë më sulmoi verbalisht sepse e quajta atë "koduese".
“Rands, koduesi është një makinë pa mend! Majmun! Koduesi nuk bën asgjë të rëndësishme përveçse shkruan rreshta të mërzitshëm kodesh të padobishme. Unë nuk jam një kodues, unë jam një zhvillues softuerësh!”
Ajo kishte të drejtë, ajo do të kishte urryer këshillën time fillestare për CEO-t e rinj: "Ndaloni së shkruari kodin!" Jo sepse po sugjeroj që ata janë kodues, por më shumë sepse po sugjeroj në mënyrë proaktive që të fillojnë të injorojnë një nga pjesët më të rëndësishme të punës së tyre: zhvillimin e softuerit.
Kështu që unë e kam përditësuar këshillën time. Nëse dëshironi të jeni një udhëheqës i mirë, mund të ndaloni së shkruari kode, por...
Jini fleksibël. Mbani mend se çfarë do të thotë të jesh inxhinier dhe mos ndalo së zhvilluari softuer.
Rreth Autorit
Michael Lopp është një zhvillues veteran softuerësh që ende nuk është larguar nga Silicon Valley. Gjatë 20 viteve të fundit, Michael ka punuar për një sërë kompanish inovative, duke përfshirë Apple, Netscape, Symantec, Borland, Palantir, Pinterest dhe gjithashtu ka marrë pjesë në një startup që dalëngadalë kaloi në harresë.
Jashtë punës, Michael drejton një blog të njohur për teknologjinë dhe menaxhimin me pseudonimin Rands, ku diskuton idetë në fushën e menaxhimit me lexuesit, shpreh shqetësimin për nevojën e vazhdueshme për të mbajtur gishtin mbi pulsin dhe shpjegon se, pavarësisht shpërblime bujare për krijimin e një produkti, suksesi juaj është i mundur vetëm falë ekipit tuaj. Blogun mund ta gjeni këtu .
Michael jeton me familjen e tij në Redwood, Kaliforni. Ai gjen gjithmonë kohë për të bërë biçikletë malore, për të luajtur hokej dhe për të pirë verë të kuqe, pasi të jesh i shëndetshëm është më i rëndësishëm se të jesh i zënë.
» Më shumë detaje rreth librit mund të gjenden në
»
»
Për Khabrozhiteley 20% zbritje duke përdorur kupon - Menaxhimi i njerëzve
Pas pagesës për versionin në letër të librit, një version elektronik i librit do të dërgohet me e-mail.
PS: 7% e çmimit të librit do të shkojë për përkthimin e librave të rinj kompjuterikë, një listë librash të dorëzuar në shtypshkronjë. .
Burimi: www.habr.com