Энтерпрайз изнутри: процессы, согласования, масштаб, плюсы и минусы

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

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

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

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

Что такое энтерпрайз на самом деле

Численность — плохой критерий. Бывают компании на 5000 человек с продуктовыми командами, которые катят в прод четыре раза в день, и компании на 300 человек, где релиз согласуют три недели. Энтерпрайз определяется не размером штата, а сочетанием свойств:

• Высокая цена ошибки. Пятнадцать минут даунтайма — это не «упс», а потерянные деньги, сюжет в СМИ или письмо от регулятора. Отсюда всё остальное.
• Внешний надзор. Банк России, ЦБ-шные ГОСТы, 152-ФЗ о персональных данных, PCI DSS для карточных данных, отраслевые лицензии, внутренний и внешний аудит. Кто-то извне имеет право прийти и потребовать доказательств, что процесс соблюдался.
• Много владельцев. Ваш сервис зависит от семи чужих систем, и ещё двенадцать зависят от вас. Ни одно изменение не является локальным.
• Долгий горизонт. Система живёт 10–20 лет и переживёт вас, вашего тимлида и текущий язык программирования. Решения оцениваются не по «как быстро выкатим», а по «как это поддерживать в 2035 году».
• Разделение обязанностей (segregation of duties). Тот, кто пишет код, не имеет права сам поставить его в прод; тот, кто согласует доступ, не имеет права им пользоваться. Это не недоверие лично к вам, это антифрод-требование из аудиторских стандартов.

Если из пяти пунктов совпадает три и больше — вы в энтерпрайзе, независимо от вывески на здании. Классические представители: банки, телеком, страхование, ритейл-сети, промышленность, госкорпорации, крупные интеграторы, а также enterprise-подразделения внутри условно «продуктовых» компаний (биллинг, бухгалтерия, антифрод почти всегда живут по энтерпрайз-правилам, даже если рядом сидит команда мобильного приложения с CI/CD на каждый мерж).

Разные виды энтерпрайза

Не смешивайте в одну кучу:

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

Почему процессы появились: короткая экономика

Полезно один раз честно посчитать, а не спорить эмоционально.

Возьмите два режима:

• Режим скорости. Правки едут в прод за час. Ошибка ловится в проде за 20 минут, чинится ещё за 40. Стоимость инцидента — небольшая, аудитории почти нет.
• Режим надёжности. Правка едет неделю. Ошибка в проде стоит миллионы, отзыв лицензии или разбирательство с регулятором.

Если ожидаемая стоимость одного пропущенного дефекта выше, чем совокупная стоимость задержки всех изменений за квартал, — процессы экономически оправданы. Именно поэтому «просто выкатывайте на прод и чините на месте» отлично работает в SaaS для маркетинга и не работает в системе расчётов. Это не разница в смелости, это разница в множителе ущерба.

Логика та же, что в статье про стоимость дефекта из Тестирование и приёмка: чем дороже ошибка, тем раньше и жёстче её ловят.

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

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

Путь одной задачи: полная картина

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

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

Числа на картинке иллюстративные, но пропорция типичная: активная работа — единицы процентов от календарного времени, остальное — ожидание. Отсюда следует неочевидное для новичка: научиться печатать быстрее не ускорит вашу поставку почти никак. Ускорит умение не создавать простои.

Если хотите измерять это цифрами, а не ощущениями — смотрите метрики потока (lead time, flow efficiency, WIP) в Kanban и поток и DORA-метрики в DORA и инженерные метрики.

Жизненный цикл задачи в трекере

В стартапе статусов в Jira обычно четыре. В энтерпрайзе их пятнадцать, и половина — это «ждём кого-то». Каждый такой статус существует, чтобы разделить ответственность: пока задача в статусе «На согласовании ИБ», она не считается просроченной для команды разработки.

Обратите внимание на количество стрелок «назад». В энтерпрайзе задача часто возвращается на два-три шага, и каждый возврат стоит нового круга ожидания. Отсюда главное правило выживания: дешевле потратить лишний день на подготовку, чем один раз вернуться из UAT. Это ровно та же экономика, что в разделе про Definition of Done в Разработка, только с множителем.

Согласования: кто эти люди и как с ними работать

Список инстанций, с которыми вы столкнётесь, и что каждой на самом деле нужно.

Архитектурный комитет (или главный архитектор). Смотрит: не появляется ли пятая очередь сообщений, не дублируете ли вы существующий сервис, укладывается ли решение в целевую архитектуру. Их страх — зоопарк технологий, который потом никто не сможет поддерживать. Что от вас нужно: письменный документ (RFC / design doc) с проблемой, двумя-тремя вариантами, обоснованным выбором и явными рисками. Формат решений — см. ADR в Архитектурные решения.

Информационная безопасность. Смотрит: новые данные (особенно персональные), новые сетевые взаимодействия, новые доступы, криптография, секреты в коде, зависимости с известными уязвимостями. Их страх — утечка и штраф. Что от вас нужно: честный ответ на вопрос «какие данные, куда, кто имеет доступ, как хранится, как удаляется». Практика встраивания проверок в пайплайн — в Безопасность в пайплайне.

Change Advisory Board (CAB), он же комитет по изменениям. Из ITIL-практик управления изменениями. Смотрит: что именно едет, когда, кто ответственный, что делаем при откате, кого затрагивает. Их страх — два несовместимых изменения в одну ночь и никто не понимает, что сломалось. Что от вас нужно: заполненная заявка на изменение с планом отката, который вы действительно проверяли, а не написали «откатим контейнер».

Смежные команды. Владельцы систем, с которыми вы интегрируетесь. Их страх — что вы сломаете им контракт или устроите незапланированную нагрузку. Что от вас нужно: заранее согласованный контракт API и предупреждение о профиле нагрузки.

Юристы, комплаенс, закупки. Появляются, когда вы хотите новую библиотеку с непонятной лицензией, внешнее SaaS или обработку данных в новой стране. Что от вас нужно: терпение и заранее заложенный в план срок.

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

Главный приём: параллелить, а не выстраивать в цепь

Новичок проходит согласования последовательно, потому что узнаёт о каждом следующем в момент, когда оно стало блокером. Опытный инженер в первый день задачи составляет список всех, кто скажет своё слово, и запускает все очереди сразу. Последовательность оставляют только там, где вход одной очереди — реальный выход другой (нет смысла нести на ИБ дизайн, который архитектор развернёт целиком).

Практическая техника, которая работает почти везде:

1. В день получения задачи спросите тимлида: «через какие согласования это пройдёт?». Запишите ответ в тикет — вы удивитесь, как часто это выясняется впервые.
2. Найдите SLA и расписание каждой инстанции. Комитет раз в две недели по средам — это значит, что пропущенная среда стоит вам двух недель.
3. Заведите тикеты во все очереди в один день, даже черновые.
4. Ведите один документ-источник правды, а не пять переписок в разных чатах.
5. Явно пометьте в задаче дату, после которой вы гарантированно не попадаете в ближайшее релизное окно, — и сообщите её заранее, а не постфактум.

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

Взаимодействие ролей: как выглядит одно изменение

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

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

Отдельно отметьте шаг «реализация против черновика контракта + моки». Ждать две недели, пока смежники доделают, — путь новичка. Договориться о контракте на бумаге и работать против заглушки — путь взрослого инженера. Contract-first подход разбирается в Стили API.

Релизный цикл и календарь, по которому живёт компания

В стартапе релиз — это событие в CI. В энтерпрайзе релиз — это дата в календаре, вокруг которой выстроен квартал.

Что из этого нужно понимать джуну:

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

Постепенно многие энтерпрайзы двигаются от больших поездов к более частым релизам — через feature flags, канареечные выкладки и автоматизацию проверок. Механику см. в Релиз и эксплуатация и CD и стратегии релиза. Ключевая мысль: частота релизов ограничена не технологией, а стоимостью проверки. Автоматизируете проверки — процесс сам начинает сокращаться. Это, кстати, лучший способ повлиять на бюрократию изнутри: не спорить с ней, а сделать её шаги дешёвыми.

Масштаб: что меняется, когда систем много

Закон Конвея работает буквально

Мелвин Конвей в 1967 году сформулировал: организация проектирует системы, копирующие её собственную структуру коммуникаций (оригинал — melconway.com). В энтерпрайзе это видно невооружённым глазом: если расчёты и отчётность — разные департаменты, между ними будет интеграция с очередью и своим форматом обмена, даже когда технически это должно быть одним модулем.

Практический вывод: границы сервисов в большой компании определяются не архитектурой, а тем, кто с кем может договориться. Спорить с этим бесполезно, учитывать — обязательно. Осознанное использование эффекта («обратный манёвр Конвея» — меняем структуру команд, чтобы получить нужную архитектуру) разбирается в Team Topologies (teamtopologies.com) и в Масштабирующие фреймворки.

Найти владельца — отдельный навык

В компании с сотнями сервисов главный вопрос обычно не «как это работает», а «кто за это отвечает». Типичный поиск: в CODEOWNERS пусто, в вики страница 2019 года, автор последнего коммита уволился, в чате поддержки отвечают «это не к нам». Что делать:

1. git log по файлу — кто трогал последним и кто трогал чаще всего;
2. система тикетов — кто закрывал задачи по этому компоненту в последний год;
3. внутренний сервис-каталог (Backstage и аналоги), если он есть и заполнен;
4. дежурный по системе — в графике on-call владелец указан почти всегда честно, потому что его будят;
5. спросить в общем чате разработки формулировкой «ищу владельца компонента X, нужно согласовать изменение контракта» — конкретно и с указанием, зачем.

Совет, который экономит месяцы: как только нашли владельца — запишите это в README компонента или в сервис-каталог. Через полгода это найдёте вы же.

Внутренние платформы: и подарок, и клетка

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

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

Legacy: код старше вашего стажа

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

Что помогает:

• Считать legacy не «плохим кодом», а кодом без тестов и без живого автора. Определение и весь набор приёмов — Michael Feathers, «Working Effectively with Legacy Code».
• Не переписывать целиком. Классическая стратегия постепенного замещения — Strangler Fig (martinfowler.com): новый функционал пишем в новом сервисе, старый перенаправляем по кускам.
• Перед изменением — обвязать характеризующими тестами: зафиксировать текущее поведение, даже если оно кажется странным. В энтерпрайзе странное поведение часто оказывается требованием регулятора десятилетней давности.
• Подробнее про работу с накопленным долгом — Поддержка и технический долг.

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

Плюсы энтерпрайза (честно, без рекламных формулировок)

• Масштаб, который негде больше увидеть. Нагрузки, объёмы данных, требования к доступности, распределённые транзакции с реальными деньгами. Задачи вроде «идемпотентность платежа при сетевом сбое» в маленькой компании просто не возникают.
• Систематическое обучение. Есть кому ревьюить ваш код, есть архитекторы, есть внутренние стандарты, есть менторство и часто оплачиваемое обучение. Джун в энтерпрайзе за первый год обычно получает больше структурированной обратной связи, чем джун в стартапе за два.
• Предсказуемость. Зарплату платят, процессы описаны, отпуск можно запланировать на полгода вперёд, компания не закроется через квартал. Для человека с ипотекой или маленьким ребёнком это не мелочь.
• Специализация. Можно глубоко уйти в одну область — базы данных, безопасность, производительность, интеграции — и стать реальным экспертом. В маленькой команде вы обречены быть универсалом.
• Формализованный рост. Есть грейды, критерии, регулярный performance review. Это скучно, но это лучше, чем «повышение зависит от настроения фаундера». Подробно — Грейды и Как расти.
• Соцпакет и инфраструктура. ДМС, компенсации, корпоративное обучение, конференции, нормальное железо, юридическая и бухгалтерская поддержка. Не героика, но качество жизни.
• Право на качество. Парадоксально, но в энтерпрайзе часто легче обосновать время на тесты, документацию и рефакторинг, чем в стартапе, где всё горит. Аргумент «регулятор потребует доказательств» открывает двери, которые не открывает аргумент «так красивее».

Минусы (тоже честно)

• Скорость. От идеи до пользователя — недели и месяцы. Дофаминовая петля «сделал → увидел эффект» растянута настолько, что связь между вашей работой и результатом ощущается слабо. Это выматывает сильнее, чем кажется со стороны.
• Размытая ответственность. Когда решение принимают семь инстанций, за результат не отвечает никто. Найти, кто скажет «да», бывает труднее, чем сделать саму работу.
• Политика. Не в смысле интриг (хотя бывает и так), а в смысле: у отделов разные цели и разные премии, и иногда ваша задача противоречит чьему-то KPI. Технически правильное решение может проиграть организационно.
• Устаревающий стек. Не везде, но часто: миграция версии фреймворка в системе на 300 интеграций — проект на квартал, поэтому её откладывают годами.
• Ощущение винтика. Ваш вклад — 0.3% продукта. Некоторых это освобождает (можно спокойно уйти в отпуск), других деморализует.
• Процессы ради процессов. Часть шагов действительно бессмысленна, и вы не сможете их отменить в одиночку. Умение спокойно жить с иррациональным — необходимый навык.
• Риск «непереносимого» опыта. Пять лет во внутренней экосистеме без работы с рыночными технологиями сильно сужают выбор при смене работы.

Ловушка, о которой мало говорят

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

Деньги и грейды в энтерпрайзе: как устроен механизм

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

Что отличает большую компанию:

• Формальная грейдовая сетка. Каждой должности соответствует грейд, каждому грейду — вилка (минимум, медиана, максимум). Вилки утверждает компенсационный комитет на основе обзоров рынка, которые компания покупает у консалтинговых агентств.
• Позиция в вилке (compa-ratio). Это отношение вашей зарплаты к медиане вилки. Если вы в нижней трети вилки — у вас есть пространство для роста внутри грейда. Если у верхней границы — вам физически не могут поднять существенно, пока не повысят грейд. Это важнейший вопрос, который почти никто не задаёт: «где я нахожусь в вилке своего грейда?» — во многих компаниях на него честно отвечают.
• Пересмотр по календарю. Повышения происходят в цикле ревью (обычно раз в год или два раза в год), а не когда вам захотелось. Просить прибавку за месяц до цикла бессмысленно — бюджеты уже свёрстаны. Готовиться нужно за квартал.
• Индексация ≠ повышение. Индексация компенсирует инфляцию всем сразу и обычно не отражает вашу работу. Реальный рост — это либо движение вверх внутри вилки, либо смена грейда.
• Премии по KPI. Часто есть годовая или квартальная премия, привязанная к целям компании/департамента и вашей оценке. Уточняйте: какой процент от оклада, насколько она реально выплачивается (спросите: «какая была фактическая выплата за последние два года относительно целевой?»), что происходит при увольнении до даты выплаты.
• Долгосрочные программы. В публичных компаниях бывают акции/RSU или их аналоги, в непубличных — фантомные/отложенные премии с вестингом на несколько лет. Разбирайтесь в условиях: график вестинга, что происходит при уходе, как оценивается.
• Нематериальное, у которого есть цена. ДМС со стоматологией, оплачиваемое обучение, компенсация спорта, льготная ипотека, релокационные пакеты. Складывайте это в общую картину: разница в окладе может съедаться разницей в пакете.

Как исследовать рынок (метод, а не цифры):

1. Соберите 15–30 актуальных вакансий на вашу роль и стек с указанными вилками. Отбрасывайте крайние 10% сверху и снизу.
2. Смотрите открытые источники: Хабр Карьера (агрегированная статистика зарплат по грейдам и специализациям), getmatch (вакансии с открытыми вилками), levels.fyi (для международного рынка и грейдовых сеток крупных компаний), ежегодные отчёты рекрутинговых агентств и зарплатные обзоры на Хабре. Все они смещены — вакансии показывают верхнюю границу, опросы переоценивают активных участников. Сверяйте несколько источников.
3. Отдельно уточняйте у знакомых в отрасли — это самый точный, но самый узкий источник.
4. Считайте полную компенсацию за год, а не оклад: оклад × 12 + ожидаемая премия
   • денежный эквивалент льгот. Например (иллюстрация метода, не рекомендация суммы): если оклад X, премия «до 20% годовых» с фактической выплатой около 70% от целевой, то ожидаемая годовая компенсация ≈ 12·X + 0.2·12·X·0.7 = 13.68·X. Тот же расчёт для второго оффера — и вы сравниваете сопоставимые числа.
5. Помните, что вилка привязана к грейду и региону, а рынок сдвигается каждые несколько месяцев. Данные полугодовой давности — уже гипотеза, а не факт.

Про переговоры — отдельно в Переговоры об оффере. Здесь только энтерпрайз-нюанс: у нанимающего менеджера обычно нет свободы выйти за пределы вилки грейда. Торговаться в такой ситуации имеет смысл не про «дайте больше», а про грейд, про позицию в вилке, про подписной бонус (на него бюджеты часто отдельные), про дату первого пересмотра, про уровень удалёнки и про обучение. Аргумент «я стою больше» без данных не работает; работает «вот моя оценка рынка по этим источникам, вот что я приношу, вот грейд, на который я претендую».

Карьерная траектория в большой компании

Три важные оговорки к этой картинке.

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

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

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

Как быть эффективным: практическая тактика

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

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

Ведите один документ на задачу. RFC или design doc — не бюрократия, а инструмент параллелизации: пока вы объясняете замысел одному человеку голосом, остальные четверо не в курсе. Документ читают все сразу.

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

Не ждите молча. Задача в чужой очереди — не «не моя проблема». Раз в несколько дней вежливый пинг с конкретикой («напоминаю про ревью тикета SEC-1234, блокирует релиз 25-го») абсолютно нормален и ожидаем. Люди в больших компаниях тонут в очередях, и напоминание воспринимают как помощь, а не как давление.

Уважайте чужие протоколы. У ИБ есть форма — заполните её полностью, а не «привет, можно я вызову внешний API?». Половина задержек в согласованиях — это возвраты из-за недозаполненных заявок.

Стройте отношения до того, как они понадобятся. Знакомый человек в смежной команде отвечает за час, незнакомый — за неделю. Это не цинизм, это структура организации. Заходите на демо соседних команд, отвечайте на чужие вопросы в общих чатах.

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

Изучите один чужой контур глубже, чем требуется. Разработчик, который понимает, как работает контур ИБ или как устроен процесс изменений, становится переводчиком между командой и организацией. Такие люди растут быстрее всех, потому что снимают с команды самую неприятную часть работы.

Типичные ошибки новичка в энтерпрайзе

1. Считать процессы глупостью и демонстративно это высказывать. Даже если конкретный шаг действительно бессмысленный, публичное презрение закрывает вам возможность его изменить: никто не будет менять правила по просьбе человека, который назвал их дурацкими.
2. Молчать, когда заблокирован. Джун сидит три дня на «жду ответа ИБ» и не говорит тимлиду. Тимлид узнаёт об этом на статусе и не понимает, почему никто не сказал. Быть заблокированным — нормально; молчать о блоке — нет.
3. Начинать кодить до согласования архитектуры. Особенно на задаче, где решение очевидно вам, но затрагивает чужие системы. Комитет развернёт — и вся неделя в мусор. Дешевле потратить день на RFC.
4. Обещать сроки, не заложив ожидание. «Работы на два дня» превращается в месяц, и виноватым выглядите вы. Правильная формулировка: «два дня работы плюс ориентировочно две-три недели на согласования и релизное окно; критичная дата — вторник, иначе уезжаем на следующий поезд».
5. Пытаться изменить всё сразу. Новый человек видит десять проблем и пишет большой пост о том, как надо. Это почти никогда не срабатывает. Работает другое: выбрать одну маленькую боль, починить её лично, показать результат — и уже потом говорить о системных изменениях с позиции человека, который что-то сделал.
6. Игнорировать документацию, потому что «её всё равно никто не читает». В энтерпрайзе читают — через два года, когда вас уже нет. И иногда это аудитор.
7. Не пользоваться корпоративными возможностями. Обучение, конференции, внутренние курсы, ротации, менторские программы — всё это лежит в HR-портале, и большинство про это просто не спрашивает.
8. Копить недовольство молча. Проблемы с нагрузкой, ролью или зарплатой в большой компании решаются через регулярные one-on-one с руководителем, а не через внезапное заявление об уходе. Механика — в Как расти и Первые 90 дней.

Как понять на собеседовании, какой энтерпрайз перед вами

Вопросы, которые дают больше информации, чем любые слова про «мы динамичная команда». Подробнее про вопросы работодателю — в Как проходить собеседования.

• «Сколько времени проходит от готового PR до прода для типовой задачи?» Ответ «пара дней» и ответ «шесть недель» описывают две разные жизни.
• «Как часто вы релизитесь и есть ли релизное окно?»
• «Через какие согласования проходит изменение, затрагивающее новые данные?» Если человек не может перечислить — либо их нет (хорошо), либо он сам не понимает процесс (плохо).
• «Есть ли у команды доступ к логам и метрикам прода? Кто дежурит?» Команда без доступа к своим логам — очень сильный сигнал о зрелости.
• «Какая доля времени команды уходит на техдолг и поддержку?» Честный ответ «процентов тридцать» лучше, чем «мы всё время делаем новое».
• «Кто принимает решение о выборе технологии — команда, архитектор или комитет?»
• «Как устроены грейды и как часто пересматривается компенсация?»
• «Расскажите про последний серьёзный инцидент — что изменили после него?» Ответ показывает культуру: ищут причины или ищут виноватого.

Отсутствие внятных ответов на первые три — не приговор, но означает, что вам придётся выяснять это самому в первый месяц.

Когда энтерпрайз — правильный выбор, а когда нет

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

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

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

Мини-итог

• Энтерпрайз определяется не численностью, а ценой ошибки, внешним надзором, количеством владельцев и долгим горизонтом жизни систем.
• Процессы там появились из реальных инцидентов, но не удаляются — поэтому часть из них устарела. Правильный вопрос: «от какого риска защищает этот шаг сегодня?».
• В календаре задачи активная работа занимает единицы процентов, остальное — ожидание. Главный рычаг ускорения — параллелить согласования и не создавать простои, а не быстрее писать код.
• Ключевые инстанции: архитектурный комитет, ИБ, CAB, смежные команды, владельцы данных. У каждой свой страх и свой формат; попадание в формат экономит недели.
• Релиз — событие в календаре: code freeze, регресс, UAT, окно. Сокращается он не спорами, а автоматизацией проверок.
• Плюсы: масштаб, обучение, предсказуемость, специализация, формальный рост, право на качество. Минусы: медленно, размытая ответственность, политика, риск непереносимого опыта и комфорта.
• Компенсация устроена через грейды и вилки; спрашивайте про свою позицию в вилке, цикл пересмотра и фактическую выплату премий. Цифры исследуйте сами по нескольким источникам и пересматривайте каждые несколько месяцев.
• Самые ценные навыки в этой среде: писать понятно, находить владельцев, вести один документ на задачу и не молчать, когда заблокирован.

Что почитать

• Michael Feathers, «Working Effectively with Legacy Code» — как менять код без тестов.
• Gene Kim, Kevin Behr, George Spafford, «The Phoenix Project» — роман про поток работы в крупной IT-организации; лучшее художественное объяснение, почему очереди убивают.
• Nicole Forsgren, Jez Humble, Gene Kim, «Accelerate» и актуальные отчёты dora.dev — данные о том, что скорость и надёжность не противоречат друг другу.
• Matthew Skelton, Manuel Pais, «Team Topologies» (teamtopologies.com) — как структура команд определяет архитектуру.
• Martin Fowler, Strangler Fig Application — стратегия постепенной замены legacy.
• Melvin Conway, How Do Committees Invent? — первоисточник закона Конвея.
• Google SRE Book (sre.google/books) — главы про управление изменениями и постмортемы без поиска виноватых.

Что дальше

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

Стартап изнутри: скорость, хаос, риск, опционы, плюсы и минусы