“Open Organization”: Nola ez galdu kaosean eta milioika batu

Egun garrantzitsu bat iritsi da Red Hat-i, Errusiako kode irekiko komunitateari eta parte hartzen duten guztiei - errusieraz argitaratu zen Jim Whitehurst-en liburua, The Open Organization: Passion That Gets Results. Xehetasunez eta bizi-bizi kontatzen du nola Red Hat-en ideiarik onenak eta talentu handiena duten pertsonari bidea ematen diogun, eta baita kaosean ez galtzeko eta mundu osoko milioika pertsona batzeko ere.

“Open Organization”: Nola ez galdu kaosean eta milioika batu

Liburu hau bizitzari eta praktikari buruzkoa ere bada. Aholku asko ditu erakunde irekiaren eredua erabiliz enpresa bat eraikitzen eta modu eraginkorrean kudeatzen ikasi nahi duen edonorentzat. Jarraian, oraintxe bertan kontuan har ditzakezun liburuan emandako printzipio garrantzitsuenetako batzuk daude.

Jimek konpainiarekin duen lan-historia nabarmena da. Kode irekiko munduan fanfarrerik ez dagoela erakusten du, baina lidergoaren ikuspegi berri bat dago:

"Konklutatzailearekin hitz egin ondoren, elkarrizketa batean interesa adierazi nuen, eta igandean Red Hat-en Raleigh-en (Ipar Carolina) egoitzara hegan egitea gustatuko litzaidakeen galdetu zidan. Igandea elkartzeko egun arraroa zela iruditu zitzaidan. Baina oraindik astelehenean New Yorkera hegazkin egingo nuenez, orokorrean bidean zegoen, eta baiezkoa eman nuen. Atlantatik hegazkin batean sartu eta Raleigh Durham aireportuan lurreratu nintzen. Handik, Ipar Carolinako Unibertsitateko campuseko Red Hat eraikinaren aurrean utzi ninduen taxi bat hartu nuen. Igandea zen, 9:30ean, eta ez zegoen inor inguruan. Argiak itzalita zeuden eta egiaztatzean ateak itxita zeudela ikusi nuen. Hasieran engainatzen ari nintzela uste nuen. Taxian bueltatzeko buelta eman nuenean, jadanik irten zela ikusi nuen. Oso laster euria hasi zuen, ez nuen aterkirik.

Taxi bat hartzera norabait joatekotan nengoela, Matthew Shulick, gerora Red Hat-eko zuzendaritza-batzordeko presidentea eta zuzendari nagusia, bere autoan gelditu zen. "Kaixo", agurtu zuen. "Kafe pixka bat hartu nahi al duzu?" Elkarrizketa bat hasteko modu ezohikoa iruditu zitzaidan, baina banekien behin betiko kafea hartu behar nuela. Azken finean, pentsatu nuen, errazagoa izango zitzaidala aireporturako taxi bat hartzea.

Igande goizak nahiko lasaiak dira Ipar Carolinan. Pixka bat behar izan genuen eguerdia baino lehen irekitako kafetegi bat aurkitzeko. Kafetegia ez zen hiriko onena eta ez garbiena, baina funtzionatzen zuen eta bertan prestatu berria zen kafea edaten zen. Mahai batean eseri eta hizketan hasi ginen.

Hogeita hamar bat minuturen buruan konturatu nintzen gauzak zihoazen modua gustatzen zitzaidala; Elkarrizketa ez zen tradizionala izan, baina elkarrizketa bera oso interesgarria izan zen. Red Hat-en estrategia korporatiboaren edo bere irudiaren Wall Street-en -prestatutako zerbait- eztabaidatu beharrean, Matthew Shulick-ek nire itxaropen, amets eta helburuei buruz gehiago galdetu zuen. Orain argi daukat Shulik enpresaren azpikulturara eta kudeaketa estilora egokituko ote nintzen ebaluatzen ari zela.

Amaitu genuenean, Shulick-ek esan zuen Michael Cunningham konpainiako kontseilari orokorra aurkeztu nahi zidala eta orain harekin elkartzea proposatu zidan goiz bazkaltzeko. Ados jarri nintzen eta alde egiteko prest egon ginen. Orduan nire solaskideak aurkitu zuen ez zuela diru-zorroa berarekin. "Aupa", esan zuen. - Ez daukat dirurik. Eta zu?" Honek ezustean hartu ninduen, baina dirua nuela eta kafea ordaintzea ez zitzaidala axola erantzun nion.

Minutu batzuk geroago, Shulik Mexikoko jatetxe txiki batean utzi ninduen, eta han Michael Cunningham ezagutu nuen. Baina berriro ere, ez zen ohiko elkarrizketarik edo negozio bilerarik izan, baina beste elkarrizketa interesgarri bat gertatu zen. Faktura ordaintzera gindoazela, jatetxeko kreditu-txartelen makina apurtuta zegoela ikusi zen eta eskudirua baino ezin genuela onartu. Cunninghamek nigana jo zuen eta ordaintzeko prest nengoen galdetu zuen, ez zuelako dirurik berarekin. New Yorkera joaten nintzenez, diru asko nuen, eta bazkaria ordaindu nuen.

Cunninghamek aireportura gidatzea eskaini zidan, eta bere autoan joan ginen. Minutu batzuk igaro ondoren, galdetu zuen: "Axola zaizu gelditzen naizen eta gasolina hartzen badut? Buruz beteko dugu aurrera». "Ez da arazorik", erantzun nion. Ponparen soinu erritmikoa entzun bezain laster, leihoan kolpe bat entzun zen. Cunningham zen. "Aizu, hemen ez dute kreditu-txartelik hartzen", esan zuen. "Diru apur bat maileguan har dezaket?" Hau benetan elkarrizketa bat edo iruzur mota bat ote zen galdetzen hasi nintzen.

Biharamunean, New York-en nengoela, Red Hat-en emazteari egindako elkarrizketa hau eztabaidatu nuen. Elkarrizketa oso interesgarria izan zela esan nion, baina ez nengoen ziur pertsona horiek ni kontratatzeko serio ote ziren: agian janaria eta gasolina doan nahi zuten? Gaurko bilera hura gogoratuz, ulertzen dut Shulick eta Cunningham pertsona irekiak zirela eta kafea hartu, bazkaldu edo gasaz bete zezaketen beste edozein pertsona bezala tratatu nindutela. Bai, dibertigarria eta are barregarria da biak dirurik gabe geratu izana. Baina haientzat ez zen diru kontua. Haiek, kode irekiko mundua bezala, ez zuten sinesten alfonbra gorriak zabaltzen edo dena perfektua zela konbentzitzen saiatzen zirenik. Ni hobeto ezagutzen saiatzen ziren, ez gure ezberdintasunak txunditu edo seinalatu nahian. Nor nintzen jakin nahi zuten.

Red Hat-en egin nuen lehen elkarrizketa argi eta garbi erakutsi zidan hemengo lana ezberdina zela. Enpresa honek ez zuen hierarkia tradizional eta kudeatzaileentzako tratu berezirik, beste enpresa gehienetan ohikoa den moduan behintzat. Denborak aurrera egin ahala, Red Hat-ek meritokraziaren printzipioan sinesten duela ere jakin nuen: beti merezi du ideiarik onena gauzatzen saiatzeak, goi-zuzendaritzaren edo udako bekadun batengandik datorren gorabehera. Beste era batera esanda, Red Hat-en egin nuen lehen esperientziak lidergoaren etorkizuna nolakoa den ezagutu ninduen».

Meritokrazia lantzeko aholkuak

Meritokrazia kode irekiko komunitatearen oinarrizko balioa da. Berdin zaigu piramidearen zein maila okupatzen duzun, gauza nagusia zure ideiak zein onak diren da. Hona hemen Jimek iradokitzen duena:

  • Inoiz ez esan: "Hori da nagusiak nahi duena" eta ez fidatu hierarkian. Horrek epe laburrean lagun zaitzake, baina ez da horrela eraikitzen meritokrazi bat.
  • Arrakasta eta ekarpen garrantzitsuak publikoki aitortu. Hau eskerrak emateko mezu elektroniko sinple bat izan liteke talde osoarekin kopiatuta.
  • Kontuan izan: zure agintea hierarkian duzun posizioaren (edo informazio pribilegiaturako sarbidea) funtzioa al da, ala irabazi duzun errespetuaren ondorioa da? Lehenengoa bada, hasi bigarrenean lanean.
  • Iritzia eskatu eta gai zehatz bati buruzko ideiak bildu. Guztiarekin erreakzionatu beharko zenuke, onena bakarrik probatu. Baina ez hartu ideiarik onenak eta haiekin aurrera egin, aprobetxatu aukera guztiak meritokraziaren izpiritua indartzeko, merezi duten guztiei meritua emanez.
  • Errekonozitu zure taldeko kide eredugarri bat lan interesgarri bat eskainiz, bere ohiko lan-eremuan egon ez arren.

Utzi zure rock izarrek euren pasioari jarraiki

Ilusioa eta inplikazioa bi hitz oso garrantzitsuak dira erakunde ireki batean. Liburuan etengabe errepikatzen dira. Baina ezin duzu pertsona sortzaile sutsuak gogor lan egin, ezta? Bestela, ez duzu haien talentuak eskaintzen duen guztia lortuko. Red Hat-en, euren proiektuetarako oztopoak ahalik eta gehien berdintzen dira:

«Berrikuntza bultzatzeko, enpresek gauza asko saiatzen dira. Googleren ikuspegia interesgarria da. 2004an Google etxe guztietan ezagun egin zenetik, Interneteko negozioko exekutibo eta ideologoek konpainiaren sekretu nagusia argitzen saiatu dira, arrakasta ikusgarria errepikatzeko. Programa ospetsuenetako bat, baina gaur egun itxita dagoena, Google-ko langile guztiei eskatzen zitzaien denboraren ehuneko 20 ia nahi zuten guztia egiten pasatzeko. Ideia zen langileek beren proiektu eta ideiak lanetik kanpo gogotsu egiten bazituzten, berritzen hasiko zirela. Honela sortu ziren hirugarrenen proiektu arrakastatsuak: GoogleSuggest, AdSense for Content eta Orkut; ehuneko 20ko esperimentu honetatik etorri ziren guztiak - zerrenda ikusgarria! […]

Red Hat-en ikuspegi ez hain formal bat hartzen dugu. Ez dugu gure langile bakoitzak "berrikuntzan" zenbat denbora eman behar duen jakiteko politika finkaturik. Jendeari bere burua hezteko denbora eskaini beharrean, langileek gauza berriak ikasten denbora pasatzeko eskubidea irabazten dutela ziurtatzen dugu. Egiari zor, jende askok oso denbora gutxi du, baina badaude ia lanaldi osoa berrikuntzan eman dezakeena ere.

Kasurik tipikoenak honelako itxura du: norbaitek albo-proiektu batean lan egiten du (zuzendariei bere garrantzia azaltzen badie -zuzenean lantokian; edo lanaldiz kanpoko orduetan - bere ekimenez), eta gero lan horrek guztiak har ditzake. bere egungo orduak».

Brainstorming baino gehiago

“Digresio lirikoa. Alex Fakeney Osborne brainstorming metodoaren asmatzailea da, gaur egun sinektika metodoaren jarraipena da. Bitxia da ideia hori Bigarren Mundu Gerran agertu izana, Osbornek Alemaniako itsaspeko baten torpedoak erasotzeko arriskuan zegoen amerikar zama-konboi baten ontzietako bat agindu zuenean. Orduan kapitainak Erdi Aroko piratek erabiltzen zuten teknikaz gogoratu zen: tripulazioak arazoak izaten baziren, marinel guztiak bizkarrean biltzen ziren txandaka arazoa konpontzeko modua iradokiz. Ideia asko egon ziren, lehen begiratuan absurdoak barne: adibidez, talde osoarekin torpedo batean putz egitearen ideia. Baina itsasontzi guztietan eskuragarri dagoen ontzi baten ponparen zorrotadarekin, oso posible da torpedo bat moteltzea edo bere ibilbidea aldatzea. Ondorioz, Osbornek asmakizun bat ere patentatu zuen: ontziaren alboan helize gehigarri bat muntatzen da, ur korronte bat alboan zehar gidatzen duena, eta torpedoa alboan irristatzen da".

Gure Jimek etengabe errepikatzen du ez dela hain erraza erakunde ireki batean lan egitea. Zuzendaritzak ere lortzen du, inori ez zaiolako bere iritzia defendatzeko beharra libratzen. Baina hauxe da emaitza bikainak lortzeko behar den ikuspegia:

"Sareko [iturburu irekiko] foroak eta txat-aretoak eztabaida bizi eta batzuetan gogorrez beteta egoten dira denetariko guztiari buruz, software-akats bat nola konpondu behar den eta hurrengo eguneraketan zein ezaugarri berri kontuan hartu behar diren. Oro har, hau da eztabaidetako lehen fasea, zeinetan ideia berriak planteatzen eta metatzen diren, baina beti dago hurrengo txanda bat: analisi kritikoa. Eztabaida hauetan edonork parte har dezakeen arren, pertsona batek bere jarrera indar guztiekin defendatzeko prest egon behar du. Ideia ezezagunak baztertu egingo dira onenean, barregarririk txarrenean.

Nahiz eta Linus Torvalds, Linux sistema eragilearen sortzaileak, bere desadostasuna adierazten du kodean proposatutako aldaketekin. Egun batean, Linus eta David Howells, Red Hat-en garatzaile nagusietako bat, Red Hat-ek gure bezeroei segurtasuna eskaintzen lagunduko zien kode aldaketa baten merituei buruzko eztabaida bizian sartu ziren. Howells-en eskaerari erantzunez, Torvaldsek idatzi zuen: “Egia esanda, hau [inprimaezina den hitza] ergela da. Badirudi dena interfaze ergel horien inguruan dabilela, eta arrazoi guztiz ergelengatik. Zergatik egin behar dugu hau? Dagoeneko X.509 analizatzailea ez zait gehiago gustatzen. Interfaze konplexu ergelak sortzen ari dira, eta orain horietako 11 izango dira. - Linus 9."

Xehetasun teknikoak alde batera utzita, espiritu berean idazten jarraitu zuen Torvaldek hurrengo mezuan —eta aipatzera ausartzen ez naizen moduan—. Gatazka hau hain zen ozen non The Wall Street Journal-eko orrialdeetan ere iritsi zen. […]

Eztabaida honek erakusten du jabedun eta aske ez den software ekoizten duten enpresa gehienek ez dutela eztabaida irekirik zer ezaugarri edo aldaketa berritan lan egin dezaketen. Produktua prest dagoenean, enpresak bezeroei bidaltzen die eta aurrera egiten du. Aldi berean, Linux-en kasuan, zer aldaketa behar diren eta -garrantzitsuena- zergatik diren beharrezkoak diren eztabaidak ez dira baretzen. Horrek, noski, prozesu osoa askoz nahasiagoa eta denbora gehiago eskatzen du».

Askatu goiz, askatu maiz

Ezin dugu etorkizuna aurreikusi, beraz, probatu besterik ez dugu egin behar:

"Abiarazte goiztiarra, maiz eguneratzeak" printzipioaren arabera funtzionatzen dugu. Edozein software proiekturen funtsezko arazoa iturburu kodean akatsak edo akatsak izateko arriskua da. Jakina, zenbat eta aldaketa eta eguneratze gehiago bildu softwarearen bertsio (bertsio) batean, orduan eta aukera handiagoa izango da bertsio honetan akatsak izateko. Kode irekiko softwarearen garatzaileak konturatu dira software-bertsioak azkar eta maiz kaleratuz gero, edozein programarekin arazo larriak izateko arriskua murrizten dela; azken finean, ez ditugu merkatura eguneratze guztiak aldi berean ekartzen, bertsio bakoitzeko banan-banan baizik. Denborarekin, ikuspegi honek akatsak murrizten ez ezik, irtenbide interesgarriagoak ere ekartzen dituela ohartu ginen. Ematen du etengabe hobekuntza txikiak egiteak berrikuntza gehiago sortzen duela epe luzera. Agian ez dago ezer harrigarririk hemen. Kaizen a edo lean b bezalako fabrikazio prozesu modernoen funtsezko printzipioetako bat aldaketa eta eguneratze txiki eta gehigarrietan arreta jartzea da.

[…] Lan egiten dugunaren zati handi batek agian ez du arrakasta izango. Baina zerk funtzionatuko duen eta zer ez galdetzen denbora asko eman beharrean, nahiago dugu esperimentu txikiak egitea. Ideia ezagunenek arrakasta ekarriko dute, eta funtzionatzen ez dutenak beren kabuz zimelduko dira. Horrela, gauza bakarra baino gauza asko proba ditzakegu, enpresarentzat arrisku handirik gabe.

Baliabideak banatzeko modu arrazionala da. Adibidez, jendeak askotan galdetzen dit nola aukeratzen ditugun kode irekiko zein proiektu komertzializatzeko. Batzuetan proiektuak abiatzen ditugun arren, gehienetan lehendik daudenetara salto egiten dugu. Ingeniari talde txiki bat —batzuetan pertsona bakarra— kode irekiko komunitatearen proiektu batean laguntzen hasten da. Proiektua arrakastatsua bada eta gure bezeroen artean eskaria bada, denbora eta ahalegin gehiago ematen hasiko gara. Hala ez bada, garatzaileek proiektu berri batera ibiltzen dira. Proposamena komertzializatzea erabakitzen dugunerako, baliteke proiektua hazita egotea, irtenbidea begi bistakoa izateko. Hainbat proiektu, softwarekoak ez direnak barne, modu naturalean sortzen dira Red Hat osoan zehar, denek argi geratu arte orain norbaitek lanaldi osoan lan egin beharko duela».

Hona hemen liburuko beste aipamen bat:

«Konturatu nintzen eginkizun hori betetzeko, biharko buruzagiek ohiko erakundeetan besterik gabe ahazten diren ezaugarriak izan behar dituztela. Erakunde ireki bat eraginkortasunez zuzentzeko, liderrak ezaugarri hauek izan behar ditu.

  • Indar pertsonala eta konfiantza. Lider arruntek posizio boterea —beren posizioa— erabiltzen dute arrakasta lortzeko. Baina meritokrazian, buruzagiek errespetua irabazi behar dute. Eta hori bakarrik da posible erantzun guztiak ez dituztela aitortzeko beldurrik ez badute. Arazoak eztabaidatzeko eta erabakiak azkar hartzeko prest egon behar dute bere taldearekin irtenbide onenak aurkitzeko.
  • Pazientzia. Komunikabideek oso gutxitan kontatzen dituzte buruzagi batek zenbaterainoko "pazientzia" duen. Baina benetan pazientzia izan behar du. Zure taldearen esfortzu eta emaitzarik onenak lortzeko lanean ari zarenean, orduetan elkarrizketak izaten eta gauzak behin eta berriz errepikatuz ondo egin arte, pazientzia izan behar duzu.
  • EQ altua (adimen emozionala). Sarritan liderren adimena sustatzen dugu beren adimen adimenean zentratuz, benetan kontuan hartu behar dena adimen emozionalaren zatidura edo EQ puntuazioa denean. Besteen artean pertsonarik adimentsuena izatea ez da nahikoa pertsona horiekin lan egiteko gai ez bazara. Red Hat bezalako langile konprometituen komunitateekin lan egiten duzunean eta inguruan inori eskatzeko gaitasunik ez duzunean, entzuteko, modu analitikoan prozesatzeko eta gauzak pertsonalki ez hartzeko gaitasuna izugarri baliotsu bihurtzen da.
  • Mentalitate ezberdina. Erakunde tradizionaletatik zetozen buruzagiak quid pro quo (latinez "quid pro quo") izpirituarekin hazi ziren, zeinaren arabera ekintza bakoitzak etekin egokia jaso behar zuen. Baina komunitate jakin bat eraikitzeko inbertitu nahi duzunean, epe luzera pentsatu behar duzu. Okerreko ekosistema bat eraikitzen saiatzea bezalakoa da, non urrats oker batek desoreka bat sor dezakeen eta epe luzerako galerak ekar ditzakeen berehala nabarituko ez dituzun. Liderrak alde batera utzi behar ditu gaur emaitzak lortzeko eskatzen dien pentsamoldea, edozein kostutan, eta negozioak egiten hasi, etorkizunean inbertituz onura handiagoak ateratzeko».

Eta zergatik da garrantzitsua

Red Hat-ek ohiko antolaketa hierarkiko batetik oso desberdinak diren printzipioetan bizi eta funtzionatzen du. Eta funtzionatzen du, arrakasta komertzialki eta gizatasunez zoriontsu egiten gaitu. Liburu hau itzuli dugu Errusiako enpresen artean antolakuntza irekiaren printzipioak zabaltzeko asmoz, ezberdin bizi nahi eta bizi daitezkeen pertsonen artean.

Irakurri, saiatu!

Iturria: www.habr.com

Gehitu iruzkin berria