Ang aklat na "Paano pamahalaan ang mga intelektwal. Ako, mga nerd at geeks"

Dedicated sa mga project manager (at sa mga nangangarap maging boss).

Mahirap magsulat ng napakaraming code, ngunit mas mahirap ang pamamahala sa mga tao! Kaya kailangan mo lang ang aklat na ito upang matutunan kung paano gawin ang dalawa.

Posible bang pagsamahin ang mga nakakatawang kwento at seryosong aral? Nagtagumpay si Michael Lopp (kilala rin sa mga makitid na bilog bilang Rands). Makakahanap ka ng mga kathang-isip na kwento tungkol sa mga kathang-isip na tao na may hindi kapani-paniwalang kapakipakinabang (kahit na kathang-isip) na mga karanasan. Ganito ibinahagi ni Rands ang kanyang iba't-ibang, minsan kakaibang mga karanasang natamo sa mga taon ng pagtatrabaho sa malalaking IT corporations: Apple, Pinterest, Palantir, Netscape, Symantec, atbp.

Ikaw ba ay isang tagapamahala ng proyekto? O gusto mong maunawaan kung ano ang ginagawa ng iyong sumpain na amo sa buong araw? Tuturuan ka ni Rands kung paano mabuhay sa Toxic World of Inflated Turkeys at umunlad sa pangkalahatang kabaliwan ng mga di-functional na flamboyant na tao. Sa kakaibang komunidad na ito ng mga baliw na brainiac ay may mga hindi kilalang nilalang - mga tagapamahala na, sa pamamagitan ng isang mystical na ritwal ng organisasyon, ay nakakuha ng kapangyarihan sa mga plano, kaisipan at mga account sa bangko ng maraming tao.

Ang aklat na ito ay hindi katulad ng anumang manuskrito ng pamamahala o pamumuno. Walang itinatago si Michael Lopp, sinasabi lang niya ito nang ganoon (marahil hindi lahat ng kuwento ay dapat isapubliko: P). Ngunit sa paraang ito lamang mauunawaan mo kung paano mabuhay kasama ang gayong amo, kung paano pamahalaan ang mga geeks at nerd, at kung paano dalhin ang "mapahamak na proyektong iyon" sa isang masayang pagtatapos!

Sipi. Kaisipan ng engineering

Mga saloobin sa: Dapat Mo bang Ipagpatuloy ang Pagsusulat ng Code?

Ang aklat ni Rands sa mga panuntunan para sa mga tagapamahala ay naglalaman ng isang napakaikling listahan ng modernong managerial na "mga dapat gawin." Ang laconicism ng listahang ito ay nagmumula sa katotohanan na ang konsepto ng "dapat" ay isang uri ng ganap, at pagdating sa mga tao, napakakaunting mga ganap na konsepto. Ang isang matagumpay na paraan ng pamamahala para sa isang empleyado ay magiging isang tunay na sakuna para sa isa pa. Ang kaisipang ito ang unang item sa listahan ng "dapat gawin" ng manager:

Manatiling flexible!

Ang pag-iisip na alam mo na ang lahat ay isang napakasamang ideya. Sa isang sitwasyon kung saan ang tanging palaging katotohanan ay ang mundo ay patuloy na nagbabago, ang flexibility ay nagiging ang tanging tamang posisyon.

Paradoxically, ang pangalawang item sa listahan ay nakakagulat na hindi nababaluktot. Gayunpaman, ang puntong ito ay ang aking personal na paborito dahil naniniwala akong nakakatulong ito na lumikha ng pundasyon para sa paglago ng pamamahala. Ang talatang ito ay nagbabasa:

Itigil ang pagsusulat ng code!

Sa teorya, kung gusto mong maging isang tagapamahala, kailangan mong matutong magtiwala sa mga nagtatrabaho para sa iyo at ganap na ibigay ang coding sa kanila. Ang payong ito ay kadalasang mahirap intindihin, lalo na para sa mga bagong minted na manager. Marahil ang isa sa mga dahilan kung bakit sila naging mga tagapamahala ay dahil sa kanilang pagiging produktibo sa pag-unlad, at kapag nagkamali, ang una nilang reaksyon ay ang pagbabalik sa mga kasanayang lubos nilang pinagtitiwalaan, na kung saan ay ang kanilang kakayahang magsulat ng code.

Kapag nakita ko na ang isang bagong minted manager ay "nahuhulog" sa pagsulat ng code, sinabi ko sa kanya: "Alam namin na maaari kang magsulat ng code. Ang tanong ay: kaya mo bang manguna? Hindi ka na mananagot para sa iyong sarili lamang, ikaw ay responsable para sa buong koponan; at gusto kong tiyakin na makukuha mo ang iyong koponan na lutasin ang mga problema nang mag-isa, nang hindi mo kailangang isulat ang code nang mag-isa. Ang iyong trabaho ay upang malaman kung paano sukatin ang iyong sarili. Ayokong maging isa ka lang, gusto kong maraming katulad mo."

Magandang payo, tama ba? Scale. Pamamahala. Pananagutan. Mga karaniwang buzzword. Sayang naman ang payo.

hindi tama?

Oo. Mali ang payo! Hindi ganap na mali, ngunit sapat na mali kaya kinailangan kong tumawag sa ilang mga dating kasamahan at humingi ng paumanhin: “Alalahanin ang paborito kong pahayag tungkol sa kung paano ka dapat huminto sa pagsusulat ng code? Ito ay mali! Oo... Simulan muli ang programming. Magsimula sa Python at Ruby. Oo seryoso ako! Nakasalalay dito ang career mo!"

Noong sinimulan ko ang aking karera bilang isang developer ng software sa Borland, nagtrabaho ako sa koponan ng Paradox Windows, na isang malaking koponan. Mayroong 13 mga developer ng application lamang. Kung magdaragdag ka ng mga tao mula sa iba pang mga team na patuloy ding nagtatrabaho sa mga pangunahing teknolohiya para sa proyektong ito, tulad ng pangunahing database engine at mga pangunahing serbisyo ng application, makakakuha ka ng 50 inhinyero na direktang kasangkot sa pagbuo ng produktong ito.

Walang ibang team na nakatrabaho ko kahit na malapit sa ganitong laki. Sa katunayan, sa bawat pagdaan ng taon, ang bilang ng mga tao sa pangkat na aking pinagtatrabahuhan ay unti-unting nababawasan. Ano ang nangyayari? Tayong mga developer ba ay sama-samang nagiging mas matalino at mas matalino? Hindi, nagbabahagi lang kami ng load.

Ano ang ginagawa ng mga developer sa nakalipas na 20 taon? Sa panahong ito nagsulat kami ng isang shitload ng code. Dagat ng code! Sumulat kami ng napakaraming code kaya napagpasyahan naming maging isang magandang ideya na pasimplehin ang lahat at maging open source.

Sa kabutihang palad, salamat sa Internet, ang prosesong ito ay naging simple hangga't maaari. Kung ikaw ay isang software developer, maaari mo itong tingnan ngayon! Hanapin ang iyong pangalan sa Google o Github at makikita mo ang code na matagal mo nang nakalimutan, ngunit mahahanap ng sinuman. Nakakatakot diba? Hindi mo ba alam na ang code ay nabubuhay magpakailanman? Oo, nabubuhay siya magpakailanman.

Ang code ay nabubuhay magpakailanman. At ang magandang code ay hindi lamang nabubuhay magpakailanman, ito ay lumalaki dahil ang mga nagpapahalaga dito ay patuloy na tinitiyak na ito ay nananatiling sariwa. Ang pile na ito ng mataas na kalidad, well-maintained code ay nakakatulong na bawasan ang average na laki ng engineering team dahil nagbibigay-daan ito sa amin na tumuon sa umiiral na code sa halip na magsulat ng bagong code, at magawa ang trabaho sa mas kaunting tao at sa mas maikling time frame.

Ang linya ng pangangatwiran na ito ay nakakapanlumo, ngunit ang ideya ay lahat tayo ay isang grupo lamang ng integration automata gamit ang duct tape upang ikonekta ang iba't ibang piraso ng mga umiiral na bagay nang magkasama upang lumikha ng bahagyang magkaibang bersyon ng parehong bagay. Ito ay isang klasikong linya ng pag-iisip sa mga senior executive na mahilig sa outsourcing. “Magagawa ito ng sinumang marunong gumamit ng Google at may duct tape! Kung gayon bakit tayo nagbabayad ng malaking pera sa ating mga makina?"

Binabayaran namin ang mga management guys na ito ng malaking pera, ngunit sa tingin nila ay walang kapararakan. Muli, ang aking pangunahing punto ay mayroong maraming makikinang at napakasipag na mga developer sa ating planeta; sila ay tunay na napakatalino at masigasig, bagaman hindi sila gumugol ng isang minuto sa pag-upo sa mga akreditadong unibersidad. Ay oo, ngayon dumami na sila!

Hindi ko iminumungkahi na magsimula kang mag-alala tungkol sa iyong lugar dahil lamang sa ilang makikinang na mga kasama ay umano'y nangangaso para dito. Iminumungkahi kong simulan mong mag-alala tungkol dito dahil ang ebolusyon ng software development ay malamang na gumagalaw nang mas mabilis kaysa sa iyo. Sampung taon kang nagtatrabaho, lima sa kanila bilang isang tagapamahala, at sa tingin mo: "Alam ko na kung paano binuo ang software." Oo, alam mo. Bye…

Itigil ang pagsusulat ng code, ngunit...

Kung susundin mo ang aking orihinal na payo at ihinto ang pagsusulat ng code, kusang-loob mo ring hihinto ang pakikilahok sa proseso ng paglikha. Ito ang dahilan kung bakit hindi ako aktibong gumagamit ng outsourcing. Hindi gumagawa ang Automata, gumagawa sila. Ang mga mahusay na disenyong proseso ay nakakatipid ng maraming pera, ngunit hindi sila nagdadala ng anumang bago sa ating mundo.

Kung mayroon kang isang maliit na koponan na gumagawa ng maraming para sa maliit na pera, kung gayon ang ideya ng pagtigil sa pagsusulat ng code ay tila isang masamang desisyon sa karera para sa akin. Kahit na sa mga halimaw na kumpanya sa kanilang walang katapusang mga regulasyon, proseso at patakaran, wala kang karapatang kalimutan kung paano bumuo ng software sa iyong sarili. At ang pagbuo ng software ay patuloy na nagbabago. Nagbabago na ngayon. Sa ilalim ng iyong mga paa! Sa mismong segundong ito!

Mayroon kang mga pagtutol. Intindihin. Makinig tayo.

“Rands, papunta na ako sa director's chair! Kung patuloy akong magsusulat ng code, walang maniniwala na kaya kong lumago.”

Nais kong itanong sa iyo ito: mula nang umupo ka sa iyong upuan na "Malapit na akong maging CEO!", napansin mo ba na nagbabago ang landscape ng software development, kahit na sa loob ng iyong kumpanya? Kung oo ang sagot mo, tatanungin kita ng isa pang tanong: paano nga ba ito nagbabago at ano ang iyong gagawin sa mga pagbabagong ito? Kung sumagot ka ng "hindi" sa aking unang tanong, pagkatapos ay kailangan mong lumipat sa ibang upuan, dahil (pumusta ako!) Ang larangan ng software development ay nagbabago sa mismong segundong ito. Paano ka lalago kung dahan-dahan ngunit tiyak na nakakalimutan mo kung paano bumuo ng software?

Ang payo ko ay huwag italaga ang iyong sarili sa pagpapatupad ng napakaraming feature para sa iyong susunod na produkto. Kailangan mong patuloy na gumawa ng mga hakbang upang manatiling nakakaalam kung paano bumubuo ang iyong koponan ng software. Magagawa mo ito bilang isang direktor at bilang isang bise presidente. Iba pa?

"Ay, Rands! Ngunit kailangang may maging tagapamagitan! Kailangang makita ng isang tao ang malaking larawan. Kung magsusulat ako ng code, mawawalan ako ng pananaw."

Kailangan mo pa ring maging referee, kailangan mo pa ring i-broadcast ang mga desisyon, at kailangan mo pa ring maglakad-lakad sa paligid ng gusali ng apat na beses tuwing Lunes ng umaga kasama ang isa sa iyong mga inhinyero upang makinig sa kanyang lingguhang "We're all doomed" rant para sa 30 minuto.! Ngunit higit sa lahat ng iyon, kailangan mong mapanatili ang isang mindset ng engineering, at hindi mo kailangang maging isang full-time na programmer para magawa iyon.

Ang aking mga tip para sa pagpapanatili ng isang engineering mentality:

1. Gamitin ang kapaligiran sa pag-unlad. Nangangahulugan ito na dapat ay pamilyar ka sa mga tool ng iyong koponan, kabilang ang code build system, version control, at programming language. Bilang resulta, magiging bihasa ka sa wikang ginagamit ng iyong koponan kapag pinag-uusapan ang tungkol sa pagbuo ng produkto. Papayagan ka rin nitong magpatuloy sa paggamit ng iyong paboritong text editor, na gumagana nang perpekto.
2. Dapat ay maaari kang gumuhit ng isang detalyadong diagram ng arkitektura na naglalarawan sa iyong produkto sa anumang ibabaw anumang oras. Ngayon hindi ko ibig sabihin ang pinasimple na bersyon na may tatlong mga cell at dalawang arrow. Dapat mong malaman ang detalyadong diagram ng produkto. Ang pinakamahirap. Hindi lang basta anumang cute na diagram, kundi isang diagram na mahirap ipaliwanag. Ito ay dapat na isang mapa na angkop para sa kumpletong pag-unawa sa produkto. Ito ay patuloy na nagbabago, at dapat mong laging malaman kung bakit naganap ang ilang partikular na pagbabago.
3. Kunin ang pagpapatupad ng isa sa mga function. Literal na nanginginig ako habang isinusulat ko ito dahil maraming nakatagong panganib ang puntong ito, ngunit talagang hindi ako sigurado na magagawa mo ang point #1 at point #2 nang hindi nangangako na ipatupad ang kahit isang feature . Sa pamamagitan ng pagpapatupad ng isa sa mga tampok sa iyong sarili, hindi lamang ikaw ay aktibong kasangkot sa proseso ng pag-unlad, ito ay magbibigay-daan din sa iyo na pana-panahong lumipat mula sa papel na "Manager na namamahala sa lahat" patungo sa papel na "Taong namamahala sa pagpapatupad ng isa ng mga function.” Ang mapagpakumbaba at hindi mapagkunwari na saloobin ay magpapaalala sa iyo ng kahalagahan ng maliliit na desisyon.
4. Nanginginig pa ako ng todo. Parang may sumisigaw na sa akin: “Yung manager who took upon himself the implementation of the function?! (At sumasang-ayon ako sa kanya!) Oo, ikaw pa rin ang tagapamahala, ibig sabihin, ito ay dapat na isang maliit na function, okay? Oo, marami ka pang gagawin. Kung hindi mo kayang gawin ang pagpapatupad ng function, mayroon akong ilang ekstrang payo para sa iyo: ayusin ang ilang mga bug. Sa kasong ito, hindi mo mararamdaman ang kagalakan ng paglikha, ngunit magkakaroon ka ng pag-unawa sa kung paano nilikha ang produkto, na nangangahulugang hindi ka maiiwan sa trabaho.
5. Sumulat ng mga unit test. Ginagawa ko pa rin ito sa huli sa ikot ng produksyon kapag nagsimulang mabaliw ang mga tao. Isipin ito bilang checklist ng kalusugan para sa iyong produkto. Gawin ito ng madalas.

Tutol na naman?

“Rands, kung magsusulat ako ng code, malito ko ang team ko. Hindi nila malalaman kung sino ako—isang manager o developer."

Ayos lang.

Oo, sabi ko, "Okay!" Natutuwa akong iniisip mong malito mo ang iyong koponan sa pamamagitan lamang ng paglangoy sa developer pond. Ito ay simple: ang mga hangganan sa pagitan ng iba't ibang mga tungkulin sa pagbuo ng software ay kasalukuyang napakalabo. Ginagawa ng mga taong UI ang matatawag na JavaScript at CSS programming. Ang mga developer ay higit na natututo tungkol sa disenyo ng karanasan ng gumagamit. Ang mga tao ay nakikipag-usap sa isa't isa at natututo tungkol sa mga bug, tungkol sa pagnanakaw ng code ng ibang tao, at tungkol din sa katotohanang walang magandang dahilan para hindi lumahok ang manager sa napakalaking, pandaigdigan, cross-pollinating na impormasyong bacchanalia na ito.

Bukod dito, gusto mo bang maging bahagi ng isang pangkat na binubuo ng madaling mapapalitang mga bahagi? Hindi lang nito gagawing mas maliksi ang iyong koponan, bibigyan nito ang bawat miyembro ng koponan ng pagkakataong makita ang produkto at kumpanya mula sa iba't ibang pananaw. Paano mo igagalang si Frank, ang kalmadong tao na namamahala sa mga build, higit pa sa pagkatapos makita ang simpleng kagandahan ng kanyang mga script ng build?

Ayokong magulo at magulo ang team mo. Sa kabaligtaran, gusto kong mas epektibong makipag-usap ang iyong koponan. Naniniwala ako na kung kasangkot ka sa paggawa ng produkto at paggawa sa mga feature, mas magiging malapit ka sa iyong team. At higit sa lahat, mas malapit ka sa patuloy na pagbabago sa proseso ng pagbuo ng software sa loob ng iyong organisasyon.

Huwag tumigil sa pag-unlad

Ang isang kasamahan ko sa Borland ay minsang inatake sa akin dahil sa pagtawag sa kanya ng isang "coder."

"Rands, ang coder ay isang walang isip na makina! Unggoy! Ang coder ay walang ginagawang mahalagang bagay maliban sa pagsusulat ng mga boring na linya ng walang kwentang code. Hindi ako isang coder, isa akong software developer!"

Tama siya, kinasusuklaman niya ang paunang payo ko sa mga bagong CEO: "Ihinto ang pagsusulat ng code!" Hindi dahil sa iminumungkahi ko na sila ay mga coder, ngunit higit pa dahil maagap kong iminumungkahi na simulan nilang huwag pansinin ang isa sa pinakamahalagang bahagi ng kanilang trabaho: software development.

Kaya na-update ko ang aking payo. Kung gusto mong maging isang mahusay na pinuno, maaari mong ihinto ang pagsusulat ng code, ngunit...

Maging marunong makibagay. Tandaan kung ano ang ibig sabihin ng pagiging isang engineer at huwag huminto sa pagbuo ng software.

Tungkol sa May-akda

Si Michael Lopp ay isang beteranong software developer na hindi pa rin umaalis sa Silicon Valley. Sa nakalipas na 20 taon, nagtrabaho si Michael para sa iba't ibang mga makabagong kumpanya, kabilang ang Apple, Netscape, Symantec, Borland, Palantir, Pinterest, at lumahok din sa isang startup na dahan-dahang lumutang sa limot.

Sa labas ng trabaho, si Michael ay nagpapatakbo ng isang tanyag na blog tungkol sa teknolohiya at pamamahala sa ilalim ng pseudonym na Rands, kung saan tinatalakay niya ang mga ideya sa larangan ng pamamahala sa mga mambabasa, nagpahayag ng pagkabahala tungkol sa patuloy na pangangailangan na panatilihin ang kanyang daliri sa pulso, at ipinapaliwanag iyon, sa kabila ng mapagbigay na gantimpala para sa paglikha ng isang produkto, ang iyong tagumpay ay posible lamang salamat sa iyong koponan. Ang blog ay matatagpuan dito www.randsinrepose.com.

Nakatira si Michael kasama ang kanyang pamilya sa Redwood, California. Palagi siyang nakakahanap ng oras sa mountain bike, paglalaro ng hockey at pag-inom ng red wine, dahil mas mahalaga ang pagiging malusog kaysa pagiging abala.

» Higit pang mga detalye tungkol sa aklat ay matatagpuan sa website ng publisher
» Talaan ng nilalaman
» Sipi

Para sa Khabrozhiteley 20% na diskwento gamit ang kupon - Pamamahala ng mga tao

Sa pagbabayad para sa papel na bersyon ng aklat, isang elektronikong bersyon ng aklat ang ipapadala sa pamamagitan ng e-mail.

PS: 7% ng presyo ng libro ay mapupunta sa pagsasalin ng mga bagong computer book, isang listahan ng mga libro na ipinasa sa printing house dito.

Pinagmulan: www.habr.com