Настав важливий день для Red Hat, російської спільноти open source та всіх причетних – російською мовою вийшла . Вона докладно і жваво розповідає, як ми в Red Hat даємо найкращим ідеям та найталановитішим людям дорогу, а ще про те, як не загубитися в хаосі та згуртувати мільйони людей по всьому світу.
А ще ця книга – про життя та практику. У ній багато порад для всіх, хто хоче навчитися будувати компанію за моделлю відкритої організації та ефективно їй керувати. Нижче – кілька найважливіших принципів, наведених у книзі, які ви можете взяти на замітку вже зараз.
Історія працевлаштування Джима в компанію чудова. Вона показує, що у світі відкритого коду немає фанфар, зате є новий підхід до лідерства:
«Після розмови з рекрутером я висловив зацікавленість у співбесіді, і він запитав, чи не буду я проти того, щоб у неділю злітати до штаб-квартири компанії Red Hat у місто Ролі, Північна Кароліна. Я подумав, що неділя – дивний день для зустрічі. Але оскільки я все одно збирався летіти в понеділок до Нью-Йорка, загалом мені було на шляху, і я погодився. Я сів на літак із Атланти і висадився в аеропорту Ролі Дарем. Звідти я взяв таксі, яке висадило мене перед будинком компанії Red Hat на території кампусу Університету Північної Кароліни. Була неділя, на годиннику 9:30 ранку, і нікого поблизу. Світло було вимкнене, і, перевіривши, я виявив, що двері замкнені. Спершу я вирішив, що мене дурять. Повернувшись, щоб повернутись у таксі, я побачив, що воно вже поїхало. Незабаром почався дощ, парасольки в мене не було.
Тільки я зібрався піти кудись, щоб зловити таксі, як Меттью Шулік, пізніше голова ради директорів та генеральний директор компанії Red Hat, підкотив на своїй машині. «Привіт, – привітався він. - Хочете випити каву? Мені це здалося незвичайним початком співбесіди, але я розумів, що мені напевно потрібно випити кави. Зрештою, подумав я, потім мені буде простіше зловити таксі до аеропорту.
У неділю в Північній Кароліні вранці досить тихо. Нам потрібен деякий час, щоб просто знайти кав'ярню, яка відкривалася б раніше полудня. Кав'ярня виявилася не найкращою в місті і не найчистішою, але вона працювала і там можна було випити свіжозвареної кави. Ми сіли за стіл і почали розмову.
Хвилин за тридцять або близько того я зрозумів, що мені подобається, як все йде; співбесіда не була традиційною, але сама розмова виявилася дуже цікавою. Замість того, щоб обговорювати тонкощі корпоративної стратегії компанії Red Hat або її іміджу на Уолл стріт – тобто займатися тим, до чого я підготувався, – Меттью Шулік більше запитував про мої надії, мрії та цілі. Тепер мені зрозуміло, що Шулик оцінював, чи відповідатиму я субкультурі та стилю управління компанії.
Після того, як ми закінчили, Шулик повідомив, що хотів познайомити мене з головним юрисконсультом компанії Майклом Каннінгемом, і запропонував зустрітися з ним тепер же за раннім ланчем. Я погодився, і ми збиралися йти. Потім мій співрозмовник виявив, що він не має з собою гаманця. «Упс, – сказав він. - У мене немає грошей. А у вас?" Це застало мене зненацька, але я відповів, що гроші в мене є, і я не проти того, щоб заплатити за каву.
За кілька хвилин Шулик висадив мене в маленькій мексиканській закусочній, де я зустрівся з Майклом Каннінгемом. Але жодної традиційної співбесіди чи ділової зустрічі знову-таки не було, зате відбулася ще одна цікава розмова. Коли ми збиралися сплатити рахунок, з'ясувалося: у ресторані зламалася машинка для оплати кредитною карткою, і у нас можуть прийняти лише готівку. Каннінгем повернувся до мене і поцікавився, чи готовий я заплатити, бо не мав з собою готівки. Оскільки я збирався до Нью-Йорка, у мене було багато готівки, тому я заплатив за ланч.
Каннінгем запропонував підвезти мене до аеропорту, і ми поїхали його машиною. За кілька хвилин він спитав: «Ви не заперечуєте, якщо я зупинюся і заправлюся? Ми помчимося на всіх парах». – «Немає проблем», – відповів я. Як тільки я почув ритмічний стукіт насоса, пролунав стукіт у вікно. То був Каннінгем. «Гей, тут не беруть кредитні картки, – повідомив він. – Чи можу я позичити трохи грошей?» Я почав запитувати себе, чи справді це співбесіда чи якась афера.
Наступного дня, перебуваючи у Нью-Йорку, я обговорив зі своєю дружиною це інтерв'ю у компанії Red Hat. Я розповів їй, що розмова була дуже цікавою, але я не впевнений, чи всерйоз ці люди мають намір найняти мене на роботу: може, їм просто знадобилися безкоштовна їжа та бензин? Згадуючи сьогодні ту зустріч, я розумію, що Шулик і Каннінгем просто були відкритими людьми і ставилися до мене як до будь-якої іншої людини, разом з якою могли випити каву, пообідати чи заправитися бензином. Так, кумедно і навіть смішно, що вони обоє виявилися без грошей. Але для них справа була не в грошах. Вони, як і світ навколо відкритого коду, не вірили в розкочування червоних килимових доріжок або спроби переконати співрозмовника, що все ідеально. Вони просто прагнули дізнатися мене краще, а не намагалися справити враження чи вказати на наші відмінності. Вони хотіли знати, хто я такий.
Моя перша співбесіда в компанії Red Hat наочно показала мені, що робота тут має інший характер. У цій компанії не спостерігалося традиційної ієрархії та особливого режиму для керівників, принаймні у тій формі, як це заведено в більшості інших компаній. Згодом я також дізнався, що компанія Red Hat вірить у принцип меритократії: завжди варто спробувати втілити найкращу з ідей, незалежно від того, чи вона виходить від вищого керівництва чи від стажера, взятого на літню роботу. Іншими словами, моє перше враження від Red Hat познайомило мене з тим, як виглядає майбутнє лідерства».
Поради щодо культивування меритократії
Меритократія – головна цінність спільноти відкритого коду. Нам не важливо, який ступінь піраміди ти займаєш, головне, наскільки хороші твої ідеї. Ось що пропонує Джім:
- Ніколи не кажіть: "Так хоче бос" - і не покладайтеся на ієрархію. Це може допомогти вам у короткостроковій перспективі, але меритократію так не збудуєш.
- Публічно визнайте успіхи та важливі вклади у спільну справу. Це може бути простий лист подяки, у копії якого – вся команда.
- Подумайте: ваш авторитет залежить від становища в ієрархії (або від доступу до привілейованої інформації) чи є результатом заробленої вами поваги? Якщо перше – почніть працювати над другим.
- Просіть зворотний зв'язок та збирайте ідеї з конкретної теми. Реагувати слід на все, апробувати лише найкраще. Але не просто беріть найкращі ідеї та рухайтеся з ними далі – використовуйте будь-яку можливість зміцнити дух меритократії, віддаючи належне всім, хто на те заслуговує.
- Позначте зразкового члена вашої команди, запропонувавши цікаве доручення, навіть якщо воно не належить до звичної для нього сфери діяльності.
Нехай ваші «рок-зірки» наслідують свою пристрасть
Ентузіазм і залучення - два дуже важливі слова у відкритій організації. У книзі вони постійно повторюються. Але ж ви не можете змусити захоплених творчих людей працювати «від і до», правильно? Інакше просто не отримаєте все, що може запропонувати їхній талант. У Red Hat перешкоди для власних проектів нівелюються максимально:
«Щоб керувати інноваціями, компанії багато чого пробують. Цікавим є підхід компанії Google. Відколи Google, починаючи з 2004 року, стала відома в кожному будинку, керівники та ідеологи в інтернет-бізнесі намагалися розгадати головний секрет компанії, щоб повторити її вражаючий успіх. Одна з найвідоміших, але зараз закритих програм полягала в тому, що всім співробітникам Google пропонувалося витрачати 20 відсотків робочого часу практично на все, що їм заманеться. Ідея полягала в наступному: якщо співробітники реалізуватимуть власні проекти та ідеї, якими захоплені крім роботи, вони почнуть створювати інновації. Так виникли успішні сторонні проекти: GoogleSuggest, AdSense for Content та Orkut; всі вони з'явилися з цього експерименту із 20 відсотками – вражаючий список! […]
Ми в Red Hat застосовуємо менш офіційний підхід. У нас немає встановленої політики щодо того, скільки часу кожен із наших співробітників має витрачати на «інновації». Замість того, щоб відводити людям окремий час на самоосвіту, ми робимо так, щоб співробітники заробляли право витрачати свій час на новий. Якщо відверто, то у багатьох таких часів досить мало, зате є й ті, хто може витрачати на інновації чи не весь робочий день.
Найбільш типовий випадок виглядає приблизно так: хтось працює над стороннім проектом (якщо він пояснив менеджерам його значущість – прямо на робочому місці; або в неробочий час – за власною ініціативою), а пізніше ця робота може займати всі його присутні години».
Більше, ніж мозковий штурм
«Ліричний відступ. Алекс Фейкні Осборн – винахідник методу «мозковий штурм», продовженням якого є метод синектики. Цікаво, що ця ідея з'явилася під час Другої світової війни, коли Осборн командував одним з кораблів американського вантажного каравану, який зазнав небезпеки торпедної атаки німецького підводного човна. Тоді капітан згадав прийом, якого вдавалися пірати Середньовіччя: якщо команда потрапляла в біду, на палубі збиралися всі моряки, щоб почергово запропонувати спосіб вирішення проблеми. Ідей було дуже багато, у тому числі на перший погляд абсурдних: наприклад, ідея подути на торпеду всією командою. Але струменем корабельної помпи, яка є на кожному судні, торпеду можна загальмувати або навіть змінити її курс. В результаті Осборн навіть запатентував винахід: у борт корабля монтується додатковий гвинт, який жене уздовж борту струмінь води, а торпеда ковзає поряд».
Наш Джим постійно повторює, що у відкритій організації не так вже й легко працювати. Навіть керівництву дістається, тому що ніхто не позбавлений необхідності відстоювати свою думку. Але саме такий підхід потрібний для досягнення відмінного результату:
«Онлайн-форуми [розробників відкритого коду] і чати часто наповнені жвавими, котрий іноді дискусіями про все – починаючи з того, як краще виправити помилку в програмному забезпеченні, і закінчуючи тим, які нові функції слід розглянути в черговому оновленні. Як правило, це перша фаза дискусій, у ході яких висуваються та накопичуються нові ідеї, але завжди має місце і наступний раунд – критичний аналіз. Хоча брати участь у цих суперечках може кожен, людині потрібно бути готовою відстоювати свою позицію всіма силами. Непопулярні ідеї в кращому разі відкинуті, у гіршому – висміють.
Навіть Лінус Торвальдс, творець операційної системи Linux, висловлює свою незгоду з пропонованими змінами коду. Якось Лінус і Девід Хауеллс, один з провідних розробників компанії Red Hat, вступили в жарку полеміку з приводу переваг зміни коду, про який просила компанія Red Hat, що допомогло б забезпечити нашим клієнтам безпеку. У відповідь на запит Хауеллса Торвальдс написав: «Щиро кажучи, це [недруковане слово] ідіотизм. Все, здається, крутиться навколо цих дурних інтерфейсів, і з абсолютно ідіотських причин. Чому ми маємо так робити? Мені вже не подобається існуючий парсер X.509. Створюються складні ідіотські інтерфейси, і тепер їх буде 11. – Linus 9».
Залишаючи технічні деталі осторонь, Торвальдс у наступному повідомленні продовжував писати так само – і таке, що я не ризикну цитувати. Цей диспут пролунав так голосно, що навіть потрапив на сторінки The Wall Street Journal. […]
Цей диспут показує, що у більшості компаній, що випускають пропрієтарні, невільні програми, немає відкритих дебатів про те, якими новими характеристиками чи змінами вони можуть працювати. Коли продукт готовий, компанія просто надсилає його клієнтам і рухається далі. У той же час у випадку з Linux дискусії про те, які саме зміни потрібні і – найголовніше – чому вони потрібні, не затихають. Це, звичайно, робить весь процес набагато безладнішим і трудомістким».
Звільняйте раніше, випускайте часто
Ми не можемо передбачати майбутнє, тому маємо просто спробувати:
«Ми діємо за принципом ранній запуск, часті оновлення». Ключова проблема будь-якого програмного проекту – ризик помилок чи багів у вихідному коді. Очевидно, що чим більше змін та оновлень збирається в одному випуску (версії) програмного забезпечення, тим вища ймовірність того, що в цій версії будуть баги. Розробники забезпечення з відкритим вихідним кодом усвідомили: зі швидким і частим випуском версій софту зменшується ризик виникнення серйозних проблем із будь-якою програмою – адже ми виносимо на ринок не всі оновлення відразу, а за порцією на кожну версію. Згодом ми помітили, що цей підхід не лише знижує кількість помилок, а й призводить до більш цікавих рішень. Виявляється, постійне внесення дрібних поліпшень, зрештою, створює більше інновацій. Можливо, тут немає нічого дивного. Один із ключових принципів сучасних виробничих процесів, таких як kaizen a або lean b, – фокус на невеликих та поступових змінах та оновленнях.
[…] Багато з того, над чим ми працюємо, може і не принести успіху. Але замість того, щоб витрачати багато часу, ламаючи голову, що спрацює, а що ні, ми вважаємо за краще проводити невеликі експерименти. Найбільш популярні ідеї приведуть до успіху, а ті, що не запрацюють, зачахнуть самі собою. Таким чином, ми можемо спробувати багато, а не щось одне, причому без особливого ризику для компанії.
Це раціональний спосіб розподілу ресурсів. Наприклад, люди часто запитують мене, як ми вибираємо, які з проектів із відкритим кодом слід комерціалізувати. Хоча ми іноді ініціюємо проекти, найчастіше ми просто підключаємось до існуючих. Невелика група інженерів – а часом і одна людина – починає робити свій внесок в один із проектів спільноти відкритого коду. Якщо проект успішний та затребуваний у наших замовників, ми починаємо витрачати на нього більше часу та зусиль. Якщо ні, то розробники переходять до нового проекту. На той час, коли ми вирішуємо комерціалізувати пропозицію, проект може розростатися настільки, що рішення очевидне. Найрізноманітніші проекти, у тому числі такі, що не стосуються програмного забезпечення, природним чином виникають по всій компанії Red Hat, поки всім не зрозуміло, що тепер комусь доведеться працювати з цим постійно».
Ось ще цитата з книги:
«Я усвідомив, що для відповідності такої ролі завтрашні керівники мають відрізнятись характеристиками, на які у звичайних організаціях просто не звертають уваги. Щоб ефективно керувати відкритою організацією, керівнику належить мати такі якості.
- Особиста сила та впевненість. Звичайні керівники використовують позиційну владу – свою посаду – для того, щоб досягти успіху. Але за меритократії керівники зобов'язані заслужити повагу. І це можливо лише в тому випадку, якщо вони не бояться визнати, що вони не мають відповідей на всі запитання. Вони мають бути готові обговорювати проблеми та швидко приймати рішення, щоб знаходити найкращі рішення спільно зі своєю командою.
- Терпіння. ЗМІ рідко розповідають історії про те, наскільки «терплячий» керівник. Але він дійсно повинен бути терплячим. Коли ви працюєте, щоб отримати від своєї команди максимум зусиль і результатів, годинами ведете діалог і повторюєте щось знову і знову, доки все не буде зроблено правильно, вам потрібно набратися терпіння.
- Висока EQ (емоційний інтелект). Занадто часто ми рекламуємо інтелектуальні можливості керівників, фокусуючись на їх IQ, коли насправді необхідно брати до уваги їхній коефіцієнт емоційного інтелекту, або оцінку EQ. Бути найрозумнішою людиною серед інших недостатньо, якщо ви не в змозі працювати з цими людьми. Коли ви працюєте з спільнотами залучених співробітників, як у Red Hat, і у вас немає можливості наказувати будь-кому, ваша здатність слухати, аналітично обробляти і не приймати все на свій рахунок стає неймовірно цінною.
- Інший менталітет. Керівники, які прийшли з традиційних організацій, були виховані на кшталт quid pro quo (лат. «послуга за послугу»), згідно з яким кожна дія має отримати адекватну віддачу. Але коли ви збираєтеся інвестувати у створення певної спільноти, вам слід довго думати. Це ніби спроба побудувати тонко збалансовану екосистему, де будь-який невірний крок здатний створити дисбаланс і призвести до довгострокових втрат, які ви можете помітити не відразу. Керівники повинні позбавитися того типу мислення, який вимагає від них досягнення результатів сьогодні ж і за будь-яку ціну, і розпочати таке ведення справ, яке дозволить отримати велику вигоду завдяки інвестиціям у майбутнє».
І чому це важливо
Red Hat живе і працює за принципами, які сильно відрізняються від традиційної організації з ієрархічним підпорядкуванням. І це працює, це робить нас комерційно успішними та по-людськи щасливими. Ми переклали цю книгу, сподіваючись поширити принципи відкритої організації серед російських компаній, серед людей, які хочуть і можуть жити інакше.
, Спробуйте!
Джерело: habr.com