Содержание11
- Кто такой веб-разработчик: простое определение без абстракций
- Три типа веб-разработчиков: кто за что отвечает
- Кого нанимать под конкретный проект: от лендинга до веб-приложения
- Штат, фриланс или студия: формы сотрудничества
- Как проверить компетенции: чек-лист для собеседования
- Красные флаги: типичные ошибки при найме
- Интеграции и бизнес-процессы: что разработчик должен понимать
- Договор и права на код: на что обратить внимание
- Вывод: как не ошибиться с выбором
- Частые вопросы
- Источники
Веб-разработчик — это специалист, который создаёт и поддерживает сайты и веб-приложения. Под одним названием скрываются три разные профессии: кто-то отвечает за внешний вид и кнопки, кто-то — за сервер и базу данных, а кто-то берёт всё сразу. Заказчик, который не отличает frontend от backend, нанимает не тех людей, срывает сроки и переплачивает.
Кто такой веб-разработчик: простое определение без абстракций
Веб-разработчик пишет код, который работает в браузере и на сервере. Он не рисует картинки и не продвигает сайт в поиске — он делает так, чтобы кнопка нажималась, форма отправлялась, а личный кабинет показывал правильные данные.
По Общероссийскому классификатору занятий профессия числится под кодом 3514 — «Специалисты-техники по Web». Это формальное подтверждение, что работа с веб-технологиями — отдельная специализация, а не побочное умение «компьютерщика».
Заказчики часто путают веб-разработчика с тремя соседними профессиями:
- Веб-дизайнер решает, как выглядит сайт: подбирает цвета, шрифты, компоновку блоков. Он отвечает на вопрос «что видит пользователь», но не на вопрос «как это работает».
- Верстальщик собирает макет дизайнера в статичную страницу: расставляет блоки, настраивает адаптив под мобильные. Без разработчика страница не будет взаимодействовать с сервером.
- Контент-менеджер наполняет сайт текстами и картинками, не затрагивая код.
Граница простая: дизайнер показывает, верстальщик собирает, разработчик оживляет. Из каких этапов складывается сам проект, разобрали в статье «Что такое веб-разработка и из чего она состоит».
Три типа веб-разработчиков: кто за что отвечает
Веб-разработчик разделяется на frontend, backend и fullstack. Frontend-разработчик взаимодействует с backend-разработчиком через API — набор правил, по которым браузер и сервер обмениваются данными.
Представьте ресторан. Frontend — это фасад, зал, меню и официант: всё, что видит посетитель. Backend — кухня, склад, холодильники и бухгалтерия: то, что скрыто, но без чего зал не работает. Fullstack — шеф, который может и на кухне, и в зале, но в каждой роли уступает узкому специалисту.
| Тип разработчика | Зона ответственности | Ключевые технологии | Типичный результат |
|---|---|---|---|
| Frontend | Браузер, интерфейс, анимации, адаптив | HTML, CSS, JavaScript, React/Vue | Страница, которая работает на телефоне и компьютере |
| Backend | Сервер, база данных, API, безопасность | PHP, Python, Node.js, PostgreSQL/MySQL | Обработка заказов, авторизация, интеграции |
| Fullstack | Обе стороны | Комбинация выше | Прототип или небольшой проект целиком |
Fullstack-разработчик совмещает функции frontend и backend. Это удобно для старта, но на сложных проектах глубина знаний в каждой области падает — как у шефа, который готовит и принимает заказы одновременно.
Кого нанимать под конкретный проект: от лендинга до веб-приложения
Выбор команды зависит от типа проекта, а не от бюджета. Лендинг может обойтись без backend-разработчика, а интернет-магазин требует его обязательно.
| Тип проекта | Минимальная команда | Когда fullstack подходит | Когда нет |
|---|---|---|---|
| Лендинг | Один frontend или fullstack | Всегда, если нет сложных форм | Нужна интеграция с CRM или оплатой |
| Корпоративный сайт | Frontend + backend или fullstack + CMS-специалист | Сайт на готовой CMS без кастома | Кастомные разделы, личный кабинет |
| Интернет-магазин | Frontend + backend, желательно DevOps | Небольшой каталог на готовом шаблоне | Сложные фильтры, 1С-интеграция, высокая нагрузка |
| Веб-приложение / SaaS | Команда из frontend, backend, тестировщика и менеджера | Только на этапе MVP | После запуска — отдельные специалисты |
Кроме разработчиков, в проекте обычно участвуют ещё три роли:
- Дизайнер готовит макеты и прототипы до того, как начнётся код.
- Тестировщик проверяет формы, оплату, адаптив и сценарии пользователя до запуска, а не после жалоб клиентов.
- Менеджер проекта держит сроки, собирает правки и переводит задачи бизнеса на язык разработки.
Сроки зависят от функционала и становятся понятны после проработки технического задания: лендинг обычно делается быстрее корпоративного сайта, интернет-магазин — дольше сайта-визитки, а кастомное веб-приложение занимает больше всего времени.
Конструкторы вроде Tilda заменяют разработчика, если проект стандартный и не требует уникальной логики. Как только появляется интеграция с 1С или кастомная CRM — нужен код.
Штат, фриланс или студия: формы сотрудничества
Бюджет складывается из специализации, уровня исполнителя и формы сотрудничества. У каждой формы свои риски — сравните их до того, как сравнивать ставки.
| Форма сотрудничества | Плюсы | Минусы | Когда выгодна |
|---|---|---|---|
| Штат | Полный контроль, быстрая коммуникация | Высокая фиксированная нагрузка, налоги, отпуска | Постоянная разработка, продуктовая компания |
| Фриланс | Гибкость, ниже ставка | Риск срыва сроков, пропажи исполнителя, нет гарантий | Разовые задачи, бюджетный старт |
| Аутсорс веб-студии | Фикс за проект или этап, гарантийные обязательства в договоре, команда под проект | Меньше гибкости, наценка студии | Сложный проект под ключ |
Платить за час выгодно, когда задачи непредсказуемы и меняются в процессе. Фикс за проект — когда техническое задание проработано и не будет меняться. Смешанная модель: фикс на этап и почасовая оплата доработок. Если нужен проект под ключ одной командой, посмотрите, как устроена разработка сайтов в ЦЕМЕС.
Как проверить компетенции: чек-лист для собеседования
Технические навыки проверяют через разговор о реальных задачах, а не абстрактные вопросы про синтаксис. Вот что стоит спросить:
Тестовое задание — реальный баг или мини-фича из вашего проекта, а не задача «отсортировать массив». Срок — несколько часов, не неделя. Проверяйте не только результат, но и как разработчик объясняет ход мыслей: это предиктор комфортной работы.
Core Web Vitals — метрики скорости и стабильности страницы — frontend-разработчик должен знать и уметь улучшать. Спросите про LCP (скорость загрузки главного контента), INP (скорость реакции на действия пользователя) и CLS (визуальную стабильность). Если кандидат называет FID — его знания устарели: INP стал стабильной метрикой Core Web Vitals и заменил FID.
Красные флаги: типичные ошибки при найме
Самый дорогой разработчик — тот, кто делает быстро и неправильно, а потом переделывает за ваш счёт.
Проверяемые признаки проблемного исполнителя:
- 01 «Сделаю всё сам»
На проекте, который требует команды. Один человек не одновременно оптимизирует базу данных и настраивает пиксельную вёрстку — кто-то из задач пострадает.
- 02 Портфолио без живых ссылок
Только скриншоты. Скриншот не доказывает, что сайт работает, быстро грузится и не падает под нагрузкой.
- 03 Не объясняет выбор технологии
«Потому что так умею» — плохой ответ. Хороший: «React выбрал, потому что у проекта сложное состояние интерфейса, а у команды уже был опыт с этой экосистемой».
- 04 Обещает сроки без уточнения ТЗ
Дата до обсуждения деталей — случайное число.
- 05 Игнорирует вопросы про интеграции
Если разработчик отмахивается от CRM, аналитики или SEO — он пишет код в вакууме, а не для бизнеса.
Интеграции и бизнес-процессы: что разработчик должен понимать
Разработчик, который не понимает бизнес-контекст, пишет код, который не зарабатывает деньги. Проверяйте пять областей:
- CRM-интеграция. Умеет ли связать сайт с Битрикс24, amoCRM, МойСклад. Заявка из формы должна падать в CRM автоматически, а не дублироваться вручную.
- SEO-готовность. Понимает ли чистые URL, семантическую вёрстку (заголовки h1–h6 без пропусков), скорость загрузки. Разработчик, который «не занимается SEO», оставляет технический долг, который придётся закрывать перед продвижением.
- Аналитика. Настраивает ли цели в Яндекс Метрике: нажатие кнопки, отправку формы, добавление в корзину. Без этого вы не узнаете, откуда приходят клиенты.
- Платежи. Опыт с ЮKassa и интернет-эквайрингом банков. Важно не «подключил раз», а «знает, как обрабатывать ошибки и возвраты».
- Core Web Vitals. Знает ли метрики LCP, INP, CLS и как их улучшать. Google прямо пишет, что эти и другие показатели удобства отражают, какие страницы поощряют его основные системы ранжирования.
Договор и права на код: на что обратить внимание
Юридическая защита — часть проекта, не формальность. Договор определяет, что именно должен сдать разработчик, кому принадлежит код и что будет с ошибками после запуска.
Ключевые пункты:
- Форма договора. С веб-студией или фрилансером обычно заключают договор подряда: по статье 702 ГК РФ подрядчик обязуется выполнить работу по заданию заказчика и сдать результат, а заказчик — принять и оплатить его. Поэтому результат нужно описать конкретно: страницы, функции, интеграции, критерии приёмки.
- Права на код. По пункту 1 статьи 1296 ГК РФ исключительное право на программу, созданную по заказу, принадлежит заказчику, если договором не предусмотрено иное. Проверьте, что в договоре нет этого «иного» — оговорки, которая оставляет права исполнителю. И учтите пункт 2 той же статьи: если договор не запрещает, исполнитель вправе использовать созданную программу для собственных нужд на условиях безвозмездной простой лицензии.
- NDA. Нужен, если в проекте — коммерческая тайна, уникальные алгоритмы, данные клиентов. Для типового сайта обычно избыточен.
- Исходный код. В каком виде и когда передаётся: доступ к репозиторию, архив, документация, доступы к хостингу и домену. Без исходников вы привязаны к разработчику.
- Гарантия. Если договор устанавливает гарантийный срок, по статье 722 ГК РФ результат работы должен весь этот срок соответствовать условиям договора о качестве. Срок и объём бесплатных исправлений пропишите явно — сам закон конкретный срок для сайта не называет.
Подробнее о том, что закладывать в техническое задание, договор и гарантии, — в статье «ТЗ, договор и гарантии».
Вывод: как не ошибиться с выбором
Сначала определите тип проекта, потом — состав команды. Лендинг и простой корпоративный сайт сделает один разработчик. Интернет-магазин, веб-приложение или SaaS требуют команды из узких специалистов.
Fullstack хорош для старта и проверки гипотез. Когда проект растёт — ищите отдельного frontend и backend. Проверяйте не только код, но и понимание бизнес-задач: умеет ли разработчик объяснить, как его работа повлияет на заявки или продажи.
Если проект сложнее лендинга — обсудите его с веб-студией до найма исполнителей. Правильная архитектура на старте избавит от дорогих переделок потом.
Источники
- 3514 Специалисты-техники по Web — КонсультантПлюс, Общероссийский классификатор занятий
- Статья 702 ГК РФ. Договор подряда — КонсультантПлюс, Гражданский кодекс РФ, часть вторая
- Статья 722 ГК РФ. Гарантия качества работы — КонсультантПлюс, Гражданский кодекс РФ, часть вторая
- Статья 1296 ГК РФ. Произведения, созданные по заказу — КонсультантПлюс, Гражданский кодекс РФ, часть четвёртая
- Core Web Vitals и результаты поиска Google — Google Search Central
- INP заменяет FID в Core Web Vitals — web.dev
