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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Ответственный ежедневно кидает в чат свежие статьи для развития, обсуждаем новые подходы и практики, пробуем, применяем.

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