Собственное ИТ-подразделение нужно не тогда, когда компания выросла до какого-то числа сотрудников или оборота. Оно нужно, когда без ваших собственных систем бизнес перестаёт зарабатывать, а изменения в этих системах требуются постоянно, а не раз в год. Пока хотя бы одно из этих условий не выполняется, свой отдел обычно обходится дороже и работает хуже, чем хороший подрядчик.
Ниже разбираю, как понять, что момент наступил, сколько это стоит в сравнении с внешней командой и как не превратить первый шаг в дорогую ошибку.
Почему размер компании не ответ
Частый вопрос звучит так: «У нас 150 человек, пора заводить ИТ?» Число сотрудников здесь почти ничего не говорит. Сеть из десяти магазинов на 300 человек может прекрасно жить на типовой учётной системе, облачной CRM и приходящем администраторе. А логистическая компания на 40 человек, у которой расчёт тарифов, маршруты и личный кабинет клиента сделаны под себя, без своей команды разработки уже через год начнёт буксовать.
Разница не в масштабе, а в том, какую роль играют системы:
| Роль ИТ в бизнесе | Что это значит | Нужен ли свой отдел разработки |
|---|---|---|
| Инфраструктура | Почта, бухгалтерия, типовая CRM, сайт-визитка | Нет. Нужен администратор или сервисный договор |
| Поддержка процессов | Доработки типовых систем, интеграции, отчёты | Чаще нет. Подрядчик плюс внутренний ответственный |
| Часть продукта | Своя логика расчётов, кабинеты клиентов, автоматизация ключевых операций | Да, когда изменения идут непрерывно |
| Сам продукт | Компания продаёт сервис или платформу | Да, с самого начала |
Если ваши системы на первой строке таблицы, вопрос закрыт: отдел разработки не нужен, сколько бы людей у вас ни работало. Самое интересное начинается на третьей строке.
Пять признаков, что момент наступил
Ни один признак по отдельности не решает. Но если совпадают три и больше, вы уже платите за отсутствие своей команды, просто эти расходы не видны в бюджете.
1. Очередь задач не заканчивается
У подрядчика всегда есть список ваших доработок, и он не сокращается. Новые задачи появляются быстрее, чем закрываются старые. Это значит, что потребность в разработке у вас постоянная, а не проектная. Подрядчик хорош для проектов с началом и концом. Для непрерывного потока изменений он дорог, потому что каждый раз заново погружается в контекст.
2. Скорость изменений стала конкурентным фактором
Конкурент запустил новый тариф за неделю, а вам на это нужно два месяца: согласовать смету, дождаться окна у подрядчика, пройти приёмку. Когда скорость изменений в системе напрямую влияет на продажи, ожидание в очереди у внешней команды становится потерянной выручкой.
3. Знания о системе живут у подрядчика
Спросите себя: если ваш подрядчик завтра исчезнет, сколько времени новой команде понадобится, чтобы разобраться в системе? Если ответ «несколько месяцев» и внутри компании никто не может объяснить, как устроены ключевые расчёты, вы в зависимости. Это не обвинение подрядчику. Это риск, который со временем только растёт.
4. Расходы на подрядчика стабильны и высоки
Если вы двенадцать месяцев подряд платите подрядчику примерно одну и ту же крупную сумму, вы фактически уже содержите команду. Только с наценкой агентства и без контроля над тем, кто именно над вами работает.
5. Системы связаны с деньгами напрямую
Сбой в системе останавливает отгрузки, приём заказов или расчёты с клиентами. Каждый час простоя стоит ощутимых денег. В такой ситуации время реакции «в течение рабочего дня по SLA» уже недостаточно, нужны люди, которые знают систему изнутри и отвечают за неё как за своё.
Сколько это стоит: штат против подрядчика
Главное заблуждение руководителей: «Наймём программиста за 250 тысяч, это дешевле, чем платить агентству 600». На деле сравнивать нужно полную стоимость, а не оклад.
Примерная картина на 2026 год для команды, которая поддерживает и развивает корпоративную систему. Цифры ориентировочные, для крупных городов, с учётом налогов и взносов:
| Статья | В месяц, руб. | В год, руб. |
|---|---|---|
| Руководитель направления или ведущий разработчик | 450 000 | 5 400 000 |
| Два разработчика среднего уровня | 700 000 | 8 400 000 |
| Аналитик или владелец продукта | 300 000 | 3 600 000 |
| Серверы, сервисы, лицензии, рабочие места | 100 000 | 1 200 000 |
| Найм, адаптация, текучесть (усреднённо) | 100 000 | 1 200 000 |
| Итого | 1 650 000 | 19 800 000 |
Такая команда даёт около 450-500 часов продуктивной работы в месяц. Это не 4 × 168 часов: отпуска, больничные, встречи и обучение съедают свою долю.
Теперь сравним с подрядчиком по ставке 3 000-4 000 рублей за час:
| Объём работ в месяц | Подрядчик, руб. | Своя команда, руб. | Что выгоднее |
|---|---|---|---|
| 100 часов | 300 000 - 400 000 | 1 650 000 | Подрядчик, с большим отрывом |
| 250 часов | 750 000 - 1 000 000 | 1 650 000 | Подрядчик |
| 450 часов | 1 350 000 - 1 800 000 | 1 650 000 | Примерно паритет |
| 600 часов и больше | от 1 800 000 | нужна команда больше | Своя команда при росте |
Вывод из таблицы простой: если ваша стабильная потребность меньше 300-400 часов разработки в месяц, свой отдел финансово не оправдан. Точка безубыточности где-то в районе 400-500 часов, причём стабильных, а не пиковых.
Но чистая арифметика не учитывает две вещи, которые часто перевешивают:
- Своя команда со временем работает быстрее. Через полгода она знает и систему, и бизнес. Задача, на которую подрядчик тратит 20 часов с погружением, у своих занимает 8.
- Подрядчик снимает с вас риски найма. Ушёл ключевой разработчик подрядчика - это его проблема. Ушёл ваш - это ваша проблема на 2-3 месяца поиска и адаптации.
Поэтому решение никогда не принимается только по таблице. Но если таблица говорит «подрядчик выгоднее в четыре раза», никакие качественные доводы это не перекроют.
Почему один программист хуже, чем никого
Самая частая ошибка: компания решает «завести своё ИТ» и нанимает одного разработчика. Выглядит как разумный осторожный шаг. На практике это худший вариант из возможных.
Что происходит дальше:
- Один человек отвечает за всё: разработку, поддержку, серверы, ответы на вопросы сотрудников. Развитие останавливается, потому что его съедает текучка.
- Никто не проверяет его решения. Руководитель без технической подготовки не может оценить качество работы, а второго специалиста рядом нет.
- Вся система оказывается в голове одного человека. Через два года он уходит, и вы в той же зависимости, что была от подрядчика, только хуже: у подрядчика хотя бы была команда и документация.
- Хорошие разработчики редко идут работать в одиночку. Им нужен рост, обмен опытом, коллеги. Поэтому на такую позицию часто приходят не лучшие.
Минимально жизнеспособная команда разработки - это два разработчика и человек, который отвечает за постановку задач со стороны бизнеса. Меньше - это не отдел, а риск.
Как переходить: три шага вместо одного прыжка
Создание ИТ-подразделения лучше растягивать во времени. Резкий разрыв с подрядчиком и найм команды с нуля почти всегда заканчивается потерей полугода.
Шаг 1. Внутренний владелец систем
Первым нанимается не программист, а человек, который понимает и бизнес, и системы: аналитик, менеджер продукта, руководитель по цифровизации. Он работает с подрядчиком со стороны компании: формулирует задачи, принимает результат, ведёт документацию, держит знания внутри.
Этот шаг оправдан уже при расходах на подрядчика от 300-400 тысяч в месяц. Он сразу снижает потери на неправильно понятых задачах и переделках, а главное, знания о системе начинают накапливаться у вас.
Шаг 2. Смешанная команда
Когда объём работ стабильно приближается к точке безубыточности, в компанию приходят первые разработчики. Подрядчик при этом не уходит, а передаёт им систему постепенно: совместная работа, ревью, общая документация. Хорошо, если в договоре с подрядчиком такой сценарий предусмотрен заранее.
На этом этапе важно, чтобы права на код, доступы к серверам и учётные записи сервисов были оформлены на компанию. Если они до сих пор на подрядчике, это первое, что нужно исправить, независимо от планов на отдел.
Шаг 3. Своя команда с внешней поддержкой
Основную работу ведут свои люди. Подрядчики привлекаются точечно: на пиковые проекты, редкие компетенции, аудит. Это нормальная зрелая модель, и полностью отказываться от внешних специалистов не нужно.
| Этап | Кто в компании | Роль подрядчика | Когда переходить дальше |
|---|---|---|---|
| 1 | Владелец систем | Вся разработка | Объём стабильно выше 400 часов в месяц |
| 2 | Владелец систем и 2 разработчика | Разработка и передача знаний | Своя команда закрывает текучку без подрядчика |
| 3 | Команда 3-6 человек | Пики и экспертиза | Растите по потребности |
Когда свой отдел не нужен даже большой компании
Есть ситуации, когда собственная разработка вредна при любом масштабе:
- Ваши процессы типовые. Если отраслевое решение покрывает 90% потребностей, разработка своего - это деньги на поддержку того, что можно купить.
- Нужна одна крупная система, а потом поддержка. Внедрение на год силами подрядчика и затем небольшой договор на сопровождение дешевле, чем нанимать команду, которой через год будет нечего делать.
- Нет человека, который будет управлять ИТ. Команда разработки без руководителя со стороны бизнеса делает то, что интересно ей, а не то, что нужно компании. Если вы не готовы выделить на это сильного управленца, лучше остаться с подрядчиком.
Короткий тест для собственника
Ответьте на пять вопросов честно:
| Вопрос | Да / Нет |
|---|---|
| Без наших собственных систем бизнес остановится или потеряет заметную выручку? | |
| Доработки нужны каждый месяц уже больше года? | |
| Мы платим подрядчикам больше 1-1,5 млн рублей в месяц стабильно? | |
| Внутри компании никто не может объяснить, как устроены ключевые расчёты в системе? | |
| Скорость изменений в системах влияет на продажи или конкурентоспособность? |
Ноль или одно «да» - свой отдел не нужен, работайте с подрядчиком. Два-три «да» - нанимайте внутреннего владельца систем и готовьте переход. Четыре-пять «да» - вы опаздываете, и каждый месяц промедления увеличивает зависимость и стоимость перехода.
Своё ИТ-подразделение - это не признак статуса и не следствие роста. Это ответ на конкретную ситуацию: системы стали частью того, как вы зарабатываете, и меняются непрерывно. Пока этого нет, лучшая стратегия - хороший подрядчик и человек внутри, который его контролирует.