Кто работает над вашим проектом: роли в команде разработки и с кем из них заказчик общается

Короткий ответ: над проектом обычно работают менеджер проекта, аналитик, дизайнер, фронтенд- и бэкенд-разработчики, тестировщик и инженер по серверам (DevOps). В небольшом проекте один человек закрывает две-три роли, и это нормально. Заказчику важно другое: чтобы каждая задача из этого списка у кого-то была, а вопросы и решения шли через одного ответственного.

Ниже — что делает каждая роль, на каком этапе она нужна и что вы от неё получаете, как роли совмещают на разных проектах и по каким признакам в смете видно, что кого-то не хватает. О том, кто нужен с вашей стороны, есть отдельный текст — о владельце продукта у заказчика, здесь речь о команде исполнителя.

Какие роли бывают в команде разработки?

Основных ролей семь: менеджер проекта, аналитик, дизайнер, фронтенд-разработчик, бэкенд-разработчик, тестировщик и DevOps-инженер. Роль — это зона ответственности, а не обязательно отдельный сотрудник. Один человек может вести две роли, но задача каждой должна быть выполнена.

Разница между ролью и должностью важна для заказчика. Когда подрядчик пишет «над проектом работает команда», это ничего не говорит. Полезный вопрос другой: кто отвечает за требования, кто за интерфейс, кто за проверку, кто за сервер. Если на какой-то пункт ответ «никто» или «как-нибудь разберёмся», пробел вылезет позже — обычно на приёмке или в первый месяц работы.

Похожая логика есть и в гибких методиках. В Руководстве по Scrum (редакция 2020 года) команда описана через три зоны ответственности — владелец продукта, Scrum-мастер и разработчики, обычно до десяти человек. Слово «разработчики» там охватывает всех, кто делает продукт: и дизайнера, и тестировщика. В заказной разработке роли обычно делят подробнее, потому что заказчику надо понимать, за что он платит.

Роль	Чем занята	Когда включается	Что вы получаете
Менеджер проекта	Планирует работы, следит за сроком и составом, собирает вопросы к заказчику	С первого звонка до закрывающего акта	План, статусы, один адрес для вопросов, протоколы решений
Аналитик	Выясняет, как устроен ваш процесс, и превращает это в требования	До дизайна и разработки, потом — при изменениях	Техзадание, сценарии, список экранов и интеграций
Дизайнер	Проектирует интерфейс: структуру, экраны, состояния, адаптив	После требований, до вёрстки	Прототип и макеты, которые вы согласуете
Фронтенд-разработчик	Делает то, что видит пользователь: страницы, формы, кнопки	После согласования макетов	Работающий интерфейс на тестовом адресе
Бэкенд-разработчик	Делает серверную часть: базу данных, логику, API, интеграции	Параллельно с фронтендом	Хранение данных, расчёты, обмен с CRM, 1С, оплатой
Тестировщик	Проверяет сценарии, ищет ошибки до вас и пользователей	По ходу сборки и перед сдачей	Список найденных и исправленных ошибок, проверенные сценарии
DevOps-инженер	Настраивает сервер, выкладку, резервные копии, мониторинг	Перед запуском и в поддержке	Рабочий адрес, доступы, копии, понятный порядок обновлений

Что делает каждая роль простыми словами?

Менеджер держит срок и договорённости, аналитик переводит ваш бизнес в требования, дизайнер рисует экраны, фронтенд делает видимую часть, бэкенд — серверную, тестировщик ищет ошибки, DevOps отвечает за сервер и выкладку. Подробнее — по каждой роли.

• Менеджер проекта. Ваш основной собеседник. Составляет план, следит, чтобы работы шли в рамках согласованного состава, собирает вопросы к вам пачкой, а не по одному в час. Фиксирует решения письменно: что согласовали, что перенесли, что считается новой задачей.
• Аналитик. Разбирается, как у вас устроена работа: кто оформляет заказ, что происходит со счётом, где данные сейчас лежат. На выходе — техзадание, сценарии пользователей, список экранов и интеграций. Без него разработчики додумывают логику сами, и додумывают по-своему.
• Дизайнер интерфейса. Отвечает не за «красиво», а за то, как человек пройдёт путь: найдёт товар, заполнит форму, увидит ошибку. Хороший дизайнер рисует не только главный экран, но и пустые списки, ошибки, длинные названия, телефонную версию.
• Фронтенд-разработчик. Превращает макеты в работающие страницы: вёрстка, формы, фильтры, анимация, адаптив. Что это такое и где проходит граница с сервером — в статье про фронтенд и бэкенд.
• Бэкенд-разработчик. Делает то, чего пользователь не видит: базу данных, права доступа, расчёты, обмен с CRM, 1С, платёжным сервисом и службой доставки. Ошибки здесь стоят дороже всего: неправильная цена, потерянный заказ, чужие данные в кабинете.
• Тестировщик. Проходит сценарии так, как пройдёт пользователь, и намеренно пытается сломать: пустые поля, двойной клик по «Оплатить», старый браузер, медленный интернет. Отдаёт разработчикам список ошибок и проверяет исправления.
• DevOps-инженер. Настраивает сервер, домен, сертификат, тестовый адрес, выкладку обновлений, резервные копии и оповещения о падении. Заметен, только когда его работы нет: сайт лёг ночью, копии не делались, обновление сломало рабочую версию.

Кроме этих семи иногда встречаются архитектор (принимает ключевые технические решения в крупных системах), контент-менеджер или копирайтер (тексты и наполнение) и SEO-специалист. Для большинства сайтов и сервисов малого бизнеса их задачи берут на себя аналитик, разработчик и менеджер.

Как роли совмещают в небольшом проекте?

Чем меньше проект, тем больше ролей у одного человека. На лендинге менеджер, аналитик и разработчик часто один специалист, а дизайнер отдельно. В веб-приложении с кабинетами и ролями совмещать проверку и разработку уже рискованно.

Совмещение само по себе не плохо. Оно убирает передачу задач между людьми, где теряется смысл, и сокращает срок: тот, кто говорил с вами о задаче, сам её и делает. Проблемы начинаются в двух случаях.

1. Человек проверяет сам себя. Разработчик, который написал форму, проверит её по тому сценарию, который держал в голове. Случай, о котором он не подумал, он не проверит и при тестировании. Поэтому даже в маленьком проекте полезен второй взгляд — менеджера или коллеги — по чек-листу.
2. Всё знание у одного человека. Если требования, доступы к серверу и устройство кода есть только у одного специалиста, его отпуск или болезнь останавливают проект. Спасают записанные требования, доступы на стороне заказчика и код в репозитории.

Обычные пары, которые работают: менеджер и аналитик; дизайнер и фронтенд на простых сайтах; бэкенд и DevOps на проектах с одним сервером. Пара, которая работает хуже: разработчик и единственный тестировщик собственного кода на проекте с оплатой или расчётами.

Проект	Кто обычно отдельно	Что чаще совмещено	На что смотреть
Лендинг (от 24 000 ₽, 2 дня)	Дизайнер	Менеджер, аналитик и разработчик — один человек; бэкенда почти нет	Кто проверяет формы и уведомления о заявках
Корпоративный сайт (от 56 000 ₽, 3–4 дня)	Дизайнер, разработчик	Менеджер с аналитиком; тестирование — разработчик и менеджер	Кто отвечает за тексты, структуру и SEO-базу
Интернет-магазин (от 104 000 ₽, от 5 дней)	Дизайнер, фронтенд, бэкенд	Менеджер с аналитиком; выкладку делает бэкенд	Есть ли отдельная проверка оплаты и обмена с учётом
Веб-приложение, кабинет, CRM (от 160 000 ₽, от 10 дней)	Аналитик, дизайнер, фронтенд, бэкенд, тестировщик	Менеджер с DevOps — редко, чаще DevOps отдельно или у бэкенда	Права ролей, перенос данных, резервные копии

С кем из команды заказчик общается напрямую?

Основной канал — менеджер проекта: сроки, состав, правки, оплата и приёмка идут через него. С аналитиком вы работаете на старте, с дизайнером — на согласовании макетов. С разработчиками напрямую — по конкретному техническому вопросу, если менеджер сам предложил такую встречу.

Логика простая: решения должны оставаться в одном месте. Если вы договорились с программистом в личной переписке «добавить ещё фильтр», менеджер об этом не знает, срок и объём поплыли, а на приёмке выясняется, что фильтр «не входил». Поэтому любую договорённость, сделанную напрямую с кем-то из команды, стоит продублировать туда, где ведётся проект, — в общий чат или на доску задач.

Удобная схема по этапам:

• Оценка и договор — менеджер, при сложной задаче к разговору подключается аналитик или ведущий разработчик.
• Требования — аналитик: интервью, разбор ваших документов и таблиц, согласование техзадания.
• Дизайн — дизайнер показывает прототип и макеты, правки вы передаёте через менеджера, чтобы они попали в счёт раундов.
• Сборка — менеджер показывает промежуточные результаты на тестовом адресе, вопросы по интеграциям уточняет бэкенд.
• Приёмка и запуск — менеджер передаёт результат и доступы, DevOps или бэкенд выкладывает проект на рабочий адрес.

Как это выглядит с документами и сроками на каждом шаге — в статье об этапах разработки.

Как по смете понять, что в команде кого-то не хватает?

Смотрите не на число людей, а на работы. Если в смете есть только «дизайн» и «разработка», спросите, где аналитика, проверка и выкладка. Их отсутствие не делает проект дешевле: эти задачи всё равно придётся сделать — вам или кому-то потом.

Тревожные признаки в коммерческом предложении:

• Нет тестирования ни строкой, ни словом. Значит, проверять будете вы, на приёмке. Для магазина с оплатой и кабинета с ролями это прямой риск.
• Нет этапа требований, а сразу «дизайн». Логика будет додумана в процессе, и часть ваших правок окажется «новой задачей».
• Нет слов о сервере, выкладке и копиях. Непонятно, кто отвечает за запуск и что будет, если сайт упадёт через неделю после сдачи.
• Сроки дизайна и разработки одинаковые для лендинга и сервиса с личным кабинетом. Обычно это шаблон, а не оценка вашей задачи.
• Вместо ролей — «команда опытных специалистов». Это не ответ. Попросите назвать, кто ведёт проект и кто проверяет результат.
• Нет ответственного с вашей стороны в плане. Если подрядчик не спрашивает, кто будет согласовывать, сроки потом сорвутся из-за ожидания ответов.

Обратный перекос тоже бывает: в смете на сайт из пяти страниц расписаны архитектор, отдельный аналитик, тестировщик и DevOps с почасовой ставкой. Для небольшого проекта такой состав избыточен. Спросите, что конкретно каждый из них сделает и что вы получите на выходе.

Какие вопросы задать подрядчику о команде?

Достаточно восьми вопросов до подписания договора. Ответы покажут, закрыты ли все роли, кто ваш контакт и что будет, если кто-то выбыл.

1. Кто ведёт проект и отвечает за срок? Как с ним связаться и как быстро он отвечает?
2. Кто готовит требования и в каком виде я их получу на согласование?
3. Кто делает дизайн, сколько раундов правок предусмотрено и на каких этапах?
4. Кто проверяет готовую работу до того, как её покажут мне, и по какому списку сценариев?
5. Кто настраивает сервер и выкладку, где будет тестовый адрес, делаются ли резервные копии?
6. Где хранится код и будет ли у меня к нему доступ?
7. Что будет со сроком, если ключевой специалист заболеет или уйдёт?
8. Кто отвечает на вопросы после запуска и сколько длится бесплатная поддержка?

Отдельно про проверку: подробно о видах тестирования и о том, что вы можете проверить сами за вечер, — в статье о тестировании сайта.

Когда разбираться в ролях вам не нужно и какие ошибки бывают?

Если вы заказываете лендинг или небольшой сайт с понятным составом, достаточно знать, кто ваш контакт и кто проверяет результат. Распределять роли внутри команды — задача подрядчика, а не ваша. Глубже разбираться стоит в проектах с оплатой, ролями и интеграциями.

Ошибки, которые встречаются у заказчиков чаще всего:

• Требовать отдельного человека под каждую роль. На небольшом проекте это раздувает смету и добавляет передач между людьми, а качество от этого не растёт.
• Обходить менеджера и ставить задачи разработчику напрямую. Договорённость теряется, а спор о том, что входило в работу, потом решать вам.
• Срезать проверку и выкладку ради цены. Экономия на смете превращается в ваши вечера на приёмке и в ночной звонок, когда сайт не открывается.
• Не назначить ответственного у себя. Команда подрядчика простаивает в ожидании ответа, а срок по договору идёт с учётом ваших согласований.
• Оценивать подрядчика по числу людей в презентации. Важнее, кто конкретно работает над вашим проектом и что каждый из них сдаёт.

Как это устроено у нас?

Архитектуру, дизайн и результат держат разработчики и дизайнеры: они проверяют каждый экран и доводят логику. Кто ведёт ваш проект, называем до старта. Ход работ виден в клиентском кабинете: доска проекта, статусы задач и документы. Цена и срок фиксируются в договоре до старта.

Ориентиры по прайсу: лендинг — от 24 000 ₽ за 2 дня, корпоративный сайт — от 56 000 ₽ за 3–4 дня, интернет-магазин — от 104 000 ₽, от 5 дней, веб-приложение — от 160 000 ₽, от 10 дней. Точную сумму и состав работ называем после брифа. Что входит в каждый тариф — на странице цен, как мы ведём заказные проекты — на странице заказной разработки.

По договору: до 2 раундов правок, приёмка — 5 рабочих дней, гарантия на исправление ошибок — 30 календарных дней с даты акта. Бесплатная поддержка после запуска — от 7 дней до месяца в зависимости от тарифа, дальше — подписка от 7 900 ₽ в месяц или разовые задачи. Исходный код передаём в ваш репозиторий или архивом; исключительное право на код остаётся у исполнителя, а вы после полной оплаты получаете лицензию на весь срок действия права: размещать проект на любом сервере и дорабатывать с любым подрядчиком. Логотип, тексты и фирменный стиль, созданные для вас по договору, — ваши. Исполнитель освобождён от НДС по п. 1 ст. 145 НК РФ.

Короткие ответы на частые вопросы

Какие роли есть в команде разработки сайта или сервиса?

Обычно это менеджер проекта, аналитик, дизайнер, фронтенд- и бэкенд-разработчики, тестировщик и инженер, который отвечает за сервер и выкладку. В небольшом проекте часть ролей совмещает один человек, но сами задачи никуда не исчезают.

Зачем нужен менеджер проекта, если можно общаться с программистом?

Менеджер держит срок, состав работ и решения, а программист занят кодом. Прямой разговор с разработчиком полезен по технической детали, но договорённости о сроках и объёме надёжнее фиксировать через одного ответственного.

Нужен ли отдельный тестировщик в небольшом проекте?

Для лендинга или сайта-визитки — обычно нет, проверку делает разработчик и менеджер по чек-листу. Для магазина с оплатой, кабинета с ролями или сервиса с расчётами отдельная проверка оправдана: ошибки находят до приёмки, а не после.

Что значит, если в смете нет строки про тестирование?

Либо проверка включена в работу разработчика, либо её не будет. Спросите прямо: кто проверяет, по какому списку сценариев и на каких устройствах. Если ответа нет, ошибки вы найдёте сами на приёмке.

Может ли один человек быть и аналитиком, и менеджером проекта?

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

Услуги и кейсы по теме: заказная разработка · типовые договоры · цены и сроки