Чем занят айтишник на работе в 2025: задачи и день из жизни

сен, 15 2025

У айтишников не весь день - код. Много общения, проверок и рутины, зато всё движется к одной цели: продукт должен работать, обновляться и не ломаться. Я живу в Новосибирске, у нас часовой пояс МСК+4, поэтому утренние созвоны уже в разгаре, а кот Рыжик традиционно пытается лечь на клавиатуру - проверенная стресс-терапия. В этой статье - честный разбор без романтизации: ответ на вопрос что делает айтишник в 2025 году, какие роли есть и как выглядит рабочий день.

• TL;DR: айтишник решает задачи по тикетам, пишет/проверяет код или настраивает инфраструктуру, общается в команде, тестирует, документирует и учится.
• Время делится между фокус-работой (50-70%), встречами (10-25%), ревью/тестами (10-20%), документацией и обучением (5-10%). По ролям доли отличаются.
• Инструменты: трекер задач (Jira/Tracker), Git, CI/CD, IDE, тестовые среды, мессенджеры, Miro/Figma, базы данных, облака и контейнеры.
• Безопасность, бэкапы и «не деплоим в пятницу вечером» - не мифы, а правила выживания.
• AI в работе - помощник, а не волшебная палочка: ускоряет рутину, но ответственность на человеке.

Чем занят айтишник весь день: роли, задачи, инструменты

Слово «айтишник» - широкий зонтик. Внутри - десяток разных профессий. Коротко по самым частым.

• Разработчик (Backend/Frontend/Mobile). Пишет фичи и фиксы, ревьюит код, пишет тесты, правит баги, участвует в планировании и разборе требований. Инструменты: Git, IDE (IntelliJ, VS Code), CI/CD (GitLab CI, TeamCity), Postman, Docker, Kubernetes, мониторинг (Grafana), трекер (Jira, YouTrack, Яндекс Трекер), мессенджер (Slack/Telegram).
• Тестировщик (QA/QA Automation). Составляет тест-кейсы, гоняет регресс, автоматизирует тесты, помогает воспроизводить баги, проверяет качество до релиза. Инструменты: TestRail, Playwright/Selenium, Charles/Fiddler, Postman, отчеты CI, баг-трекер.
• DevOps/SRE. Строит и поддерживает инфраструктуру, пайплайны, мониторинг и алерты, отвечает за отказоустойчивость и релизы. Инструменты: Docker, Kubernetes, Terraform/Ansible, Prometheus/Grafana, Nginx, GitLab CI, ArgoCD.
• Аналитик (системный/продуктовый/данных). Переводит «хотелки» в требования, рисует схемы, считает метрики, проверяет гипотезы. Инструменты: SQL, Python/Excel, Amplitude/Metabase, BPMN/диаграммы, Confluence.
• Дизайнер (UI/UX). Прорабатывает пользовательские сценарии, делает макеты и прототипы, ведет дизайн-систему. Инструменты: Figma, FigJam, Miro, Zeplin.
• Продуктовый менеджер. Формулирует цели, приоритизирует бэклог, собирает обратную связь, отвечает за результат. Инструменты: Jira/Tracker, Miro, Confluence, аналитика.
• Сисадмин/инженер поддержки. Настраивает сети, сервера, доступы, помогает сотрудникам, следит за безопасностью рабочих мест.
• Безопасник (AppSec/SOC). Находит уязвимости, проверяет код и зависимости, управляет инцидентами.
• Техрайтер. Пишет понятные инструкции для людей и документацию для разработчиков.

На практике люди пересекаются: разработчик пишет автотесты, DevOps автоматизирует процессы тестирования, аналитик с продуктом считают метрики и вместе меняют приоритеты. По данным JetBrains «The State of Developer Ecosystem 2024», в России разработчики чаще выбирают Java, Kotlin, Python, JavaScript и Go; это хорошо бьется с тем, что мы видим в вакансиях в 2025 году.

Как это выглядит в задачах? Один день - это несколько тикетов. Вот четыре жизненных примера.

• Разработчик Backend: «Добавить поддержку платежей “Мир” в API». Что делает: читает требование, проектирует изменения в БД и сервисах, пишет код и миграции, покрывает тестами, прогоняет локально, кидает MR на ревью, прикручивает фича-флаг, выкатывает через пайплайн.
• QA: «Регресс оплаты картами в iOS-приложении». Что делает: собирает билд, прогоняет чек-лист на реальных устройствах и симуляторах, гоняет автотесты в CI, логирует баги с шагами воспроизведения и скринкастом, повторно проверяет фиксы.
• DevOps: «Вынести Redis в управляемый кластер». Что делает: настраивает Terraform, пишет Helm-chart, конфигурирует мониторинг и алерты, проводит миграцию без простоя, документирует план отката.
• Аналитик: «Падают конверсии в корзину после последнего релиза». Что делает: строит дашборд в Metabase, сверяет версии релизов, смотрит логи, делает срезы по платформам/странам/каналам, формулирует гипотезу и отдает на проверку QA/разработчикам.

Сколько времени на что уходит? Ниже - ориентиры. Они не про идеал, а про среднюю температуру по «офису».

По данным Stack Overflow Developer Survey 2024, у разработчиков заметная часть времени уходит на коммуникации, ревью и поддержку, не только на «писать код». Похожую картинку показывают отчеты GitLab DevSecOps 2024: команды с налаженным CI/CD тратят меньше времени на ручные операции и катят чаще. DORA-метрики тоже подтверждают: лучшие команды деплоят на заказ и откатываются за минуты.

AI здесь уже рабочая лошадка: подсказать сниппет кода, написать unit-тест, сгенерировать SQL-запрос, набросать черновик документации. Но «подписывать чеком» ИИ нельзя: в прод прилетает только то, что человек проверил. На моей практике ИИ экономит 10-20% времени на рутине. Остальное - понимание контекста, архитектуры, чистоты решений и ответственности.

Как проходит рабочий день: шаги, чек-листы и лайфхаки

День строится вокруг задач. Чтобы не утонуть в «мелочах», помогает понятная последовательность.

1. Проверка контекста: трекер задач, CI, письма, мессенджер. Я в Новосибирске, поэтому часть сообщений из Москвы прилетела ночью - быстро просматриваю, что блокирует команду.
2. План на день: 2-3 ключевые задачи, остальное - буфер. Фокус-блоки по 90-120 минут с тихими уведомлениями.
3. Ежедневный стендап (10-15 минут): что сделала вчера, что сегодня, есть ли блокеры. Только факты - «мысли вслух» в чат/комментарии к задаче.
4. Фокус-работа: код/тесты/макеты/запросы/инфраструктура. Мини-цели: «открыть MR», «покрыть тестами», «выкатить на стейдж».
5. Встречи по делу: груминг (разбираем будущие задачи), планирование (раскладываем по спринту), ретро (что улучшить), демо (показываем результат). Без повестки - переносим.
6. Ревью и тесты: проверяем чужой код/макет, прогоняем автотесты, договариваемся об улучшениях. Не «чини завтра», а конкретно: «переименовать, вынести, покрыть граничные случаи».
7. Релиз: фича-флаги, чек-листы, мониторинг. Если есть сомнения - канареечный релиз и план отката. Пятничные выкаты вечером - табу.
8. Документация: короткие заметки в Confluence/README - потом экономят часы. Идеально - «живущие» runbooks.
9. Учебный слот: 30 минут на статью, доклад, курс или разбор сложного бага. Это инвестиция, а не «лишняя роскошь».

Чек-листы, которые спасают нервы.

• Перед коммитом: тесты проходят локально; линтер/форматер ок; нет секретов в коде; миграции корректные; описание коммита понятное.
• Перед релизом: фича-флаги заведены; есть план отката; мониторинг/алерты включены; QA погонял регресс; есть ответственный «на дежурстве».
• Закрывая баг: приложены шаги, скрин/лог; понятна причина; есть автотест или чек-лист на регресс; при необходимости - обновлена документация.

Полезные формулы и правила.

• 60/30/10 для разработчика: 60% - фокус-код, 30% - ревью/тесты/поддержка, 10% - созвоны. Если созвоны едят больше 25% неделями - перегруз встречами, надо чинить процесс.
• Два крупных блока в день лучше, чем пять обрывков по 30 минут. Переключение контекста съедает до 20-40% продуктивности - это видно по метрикам в IDE и CI.
• Definition of Done (DoD): задача считается сделанной только когда код в мастер-ветке, тесты зеленые, документация обновлена, метрики мониторятся.
• Правило пятницы: если релиз в пятницу после 16:00 - это не смелость, это риск для всех. Перенос спасает выходные и репутацию.

Пример хорошего описания задачи:

• Цель: «Добавить Apple Pay в iOS-клиент для сегмента RU».
• Критерии приема: «Оплата проходит на стейдже; логируется в событийную таблицу; видна в админке; покрытие автотестами - 80%».
• Граница: «Android и Web - вне задачи; UI - из макета v2.1».
• Риски: «Требуется обновление SDK; старые устройства < iOS 14 - не поддерживаем».

И пример «живых» подсказок из практики.

• Пишите коммиты так, чтобы их было не стыдно читать завтра. Хорошо: «feat(pay): add MIR gateway with retry and idempotency»; плохо: «fix2».
• Баг-репорт с видео воспроизведения - экономит полчаса каждому. Слышно, как нажимали кнопки - вопросов меньше.
• Телеграм удобен, но задачи живут в трекере. Иначе контекст теряется. Я оставляю краткий резюме в задаче после каждого важного обсуждения в чате.
• Разные часовые пояса - разные ожидания. В Новосибирске рабочее утро начинается, когда Москве еще кофе кипит. Асинхронность спасает.
• Не бойтесь говорить «не знаю». Быстро найти, проверить и зафиксировать - ценно.
• Рыжик - отличный индикатор усталости: если уже в третий раз лег на клавиатуру, пора встать и пройтись.

Где «узкие места» обычно.

• Встреч слишком много. Лечится повесткой, таймбоксом и «без меня можно?» У нас оставляют запись и краткий конспект - экономит время.
• Требования размыты. Просим примеры, сценарии, критерии приема. Лучше потратить 20 минут до кода, чем 2 дня после.
• Долгий код-ревью. Делаем MR помельче, добавляем контекст в описание, отмечаем «что именно посмотреть».
• Тесты «падающие рандомно». Помечаем flaky, стабилизируем и не тащим дальше. Иначе CI не верят, и всё тормозит.

Вопросы, сценарии и следующие шаги

Частые вопросы - коротко и по делу.

• «Айтишник - это обязательно программист?» Нет. Есть QA, аналитики, дизайнеры, DevOps, продукт, безопасники, техрайтеры.
• «Сколько кода у разработчика в день?» Считайте задачами, не строками. В хороший день - одна-две законченные части работы, MR прошел ревью, тесты зеленые.
• «Нужна ли математика?» Для ML/алгоритмов - да. Для бэкенда/фронта - базовая логика и структурное мышление решают чаще.
• «Без английского можно?» Можно, но границы уже завтра упретесь. Большая часть доков и обсуждений - на английском.
• «Сколько встреч?» 2-5 часов в неделю для разработчика - норма. Если 3 часа в день - сигнал перепланировать.
• «Удаленка или офис?» В 2025 - гибрид. Релизы и дизайн-сессии часто лучше решать очно, остальное - асинхронно.
• «AI заберет работу?» Заберет рутину. Работу - нет. Ценность - в понимании задачи, инженерном вкусе и командной игре.
• «Что по документам?» Достаточно «ровной» Confluence-страницы и аккуратных README. Главный критерий - чтобы другой человек смог повторить.

Если вы выбираете направление - мини-навигатор.

• Любите собирать сложные системы - DevOps/SRE.
• Тянет к визуалу и людям - UX/UI-дизайн, продукт.
• Нравится логика и структуры - бэкенд/аналитика данных.
• Любите искать несоответствия - QA.

Простые следующие шаги - по сценариям.

• Школьник/студент: выберите 1-2 направления, пройдите бесплатный мини-курс, сделайте маленький проект (лендинг, телеграм-бот, дашборд), опубликуйте на GitHub. Попросите ревью у сообщества.
• Смена профессии: возьмите прикладную задачу с работы/быта - автоматизируйте отчет, напишите скрипт, соберите дашборд. Это первый «профессиональный» кейс.
• Родитель: режим «тихих часов» творит чудеса. Дети спят - вы учитесь. План - по 30-45 минут, но каждый день.
• HR/руководитель: не просите «сделать быстро» без контекста. Дайте цель, критерии, ограничения и сроки - получите прогнозируемый результат.

Что делать, если «не едет».

• Застряли: проговорите проблему уточняющими вопросами в задаче, приложите логи/скриншоты, предложите 2-3 варианта. Часто ответ придет, пока пишете.
• Слишком много задач: WIP-лимит в 1-2 активные. Остальное - в очередь. Закрытые задачи - лучшая мотивация.
• Выгорание: отключите уведомления на вечер, договоритесь о «окнах тишины», смените тип задач на неделю. Если надо - берите выходной. Без ресурса долго не протянет никто.

И немного локального контекста 2025.

• Часть команд в России перешла на отечественные аналоги: Яндекс Трекер вместо Jira, VK Teams вместо Slack, ЯндексGPT или GigaChat вместо зарубежных LLM. Функционально - хватает.
• Инфраструктура чаще в гибриде: что-то в облаках, что-то на своих серверах. Требования к безопасности выросли, аудит логов - рутина, но нужная.
• Команды распределены по поясам. Новосибирск - удобный «мост»: можно накрыть утро Владивостока и вечер Москвы.

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