Fontos nap érkezett a Red Hat számára, az orosz open source közösségnek és minden érintettnek – orosz nyelven megjelent . Részletesen és élvezetesen ismerteti, hogyan adjuk a legjobb ötleteknek és a legtehetségesebb embereknek az utat a Red Hat-ben, valamint arról, hogyan lehet a káoszban nem elveszni és összehozni milliókat szerte a világon.
Ezenkívül ez a könyv az életről és a gyakorlati tapasztalatokról szól. Sok tanácsot tartalmaz mindazok számára, akik meg akarják tanulni, hogyan lehet nyitott szervezet modelljében működő céget építeni és hatékonyan irányítani azt. Íme néhány legfontosabb alapelv, amely a könyvben szerepel, és amelyet már most figyelembe vehet.
Jim vállalati alkalmazása figyelemre méltó. Megmutatja, hogy a nyílt kód világában nincsenek fanfárok, de van egy új megközelítés a vezetéshez:
"A toborzóval folytatott beszélgetés után kifejeztem érdeklődésemet egy interjú iránt, és ő megkérdezte, hogy nem lenne-e ellenemre, ha vasárnap elrepülnék a Red Hat központjába Raleigh-be, Észak-Karolinába. Azt gondoltam, hogy a vasárnap furcsa nap a találkozóra. De mivel egyébként hétfőn New Yorkba mentem, lényegében elérhető volt, ezért beleegyeztem. Felszálltam az Atlantából induló repülőgépre, és a Raleigh-Durham repülőtéren szálltam le. Onnan taxit hívtam, ami a Red Hat épülete elé tett le a North Carolina Egyetem campusán. Vasárnap volt, 9:30-kor, és senki sem volt a közelben. A fények ki voltak kapcsolva, és miután ellenőriztem, észrevettem, hogy az ajtók zárva vannak. Először azt hittem, hogy megtréfálnak. Amikor megfordultam, hogy visszatérjek a taxiba, láttam, hogy már elment. Hamarosan elkezdett esni, esernyőm nem volt.
Csak akkor készültem elindulni, hogy taxit hívjak, amikor Matthew Szulik, a Red Hat igazgatótanácsának elnöke és vezérigazgatója, felhajtott az autójával. "Helló, – köszöntött. – Szeretne egy kávét?" Ez számomra szokatlan kezdete tűnt az interjúnak, de tudtam, hogy mindenképpen meg kell innom egy kávét. Végül, gondoltam, később könnyebb lesz taxit hívni a repülőtérre.
Vasárnap reggel Észak-Karolinában meglehetősen csendes volt. Egy kis időbe telt, mire megtaláltuk a kávézót, amely reggel nyitott. A kávézó nem volt a legjobb a városban, és nem is a legszebb, de működött, és lehetett frissen főzött kávét inni. Leültünk egy asztalhoz, és elkezdtük a beszélgetést.
Körülbelül harminc perc múlva rájöttem, hogy tetszik, ahogy minden megy; a interjú nem volt hagyományos, de a beszélgetés nagyon érdekesnek bizonyult. Ahelyett, hogy a Red Hat vállalat vállalati stratégiájáról vagy a Wall Street-i imázsáról beszélgettünk volna – amihez készültem –, Matthew Shulik inkább a reményeimről, álmaimról és céljaimról kérdezett. Most már világos számomra, hogy Shulik azt mérte fel, hogy illeszkedem-e a vállalat szubkultúrájába és vezetési stílusába.
Miután végeztünk, Shulik közölte, hogy szeretné, ha megismerném a vállalat fő jogtanácsosát, Michael Cunningham-t, és javasolta, hogy most azonnal találkozzunk vele egy korai ebéden. Beleegyeztem, és elindultunk. Ekkor a beszélgetőtársam ráeszmélt, hogy nincs nála tárca. "Ups, - mondta. - Nincs pénzem. Neked van?" Meglepetten érintett, de válaszoltam, hogy van pénzem, és szívesen kifizetem a kávét.
Néhány perc múlva Shulik egy kis mexikói étkezdénél állított le, ahol találkoztam Michael Cunningham-nal. De újra nem történt meg a hagyományos interjú vagy üzleti találkozó, viszont egy újabb érdekes beszélgetés alakult ki. Amikor a számlát akartuk rendezni, kiderült, hogy az étteremben elromlott a bankkártyás fizetőgép, és csak készpénzes fizetést tudnak fogadni. Cunningham hozzám fordult, és megkérdezte, készen állok-e kifizetni, mert neki nincs készpénze. Mivel New Yorkba készültem, sok készpénzem volt, így én fizettem az ebédért.
Canningem felajánlotta, hogy elvisz a repülőtérre, és beszálltunk az autójába. Pár perc múlva megkérdezte: "Nem bánja, ha megállok tankolni? Sűrűn fogunk száguldani". – "Nincs probléma" – válaszoltam. Ahogy meghallottam a pumpa ritmikus zúgását, kopogás hallatszott az ablakon. Canningem volt az. "Hé, itt nem fogadják el a hitelkártyákat – mondta. – Kölcsönkérhetnék egy kis pénzt?" Kezdtem azon tűnődni, hogy ez valóban egy interjú, vagy csak valami átverés.
Másnap, amikor New Yorkban voltam, megbeszéltem a feleségemmel ezt az interjút a Red Hat-nél. Elmondtam neki, hogy a beszélgetés nagyon érdekes volt, de nem vagyok biztos benne, hogy ezek az emberek komolyan gondolják, hogy fel akarnak venni: talán csak ingyen ételre és üzemanyagra volt szükségük? Ma, amikor visszaemlékszem arra a találkozóra, megértem, hogy Shulik és Canningem egyszerűen nyitott emberek voltak, akik úgy bántak velem, mint bármelyik másik személlyel, akivel kávézhattak, ebédelhettek vagy tankolhattak. Igen, vicces és még mulatságos is, hogy mindketten pénz nélkül maradtak. De számukra nem a pénzről szólt a dolog. Ők, akárcsak az open source körüli világ, nem hittek a vörös szőnyegek leterítésében vagy abban, hogy próbálják meggyőzni a kérdezettet, hogy minden tökéletes. Csak jobban meg akartak ismerni, és nem próbálták lenyűgözni vagy hangsúlyozni a különbségeinket. Tudni akarták, ki vagyok.
Az első interjúm a Red Hat-nél egyértelműen megmutatta, hogy itt más a munka jellege. Ezen a cégnél nem volt tapasztalható hagyományos hierarchia, és nem voltak külön szabályok a vezetők számára, legalábbis abban a formában, ahogyan a legtöbb más cégnél megszokott. Idővel azt is megtudtam, hogy a Red Hat hisz a meritokrácia elvében: mindig érdemes megvalósítani a legjobb ötleteket, függetlenül attól, hogy azok a felső vezetéstől vagy egy nyári munkás gyakornoktól származnak. Más szavakkal, a Red Hat-ről alkotott első benyomásom bemutatott engem, hogy milyen a jövőbeli vezetés.
Tippek a meritokrácia előmozdításához
A meritokrácia a nyílt forráskódú közösség legfontosabb értéke. Nem számít, milyen rangot töltesz be a piramisban, csak az, mennyire jók az ötleteid. Ezt ajánlja Jim:
- Soha ne mondd: „Így akarja a főnök” – és ne támaszkodj a hierarchiára. Ez segíthet rövid távon, de a meritokráciát így nem lehet felépíteni.
- Nyilvánosan ismerd el a sikereket és a fontos hozzájárulásokat a közös cél érdekében. Ez lehet egy egyszerű köszönő e-mail, amelyet az egész csapatnak elküldenek.
- Gondolkodj el rajta: a tekintélyed a hierarchiából (vagy a privilegizált információkhoz való hozzáférésből) származik, vagy pedig az általad megkeresett tisztelet eredménye? Ha az első, kezdd el dolgozni a másodikon.
- Kérj visszajelzést és gyűjts ötleteket egy konkrét témában. Mindenre reagálj, a legjobbat próbáld ki. De ne csak vedd el a legjobb ötleteket és haladj vele tovább – használd ki minden lehetőséget a meritokrácia szellemének megerősítésére, elismerve mindazokat, akik megérdemlik.
- Ismerj el egy példaértékű csapattagot érdekes feladattal, még akkor is, ha az nem tartozik a megszokott tevékenységi körébe.
Hagyd, hogy a rockcsillagjaid követhessék a szenvedélyüket.
A lelkesedés és az elkötelezettség – ez a két szó rendkívül fontos egy nyitott szervezetben. A könyvben folyamatosan ismétlik. De nem tudod kényszeríteni a szenvedélyes kreatív embereket, hogy „tól ig” dolgozzanak, ugye? Különben nem kapnád meg mindazt, amit a tehetségük kínálhat. A Red Hat-nél a saját projektek előtt álló akadályokat maximálisan csökkentik:
„A vállalatok sok mindent kipróbálnak az innovációk irányításához. Érdekes a Google megközelítése. Mióta a Google 2004 óta ismert minden háztartásban, a vezetők és az internetes üzletág ideológusai megpróbálták megfejteni a cég titkát, hogy megismételhessék a lenyűgöző sikerét. Az egyik legismertebb, de jelenleg zárva lévő program az volt, hogy a Google alkalmazottainak 20%-át javasolták arra, hogy szinte bárminek szenteljék, amihez kedvük van. Az ötlet az volt, hogy ha az alkalmazottak elkezdenek saját projekteket és ötleteket megvalósítani, amelyek iránt lelkesednek a munka mellett, akkor innovációkat fognak létrehozni. Így születtek a sikeres külső projektek: a Google Suggest, az AdSense for Content és az Orkut; mindezek ebből a 20%-os kísérletből származnak – lenyűgöző lista! […]
A Red Hat-nél nem annyira hivatalos megközelítést alkalmazunk. Nincs megszabott politika arra vonatkozóan, hogy minden munkatársunk mennyi időt tölthet 'innovációval'. Ahelyett, hogy az embereknek külön időt biztosítanánk az önképzésre, arra törekszünk, hogy munkatársaink megszerezzék a jogot arra, hogy új dolgokra fordítsák az idejüket. Őszintén szólva, sokaknak elég kevés ideje van erre, míg mások szinte az egész munkanapjukat innovációval tölthetik.
A legtipikusabb eset körülbelül így néz ki: valaki egy külső projektet végez (ha elmagyarázta a menedzsereknek a jelentőségét – közvetlenül a munkahelyén; vagy nem munkaidőben – saját kezdeményezésből), majd később ez a munka akár az összes munkaidejét is elfoglalhatja.
Több, mint ötletelés
Egy lírai kitérő: Alex Faikney Osborn – az ötletelési módszer feltalálója, amelynek folytatása ma a szinergiák módszere. Érdekes, hogy ez az ötlet a második világháború alatt született, amikor Osborn az amerikai áruszállító konvoj egyik hajójának parancsnoka volt, amely német tengeralattjáró torpedó támadásának volt kitéve. Akkor a kapitány emlékezett arra a technikára, amit a középkori kalózok alkalmaztak: ha a legénység bajba került, a fedélzeten összegyűltek a tengerészek, hogy sorban javasoljanak megoldást a problémára. Rengeteg ötlet merült fel, köztük első pillantásra abszurdnak tűnők is: például, hogy fújni kéne a torpedóra az egész legénységgel. De a hajón lévő szivattyú áramlásával a torpedót valóban le lehet lassítani vagy akár az irányát is meg lehet változtatni. Ennek eredményeként Osborn még szabadalmaztatta a találmányt: a hajó oldalára egy plusz propellert szerelnek fel, amely vízsugár terelésére szolgál, míg a torpedó az oldalán csúszik.
Jim folyamatosan hangsúlyozza, hogy nyitott szervezetben nem olyan könnyű dolgozni. Még a vezetőknek sem könnyű, mert senki sem mentes attól, hogy megvédje a saját véleményét. De pontosan ez a megközelítés szükséges a kiváló eredmény eléréséhez:
Az online fórumok [nyílt forráskódú fejlesztők] és csevegések gyakran élénk, néha pedig éles vitákkal telítettek mindarról, hogy hogyan lehet a legjobban javítani egy szoftverhibát, és hogy milyen új funkciókat érdemes megfontolni a következő frissítés során. általában ez a vita első fázisa, ahol új ötletek merülnek fel és halmozódnak, de mindig van egy következő kör is – a kritikai elemzés. Bárki részt vehet ezekben a vitákban, az embereknek fel kell készülniük arra, hogy minden erővel védjék álláspontjukat. A népszerűtlen ötleteket legjobb esetben elutasítják, legrosszabb esetben kigúnyolják.
Még Linus Torvalds, a Linux operációs rendszer megalkotója is kifejezi véleménykülönbségét a kódra javasolt változtatásokkal kapcsolatban. Egyszer Linus és David Howell, a Red Hat egyik vezető fejlesztője heves vitába kezdett a Red Hat által kért kódmódosítások előnyeiről, ami segíthetne biztosítani az ügyfeleink biztonságát. Howell kérésére Torvalds azt válaszolta: „Őszintén szólva, ez [csúnya szó] idiótaság. Mindennek a körülöttük levő buta interfészek körül kell forognia, teljesen idióta okok miatt. Miért kellene ezt tennünk? Már nem tetszik a jelenlegi X.509 elemző. Idióta, bonyolult interfészeket hoznak létre, és most már 11 lesz belőlük. – Linus 9.”
A technikai részleteket félretéve, Torvalds a következő üzenetében továbbra is hasonló szellemben írt – olyan dolgokról, amelyeket nem mernék idézni. Ez a vita olyan hangosan zajlott, hogy még a The Wall Street Journal hasábjain is megjelent. […]
Ez a vita megmutatja, hogy a legtöbb vállalat, amely tulajdonjogú, nem szabad szoftvereket készít, nem folytat nyílt vitákat arról, milyen új jellemzőkön vagy változtatásokon dolgoznak. Amikor egy termék elkészül, a cég egyszerűen eljuttatja azt az ügyfelekhez, és továbblép. Ezzel szemben a Linux esetében a szükséges változtatásokról – és ami a legfontosabb, hogy miért van szükség rájuk – folytatott viták sosem csitulnak. Ez természetesen sokkal szorosabbá és időigényesebbé teszi az egész folyamatot.
Kiadás korán, kiadás gyakran
Nem tudjuk megjósolni a jövőt, ezért csak próbálkozni kell:
A "korai indulás, gyakori frissítések" elve alapján működünk. A programprojektek egyik kulcsfontosságú problémája a forráskód hibáinak vagy bugjainak kockázata. Nyilvánvaló, hogy minél több változtatás és frissítés gyűlik össze egy szoftververzióban, annál nagyobb a valószínűsége annak, hogy a verzióban hibák találhatók. Az open source szoftverfejlesztők felismerték, hogy a gyors és gyakori verziókiadás csökkenti a komoly problémák kockázatát bármely programmal kapcsolatban – hiszen nem mindent egyszerre hozunk a piacra, hanem minden verzióhoz külön frissítéssel járulunk hozzá. Idővel észrevettük, hogy ez a megközelítés nemcsak a hibák számát csökkenti, hanem érdekesebb megoldásokhoz is vezet. Kiderült, hogy a folyamatos apró fejlesztések végső soron több innovációt eredményeznek. Lehet, hogy ebben nincs semmi meglepő. A modern gyártási folyamatok, mint a kaizen vagy lean, egyik kulcsfontosságú elve a kis léptékű és fokozatos változásokra és frissítésekre való összpontosítás.
[…] Azon sok minden, amin dolgozunk, nem necessarily vezet sikerhez. De ahelyett, hogy rengeteg időt töltenénk azzal, hogy kitaláljuk, mi működik és mi nem, inkább kisebb kísérleteket végzünk. A legkeresettebb ötletek sikerhez vezetnek, míg azok, amelyek nem működnek, maguktól elhalványulnak. Így sok mindent kipróbálhatunk, nem csupán egyet, és mindezt a cég számára minimális kockázattal.
Ez egy racionális módja az erőforrások elosztásának. Például az emberek gyakran megkérdezik tőlem, hogyan választjuk ki, hogy a nyílt forráskódú projektek közül melyeket érdemes kereskedelmi célra használni. Bár néha kezdeményezünk projekteket, gyakrabban egyszerűen csatlakozunk a meglévőkhöz. Egy kis mérnöki csapat – néha akár egy ember is – elkezd hozzájárulni az egyik nyílt forráskódú közösségi projekthez. Ha a projekt sikeres és igény van rá az ügyfeleink részéről, akkor több időt és energiát kezdünk ráfordítani. Ha nem, a fejlesztők átállnak egy új projektre. Mire eldöntjük, hogy kereskedelmi célra alakítjuk a terméket, a projekt olyan mértékben megnőhet, hogy a döntés nyilvánvalóvá válik. Számos különböző projekt, beleértve a szoftverhez nem kapcsolódóakat is, természetesen felmerül a Red Hat cégen belül, míg végül mindenkinek világossá válik, hogy mostantól valakinek folyamatosan foglalkoznia kell ezekkel.
Íme egy újabb idézet a könyvből:
„Rájöttem, hogy a holnapi vezetőknek, hogy megfeleljenek egy ilyen szerepnek, olyan tulajdonságokkal kell rendelkezniük, amelyekre a hagyományos szervezetekben egyszerűen nem figyelnek oda. A nyitott szervezetek hatékony vezetéséhez a vezetőknek az alábbi tulajdonságokkal kell rendelkezniük.
- Személyes erő és önbizalom. A hagyományos vezetők pozíciós hatalmukat – a beosztásukat – használják a siker elérésére. De a meritokráciában a vezetőknek ki kell érdemelniük a tiszteletet. Ez pedig csak akkor lehetséges, ha nem félnek beismerni, hogy nem tudják a válaszokat minden kérdésre. Készen kell állniuk a problémák megvitatására és gyors döntések meghozatalára, hogy a csapatukkal közösen találják meg a legjobb megoldásokat.
- Türelem. A média ritkán számol be arról, hogy mennyire „türelmes” a vezető. Pedig neki tényleg türelmesnek kell lennie. Amikor azon dolgozik, hogy a csapatától a legjobb eredményeket és erőfeszítéseket kapja, órákon át folytat párbeszédet, és újra és újra elmondja ugyanazt, amíg minden tökéletesen el nem készül, akkor türelemre van szüksége.
- Magas EQ (érzelmi intelligencia). Túl gyakran hirdetjük a vezetők intellektuális képességeit, a fókuszálva az IQ-jukra, pedig valójában figyelembe kell venni az érzelmi intelligenciájukat, vagyis az EQ-jukat. A legokosabb embernek lenni mások között nem elég, ha nem tudsz együttműködni ezekkel az emberekkel. Amikor elkötelezett munkavállalói közösségekkel dolgozol, mint a Red Hat esetében, és nincs hatalmad parancsolni valakinek, a képességed, hogy figyelj, analitikusan feldolgozz, és ne vedd magadra a dolgokat, rendkívül értékessé válik.
- Más mentalitás. A hagyományos szervezetekből érkező vezetők a quid pro quo szellemben nőttek fel, amely szerint minden cselekedetnek megfelelő visszautat kell biztosítania. De amikor egy adott közösség létrehozásába fektetsz be, hosszú távon kell gondolkodnod. Olyan ez, mint egy finoman kiegyensúlyozott ökoszisztéma építése, ahol bármely téves lépés egyensúlyzavart okozhat, és hosszú távú veszteségeket eredményezhet, amelyeket nem azonnal vehetsz észre. A vezetőknek meg kell szabadulniuk attól a gondolkodásmódtól, amely az azonnali eredmények elérését várja el tőlük, és olyan üzletmenetet kell folytatniuk, amely hosszú távú hasznot hoz a jövőbe való befektetés révén.
És miért fontos ez
A Red Hat olyan elvek szerint él és dolgozik, amelyek erősen eltérnek a hagyományos, hierarchikus szervezetektől. És ez működik, kereskedelmileg sikeressé tesz minket és emberileg boldoggá. Ezt a könyvet azért fordítottuk, hogy elterjesszük az nyitott szervezet elveit az orosz cégek között, azok között az emberek között, akik másképp akarnak és tudnak élni.
, próbáld ki!
Forrás: habr.com
