Структура и процессы бэкенд-команды: распределение задач, коммуникация и работа

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

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

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

Как выстроена коммуникация с другими специалистами
Бэкендер постоянно взаимодействует с участниками команды из других направлений:

➡️ С фронтендом ведется наиболее частое взаимодействие, поскольку комплексная бизнес-задача требует доработок с обеих сторон. Бэкенд и фронтенд работают в паре и совместно устраняют баги, заведенные тестировщиком.
➡️ Если возникают вопросы по функциональности, бэкендер напрямую обращается к аналитику, автору постановки, за уточнением требований.
➡️ Когда задача уходит в тестирование, тестировщик может обратиться к бэкендеру и фронтендеру, например, при обнаружении неочевидного бага.
➡️ Взаимодействие с ML-командой ведется через тимлида. Бэкендер получает готовые образы и API, за концептуальное видение отвечает тимлид. В редких случаях конкретный специалист может напрямую связаться с ML-разработчиком для решения локальной задачи.
➡️ При проблемах на продакшен-стенде бэкендер и DevOps исследуют проблему в паре. Если источник в инфраструктуре, устранением занимается DevOps, если в коде — бэкенд. По итогу совместного анализа определяется, кто берет задачу на себя.