Вот уже год как наша жизнь перетекла на удаленку. Мы в компании ISPsystem привыкли работать из офиса, видеть всех членов команды ежедневно на расстоянии вытянутой руки. К работе в новом формате я адаптировалась быстро. Но скажу честно, работать удаленно — не так уж и легко, как может казаться со стороны. Многие не выдерживают. Сказывается как отсутствие живого общения, так и приевшиеся четыре стены, за которыми можно не заметить, как меняются времена года.
Как же адаптироваться под ситуацию? Как внести разнообразие в работу, получить новые впечатления и прокачать скиллы не выходя из дома? Я хочу поделиться нашим опытом проведения командировок внутри компании. Он может быть полезен компаниям, в которых существуют сразу несколько продуктовых команд.
Идея командировок
Мысль отправлять людей в командировки зародилась у руководства задолго до начала пандемии и перехода на удаленку. Основная идея заключалась в том, чтобы брать одного технического специалиста из продуктовой команды и отправлять на пару спринтов в другую команду. У нас в компании на тот момент было 5 команд, состоящих из frontend и backend разработчиков, QA, UX-дизайнеров и продуктологов. И вроде все мы работаем плюс-минус одинаково, живем по скраму, закрываем спринты... Но все-таки, каждая команда — это отдельный мир со своими процессами, подходами к работе и привычками.
Командировка выглядела не только как неплохой способ разнообразить жизнь разработчику или QA, получить опыт работы с другим продуктом и прокачать скиллы, но и как возможность перенести полезные процессы из одной команды в другую. Иногда бывает так, что для решения какой-то большой задачи в команде не хватает ресурсов. В таком случае командировка — это еще и способ помочь команде.
«Для человека командировка — это смена обстановки. Когда долго работаешь над одним проектом — надоедает. Кажется, что вокруг все пилят что-то интересное, а ты один киснешь. А по факту, программирование — оно везде программирование. А еще это обмен опытом и возможность провести своего рода аудит. Понять, насколько легко или сложно онбордить людей в команду, посмотреть на процессы со стороны»
Александр, руководитель отдела разработки и тестирования
Оффлайн-командировки выглядели сурово. С полноценным переездом в другой кабинет и полным погружением в атмосферу и внутреннюю кухню другой команды. Представьте, как в один день несколько людей из разных команд встречаются в коридоре с мониторами в руках. Для нас эта картина не была столь удивительной, переходы из одной команды в другую были привычны, хоть и случались не часто. Поэтому коллеги интерпретировали переход в другую команду как уход навсегда. Одни взгрустнули от потери боевой единицы, другие же наоборот обрадовалась пополнению.
Первая командировка в оффлайне
Первопроходцами эксперимента стали разработчики. Казалось, что им будет проще влиться в новый продукт. Технологии у нас плюс-минус одинаковые, продукты схожие, например VMmanager и DCImanager во многом пересекаются своей функциональностью. Продолжительность командировки определили примерно в пару недель, но четкого срока не было.
Но первый блин всегда комом. Первая командировка одного из наших Frontend-разработчиков была неудачной. Его отправили в другой проект на помощь в разработке одной из крупных фич. Предполагали, что на это потребуется пару недель, однако разработка затянулась по времени. В команде беспокоились, что командировка превратится в полноценный уход. Так и произошло. После этого мы начали смотреть на эксперимент с опаской.
На какое-то время командировки прекратились. Со временем к ним все же решили вернуться — отправлять людей на помощь в решении крупных задач.
«Я был в командировке уже во время удалёнки, уходил в команду DCImanager на три спринта. Передо мной были поставлены цели: помочь команде, написав фичу, обменяться опытом, предоставить взгляд со стороны на процессы. Но главное — потушить пожар. Ресурсов в команде не хватало, задач было много. Командировочное задание в виде написания фичи «Скрипты» было успешно выполнено, опыт получен, обратная связь оставлена. Польза была в том, что я действительно помог с выполнением текущей работы. Не смотря на то, что все команды делают одну и ту же работу, процессы отличаются весьма значительно»
Александр, frontend-разработчик
Мои командировки
Я работаю QA-специалистом в команде BILLmanager и стала первопроходцем командировок среди QA. И если у разработчиков все сложилось, то с обменом опыта у QA все было немного сложнее. Хоть мы и стали больше понимать друг друга и чаще общаться после Школы тестировщиков, но все равно процессы тестирования в командах оставались разными. У кого-то преобладает ручное тестирование, у кого-то автоматизированное. В одной команде пишут чек-листы, а в другой тест-кейсы с высоким уровнем детализации. У всех разные подходы, которые исходят из потребностей в тестировании конкретного продукта. Пока мы лишь стремимся к тому, чтобы стандартизировать их.
Моя первая командировка случилась в сентябре 2020 года в VMmanager. Я немного скептично отнеслась к предложению «сходить в командировку». Несмотря на то, что это мероприятие весьма полезно в плане роста, смена команды — это все-таки выход из зоны комфорта. Это встряска, к которой я не была готова, но решила попробовать из любопытства.
Реализовывать командировки с приходом удаленки стало намного проще. Не было необходимости в один день тащить всю свою технику и кучу вещей на новое рабочее место, адаптироваться, тратить время. Проснулся с утра, выпил кофе, включил ноутбук — и вот ты в командировке. Новая команда, новые задачи, новые впечатления, и все это с котом на коленях.
Продолжительность командировки на этот раз определили четко — 6 недель. Все команды компании живут по двухнедельным спринтам. Поэтому выходит, что человек находится в командировке три полноценных спринта. Этого времени должно быть достаточно чтобы погрузиться в продукт, проникнуться процессами в команде и начать решать задачи.
Передо мной стояла цель посмотреть на процессы тестирования в команде, по возможности оптимизировать их, передать свой опыт. Командировка оказалась хорошим способом обмена знаниями.
За эти шесть недель мне удалось лучше узнать продукт, посмотреть на привычные процессы под другим углом, поделиться опытом и дать обратную связь команде VMmanager. Также мне удалось затащить в команду полезные практики, используемые в BILLmanager. Так в команде VMmanager появился шаблон задач с которым удается более грамотно и полно описывать баг-репорты, а в задачах стали появляться детализированные чек-листы.
Моя вторая командировка состоялась спустя четыре месяца. В феврале 2021 года я уходила в команду DCImanager так же на три спринта. Цели командировки были теми же. По итогу я лучше узнала продукт. Он оказался очень сложным, но интересным. Я посмотрела на процесс тестирования. В нем активно используют автоматизацию для решения многих задач — в этом кардинальное отличие от подходов других командах. И конечно, увидела еще одну вариацию привычных мне процессов . Нам есть чему учиться друг у друга. Мне удалось совсем немного поучаствовать в автоматизации, но это был полезный опыт. Теперь хочется использовать его для решения повседневных задач.
Польза командировок
Командировка — это отличный способ обменяться опытом как для разработки, так и для тестирования. Это непросто, и поначалу кажется, что шесть недель — достаточно небольшой период, за который невозможно сделать что-то существенное. На деле этот промежуток времени позволяет как минимум трезво оценить собственный уровень. Для меня это стало самым полезным. Мне тяжело оценивать саму себя. Особенно потому что я работаю в одном продукте достаточно долго. Раньше мне приходилось часто задумываться о том, насколько я действительно квалифицированный специалист. После командировок мои внутренние сомнения развеялись.
За шесть недель сложно привнести что-то в команду и поменять уже устоявшиеся процессы, но можно поделиться своим взглядом со стороны и предложить альтернативные варианты улучшений.
«Такая практика "по обмену премудростями" была полезна. У нас на фронтенде во всех продуктах один и тот же стэк, поэтому я достаточно быстро начал решать задачи: с утра пришел, ребята рассказали про основы продукта, помогли поднять бэкенд и вечером я уже что-то делал.
Но позже, когда пришло время сдавать фичу в приемку, я понял, что процессы тестирования и ревью в команде построены по-другому. Поначалу было непривычно. В процессе работы мы обсуждали отличия в кодестайле и общих архитектурных подходах. По окончании командировки я принес немного фронтендерских полезностей в свою команду.
Что касается скрам-процессов, тут все прошло без перенимания практик. Я рассказал ребятам, как в VMmanager проходят ретро и стендапы, даже несколько стендапов пробовал провести в другом формате, но, кажется, это не прижилось»
Кирилл, Frontend-разработчик
Что учесть, если захотите провести командировку у себя в компании
Оптимальная продолжительность командировки — три спринта (6 недель). Может быть больше, но не меньше. Схема работает примерно так. В первом спринте человек вкатывается в процессы, изучает продукт, привыкает к команде. Во втором спринте человек уже начинает вариться в команде, делать задачи, бежать к целям вместе с командой. В третьем спринте он уже способен оценить процесс внутри команды, может предложить пути оптимизации или же наоборот понять какой процесс можно привнести в свою команду.
Между командировками должны быть перерывы от полугода. Не стоит устраивать путешествия из команды в команду слишком часто — это встряска, которая может вывести человека из строя.
Планировать командировки стоит заранее. Работа в команде зачастую предполагает долгосрочное планирование с учетом ресурсов. Бывают достаточно большие фичи или задачи с обозначенным сроком. Чтобы не приходилось перекраивать планы внутри команды, рискуя сроками или бросать что-то на полпути, командировки лучше планировать как минимум за месяц-два до их начала.
