A sosit o zi importantă pentru Red Hat, comunitatea rusă open source și toți cei implicați – în limba română a fost publicată . Aceasta detaliază și povestește viu cum noi, la Red Hat, oferim cea mai bună cale celor mai bune idei și celor mai talentați oameni, dar și cum să nu te pierzi în haos și să unești milioane de oameni din întreaga lume.
În plus, această carte este despre viață și despre practică. Conține multe sfaturi pentru toți cei care doresc să învețe cum să construiască o companie pe modelul organizației deschise și să o conducă eficient. Mai jos – câteva dintre cele mai importante principii prezentate în carte, pe care le puteți nota deja acum.
Povestea angajării lui Jim în companie este remarcabilă. Aceasta arată că în lumea codului deschis nu există fanfare, ci o nouă abordare a conducerii:
„După discuția cu recrutorul, am exprimat interesul pentru un interviu, iar el m-a întrebat dacă m-ar deranja să zbor duminică la sediul companiei Red Hat din orașul Raleigh, Carolina de Nord. M-am gândit că duminica este o zi ciudată pentru o întâlnire. Dar, cum oricum plănuiesc să zbor luni la New York, așa că, în general, era pe calea mea, și am fost de acord. M-am urcat în avionul din Atlanta și am aterizat în aeroportul Raleigh-Durham. De acolo am luat un taxi, care m-a lăsat în fața clădirii companiei Red Hat pe campusul Universității Carolina de Nord. Era duminică, iar ceasul arăta 9:30 dimineața, și nu era nimeni în apropiere. Luminile erau stinse și, după ce am verificat, am descoperit că ușile erau încuiate. La început, am crezut că mă bat joc de mine. Întorcându-mă pentru a reveni în taxi, am văzut că acesta a plecat deja. Foarte curând a început să plouă, eu nu aveam umbrelă.
Numai ce mă pregăteam să plec undeva pentru a lua un taxi, când Matthew Szulik, ulterior președinte al consiliului de administrație și director general al companiei Red Hat, a venit cu mașina lui. „Bună, - a salutat el. - Vrei să bei o cafea?” Mi s-a părut un început neobișnuit pentru un interviu, dar știam că am nevoie cu siguranță de o cafea. În final, m-am gândit, îmi va fi mai ușor să apuc un taxi până la aeroport.
Duminica, diminețile în Carolina de Nord sunt destul de liniștite. Ne-a luat ceva timp să găsim o cafenea care să se deschidă înainte de prânz. Cafeneaua s-a dovedit a fi nici cea mai bună din oraș, nici cea mai curată, dar era deschisă și acolo puteam savura o cafea proaspăt preparată. Ne-am așezat la o măsuță și am început discuția.
După aproximativ treizeci de minute, mi-am dat seama că îmi place cum decurg lucrurile; interviul nu a fost tradițional, dar discuția a fost foarte interesantă. În loc să discutăm despre subtilitățile strategiei corporative a companiei Red Hat sau despre imaginea sa pe Wall Street — adică despre ceea ce mă pregătisem — Matthew Schulik a întrebat mai degrabă despre speranțele, visurile și obiectivele mele. Acum înțeleg că Schulik evalua dacă mă pot adapta subculturii și stilului de management al companiei.
După ce am terminat, Schulik mi-a spus că dorește să mă prezinte cu consilierul juridic al companiei, Michael Cunningham, și a propus să ne întâlnim acum, la un prânz devreme. Am fost de acord și ne-am pregătit să plecăm. Apoi, interlocutorul meu a descoperit că nu avea portofelul cu el. „Ups”, a spus el. „Nu am bani. Dar tu?” M-a surprins, dar am răspuns că am bani și nu am nimic împotrivă să plătesc cafeaua.
După câteva minute, Schulik m-a lăsat la o mică taco shack mexicană, unde m-am întâlnit cu Michael Cunningham. Dar din nou nu a avut loc un interviu tradițional sau o întâlnire de afaceri, ci o altă conversație interesantă. Când ne pregăteam să plătim nota, s-a descoperit că restaurantul avea probleme cu terminalul de plată cu cardul, iar noi puteam plăti doar în numerar. Cunningham s-a întors către mine și m-a întrebat dacă sunt pregătit să plătesc, pentru că nu avea bani cash. Având în vedere că mă îndreptam spre New York, aveam mulți bani cash asupra mea, așa că am plătit prânzul.
Cunningham mi-a propus să mă ducă la aeroport, așa că am plecat cu mașina lui. După câteva minute, m-a întrebat: „Te deranjează dacă mă opresc să alimentăm? Vom merge cu viteză maximă”. – „Nicio problemă”, am răspuns eu. De îndată ce am auzit sunetul ritmic al pompei, a bătut cineva în geam. Era Cunningham. „Hei, aici nu acceptă carduri de credit”, mi-a spus el. – „Pot împrumuta puțini bani?” Am început să mă întreb dacă aceasta este cu adevărat o interviu sau vreo înșelătorie.
În ziua următoare, aflându-mă în New York, am discutat cu soția mea despre acest interviu la Red Hat. I-am spus că discuția a fost foarte interesantă, dar nu sunt sigur dacă acești oameni sunt serioși în legătură cu angajarea mea: poate le-a trebuit doar mâncare gratis și benzină? Reflectând acum la acea întâlnire, îmi dau seama că Shulik și Cunningham erau doar oameni deschiși, care mă tratau ca pe oricine altcineva cu care ar putea bea o cafea, a lua prânzul sau a alimenta. Da, este amuzant și chiar hilar că amândoi au rămas fără bani. Dar pentru ei nu era vorba despre bani. Ca și lumea din jurul codului deschis, ei nu credeau în desfășurarea covoarelor roșii sau în încercarea de a convinge candidatul că totul este perfect. Vroiau pur și simplu să mă cunoască mai bine, nu să încerce să impresioneze sau să sublinieze diferențele noastre. Vreau să știe cine sunt.
Primul meu interviu la Red Hat mi-a arătat clar că munca aici are un alt caracter. În această companie nu părea să existe o ierarhie tradițională și un mod special pentru lideri, cel puțin în forma în care este obișnuit în majoritatea celorlalte firme. Cu timpul, am aflat și că Red Hat crede în principiul meritocrației: întotdeauna merită să încerci să implementezi cea mai bună idee, indiferent dacă provine de la conducerea superioară sau de la un stagiar angajat pe termen scurt. Cu alte cuvinte, prima mea impresie despre Red Hat m-a familiarizat cu ce înseamnă viitorul conducerii.
Sfaturi pentru cultivarea meritocrației
Meritocrația este valoarea centrală a comunității de cod deschis. Nu contează ce nivel ocupi în piramidă, important este cât de bune sunt ideile tale. Iată ce propune Jim:
- Nu spuneți niciodată: „Așa vrea șeful” – și nu vă bazați pe ierarhie. Acest lucru poate să vă ajute pe termen scurt, dar nu așa se construiesc meritocrațiile.
- Recunoașteți public succesele și contribuțiile importante la cauza comună. Poate fi un simplu email de mulțumire în care e inclusă întreaga echipă.
- Gândiți-vă: autoritatea dumneavoastră depinde de poziția în ierarhie (sau de accesul la informații privilegiate) sau este rezultatul respectului câștigat de dumneavoastră? Dacă este primul, începeți să lucrați la al doilea.
- Cereriți feedback și adunați idei pe o temă specifică. Trebuie să răspundeți la toate, să puneți în aplicare doar cele mai bune. Dar nu luați pur și simplu cele mai bune idei și continuați cu ele – folosiți orice oportunitate pentru a întări spiritul meritocrației, oferind credit tuturor celor care merită.
- Marcați un membru exemplar al echipei dumneavoastră, oferindu-i o sarcină interesantă, chiar dacă nu ține de domeniul său obișnuit de activitate.
Lăsați-vă „rock star-urile” să își urmeze pasiunea.
Entuziasmul și implicarea sunt două cuvinte foarte importante într-o organizație deschisă. Ele sunt repetate constant în carte. Dar nu puteți obliga oameni creativi pasionați să lucreze „de la început până la sfârșit”, nu-i așa? Altfel, pur și simplu nu veți obține tot ce poate oferi talentul lor. La Red Hat, obstacolele pentru proiectele proprii sunt eliminate cât mai mult posibil:
„Pentru a gestiona inovațiile, companiile încearcă multe. Abordarea companiei Google este interesantă. De când Google, începând cu 2004, a devenit cunoscută în fiecare casă, liderii și ideologii din afaceri online au încercat să descifreze secretul principal al companiei pentru a repeta succesul său impresionant. Una dintre cele mai cunoscute, dar în prezent închise, programe consta în faptul că tuturor angajaților Google li se oferea posibilitatea de a petrece 20% din timpul de muncă practic pe orice își doresc. Ideea era următoarea: dacă angajații ar începe să implementeze propriile proiecte și idei, care îi pasionează în afara muncii, atunci vor începe să creeze inovații. Astfel au apărut proiecte externe de succes: GoogleSuggest, AdSense for Content și Orkut; toate au venit din acest experiment cu 20 de procente – o lista impresionantă! […]
La noi la Red Hat, abordăm lucrurile într-un mod mai puțin formal. Nu avem o politică stabilită referitoare la cât timp trebuie să dedice fiecare angajat „inovației”. În loc să alocăm timp dedicat pentru autoeducație, facem ca angajații să câștige dreptul de a-și folosi timpul pentru nou. Dacă mă voi exprima sincer, mulți au foarte puțin timp pentru aceasta, dar există și cei care pot dedica aproape întreaga zi de lucru inovațiilor.
Cel mai tipic caz arată cam așa: cineva lucrează la un proiect secundar (dacă a explicat managerilor importanța acestuia – chiar la locul de muncă; sau în afara orelor de program – din inițiativa proprie), iar mai târziu acestă muncă poate ocupa toate orele de prezență ale acestuia.
Mai mult decât un brainstorming
«O digresiune lirică. Alex F.A. Osborn este inventatorul metodei de „brainstorming”, continuare a căreia este astăzi metoda sinectică. Interesant este că această idee a apărut în timpul celui de-al Doilea Război Mondial, când Osborn comanda unul dintre vasele caravanei comerciale americane, aflându-se în pericol de atac torpilor de către un submarin german. Atunci, căpitanul și-a amintit de o tehnică folosită de pirați în Evul Mediu: dacă echipajul se afla în dificultate, pe punte se adunau toți marinarii pentru a propune, pe rând, soluții la problemă. Au fost multe idei, inclusiv unele care păreau complet absurde: de exemplu, ideea de a suflă asupra torpilei cu toată echipa. Dar cu jetul pompei de apă de pe fiecare navă, torpila poate fi încetinită sau chiar îndreptată pe o nouă traiectorie. Drept rezultat, Osborn a brevetat chiar invenția: un șurub suplimentar montat pe bordul navei care împinge un jet de apă de-a lungul acestuia, iar torpila alunecă pe lângă.»
Jim nostru repetă constant că nu este atât de simplu să lucrezi într-o organizație deschisă. Chiar și conducerea nu este scutită, deoarece nimeni nu este scutit de nevoia de a-și susține punctul de vedere. Dar anume această abordare este necesară pentru a obține rezultate excelente:
Forumurile online [dezvoltatorilor de cod deschis] și chat-urile sunt adesea pline de discuții animate, uneori chiar incisive, despre tot – de la cum să corectezi cel mai bine o eroare în software, la ce noi caracteristici ar trebui să fie luate în considerare în actualizarea următoare. De obicei, aceasta este prima fază a discuțiilor, în care se aduc și se adună idei noi, dar întotdeauna există o rundă ulterioară – analiza critică. Deși oricine poate participa la aceste dispute, trebuie să fie pregătit să-și apere punctul de vedere cu toate puterile. Ideile nepopulare sunt respinse la cel mai bun caz și, în cel mai rău caz, ridiculizate.
Chiar și Linus Torvalds, creatorul sistemului de operare Linux, își exprimă dezacordul față de modificările propuse în cod. Odată, Linus și David Howell, unul dintre dezvoltatorii de frunte ai companiei Red Hat, au intrat într-o polemică aprinsă privind avantajele modificării codului solicitate de compania Red Hat, care ar ajuta la asigurarea securității clienților noștri. În răspuns la cererea lui Howell, Torvalds a scris: „Sincer, este [cuvânt vulgar] o idioțenie. Totul pare să se învârtă în jurul acestor interfețe stupide și din motive complet idioate. De ce ar trebui să facem asta? Nu-mi place parserul existent X.509. Se creează interfețe idioate și complicate și acum vor fi 11. – Linus 9.”
Lăsând la o parte detaliile tehnice, Torvalds în următorul mesaj a continuat să scrie în același ton – și într-un mod pe care nu îndrăznesc să-l citez. Această dispută a fost atât de zgomotoasă încât a ajuns chiar pe paginile The Wall Street Journal. […]
Această dispută arată că în majoritatea companiilor care produc programe proprii, ne-libere, nu există dezbateri deschise despre ce caracteristici noi sau modificări ar putea fi lucrate. Atunci când produsul este gata, compania pur și simplu îl trimite clienților și își continuă calea. În același timp, în cazul Linux, discuțiile despre ce modificări sunt necesare și – cel mai important – de ce sunt necesare, nu se stind. Acest lucru, bineînțeles, face întregul proces mult mai haotic și laborios.
Publicați devreme, publicați adesea
Nu putem prezice viitorul, așa că trebuie să încercăm:
«Acționăm după principul „lansare timpurie, actualizări frecvente”. Principala problemă a oricărui proiect software este riscul de erori sau bug-uri în codul sursă. Este evident că cu cât mai multe modificări și actualizări sunt acumulate într-o singură lansare (versiune) a software-ului, cu atât mai mare este probabilitatea ca această versiune să aibă bug-uri. Dezvoltatorii de software cu sursă deschisă au realizat că, prin lansări rapide și frecvente, riscul de probleme serioase cu orice aplicație este redus – deoarece nu lansăm toate actualizările deodată, ci pe porții pentru fiecare versiune. De-a lungul timpului, am observat că această abordare nu doar că reduce numărul de erori, ci conduce și la soluții mai interesante. Se pare că, prin aducerea constantă de îmbunătățiri mici, se generează, în cele din urmă, mai multe inovații. Poate că nu este nimic surprinzător în asta. Unul dintre principiile cheie ale proceselor moderne de producție, cum ar fi kaizen a sau lean b, este concentrarea asupra modificărilor și actualizărilor mici și progresive.
[…] Multe dintre lucrurile la care lucrăm pot să nu aibă succes. Însă, în loc să pierdem mult timp gândindu-ne ce va funcționa și ce nu, preferăm să facem experimente mici. Cele mai solicitate idei vor avea succes, iar cele care nu vor funcționa se vor stinge de la sine. Astfel, putem încerca multe, nu doar unul, și asta fără un risc semnificativ pentru companie.
Aceasta este o modalitate rațională de alocare a resurselor. De exemplu, oamenii mă întreabă adesea cum alegem care dintre proiectele cu sursă deschisă ar trebui comercializate. Deși uneori inițiem proiecte, de cele mai multe ori ne conectăm la cele existente. Un mic grup de ingineri – și uneori o singură persoană – începe să contribuie la unul dintre proiectele comunității de sursă deschisă. Dacă proiectul este de succes și este solicitat de clienții noștri, începem să investim mai mult timp și efort în acesta. Dacă nu, dezvoltatorii trec la un nou proiect. La momentul la care decidem să comercializăm oferta, proiectul poate fi extins atât de mult încât decizia devine evidentă. O varietate de proiecte, inclusiv cele care nu țin de software, apar în mod natural în întreaga companie Red Hat, până când devine clar pentru toată lumea că acum cineva trebuie să se ocupe de acest lucru constant.
Iată încă o citat din carte:
„Am realizat că, pentru a corespunde unei astfel de roluri, conducătorii de mâine trebuie să se distanțeze prin caracteristici la care organizațiile obișnuite pur și simplu nu acordă atenție. Pentru a conduce eficient o organizație deschisă, conducătorul trebuie să aibă următoarele calități.
- Puterea personală și încrederea. Conducătorii obișnuiți folosesc puterea de poziție – funcția lor – pentru a avea succes. Dar, în contextul meritocrației, conducătorii trebuie să merite respectul. Și acest lucru este posibil doar dacă nu le este frică să recunoască că nu au toate răspunsurile la întrebări. Trebuie să fie gata să discute problemele și să ia decizii rapid, pentru a găsi cele mai bune soluții împreună cu echipa lor.
- Răbdare. Mass-media povestește rar despre cât de „răbdător” este un conducător. Dar el trebuie cu adevărat să fie răbdător. Atunci când lucrezi pentru a obține de la echipa ta maximul de eforturi și rezultate, dialogul durează ore întregi, și repeți lucruri din nou și din nou până când totul este realizat corect, trebuie să ai răbdare.
- Inteligența emoțională ridicată (EQ). Adesea, ne concentrăm pe abilitățile intelectuale ale liderilor, punând accent pe IQ-ul lor, când de fapt ar trebui să luăm în considerare și coeficientul de inteligență emoțională, sau evaluarea EQ. A fi cea mai deșteaptă persoană dintr-un grup nu este suficient dacă nu poți colabora cu acești oameni. Când lucrezi cu comunități de angajați implicați, precum în Red Hat, și nu ai puterea de a ordona cuiva, capacitatea ta de a asculta, de a analiza informațiile și de a nu lua totul personal devine extrem de valoroasă.
- O mentalitate diferită. Liderii veniți din organizații tradiționale au fost educați într-un spirit de quid pro quo (lat. „serviciu pentru serviciu”), conform căruia fiecare acțiune ar trebui să primească o compensație adecvată. Însă atunci când intenționezi să investești în crearea unei comunități, trebuie să gândești pe termen lung. Este ca și cum ai încerca să construiești un ecosistem delicat, în care orice pas greșit poate provoca un dezechilibru și duce la pierderi pe termen lung, pe care nu le poți observa imediat. Liderii trebuie să renunțe la tipul de gândire care le solicită rezultate imediate, cu orice preț, și să înceapă un mod de afaceri care să aducă beneficii mari prin investițiile în viitor.
Și de ce este important
Red Hat trăiește și lucrează conform unor principii care diferă semnificativ de cele ale unei organizații tradiționale cu structură ierarhică. Și aceasta funcționează, ne face comercial de succes și uman fericiți. Am tradus această carte în speranța de a răspândi principiile organizației deschise în rândul companiilor rusești, printre cei care doresc și pot trăi diferit.
, încercați!
Sursa: habr.com
