Как делают софт и карьера Стартап изнутри: скорость, хаос, риск, опционы, плюсы и минусы
0%

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

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

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

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

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

Что делает стартап стартапом

Самое рабочее определение дал Стив Бланк: стартап — это временная организация, созданная для поиска повторяемой и масштабируемой бизнес-модели (steveblank.com). Разберём его по словам, потому что каждое слово имеет последствия для вашей работы.

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

«Поиска». Ключевое слово. Стартап не исполняет известный план — он проверяет гипотезы. Значит, то, что вы напишете, с высокой вероятностью выкинут. Это не признак плохого управления, это природа работы. Разработчик, который воспринимает выкинутый код как личное оскорбление, в стартапе страдает.

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

Отсюда — важные не-стартапы, которые часто называют стартапами:

  • Небольшая студия, которая делает сайты на заказ. Модель известна и работает, роста в разы не предполагается — это малый бизнес. Отличная работа, но динамика другая, см. типы проектов.
  • Компания на 300 человек с раундом C, выручкой и отделом кадров. Это скейлап: бизнес-модель уже найдена, теперь её масштабируют. Хаос там ещё есть, но это уже хаос роста, а не хаос поиска.
  • «Стартап» внутри корпорации, у которого бюджет утверждён на три года вперёд. Ограничение по деньгам ненастоящее, а значит, отсутствует главный двигатель — страх не дожить.

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

Деньги: механика, которая определяет вашу работу

Разработчику кажется, что финансирование — дело основателей. На практике именно оно решает, будет ли у вас через полгода работа, успеете ли вы отрефакторить модуль и почему CTO вдруг перестал отвечать в чате.

Burn rate — сколько денег компания тратит в месяц сверх того, что зарабатывает. В IT-стартапе это на 60–80% фонд оплаты труда. Каждый новый разработчик — это не только руки, но и минус несколько недель runway.

Runway — деньги на счету, делённые на burn rate. Три месяца runway означают режим выживания, восемнадцать — можно строить планы на квартал вперёд.

Окно фандрейзинга. Поднять раунд — это 4–8 месяцев переговоров, дью-дилидженса и юристов, и результат не гарантирован. Значит, начинать надо задолго до нуля. Если runway короче окна, компания попадает в ловушку: денег на поиск денег уже не хватает.

Runway, burn rate и окно фандрейзинга: почему быстрый найм убивает компанию раньше, чем неудачный продукт

Практические следствия, которые видно с рабочего места:

  • Основатель пропал на два месяца и приходит только на демо — идёт раунд. Это худшее время просить о реорганизации процессов.
  • Внезапно «нам нужна вот эта интеграция к 15-му числа» без объяснений — вероятно, это условие сделки с крупным клиентом или требование инвестора для отчётности.
  • Резко перестали нанимать и заговорили про «эффективность» — runway сократился. Дальше либо раунд, либо сокращения, и стоит спокойно спросить об этом напрямую.
  • Неожиданный найм пяти человек за месяц — раунд закрыт. Хорошая новость, но приготовьтесь к тому, что процессы, которые работали на пятерых, немедленно сломаются.

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

Стадии: одна и та же вакансия означает пять разных работ

«Разработчик в стартапе» — это пять разных профессий в зависимости от стадии. Люди, которым отлично на одной стадии, часто уходят на следующей — и это нормально, а не предательство.

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

Скорость: за счёт чего она реально берётся

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

Настоящие источники скорости:

  1. Короткий контур принятия решений. Человек, который решает «делаем или нет», сидит в соседнем кресле. Обсуждение фичи занимает пятнадцать минут вместо двух недель переписки. Это самая большая и самая честная часть выигрыша.
  2. Отсутствие legacy. Нет двадцати систем-потребителей вашего API, нет обратной совместимости с версией трёхлетней давности, нет отдела, который сломается от изменения формата. Ломать можно, потому что ломать почти нечего.
  3. Нет внешних регуляторных ворот. В большинстве ниш нет обязательной приёмки, аттестации и подписи заказчика. Сравните с релизом и эксплуатацией в регулируемом контуре.
  4. Одна голова держит систему целиком. Пока систему можно уместить в голове одного человека, проектирование стоит почти нуля.
  5. Право не делать. Стартап может сказать «эту половину сценариев мы не поддерживаем» и не поддерживать. Энтерпрайз обычно не может.

Мнимые источники скорости (то, что выглядит как скорость, а является займом):

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

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

Обратите внимание на два узла, которые новички пропускают. Первый — «можно проверить без кода»: самый быстрый код — ненаписанный, и в стартапе это не шутка, а рабочая практика (см. Paul Graham, Do Things that Don’t Scale). Второй — «удаляем код в течение недели»: невыключенные эксперименты образуют самый противный вид техдолга, потому что никто не помнит, живой этот код или нет.

Хаос: как он выглядит в календаре

Слово «хаос» звучит романтично, пока не увидишь его в виде своей недели. Вот честная реконструкция.

Понедельник: доделываете экспорт отчётов, задача взята в пятницу. В обед основатель приносит запрос от клиента, который готов платить, если появится SSO. Экспорт откладывается.

Вторник: разбираетесь с SSO. Оказывается, у клиента корпоративный провайдер, документация закрытая. Полдня уходит на переписку с их админом.

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

Четверг: возвращаетесь к SSO. К вечеру приходит новость: тот клиент решил отложить решение до следующего квартала. Задачу останавливают.

Пятница: доделываете экспорт, который начали в понедельник. На ретро говорите, что три дня ушли в никуда. Основатель отвечает, что клиент был на 30% годовой выручки, и он бы принял то же решение снова. И он прав.

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

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

Что реально помогает лично вам выжить в этом режиме:

  • Письменная фиксация решений в одну строку. Не архитектурный документ, а сообщение в общий канал: «Решили: отчёты считаем ночью батчем, а не на лету, потому что запрос не укладывается в таймаут. Плата: данные отстают на сутки. Согласовано с NN». Тридцать секунд сейчас — час экономии через два месяца.
  • Правило „я делаю X, остановите меня, если не то“. В условиях, когда постановки приходят голосовым сообщением, вы возвращаете своё понимание текстом и продолжаете работу, не дожидаясь подтверждения. Это переносит риск недопонимания с вас на того, кто ставил задачу, и при этом никого не тормозит.
  • Один трекер, даже плохой. Задачи в Telegram теряются гарантированно. Про то, откуда вообще берутся постановки, — требования и аналитика.
  • Отдельный список «мы это сломали намеренно». Чтобы техдолг был решением, а не забывчивостью.

Кто с кем разговаривает: контур обратной связи

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

Этот контур — главная профессиональная ценность стартапа. Вы своими глазами видите связь «написал код → изменилось поведение людей → изменились деньги компании». После двух лет такого опыта вы начинаете думать о задачах иначе, и это заметно на собеседованиях в любую компанию.

Обратная сторона тоже настоящая. Прямой доступ к разработчику означает, что разработчика дёргают. Если не поставить хоть какой-то фильтр (дежурный по поддержке на неделю, окно «до 12 не трогаем», отдельный канал для инцидентов), сфокусированной работы не останется совсем. Как договариваться о таком — в ролях и командах.

Технические решения при горизонте в шесть месяцев

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

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

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

Решение Почему необратимо Минимум, который надо сделать сразу
Деньги и платежи Ошибки видны бухгалтерии и клиентам, задним числом не чинятся Идемпотентность операций, журнал всех изменений баланса, никаких вычислений в плавающей точке
Персональные данные Регуляторный и репутационный риск, утечка необратима Не собирать лишнего, разделить хранение, не писать PII в логи
Аутентификация Взлом стоит компании существования Готовая библиотека или провайдер, никакой самописной криптографии
Схема ключевых сущностей Миграция накопленных данных дороже переписывания кода в разы Полчаса подумать над идентификаторами и связями, см. проектирование
Бэкапы и проверка восстановления Потерянные данные не возвращаются Автоматический бэкап и хотя бы одно проверенное восстановление
Возможность откатить релиз Без отката любая авария длится столько, сколько чинится «вперёд» Тегированные образы, миграции только совместимые вперёд

Всё остальное — честная территория для сознательного упрощения.

Оригинал квадранта — martinfowler.com/bliki/TechnicalDebtQuadrant.html; подробный разбор процентов по долгу — в статье поддержка и технический долг.

Практические принципы, которые в стартапе работают лучше всего:

  • Скучные технологии. Дэн Маккинли, Choose Boring Technology: у команды есть ограниченное число «жетонов на инновацию», и тратить их надо на то, что отличает ваш продукт, а не на модную базу данных. Стартапу почти всегда достаточно PostgreSQL, одного языка и одного способа деплоя.
  • Монолит сначала. Мартин Фаулер, MonolithFirst: микросервисы решают организационную проблему, которой у команды из шести человек нет, а платить за них инфраструктурой и распределёнными транзакциями приходится сразу.
  • Покупать, а не строить. Аутентификация, платежи, рассылки, аналитика, поиск, очереди — берите управляемые сервисы. Ваши двести часов, сэкономленные на своей реализации очереди, — это месяц runway.
  • Один способ делать каждую вещь. Хаос выдерживается, только если техническая база предсказуема: один язык на бэкенде, один шаблон сервиса, один пайплайн. Разнообразие стека — роскошь компаний, у которых есть люди на его поддержку.
  • Наблюдаемость раньше тестов. Спорный, но практичный тезис для ранней стадии: логи со структурой, метрики и алерт на «пятисотки» дают больше на единицу усилий, чем юнит-тесты кода, который через месяц выкинут. Тесты пишутся в первую очередь на то, что уже доказало право на жизнь: деньги, права доступа, критичные расчёты. Подробно про баланс — тестирование.

Минимально жизнеспособный процесс

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

# Минимальный набор, который окупается в команде 5-10 человек

трекер:
  один: true            # Jira, Linear, YouTrack, GitHub Issues — неважно
  правило: "если задачи нет в трекере, её не существует"

репозиторий:
  ветка: "короткая ветка от main, жизнь 1-3 дня"
  ревью: "обязательно, если в команде есть второй инженер"
  main: "всегда деплоится"

ci:
  на_каждый_пуш: [линтер, тесты, сборка]
  время: "меньше 10 минут, иначе его начнут обходить"

окружения:
  prod: "один"
  staging: "один, максимально похожий на prod"
  # третьего окружения на этой стадии не нужно

деплой:
  способ: "одна команда или кнопка, доступна любому инженеру"
  откат: "та же кнопка, предыдущая версия"
  флаги: "любая рискованная фича выкатывается выключенной"

дежурство:
  кто: "по очереди, включая CTO"
  канал: "один, с алертами из мониторинга"
  правило: "разбор инцидента письменно, без поиска виноватого"

встречи:
  ежедневно: "10 минут, стоя, только блокеры"
  еженедельно: "приоритеты на неделю, 30 минут"
  # ретро раз в две недели — первое, что выкидывают, и зря

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

Как выглядит недельный ритм в стартапе на стадии первых клиентов:

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

Роли: их нет, пока не станет больно

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

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

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

Момент, когда «все делают всё» ломается, наступает предсказуемо — обычно между 15 и 30 людьми. Симптомы:

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

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

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

Вознаграждение: оклад, опционы и как это устроено

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

Из чего складывается компенсация в стартапе

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

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

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

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

Как устроены опционы: словарь, который надо знать до подписания

  • Опционный пул (ESOP). Заранее выделенная доля капитала компании — обычно однозначные проценты — которую распределяют между сотрудниками. Ваш грант измеряется либо в процентах от компании, либо в числе акций (тогда обязательно спрашивайте общее число акций, иначе цифра бессмысленна).
  • Грант (grant). Ваше индивидуальное предложение: сколько акций, по какой цене, на каких условиях.
  • Цена исполнения (strike price). Цена, по которой вы сможете выкупить акции. Фиксируется в момент гранта. Если компания выросла, разница между ценой исполнения и текущей стоимостью — ваша потенциальная прибыль. Если компания подешевела, опцион становится бесполезен — это называется «под водой».
  • Вестинг (vesting). График, по которому право на акции появляется постепенно. Классика индустрии — четыре года с обрывом (cliff) в один год: до года вы не получаете ничего вообще, в конце первого года — четверть, дальше — помесячно или поквартально.
  • Обрыв (cliff). Ровно та причина, по которой уход через одиннадцать месяцев обнуляет весь опцион.
  • Окно исполнения (exercise window). Срок после увольнения, в течение которого можно выкупить свои акции — исторически 90 дней. Это самая недооценённая деталь: чтобы не потерять уже заработанное, вам придётся заплатить реальные деньги за неликвидные бумаги, и иногда ещё и налог.
  • Разводнение (dilution). Каждый новый раунд выпускает новые акции, и ваш процент уменьшается. Доля 1% после трёх раундов может стать существенно меньше. Разводнение не обязательно плохо: 0,4% в компании, которая стоит в двадцать раз больше, лучше, чем 1% в компании, которая не выросла.
  • Ликвидационная преференция (liquidation preference). Право инвесторов забрать при продаже свои деньги (или их кратное) раньше всех остальных. Именно она объясняет, почему в новостях компанию продали за «хорошие деньги», а команда не получила ничего.
  • Tag along / drag along. Право присоединиться к сделке основателей и обязанность продать свою долю вместе с ними. Определяет, можете ли вы вообще выйти.

Как эти механики складываются в реальную выплату:

Как делится сумма сделки между инвесторами и командой: механика ликвидационной преференции

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

Российская специфика

В российской правовой реальности классический опцион на акции часто нереализуем: большинство компаний — ООО с долями, а не АО с акциями, и передача доли требует нотариуса. Поэтому встречаются:

  • Фантомные опционы — договор, по которому при наступлении события (продажа компании, раунд, достижение показателей) вы получаете денежную выплату, привязанную к стоимости условной доли. Юридически это обязательство компании, а не собственность. Проверяйте, кто сторона договора и чем обеспечено обязательство.
  • Опцион на заключение договора купли-продажи доли (статьи 429.2 и 429.3 ГК РФ) — более крепкая конструкция, но требует нотариального оформления.
  • Структура через иностранное юрлицо — если у группы есть холдинг за периметром, опцион может выдаваться на него. Тогда всплывают вопросы валютного контроля и налогов, и это тема для консультации с юристом, а не для доверия на слово.

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

Как самому оценить опцион

Не «сколько мне обещали», а «сколько это стоит с поправкой на риск». Порядок рассуждения:

  1. Узнайте свою долю в процентах от полностью разводнённого капитала. Не в акциях — в процентах. Если отказываются называть, это ответ.
  2. Узнайте оценку компании в последнем раунде и сколько всего привлечено. Второе — приближение к порогу преференций.
  3. Прикиньте разводнение будущих раундов. Каждый следующий раунд обычно уменьшает вашу долю на заметную величину.
  4. Умножьте на честную вероятность успешного выхода. По данным разборов венчурного рынка, до значимого выхода доходит меньшинство профинансированных компаний, а до крупного — единицы процентов; CB Insights ведёт разбор причин закрытий: cbinsights.com/research/startup-failure-reasons-top.
  5. Примените дисконт за неликвидность и срок. Деньги через пять-семь лет с высокой неопределённостью и без возможности продать в промежутке стоят намного меньше номинала.
  6. Разделите результат на срок вестинга и сравните с разницей в окладе, на которую вы соглашаетесь. Это и есть цена вашей ставки.

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

Хороший бесплатный справочник по механике долевого вознаграждения — Holloway Guide to Equity Compensation.

Как исследовать рынок

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

  • Хабр Карьера — калькулятор зарплат и регулярные полугодовые отчёты по российскому IT-рынку с разбивкой по специализациям, грейдам и городам.
  • getmatch — вакансии публикуются с указанием вилок, что даёт срез актуальных предложений, а не воспоминаний.
  • levels.fyi — данные преимущественно по международному рынку, полезны для понимания структуры компенсации (оклад + акции + бонус) и уровней грейдов.
  • Отчёты рекрутинговых агентств и job-бордов — обзоры рынка труда от крупных агентств и HR-платформ выходят регулярно; смотрите на методологию и размер выборки, прежде чем верить медиане.
  • Живые люди. Разговор с двумя-тремя знакомыми на схожих позициях даёт более точную картину, чем любой отчёт, потому что учитывает контекст: стек, город, тип компании.

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

Риск: честная арифметика

Про риск в стартапах принято говорить либо восторженно, либо катастрофически. Попробуем спокойно.

Что вы действительно рискуете потерять:

  • Часть дохода. Разница в окладе за два-три года — вполне измеримая сумма, и она не компенсируется автоматически.
  • Время. Два года в компании, которая закрылась, не пропадают полностью, но и не равны двум годам в компании, которая выросла.
  • Опыт зрелых процессов. Если вы не видели нормального ревью, регламентированного релиза и нагруженной системы, на собеседовании в крупную компанию это будет заметно.
  • Резюме с необъяснимыми пробелами. Три закрывшихся стартапа подряд читаются нейтрально, но потребуют объяснений.
  • Здоровье. Режим «ещё две недели поднажмём» имеет свойство длиться год. Выгорание в стартапах — не миф, а самая частая причина ухода.

Что вы действительно приобретаете:

  • Широту. Вы увидите весь цикл от разговора с клиентом до дежурства в три часа ночи. Это редко и ценно.
  • Скорость роста ответственности. В стартапе можно за полтора года дойти до владения крупной частью системы. В большой компании тот же путь занимает дольше просто из-за очереди.
  • Продуктовое мышление. Умение спросить «а зачем» и оценить задачу по влиянию, а не по интересности. Ближайший смежный материал — product-management.
  • Сеть контактов. Люди из ранней команды разлетаются по индустрии и остаются вашим кругом на годы. Это недооценённый актив.
  • Небольшой шанс на существенную выплату. Именно небольшой — см. расчёт выше.

Как страховать риск, не отказываясь от него:

  1. Финансовая подушка на несколько месяцев жизни до выхода, а не после.
  2. Оклад, на который вы согласны, если опцион не выстрелит вообще.
  3. Никогда не соглашаться на «поработай пока без оформления / с задержкой зарплаты / за долю». Задержка зарплаты — не «трудности роста», а симптом того, что компания уже за краем.
  4. Всё, что обещано, — письменно. Оффер с описанием опционной программы, а не устная договорённость на кухне.
  5. Не финансировать компанию собой: не покупать оборудование за свои, не оплачивать сервисы с личной карты «а потом компенсируем».
  6. Держать резюме и профиль в актуальном состоянии. Это не нелояльность, это гигиена — см. как проходить собеседования.

Кому стартап подходит, а кому нет

Честный разбор без романтики.

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

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

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

Подделки: что называют стартапом, но им не является

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

Как проверять стартап на собеседовании

Собеседование двустороннее — и в стартапе это особенно верно, потому что проверять надо не только команду, но и жизнеспособность компании. Вопросы, которые стоит задать основателю или CTO:

Про деньги и выживание:

  1. Какой сейчас runway в месяцах и что планируется дальше — раунд, выход на самоокупаемость?
  2. Сколько всего привлечено и на какой стадии компания?
  3. Откуда берётся выручка сегодня и сколько платящих клиентов?
  4. Были ли задержки зарплаты за последний год?

Про опционы: 5. Есть ли опционная программа, оформлена ли она документами, и можно ли увидеть их до подписания оффера? 6. Какова моя доля в процентах от полностью разводнённого капитала? 7. Каков график вестинга, есть ли cliff, каково окно исполнения после ухода? 8. Какие ликвидационные преференции у инвесторов?

Про инженерную реальность: 9. Сколько раз в неделю выкатываете в прод и как откатываете? 10. Кто дежурит по инцидентам и сколько инцидентов было в прошлом месяце? 11. Есть ли код-ревью и кто будет смотреть мой код? 12. Что сломано настолько, что об этом все знают и никто не чинит?

Про людей: 13. Кто ушёл из команды за последний год и почему? 14. Как принимаются решения, если основатель и команда не согласны? 15. Как выглядела прошлая неделя у человека на моей позиции?

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

Типичные ошибки

Ошибки разработчика, впервые пришедшего в стартап:

  • Принести энтерпрайзные стандарты целиком. Слои абстракции, полное покрытие тестами, микросервисы — на стадии поиска модели это сжигает runway на код, который выкинут.
  • Считать опцион частью дохода. До подписанных документов и реального выхода это ноль. Планировать бюджет из него — самая дорогая ошибка в списке.
  • Не фиксировать договорённости. «Мы обсуждали пересмотр через полгода» без письменного следа не существует.
  • Соглашаться на «пока без оформления». Ни серые выплаты, ни отсутствие договора не компенсируются перспективами.
  • Молчать про перегруз. В стартапе никто не следит за вашей загрузкой — эта функция целиком ваша.
  • Путать хаос с отсутствием требований к качеству. Скорость не отменяет ответственности за деньги, данные и доступы.
  • Не выключать эксперименты. Флаги, которые никто не убрал, через год образуют систему, поведение которой никто не может предсказать.
  • Оставаться в компании, которая явно не выживает, из чувства долга. Верность команде понятна, но у вас нет инвесторского портфеля, чтобы диверсифицировать риск.

Ошибки, которые совершают сами стартапы (полезно распознавать заранее):

  • Нанимать быстрее, чем растёт выручка, и сокращать через полгода — см. график runway выше.
  • Начинать строить платформу до того, как найден хотя бы один повторяемый сценарий использования.
  • Копировать процессы большой компании после первого раунда, потому что «пора взрослеть».
  • Не отпускать технические решения на одного основателя при команде в тридцать человек.
  • Считать переработки стратегией. Пол Грэм разбирал типичные способы убить стартап: paulgraham.com/startupmistakes.html.

Мини-итог

  • Стартап — это не размер и не дресс-код, а фаза поиска бизнес-модели при ограниченном запасе денег. Всё остальное — следствия.
  • Главная переменная — runway. Она объясняет и скорость решений, и внезапные развороты, и найм, и сокращения. Спрашивать о ней — норма.
  • Скорость стартапа наполовину настоящая (короткий контур решений, нет legacy, нет регуляторных ворот) и наполовину заёмная (нет тестов, мониторинга, записанных решений). Первую берите бесплатно, вторую — только осознанно.
  • Правило обратимости: экономить можно ровно там, где решение дёшево отменить. Деньги, персональные данные, аутентификация, схема ключевых сущностей, бэкапы и возможность отката — не та территория.
  • Минимальный процесс — один трекер, короткие ветки, CI до десяти минут, один способ деплоя с откатом, флаги функциональности, дежурство и письменный разбор инцидентов. Этого достаточно и это окупается сразу.
  • Компенсация состоит из оклада и опциона, который надо уметь читать: доля от разводнённого капитала, цена исполнения, вестинг, cliff, окно исполнения, разводнение, ликвидационные преференции. Устные обещания стоят ноль.
  • Оценивать опцион надо методом, а не по названной сумме: доля × оценка × вероятность выхода × дисконт за неликвидность, делённое на срок вестинга. Рынок исследуйте по открытым источникам — Хабр Карьера, getmatch, levels.fyi, отчёты агентств, — всегда сверяясь с датой сбора данных.
  • Риск реален и измерим. Страхуется подушкой, окладом «как будто опциона нет», письменными договорённостями и актуальным резюме.
  • Джуну в стартапе бывает и лучший старт, и потерянные два года. Разделяющий критерий один: есть ли рядом инженер сильнее вас, у которого есть время смотреть ваш код.

Что дальше

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

Грейды: что на самом деле отличает junior, middle, senior и lead

Нашли неточность? Выделите фрагмент текста — рядом появится жучок.

Нужен разбор именно вашей ситуации?

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

Доска запросов