Идея написать данную статью у меня возникла в самый обычный рабочий день, в момент когда ко мне от менеджеров в jira упала новая задачка. Сама задача была нормально заполнена - было и подробное описание, и ссылка на документацию с бизнес-требованиями, и приложены макеты.
Однако, её статус был не в “Ready for development”. Также можно было увидеть что сама задача ждёт выполнения другой задачи - на разработку API с данными. Здесь у меня начались вопросы, а также желание в очередной раз разъяснить менеджерам что критичных блокеров у этой задачи нет.
За годы службы фронтенд‑разработчиком могу уверенно сказать что одна из достаточно часто встречающихся проблем в рабочем процессе команд веб‑разработки — это неправильно построенная коммуникация между фронтенд и бэкенд разработчиками, не до конца разделенные между ними сферы ответственности, и в целом пуск деятельности на самотек, «авось как‑нибудь сработаются, главное чтобы в конце нормальный продукт получился». При том что внутрикомандные практики взаимодействия между разработчиками в большинстве компаний в целом отлажены, взаимодействию межкомандному уделяется гораздо меньше времени, что странно, учитывая, что работают они зачастую над одним и тем же продуктом.
Одной из частностей этой общей проблемы является то, что в большинстве мест где я работал, толком была не распараллелена работа между бэкенд и фронтенд разработчиками. И даже если макеты готовы и сама фича «от и до» проанализирована со стороны системных аналитиков, то есть уже понятно что нужно получить на выходе — команде фронтенд‑разработки все‑равно надо дождаться работающей апишки прежде чем приступить к работе. Причем такая ситуация стабильно не меняется с годами, и отсутствие готовой серверной части фичи по умолчанию является блокером для работы команды клиентской разработки.
