Кто есть кто в IT-разработке: ликбез для бизнеса
Этот текст — для вас. Я объясняю, кто есть кто, простыми словами, с примерами.
0. Уровни: джуниор, миддл, сеньор
Прежде чем разбирать роли, важно понять, что у каждой роли есть уровень квалификации. Это не «звания», а опыт и зона ответственности.
| Уровень | Опыт | Что умеет | Что делает | Примерная зарплата |
|---|---|---|---|---|
| Junior джуниор |
0–2 года | Выполняет конкретные задачи под контролем | Пишет код по готовому ТЗ, исправляет ошибки, учится | 60 000 – 120 000 ₽ |
| Middle миддл |
2–5 лет | Работает самостоятельно, решает типовые задачи | Может спроектировать модуль, выбрать технологию, обучить джуниора | 150 000 – 250 000 ₽ |
| Senior сеньор |
5+ лет | Проектирует системы, принимает архитектурные решения | Проектирует архитектуру, выбирает стек, отвечает за качество, управляет командой | 250 000 – 450 000+ ₽ |
* ориентировочные цифры. В Москве выше, в регионах ниже. Но главное — разница в результатах.
5 джуниоров не заменят одного сеньора
Этот миф дорого обходится бизнесу.
«Зачем платить 300 000 сеньору? Найму 5 джуниоров по 60 000 — и они сделают то же самое, да ещё и быстрее!»
Нет. Не сделают. И вот почему:
| Параметр | 5 джуниоров (по 60 000 ₽) | 1 сеньор (300 000 ₽) |
|---|---|---|
| Общая стоимость | 300 000 ₽/мес | 300 000 ₽/мес |
| Качество кода | Низкое (каждый пишет по-своему, «каша») | Высокое (единый стиль, архитектура) |
| Скорость | Медленно (нужно объяснять, проверять, переделывать) | Быстро (знает, что делать, без подсказок) |
| Координация | Требует постоянного контроля | Работает автономно |
| Ошибки | Много (каждый ошибается по-своему) | Мало (знает типичные проблемы и избегает их) |
| Архитектура | «Код как получится» | Проектирует систему так, чтобы она не развалилась через полгода |
Главное: 5 джуниоров создадут 5 раз больше ошибок, которые потом будет исправлять кто-то другой. Сеньор сделает качественно один раз.
Реальный итог:
| Сценарий | Время | Деньги |
|---|---|---|
| 5 джуниоров | 6 месяцев разработки + 6 месяцев переделок = 12 месяцев | 300 000 × 12 = 3 600 000 ₽ |
| 1 сеньор | 6 месяцев разработки = 6 месяцев | 300 000 × 6 = 1 800 000 ₽ |
Вы сэкономили 1 800 000 ₽ и полгода времени. А ещё — нервы и репутацию.
Сеньор не «дорогой». Он эффективный.
1. Дизайнер
Что делает: рисует интерфейс. Макеты страниц, кнопки, формы, цвета, шрифты, отступы. То, что видит пользователь.
О чём думает: «Как сделать, чтобы пользователю было понятно и приятно пользоваться».
Как отличить хорошего от плохого:
| Плохой дизайнер | Хороший дизайнер |
|---|---|
| Делает «красиво» без логики | Делает удобно, а потом красиво |
| Использует 20 шрифтов на одной странице | Использует 2–3 шрифта, выдержанную цветовую схему |
| Не спрашивает, как пользователь будет взаимодействовать | Продумывает сценарии: что нажимает пользователь, куда переходит |
| Сдаёт макеты без пояснений | Сдаёт макеты с описанием логики и состояний (кнопка активна/не активна, ошибка валидации) |
Пример: дизайнер рисует личный кабинет. Хороший — продумывает, как пользователь меняет аватарку, где видит историю заказов, куда нажимает, чтобы выйти. Плохой — просто рисует «красивую страницу» без логики переходов.
2. Верстальщик
Что делает: берёт макеты дизайнера и превращает их в HTML/CSS. То есть в код, который браузер понимает и показывает как страницу.
О чём думает: «Как сделать, чтобы страница одинаково хорошо выглядела на всех устройствах (компьютере, телефоне, планшете) и быстро загружалась».
Как отличить хорошего от плохого:
| Плохой верстальщик | Хороший верстальщик |
|---|---|
| Вёрстка «ломается» на телефоне | Вёрстка адаптивная — одинаково хорошо на всех экранах |
| Использует картинки вместо текста | Использует текст, который можно скопировать и который видят поисковики |
| Не заботится о скорости загрузки | Оптимизирует картинки, использует современные форматы |
| Код — «каша» (всё в одном файле) | Код чистый, понятный, с комментариями |
Важно: хороший верстальщик и дизайнер — это два разных человека. Дизайнер рисует, верстальщик превращает рисунок в код.
3. Фронтенд-разработчик (JS-разработчик)
Что делает: оживляет вёрстку. Добавляет логику на стороне браузера: что происходит, когда пользователь нажимает кнопку, открывает модальное окно, отправляет форму без перезагрузки страницы.
О чём думает: «Как сделать, чтобы интерфейс был интерактивным, быстрым и без ошибок».
Как отличить хорошего от плохого:
| Плохой фронтенд-разработчик | Хороший фронтенд-разработчик |
|---|---|
| Пишет код, который тормозит | Пишет код, который работает быстро |
| Не обрабатывает ошибки (если что-то упало — всё сломалось) | Обрабатывает ошибки — пользователь видит понятное сообщение |
| Использует устаревшие подходы | Использует современные фреймворки (React, Vue, Svelte) |
| «Привязан» к одному фреймворку | Понимает общие принципы и может работать с разными инструментами |
Пример: пользователь нажал «Отправить заявку». Хороший фронтенд-разработчик показывает индикатор загрузки, а после ответа — сообщение об успехе или ошибке. Плохой — просто отправляет данные, и пользователь висит в неопределённости.
4. Бэкенд-разработчик
Что делает: пишет код, который работает на сервере. Обрабатывает данные, хранит их в базе данных, общается с внешними сервисами (1С, CRM, платёжные системы), возвращает ответы фронтенду.
О чём думает: «Как сделать, чтобы данные хранились надёжно, обрабатывались быстро, а система не падала при нагрузке».
Как отличить хорошего от плохого:
| Плохой бэкенд-разработчик | Хороший бэкенд-разработчик |
|---|---|
| Пишет «работает и ладно» | Пишет так, чтобы работало и при 10 клиентах, и при 10 000 |
| Не думает о безопасности | Защищает данные, использует правильную авторизацию |
| Не документирует API | Описывает API, чтобы фронтенд-разработчик понимал, как с ним работать |
| Не оптимизирует запросы к БД | Оптимизирует, чтобы сайт не тормозил |
Пример: пользователь оформляет заказ. Хороший бэкенд-разработчик проверяет остатки на складе, резервирует товар, создаёт заказ в базе, отправляет данные в 1С, а в случае ошибки — возвращает понятное сообщение. Плохой — просто сохраняет заказ в базу, даже если товара нет на складе.
5. Системный администратор (DevOps)
Что делает: настраивает серверы, следит за их работой, обновляет программное обеспечение, делает резервные копии, защищает систему от атак.
О чём думает: «Как сделать, чтобы система не упала, была надёжной и защищённой».
Как отличить хорошего от плохого:
| Плохой сисадмин | Хороший сисадмин |
|---|---|
| Настроил — и забыл | Настроил и постоянно контролирует: логи, нагрузка, ошибки |
| Не делает бэкапы | Делает регулярные бэкапы и проверяет их восстановление |
| Не обновляет ПО | Обновляет вовремя, чтобы не было уязвимостей |
| Начинает искать проблему, когда сайт уже упал | Видит проблемы заранее и предотвращает падения |
6. Архитектор баз данных
Что делает: проектирует структуру базы данных (БД): какие таблицы нужны, какие поля, как они связаны друг с другом, какие индексы нужны для скорости.
О чём думает: «Как сделать, чтобы данные хранились эффективно, быстро искались и легко изменялись».
Как отличить хорошего от плохого:
| Плохой архитектор БД | Хороший архитектор БД |
|---|---|
| Создаёт таблицы «на ходу», по мере необходимости | Проектирует структуру заранее, до начала разработки |
| Не думает об индексах — база тормозит | Добавляет индексы для быстрых запросов |
| Не документирует схему | Описывает структуру, чтобы разработчики понимали, где что лежит |
| Не продумывает рост данных | Проектирует так, чтобы база работала и при 100 записях, и при 100 000 |
7. Технический писатель
Что делает: пишет документацию. Технические задания, инструкции для пользователей, описания API, схемы работы систем. То, что помогает всем остальным работать.
О чём думает: «Как сделать, чтобы любой человек понял, что здесь написано, и мог использовать».
Как отличить хорошего от плохого:
| Плохой техписатель | Хороший техписатель |
|---|---|
| Пишет сложно, непонятно, «для себя» | Пишет так, что понятно любому: разработчику, менеджеру, пользователю |
| Не использует схемы и диаграммы | Добавляет схемы, которые объясняют в 10 раз быстрее, чем текст |
| Не обновляет документацию | Обновляет, когда система меняется |
| Документация — «просто текст» | Документация структурирована: есть оглавление, разделы, примеры |
8. Тестировщик (QA)
Что делает: проверяет, что система работает так, как задумано. Ищет ошибки до того, как их найдут пользователи.
О чём думает: «Как сделать, чтобы в продакшене не было ошибок».
Как отличить хорошего от плохого:
| Плохой тестировщик | Хороший тестировщик |
|---|---|
| Проверяет «как придётся» — вручную и без системы | Пишет тестовые сценарии, использует автоматизацию |
| Находит одну ошибку — радуется | Проверяет, не появились ли новые ошибки после исправления (регресс) |
| Проверяет только «позитивный сценарий» | Проверяет и негативные: что будет, если ввести неверные данные, или отправить пустую форму |
| Находит ошибки — но не умеет их описать | Описывает ошибки так, что разработчик понимает, в чём проблема, и может её воспроизвести |
📌 Итог: кто нужен для чего
| Задача | Кто нужен |
|---|---|
| Нарисовать интерфейс | Дизайнер |
| Превратить макет в страницу | Верстальщик |
| Оживить страницу (кнопки, формы, анимация) | Фронтенд-разработчик |
| Хранить и обрабатывать данные | Бэкенд-разработчик |
| Настроить серверы и следить за их работой | Системный администратор |
| Проектировать структуру данных | Архитектор БД |
| Написать документацию (ТЗ, описание, инструкции) | Технический писатель |
| Проверить, что всё работает без ошибок | Тестировщик (QA) |
Если вы поняли, кто есть кто, и осознали, что 5 джуниоров не заменят одного сеньора — вы уже на шаг ближе к правильному решению.
Если вы не знаете, какие специалисты нужны для вашего проекта — напишите мне. Я помогу определить роли, объём работ и бюджет.