Циан — Удаленка

Привет!

Меня зовут Слава, я технический руководитель направления «Застройщики» в Циан. «Застройщики» — это большая команда, внутри которой работают 25 человек. Из них 18 — разработчики и тестировщики. С середины 2019 года мы участвовали в экспериментах по удаленной работе в Циан. У нас успешно получилось перейти на частичную удаленку к началу 2020-го, еще до начала коронавирусных ограничений. Хочу рассказать об опыте перехода Циан на удаленку, в первую очередь со стороны IT.

С 23 марта наша команда работает из дома, компания больше 200 дней ведет удаленную работу. За это время мы успели закончить запланированный квартал, адаптироваться к полностью удаленной работе и запланировать новый квартал. Наш опыт может быть интересен тем, кто сейчас совершает похожую трансформацию или просто хочет узнать, как это прошло у других.

История до 23 марта

    Внутри IT сеньорам можно было работать из дома два дня в неделю по согласованию с руководителем. Остальные могли работать из дома семь дней в год. Это время было выделено скорее под болезни или какие-то другие случаи, когда надо быть дома и не появляться в офисе. В 2019-м стало понятно, что эта система больше вызывает вопросы, чем дает преимущества. Почему только сеньорам можно работать из дома? А если мне руководитель разрешит?

Одна из ценностей внутри компании — «меняйся!». Можно изменить почти любой процесс или традицию, если объяснить, зачем это надо и почему это сработает. Именно так мы и поступили с удаленной работой — начали эксперименты для поиска хорошего решения.

В 2019 году мы провели несколько экспериментов для того, чтобы понять, как удаленка влияет на метрики, и собрать обратную связь от участников. «Застройщики» принимали участие во всех экспериментах. Детально описывать их не буду, так как прошло уже больше года с начала первого. Если они интересны — спрашивайте в комментариях или личке.

Принципы и правила, которые использовала наша команда

• Общаемся асинхронно. Ответ нужен прямо сейчас — позвони.

• Ставим плагин для Slack, который синхронизирует статус с Google Calendar.

• Появился чатик в Slack, в котором надо было отметиться о работе из дома.

• На встречу — груминг — все приходят в офис. На этой встрече команда обсуждает с продуктом детали реализации текущего или будущего проекта.

Неудачные практики и проблемы, которые подсветили эксперименты

• Расписание посещения офиса. Встречи переносились на момент присутствия человека в офисе. Сильно удлинились коммуникации плюс замедлились процессы. Команда, которая тестировала расписание, вернулась в офис и вышла из эксперимента.

• Сложности с VPN. Низкая скорость и периодическая недоступность.Он сильно улучшился за время эксперимента 

• Не у всех разработчиков были ноутбуки. Они работали на десктопах, так как те мощнее. Часть перешла на ноутбуки за время эксперимента, часть подключалась удаленно к десктопу, который стоял в офисе.

• Не у всех было хорошо обустроенное рабочее место дома. После первого эксперимента у части сотрудников появилось комфортное рабочее место, у части осталось по-старому.

• Wi-Fi в офисе на встречах иногда работал отвратительно. Видео не работало, звук сильно опаздывал. Качество Wi-Fi сильно улучшили за время первого эксперимента, но и во время второго картинка и звук были не всегда стабильными.

• Встречи с большой «лягушкой» в центре комнаты для удаленного участника превращались в гвалт и прерывания. Встречи стали жестче модерироваться и мы просили удаленных членов команды говорить, если что-то не слышно. Работало, но не всегда.

• Не у всех были вебкамеры. Купили.

• Не было широкоугольной вебкамеры для трансляции командных встреч. Купили.

• Встречи в переговорных, когда часть команды дома, часть в офисе. Одной модерации встреч не хватило. Мы пробовали проводить некоторые встречи с мест, но мешали коллегам в офисе. У нас разделенный open space. Проблему до конца не решили за время экспериментов.

• Переговорные комнаты. В офисе много переговорных комнат, но все они оборудованы для встреч от четырех человек и почти всегда заняты. Быстрые созвоны с удаленными членами команды приводили к поиску комнат по всему офису, и если все было занято, то встреча проводилась или из открытого пространства, или отменялась. В офисе появились комнаты для созвонов на одного человека. Один раз я в такой комнате провел два часа за разговором, и это оказалось удобно.

• Хранение личных вещей. Во втором эксперименте больше времени команда стала проводить вне офиса. И оказалось, что для открепления от рабочих мест нам не хватает мест хранения. Решили пока обойтись тумбочками. В будущем решили поменять на более удобные системы.

Что в результате

    Эксперименты подтвердили возможность удаленной работы. Для системности было предложено три варианта: 

• два дня в неделю — базовый вариант, предполагает два дня работы из дома в неделю. Рабочее место остается закрепленным за сотрудником;

• 3–4 дня в неделю — продвинутый вариант, предполагает один день работы из офиса в неделю. Рабочее место открепляется от сотрудника;

• полная удаленка. Рабочее место открепляется от сотрудника. Посещение офиса свободное.

Разные варианты оставляют руководителю управляемость над процессом перехода на удаленку. Не все те, кого нанимали изначально в офис, были готовы к удаленной работе. Вместе с руководителем можно было выработать план постепенного перехода к желаемому варианту.

История после 23 марта

Переход на полную удаленку прошел для нас бесшовно. Все процессы компании были перенесены в удаленный формат, некоторые мы потом обновили. Дальше буду говорить только про IT — это разработчики, тестировщики, автоматизаторы, менеджеры проектов, тимлиды и руководители. Частично затрону менеджеров продукта и дизайнеров.

IT Циан разделено на несколько направлений по сферам бизнеса. Внутри направлений процессы разработки и принцип разбиения команд могут отличаться. Снаружи это один процесс на уровне всей компании.

Общие процессы

Глобальное планирование происходит вехами. Веха — это целевое значение выбранной метрики, которого нужно достичь примерно за квартал. Менеджер продукта готовит инициативы, которые прокачивают метрику, и вся команда их оценивает. После этого становится понятно, что мы можем сделать. В веху также попадают стратегические проекты, которые не влияют на метрику, но важны для бизнеса в целом. Подробнее об этом можно посмотреть здесь: «Как мы учились мыслить ценностью, а не скоупом, и что из этого вышло». Петр Марков, РИТ++, 2018. [https://www.youtube.com/watch?v=tC9s7g4fb8w]

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

Разработка внутри Циан оцифрована (полный обзор — «Тотальный контроль производительности». Михаил Юматов, Pycon Russia, 2017. [https://www.youtube.com/watch?v=-J5UTQObcGM]). 

Есть основные метрики, которые должны соблюдать все направления независимо от внутреннего процесса:

• Time-To-Market(TTM) фич не больше двух недель. Фича — законченная продуктовая функциональность, которая может быть открыта пользователю. TTM — время от начала разработки до релиза на прод (или попадания в RC сборку приложения);

• SLA для задач в микросервисах. Более 70% задач в микросервисах должны попадать в продакшн быстрее, чем за 12 рабочих часов;

• SLA багов. Баги должны закрываться за определенное время в зависимости от приоритета. Норма — 10 дней, мажор — 2 дня, крит — 4 часа, блокер — 2 часа;

• Reopen rate. Количество переоткрытых задач — не более 30%. Причины переоткрытия задач — непрохождение ревью (сюда же включены технические проверки кода — рабочие тесты, покрытие тестами, проверка линтера), переоткрытие QA, большой фон ошибок в канарейке и технические проблемы CI/CD системы.

Есть еще вспомогательные метрики, которые смотрят руководители направлений и лиды команд. Информация забирается из джиры и импортируется в postgres. Далее любой человек в IT может построить дашборды и метрики, полезные для себя. У меня есть много своих дашбордов из метрик: статус спринта, общее попадание в оценку проекта, распределение багов по разработчикам и другие.

Внутри нашего направления мы записываем время, потраченное на задачу, для того чтобы понимать, насколько хорошо оцениваем задачи и проекты. Пользуемся функцией логирования времени в Jira.

По внешним большим процессам можно рассказать еще много, и, скорее всего, потянет на отдельную статью. Если что-то интересно — задавайте вопросы в комментариях, постараюсь быстро ответить. 

Основные столпы: синхронное стратегическое планирование на уровне компании, недельные тактические итерации и полностью оцифрованная разработка. Сейчас это позволяет нам сказать, что мы не потеряли в эффективности в сравнении с офисным периодом.

Ведение проектов

Все инициативы мы упаковываем в проекты. Большие проекты делим на фичи, если это возможно. Каждый проект имеет несколько свойств и артефактов:

• маечная оценка трудоемкости перед стартом. Свойство в jira;

• маечная оценка в конце. Свойство в jira;

• статья с описанием проекта. Страница в confluence;

• дизайн. Макеты внутри figma.

Маечная оценка — это верхнеуровневая оценка трудоемкости проекта в размерах маек: XS, S, M, L, XL. Каждый размер соответствует часам XS — 16 часов, S — 40 часов, M — 80 часов, L — 160 часов, XL — 480 часов. На каждый стек, необходимый в проекте, ставим отдельную майку.

Расскажу поподробнее о статье проекта и о том, как она появляется. В нашем направлении статью чаще всего создает менеджер продукта. Внутри он описывает инициативу и целевую метрику. Способ запуска — эксперимент или нет. В каком случае будем считать эксперимент успешным. Описание инициативы может быть поверхностным или очень глубоким, зависит от типа проекта. 

Дальше вся команда разработки садится и прорабатывает, что конкретно и как мы будем делать. Любой разработчик может поставить под сомнение любую часть инициативы — от базовой предпосылки до интерфейсного решения. В процессе работы мы уточняем дизайн, интерфейсное решение и детали бизнес-логики. Все обсуждения и решения записываются в статью.

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

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

CI/CD атоматизация

Об этом много писать не буду. Мы умеем выкатывать 75% задач в прод быстрее восьми часов, собирать еженедельно сборку приложений и обновлять монолит планово один раз в день. Где об этом почитать:

• «Как доставить быстро и без боли. Автоматизируем релизы». Александр Коротков, РИТ++ 2019; [https://www.youtube.com/watch?v=0wvUyjexoIg&feature=emb_title]

• «Меняем толстое на гибкое. CI/CD на BPMN+Camunda». Александр Коротков, TechleadConf, 2020. [https://techleadconf.ru/2020/abstracts/6742];

• «От скриптов к собственной платформе: как мы автоматизировали разработку в ЦИАН». [https://habr.com/ru/company/cian/blog/486056/]

Промежуточные итоги

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

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

    Для продуктовых команд хорошо работает распространение среди всех участников информации, достаточной для принятия автономных решений. Попробуйте это сделать на 2–3 проектах, и, возможно, это сильно ускорит разработку.

    Система автоматического деплоймента позволила нам не замедлить выкатку задач в прод. Даже в моменты, когда никто не ходит в офис. Если у вас сейчас нет автоматического деплоймента, то стоит  попробовать его сделать.

    Основная мысль — экспериментируйте с подходами и процессами в безопасной среде. Наш опыт может быть как полезен, так и вреден для вашей команды разработки. Только опытным путем получается понять, что работает, а что нет.

Здесь хочу закончить первую часть статьи. Во второй части:

• как изменился наём на удаленке;

• как происходит выход новых сотрудников на удаленку;

• над какими проблемами работаем.

Если есть что-то, что вы хотели бы узнать, спрашивайте в комментариях.