Всем привет! Меня зовут Роман, и сегодня я поделюсь своим опытом работы в распределенной команде верстки. Расскажу о процессах, которые мы построили, и как команда из четырех человек покрывает потребности в верстке целого подразделения, состоящего из 30+ продуктов и 20+ продуктовых команд.
Еще расскажу о том, как:
- Контролировать работу распределенной команды;
- Добиваться консистентности кода в разных проектах;
- Справедливо распределять задачи;
- Поддерживать высокое качество работы;
- Не накапливать незавершенные задачи;
- Проводить профилактику выгорания и развивать сотрудников.
Вместо вступления
Думаю, стоит сразу рассказать о том, почему у нас в Тинькофф Бизнесе есть выделенные верстальщики. Ведь бытует мнение, что любой веб-разработчик должен уметь хорошо верстать.
Во многих компаниях разработчики все верстают сами. Но, во-первых, не все разработчики любят верстать и делают это достаточно хорошо. Во-вторых, для разработчика верстка далеко не всегда находится в высоком приоритете, фокус смещен на код. А когда нет фокуса — страдает качество и отношение к деталям.
Поэтому у нас есть выделенные верстальщики, но они не прикреплены к конкретному проекту, ведь не все проекты могут обеспечивать задачами по верстке постоянно.
Как было раньше?
Раньше процесс был достаточно простым.
В моем подразделении было четыре верстальщика и специальный чатик, куда все заинтересованные кидали задачки на верстку, а мы их потихоньку разбирали. В целом система работала, но были, конечно, и свои недостатки.
Например, задачу могли кинуть, но никто из верстальщиков на сообщение не реагировал. Автор задачи начинал писать в чатик еще раз — мол, кто же все-таки возьмет задачу? Плюс не было никакого планирования и понимания, кто чем занят, когда освободится и в какие проекты погружен.
Чтобы сообщения от авторов не висели без ответов, даже когда все заняты, я начал отвечать на все сообщения и прикидывать, кто когда сможет взять ту или иную задачу. Параллельно фиксировал, кто в каких проектах участвовал, кто в каких задачах разбирается лучше всего. Так продлилось около месяца, система стала работать лучше — мгновенная реакция на задачки полностью устраивала заказчиков.
Правда, такой подход все еще не давал ответов на многие вопросы. Например, сложно было прогнозировать загрузку, не было единства в подходах, не было какого-то планирования, каждый был сам по себе и самостоятельно решал свою задачу. Кроме чата не было единой точки входа в верстку, не с кем было обсудить новый проект, оценить дизайн, потому что непонятно, кто и когда будет над ним работать.
И вот на одной из встреч с руководителем мы решили организовать новую команду верстки из всех верстальщиков, с кем мы делили задачи, чтобы выстроить процессы и обеспечить версткой все проекты.
Вот что из этого получилось.
Строим команду
Дано: четыре верстальщика из разных городов и даже стран. 30+ проектов на одинаковом стеке, но, ввиду особенностей проектов, часто с разной архитектурой, разными версиями дизайна и компонентами, разными командами разработки, которые иногда практикуют свои подходы.
Прежде всего мы создали приватный чат только с верстальщиками. Это позволяет оперативно решать вопросы команды, когда не требуется большая срочность, а также всегда можно задать вопрос, попросить коллег о помощи или ревью своей работы.
Контроль
Как контролировать работу сотрудников, если они не сидят рядом?
Вообще существуют разные типы контроля в зависимости от уровня скиллов и уровня доверия к сотруднику. Не буду останавливаться на них подробно, вы и сами все узнаете.
Мне повезло — все ребята были одинаково хорошего уровня и по умолчанию имели 100% доверия. Поэтому система нужна была не столько для контроля, сколько для синхронизации действий и для понимания общей картины. Для этого мы ввели ежедневные утренние созвоны протяженностью до 10 минут, на которых все говорили, что они делали вчера и что собираются делать сегодня.
Эти созвоны служат только для синхронизации по задачам и проектам, они не подразумевают разбора проблем, трудностей, холиваров или решения других вопросов — все это при необходимости выносится в отдельные созвоны или обсуждения в чате. Очень важно следить за этим и пресекать все попытки перевести созвон в часовую беседу о погоде.
Консистентность кода
К нам поступают задачи из совершенно разных проектов с разным кодом и качеством, поэтому необходимо было добиться поставки единого высокого уровня верстки во все проекты независимо от исходных данных. Для этого через общие обсуждения и голосования мы разработали правила и рекомендации по верстке, которые строго соблюдаем внутри нашей команды, а также рекомендуем к использованию всем другим. Прописан даже порядок свойств.
Да, если вы напишете в CSS свойство цвета выше ширины, то получите комментарий и ваш PR не будет смёржен. Это может показаться странным, ведь порядок свойств в большинстве случаев не повлияет на итоговый результат, но мы же помним: много проектов, единый высокий уровень качества. Поэтому у нас должен быть максимальный порядок. Везде. Даже порядок в порядке свойств.
Сразу скажу, что это была хорошая идея — зафиксировать порядок. Он позволяет писать более структурированный и продуманный CSS. Например, есть правило группировки свойств. Если вы пишете display: flex, то все сопутствующие свойства (align-items, justify-content) должны быть описаны рядом, чтобы было проще понимать, что происходит.
Сейчас мы постепенно приходим к тому, что выносим все правила в линтеры, чтобы снизить число некритичных комментариев на ревью, а также дать возможность ревьюерам сосредоточиться на действительно важных вещах, например на архитектуре.
Кстати, наши конфиги линтеров есть в открытом доступе, возможно, они и вам будут полезны. Скачать конфиги.
Распределение задач
Итак, коммуникация налажена, правила игры зафиксированы, но как играть? Почему Ваня делает только простые задачи, а Пете достаются сложные, да еще и из проекта, которым давно никто не занимался?
И правда, есть проекты, которым:
- постоянно нужна верстка;
- постоянно нужна верстка и у них все постоянно меняется;
- которые писались очень давно и снова начинают развиваться.
Тут появляется очередной вопрос: как равноценно и справедливо распределять задачи?
А нужна ли справедливость?
Можно задействовать административный ресурс и жестко сказать: «Петя, ты делаешь эти задачи, они никому не нравятся, а мы пока с Ваней возьмем вот эти, интересные».
Так, конечно, можно поступить, и некоторое время это даже будет работать. Но минусов от этого мы получим сразу несколько:
- Петя начинает нас немного недолюбливать, а значит, меньше вовлечен в командную работу;
- Петя может когда-нибудь сгореть и уволиться, да еще не предупредив заранее, и у нас образуется дыра в ресурсах;
- У Пети была самая большая экспертиза в сложных проектах, а теперь каждому из оставшихся потребуется много времени, чтобы разобраться в проектах Пети.
Кажется, что так поступать не стоит. Но как быть?
Для начала нужно выделить несколько групп, по которым можно разбить все входящие задачи.
У нас это выглядит примерно так.
Проекты А, 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 неделя |
Что нам это дает? Во-первых, все ребята одинаково хорошо разбираются во всех проектах и могут без проблем подменить друг друга. Во-вторых, есть более интересные проекты и это их любимое дежурство, что дополнительно мотивирует, придает сил и не позволяет выгореть от однотипной работы.
Более того, чтобы убрать ручное регулирование, мы договорились, что приоритет работ выставляет сам проект. То есть мы выделяем человека, а он выполняет те задачи, которые дает проект. Это очень удобно: нам не нужно приоритизировать внутри команды и думать над очередностью. Этим занимается проект, его команда и продукт-менеджер.
Правда, можно найти проблему. Один человек разбирается с задачами всех проектов, которые приходят нерегулярно, — это тот, кто в текущее дежурство не работает ни над одним из крупных проектов.
Кажется, что его может засыпать задачами, а заказчики будут дергать со всех сторон и в итоге не дадут работать. Чтобы исключить этот риск, у нас есть специальная страница с такими задачами. Когда появляется очередная задача, она добавляется в конец списка.
Вот пример такой странички:
На ней видны все задачи и их статусы. Заказчик в любой момент может отследить прогресс и понять, когда примерно его задача пойдет в работу.
Конечно, у всех самые срочные задачи и все хотят пройти без очереди. Специально для таких ситуаций был придуман следующий механизм: если у заказчика «горит» и он хочет отдать свою задачу в работу быстрее, он должен договориться с тем, кто стоит по списку выше него. Если тот готов отдать свое место — нет проблем, меняем местами задачки в списке.
Можно подумать, что это достаточно слабое место и нас должно засыпать, но вот уже полгода это работает.
Конечно, ситуации могут быть разные, но ручное регулирование и административный ресурс никто не отменял ;)
Контроль качества
Все совершают ошибки. Я еще не видел ни одного разработчика или верстальщика, который ни разу не ошибался. Как можно минимизировать количество таких ошибок?
Для этого у нас активно применяется практика дизайн-ревью. Что она в себя включает?
Когда работа над макетом закончена, верстальщик созванивается с дизайнером и показывает ему результат работы на своем экране. Это позволяет решить сразу несколько вопросов:
- Дизайнер может максимально быстро увидеть как ошибку верстальщика, так и свою ошибку, если в макет закралась неточность.
- Оперативно решить вопросы типа «как должно отображаться при наведении или фокусе?». Если, конечно, эти состояния не были отражены в дизайне.
- И большой дополнительный плюс: дизайнер может увидеть, что результат смотрится не оптимально, и в режиме онлайн внести изменения.
В самом начале внедрения этой практики мы опасались, что работа будет тормозиться, потому что:
- дизайнера нет на месте;
- дизайнер болеет, а никто другой не в курсе;
- во время ревью дизайнер решил полностью изменить макет.
Но на практике этот подход хорошо себя зарекомендовал, и мы внедрили его на большинстве проектов.
Ревью
Мы неплохо прокачали нашу команду верстки, можно идти работать! Но нет, есть еще кое-что. У нас принята практика кросс-ревью.
Это значит, что любой может ревьюить твои PR-ы и оставлять к ним комментарии. Только, если быть честным, многие разработчики не любят вникать в ревью верстки и готовы поставить апрув «не глядя» — лишь бы верстка поскорее заехала и они смогли скорее писать логику.
Чтобы не допустить такого, у нас есть правило: каждый верстальщик обязан добавлять во все свои пул-реквесты всех верстальщиков.
И PR нельзя мёржить, если не получен хотя бы один апрув от другого верстальщика. Неплохо, но кажется, что есть риск образования пробки в виде огромного количества PR-ов, потому что сотрудники могут просматривать код коллег несвоевременно, из-за чего работа будет тормозиться.
Чтобы такого не допустить, у нас два раза в день, в 10:00 и 15:00, стреляет в чат напоминалка о необходимости провести ревью коллег. И когда заходишь в stash, ты видишь, сколько PR-ов ждут твоего анализа.
Мы стараемся, чтобы эта цифра была минимальной. Для этого у нас есть еще одно правило хорошего ревью. Если ты до конца просмотрел PR, у него нет конфликтов и на нем нет статуса «в работе» — значит, от тебя обязательно должна быть реакция: либо «апрув», либо «на доработку». Если ты оставил комментарии, но не обозначил свою позицию — значит, ты досмотрел PR не до конца.
Плюс к этому есть дополнительная персональная ответственность за свои пул-реквесты. Что это значит?
Ты сделал верстку, все по макету, все красиво, но нет функциональности. И катить такое в прод ну никак нельзя. А значит, нельзя и мёржить в develop. А PR у тебя открыт, апрувы есть и кажется, что ты свою работу выполнил. К тому же к тебе приходит разработчик и говорит: «А давай подождем пару дней, я залью логику прямо в твою ветку — и сразу работающую фичу и смёржим?» А вот и нет! Так это не работает. И не должно.
Работа не считается законченной, пока твой PR с версткой не смёржен. Как поступать в такой ситуации? Да очень просто: разработчик создает свою ветку, где планирует писать логику, а мы мёржим верстку в его ветку. Профит.
Каждый верстальщик самостоятельно следит за своими PR-ами и разбирается с такими ситуациями: когда некуда мёржить, не собираются билды, бизнес решил отложить сроки запуска и прочее. Его работа не выполнена, пока PR не смёржен.
Периодически мы устраиваем опрос на созвонах: у кого сколько открытых PR-ов и сколько PR-ов нужно проревьюить. Цифры стабильно меньше 10, стремимся к тому, чтобы стали меньше 5. Такие опросы подтверждают, что автоматические напоминалки в чатик все еще работают и сотрудники реагируют на них.
Вот сейчас есть ощущение, что работа выстроена очень неплохо, можно сидеть и бесконечно смотреть на то, как задачи переводятся из одного статуса в другой (кстати, мы за этим строго следим), но что по развитию? Верстаем таблицами? Не знаем, что веб не стоит на месте?
Развитие
Чтобы команда развивалась не только в плане экспертизы между проектами, но и в плане скиллов, у нас есть специальное недельное дежурство, которое называется Green Flag. Если на этой неделе ты — грин-флаг, значит, ты ежедневно уделяешь время на поиск полезной информации по верстке, подходам или просто технологиям и кидаешь ссылки на статьи в наш приватный чат. Обычно это делают с утра или сразу после обеда.
Информацию берут на любимых ресурсах, на том же «Хабре» например. Это достаточно удобно, ведь ты знаешь, что твой коллега ежедневно кидает в чат ссылки на топовые статьи, а тебе осталось лишь прочитать ее вечером после работы.
Стоит сразу оговориться: несмотря на то, что эту активность все поддерживают, многие забывают делать это ежедневно. Поэтому мы ввели еще одно дежурство, тоже еженедельное, которое призвано мотивировать грин-флага не забывать про свои обязанности. А если грин-флаг все-таки забыл — проверяющий может скинуть инфу от себя. Интересно, но вот этот подход работает без сбоев и иногда оба дежурных кидают годноту в чат.
Если вас пугает количество дежурств, то все не так плохо. Стабильно у одного сотрудника одно дежурство — это проект, на котором он работает. И периодически добавляется второе дежурство — грин-флаг или мотиватор грин-флага, — которое, по сути, просто формальность.
Итоги
Итак, только что мы собрали с нуля распределенную, а главное — работающую команду верстки. Давайте вспомним, что нам помогло:
- Приватный чат позволяет оперативно решать все возникающие вопросы.
- Ежедневные дейлики помогают быть в курсе, кто чем занимается, и понимать общую картину.
- Зафиксированные правила работы и строгое их соблюдение позволяют поддерживать консистентность кода во всех проектах.
- Двухнедельные круговые дежурства позволяют быть в контексте всех проектов и обеспечивают справедливое автоматическое распределение задач.
- Дизайн-ревью позволяет быть уверенными в качестве результата, который попадает к клиенту.
- Следим, чтобы ревью выполнялось регулярно и чтобы не скапливалась своя незавершенная работа.
- Ответственный ежедневно кидает в чат свежие статьи для развития, обсуждаем новые подходы и практики, пробуем, применяем.
Все это помогает нам закрывать задачи и обеспечивать версткой целое подразделение. А какие активности есть в ваших командах?
Автор: Roman Aleksyutin
