Настал важный день для 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, пока всем не становится ясно, что теперь кому-то придется работать с этим постоянно».
Вот еще цитата из книги:
«Я осознал, что для соответствия такой роли завтрашние руководители должны отличаться характеристиками, на которые в обычных организациях просто не обращают внимания. Чтобы эффективно руководить открытой организацией, руководителю надлежит обладать следующими качествами.
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 дискуссии о том, какие именно изменения необходимы и – самое главное – почему они необходимы, не затихают. Это, конечно, делает весь процесс намного более беспорядочным и трудоемким».
Release early, release often
Мы не может предвидеть будущее, поэтому должны просто попробовать:
«Мы действуем по принципу «ранний запуск, частые обновления». Ключевая проблема любого программного проекта – риск ошибок или багов в исходном коде. Очевидно, что чем больше изменений и обновлений собирается в одном выпуске (версии) программного обеспечения, тем выше вероятность того, что в этой версии будут баги. Разработчики обеспечения с открытым исходным кодом осознали: с быстрым и частым выпуском версий софта уменьшается риск возникновения серьезных проблем с какой-либо программой – ведь мы выносим на рынок не все обновления сразу, а по порции на каждую версию. Со временем мы заметили, что этот подход не только снижает число ошибок, но и приводит к более интересным решениям. Оказывается, постоянное внесение мелких улучшений в конечном счете создает больше инноваций. Возможно, здесь и нет ничего удивительного. Один из ключевых принципов современных производственных процессов, таких как kaizen a или lean b, – фокус на небольших и постепенных изменениях и обновлениях.
[…] Многое из того, над чем мы работаем, может и не принести успеха. Но вместо того, чтобы тратить массу времени, ломая голову, что сработает, а что нет, мы предпочитаем проводить небольшие эксперименты. Наиболее востребованные идеи приведут к успеху, а те, что не заработают, зачахнут сами собой. Таким образом мы можем попробовать многое, а не чтото одно, причем без особого риска для компании.
Это рациональный способ распределения ресурсов. Например, люди часто спрашивают меня, как мы выбираем, какие из проектов с открытым кодом следует коммерциализировать. Хотя мы иногда инициируем проекты, чаще всего мы просто подключаемся к существующим. Небольшая группа инженеров – а порой и один человек – начинает вносить свой вклад в один из проектов сообщества открытого кода. Если проект успешен и востребован у наших заказчиков, мы начинаем тратить на него больше времени и усилий. Если нет, разработчики переходят к новому проекту. К тому времени, когда мы решаем коммерциализировать предложение, проект может разрастись до такой степени, что решение очевидно. Самые разные проекты, в том числе не относящиеся к программному обеспечению, естественным образом возникают по всей компании Red Hat, пока всем не становится ясно, что теперь кому-то придется работать с этим постоянно».
Вот еще цитата из книги:
«Я осознал, что для соответствия такой роли завтрашние руководители должны отличаться характеристиками, на которые в обычных организациях просто не обращают внимания. Чтобы эффективно руководить открытой организацией, руководителю надлежит обладать следующими качествами.
- Личная сила и уверенность. Обычные руководители используют позиционную власть – свою должность – для того, чтобы добиться успеха. Но при меритократии руководители обязаны заслужить уважение. И это возможно лишь в том случае, если они не боятся признать, что у них нет ответов на все вопросы. Они должны быть готовы обсуждать проблемы и быстро принимать решения, чтобы находить лучшие решения совместно со своей командой.
- Терпение. СМИ редко рассказывают истории о том, на сколько «терпелив» руководитель. Но он в самом деле обязан быть терпеливым. Когда вы работаете, чтобы получить от своей команды максимум усилий и результатов, часами ведете диалог и повторяете что-то снова и снова, пока всё не будет сделано правильно, – вам нужно набраться терпения.
- Высокий EQ (эмоциональный интеллект). Слишком часто мы рекламируем интеллектуальные возможности руководителей, фокусируясь на их IQ, когда в действительности необходимо принимать во внимание их коэффициент эмоционального интеллекта, или оценку EQ. Быть самым умным человеком среди других недостаточно, если вы не в состоянии работать с этими людьми. Когда вы работаете с сообществами вовлеченных сотрудников, как в Red Hat, и у вас нет возможности приказывать кому-либо, ваша способность слушать, аналитически обрабатывать и не принимать всё на свой счет становится невероятно ценной.
- Другой менталитет. Руководители, пришедшие из традиционных организаций, были воспитаны в духе quid pro quo (лат. «услуга за услугу»), согласно которому каждое действие должно получить адекватную отдачу. Но когда вы собираетесь инвестировать в создание определенного сообщества, вам следует мыслить долгосрочно. Это словно попытка построить тонко сбалансированную экосистему, где любой неверный шаг способен создать дисбаланс и привести к долгосрочным потерям, которые вы можете заметить не сразу. Руководители должны избавиться от того типа мышления, который требует от них достижения результатов сегодня же и любой ценой, и начать такое ведение дел, которое позволит получить большую выгоду благодаря инвестициям в будущее».
И почему это важно
Red Hat живет и работает по принципам, сильно отличающимся от традиционной организации с иерархическим подчинением. И это работает, это делает нас коммерчески успешными и по-человечески счастливыми. Мы перевели эту книгу в надежде распространить принципы открытой организации среди российских компаний, среди людей, которые хотят и могут жить иначе.
Читайте, пробуйте!
