company_banner

Как организовать эффективную работу распределенной команды верстки

Всем привет! Меня зовут Роман, и сегодня я поделюсь своим опытом работы в распределенной команде верстки. Расскажу о процессах, которые мы построили, и как команда из четырех человек покрывает потребности в верстке целого подразделения, состоящего из 30+ продуктов и 20+ продуктовых команд.


Как организовать эффективную работу распределенной команды верстки

Еще расскажу о том, как:


  • Контролировать работу распределенной команды;
  • Добиваться консистентности кода в разных проектах;
  • Справедливо распределять задачи;
  • Поддерживать высокое качество работы;
  • Не накапливать незавершенные задачи;
  • Проводить профилактику выгорания и развивать сотрудников.

Вместо вступления


Думаю, стоит сразу рассказать о том, почему у нас в Тинькофф Бизнесе есть выделенные верстальщики. Ведь бытует мнение, что любой веб-разработчик должен уметь хорошо верстать.


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


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


Как было раньше?


Раньше процесс был достаточно простым.


В моем подразделении было четыре верстальщика и специальный чатик, куда все заинтересованные кидали задачки на верстку, а мы их потихоньку разбирали. В целом система работала, но были, конечно, и свои недостатки.


Например, задачу могли кинуть, но никто из верстальщиков на сообщение не реагировал. Автор задачи начинал писать в чатик еще раз — мол, кто же все-таки возьмет задачу? Плюс не было никакого планирования и понимания, кто чем занят, когда освободится и в какие проекты погружен.


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


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


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


Вот что из этого получилось.


Строим команду


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


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


Контроль


Как контролировать работу сотрудников, если они не сидят рядом?


Вообще существуют разные типы контроля в зависимости от уровня скиллов и уровня доверия к сотруднику. Не буду останавливаться на них подробно, вы и сами все узнаете.


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


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


Консистентность кода


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


Да, если вы напишете в CSS свойство цвета выше ширины, то получите комментарий и ваш PR не будет смёржен. Это может показаться странным, ведь порядок свойств в большинстве случаев не повлияет на итоговый результат, но мы же помним: много проектов, единый высокий уровень качества. Поэтому у нас должен быть максимальный порядок. Везде. Даже порядок в порядке свойств.


Сразу скажу, что это была хорошая идея — зафиксировать порядок. Он позволяет писать более структурированный и продуманный CSS. Например, есть правило группировки свойств. Если вы пишете display: flex, то все сопутствующие свойства (align-items, justify-content) должны быть описаны рядом, чтобы было проще понимать, что происходит.


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


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


Распределение задач


Итак, коммуникация налажена, правила игры зафиксированы, но как играть? Почему Ваня делает только простые задачи, а Пете достаются сложные, да еще и из проекта, которым давно никто не занимался?


И правда, есть проекты, которым:


  • постоянно нужна верстка;
  • постоянно нужна верстка и у них все постоянно меняется;
  • которые писались очень давно и снова начинают развиваться.

Тут появляется очередной вопрос: как равноценно и справедливо распределять задачи?


А нужна ли справедливость?


Можно задействовать административный ресурс и жестко сказать: «Петя, ты делаешь эти задачи, они никому не нравятся, а мы пока с Ваней возьмем вот эти, интересные».


Так, конечно, можно поступить, и некоторое время это даже будет работать. Но минусов от этого мы получим сразу несколько:


  1. Петя начинает нас немного недолюбливать, а значит, меньше вовлечен в командную работу;
  2. Петя может когда-нибудь сгореть и уволиться, да еще не предупредив заранее, и у нас образуется дыра в ресурсах;
  3. У Пети была самая большая экспертиза в сложных проектах, а теперь каждому из оставшихся потребуется много времени, чтобы разобраться в проектах Пети.

Кажется, что так поступать не стоит. Но как быть?


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


У нас это выглядит примерно так.


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


Но опять мы упираемся в проблему, когда человек, постоянно работающий над проектом А, понятия не имеет, что происходит в проекте С.


Для решения этой проблемы у нас введены двухнедельные дежурства.


С понедельника и на ближайшие две недели Петя работает над проектом А, затем переходит на проект B, потом C — так он регулярно меняет свою деятельность.


Выглядит это примерно так:


Ваня Петя Миша Андрей
Проект A 1 и 2 неделя 3 и 4 неделя 5 и 6 неделя 7 и 8 неделя
Проект B 3 и 4 неделя 5 и 6 неделя 7 и 8 неделя 1 и 2 неделя
Проект С 5 и 6 неделя 7 и 8 неделя 1 и 2 неделя 3 и 4 неделя
Проект D 7 и 8 неделя 1 и 2 неделя 3 и 4 неделя 5 и 6 неделя

Что нам это дает? Во-первых, все ребята одинаково хорошо разбираются во всех проектах и могут без проблем подменить друг друга. Во-вторых, есть более интересные проекты и это их любимое дежурство, что дополнительно мотивирует, придает сил и не позволяет выгореть от однотипной работы.


Более того, чтобы убрать ручное регулирование, мы договорились, что приоритет работ выставляет сам проект. То есть мы выделяем человека, а он выполняет те задачи, которые дает проект. Это очень удобно: нам не нужно приоритизировать внутри команды и думать над очередностью. Этим занимается проект, его команда и продукт-менеджер.


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


Кажется, что его может засыпать задачами, а заказчики будут дергать со всех сторон и в итоге не дадут работать. Чтобы исключить этот риск, у нас есть специальная страница с такими задачами. Когда появляется очередная задача, она добавляется в конец списка.


Вот пример такой странички:


Страница со списком задач

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


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


Можно подумать, что это достаточно слабое место и нас должно засыпать, но вот уже полгода это работает.


Конечно, ситуации могут быть разные, но ручное регулирование и административный ресурс никто не отменял ;)


Контроль качества


Все совершают ошибки. Я еще не видел ни одного разработчика или верстальщика, который ни разу не ошибался. Как можно минимизировать количество таких ошибок?


Для этого у нас активно применяется практика дизайн-ревью. Что она в себя включает?


Когда работа над макетом закончена, верстальщик созванивается с дизайнером и показывает ему результат работы на своем экране. Это позволяет решить сразу несколько вопросов:


  1. Дизайнер может максимально быстро увидеть как ошибку верстальщика, так и свою ошибку, если в макет закралась неточность.
  2. Оперативно решить вопросы типа «как должно отображаться при наведении или фокусе?». Если, конечно, эти состояния не были отражены в дизайне.
  3. И большой дополнительный плюс: дизайнер может увидеть, что результат смотрится не оптимально, и в режиме онлайн внести изменения.

В самом начале внедрения этой практики мы опасались, что работа будет тормозиться, потому что:


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

Но на практике этот подход хорошо себя зарекомендовал, и мы внедрили его на большинстве проектов.


Ревью


Мы неплохо прокачали нашу команду верстки, можно идти работать! Но нет, есть еще кое-что. У нас принята практика кросс-ревью.


Это значит, что любой может ревьюить твои PR-ы и оставлять к ним комментарии. Только, если быть честным, многие разработчики не любят вникать в ревью верстки и готовы поставить апрув «не глядя» — лишь бы верстка поскорее заехала и они смогли скорее писать логику.


Чтобы не допустить такого, у нас есть правило: каждый верстальщик обязан добавлять во все свои пул-реквесты всех верстальщиков.


И PR нельзя мёржить, если не получен хотя бы один апрув от другого верстальщика. Неплохо, но кажется, что есть риск образования пробки в виде огромного количества PR-ов, потому что сотрудники могут просматривать код коллег несвоевременно, из-за чего работа будет тормозиться.


Чтобы такого не допустить, у нас два раза в день, в 10:00 и 15:00, стреляет в чат напоминалка о необходимости провести ревью коллег. И когда заходишь в stash, ты видишь, сколько PR-ов ждут твоего анализа.


Пример напоминалки о необходимости провести ревью

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


Плюс к этому есть дополнительная персональная ответственность за свои пул-реквесты. Что это значит?


Ты сделал верстку, все по макету, все красиво, но нет функциональности. И катить такое в прод ну никак нельзя. А значит, нельзя и мёржить в develop. А PR у тебя открыт, апрувы есть и кажется, что ты свою работу выполнил. К тому же к тебе приходит разработчик и говорит: «А давай подождем пару дней, я залью логику прямо в твою ветку — и сразу работающую фичу и смёржим?» А вот и нет! Так это не работает. И не должно.


Работа не считается законченной, пока твой PR с версткой не смёржен. Как поступать в такой ситуации? Да очень просто: разработчик создает свою ветку, где планирует писать логику, а мы мёржим верстку в его ветку. Профит.


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


Периодически мы устраиваем опрос на созвонах: у кого сколько открытых PR-ов и сколько PR-ов нужно проревьюить. Цифры стабильно меньше 10, стремимся к тому, чтобы стали меньше 5. Такие опросы подтверждают, что автоматические напоминалки в чатик все еще работают и сотрудники реагируют на них.


Вот сейчас есть ощущение, что работа выстроена очень неплохо, можно сидеть и бесконечно смотреть на то, как задачи переводятся из одного статуса в другой (кстати, мы за этим строго следим), но что по развитию? Верстаем таблицами? Не знаем, что веб не стоит на месте?


Развитие


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


Пример ссылки на статью в чате

Информацию берут на любимых ресурсах, на том же «Хабре» например. Это достаточно удобно, ведь ты знаешь, что твой коллега ежедневно кидает в чат ссылки на топовые статьи, а тебе осталось лишь прочитать ее вечером после работы.


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


Если вас пугает количество дежурств, то все не так плохо. Стабильно у одного сотрудника одно дежурство — это проект, на котором он работает. И периодически добавляется второе дежурство — грин-флаг или мотиватор грин-флага, — которое, по сути, просто формальность.


Итоги


Итак, только что мы собрали с нуля распределенную, а главное — работающую команду верстки. Давайте вспомним, что нам помогло:


  1. Приватный чат позволяет оперативно решать все возникающие вопросы.
  2. Ежедневные дейлики помогают быть в курсе, кто чем занимается, и понимать общую картину.
  3. Зафиксированные правила работы и строгое их соблюдение позволяют поддерживать консистентность кода во всех проектах.
  4. Двухнедельные круговые дежурства позволяют быть в контексте всех проектов и обеспечивают справедливое автоматическое распределение задач.
  5. Дизайн-ревью позволяет быть уверенными в качестве результата, который попадает к клиенту.
  6. Следим, чтобы ревью выполнялось регулярно и чтобы не скапливалась своя незавершенная работа.
  7. Ответственный ежедневно кидает в чат свежие статьи для развития, обсуждаем новые подходы и практики, пробуем, применяем.

Все это помогает нам закрывать задачи и обеспечивать версткой целое подразделение. А какие активности есть в ваших командах?

Tinkoff.ru
IT’s Tinkoff.ru — просто о сложном

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

    0
    Вот еще хорошее видео по теме управления распределенными командами от deusdeorum
      +1
      Имел удовольствие поработать в такой «распределённой команде», и имею добавить ещё пуру важных пунктов.
      Строгие и всеобъемлющие гайды. Ставить отступы перед блоком или после? Делать списки div-ми или ul-ми? Хлебные крошки и заголовок — часть контента страницы или часть лейута? Кнопка с иконкой- это отдельный компонент, или подвид обычной кнопки? Как делать переключатель для табов, отдельным компонентом или частью контейнера? И много других интересных вопросов, которые каждый будет решать в меру своего опыта.
      Выдавать работу последовательно. Сначала базовые «атомы», потом блоки, потом структурный лейаут, потом страницы. А иначе, если сразу раздавать страницы, вкупе с предыдущим пунктом, у вас образуется несколько огрызков несовместимых UI-китов, которые потом придётся долго и болезненно сращивать.
      Не подгоняйте график работы под график созвона с клиентом. Это приведёт к тому, что часть задач будет сделана «лишь бы успеть», а времени на доделку потом не дадут, «вы же её уже сдали».
      Не дробите задачи слишком мелко. Время на командное взаимодйствие — величина мало зависимая от размера задачи. При длительности задачи менее 1.5 часов (по своему опыту), на мерджи, пул-реквесты, автотесты, код-ревью, таск-трекер и прочую бюрократию начинает уходить времени больше, чем на саму задачу. Идеальный вариант — чтобы в один рабочий день укладывалась 1 или 2 задачи со всей бюрократией.

      Вроде бы всё очевидно, но не раз уже видел, как на всё это забивают.
        +1
        Все правильно говорите. Имел несчастье в одно время поработать в команде, где на задачу давали менее 30 минут со всей бюрократией. Благо поработал там не долго, но опыт получил из области «как делать не надо».
        А вообще я придерживаюсь мнения, что задач «менее одного часа» не бывает.

        Автор статьи молодец. С большим удовольствием прочитал статью.
          0
          Спасибо за дополнения, они действительно очень полезные. Согласен со всеми пунктами. У нас касательно первого пункта — нет гайда по всем возможным ситуациям, но подходы к решениям +- используются одинаковые. Если появляется неочевидное решение — мы обсуждаем его и, если автор может аргументированно показать его целесообразность и эффективность, берем его на «вооружение»
          0
          Я правильно понял, что верстальщики и разработчики работают в одном проекте?
            0
            Да, все верно. Причем довольно часто команда разработки работает над одним проектом постоянно, в то время как верстальщики приходят на проект по мере появления задач. Когда задач нет, верстальщики работают над другими проектами, где, как правило, свои команды разработки.
            0
            Спасибо за статью, очень интересный материал. Добавлю от себя довольно хороший инструмент — интерактивный прототип в Фигме, позволяет лучше понять логику работы приложения, сокращает время на коммуникацию с дизайнером, уменьшает количество корректировок.
              0
              Спасибо, да, Фигма топовый инструмент
              0

              Роман, все вроде у вас складно, но есть вопросы по верстке:
              1) в техподдержке мне обещали закрыть 13 января (?) баг с невозможностью писать цифры в хроме в инпуте, в результате чего я не могу залогиниться в свой клиент-банк для бизнеса и пользоваться деньгами;
              2) в платежном поручении нет 2019 года в налоговых платежах — нельзя оплатить обязательные платежи ИП — этот баг обещали закрыть 20 января. Но черт побери! Заплатить-то нужно до конца года! Хотя, какое это имеет значение, если в клиент-банк вообще невозможно зайти.


              Хорошо, что счет не только в вашем банке. Я считаю, что такие баги нужно закрывать не в следующем году, а немедленно.

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

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

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