Не проводим дейлики и прекрасно себя чувствуем

Начну с того что у нас крайне гибкий график и есть те кто начинают работать с 16 по МСК, есть те кто живут в +3 от МСК, кто-то условно может взять выходной в понедельник вместо воскресенья. В таких условиях часто достаточно сильно проседает общая производительность команды, все друг друга ждут, Lead Time растёт

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

Минимум личных сообщений, всё общение внутри задач.

Для этого крайне важно уметь работать с трекером, у нас это ClickUp и там очень удобно работают уведомления: совершая любое действие с задачей, в том числе если оставить там коммент — ты становишься вотчером. А вотчер получает уведомления по всем действиям с этой задачи. Так же можно поставить десктоп версию и приложение для пушей.

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

А точнее увеличение этой метрики.

Фактор автобуса — это мера сосредоточения информации среди отдельных членов проекта.

В первую очередь банальное cross review помогает нескольким разработчикам быть в контексте задач другого. Этого достаточно часто хватает, чтобы закрыть срочную задачу.

Ну и в крайнем случае, если совсем никого нет, то подключаюсь я, так как сам разработчик (Node.js, React, Vue, немного React Native). Например, недавно клиент 4 января пришёл с просьбой переключить приложение в боевой режим, соответственно нужно заменить креды в одной из интеграций, все проверить и залить. Что собственно и сделал, так как не хотелось никого вытягивать с выходных.

Так же любой может без проблем подключиться к любой задаче, так как есть контекст (коммуникация в задачах). Мне, например, удобно подключаться на помощь к решению вопроса, меня просто тегают в задаче, я захожу и вижу что обсуждали и почему вопрос возник

Хоть график гибкий, все равно часто люди работают в одно и то же время. Например, с 8 утра до 11 и с 16 до 21, или по вторникам никогда не работает. Мы это фиксируем, все знаем кто когда обычно в сети и строим правильные ожидания. Плюс в ClickUp есть удобная штука — Pulse

В первую очередь перед фичей/некоторым объёмом задач — бэк составляет контракты по которым можно подключать фронт. Составляют ориентируясь на дизайн или прототип. Это в принципе правильный процесс не только с точки зрения сокращения коммуникации, но и в целом на этом этапе разработчик бэка может понять где и какие выборки нужны будут и какие индексы понадобятся.

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

Не важно какой инструмент у вас в команде: Jira, Youtrack, Trello, ClickUp. Важно пользоваться им на полную. Для меня максимально подходящим и удобным оказался ClickUp, каждый раз с помощью него удается легко внедрить новый любой процесс. Работа с трекером у нас очень активная, даже дейликов нет, оставили только формальные статусы в текстовом виде 3 раз в неделю. Зачастую даже они пользы большой не несут, так как всё видно в трекере, лишь иногда на подобных статусах появляются вопросы.

Ну и конечно важно как активно разработчики работают с задачами в трекере. Если разработчики не понимают для чего и зачем — никакие процессы не помогут