Какие бывают проекты: продукт, аутсорс, аутстафф, внутренняя разработка, госсектор

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

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

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

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

Пять осей, которые объясняют почти все различия

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

1. Кто платит за ваш код. Пользователь напрямую (подписка, покупка), рекламодатель, заказчик по договору, или собственная компания из своего бюджета. От этого зависит, что считается успехом и насколько быстро приходит обратная связь.

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

3. Кто несёт риск ошибки. Если сорвали срок — компания теряет долю рынка, или платит неустойку по договору? Если баг в проде — потеряли конверсию, или нарушили условия SLA с финансовыми санкциями? Риск определяет строгость процессов гораздо сильнее, чем чья-либо любовь к бюрократии.

4. Горизонт жизни кода. Вы будете сопровождать это три года или сдадите через три месяца и больше никогда не откроете? От горизонта зависит рациональная стратегия качества: в некоторых типах проектов «написать быстро и грязно» — не халтура, а верное инженерное решение.

5. Кто принимает продуктовые решения. Вы участвуете в решении «что делать», или получаете готовый список требований? Это главный источник профессионального удовлетворения или выгорания — в зависимости от того, что вам нужно.

Обратите внимание: на карте нет оси «интересные технологии». Она есть везде и нигде — легаси на Java 8 встречается в модном стартапе, а Rust и Kubernetes бывают в госконторе. Технологический стек — плохой предсказатель того, как будет выглядеть ваш рабочий день.

Как течёт денежный контур

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

Три следствия, которые стоит держать в голове весь оставшийся текст.

В продукте петля обратной связи короткая: вы выкатили — метрика дёрнулась — вы узнали, что были неправы. Именно поэтому в продуктовых компаниях так носятся с аналитикой и экспериментами (подробно — в треке product-management).

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

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

Продуктовая компания

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

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

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

Разновидности, которые ощущаются по-разному:

• B2C (массовый пользователь): много трафика, много данных, эксперименты имеют статистическую силу, любой баг видят тысячи людей за минуты. Нагрузка и производительность — реальные проблемы, а не упражнения.
• B2B SaaS: пользователей мало, каждый дорог, вместо A/B-тестов — разговоры с клиентами. Появляются корпоративные требования: SSO, аудит, экспорт, кастомные роли. Клиент может позвонить вашему CEO из-за бага.
• Финтех, медтех, всё регулируемое: продуктовая свобода плюс регуляторные ограничения. Изменения в расчёте комиссии — не просто фича, а зона ответственности комплаенса.
• Инфраструктурные и девелоперские продукты: пользователи — такие же инженеры, требования к качеству документации и API высокие, обратная связь честная и злая.

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

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

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

Аутсорс: разработка на заказ

Что это. Ваша компания продаёт другой компании разработку. Есть договор, есть предмет, есть срок и цена. Результат передаётся заказчику.

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

Три формы контракта, и почему это ваша проблема тоже

Fixed price (фиксированная цена). Заказчик платит фиксированную сумму за оговорённый объём. Все риски оценки — на подрядчике. Отсюда всё остальное: подробное ТЗ до начала работ, жёсткий контроль изменений (любое изменение — дополнительное соглашение), давление на сроки в конце, экономия на всём, что не проверяется при приёмке. Тесты и рефакторинг в fixed price — первое, что режут, потому что за них никто не платит отдельно.

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

Time & Materials (по факту затрат). Заказчик оплачивает потраченное время по ставке. Риск оценки — на заказчике, поэтому он требует прозрачности: таймшиты, регулярные демо, отчёты. Атмосфера здоровее: изменение требований не катастрофа, а нормальный ход событий. Но появляется учёт времени, и он может быть довольно занудным.

Dedicated team (выделенная команда). Заказчик оплачивает команду целиком на длительный срок. Формально это ещё аутсорс, по ощущениям — почти продукт: та же команда, тот же домен, годы работы. Лучший вариант аутсорса для роста, если заказчик адекватный.

Жизненный цикл аутсорс-проекта

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

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

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

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

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

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

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

Аутстафф: вы работаете там, а зарплату платят здесь

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

Формально это разновидность аутсорса, но по ощущениям — отдельный мир, потому что у вас появляется двойное подчинение.

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

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

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

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

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

Внутренняя разработка: IT внутри не-IT компании

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

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

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

Ландшафт систем — зоопарк: что-то куплено (SAP, 1С, Salesforce), что-то написано десять лет назад ушедшим подрядчиком, что-то пишете вы. Значительная часть работы — интеграции: заставить пять систем согласованно рассказывать одну и ту же правду. Это недооценённо сложная инженерная задача, и знание DDD здесь окупается буквально.

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

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

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

Госсектор и регулируемые отрасли

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

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

Что отличается на практике:

• Закупки и конкурсы. Работа начинается не с обсуждения, а с конкурсной процедуры (в России — 44-ФЗ для госзаказчиков и 223-ФЗ для госкомпаний). Отсюда — фиксированные цена и срок, зафиксированные до того, как кто-то посмотрел в код. Изменить условия в процессе тяжело даже при обоюдном желании.
• Документация по стандартам. Техническое задание и комплект документов часто оформляются по ГОСТ 34 (автоматизированные системы) или ГОСТ 19 (программная документация): ТЗ, эскизный и технический проект, пояснительная записка, руководство пользователя, руководство администратора, программа и методика испытаний. Объём документации может превышать объём кода, и это не шутка.
• Приёмочные испытания. Не «QA потестировал», а формализованная процедура по утверждённой программе и методике, с протоколом и подписями комиссии. Каждый пункт методики — проверяемое утверждение.
• Требования по защите информации. Если система обрабатывает персональные данные или относится к КИИ, появляются требования регуляторов, аттестация объекта информатизации, сертифицированные средства защиты. Практический эффект для разработчика: список разрешённых библиотек и версий может быть ограничен, а обновление зависимости — отдельная процедура.
• Импортозамещение. Требование использовать ПО из реестра отечественного ПО и российские СУБД (Postgres Pro, Ред База данных) и ОС (Astra Linux, РЕД ОС). Это влияет на архитектурные решения напрямую.
• Контуры без интернета. Закрытый контур означает: нет прямого доступа к публичным репозиториям пакетов, свой внутренний зеркальный репозиторий, перенос артефактов по регламенту. CI выглядит иначе, чем вы привыкли.

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

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

Про «там всё плохо с инженерной культурой» — это миф ровно в той же мере, в какой миф «в стартапе всегда современный стек». Есть госпроекты с нормальным CI, код-ревью и автотестами, и есть продуктовые компании, где деплой — это копирование файлов по SSH. Проверяйте конкретную команду, а не отрасль.

Ещё несколько типов, которые вы встретите

Агентство или студия. Сайты, лендинги, мобильные приложения под ключ, дизайн-ориентированные проекты. Проекты короткие (недели), их много, качество кода вторично по отношению к скорости и внешнему виду. Отличная школа скорости и ужасная школа инженерии. Хорошо в самом начале пути, вредно надолго.

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

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

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

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

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

Как тип проекта меняет ваш рабочий день по фазам SDLC

Мы прошли по фазам в статьях 01–07 трека. Вот честная таблица, как эти фазы выглядят в разных типах.

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

Релизный ритм: одна и та же фича в трёх мирах

Наглядно: путь одной средней фичи от «решили делать» до «работает у пользователей».

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

Деньги: как тип проекта влияет на структуру вознаграждения

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

Из чего вообще складывается доход:

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

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

Как исследовать рынок самому — метод, а не чужое мнение:

1. Соберите факты из открытых источников. Для российского рынка — Хабр Карьера (регулярные зарплатные отчёты с разбивкой по грейдам, специализациям и регионам), getmatch (вакансии с указанными вилками — это редкость и потому ценно), зарплатные обзоры рекрутинговых агентств. Для международного рынка — levels.fyi (данные по уровням и компонентам пакета) и Stack Overflow Developer Survey.
2. Смотрите на распределение, а не на среднее. «Средняя зарплата разработчика» — бесполезное число; вам нужны медиана и границы для вашего грейда, стека и города.
3. Собирайте живые данные: вакансии с вилками за последний месяц, разговоры с рекрутерами (спрашивайте вилку в первом же контакте — это нормально), сообщества.
4. Проверяйте себя интервью. Один-два процесса в год, даже без намерения менять работу, дают самую честную калибровку.
5. Считайте пакет целиком и в год, а не оклад в месяц.

Все числа, которые вы встретите в статьях и отчётах, — снимок конкретного момента конкретного рынка. Метод расчёта переносится, цифры — нет. Подробно — в статьях Зарплата и своя цена и Переговоры об оффере.

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

Вакансии редко врут прямо, но регулярно недоговаривают. Вот вопросы, которые дают максимум информации за минимум времени, и что означают ответы.

«Кто ваш пользователь и как вы понимаете, что фича удалась?» Внятный ответ с метрикой — продукт. «Заказчик принял этап» — аутсорс. «Пользователи в соседнем департаменте перестали жаловаться» — внутренняя разработка. Пауза и растерянность — команда далеко от смысла своей работы, и это стоит уточнить.

«В чей репозиторий я буду коммитить и чья это интеллектуальная собственность?» Прямо вскрывает аутстафф и аутсорс. Заодно узнаете, сможете ли вы что-то рассказывать о проекте потом.

«Как часто вы выкатываете в прод и что нужно, чтобы выкатить?» Лучший единственный вопрос про зрелость инженерной культуры. Ответ «несколько раз в день, автоматически, откат в одну кнопку» и ответ «раз в квартал, ночью, с согласованием» описывают две разные жизни.

«Что происходит, когда оценка не сходится со сроком?» Здоровый ответ описывает механизм: режем объём, двигаем срок, обсуждаем с заказчиком. Ответ «мы стараемся укладываться» — это либо переработки, либо срезанное качество.

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

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

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

Карьера сквозь типы проектов

Никакой единственно верной траектории нет, но есть повторяющиеся сюжеты — с честными плюсами и минусами каждого.

Практические выводы из этой картинки.

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

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

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

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

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

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

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

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

Ошибка пятая: судить по одному собеседованию. Вам показывают лучшую версию. Спросите, можно ли поговорить с будущим коллегой-разработчиком (не с лидом) десять минут. Отказ информативен.

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

Мини-итог

• Тип проекта определяется не отраслью и не стеком, а тем, кто платит, кто владеет кодом, кто несёт риск и как долго вы живёте с последствиями.
• Продукт даёт короткую петлю обратной связи и влияние на решения, но и собственное вечное легаси.
• Аутсорс даёт широту опыта; его качество определяется типом контракта — fixed price и T&M создают разные миры внутри одной компании.
• Аутстафф — рабочий способ войти в большой проект, но у него есть структурный дефект: те, кто видит вашу работу, не решают про вашу зарплату. Компенсируется только вашей дисциплиной в сборе обратной связи.
• Внутренняя разработка даёт глубину домена и стабильность ценой темпа и риска получить непереносимый опыт.
• Госсектор и регулируемые отрасли обменивают скорость на проверяемость — и это осознанный обмен, а не глупость.
• Строгость процесса почти всегда объясняется стоимостью ошибки и текстом договора. Прежде чем осуждать процесс, найдите риск, который он закрывает.
• Про деньги: изучайте структуру вознаграждения и метод исследования рынка, а не чужие цифры. Открытые источники — Хабр Карьера, getmatch, levels.fyi, зарплатные обзоры агентств; смотрите на медиану и разброс для вашего грейда, а не на среднее.

Источники

• Хабр Карьера — зарплаты в IT — регулярные отчёты по российскому рынку с разбивкой по грейдам и специализациям.
• getmatch — площадка с обязательным указанием вилок в вакансиях.
• levels.fyi — данные по уровням и составу компенсации в международных компаниях.
• Stack Overflow Developer Survey — ежегодный срез по технологиям, форматам занятости и оплате.
• dora.dev — исследования DevOps-практик; полезны, чтобы отличать зрелость процессов от риторики о ней.
• Frederick Brooks, «The Mythical Man-Month» — про природу проектов с фиксированным сроком; не устарело.
• Tom DeMarco, Timothy Lister, «Peopleware» — про то, как организационная среда влияет на продуктивность сильнее, чем инструменты.
• Портал государственных закупок zakupki.gov.ru — если хотите увидеть, как реально выглядит ТЗ госзаказчика, откройте несколько закупок по теме «разработка информационной системы».
• Единый реестр российского ПО — практический контекст требований импортозамещения.
• Материалы портала: Управление проектами, Продуктовый менеджмент, Модели разработки и Предварительная оценка IT-проектов.

Что дальше

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