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

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

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

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


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

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

18 декабря 2005

Местоположение

Россия

Численность

5 001–10 000 человек

Дата регистрации

26 октября 2011

Блог на Хабре