На открытии нашей конференции HolyJS от компании SEMrush на сцену выходила фронтенд-разработчик Анастасия Манзюк, и в своём приветственном слове упомянула удивительно высокий уровень автономии внутри компании: каждая команда разработки самостоятельно принимает многие решения, которые в другой организации могут быть «спущены сверху».
Нам стало интересно, как это сказывается на разработке, и мы задали Анастасии несколько вопросов и об этом, и в целом о её фронтенд-работе в компании.
— Над чем лично вы работаете в SEMrush?— Я из инфраструктурной команды, отвечающей за разработку различных внутренних сервисов, например, сервиса по работе с данными пользователей.
Нашими заказчиками являются другие команды нашей компании (разработчики или Sales). Для них мы делаем инструменты, обеспечивающие автоматизацию их работы.
Часто мы работаем не только на тёмной стороне SEMrush, но и выходим на свет: занимаемся различными улучшениями, которые видит пользователь. Они связаны с его профилем, авторизацией или регистрацией.
Также мы помогаем ещё 27 командам разработки в решении каких-то глобальных задач, но это уже немного другая история.
Но стоит отметить, что чаще в нашей компании можно столкнуться с представителем команды разработки, чей сервис создаётся для наших внешних пользователей — маркетологов и не только.
— А какая специфика у работы на «тёмной стороне», каково это — разрабатывать для своих?
— Думаю, что самое главное отличие — скорость получения фидбека. Когда твои заказчики — это твои коллеги, сидящие в соседнем кабинете, обратная связь доходит почти моментально. Часто можно получить запрос какой-то новой функциональности прямо в коридоре, пока идёшь за чаем.
Ещё коллеги дают очень конструктивные советы, сразу с предложениями, как можно было бы решить ту или иную проблему — это очень ценно, мы стараемся это использовать, и нам это очень помогает.
Второе заметное отличие — метрики. Работая в продуктовой команде, можно отслеживать динамику роста пользователей, сколько из них используют всё больше функций, кто благодаря новому функционалу переходит на более широкие тарифные планы.
В случае с внутренними пользователями подобные вещи отслеживать немного сложнее, ведь динамика уже не будет так сильно зависеть от качества твоего продукта. Да, можно следить, какой функционал зашёл круче, но опять же, как понять, сколько по факту денег это сэкономило или принесло компании? Вот здесь метрики для нас всегда немного сложный вопрос.
Кто-то, возможно, мог бы задуматься, что когда твою работу не видит конечный пользователь — это немного обидно. Но в зоне ответственности нашей команды есть сервисы, от которых зависит напрямую работа множества других продуктов. Поэтому, если у нас что-то пойдёт не так, пользователь это точно заметит. Так что таких сожалений по этому поводу мы точно не испытываем.
А во всём другом, как мне кажется, это всё очень близко к работе продуктового разработчика. Всё так же важно следить за качеством продукта, за тем, чтобы сервис был удобен пользователю, а новый функционал доставлялся вовремя.
— А «разработка для разработчиков» отличается от «разработки для Sales»?
— Есть то очевидное отличие, что зачастую разработчикам не нужен интерфейс, нужно только API. Но, по-моему, главное остаётся общим: и разработчикам, и команде Sales важно, чтобы сервис был стабилен, быстро работал и был удобен в использовании. Поэтому проекты пишутся с одинаковыми требованиями к ним.
— По поводу «автономии команд» в SEMrush для начала спросим вот что: в итоге стек используемых технологий в компании оказывается очень разнообразным? Что используют чаще всего?
— Действительно, поскольку команда сама выбирает, что будет использовать, а команд разработки у нас уже 28, общий стек технологий у нас достаточно большой. Список охватывает практически все популярные фреймворки и библиотеки, попробую перечислить самые часто встречаемые: в новых проектах лидируют React, Redux, Mobx, встречается Vue и Angular, кто-то пишет на TypeScript. Некоторые команды используют Saga. Есть опыт использования Node.js на бэкенде. В сервисах, написанных чуть раньше, часто можно встретить Backbone.
Среди сборщиков тоже свободный выбор: от grunt и gulp до webpack первой и второй версии и babel.
— А конкретно вы с чем работаете?
— В новых проектах наша команда использует React/Redux, webpack, babel. Выбор на такие технологии пал в силу их популярности в нашей компании — можно всегда получить хороший совет от коллег, либо найти его среди множества информации в интернете. В некоторых более старых проектах часто сталкиваемся с Backbone, gulp и grunt.
— Условно говоря, обычно в компании такого размера есть «большой дядя», который думает о скучных вещах вроде обратной совместимости и не даёт командам заиграться с блестящими новыми штучками. А в вашем случае этого дяди нет. К чему это приводит, часто ли приходится «бить себя по рукам», чтобы не заиграться?
— Думаю, что даже в компаниях с техническим контролем сверху разработчики задумываются об обратной совместимости и других «скучных вещах». Просто ответственность за итоговый продукт лежит на одном человеке.
Почему-то, когда узнают, что у нас нет того самого «большого дяди», многим начинает казаться, что у нас тут полная анархия, каждый творит, что хочет, и вообще это всё похоже на какой-то зоопарк с бешеными зверюшками.
На самом деле нет. Нужно понимать: когда такого управления нет сверху, оно должно появиться в тебе и в каждом из разработчиков. Ты сам себе должен стать «большим дядей».
Потому что когда ты точно знаешь, что это ты ответственен за всё, что у тебя в продукте происходит, у тебя и взгляд на все эти новомодные штучки меняется. Не хочется уже тащить «в дом» всё подряд, хочется только самое лучшее, надёжное и проверенное. И это становится не только приоритетом компании, но и твоим личным приоритетом и даже желанием.
Естественно, новые фреймворки выходят, но кто мешает пощупать их сначала на чём-то маленьком, может быть, даже и не на пользователе находящемся? Обычно всё так и происходит: попробовал на чём-то простом — затянуло, поделился опытом с коллегами, выяснил, что ты такой не один, и вот тут уже можно и подумать: «А не самое ли время это где-то ещё использовать на рабочих задачах».
— К вопросу о «поделился опытом с коллегами»: раз у вас разные команды обладают совершенно разными знаниями, насколько активно внутри компании происходит обмен ими?
— У нас существует практика обмена знаниями, компания старается её развивать и всячески мотивировать разработчиков в ней участвовать.
Пару лет назад у нас просто проходили встречи, когда кто-то говорил: «Хочу всем рассказать про вот такую классную штуку». Заинтересованные собирались, происходил доклад.
Затем, чтобы сделать процесс ещё активнее, мы завели доску, на которой любой человек из компании может повесить стикер с темой выступления, которое он хотел бы рассказать или послушать. Получаются две колонки: «могу рассказать» и «хочу послушать». Спрос и предложение.
Выступления происходят примерно раз в одну-две недели, причём часто они получаются действительно полезными. Кто-то рассказывает, как внедрил новые инструменты. Кто-то о какой-то сложной задаче: почему получилась или нет, какие выводы сделали. Часто происходят доклады между различными гильдиями: QA рассказывают, как писать автотесты, фронтендеры — как обуздать свой первый <div>.
Подобного рода вещи некоторые команды внедряют и внутри себя, чтобы не возникало ситуации, когда единственный QA в отпуске, а ты не знаешь, что делать с тестами, пока его нет.
Чтобы нам было повеселее, на такие доклады даже привозят пиццу, и знания усваиваются с двойной скоростью!
Ещё возникают ситуации, когда не знаешь, как лучше решить какую-то задачу, а надо срочно, нет времени ждать доклада. Для таких случаев всегда есть тематический общий чат, где можно кинуть клич и спросить, был ли у кого-то опыт решения подобной проблемы. Очень часто кто-то находится.
А если нет, то это отличный повод потом всем рассказать на отдельном выступлении, чем всё закончилось.
— А возникает ли соперничество между разными командами, сравнивают ли «у кого какие-то метрики лучше окажутся»?
— Все команды очень разные: у каждой свой продукт, свои цели, свой рабочий процесс, поэтому, даже если они и используют схожие метрики, то шкалы у всех очень разные и показатели тоже.
И если попытаться кого-то сравнивать, то это будет сравнение на уровне «вот они — молодцы, а мы что-то не очень». Но это «не очень» будет даже не относительно другой команды, а относительно ваших собственных результатов.
Поэтому мне кажется, что тут скорее соперничество с самим собой. Сделать лучше, чем делал. Не получилось — понять почему, найти проблему, устранить и снова попытаться. А успех коллег — это скорее только мотиватор для твоего собственного.
— В случае с JavaScript часто говорят о разнообразной боли — «зоопарк фреймворков», «что делать с зависимостями» и так далее. Во-первых, насколько вы в SEMrush ощущаете эти болевые места, а во-вторых, влияет ли как-то «автономия команд» на это?
— Конечно, мы тоже ощущаем сложности. И с обновлением зависимостей, когда у тебя огромный продукт написан уже несколько лет назад и нет желающих сейчас его переписывать. И зоопарк фреймворков из прошлых лет и новых продуктов — это всё нам знакомо.
Вот хороший вопрос про автономию команд. С одной стороны, автономия позволяет тебе делать свой продукт, ни от кого не зависящий, обновлять зависимости сразу же, как только это понадобится, использовать фреймворки, которые ты считаешь подходящими для конкретной задачи. Когда ты ни от кого не зависишь — ты сам себе мастер, поэтому многие проблемы решаются быстрее и проще.
Вся боль начинается в элементах, где пересекаются несколько продуктов — в общих частях. Например, хочется вынести какие-то инструменты в межкомандное использование. Но все, кто будут их использовать, сразу теряют автономность. Успеют ли другие команды обновить свой инструмент к моменту, когда ты захочешь обновить свой? И тут всегда получается очень болезненный выбор.
Нужно думать, как будет лучше для пользователей и для дальнейшей разработки. И надо идти и договариваться, тут нет какого-то общего варианта решения вопроса, который всех бы устроил. Здесь и начинается включение того самого «большого дяди». Продумать наперёд, как сделать лучше, чтобы хорошо было уже сейчас.
Вообще, мне кажется, «нормально делай — нормально будет» — это очень правильный девиз. Потому что практически все проблемы, на которые мы натыкаемся — это остатки каких-то не до конца решённых задач, и зачастую наших же. Если почаще думать о пользователе, о той ценности, которую ты ему несёшь, и о том, как это будет поддерживать человек, работающий после тебя, некоторые проблемы начнут решаться сами собой.
По крайней мере, мне бы самой хотелось максимально приблизиться к подобному подходу в работе, и ждать того же от своих коллег.
