Isang mahalagang araw ang dumating para sa Red Hat, ang Russian open source na komunidad at lahat ng kasangkot - nai-publish ito sa Russian . Ikinuwento niya nang detalyado at malinaw kung paano namin sa Red Hat ay nagbibigay ng pinakamahuhusay na ideya at pinakamahuhusay na tao sa landas, at tungkol din sa kung paano hindi mawawala sa kaguluhan at magkaisa ang milyun-milyong tao sa buong mundo.
Ang aklat na ito ay tungkol din sa buhay at kasanayan. Naglalaman ito ng maraming payo para sa sinumang gustong matuto kung paano bumuo ng isang kumpanya gamit ang bukas na modelo ng organisasyon at epektibong pamahalaan ito. Nasa ibaba ang ilan sa pinakamahahalagang prinsipyo na ibinigay sa aklat na maaari mong tandaan sa ngayon.
Ang kasaysayan ng trabaho ni Jim sa kumpanya ay kapansin-pansin. Ito ay nagpapakita na walang kagalakan sa open source na mundo, ngunit mayroong isang bagong diskarte sa pamumuno:
"Pagkatapos makipag-usap sa recruiter, nagpahayag ako ng interes sa isang pakikipanayam, at tinanong niya kung gusto kong lumipad sa punong-tanggapan ng Red Hat sa Raleigh, North Carolina, sa Linggo. Akala ko Linggo ay isang kakaibang araw upang magkita. Ngunit dahil lilipad pa ako sa New York sa Lunes, sa pangkalahatan ay papunta na ito, at pumayag ako. Sumakay ako ng eroplano mula sa Atlanta at lumapag sa Raleigh Durham Airport. Mula doon, sumakay ako ng taxi na nagpababa sa akin sa harap ng gusali ng Red Hat sa campus ng University of North Carolina. Linggo noon, 9:30 am, at walang tao. Nakapatay ang mga ilaw at sa pagsuri ay nakita kong naka-lock ang mga pinto. Nung una akala ko niloloko ako. Pagtalikod ko para bumalik sa taxi, nakita kong nakaalis na ito. Sa lalong madaling panahon nagsimula ang ulan, wala akong payong.
Nang malapit na akong sumakay ng taxi, si Matthew Shulick, na kalaunan ay chairman ng board of directors at CEO ng Red Hat, ay huminto sa kanyang sasakyan. “Hi,” bati niya. “Gusto mo bang magkape?” Ito ay tila isang hindi pangkaraniwang paraan upang magsimula ng isang pakikipanayam, ngunit alam kong talagang kailangan kong kumuha ng kape. Sa huli, naisip ko, mas madali para sa akin na sumakay ng taxi papuntang airport.
Ang Linggo ng umaga ay medyo tahimik sa North Carolina. Medyo natagalan kami para lang makahanap ng coffee shop na bukas bago magtanghali. Ang coffee shop ay hindi ang pinakamahusay sa lungsod at hindi ang pinakamalinis, ngunit ito ay gumana at maaari kang uminom ng sariwang timplang kape doon. Umupo kami sa isang table at nagsimulang mag-usap.
Pagkaraan ng mga tatlumpung minuto o higit pa ay napagtanto ko na nagustuhan ko ang takbo ng mga bagay; Ang panayam ay hindi tradisyonal, ngunit ang pag-uusap mismo ay naging napaka-interesante. Sa halip na talakayin ang mas pinong mga punto ng diskarte ng kumpanya ng Red Hat o ang imahe nito sa Wall Street—isang bagay na pinaghandaan ko—nagtanong pa si Matthew Shulick tungkol sa aking mga pag-asa, pangarap, at layunin. Ngayon ay malinaw na sa akin na tinatasa ni Shulik kung babagay ako sa subculture at istilo ng pamamahala ng kumpanya.
Nang matapos kami, sinabi ni Shulick na gusto niyang ipakilala sa akin ang pangkalahatang tagapayo ng kumpanya, si Michael Cunningham, at iminungkahi na makipagkita ako sa kanya ngayon para sa isang maagang tanghalian. Pumayag naman ako at naghanda na kaming umalis. Tapos nadiskubre ng kausap ko na wala pala sa kanya ang wallet niya. "Oops," sabi niya. - Wala akong pera. At ikaw?" Nagulat ako dito, ngunit sumagot ako na may pera ako at hindi nag-iisip na magbayad para sa kape.
Pagkalipas ng ilang minuto, ibinaba ako ni Shulik sa isang maliit na Mexican restaurant, kung saan nakilala ko si Michael Cunningham. Ngunit muli, walang tradisyonal na pakikipanayam o pagpupulong sa negosyo ang sumunod, ngunit isa pang kawili-wiling pag-uusap ang naganap. Nang magbabayad na kami ng bill, sirang pala ang credit card machine ng restaurant, at cash lang ang natatanggap namin. Lumingon sa akin si Cunningham at tinanong kung handa na akong magbayad, dahil wala siyang dalang pera. Dahil pupunta ako sa New York, marami akong pera, kaya binayaran ko ang tanghalian.
Inalok ni Cunningham na ihatid ako sa airport, at sumakay kami sa kotse niya. Pagkaraan ng ilang minuto, nagtanong siya, “Pakialam mo ba kung huminto ako at magpapagasolina? Mauuna na tayo." “No problem,” sagot ko. Nang marinig ko ang maindayog na tunog ng bomba, may kumatok sa bintana. Ito ay Cunningham. "Uy, hindi sila kumukuha ng mga credit card dito," sabi niya. "Pwede ba akong humiram ng pera?" Nagsimula akong magtaka kung ito ba ay isang panayam o isang uri ng scam.
Kinabukasan, habang nasa New York, tinalakay ko ang panayam na ito sa aking asawa sa Red Hat. Sinabi ko sa kanya na ang pag-uusap ay napaka-interesante, ngunit hindi ako sigurado kung ang mga taong ito ay seryoso sa pagkuha sa akin: baka gusto lang nila ng libreng pagkain at gas? Sa pag-alala sa pulong na iyon ngayon, naiintindihan ko na sina Shulick at Cunningham ay simpleng mga bukas na tao at tinatrato ako tulad ng sinumang tao kung kanino sila makakasama ng kape, tanghalian o pagpuno ng gas. Oo, nakakatuwa at nakakatuwa na pareho silang nauwi sa walang pera. Ngunit para sa kanila ito ay hindi tungkol sa pera. Sila, tulad ng open source na mundo, ay hindi naniniwala sa pagpapalabas ng mga pulang karpet o sinusubukang kumbinsihin ang iba na ang lahat ay perpekto. Sinusubukan lang nilang kilalanin ako nang mas mabuti, hindi sinusubukan na mapabilib o ituro ang aming mga pagkakaiba. Gusto nilang malaman kung sino ako.
Ang aking unang panayam sa Red Hat ay malinaw na nagpakita sa akin na ang trabaho dito ay naiiba. Ang kumpanyang ito ay walang tradisyunal na hierarchy at espesyal na pagtrato para sa mga manager, kahit man lang sa anyo na karaniwan sa karamihan ng iba pang mga kumpanya. Sa paglipas ng panahon, nalaman ko rin na naniniwala ang Red Hat sa prinsipyo ng meritokrasya: palaging sulit na subukang ipatupad ang pinakamahusay na ideya, hindi alintana kung ito ay nagmula sa senior management o mula sa isang summer intern. Sa madaling salita, ang aking unang karanasan sa Red Hat ay nagpakilala sa akin kung ano ang hitsura ng hinaharap ng pamumuno.
Mga tip para sa paglinang ng meritokrasya
Ang meritocracy ay ang pangunahing halaga ng open source na komunidad. Hindi mahalaga sa amin kung anong antas ng pyramid ang iyong sinasakop, ang pangunahing bagay ay kung gaano kahusay ang iyong mga ideya. Narito ang iminumungkahi ni Jim:
- Huwag kailanman sabihin, "Iyan ang gusto ng boss," at huwag umasa sa hierarchy. Maaaring makatulong ito sa iyo sa maikling panahon, ngunit hindi ito kung paano ka bumuo ng isang meritokrasya.
- Kinikilala ng publiko ang mga tagumpay at mahahalagang kontribusyon. Ito ay maaaring isang simpleng email ng pasasalamat kasama ang buong koponan sa kopya.
- Isaalang-alang: ang iyong awtoridad ba ay isang function ng iyong posisyon sa hierarchy (o access sa privileged information), o ito ba ay resulta ng paggalang na iyong natamo? Kung ang una, simulan ang paggawa sa pangalawa.
- Humingi ng feedback at mangalap ng mga ideya sa isang partikular na paksa. Dapat kang tumugon sa lahat, subukan lamang ang pinakamahusay. Ngunit huwag lamang kunin ang pinakamahusay na mga ideya at magpatuloy sa kanila - kunin ang bawat pagkakataon upang palakasin ang diwa ng meritokrasya, na nagbibigay ng kredito sa lahat na karapat-dapat dito.
- Kilalanin ang isang huwarang miyembro ng iyong pangkat sa pamamagitan ng pag-aalok ng isang kawili-wiling takdang-aralin, kahit na wala ito sa kanilang karaniwang larangan ng trabaho.
Hayaang sundin ng iyong mga rock star ang kanilang hilig
Ang sigasig at pakikilahok ay dalawang napakahalagang salita sa isang bukas na organisasyon. Ang mga ito ay paulit-ulit na paulit-ulit sa aklat. Ngunit hindi ka makakakuha ng madamdamin na mga taong malikhain upang magtrabaho nang husto, tama ba? Kung hindi, hindi mo makukuha ang lahat ng inaalok ng kanilang talento. Sa Red Hat, ang mga hadlang para sa kanilang sariling mga proyekto ay na-level out hangga't maaari:
"Upang himukin ang pagbabago, sinusubukan ng mga kumpanya ang maraming bagay. Ang diskarte ng Google ay kawili-wili. Mula nang makilala ang Google sa bawat tahanan noong 2004, sinubukan ng mga executive at ideologist sa negosyo sa Internet na lutasin ang pangunahing sikreto ng kumpanya upang maulit ang kahanga-hangang tagumpay nito. Isa sa pinakatanyag, ngunit kasalukuyang sarado, na mga programa ay ang lahat ng empleyado ng Google ay hiniling na gumugol ng 20 porsiyento ng kanilang oras sa paggawa ng halos anumang bagay na gusto nila. Ang ideya ay kung ipagpatuloy ng mga empleyado ang kanilang sariling mga proyekto at ideya na kinahihiligan nila sa labas ng trabaho, magsisimula silang magbago. Ganito lumitaw ang matagumpay na mga proyekto ng third-party: GoogleSuggest, AdSense para sa Nilalaman at Orkut; lahat sila ay nagmula sa 20 porsiyentong eksperimentong ito—isang kahanga-hangang listahan! […]
Sa Red Hat, hindi gaanong pormal ang ginagawa namin. Wala kaming nakatakdang patakaran tungkol sa kung gaano karaming oras ang dapat gugulin ng bawat isa sa aming mga empleyado sa "pagbabago." Sa halip na bigyan ang mga tao ng dedikadong oras upang turuan ang kanilang mga sarili, tinitiyak namin na ang mga empleyado ay makakakuha ng karapatang gugulin ang kanilang oras sa pag-aaral ng mga bagong bagay. Sa totoo lang, napakakaunting oras ng maraming tao, ngunit mayroon ding mga taong kayang gugulin ang halos buong araw ng trabaho sa pagbabago.
Ang pinakakaraniwang kaso ay ganito ang hitsura: ang isang tao ay nagtatrabaho sa isang side project (kung ipinaliwanag niya ang kahalagahan nito sa mga tagapamahala - direkta sa lugar ng trabaho; o sa mga oras na hindi nagtatrabaho - sa kanyang sariling inisyatiba), at sa ibang pagkakataon ang gawaing ito ay maaaring tumagal ng lahat. kanyang kasalukuyang oras.”
Higit pa sa brainstorming
“Lyrical digression. Si Alex Fakeney Osborne ang imbentor ng paraan ng brainstorming, isang pagpapatuloy nito ngayon ay ang synectics method. Nakapagtataka na ang ideyang ito ay lumitaw noong Ikalawang Digmaang Pandaigdig, nang si Osborne ay nag-utos ng isa sa mga barko ng isang convoy ng kargamento ng Amerika na nasa panganib ng pag-atake ng torpedo ng isang submarino ng Aleman. Pagkatapos ay naalala ng kapitan ang pamamaraan na ginamit ng mga pirata ng Middle Ages: kung ang mga tripulante ay nagkaproblema, ang lahat ng mga mandaragat ay nagtitipon sa kubyerta upang magpalitan ng pagmumungkahi ng isang paraan upang malutas ang problema. Mayroong maraming mga ideya, kabilang ang mga walang katotohanan sa unang sulyap: halimbawa, ang ideya ng pamumulaklak sa isang torpedo kasama ang buong koponan. Ngunit sa jet ng bomba ng barko, na magagamit sa bawat barko, posible na pabagalin ang isang torpedo o kahit na baguhin ang takbo nito. Bilang resulta, nag-patent pa si Osborne ng isang imbensyon: isang karagdagang propeller ay naka-mount sa gilid ng barko, na nagtutulak sa isang daloy ng tubig sa gilid, at ang torpedo ay dumudulas sa tabi.
Patuloy na inuulit ng aming Jim na hindi ganoon kadaling magtrabaho sa isang bukas na organisasyon. Kahit na ang management ay nakukuha, dahil walang sinuman ang hindi kailangang ipagtanggol ang kanilang opinyon. Ngunit ito ang eksaktong diskarte na kinakailangan upang makamit ang mahusay na mga resulta:
“Ang mga online [open source] na mga forum at chat room ay kadalasang puno ng masigla at kung minsan ay masasamang talakayan tungkol sa lahat mula sa kung paano pinakamahusay na ayusin ang isang software bug hanggang sa kung anong mga bagong feature ang dapat isaalang-alang sa susunod na update. Bilang isang patakaran, ito ang unang yugto ng mga talakayan, kung saan ang mga bagong ideya ay inilalagay at naipon, ngunit palaging may susunod na pag-ikot - kritikal na pagsusuri. Bagama't ang sinuman ay maaaring lumahok sa mga debateng ito, ang isang tao ay dapat na maging handa upang ipagtanggol ang kanyang posisyon nang buong lakas. Ang hindi sikat na mga ideya ay tatanggihan sa pinakamahusay, kinutya sa pinakamasama.
Maging si Linus Torvalds, ang lumikha ng Linux operating system, ay nagpahayag ng kanyang hindi pagkakasundo sa mga iminungkahing pagbabago sa code. Isang araw, sina Linus at David Howells, isa sa mga nangungunang developer ng Red Hat, ay nagkaroon ng mainit na debate tungkol sa mga merito ng pagbabago ng code na hiniling ng Red Hat na makakatulong sa pagbibigay ng seguridad sa aming mga customer. Bilang tugon sa kahilingan ni Howells, sumulat si Torvalds: “Sa totoo lang, ito ay [hindi mai-print na salita] hangal. Ang lahat ay tila umiikot sa mga hangal na interface na ito, at para sa ganap na hangal na mga kadahilanan. Bakit natin ito gagawin? Hindi ko na gusto ang kasalukuyang X.509 parser. Ang mga hangal na kumplikadong interface ay nililikha, at ngayon ay magkakaroon ng 11 sa kanila. – Linus 9.”
Iniwan ang mga teknikal na detalye sa tabi, nagpatuloy si Torvalds sa pagsulat sa parehong diwa sa susunod na mensahe - at sa paraang hindi ako nangahas na sumipi. Napakalakas ng pagtatalo na ito na napunta pa ito sa mga pahina ng The Wall Street Journal. […]
Ipinapakita ng debateng ito na ang karamihan sa mga kumpanyang gumagawa ng pagmamay-ari, hindi libreng software ay walang bukas na debate tungkol sa kung anong mga bagong feature o pagbabago ang maaaring ginagawa nila. Kapag handa na ang produkto, ipinapadala lang ito ng kumpanya sa mga customer at nagpapatuloy. Kasabay nito, sa kaso ng Linux, ang mga talakayan tungkol sa kung anong mga pagbabago ang kailangan at - higit sa lahat - kung bakit kinakailangan ang mga ito, ay hindi humupa. Ito, siyempre, ay ginagawang mas magulo at nakakaubos ng oras ang buong proseso."
I-release nang maaga, i-release madalas
Hindi natin mahuhulaan ang hinaharap, kaya kailangan lang nating subukan:
"Nagpapatakbo kami sa prinsipyo ng "maagang paglunsad, madalas na pag-update." Ang pangunahing problema ng anumang proyekto ng software ay ang panganib ng mga error o mga bug sa source code. Malinaw, mas maraming pagbabago at update ang nakolekta sa isang release (bersyon) ng software, mas mataas ang posibilidad na magkaroon ng mga bug sa bersyong ito. Napagtanto ng mga developer ng open source software na sa pamamagitan ng mabilis at madalas na pagpapalabas ng mga bersyon ng software, nababawasan ang panganib ng mga seryosong problema sa anumang programa - pagkatapos ng lahat, hindi namin dinadala ang lahat ng mga update sa merkado nang sabay-sabay, ngunit isa-isa para sa bawat bersyon. Sa paglipas ng panahon, napansin namin na ang diskarte na ito ay hindi lamang binabawasan ang mga error, ngunit humahantong din sa mas kawili-wiling mga solusyon. Lumalabas na ang patuloy na paggawa ng maliliit na pagpapabuti ay lumilikha ng higit pang pagbabago sa katagalan. Marahil ay walang nakakagulat dito. Ang isa sa mga pangunahing prinsipyo ng modernong proseso ng pagmamanupaktura gaya ng kaizen a o lean b ay isang pagtutok sa maliliit at incremental na pagbabago at pag-update.
[…] Maaaring hindi magtagumpay ang karamihan sa ating pinagtatrabahuhan. Ngunit sa halip na gumugol ng maraming oras sa pag-iisip kung ano ang gagana at kung ano ang hindi, mas gusto naming magsagawa ng maliliit na eksperimento. Ang pinakasikat na mga ideya ay hahantong sa tagumpay, at ang mga hindi gumagana ay malalanta sa kanilang sarili. Sa ganitong paraan maaari nating subukan ang maraming bagay sa halip na isang bagay lamang, nang walang malaking panganib sa kumpanya.
Ito ay isang makatwirang paraan upang maglaan ng mga mapagkukunan. Halimbawa, madalas akong tinatanong ng mga tao kung paano namin pipiliin kung aling mga open source na proyekto ang ikomersyal. Bagama't kung minsan ay nagpapasimula tayo ng mga proyekto, mas madalas na tumalon lang tayo sa mga umiiral na. Isang maliit na grupo ng mga inhinyero—minsan isang tao lang—nagsisimulang mag-ambag sa isa sa mga proyekto ng open source na komunidad. Kung ang proyekto ay matagumpay at hinihiling sa aming mga customer, magsisimula kaming gumugol ng mas maraming oras at pagsisikap dito. Kung hindi, lumipat ang mga developer sa isang bagong proyekto. Sa oras na magpasya kaming i-komersyal ang panukala, ang proyekto ay maaaring lumago sa isang lawak na ang solusyon ay halata. Ang iba't ibang proyekto, kabilang ang mga hindi software, ay natural na umuusbong sa buong Red Hat hanggang sa maging malinaw sa lahat na ngayon ay may isang taong kailangang magtrabaho sa buong oras na ito."
Narito ang isa pang quote mula sa libro:
"Napagtanto ko na upang matugunan ang tungkuling ito, ang mga pinuno ng bukas ay dapat na may mga katangian na hindi napapansin sa mga kumbensyonal na organisasyon. Upang epektibong mamuno sa isang bukas na organisasyon, ang isang pinuno ay dapat magkaroon ng mga sumusunod na katangian.
- Personal na lakas at kumpiyansa. Ginagamit ng mga ordinaryong pinuno ang kapangyarihan sa posisyon—ang kanilang posisyon—upang makamit ang tagumpay. Ngunit sa isang meritokrasya, ang mga pinuno ay dapat magkaroon ng respeto. At ito ay posible lamang kung hindi sila natatakot na aminin na wala silang lahat ng mga sagot. Dapat ay handa silang talakayin ang mga problema at gumawa ng mga desisyon nang mabilis upang mahanap ang pinakamahusay na solusyon sa kanilang koponan.
- pasensya. Ang media ay bihirang magkuwento tungkol sa kung gaano ka "patient" ang isang pinuno. Pero kailangan talaga niyang tiisin. Kapag nagsusumikap ka upang makuha ang pinakamahusay na pagsisikap at mga resulta mula sa iyong koponan, pagkakaroon ng mga pag-uusap nang maraming oras at paulit-ulit na mga bagay hanggang sa magawa ito nang tama, kailangan mong maging matiyaga.
- Mataas na EQ (emotional intelligence). Kadalasan ay itinataguyod natin ang katalinuhan ng mga pinuno sa pamamagitan ng pagtutok sa kanilang IQ, kapag ang talagang kailangang isaalang-alang ay ang kanilang emotional intelligence quotient, o EQ score. Ang pagiging pinakamatalinong tao sa iba ay hindi sapat kung hindi mo kayang makipagtulungan sa mga taong iyon. Kapag nakipagtulungan ka sa mga komunidad ng mga nakatuong empleyado tulad ng Red Hat, at wala kang kakayahang mag-order ng sinuman sa paligid, ang iyong kakayahang makinig, magproseso nang analytical, at hindi kumuha ng mga bagay nang personal ay magiging lubhang mahalaga.
- Iba't ibang mentalidad. Ang mga pinuno na nagmula sa tradisyonal na mga organisasyon ay pinalaki na may diwa ng quid pro quo (Latin para sa "quid pro quo"), ayon sa kung saan ang bawat aksyon ay dapat makatanggap ng sapat na pagbabalik. Ngunit kapag naghahanap ka upang mamuhunan sa pagbuo ng isang partikular na komunidad, kailangan mong mag-isip nang pangmatagalan. Ito ay tulad ng pagsubok na bumuo ng isang maselang balanseng ecosystem, kung saan ang anumang maling hakbang ay maaaring lumikha ng isang kawalan ng timbang at humantong sa mga pangmatagalang pagkalugi na maaaring hindi mo kaagad mapansin. Dapat alisin ng mga pinuno ang pag-iisip na nangangailangan sa kanila na makamit ang mga resulta ngayon, sa anumang halaga, at magsimulang magnegosyo sa paraang nagpapahintulot sa kanila na umani ng mas malaking benepisyo sa pamamagitan ng pamumuhunan sa hinaharap.”
At bakit ito mahalaga
Ang Red Hat ay nabubuhay at nagpapatakbo sa mga prinsipyong ibang-iba sa tradisyonal na hierarchical na organisasyon. At gumagana ito, ginagawa tayong matagumpay sa komersyo at masaya sa tao. Isinalin namin ang aklat na ito sa pag-asang maipalaganap ang mga prinsipyo ng bukas na organisasyon sa mga kumpanyang Ruso, sa mga taong gusto at maaaring mamuhay nang iba.
, subukan mo!
Pinagmulan: www.habr.com