Как удаленка ускоряет инновации на GitLab

Автор оригинала: Victor Wu
  • Перевод

На GitLab удаленка — это не бизнес-риск, а конкурентное преимущество.



Я менеджер продуктов на GitLab. Обычно занимаюсь стадией планирования в жизненном цикле DevOps. Я пришел в ноябре 2016 и с тех пор любуюсь, какими семимильными шагами развивается GitLab как продукт и как команда. Многие новички спрашивают меня за кофе о культуре GitLab, особенно об удаленке, ведь мы только так и работаем. Со временем мои взгляды менялись, и я хочу рассказать, почему удаленка кажется мне не препятствием, а конкурентным преимуществом. Во всяком случае, для GitLab.


Как я привыкал


Когда я пришел на GitLab, мне казалось, что удаленка — это проблема, которую нужно решать. Или хотя бы контролировать. Я думал, это риск. Например, мне хотелось каждый день встречаться с моей командой. Компании из Кремниевой долины и умные книги говорят, что нужно регулярно встречаться и общаться, иначе невозможно создать успешный продукт и завоевать рынок. К моему тогдашнему ужасу, мы никогда не встречались (и сейчас не собираемся). И — странное дело — мы плодотворно сотрудничали и поставляли продукты только в путь. Такого я точно не ожидал.


Потом стал привыкать делать продукты в стиле GitLab, и удаленка показалось не такой уж рискованной. Есть, конечно, пара минусов, но в остальном сплошная радость. Вот плюсы и минусы удаленки, если интересно.


На самом деле недостаточно взвесить плюсы и минусы, чтобы описать важность удаленной работы для GitLab. С удаленкой (и другими ключевыми компонентами GitLab) мы очень быстро создаем инновации, а значит получаем уникальное конкурентное преимущество. И вот почему.


Взаимозависимые компоненты


Удаленка так хорошо вписывается в GitLab благодаря важным взаимозависимым компонентам:


Асинхронные коммуникации


Удаленные сотрудники разбросаны по всей планете и работают в разных часовых поясах. Поэтому мы предпочитаем асинхронные коммуникации (обычно в текстовом виде), растянутые в пространстве и времени. В таком формате приходится все записывать, причем выражаться четко и ясно. Иначе никак, ведь за сутки иногда удается обменяться только фразой–другой. Мы предпочитаем текст, потому что в интернете и современных приложениях (например, в задачах GitLab) текст подходит для упорядочивания, поиска и гиперссылок. Текст легко анализировать и усваивать. Это очень эффективная форма коммуникации, особенно для совместной работы.


Прозрачность


Цифровые асинхронные сообщения можно сколько угодно рассылать, в отличии от бумажных документов в офисе. Мы не отгораживаемся друг от друга стенами, как в традиционных компаниях. Наши коммуникации и работа прозрачны по умолчанию. Иногда приходится добавлять разрешения и потом еще управлять ими, а это лишние расходы. Если хочешь отправить сообщение, нужно подумать, кто должен его получить, и настроить разрешения. У получателей работы тоже прибавляется, ведь до контента так просто не доберешься. Это лишняя головная боль, и такие штуки накапливаются. Мы стараемся их избегать.


И так понятно, что твое сообщение может увидеть кто угодно, даже если он тут не работает. Так что лучше сразу говорить, как есть.

Если у вас все прозрачно, говорить правду очень просто, а врать незачем. Это не только правильно, но и выгодно в плане долгосрочного развития бизнеса. Например, и так понятно, что твое сообщение может увидеть кто угодно, даже если он тут не работает. Так что лучше сразу говорить, как есть, и к этому быстро привыкаешь. Не нужно выдумывать отдельную версию для каждого, а потом еще помнить, что кому отправил. У тебя есть один источник истины, и в нем не запутаешься. Других-то нет. У нас это, обычно, описание в тикете.


Танцуют все!


Когда всем доступен единый источник истины, все вносят свой вклад. У всех есть одна и та же информация, и работать с ней может каждый. Помните, я говорил, что отправитель обычно думает, кто получит сообщение? В нашем случае что-то полезное может прийти, откуда не ждали. Без прозрачности такое не провернешь: искусственные барьеры мешают возможному сотрудничеству. Иногда хорошим идеям нужно созреть. Например, высказал ты какую-то мысль, но условия для нее пока не самые подходящие. А потом оказывается, что это просто вопрос времени. В будущем кто-нибудь эту мысль откопает и будет развивать дальше, используя все открытые обсуждения и наработки.


Когда идею может подать каждый, их становится вагон. На GitLab иногда лучшие решения сложным проблемам приходят совсем от других команд. Но у нас все-таки есть ответственные. Они принимают решения, когда мы застряли.


Итерация


Как собрать все эти коммуникации и совместную работу, если они по сути транзакционные, распределенные и неструктурированные? Нам приходится работать итеративно. Многие (включая меня), думают, что понимают итерацию, пока не приходят на GitLab. Я постоянно вижу новичков, которые удивляются, до какой крайней степени мы довели эту концепцию. Продукт и код поставляются минимальными фрагментами, чтобы разработчик сразу получил обратную связь и знал, куда работать дальше. На GitLab вы отрезаете крошечные кусочки и сразу запускаете в работу. Мы, конечно, строим грандиозные планы, но не зацикливаемся на подробном анализе. Мы просто берем самую маленькую задачу и решаем ее. Каждый день ожидания мы считаем упущенной выгодой. Лучше сделать хоть что-нибудь сегодня и сразу получить результат. Мы сосредоточены на действии.


Каждый день ожидания мы считаем упущенной выгодой. Лучше сделать хоть что-нибудь сегодня и сразу получить результат.

А у маленьких фрагментов и проблемы маленькие. Логично, что на мелкие проблемы находится больше желающих: взглянуть на описание тикета — это вам не двухчасовую презентацию высидеть. А раз проблема по умолчанию прозрачна, решать ее может вообще кто угодно. Лично я каждый день параллельно обсуждаю 20–30 проблем. Я бы вряд ли это осилил, если бы приходилось каждый раз ходить на специальные встречи. В итоге я хоть как-то поучаствовал в невероятном количестве проектов. Умножьте это на все команды GitLab, а потом еще на все сообщество GitLab, и сразу понятно, откуда на GitLab все эти инновации.


GitLab не мучается с удаленкой, а вовсю извлекает из нее выгоду.


В заключение


Я тут рассказал о бесконечных переписках и фонтане идей. Так мы и работаем. Бывает, новички уже через несколько недель замечают, что по уши увязли во всех обсуждениях разом. Это неудивительно, ведь мы развиваемся, идей становится все больше, наша сеть растет и связи между нами множатся. Но довольно скоро новички учатся выбирать только самое интересное. Думаю, это неплохая стратегия, ведь хорошие идеи привлекают больше внимания, и мы доверяем нашему коллективному разуму. Но нам все равно нужны четко определенные роли и обязанности, чтобы узкие специалисты и ответственные лица подталкивали наши инновации в нужном
направлении.


А как вы справляетесь с удаленкой? Напишите коммент или твитните на @gitlab.

  • +28
  • 6,3k
  • 2
Southbridge
293,00
Обеспечиваем стабильную работу серверов
Поделиться публикацией

Комментарии 2

    +3
    У меня аналогичное впечатление, что зачастую лучше асинхронной текстовой коммуникации ничего нет.
    А если требуется коллективный созвон в скайпе, то это означает что просто никто не может понять что происходит и кто за что отвечает.
      0

      Складывается впечатление, что написано менеджером для менеджеров. Плюсы есть и у той, и у другой модели. А доводов за удаленку в этой статье я особо и не увидел.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое