Стартап изнутри: скорость, хаос, риск, опционы, плюсы и минусы
В предыдущей статье трека — энтерпрайз изнутри — мы разбирали мир, где решение проходит через четыре согласования, а релиз готовится месяц. Стартап часто описывают как его зеркальное отражение: «здесь можно всё, никто не мешает, катим в прод по десять раз в день». Это описание верно примерно наполовину и опасно ровно тем, что вторую половину умалчивает.
Вторая половина звучит так: в стартапе никто не мешает вам принять неверное решение, у компании ограничен запас денег, а ваше вознаграждение частично состоит из бумаги, которая может не стоить ничего. Это не повод не идти в стартап. Это повод понимать, во что вы заходите, и уметь задать десять правильных вопросов до подписания оффера.
Эта статья — не агитация в обе стороны. Это инструкция по чтению стартапа как системы: откуда берутся деньги, почему из них следуют процессы, какие технические решения при этом рациональны и как устроена компенсация, включая ту её часть, о которой не принято говорить вслух.
Что делает стартап стартапом
Самое рабочее определение дал Стив Бланк: стартап — это временная организация, созданная для поиска повторяемой и масштабируемой бизнес-модели (steveblank.com). Разберём его по словам, потому что каждое слово имеет последствия для вашей работы.
«Временная». Стартап — переходное состояние, а не форма жизни. Он должен либо превратиться в компанию с работающей экономикой, либо закрыться. Оба исхода нормальны, третьего нет. Отсюда особая интонация всех решений: почти каждое из них принимается с горизонтом «доживём ли мы до следующего этапа».
«Поиска». Ключевое слово. Стартап не исполняет известный план — он проверяет гипотезы. Значит, то, что вы напишете, с высокой вероятностью выкинут. Это не признак плохого управления, это природа работы. Разработчик, который воспринимает выкинутый код как личное оскорбление, в стартапе страдает.
«Повторяемой и масштабируемой». Один довольный клиент — не бизнес-модель. Модель считается найденной, когда понятно: за счёт какого канала приходят пользователи, сколько стоит их привлечение, сколько они приносят и почему второй, десятый и сотый клиент придут так же, как первый. До этого момента компания живёт на чужие деньги.
Отсюда — важные не-стартапы, которые часто называют стартапами:
- Небольшая студия, которая делает сайты на заказ. Модель известна и работает, роста в разы не предполагается — это малый бизнес. Отличная работа, но динамика другая, см. типы проектов.
- Компания на 300 человек с раундом C, выручкой и отделом кадров. Это скейлап: бизнес-модель уже найдена, теперь её масштабируют. Хаос там ещё есть, но это уже хаос роста, а не хаос поиска.
- «Стартап» внутри корпорации, у которого бюджет утверждён на три года вперёд. Ограничение по деньгам ненастоящее, а значит, отсутствует главный двигатель — страх не дожить.
Единственная переменная, которая объясняет поведение настоящего стартапа лучше всех остальных, — runway: на сколько месяцев хватит денег при текущей скорости расходов. Всё остальное — производные.
Деньги: механика, которая определяет вашу работу
Разработчику кажется, что финансирование — дело основателей. На практике именно оно решает, будет ли у вас через полгода работа, успеете ли вы отрефакторить модуль и почему CTO вдруг перестал отвечать в чате.
Burn rate — сколько денег компания тратит в месяц сверх того, что зарабатывает. В IT-стартапе это на 60–80% фонд оплаты труда. Каждый новый разработчик — это не только руки, но и минус несколько недель runway.
Runway — деньги на счету, делённые на burn rate. Три месяца runway означают режим выживания, восемнадцать — можно строить планы на квартал вперёд.
Окно фандрейзинга. Поднять раунд — это 4–8 месяцев переговоров, дью-дилидженса и юристов, и результат не гарантирован. Значит, начинать надо задолго до нуля. Если runway короче окна, компания попадает в ловушку: денег на поиск денег уже не хватает.
Практические следствия, которые видно с рабочего места:
- Основатель пропал на два месяца и приходит только на демо — идёт раунд. Это худшее время просить о реорганизации процессов.
- Внезапно «нам нужна вот эта интеграция к 15-му числа» без объяснений — вероятно, это условие сделки с крупным клиентом или требование инвестора для отчётности.
- Резко перестали нанимать и заговорили про «эффективность» — runway сократился. Дальше либо раунд, либо сокращения, и стоит спокойно спросить об этом напрямую.
- Неожиданный найм пяти человек за месяц — раунд закрыт. Хорошая новость, но приготовьтесь к тому, что процессы, которые работали на пятерых, немедленно сломаются.
Умение прямо спросить «какой сейчас runway и когда следующий раунд» — не наглость, а профессиональная гигиена. В здоровом стартапе на этот вопрос отвечают цифрой. Уклончивый ответ — сам по себе ответ.
Стадии: одна и та же вакансия означает пять разных работ
«Разработчик в стартапе» — это пять разных профессий в зависимости от стадии. Люди, которым отлично на одной стадии, часто уходят на следующей — и это нормально, а не предательство.
Ключевая мысль: стартап — это не тип компании, а фаза. Если вам нравится драйв ранней стадии, знайте, что через два-три года успеха вы окажетесь в другой компании с тем же названием.
Скорость: за счёт чего она реально берётся
Стартап действительно быстрее энтерпрайза, но важно понимать источники этой скорости — потому что часть из них воспроизводима, а часть является отложенным долгом.
Настоящие источники скорости:
- Короткий контур принятия решений. Человек, который решает «делаем или нет», сидит в соседнем кресле. Обсуждение фичи занимает пятнадцать минут вместо двух недель переписки. Это самая большая и самая честная часть выигрыша.
- Отсутствие legacy. Нет двадцати систем-потребителей вашего API, нет обратной совместимости с версией трёхлетней давности, нет отдела, который сломается от изменения формата. Ломать можно, потому что ломать почти нечего.
- Нет внешних регуляторных ворот. В большинстве ниш нет обязательной приёмки, аттестации и подписи заказчика. Сравните с релизом и эксплуатацией в регулируемом контуре.
- Одна голова держит систему целиком. Пока систему можно уместить в голове одного человека, проектирование стоит почти нуля.
- Право не делать. Стартап может сказать «эту половину сценариев мы не поддерживаем» и не поддерживать. Энтерпрайз обычно не может.
Мнимые источники скорости (то, что выглядит как скорость, а является займом):
- Отсутствие тестов. Экономит недели на старте, возвращается часами отладки на каждом релизе через полгода.
- Отсутствие мониторинга. Вы узнаёте об аварии от клиента в чате — то есть после того, как ущерб уже нанесён.
- Ручной деплой с ноутбука. Работает, пока деплоит один конкретный человек и пока он не в отпуске.
- Решения без записи. Через три месяца никто не помнит, почему выбрали эту схему данных, и её переделывают вслепую.
Полезная эвристика: скорость, полученная за счёт устранения согласований, — бесплатна и её надо брать. Скорость, полученная за счёт устранения обратной связи, — это заём под высокий процент. Тесты, логи, метрики и алерты — это не бюрократия, это и есть обратная связь, а стартап живёт поиском, то есть обратной связью.
или из разговора с клиентом"] --> B{"Можно проверить
без кода?"} B -->|"да"| C["Лендинг, фейк-дверь,
ручная услуга за кулисами"] C --> M["Смотрим на поведение
реальных людей"] B -->|"нет"| D["Самая узкая версия,
которая даёт ответ"] D --> E["Ветка от main,
1-3 дня работы"] E --> F{"Ревью есть?"} F -->|"есть второй инженер"| G["Быстрое ревью,
меньше часа ожидания"] F -->|"нет"| H["Самопроверка по чек-листу:
деньги, доступы, данные, откат"] G --> I["CI: линтер, тесты,
сборка образа"] H --> I I --> J["Деплой в прод
за флагом функциональности"] J --> K["Включаем на 5% или
на внутренних пользователях"] K --> M M --> N{"Гипотеза
подтвердилась?"} N -->|"да"| O["Раскатываем,
убираем флаг, дописываем тесты"] N -->|"нет"| P["Выключаем флаг,
удаляем код в течение недели"] P --> Q["Записываем, что узнали"] O --> Q
Обратите внимание на два узла, которые новички пропускают. Первый — «можно проверить без кода»: самый быстрый код — ненаписанный, и в стартапе это не шутка, а рабочая практика (см. Paul Graham, Do Things that Don’t Scale). Второй — «удаляем код в течение недели»: невыключенные эксперименты образуют самый противный вид техдолга, потому что никто не помнит, живой этот код или нет.
Хаос: как он выглядит в календаре
Слово «хаос» звучит романтично, пока не увидишь его в виде своей недели. Вот честная реконструкция.
Понедельник: доделываете экспорт отчётов, задача взята в пятницу. В обед основатель приносит запрос от клиента, который готов платить, если появится SSO. Экспорт откладывается.
Вторник: разбираетесь с SSO. Оказывается, у клиента корпоративный провайдер, документация закрытая. Полдня уходит на переписку с их админом.
Среда: падает прод. Причина — таблица выросла до размера, когда отчётный запрос перестал укладываться в таймаут. Чините индексом, потом сидите и думаете, что это надо переделывать нормально, но не сейчас.
Четверг: возвращаетесь к SSO. К вечеру приходит новость: тот клиент решил отложить решение до следующего квартала. Задачу останавливают.
Пятница: доделываете экспорт, который начали в понедельник. На ретро говорите, что три дня ушли в никуда. Основатель отвечает, что клиент был на 30% годовой выручки, и он бы принял то же решение снова. И он прав.
Это и есть хаос: не бардак от глупости, а высокая частота смены приоритетов из-за высокой неопределённости. Он неустраним, пока компания ищет модель. Устранима только его худшая часть — потери из-за незафиксированных решений.
потому что срочно Идея --> Заморожена: гипотеза отпала
до начала работы ВРаботе --> Приостановлена: приоритет сменился
в середине Приостановлена --> ВРаботе: вернулись через неделю Приостановлена --> Отменена: не вернулись никогда ВРаботе --> ЗаФлагом: выкатили в прод,
но выключенной ЗаФлагом --> Раскатывается: метрики подтвердили ЗаФлагом --> Откатывается: метрики опровергли Откатывается --> УдаленКод: убрали флаг и код Раскатывается --> Живёт Живёт --> Техдолг: работает, но написано
под другие объёмы Техдолг --> Живёт: переписали УдаленКод --> [*] Отменена --> [*] Живёт --> [*] note right of Приостановлена Самое дорогое состояние. Незакрытая задача занимает место в голове и в ветках. Если через 2 недели не вернулись — честнее отменить. end note
Сравните этот жизненный цикл с тем, что описан в разработке: в упорядоченном процессе задача идёт вперёд, в стартапе она регулярно ходит назад и вбок. Практический вывод: держите не больше одной-двух задач в состоянии «начато», потому что вероятность отмены высокая, а незавершённая работа — чистый убыток.
Что реально помогает лично вам выжить в этом режиме:
- Письменная фиксация решений в одну строку. Не архитектурный документ, а сообщение в общий канал: «Решили: отчёты считаем ночью батчем, а не на лету, потому что запрос не укладывается в таймаут. Плата: данные отстают на сутки. Согласовано с NN». Тридцать секунд сейчас — час экономии через два месяца.
- Правило „я делаю X, остановите меня, если не то“. В условиях, когда постановки приходят голосовым сообщением, вы возвращаете своё понимание текстом и продолжаете работу, не дожидаясь подтверждения. Это переносит риск недопонимания с вас на того, кто ставил задачу, и при этом никого не тормозит.
- Один трекер, даже плохой. Задачи в Telegram теряются гарантированно. Про то, откуда вообще берутся постановки, — требования и аналитика.
- Отдельный список «мы это сломали намеренно». Чтобы техдолг был решением, а не забывчивостью.
Кто с кем разговаривает: контур обратной связи
В энтерпрайзе между разработчиком и пользователем шесть человек. В стартапе — ноль или один, и это меняет всё.
«не могу выгрузить отчёт» F->>D: Пересылает сообщение
напрямую, без тикета D->>P: Смотрит логи, находит причину D-->>F: «Проблема у всех с датасетом больше 50к строк» F->>D: «Сколько таких клиентов? Чиним сейчас?» D-->>F: «Семнадцать из ста. Костыль — 2 часа,
нормально — 3 дня» F->>D: «Костыль сейчас, нормально — после раунда» D->>P: Выкатывает фикс за флагом D->>U: Пишет клиенту напрямую:
«починили, проверьте» U-->>D: «Работает, спасибо» Note over D,U: Цикл занял полдня.
В энтерпрайзе тот же цикл —
от двух недель до квартала. Note over F,D: Обратная сторона: разработчик
прерывается непредсказуемо,
сфокусированной работы почти нет
Этот контур — главная профессиональная ценность стартапа. Вы своими глазами видите связь «написал код → изменилось поведение людей → изменились деньги компании». После двух лет такого опыта вы начинаете думать о задачах иначе, и это заметно на собеседованиях в любую компанию.
Обратная сторона тоже настоящая. Прямой доступ к разработчику означает, что разработчика дёргают. Если не поставить хоть какой-то фильтр (дежурный по поддержке на неделю, окно «до 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 ГК РФ) — более крепкая конструкция, но требует нотариального оформления.
- Структура через иностранное юрлицо — если у группы есть холдинг за периметром, опцион может выдаваться на него. Тогда всплывают вопросы валютного контроля и налогов, и это тема для консультации с юристом, а не для доверия на слово.
Практическое правило: устные обещания опционов не стоят ничего. Фраза «мы оформим, когда будет раунд» встречается очень часто и очень часто не заканчивается ничем — не обязательно из злого умысла, чаще из-за того, что у основателей не доходят руки, а потом условия меняются. Пока нет подписанного документа, считайте эту часть компенсации равной нулю и договаривайтесь об окладе так, как будто её нет.
Как самому оценить опцион
Не «сколько мне обещали», а «сколько это стоит с поправкой на риск». Порядок рассуждения:
- Узнайте свою долю в процентах от полностью разводнённого капитала. Не в акциях — в процентах. Если отказываются называть, это ответ.
- Узнайте оценку компании в последнем раунде и сколько всего привлечено. Второе — приближение к порогу преференций.
- Прикиньте разводнение будущих раундов. Каждый следующий раунд обычно уменьшает вашу долю на заметную величину.
- Умножьте на честную вероятность успешного выхода. По данным разборов венчурного рынка, до значимого выхода доходит меньшинство профинансированных компаний, а до крупного — единицы процентов; CB Insights ведёт разбор причин закрытий: cbinsights.com/research/startup-failure-reasons-top.
- Примените дисконт за неликвидность и срок. Деньги через пять-семь лет с высокой неопределённостью и без возможности продать в промежутке стоят намного меньше номинала.
- Разделите результат на срок вестинга и сравните с разницей в окладе, на которую вы соглашаетесь. Это и есть цена вашей ставки.
Итог этого упражнения почти всегда один и тот же: опцион на ранней стадии — лотерейный билет с положительным матожиданием и огромной дисперсией. Разумная стратегия — соглашаться на него только тогда, когда оклад закрывает вашу жизнь без учёта опциона.
Хороший бесплатный справочник по механике долевого вознаграждения — Holloway Guide to Equity Compensation.
Как исследовать рынок
Ваша переговорная позиция строится на данных, а не на ощущениях. Открытые источники, по которым можно собрать картину самому:
- Хабр Карьера — калькулятор зарплат и регулярные полугодовые отчёты по российскому IT-рынку с разбивкой по специализациям, грейдам и городам.
- getmatch — вакансии публикуются с указанием вилок, что даёт срез актуальных предложений, а не воспоминаний.
- levels.fyi — данные преимущественно по международному рынку, полезны для понимания структуры компенсации (оклад + акции + бонус) и уровней грейдов.
- Отчёты рекрутинговых агентств и job-бордов — обзоры рынка труда от крупных агентств и HR-платформ выходят регулярно; смотрите на методологию и размер выборки, прежде чем верить медиане.
- Живые люди. Разговор с двумя-тремя знакомыми на схожих позициях даёт более точную картину, чем любой отчёт, потому что учитывает контекст: стек, город, тип компании.
Правило чтения любых данных о зарплатах: смотрите не на среднее, а на распределение и на дату сбора. Рынок меняется в обе стороны, и цифра годичной давности — это исторический факт, а не ориентир.
Риск: честная арифметика
Про риск в стартапах принято говорить либо восторженно, либо катастрофически. Попробуем спокойно.
Что вы действительно рискуете потерять:
- Часть дохода. Разница в окладе за два-три года — вполне измеримая сумма, и она не компенсируется автоматически.
- Время. Два года в компании, которая закрылась, не пропадают полностью, но и не равны двум годам в компании, которая выросла.
- Опыт зрелых процессов. Если вы не видели нормального ревью, регламентированного релиза и нагруженной системы, на собеседовании в крупную компанию это будет заметно.
- Резюме с необъяснимыми пробелами. Три закрывшихся стартапа подряд читаются нейтрально, но потребуют объяснений.
- Здоровье. Режим «ещё две недели поднажмём» имеет свойство длиться год. Выгорание в стартапах — не миф, а самая частая причина ухода.
Что вы действительно приобретаете:
- Широту. Вы увидите весь цикл от разговора с клиентом до дежурства в три часа ночи. Это редко и ценно.
- Скорость роста ответственности. В стартапе можно за полтора года дойти до владения крупной частью системы. В большой компании тот же путь занимает дольше просто из-за очереди.
- Продуктовое мышление. Умение спросить «а зачем» и оценить задачу по влиянию, а не по интересности. Ближайший смежный материал — product-management.
- Сеть контактов. Люди из ранней команды разлетаются по индустрии и остаются вашим кругом на годы. Это недооценённый актив.
- Небольшой шанс на существенную выплату. Именно небольшой — см. расчёт выше.
Как страховать риск, не отказываясь от него:
- Финансовая подушка на несколько месяцев жизни до выхода, а не после.
- Оклад, на который вы согласны, если опцион не выстрелит вообще.
- Никогда не соглашаться на «поработай пока без оформления / с задержкой зарплаты / за долю». Задержка зарплаты — не «трудности роста», а симптом того, что компания уже за краем.
- Всё, что обещано, — письменно. Оффер с описанием опционной программы, а не устная договорённость на кухне.
- Не финансировать компанию собой: не покупать оборудование за свои, не оплачивать сервисы с личной карты «а потом компенсируем».
- Держать резюме и профиль в актуальном состоянии. Это не нелояльность, это гигиена — см. как проходить собеседования.
Кому стартап подходит, а кому нет
Честный разбор без романтики.
Подходит, если: вы переносите неопределённость без тревоги; вам важнее влияние, чем стабильность; вы умеете сами решать, что делать, когда постановка неполная; у вас есть финансовая подушка и нет обязательств, которые не переживут трёх месяцев без дохода; вы получаете удовольствие от широты, а не от глубины.
Не подходит, если: вам нужна предсказуемость дохода и графика; вы растёте через наставничество и структурированную обратную связь; вам важно доводить вещи до состояния «сделано хорошо» — в стартапе большинство вещей остаются в состоянии «работает и ладно»; вы недавно начали и вам нужен кто-то, кто проверит ваш код.
Отдельно про джунов. Расхожий совет «в стартап не ходи первым местом работы» слишком категоричен, но за ним стоит реальная закономерность: в стартапе никто не обязан вас учить. Критерий простой и проверяемый на собеседовании — есть ли в команде хотя бы один инженер, который сильнее вас и у которого будет время смотреть ваш код. Если да, стартап для начинающего может быть лучшим стартом в жизни: объём практики огромный. Если нет — вы за год закрепите собственные ошибки и получите «два года опыта», которые на рынке будут читаться как полгода. Про то, как соотносятся опыт и грейд, — в следующей статье про грейды, а про первые месяцы — в первых 90 днях.
Подделки: что называют стартапом, но им не является
- Аутсорс-студия с самокатами. Признаки: заказчики вместо пользователей, почасовая тарификация, «проекты», а не продукт. Не плохо само по себе — но это аутсорс, и ожидания надо строить другие.
- Компания без денег и без плана их получить. Признаки: не могут назвать runway, «выручка вот-вот пойдёт», зарплата платится нерегулярно. Это не стартап, это личный проект основателя за ваш счёт.
- Корпоративный «инновационный юнит». Внутри большой компании, с корпоративным бюджетом и корпоративными согласованиями. Скорость декларируется, а закупка сервиса занимает два месяца. Бывает продуктивно, но это энтерпрайз в маскировочной раскраске.
- Скейлап, который продаёт себя как ранний стартап. Двести человек, процессы, отделы — но на собеседовании обещают «дух стартапа и влияние на продукт». Влияния там ровно столько же, сколько в любой компании такого размера.
- «Семья». Компания, где вместо условий труда обсуждают ценности и вовлечённость. Проверяется одним вопросом: что происходит с человеком, который в семь вечера закрывает ноутбук.
Как проверять стартап на собеседовании
Собеседование двустороннее — и в стартапе это особенно верно, потому что проверять надо не только команду, но и жизнеспособность компании. Вопросы, которые стоит задать основателю или CTO:
Про деньги и выживание:
- Какой сейчас runway в месяцах и что планируется дальше — раунд, выход на самоокупаемость?
- Сколько всего привлечено и на какой стадии компания?
- Откуда берётся выручка сегодня и сколько платящих клиентов?
- Были ли задержки зарплаты за последний год?
Про опционы: 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