Компания GitLab уже несколько раз привлекала наше внимание: мы писали об инциденте с базой данных, решении перейти на собственное железо и о том, как пользователи убедили GitLab не уходить из облака. Все эти истории объединяет небывалая открытость, которую проявила компания при ликвидации последствий аварий и принятии жизненно важных решений. Мы решили узнать причины такой публичности и нашли замечательный документ, в котором описаны ценности GitLab.
Помимо открытости в нем оказалось много вещей, с которыми, как нам кажется, будет интересно познакомиться и читателям Хабра. Многие из нас работают в похожих условиях: из дома, общаясь удаленно, иногда годами не видя своих коллег. У такого типа работы есть не только преимущества, но и недостатки, а компания GitLab накопила немалый опыт, который может оказаться полезен нам всем. Перевод ценностей GitLab вы можете найти под катом.
CREDIT
Шесть наших ценностей — это Сотрудничество (Collaboration), Результаты (Results), Эффективность (Efficiency), Многообразие (Diversity), Итеративность (Iteration) и Прозрачность (Transparency) (первые буквы английских слов составляют CREDIT, в переводе с английского в данном случае «уважение» — Прим. перев.) Мы верим в доброту и взаимодействуем для достижения результатов. Результаты позволяют нам делать все остальное. Мы добиваемся результатов максимально эффективно, не тратя времени понапрасну. Мы рады разнообразию в нашей команде. Наша работа прозрачна как внутри, так и вне компании. Вместе эти ценности означают уважение (credit), которое мы испытываем друг к другу. Далее описано, как наши ценности применяются на практике.
Сотрудничество
Помощь другим должна быть в приоритете, даже если она не связана с задачами, над которыми идет работа. Вы и сами должны без колебаний обращаться за помощью. Любой человек, в том числе и не работающий в GitLab, может присоединиться к обсуждению любого вопроса. Тот, кто непосредственно выполняет работу, решает, как ее делать, но он должен серьезно рассмотреть полученные предложения, отвечая на них и объясняя свою позицию.
- Доброта. Нам в команде мерзавцы не нужны. В некоторый компаниях говорят: «При оценке людей важна точность, а не доброта». Мы тоже за точность, но думаем, что делать это надо по-доброму. Обратная связь должна быть максимально позитивной и публичной.
- Негатив в формате 1-1. Давайте отрицательную обратную связь при как можно меньшем количестве посторонних. Лучше для этого использовать видеозвонки один на один.
- Говорите спасибо. За помощь благодарите публично, например, в нашем чате
#thanks
. - Эффективная обратная связь. Составление качественного отзыва — непростая задача, которую надо стараться выполнять эффективно. Давая обратную связь, всегда убеждайтесь, что она о работе, а не о человеке. Обязательно добавьте свежий и понятный пример. Принимайте во внимание, если у человека в жизни непростой период, какие-то личные трудности. Примеры позитивной обратной связи можно найти в нашем thanks-чате. Менеджерам важно понимать, что подчиненные реагируют на негативную ситуацию с их руководителем в шесть раз сильнее, чем на позитивную. Поэтому в некоторых случаях критиковать не стоит вообще, особенно если ошибка не проявляется постоянно и не принесла большого вреда. Когда негативная обратная связь все же необходима, она в первую очередь должна быть нацелена на повышение качества работы сотрудника. Не скупитесь на похвалу, делайте это открыто, в том числе и с целью усиления вовлеченности.
- Старайтесь лучше узнать друг друга. Мы используем много текстовых средств коммуникации, не видим друг друга, не работаем в одном офисе, поэтому для предотвращения конфликтов необходимо личное знание человека, стоящего за строками текста в чатах и почте. Поощряйте людей лучше узнавать друг друга на личном уровне. Используйте для этого групповые звонки, виртуальные чаепития и наш саммит.
- Не давите своим званием. Если вы почувствовали необходимость напомнить кому-то о своем служебном положении, значит вы делаете что-то не то, поскольку всем сотрудникам и так хорошо известно, что у нас иерархическая система принятия решений. Объясняйте, почему вы решили сделать так, а не иначе, и уважайте каждого независимо от выполняемой функции.
- Извиняйтесь. Если вы совершили ошибку, попросите прощения. Извиняясь, вы проявляете силу, а не слабость. Люди, делающие бо?льшую часть работы, вероятно, совершат и больше ошибок.
- Не выпячивайте свое «я». Не спорьте только ради того, чтобы выиграть спор, не критикуйте за ошибку дважды. Вы — это не ваша работа, необходимо не защищать свою точку зрения, а вместе искать правильный ответ.
- Способствуйте успеху других. Кандидат, успевший пообщаться со многими людьми в GitLab, отметил, что по сравнению с другими компаниями одна вещь выделяется особенно сильно: каждый сотрудник GitLab способствует успеху других.
- Люди — это не их работа. Говорите о работе, а не о ее исполнителях («ты не прислал отзыв о новом дизайне» вместо «ты меня никогда не слушаешь»). Получая обратную связь, помните, что она помогает стать лучше и что другие искренне желают вашего успеха.
Результаты
Мы делаем то, что обещали друг другу, клиентам, пользователям и инвесторам.
- Цените результаты, а не отработанные часы. Нам важны достижения: написанный код, счастливые пользователи и коллеги, получившие помощь. Не состязайтесь в количестве отработанных часов — мы не хотим, чтобы кто-то чувствовал вину за то, что он вчера после обеда занимался своими делами. Вместо этого радуйтесь своим и чужим достижениям. Не нужно отчитываться за рабочие часы. Вместо следования жестким правилам мы предпочитаем доверять членам нашей команды.
- Записывайте обещания. Измеримые цели должны быть согласованы в письменном виде. В Gitlab мы используем OKR. Наши цели доступны здесь.
- Установка на личностный рост. Вы не всегда будете добиваться результата, а за неудачами следуют самокритика и негативные отзывы со стороны. Мы верим, что талант можно развить за счет усердной работы, правильно выбранной стратегии и помощи других людей. Мы нанимаем сотрудников на основе траектории их развития, а не родословной.
Эффективность
Нам важно работать над тем, что нужно, не делать больше, чем нужно, и не выполнять одно и то же несколько раз. Таким образом мы добиваемся большего, и это позволяет нам полнее реализовывать себя.
- Скучные решения. Используйте самые простые и скучные решения. В случае необходимости их всегда можно будет усложнить. В нашей организации скорость внедрения инноваций ограничивается общей добавленной на данный момент сложностью, поэтому любое уменьшение сложности нам выгодно. Не следует выбирать интересную технологию только потому, что вам хочется с ней поработать. Использование распространенных решений означает, что многие ошибки уже исправлены, а другим людям будет проще подключиться к разработке.
- Цените чужое время. Всегда учитывайте, сколько времени коллег уйдет на организуемые вами совещания и запускаемые процессы согласования. Старайтесь избегать совещаний, а если это невозможно, делайте участие необязательным, пишите понятную повестку и документируйте результаты. Вместо того чтобы обязывать людей согласовывать свои действия, доверяйте их суждению и предлагайте просто проконсультироваться с вами, если у них появятся вопросы.
- Тратьте деньги компании как собственные. Каждый потраченный доллар мы должны заработать и вернуть. Берегите деньги компании так же, как собственные.
- Свобода. У вас должны быть понятные цели и свобода в выборе способов их достижения.
- Бережливость. Amazon сформулировал это наилучшим образом: «Достигайте большего с меньшим. Ограничения рождают находчивость, самодостаточность и изобретательность. За раздувание штата, рост бюджета и сохранение фиксированных расходов дополнительных очков не дают».
- ConvDev. Наша работа строится согласно принципам conversational development.
- Короткие устные ответы. На устные вопросы давайте короткие ответы, чтобы собеседник мог спросить что-то еще или сразу двинуться дальше.
- Делайте рассылки максимально короткими. Письма, отправляемые сразу нескольким адресатам, не должны быть длинными. В этом исследовании HBR говорится: «Многие утверждают, что им приходится читать слишком длинные, плохо организованные, неясные, заполненные жаргоном сообщения, что крайне неэффективно».
- Сам себе руководитель. Мы хотим, чтобы члены нашей команды были сами себе руководителями, которым для достижения поставленных целей не нужны ежедневные проверки.
- Ответственность, а не закоснелость. Вместо жестких правил и повсеместных процессов согласования мы, когда это возможно, даем людям возможность принимать собственные решения и возлагаем на них ответственность за их принятие.
- Ошибки допустимы. Не каждая проблема должна приводить к новому процессу, который ее решает. Дополнительные процессы снижают эффективность всех действий в целом, а ошибка затрагивает только одно из них.
Многообразие
В наше сообщество входят люди со всего мира. У них разные биографии и мнения. Мы нанимаем сотрудников из любых уголков мира и поощряем разнообразие. Мы стараемся, чтобы каждый чувствовал, что ему у нас рады, а также работаем над увеличением количества сотрудников, относящихся к меньшинствам и национальностям, которые недостаточно представлены в наших компании и сообществе. К примеру, мы спонсируем проведение праздников разнообразия и учредили двойной бонус за рекомендацию.
- Культурное соответствие — это чушь. Мы не нанимаем на основе культурной принадлежности и не отдаем предпочтение тем кандидатам, с которыми хотели бы выпить. Мы берем на работу и награждаем сотрудников на основании наших общих ценностей, но в то же время стремимся к культурному многообразию, а не культурному соответствию (как, например, в случае брограммерской (brogrammer)) атмосферы.
- Религию и политику оставьте дома. Мы не обсуждаем религию и политику, поскольку в процессе таких дискуссий очень легко отдалить людей, придерживающихся точки зрения меньшинства. Вы можете без проблем рассказать, что посетили церемонию или митинг, но не упоминайте религию или партию.
- Чудачество. Неожиданные и необычные вещи делают жизнь более интересной. Поощряйте оригинальные подарки, привычки, поведение, точки зрения и радуйтесь им. В качестве примера можно привести наши групповые звонки, на которых мы большую часть времени говорим о том, чем занимаемся вне работы: от огнеметания до вязания. Open source позволяет общаться с интересными людьми. И мы стараемся нанимать таких людей, которые считают, что работа — это отличный способ самовыражения.
Итеративность
Мы дробим задачи на как можно меньшие части и запускаем их в работу как можно быстрее. Если что-то может быть исключено из первой итерации, создайте новую задачу и свяжите ее с текущей. Не пишите большие планы — достаточно первого шага. Поверьте, вам будет гораздо понятнее, что делать дальше, после того как что-то уже выпущено (released). Если вы немного смущены малым количеством функций продукта в первой итерации, значит вы все делаете правильно. Новые люди, приходящие в GitLab, часто не до конца понимают, насколько сильно эта ценность влияет на рабочий процесс и его результаты. Поначалу быстрое принятие решений и осознание того, что вещи меняются с меньшим количеством консультаций, даются тяжело. Но часто самая простая версия оказывается самой лучшей.
- Уменьшайте время циклов. Короткие итерации уменьшают наше время цикла.
- Работайте как часть сообщества. Короткие итерации позволяют вовлекать в процесс больше участников сообщества. Их работа становится больше похожей на нашу, а мы быстрее получаем обратную связь.
- Минимально жизнеспособное изменение (MVC — Minimum Viable Change). Чтобы улучшить результат, всегда старайтесь сделать наиболее быстрое изменение. Если вы считаете, что задуманное лучше, чем существующее, нет нужды терять время на его шлифовку.
- Создайте предложение. Если нужно принять командное решение, вместо организации совещания создайте предложение — это гораздо более эффективное использование времени всех членов команды. Люди, получившие предложение, не должны ощущать себя забытыми, а тот, кто создал предложение, не должен расстраиваться, что в итоге решили реализовать что-то совсем другое. Не позволяйте своему эго и желанию видеть свое решение реализованным встать на пути нахождения оптимума.
- Все есть проект (draft). В GitLab мы редко называем что-то проектом (draft). Все и так всегда в проекте и может быть в любой момент изменено.
- В разработке. Поскольку у нас с каждым днем появляется все больше пользователей, они требуют стабильности, особенно в нашем UX. Мы всегда должны оптимизировать работу в расчете на отдаленную перспективу. Это означает, что пользователи могут столкнуться с неудобствами в каком-то ограниченном промежутке времени, но в итоге получат более качественный продукт.
Прозрачность
Будьте как можно более открытыми. Публикуя информацию, мы снижаем порог вхождения для новых участников сообщества и упрощаем взаимодействие. В качестве примера можно привести публичный репозиторий этого сайта, который также содержит это корпоративное справочное пособие. Все, что мы делаем, публично по умолчанию, например, системы работы с задачами GitLab CE и GitLab EE, а также маркетинг и инфраструктура. Прозрачность создает осведомленность о GitLab, позволяет нанимать людей, разделяющих наши ценности. Она позволяет быстрее получать обратную связь от людей вне компании и упрощает взаимодействие с ними. Смысл также в том, чтобы в духе open source, который, по нашему мнению, создает дополнительную ценность, поделиться со всем миром отличным программным обеспечением, документацией, примерами, уроками и процессами. Есть и исключения. Материалы, которые по умолчанию не являются публичными, перечислены в общих рекомендациях. На личном уровне: лучше говорить откровенно и начистоту, а не натягивать покерфейс. Не бойтесь признать, что вы совершили ошибку или оказались неправы. Когда что-то пошло не так, следует спросить себя: «Это повод применить kaizen?» и начать поиск лучшего пути, не впадая в отчаяние.
- Публичны по умолчанию. В GitLab все открыто по умолчанию.
- Прямота — мы открыты друг другу. Мы стараемся развить в себе внутреннего Бена Хоровитца (Ben Horowitz): быть откровенными и добрыми — редкое сочетание небалабола и несволочи. Правда, тут будет сложно получить обратную связь, так как она у нас всегда о работе, а не о человеке.
- Все и всех можно поставить под сомнение. Любые прошлые решения и руководства открыты для переосмысления, но вы действуете в соответствии с ними до тех пор, пока они не изменены.
- Не согласись, но выполни. Все может быть поставлено под сомнение, но если решение не отменено, его надо выполнять — это общий принцип.
- Ценность истинна тогда, когда ради нее надо потрудиться или даже пострадать. В Калифорнии, например, многие компании не сообщают реальную причину отказа при приеме на работу, потому что это повышает вероятность получить судебный иск. Мы стремимся отклонять кандидатуры максимально обоснованно и давать людям возможность вырасти, получив нашу обратную связь. Таким образом, мы несем повышенный риск, придерживаясь высокого стандарта принятия решений, и поступаем правильно, прямо сообщая кандидатам наши мысли.
Пять дисфункций
Наши ценности помогают нам предотвращать пять дисфункций.
- Отсутствие доверия (нежелание показать свою уязвимость внутри группы) => предотвращается взаимодействием, в особенности добротой.
- Боязнь конфликта (стремление к искусственной гармонии вместо конструктивных эмоциональных дебатов) => предотвращается прозрачностью, в особенности прямотой.
- Недостаточная вовлеченность (видимость согласия при принятии коллективных решений создает неопределенность в организации) => предотвращается прозрачностью, в особенности прямотой.
- Избегание ответственности (уклонение от призвания коллег к ответственности за контрпродуктивное поведение; приводит к установке более низких стандартов) => предотвращается результатами, итеративностью и прозрачностью.
- Невнимание к результатам (нацеленность на собственный успех, статус и эго ставятся выше командного успеха) => предотвращается результатами.
Зачем нужны ценности
Наши ценности помогают понять, как нужно себя вести, и должны применяться на практике. Они описывают правила поведения, которых должны придерживаться работающие у нас люди. Цели помогают понять, как нужно вести себя в организации и чего можно ожидать от других. Наши цели — это база для процесса распределенного принятия решений, они позволяют понять, что делать, не спрашивая своего руководителя.
Как мы поддерживаем наши ценности
Ценностями становится поощряемое поведение. Мы поддерживаем наши ценности следующим образом:
- Тем, что мы делаем, в особенности действиями руководства.
- Тем, кого мы принимаем на работу.
- Тем, на чем мы акцентируем внимание во время периода адаптации нового сотрудника.
- Теми критериями, которыми мы руководствуемся при продвижении по службе.
- Теми критериями, которые мы используем для премирования.
- Тем поведением, за которое мы хвалим.
- Теми критериями, которыми мы руководствуемся при расставании с сотрудниками.
Можно играть
В наши ценности не включены некоторые очевидные качества и модели поведения. Мы называем это термином «можно играть»:
- Будьте правдивыми и честными.
- Будьте надежными, справедливыми и уважительными.
- Будьте вовлеченными, креативными, вдохновляющими и страстно увлеченными своей работой.
- Будьте достойны доверия пользователей и клиентов.
- Действуйте в наилучших интересах компании, членов команды, клиентов, пользователей и инвесторов.
- Действуйте в соответствии с законом.
Ссылки:
- Оригинал: GitLab Values
Комментарии (10)
terrier
22.05.2017 16:01+1Так итого — какие ценности гитлаба привели к
«Out of 5 backup/replication techniques deployed none are working reliably or set up in the first place»
Diversity, Iteration или Transparency?gekk0
22.05.2017 16:48+1Человеческий фактор, в данном случае Efficiency:
Свобода.
Сам себе руководитель.
Ответственность, а не закоснелость. Вместо жестких правил и повсеместных процессов согласования мы, когда это возможно, даем людям возможность принимать собственные решения и возлагаем на них ответственность за их принятие.Сам я поддерживаю свободу и ответственность, но в этот раз, похоже, они вышли боком.
При этом GitLab не АЭС. Допускаю, что даже на риск потери базы руководители идут сознательно, а потери считают допустимыми.
terrier
22.05.2017 17:11При этом GitLab не АЭС. Допускаю, что даже на риск потери базы руководители идут сознательно, а потери считают допустимыми.
Все так. Если бы они писали список своих реальных ценностей, то где-то в начале было бы
— Мы особо ни за что не отвечаем, так что можем позволить себе относиться к работе несколько более баззаботно, экономя существенную денежку на специалистах попроще, процессах попримитивнее и отсутствии бюрократии.
Skar404
Кто пользуется GitLab не как локальной заменой GitHub?
Обычно ситуация такая, не хочешь платить и хочешь приватный репозиторий, тогда — bitbucket
Нужный публичный репозиторий — Github
Если нужен локальный репозиторий — разворачиваешь Gitlab на сервере.
DorianPeregrim
Вполне хорошая замена Bitbucket, особенно с учетом того, что нет ограничений на количество бесплатных участников в приватном репозитории.
ahanoff
У gitlab на free plan неограниченное количество приватных репозиториев, так что в последнее время храню свои наработки там.
Несмотря на удаление базSkar404
Думаю удаления базы это даже хорошо, в плане нового опыта, все ошибающийся, и надеюсь сейчас уже:
`oh-my-war-server.cluster.gitlab.com` и `dev.cluster.gitlab.com `
Меня пугает:
1) По мне излишняя открытость, не стоит так открыто освещать проблему до её решения (да и когда был стрим процесса восстановления мне лично напомнило первую серию из черного зеркала).
2) Что они не могли восстановить из backup, сложилось впечатление что они не тестировали восстановления из backup и делали это для галочки.
Мне для неограниченное количество приватных репозиториев легче поднять VPS с Jenkins + Gitlab + Docker, да и уже прикрутить к этой балалайке Amazon Glacier и все будет прекрасно (пока не повторится история как с S3).
gresolio
GitLab имеет одно очень вкусное преимущество в сравнению с другими конкурентами — 10 Gb лимит на один репозиторий, Bitbucket замораживает репозиторий после превышения 1 GB (так званый Soft limit), у GitHub — тоже ограничение 1 Gb. Это далеко не всем полезно, потому что код мало весит, но иногда бывает очень кстати для больших проектов с разными жирными файлами. Вот ещё кстати хороший ресурс по сравнению хостингов для кода: Compare Git Hosting.
iit
Использую его как хранилище своих наработок, которые вроде интересны и нужны но пока еще стыдно показать их людям. Стоит себе мирно в виртуалке и кушать особо не просит + gitlab-ci достаточно удобный.
Github использую для того что не важно от слова совсем или не стыдно показать людям. Bitbucket уже для работы, есть группы по отделам (отдел как раз 4-6 человек) и есть платный акк тех директора куда переносим проекты где > 5 человек.
Envek
Изначально так и пользовались, но потом у GitLab'а появились свои прикольные фишки, которых не хватает а GitHub:
git commit --fixup
, то GitLab автоматом добавит префиксWIP
к названию MR (при наличии этого префикса блокируется возможность merge). Если вручную пушнуть fast-forward-ом ветку MR в целевую, то GitLab поймёт, что MR влит и пометит его, как за'merge'нный.