Как устроена IT-индустрия: роли, команды, как выглядит рабочий день

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

Кто решает, что делать? Почему разработчик не пишет код восемь часов подряд? Кто такой «продакт» и почему он всё время что-то спрашивает? Что происходит с вашим кодом после того, как вы его написали?

Эта статья — карта индустрии изнутри. Без романтики про «гениев в толстовках» и без страшилок. Просто как оно есть.

Зачем вообще нужны все эти люди

Начнём с честного вопроса. Если программист умеет писать программы — зачем вокруг него столько народу?

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

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

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

Где работают программисты: типы компаний

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

Для первой работы нет однозначно «правильного» варианта, но есть закономерность: в аутсорсе и агентствах чаще берут новичков (там нужны руки и есть поток типовых задач), а в сильных продуктовых компаниях выше планка входа. Внутренний IT крупного банка или ритейлера — часто недооценённый вход в профессию: там много рутинных задач, спокойный темп и реальный шанс для джуна.

Аналогия. Продуктовая компания — как собственный ресторан: вы годами доводите одно меню, знаете каждого постоянного гостя. Аутсорс — как кейтеринг: сегодня свадьба, завтра корпоратив, каждый раз новое место и новые пожелания.

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

Кто есть кто: роли по-человечески

Ниже — не должностные инструкции, а то, что человек реально делает и что у него болит.

Разработчик (developer, engineer, программист)

Пишет и меняет код. Внутри делится по тому, с какой частью системы работает:

• Frontend — то, что человек видит и трогает: кнопки, формы, экраны. Языки: JavaScript/TypeScript (трек по TypeScript).
• Backend — то, что происходит на сервере: логика, расчёты, работа с базой данных. Python, Java, Go (трек по Go), C#, PHP.
• Mobile — приложения для телефонов: Swift для iOS, Kotlin для Android.
• Fullstack — и то, и другое. Часто в маленьких командах.
• Data / ML — работа с данными и моделями машинного обучения.
• Embedded — код для устройств: кофемашин, автомобилей, датчиков.

Что болит: непонятные требования, старый чужой код, задачи «надо было вчера».

Тестировщик (QA — quality assurance)

Проверяет, что программа работает — и, что важнее, ищет случаи, где она не работает. Хороший тестировщик — не «человек, который кликает кнопки», а человек с особым складом ума: он придумывает то, о чём разработчик не подумал. «А если имя из 500 символов? А если нажать Отправить дважды? А если интернет пропал посередине?»

Бывает ручной (проверяет руками) и автоматизатор (пишет программы, которые проверяют программу). Автоматизатор — это тоже программист.

DevOps / SRE

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

Аналитик

Тут путаница, потому что аналитики разные:

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

Продакт-менеджер и проджект-менеджер

Их постоянно путают, а разница простая:

• Продакт (product manager) отвечает за вопрос что делать и зачем. Он решает, что важнее: новая кнопка или ускорение поиска.
• Проджект (project manager) отвечает за вопрос как довести до конца в срок. Он следит за планом, сроками, зависимостями, договорённостями.

В маленьких компаниях это один человек. В больших — два, и они спорят между собой.

Дизайнер

UX-дизайнер думает про то, как человек пользуется продуктом (куда нажмёт, что поймёт, где растеряется). UI-дизайнер рисует, как это выглядит. Часто один человек делает и то, и другое.

Тимлид, техлид, архитектор

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

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

Как задача проходит путь до пользователя

Вот главное, что стоит понять новичку: написание кода — это одна стадия из семи, и не самая длинная.

Продакшн (production, «прод») — это боевая версия системы, та самая, которой пользуются живые люди. Противоположность — тестовый стенд, копия системы, где можно ломать что угодно. Фраза «уронил прод» означает, что из-за чьих-то изменений сервис перестал работать у пользователей. Это случается со всеми, включая очень опытных; в нормальных командах за это не увольняют, а разбирают причину.

У самой задачи тоже есть жизненный цикл — вы будете видеть эти статусы в трекере каждый день:

Стрелки «назад» — не признак плохой работы. Возврат из ревью и из тестирования — это норма, так и должно быть. Дешевле поймать ошибку здесь, чем у пользователя.

Как выглядит рабочий день

Самое частое разочарование новичков: вы не будете писать код восемь часов подряд. И это не потому, что вы недостаточно стараетесь.

Считаем: на собственно код ушло около 3,5 часов из 7 рабочих. Это хороший день. Давайте посчитаем долю честно — заодно вспомним словари из статьи Списки, словари и множества.

# Ключ — чем занимались, значение — сколько минут это заняло
day = {
    "написание кода": 180,
    "код-ревью коллег": 45,
    "встречи": 90,
    "переписка, вопросы": 60,
    "разбор поломки": 30,
}

# sum() складывает все значения словаря; day.values() — это все числа без ключей
total = sum(day.values())
print(f"Всего: {total} мин = {total / 60:.1f} ч")

# .items() отдаёт пары «ключ, значение» — их удобно распаковать в две переменные
for activity, minutes in day.items():
    share = minutes / total * 100          # доля в процентах
    bar = "*" * round(share / 4)           # столбик: одна звёздочка примерно на 4%
    # :20 — выровнять текст по ширине 20 символов, :5.1f — число с одним знаком после точки
    print(f"{activity:20} {minutes:4} мин {share:5.1f}% {bar}")

Вывод:

Всего: 405 мин = 6.8 ч
написание кода        180 мин  44.4% ***********
код-ревью коллег       45 мин  11.1% ***
встречи                90 мин  22.2% ******
переписка, вопросы     60 мин  14.8% ****
разбор поломки         30 мин   7.4% **

Меньше половины дня на код. Остальное — не «потери», а тоже работа: без ревью в код попадут ошибки, без обсуждений вы сделаете не то, без разбора поломки сервис останется сломанным.

Что такое дейли-стендап

Короткая (10–15 минут) ежедневная встреча команды. Каждый отвечает на три вопроса: что делал вчера, что буду делать сегодня, что мешает. Стоя — чтобы не рассиживались, отсюда и название («stand up» — «встать»).

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

Другие встречи, которые вы увидите

• Планирование (planning) — раз в одну-две недели решают, какие задачи берём в работу.
• Груминг / рефайнмент (backlog refinement) — разбор будущих задач: уточняем описания, прикидываем сложность.
• Ретроспектива (retro) — раз в две недели команда обсуждает, что в процессе работало хорошо, что плохо, и что поменяем.
• Один на один (1:1) — личная беседа с тимлидом раз в одну-две недели: как ваши дела, что мешает, куда растёте.

Всё это — часть подходов, которые называют Agile. Самые распространённые:

• Scrum — работа отрезками по 1–2 недели («спринтами»), с планированием в начале и ретро в конце.
• Kanban — без фиксированных отрезков: есть доска со статусами и правило «не брать слишком много задач одновременно».

Честно о недостатках. Эти ритуалы легко превращаются в театр: стендап на сорок минут с отчётом каждого перед менеджером, ретро, после которого ничего не меняется, оценки задач, которые никто не соблюдает. Если вы попадёте в такую команду — знайте, что дело не в вас и не в том, что вы «не понимаете Agile». Первоисточник (Agile-манифест, Scrum Guide) читается за 15 минут и во многом об обратном — о доверии и меньшем количестве формальностей.

Код-ревью: почему ваш код будут критиковать

Код-ревью (code review) — практика, при которой ваши изменения перед попаданием в общий проект читает другой разработчик и оставляет комментарии. Технически это происходит через пул-реквест (pull request, PR) — мы касались этого в статье Командная строка и Git.

Первое ревью почти всегда болезненно: вы старались, а вам написали двадцать замечаний. Поэтому сразу три вещи, которые стоит знать.

Первое: замечания получают все. У сеньоров тоже. Количество комментариев говорит о сложности изменений, а не о вашей глупости.

Второе: комментарии бывают разного веса. Учитесь различать:

Третье: спрашивать — нормально. Ответ «не понял, почему так лучше, объясни?» — признак профессионала, а не слабости. Плохо — молча делать как сказали, не понимая зачем.

Отличный (и бесплатный) свод правил ревью — Google Engineering Practices, там есть отдельные тексты и для автора кода, и для рецензента.

Грейды: junior, middle, senior

Это самая мифологизированная тема, поэтому разберём прямо.

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

• Junior получает разложенную задачу с понятным результатом. Ему помогают, его код внимательно ревьюят. Нормальное ожидание от джуна — не «безошибочность», а обучаемость и умение вовремя попросить помощи.
• Middle получает задачу целиком («сделай экспорт отчётов») и сам решает, как её разложить. Работает без постоянного присмотра.
• Senior получает проблему («у нас медленно грузятся отчёты и жалуются клиенты») — и сам выясняет причину, предлагает варианты, оценивает риски. Плюс помогает расти другим.
• Lead / Staff отвечает уже не за свой код, а за то, чтобы вся команда выдавала результат.

Честные оговорки. Единого стандарта нет: сеньор в маленьком агентстве и сеньор в большой продуктовой компании — разные люди по требованиям. Названия должностей в разных компаниях не сравнимы напрямую. Про инженерные карьерные лестницы за пределами менеджмента хорошо написано на StaffEng и в блоге The Pragmatic Engineer.

Читаем индустрию по вакансиям

Разговоры разговорами, но есть способ узнать про рынок факты, а не мнения: посмотреть, что реально пишут в вакансиях. Заодно это отличная задача для вашего Python.

# Обычно такие тексты читают из файла, но для примера положим прямо в код
vacancies = [
    "Junior Python developer: Python, SQL, Git",
    "Backend-разработчик: Python, Django, PostgreSQL, Docker, Git",
    "Стажёр в отдел разработки: Python, Git, английский",
    "Data-инженер: Python, SQL, Airflow, Docker",
]

counter = {}  # здесь будем копить: технология -> сколько раз встретилась

for text in vacancies:
    # split(":") режет строку по двоеточию на две части:
    # слева название вакансии, справа перечень технологий
    title, tools_text = text.split(":")

    for tool in tools_text.split(","):   # режем перечень по запятым
        tool = tool.strip().lower()      # strip() убирает пробелы по краям, lower() — приводит к строчным
        # .get(tool, 0) вернёт текущее число, а если ключа ещё нет — вернёт 0
        counter[tool] = counter.get(tool, 0) + 1

# sorted сортирует пары «ключ, значение».
# key=lambda pair: pair[1] означает «сортируй по второму элементу пары», то есть по числу.
# reverse=True — по убыванию.
pairs = sorted(counter.items(), key=lambda pair: pair[1], reverse=True)

for tool, count in pairs:
    print(f"{tool:12} {'#' * count} {count}")

Вывод:

python       #### 4
git          ### 3
sql          ## 2
docker       ## 2
django       # 1
postgresql   # 1
английский   # 1
airflow      # 1

Даже на четырёх выдуманных вакансиях видно закономерность, которая держится и на четырёхстах настоящих: Git и SQL требуют почти везде, независимо от языка. Это не случайность — Git это то, как индустрия хранит код, а SQL то, как она хранит данные.

Ещё один крошечный пример — так команды смотрят на свою «скорость» (velocity):

closed = [7, 5, 9, 6, 8]  # закрытых задач по неделям

print(f"В среднем за неделю: {sum(closed) / len(closed):.1f} задач")
print(f"Худшая неделя: {min(closed)}, лучшая: {max(closed)}")

В среднем за неделю: 7.0 задач
Худшая неделя: 5, лучшая: 9

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

Типичные ошибки в этом коде и что означают сообщения

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

1. Лишнее двоеточие в строке.

"Работа: Python: SQL".split(":")   # получится ТРИ куска, а не два

ValueError: too many values to unpack (expected 2)

Дословно: «слишком много значений для распаковки (ожидалось 2)». Распаковка — это когда слева от = стоит несколько переменных: title, tools_text = .... Python получил три куска, а мест для них два. Лечится ограничением: text.split(":", 1) — «режь только по первому двоеточию».

2. Забыли внутренний цикл.

tools = tools_text.split(",")
tools.strip()

AttributeError: 'list' object has no attribute 'strip'

Дословно: «у объекта типа список нет свойства strip». split() возвращает список строк, а strip() есть у строки, а не у списка. Нужно пройтись циклом по элементам.

3. Обратились к несуществующему ключу.

counter[tool] = counter[tool] + 1   # если tool ещё не встречался

KeyError: 'python'

Дословно: «ошибка ключа: python». В словаре нет такого ключа, а вы просите его значение. Поэтому в примере используется counter.get(tool, 0) — «дай значение, а если ключа нет, дай ноль».

4. Пустой словарь при подсчёте долей.

ZeroDivisionError: division by zero

Дословно: «деление на ноль». Если day пуст, total равен нулю. Реальные данные бывают пустыми чаще, чем кажется, — проверяйте: if total == 0: ....

Чего в этой профессии не ждать

Несколько честных вещей, которые лучше узнать заранее, чем на третьем месяце работы.

Вы будете читать чужой код больше, чем писать свой. Часто старый, странный, без комментариев. Это называется легаси (legacy) — унаследованный код, который работает и который страшно трогать. Умение разбираться в чужом коде — отдельный и очень ценный навык.

Синдром самозванца никуда не денется. Ощущение «все вокруг умнее, скоро поймут, что я не тяну» испытывают люди с двадцатью годами опыта. Помогает простое: вести журнал того, что вы уже научились делать, — память об этом на удивление короткая.

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

Выгорание — реальный производственный риск. Работа умственная, границы размытые, «ещё полчасика» легко превращается в полночь. Способность останавливаться — профессиональный навык, а не лень.

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

Практические задания

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

1. Свой день в цифрах. Возьмите пример со словарём day и запишите туда свой вчерашний день (учёба, дорога, соцсети, сон). Посчитайте, сколько процентов ушло на осознанное обучение. Подсказка: меняется только содержимое словаря, код считать ничего не надо.

2. Реальные вакансии. Откройте любой сайт с вакансиями, найдите 5 вакансий уровня junior по интересной вам специальности и добавьте их в список vacancies в формате "название: технология, технология, ...". Посмотрите, что окажется в топе. Подсказка: следите за форматом — ровно одно двоеточие в строке, иначе получите ValueError из разбора выше. Либо сразу используйте text.split(":", 1).

3. Синонимы. В настоящих вакансиях одно и то же пишут по-разному: postgres и postgresql, js и javascript. Приведите их к одному виду перед подсчётом. Подсказка: заведите словарь замен synonyms = {"postgres": "postgresql", "js": "javascript"} и перед строкой с counter[...] напишите tool = synonyms.get(tool, tool) — «замени, если знаем замену, иначе оставь как есть».

4. Читаем из файла. Перенесите вакансии в файл vacancies.txt (по одной на строку) и прочитайте их оттуда, как в статье Файлы и форматы данных. Подсказка: with open("vacancies.txt", encoding="utf-8") as f: и цикл по строкам файла. Не забудьте strip() — в конце каждой строки прячется невидимый \n. Если увидите FileNotFoundError, значит программа ищет файл не там, где вы его положили.

5. Карта пробелов. Соберите список технологий, которые вы уже трогали (known = ["python", "git"]), и выведите: какие требования из вакансий вы закрываете, а какие нет — отсортировав недостающие по частоте упоминаний. Получится ваш личный план обучения, основанный на данных, а не на чужих советах. Подсказка: множества из статьи Списки, словари и множества здесь как раз к месту: set(counter) - set(known) даёт то, чего вы не знаете. А чтобы отсортировать по частоте, пригодится тот же приём с sorted и key=.

Мини-итог

• Роль — это зона ответственности, а не звание. В маленькой команде роли совмещаются, но набор вопросов, на которые кто-то должен ответить, не меняется.
• Написание кода — примерно половина рабочего дня в хорошем случае. Остальное — ревью, обсуждения, разбор проблем, и это тоже работа, а не помеха.
• Задача проходит длинный путь от идеи до продакшна, и возвраты назад из ревью и тестирования — норма, а не провал.
• Ритуалы (стендапы, спринты, ретро) существуют ради обмена информацией. Где они превращаются в отчётность, они перестают работать — и это не ваша вина.
• Код-ревью — про код, а не про вас. Учитесь различать ошибку, риск, стиль и вкусовщину.
• Грейд определяется размером неопределённости, которую вы способны взять на себя, а не количеством выученных фреймворков.
• Git и SQL требуют почти во всех вакансиях, независимо от языка. Это самая безопасная инвестиция времени.

Что почитать дальше по теме (всё по-настоящему полезное, не рекламное):

• Camille Fournier, The Manager’s Path — как устроен рост от разработчика до руководителя.
• Matthew Skelton, Manuel Pais, Team Topologies — teamtopologies.com, почему команды устроены так, а не иначе.
• Google Engineering Practices — свод правил код-ревью.
• Stack Overflow Developer Survey — ежегодный опрос десятков тысяч разработчиков: языки, зарплаты, инструменты, настроения.
• Atlassian Agile Coach — понятные разборы Scrum, Kanban и всех этих встреч.

Что дальше

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

Куда двигаться дальше: специализации, план обучения и первая работа