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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Танцуют все!

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

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

Итерация

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

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

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

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

В заключение

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

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

Автор: nAbdullin

Источник ^[14]