Слова «фронтенд» и «бэкенд» описывают части системы, а не список ролей в проекте. Из-за этой подмены разговор о команде сводится к вопросу «сколько нужно программистов», хотя буксуют проекты обычно не из-за нехватки рук на коде. Разберём полный состав ролей, что из этого можно совмещать, что совмещать нельзя, что обязан делать заказчик и что остаётся у компании, когда работу выполняет внешняя команда.
Части системы и роли в проекте — не одно и то же
Фронтенд — это то, что открывается в браузере: вёрстка, экраны, поведение элементов. Бэкенд — то, что работает на сервере: данные, расчёты, права доступа, обмен с другими системами. Это деление кода.
Роль — это зона ответственности человека: кто формулирует задачу, кто принимает решение по спорному вопросу, кто проверяет результат, кто отвечает за содержимое после запуска. Один человек может закрывать несколько ролей, и наоборот — одну роль иногда делят двое. Поэтому список «два разработчика и дизайнер» ничего не говорит о том, дойдёт ли проект до запуска.
Полный состав ролей и зоны ответственности
| Роль | За что отвечает | Что от неё остаётся на проекте |
|---|---|---|
| Менеджер проекта | Сроки, приоритеты, коммуникация, риски | План работ, статус задач, договорённости в письменном виде |
| Аналитик | Постановка задачи, сценарии, требования к данным | Описание функций и правил, по которым потом принимают работу |
| Проектировщик интерфейсов | Структура экранов, сценарии, состояния, тексты | Прототип и логика переходов между экранами |
| Дизайнер | Оформление, типографика, адаптив, дизайн-система | Макеты и набор повторно используемых компонентов |
| Фронтенд-разработчик | Вёрстка, поведение интерфейса, скорость загрузки | Клиентская часть и её исходники |
| Бэкенд-разработчик | Данные, логика, интеграции, права доступа | Серверная часть, схема базы, описание методов обмена |
| Тестировщик | Проверка сценариев, крайние случаи, повторные проверки после правок | Список проверок, который переиспользуется при каждом обновлении |
| Администратор сервера | Хостинг, домен, почта, резервные копии, сертификаты | Доступы, инструкция по развёртыванию, расписание копий |
| Контент-менеджер | Наполнение, актуальность, картинки и документы | Заполненные разделы и правила ведения |
| Владелец продукта со стороны заказчика | Решения по спорным вопросам, приёмка результата | Одна точка ответственности вместо пяти мнений |
Что совмещается в небольшой команде
На проекте длиной в несколько месяцев редко бывает по человеку на роль. Совмещение — норма, если зоны ответственности названы вслух и записаны.
- Разработчик делает и клиентскую, и серверную часть. Работает, пока проекту не нужны одновременно сложный интерфейс и высокая нагрузка.
- Менеджер выполняет функции аналитика. Допустимо, если он действительно погружается в предметную область, а не пересылает письма между сторонами.
- Проектировщик и дизайнер — один человек. Частый и рабочий вариант.
- Администрирование берёт на себя бэкенд-разработчик. Приемлемо при условии, что резервные копии настроены и хотя бы раз проверены восстановлением, а не просто «где-то есть».
Что совмещать нельзя
Есть пары ролей, объединение которых убирает контроль, а не экономит бюджет.
- Автор задачи и приёмщик результата. Если работу принимает тот же человек, который её ставил, никто не проверяет, решена ли исходная проблема бизнеса.
- Разработчик и единственный тестировщик своей работы. Автор кода проверяет то, что задумал, а не то, что сделает пользователь. Самопроверка нужна, но она не заменяет отдельный взгляд.
- Владелец решений и исполнитель. Когда подрядчик сам решает, каким должен быть бизнес-процесс, спорить об этом на приёмке уже поздно.
Роль заказчика: без неё не работает ничего
Больше всего проектов тормозит не на стороне разработки. Со стороны компании нужны три вещи, и все три — с фамилиями.
- Единая точка решений. Один человек с полномочиями отвечать на вопросы и утверждать спорное. Если правки приходят от нескольких руководителей и противоречат друг другу, команда делает работу дважды.
- Контент. Тексты, фотографии, документы, описания услуг. Готовый сайт без наполнения не запускается, а собрать содержимое за компанию подрядчик не может: он не знает деталей бизнеса.
- Доступы. Домен, хостинг, почта, аналитика, учётные системы, платёжный сервис. Отсутствие одного доступа останавливает целый этап, и выясняется это обычно в последний день.
Что происходит после запуска
Запуск — не конец проекта, а смена режима. К этому моменту должно быть понятно, кто закрывает четыре задачи: приём и разбор обращений от пользователей, обновление системного окружения и модулей, резервное копирование с проверкой восстановления, ведение содержимого. Отдельно стоит договориться, как ставятся срочные задачи и что считается срочным: без этого мелкая правка идёт по общей очереди, а авария — тоже по общей очереди.
Как понять, какой роли не хватает
Быстрая проверка: задайте по проекту шесть вопросов и попробуйте ответить фамилией, а не названием отдела.
- Кто принимает решение по спорному вопросу и может сказать «делаем так»?
- Кто описывает, как функция должна работать, до начала разработки?
- Кто пишет тексты и готовит фотографии?
- Кто проверяет работу до показа заказчику?
- Кто отвечает за сервер, домен и резервные копии?
- Кто отвечает за сайт через полгода после запуска?
Если хотя бы на один вопрос ответа нет, это и есть слабое место проекта. Обычно без ответа остаются четвёртый и шестой.
Внешняя команда и что обязано остаться у компании
Штатная команда знает предметную область и всегда под рукой, но её нужно набирать, загружать работой и удерживать. Внешняя подключается быстрее и закрывает роли, которые не нужны постоянно: тестировщика, администратора, проектировщика. Разница не в качестве, а в том, что при работе с подрядчиком часть ответственности легко потерять по невнимательности.
Независимо от того, кто выполняет работу, у компании должны оставаться:
- доступы к домену, хостингу, почте, аналитике и платёжным сервисам, оформленные на компанию, а не на сотрудника подрядчика;
- исходный код в репозитории, доступ к которому есть у заказчика;
- описание того, как проект разворачивается и обновляется;
- перечень интеграций и учётных записей, которые используются;
- макеты и дизайн-система в исходных файлах, а не только картинками.
Проверять это стоит не при расставании, а на первом месяце работы: тогда восстановление недостающего стоит одного письма, а не отдельного проекта.
Если на проекте не хватает конкретных ролей, а нанимать их в штат рано, мы закрываем их своими специалистами: выделенная команда разработки под задачи проекта, с названными зонами ответственности и передачей доступов и исходников на вашей стороне.
