Перейти к основному содержимому

Модели IT-бизнеса

Связь с другими статьями

Договор и приёмка — следующая статья. Карьера в IT — раздел 1-26. Старт проекта — 7.17.


Почему модель работодателя важна

От модели бизнеса зависят:

  • кто ставит задачи — свой PO, PM заказчика, менеджер интегратора;
  • кто владеет кодом — компания, клиент, open source;
  • как оценивают успех — метрики продукта, акт приёмки, утилизация часов;
  • что ждут на испытательном сроке — первый PR, сдача этапа, выход на проект клиента.

Один и тот же заголовок "разработчик" в продукте, интеграторе и аутстаффе означает разный контекст. Junior, который не понимает модель, часто разочаровывается: "я думал, буду делать продукт, а оказалось — заказная разработка по ТЗ".

Четыре базовые модели


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

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

Характеристики

АспектКак обычно устроено
ЦельРост метрик продукта: MAU, retention, revenue
ПриоритетыPO/PM, roadmap, гипотезы
ГоризонтГоды, несколько релизных циклов
ПроцессScrum, Kanban, product discovery
КодОбычно остаётся у компании
Метрики успехаDAU, conversion, NPS, churn

Плюсы для разработчика

  • влияние на архитектуру и стек (в разумных пределах);
  • видимый результат для пользователей;
  • долгий горизонт — можно углубиться в домен;
  • часто сильнее инженерная культура (CI, review).

Минусы и риски

  • feature factory — много фич без проверки гипотез (продуктовая аналитика);
  • давление метрик и дедлайнов релиза;
  • в крупном продукте — узкая зона ответственности (только один сервис).

Пример

Компания делает CRM для малого бизнеса. Команда из 12 человек: 6 backend, 3 frontend, 1 QA, 1 PO, 1 PM. Релизы каждые 2 недели. Задачи из product backlog, приоритет — отток клиентов после онбординга.


Интегратор и заказная разработка

Интегратор или студия заказной разработки — компания, которая строит систему под конкретного заказчика по договору.

Заказчик платит за результат по ТЗ (fixed price) или по модели T&M (time and material — оплата за время).

Характеристики

АспектКак обычно устроено
ЦельСдача этапа, акт, формальная приёмка
ДокументыТЗ, ПМИ, материалы по ГОСТ
ПроцессГибрид waterfall в договоре и Scrum внутри этапа
ЗаказчикЧасто формальный; решения через PM и юристов
IPЧасто переходит заказчику по договору

Плюсы для разработчика

  • разнообразие доменов и проектов;
  • опыт работы с госконтрактами, ERP, интеграциями;
  • чёткие критерии "сделано" — AC, ПМИ.

Минусы и риски

  • scope creep без change request — переработки "бесплатно";
  • меньше влияния на продуктовые решения;
  • смена проекта после сдачи — context switch.

Fixed price и T&M внутри интегратора

МодельДля разработчика
Fixed priceScope жёсткий; "ещё кнопка" = CR и согласование
T&MГибче scope; важен учёт часов, прозрачность в трекере

Подробнее — договор и приёмка.

Пример

Интегратор внедряет портал для регионального министерства. ТЗ на 200 страниц, этапы по договору, приёмка по ПМИ. Внутри команда работает спринтами по 2 недели, но акт подписывают раз в квартал.


Аутстафф (outstaff)

Компания-работодатель предоставляет специалистов в команду клиента. Вы числитесь у одной фирмы, а работаете в их Jira, их Git, их процессах — физически или удалённо.

Характеристики

АспектКак обычно устроено
КлиентПродуктовая компания, банк, госкорпорация
МенеджментЛиния может быть двойная: у клиента и у аутстаффера
Оплата клиентомЗа часы или месяц специалиста
Стек и архитектураРешает клиент
СрокКонтракт на 3–12+ месяцев, продление

Плюсы

  • опыт крупного продукта или госпроекта "изнутри";
  • погружение в зрелые процессы (если у клиента они есть);
  • иногда выше ставка, чем в малом интеграторе.

Минусы

  • меньше влияния на архитектуру, стек, приоритеты;
  • риск "вас первым снимут" при сокращении бюджета клиента;
  • двойная отчётность — timesheet аутстафферу и статус клиенту.

Линия менеджмента — критичный вопрос

Перед выходом на проект выясните:

ВопросНазначение
Кто ставит задачи на день?Тимлид клиента или ваш PM
Кто оценивает performance?Влияет на бонусы и продление
Кто решает конфликт приоритетов?Эскалация
Можно ли участвовать в архитектурных решениях?Рост карьеры
Типичная ловушка

"Вы в команде банка" на собеседовании, а на деле — изолированная задача без доступа к prod и без ментора. Уточняйте состав команды, процесс review и длительность контракта.

Пример

Разработчик нанят компанией OutStaff LLC, выведен в команду финтех-продукта на 6 месяцев. Daily с командой клиента, PR в их GitLab, performance review раз в квартал — у клиента и дублирующий sync с OutStaff LLC.


Аутсорс (outsourcing)

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

Характеристики

АспектКак обычно устроено
ФокусПоставка по контракту, milestone
ОплатаЧасто fixed price
IPОбычно переходит заказчику (7.07)
КомандаВнутренняя у аутсорсера; клиент видит PM и демо
ПроцессScrum/Kanban внутри, waterfall наружу

Плюсы

  • команда под ключ — PM, QA, dev;
  • чёткие milestone и demo для клиента.

Минусы

  • жёсткие дедлайны при неполных требованиях;
  • crunch перед сдачей этапа;
  • после сдачи проекта — ротация на другой контракт.

Аутстафф и аутсорс — сравнение

АутстаффАутсорс
Покупает клиентЧеловеко-часы / специалистаРезультат
Где вы работаетеПроцессы клиентаПроцессы аутсорсера
Видимость для клиентаВы в их чатахЧасто через PM
Риск scopeМеньше, если T&MВыше при fixed price

Другие типы работодателей

Консалтинг и аудит

Короткие проекты: оценка архитектуры, миграция, аудит ИБ. Много презентаций и документов, меньше долгого сопровождения кода.

Вендор ПО (SAP, 1С, Microsoft partner)

Внедрение ERP: fit-gap, настройка, кастомизация, обучение. TCO на годы. Отдельный карьерный трек — функциональный консультант, разработчик расширений.

Стартап

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

Госсектор и корпорации с in-house IT

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


Внедрение ERP

Отдельный класс — внедрение ERP:

  • fit-gap — что покрывает стандарт, что кастомизировать;
  • обучение пользователей и change management;
  • TCO (total cost of ownership) на годы — лицензии, поддержка, доработки.

Для разработчика ERP часто означает: платформа 1С, SAP ABAP, конфигурация + код расширений, редкие релизы по окнам.


Сравнительная таблица для соискателя

КритерийПродуктИнтеграторАутстаффАутсорс
Влияние на продуктВысокоеСреднееНизкоеСреднее внутри команды
Стабильность scopeМеняется частоПо CRУ клиентаПо контракту
ДокументооборотУмеренныйВысокийЗависит от клиентаВысокий к сдаче
Рост в архитектуруДаЗависит от проектаРедкоЗависит от роли
Типичный процессAgileГибридКак у клиентаAgile внутри

Выбор работодателя для junior

Оценивайте не только бренд и зарплату:

Чек-лист собеседования

  • Есть ли наставник (buddy) первые 1–3 месяца?
  • Описан ли процесс (методология)?
  • Code review обязателен или формальность?
  • Стек актуален для рынка?
  • Домен интересен или хотя бы переносим (fintech, e-commerce)?
  • Понятна модель — продукт, проект, аутстафф?
  • Time to first PR — ориентир ≤ 2 недели?

Куда идти junior без опыта

СитуацияРазумный выбор
Нужен ментор и процессПродукт или крупный интегратор с academy
Нужен опыт "большого" банка/техаАутстафф в сильную команду клиента
Нужно быстро набить портфолио проектовИнтегратор / аутсорс (с оговоркой на качество)
Есть сильный pet-projectСтартап или продукт

См. карьера в IT, советы для новичка.


Как модель влияет на ваш день

Продукт — типичная неделя

  • Планирование спринта, refinement backlog.
  • Разработка фичи с A/B-тестом.
  • Demo на review, метрики через неделю.

Интегратор — типичная неделя

  • Задачи из ТЗ, привязка к пункту спецификации.
  • Подготовка к demo этапа для заказчика.
  • QA по чек-листу ПМИ.

Аутстафф — типичная неделя

  • Daily с командой клиента.
  • PR по их стандартам.
  • Раз в месяц — sync с HR/PM аутстаффера.

Связь с проектом

Модель заказчика определяет:


FAQ

Аутстафф — это хуже продукта?

Не обязательно. Зависит от клиента: сильная команда банка может дать больше роста, чем слабый продукт без review.

Можно ли перейти из интегратора в продукт?

Да, частый путь. Важно показать ownership, тесты, понимание продукта в резюме и на собеседовании.

Как понять модель по вакансии?

Ищите: "выведем на проект клиента" (аутстафф), "разработка под ключ" (аутсорс/интегратор), "наш продукт", "roadmap", "MAU" (продукт).

In-house в банке — это продукт?

Обычно да, internal product. Но процессы могут быть тяжелее, чем в SaaS-стартапе.

ERP-интегратор — это интегратор?

Да, с уклоном в платформу и длинный lifecycle.


Российский рынок: нюансы моделей

Продукт с иностранным капиталом и локализация

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

  • отдельное юрлицо и compliance;
  • ограничения на стек и облака;
  • hybrid remote внутри РФ.

Госзаказ через интегратора

Заказчик — государственный орган; исполнитель — интегратор с лицензиями и опытом 44-ФЗ. Разработчик видит ТЗ, ПМИ, этапы (договор). Процесс часто waterfall наружу, agile внутри.

Аутстафф в банк или телеком

Популярный путь для middle+: высокие требования к ИБ, background check, иногда закрытый контур без интернета на рабочей машине. Модель аутстаффа, продукт — клиента.

Стартапы и студии

Малые продуктовые команды 5–15 человек часто совмещают продукт + заказную разработку для cash flow. Уточняйте на собеседовании долю: 80% свой продукт или 80% клиентские проекты.


Вопросы на собеседовании про модель

Вопрос работодателюЧто выясняете
Кто ваш клиент — рынок или заказчики?Продукт vs интегратор
Код в open source или под NDA?Портфолио
Как устроен performance review?Аутстафф: двойная линия
Сколько проектов параллельно?Context switch
Есть ли on-call и runbook?Операционная зрелость

См. также


Содержание