Prišel je pomemben dan za Red Hat, rusko odprtokodno skupnost in vse vpletene – objavljen je bil v ruščini . Podrobno in živo pripoveduje, kako v Red Hatu najboljšim idejam in najbolj nadarjenim ljudem ponujamo pot, pa tudi o tem, kako se ne izgubiti v kaosu in združiti milijone ljudi po vsem svetu.
Tudi ta knjiga govori o življenju in praksi. Vsebuje veliko nasvetov za vse, ki se želijo naučiti graditi podjetje po modelu odprte organizacije in ga učinkovito upravljati. Spodaj je nekaj najpomembnejših načel, navedenih v knjigi, ki si jih lahko takoj zapomnite.
Jimova zgodovina zaposlitve v podjetju je izjemna. Kaže, da v odprtokodnem svetu ni pompa, ampak obstaja nov pristop k vodenju:
»Po pogovoru z nabornikom sem izrazil zanimanje za intervju in vprašal me je, če bi imel kaj proti, da bi v nedeljo odletel na sedež Red Hat v Raleighu v Severni Karolini. Nedelja se mi je zdela čuden dan za srečanje. Ker pa sem še vedno nameraval leteti v New York v ponedeljek, na splošno je bilo na poti, in sem se strinjal. Vkrcal sem se na letalo iz Atlante in pristal na letališču Raleigh Durham. Od tam sem vzel taksi, ki me je odložil pred stavbo Red Hat v kampusu Univerze v Severni Karolini. Bila je nedelja, 9 zjutraj in nikogar ni bilo zraven. Luči so bile ugasnjene in ko sem preveril, sem ugotovil, da so vrata zaklenjena. Najprej sem mislil, da me zavajajo. Ko sem se obrnil, da bi se vrnil v taksi, sem videl, da je že odpeljal. Kmalu je začelo deževati, dežnika nisem imela.
Ravno ko sem hotel nekam iti, da bi ujel taksi, se je Matthew Shulick, kasneje predsednik upravnega odbora in izvršni direktor Red Hat-a, ustavil s svojim avtomobilom. "Živjo," je pozdravil. "Bi radi kavo?" To se mi je zdel nenavaden način za začetek intervjuja, vendar sem vedel, da moram nujno na kavo. Navsezadnje sem mislil, da bi mi bilo lažje ujeti taksi do letališča.
Nedeljsko jutro je v Severni Karolini precej mirno. Kar nekaj časa smo potrebovali, da smo našli kavarno, ki se je odprla pred poldnevom. Kavarna ni bila najboljša v mestu in ne najbolj čista, vendar je delovala in tam si lahko spil sveže skuhano kavo. Usedla sva se za mizo in se začela pogovarjati.
Po približno tridesetih minutah sem ugotovil, da mi je všeč, kako stvari potekajo; Intervju sicer ni bil tradicionalen, vendar je bil sam pogovor zelo zanimiv. Namesto da bi razpravljal o finih točkah strategije podjetja Red Hat ali o njegovi podobi na Wall Streetu – na kar sem bil pripravljen – je Matthew Shulick vprašal več o mojih upih, sanjah in ciljih. Zdaj mi je jasno, da je Shulik ocenjeval, ali bom ustrezal subkulturi in slogu vodenja podjetja.
Ko smo končali, je Shulick rekel, da me želi predstaviti glavnemu svetovalcu podjetja, Michaelu Cunninghamu, in predlagal, da se zdaj srečam z njim na zgodnjem kosilu. Privolil sem in pripravili smo se na odhod. Nato je moj sogovornik ugotovil, da pri sebi nima denarnice. "Ojoj," je rekel. - Jaz nimam denarja. In ti?" To me je presenetilo, a sem odgovoril, da imam denar in da mi je vseeno, da plačam kavo.
Nekaj minut kasneje me je Shulik odložil v majhni mehiški restavraciji, kjer sem srečal Michaela Cunninghama. A spet ni sledil tradicionalni intervju ali poslovno srečanje, pač pa je stekel še en zanimiv pogovor. Ko sva hotela plačati račun, se je izkazalo, da je bil avtomat za kreditne kartice v restavraciji pokvarjen in da lahko sprejemava samo gotovino. Cunningham se je obrnil k meni in me vprašal, ali sem pripravljen plačati, saj pri sebi ni imel gotovine. Ker sem šel v New York, sem imel veliko denarja, zato sem plačal kosilo.
Cunningham se je ponudil, da me odpelje na letališče, in šla sva z njegovim avtomobilom. Po nekaj minutah je vprašal: »Ali imate kaj proti, če se ustavim in dobim plin? Šli bomo s polno paro naprej." "Ni problema," sem odgovoril. Takoj ko sem zaslišal ritmični zvok črpalke, je potrkalo na okno. Bil je Cunningham. "Hej, tukaj ne sprejemajo kreditnih kartic," je rekel. "Ali si lahko sposodim nekaj denarja?" Začel sem se spraševati, ali je to res intervju ali kakšna prevara.
Naslednji dan, ko sem bil v New Yorku, sem o tem intervjuju razpravljal s svojo ženo pri Red Hatu. Rekel sem ji, da je bil pogovor zelo zanimiv, vendar nisem bil prepričan, ali so ti ljudje mislili resno, da bi me najeli: morda so želeli le brezplačno hrano in bencin? Ko se danes spomnim tistega srečanja, razumem, da sta bila Shulick in Cunningham preprosto odprta človeka in sta me obravnavala kot vsako drugo osebo, s katero sta lahko popila kavo, kosilo ali natočila bencin. Ja, smešno in celo smešno je, da sta oba ostala brez denarja. A zanje ni šlo za denar. Tako kot odprtokodni svet niso verjeli v razgrnitev rdečih preprog ali poskušanje prepričevanja drugih, da je vse popolno. Želeli so me samo bolje spoznati, ne pa narediti vtis ali poudariti naše razlike. Želeli so vedeti, kdo sem.
Moj prvi intervju pri Red Hatu mi je jasno pokazal, da je delo tukaj drugačno. To podjetje ni imelo tradicionalne hierarhije in posebne obravnave menedžerjev, vsaj v obliki, ki je običajna v večini drugih podjetij. Sčasoma sem tudi izvedel, da Red Hat verjame v načelo meritokracije: vedno je vredno poskušati uresničiti najboljšo idejo, ne glede na to, ali prihaja od višjega vodstva ali od poletnega pripravnika. Z drugimi besedami, moja prva izkušnja pri Red Hatu mi je predstavila, kako izgleda prihodnost vodenja.«
Nasveti za negovanje meritokracije
Meritokracija je temeljna vrednota odprtokodne skupnosti. Za nas ni pomembno, na kateri stopnji piramide se nahajate, pomembno je, kako dobre so vaše ideje. Jim predlaga naslednje:
- Nikoli ne recite: "To hoče šef" in ne zanašajte se na hierarhijo. To vam lahko pomaga kratkoročno, vendar tako ne zgradite meritokracije.
- Javno priznajte uspehe in pomembne prispevke. To je lahko preprosto zahvalno e-poštno sporočilo s kopijo celotne ekipe.
- Razmislite: ali je vaša avtoriteta funkcija vašega položaja v hierarhiji (ali dostopa do privilegiranih informacij) ali je rezultat spoštovanja, ki ste si ga prislužili? Če je prvo, začnite delati na drugem.
- Prosite za povratne informacije in zbirajte ideje o določeni temi. Odzvati se je treba na vse, preizkusiti le najboljše. Vendar ne vzemite le najboljših idej in nadaljujte z njimi – izkoristite vsako priložnost za krepitev duha meritokracije in dajte priznanje vsem, ki si to zaslužijo.
- Prepoznajte vzornega člana svoje ekipe tako, da mu ponudite zanimivo nalogo, tudi če ni na njihovem običajnem delovnem področju.
Naj vaše rock zvezde sledijo svoji strasti
Entuziazem in vključenost sta dve zelo pomembni besedi v odprti organizaciji. V knjigi se nenehno ponavljajo. Toda strastnih ustvarjalnih ljudi ne morete pripraviti do trdega dela, kajne? V nasprotnem primeru preprosto ne boste dobili vsega, kar ponuja njihov talent. Pri Red Hatu so ovire za lastne projekte čim bolj odpravljene:
»Da bi spodbudila inovacije, podjetja poskušajo marsikaj. Googlov pristop je zanimiv. Odkar je Google leta 2004 postal poznan v vsakem domu, so vodilni in ideologi v internetnem poslu poskušali razvozlati glavno skrivnost podjetja, da bi ponovili njegov osupljiv uspeh. Eden najbolj znanih, a trenutno zaprtih programov je bil, da so morali vsi Googlovi zaposleni porabiti 20 odstotkov svojega časa za skoraj vse, kar želijo. Zamisel je bila, da bodo zaposleni začeli uvajati inovacije, če bodo sledili lastnim projektom in idejam, do katerih so bili navdušeni zunaj službe. Tako so nastali uspešni projekti tretjih oseb: GoogleSuggest, AdSense za vsebino in Orkut; vsi so izhajali iz tega 20-odstotnega poskusa – impresiven seznam! […]
Pri Red Hatu imamo manj formalen pristop. Nimamo določene politike glede tega, koliko časa naj vsak od naših zaposlenih porabi za »inovacije«. Namesto da bi ljudem namenili čas za samoizobraževanje, poskrbimo, da si zaposleni zaslužijo pravico, da svoj čas porabijo za učenje novih stvari. Resnici na ljubo ima marsikdo tega časa zelo malo, so pa tudi takšni, ki lahko za inovacije porabijo skoraj ves delovni dan.
Najbolj tipičen primer izgleda nekako takole: nekdo dela na stranskem projektu (če je vodjem razložil njegov pomen – neposredno na delovnem mestu; ali izven delovnega časa – na lastno pobudo), kasneje pa lahko to delo zavzame vse njegove trenutne ure."
Več kot pametovanje
»Lirična digresija. Alex Fakeney Osborne je izumitelj metode možganske nevihte, katere nadaljevanje je danes metoda sinektike. Zanimivo je, da se je ta ideja pojavila med drugo svetovno vojno, ko je Osborne poveljeval eni od ladij ameriškega tovornega konvoja, ki je bil v nevarnosti torpednega napada nemške podmornice. Nato se je kapitan spomnil tehnike, h kateri so se zatekali pirati v srednjem veku: če je posadka zašla v težave, so se vsi mornarji zbrali na palubi in izmenično predlagali način za rešitev težave. Idej je bilo veliko, tudi na prvi pogled absurdnih: na primer ideja, da bi s celotno ekipo pihali na torpedo. Toda s curkom ladijske črpalke, ki je na voljo na vsaki ladji, je povsem mogoče upočasniti torpedo ali celo spremeniti njegovo smer. Posledično je Osborne celo patentiral izum: na bok ladje je nameščen dodaten propeler, ki poganja tok vode ob bok, torpedo pa drsi ob njem.«
Naš Jim nenehno ponavlja, da ni tako lahko delati v odprti organizaciji. Tudi vodstvo dobi, saj nikomur ni prihranjeno zagovarjanje svojega mnenja. Toda to je ravno pristop, ki je potreben za doseganje odličnih rezultatov:
»Spletni [odprtokodni] forumi in klepetalnice so pogosto polni živahnih in včasih ostrih razprav o vsem, od tega, kako najbolje popraviti napako v programski opremi, do tega, katere nove funkcije je treba upoštevati pri naslednji posodobitvi. Praviloma je to prva faza razprav, v kateri se podajajo in kopičijo nove ideje, vedno pa sledi naslednji krog - kritična analiza. Čeprav lahko v teh razpravah sodeluje kdorkoli, mora biti človek pripravljen braniti svoje stališče z vsemi močmi. Nepriljubljene ideje bodo v najboljšem primeru zavrnjene, v najslabšem pa zasmehovane.
Tudi Linus Torvalds, ustvarjalec operacijskega sistema Linux, izraža svoje nestrinjanje s predlaganimi spremembami kode. Nekega dne sta se Linus in David Howells, eden od vodilnih razvijalcev Red Hata, zapletla v vročo razpravo o prednostih spremembe kode, ki jo je zahteval Red Hat in ki bi pomagala zagotoviti varnost našim strankam. V odgovor na Howellsovo zahtevo je Torvalds zapisal: »Odkrito povedano, to je [nenatisljiva beseda] idiotsko. Zdi se, da se vse vrti okoli teh neumnih vmesnikov in to iz popolnoma neumnih razlogov. Zakaj bi morali to narediti? Obstoječi razčlenjevalnik X.509 mi ni več všeč. Ustvarjajo se neumni zapleteni vmesniki in zdaj jih bo 11. – Linus 9.«
Če pustimo tehnične podrobnosti ob strani, je Torvalds v naslednjem sporočilu nadaljeval s pisanjem v istem duhu – in to tako, da si ne upam citirati. Ta spor je bil tako glasen, da je prišel celo na strani The Wall Street Journala. […]
Ta razprava kaže, da večina podjetij, ki proizvajajo lastniško, neprosto programsko opremo, nima odprte razprave o tem, na katerih novih funkcijah ali spremembah morda delajo. Ko je izdelek pripravljen, ga podjetje preprosto pošlje strankam in gre naprej. Hkrati pa v primeru Linuxa razprave o tem, katere spremembe so potrebne in - kar je najpomembneje - zakaj so potrebne, ne pojenjajo. Zaradi tega je celoten proces seveda veliko bolj neurejen in dolgotrajen.«
Izpustite zgodaj, izpustite pogosto
Prihodnosti ne moremo napovedati, zato moramo samo poskusiti:
»Delujemo po načelu »zgodnji zagon, pogoste posodobitve«. Ključna težava vsakega projekta programske opreme je tveganje napak ali hroščev v izvorni kodi. Očitno je, da več sprememb in posodobitev je zbranih v eni izdaji (različici) programske opreme, večja je verjetnost, da bodo v tej različici napake. Razvijalci odprtokodne programske opreme so spoznali, da se s hitrim in pogostim objavljanjem različic programske opreme zmanjša tveganje za resne težave s katerim koli programom - navsezadnje ne prinašamo vseh posodobitev na trg naenkrat, temveč eno za drugo za vsako različico. Sčasoma smo opazili, da ta pristop ne le zmanjšuje napake, ampak vodi tudi do bolj zanimivih rešitev. Izkazalo se je, da nenehne majhne izboljšave dolgoročno ustvarjajo več inovacij. Morda tukaj ni nič presenetljivega. Eno od ključnih načel sodobnih proizvodnih procesov, kot sta kaizen a ali lean b, je osredotočenost na majhne in postopne spremembe in posodobitve.
[…] Veliko tega, na čemer delamo, morda ne bo uspelo. Toda namesto da bi porabili veliko časa za razmišljanje, kaj bo delovalo in kaj ne, raje izvajamo majhne poskuse. Najbolj priljubljene ideje bodo pripeljale do uspeha, tiste, ki ne delujejo, pa bodo same od sebe izginile. Na ta način lahko preizkusimo veliko stvari in ne samo eno, brez večjega tveganja za podjetje.
To je racionalen način razporejanja sredstev. Ljudje me na primer pogosto sprašujejo, kako izbiramo, katere odprtokodne projekte bomo komercializirali. Medtem ko včasih dajemo pobudo za projekte, pogosteje preprosto skočimo v obstoječe. Majhna skupina inženirjev – včasih samo ena oseba – začne prispevati k enemu od projektov odprtokodne skupnosti. Če je projekt uspešen in ima povpraševanje med našimi strankami, začnemo vanj vlagati več časa in truda. Če ne, razvijalci nadaljujejo z novim projektom. Do trenutka, ko se odločimo za komercializacijo predloga, je projekt morda že tako zrasel, da je rešitev očitna. Različni projekti, vključno s tistimi, ki niso programski, se naravno pojavljajo v Red Hatu, dokler vsem ne postane jasno, da bo zdaj nekdo moral na tem delati s polnim delovnim časom.«
Tukaj je še en citat iz knjige:
»Spoznal sem, da morajo imeti jutrišnji vodje lastnosti, ki so v običajnih organizacijah preprosto spregledane, če želijo izpolniti to vlogo. Za učinkovito vodenje odprte organizacije mora vodja imeti naslednje lastnosti.
- Osebna moč in samozavest. Običajni voditelji uporabljajo položajno moč – svoj položaj – za doseganje uspeha. Toda v meritokraciji si morajo voditelji zaslužiti spoštovanje. In to je mogoče le, če se ne bojijo priznati, da nimajo vseh odgovorov. Biti morajo pripravljeni razpravljati o težavah in hitro sprejemati odločitve, da bi s svojo ekipo našli najboljše rešitve.
- Potrpežljivost. Mediji redko govorijo o tem, kako "potrpežljiv" je vodja. Ampak res mora biti potrpežljiv. Ko se trudite, da bi vaša ekipa dosegla najboljše rezultate in se pogovarjate ure in ure ter stvari ponavljate znova in znova, dokler ni dobro opravljeno, morate biti potrpežljivi.
- Visok EQ (čustvena inteligenca). Prepogosto promoviramo inteligenco vodij tako, da se osredotočamo na njihov IQ, medtem ko je tisto, kar je resnično treba upoštevati, njihov količnik čustvene inteligence ali rezultat EQ. Biti najpametnejša oseba med drugimi ni dovolj, če ne znaš delati s temi ljudmi. Ko delate s skupnostmi angažiranih zaposlenih, kot je Red Hat, in nimate možnosti nikomur ukazovati, postane vaša sposobnost poslušanja, analitične obdelave in ne jemanja stvari osebno izjemno dragocena.
- Drugačna mentaliteta. Vodje, ki so izhajali iz tradicionalnih organizacij, so bili vzgojeni v duhu quid pro quo (latinsko »quid pro quo«), po katerem mora vsako dejanje dobiti ustrezno povračilo. Ko pa želite vlagati v izgradnjo določene skupnosti, morate razmišljati dolgoročno. To je kot da bi poskušali zgraditi občutljivo uravnotežen ekosistem, kjer lahko vsak napačen korak povzroči neravnovesje in privede do dolgoročnih izgub, ki jih morda ne opazite takoj. Vodje se morajo znebiti miselnosti, ki od njih zahteva doseganje rezultatov danes, za vsako ceno, in začeti poslovati na način, ki jim omogoča, da izkoristijo večje koristi z vlaganjem v prihodnost.«
In zakaj je to pomembno
Red Hat živi in deluje po načelih, ki se zelo razlikujejo od tradicionalne hierarhične organizacije. In deluje, dela nas komercialno uspešne in človeško srečne. To knjigo smo prevedli v upanju, da bomo načela odprte organizacije razširili med ruska podjetja, med ljudi, ki želijo in zmorejo živeti drugače.
, poskusi!
Vir: www.habr.com