GreenCore 
Тендеры и лиды
Информация
На российском IT-рынке цена подрядчика долгое время оставалась одним из самых понятных критериев выбора. Есть ставка разработчика, есть оценка проекта, есть несколько коммерческих предложений — дальше кажется логичным выбрать вариант с меньшей стоимостью. Проблема в том, что в разработке программного обеспечения цена договора и стоимость проекта — далеко не одно и то же. Можно заплатить меньше за разработку и существенно больше за исправление архитектурных решений, перенос сроков, переработку функциональности, сопровождение и дальнейшее развитие системы.
Мы считаем, что ошибка здесь начинается с неправильного объекта сравнения. Заказчик сравнивает стоимость производства кода, хотя на самом деле покупает способность подрядчика управляемо изменить IT-систему и получить бизнес-результат. Если подрядчик выставляет более низкую ставку, но создаёт больше технического долга, требует постоянного контроля или закладывает архитектуру, которую сложно развивать, экономия на старте быстро перестаёт быть экономией.
Для российского рынка эта тема сейчас особенно актуальна. Бизнес одновременно находится под давлением ограниченных бюджетов, импортозамещения, необходимости развивать существующие системы и требований к экономической эффективности. По данным Б1, объём российского рынка IT-услуг вырос до 638 млрд рублей в 2024 году, а на заказную разработку пришлось 24% рынка IT-услуг. То есть речь идёт уже не о нишевой услуге, а о значительном сегменте корпоративных расходов. При этом CNews отмечает, что в 2025–2026 годах заказчики всё чаще смотрят не на скорость замены систем как таковую, а на экономическую эффективность, устойчивость и гибкость архитектуры.
Самая очевидная ловушка выглядит так: подрядчик А предлагает разработчика за 2 000 рублей в час, подрядчик Б — за 3 000. На уровне таблицы закупки первый вариант дешевле на 33%. Но из этой таблицы совершенно не видно, сколько часов потребуется каждому подрядчику, сколько времени займёт согласование решений, сколько дефектов возникнет после релиза и насколько дорого будет внести следующее изменение.
Поэтому корректнее считать не Hourly Rate, а совокупную стоимость результата. Условно её можно представить как сумму разработки, управления, исправления дефектов, инфраструктуры, поддержки, последующих изменений и стоимости задержки бизнес-эффекта. Последний компонент часто вообще не попадает в коммерческое предложение, хотя именно он способен сделать дешёвый проект самым дорогим.
Предположим, два подрядчика оценивают задачу в 10 млн и 7 млн рублей. Первый предлагает более дорогую архитектуру, закладывает полноценную аналитику, автоматизированное тестирование и работу архитектора. Второй сокращает подготовительный этап, быстрее переходит к разработке и предлагает более низкую стоимость. Если первый проект запускается через шесть месяцев, а второй — через четыре, на бумаге второй действительно дешевле. Но если после запуска каждое изменение требует нескольких недель из-за архитектурных ограничений, первоначальная разница в три миллиона рублей может исчезнуть уже на этапе развития.
Российский рынок заказной разработки сейчас хорошо показывает, почему ставка перестаёт быть достаточным ориентиром. По данным CNewsMarket, средняя стоимость дня работы разработчика, выставляемая заказчикам IT-аутсорсерами, в 2025 году снизилась с 29,6 тыс. до 24,9 тыс. рублей, то есть на 15,7%. Снижение также произошло по DevOps и руководителям проектов. CNews связывает эту динамику с усилением конкуренции и изменением экономики проектов. Само по себе снижение ставки не означает пропорционального снижения стоимости качественного результата: рынок может становиться дешевле по единице ресурса одновременно с ростом требований к управляемости и ответственности исполнителя.
Более того, Б1 в исследовании аутсорсинга 2026 года фиксирует, что главными причинами использования внешних подрядчиков респонденты называют экономическую эффективность — 70% — и доступ к знаниям и опыту — 62%. Это важное изменение восприятия аутсорсинга: бизнес покупает не просто дополнительные руки, а определённую компетенцию и способ её применения.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13768 тендеров
проведено за восемь лет работы нашего сайта.
Наиболее опасные последствия дешёвой разработки редко появляются в первой смете. Они появляются через несколько месяцев, когда продукт уже работает, а команда пытается его изменить.
Написать функциональность можно относительно быстро. Намного сложнее сделать так, чтобы через год добавление новой функции не требовало переписывать несколько существующих компонентов. Именно здесь появляется технический долг. Он не всегда означает плохой код: иногда это осознанный компромисс ради скорости. Проблема возникает тогда, когда компромиссы не фиксируются, не оцениваются и постепенно превращаются в постоянную стоимость изменений.
Для российского бизнеса это уже не абстрактная инженерная проблема. По исследованию OCS, опубликованному CNews 2 октября 2026 года, у 25% крупных российских компаний технический долг затрагивает более половины инфраструктурного программного обеспечения. У каждой двенадцатой организации проблемы накопились более чем в 75% инфраструктурных платформ. При этом 35% крупных компаний планируют бюджет преимущественно на замену отдельных платформ, тогда как масштабное обновление инфраструктуры входит в планы только 11%. Исследование проводилось среди 202 корпоративных заказчиков — IT-директоров и их заместителей — в апреле–мае 2026 года.
Это особенно показательно для оценки подрядчиков. Если бизнес сегодня выбирает исполнителя исключительно по минимальной стоимости, он фактически может покупать ещё один источник будущего технического долга в момент, когда существующий долг и так становится системной проблемой.
Есть и другая скрытая стоимость — зависимость от конкретной команды. Если подрядчик создаёт решение так, что только его собственные специалисты способны его сопровождать, низкая цена первой фазы превращается в высокую стоимость дальнейшей эксплуатации. Заказчику приходится либо постоянно продлевать договор, либо тратить значительные ресурсы на передачу системы другой команде.
Поэтому мы считаем хорошим признаком зрелого подрядчика не обещание сделать «максимально быстро и дёшево», а готовность заранее говорить о будущей стоимости изменений. Что произойдёт, если количество пользователей вырастет в пять раз? Сколько будет стоить подключение новой системы? Можно ли заменить отдельный компонент без переписывания всей платформы? Как будет организована передача проекта внутренней команде? Где находятся потенциальные точки архитектурной связанности?
Такие вопросы редко влияют на стоимость первого коммерческого предложения в пользу её уменьшения. Зато они позволяют понять, какой будет экономика системы через два-три года.
В подходе GreenCore отправной точкой является не стоимость отдельного специалиста и даже не технология сама по себе, а контекст системы, которую предстоит построить или изменить. Публичное позиционирование компании также строится вокруг погружения в бизнес-задачу, архитектуры, интеграций, масштабируемости и ответственности за результат, а не за количество потраченных часов.
Для нас это означает довольно простой принцип: прежде чем оптимизировать стоимость разработки, нужно определить стоимость неправильного технического решения. Если архитектура изначально ограничивает развитие продукта, снижение бюджета первой фазы может быть экономически бессмысленным.
Поэтому CTO должен смотреть на проект как минимум в трёх горизонтах.
Первый — запуск: сколько ресурсов необходимо, чтобы вывести решение в промышленную эксплуатацию.
Второй — эксплуатация: сколько будет стоить поддерживать его стабильность, безопасность и производительность.
Третий — развитие: сколько времени и денег потребуется на изменение системы через год, два или пять лет.
При таком подходе вполне может оказаться, что более дорогой подрядчик на старте экономически рациональнее, если его архитектура уменьшает будущую стоимость изменений. Но здесь важно не впадать и в противоположную крайность: высокая цена сама по себе не является признаком высокого качества. Дорогой подрядчик тоже может создавать технический долг, избыточно усложнять архитектуру или не обеспечивать необходимую скорость.
Именно поэтому мы не считаем правильным использовать простую формулу «дороже = качественнее». Сравнивать необходимо не ставки, а модель создания результата. Сколько времени занимает аналитика? Кто принимает архитектурные решения? Как контролируется качество? Как устроено тестирование? Что происходит при изменении требований? Как измеряется производительность? Как фиксируются технические риски? Как передаётся проект? Какие зависимости создаются между системами?
Это хорошо согласуется с тем, как меняется сама корпоративная разработка в России. Исследование LDM, основанное на 50 интервью и ответах более 100 специалистов, преимущественно из финансового сектора, ритейла и промышленности, показывает: ключевой запрос крупных компаний — не просто увеличение скорости разработки, а управляемый time-to-market без роста технического долга. При этом исследование отдельно подчёркивает связь архитектуры со скоростью поставки изменений.
То есть для CTO экономия — это не обязательно уменьшение бюджета разработки. Иногда экономия заключается в том, чтобы сегодня потратить немного больше и не платить гораздо больше за каждое следующее изменение.
Мы считаем, что сравнивать коммерческие предложения имеет смысл только после приведения их к единой модели (об этом вскользь упомянули тут). В неё стоит включить стоимость аналитики и проектирования, разработки, QA, DevOps, управления, инфраструктуры, поддержки, исправления дефектов, развития и передачи системы. Если один подрядчик включает часть этих работ в стоимость, а другой показывает их отдельными строками, сравнение исключительно по итоговой сумме будет некорректным.
Следующий уровень — оценка рисков. У каждого проекта есть вероятность изменения требований, задержки интеграций, нехватки компетенций, ухода ключевого специалиста, роста нагрузки или появления новых требований безопасности. Эти риски нельзя полностью перевести в рубли, но их можно хотя бы зафиксировать и понять, какая сторона будет ими управлять.
Отдельно стоит оценивать стоимость задержки. Если новая система должна сократить ручной труд, ускорить продажи или позволить запустить новый цифровой продукт, то месяц задержки имеет экономическое значение. Иногда разница между подрядчиками в 20% стоимости разработки оказывается гораздо менее значимой, чем несколько месяцев разницы в time-to-market.
Наконец, нужно проверить, что именно заказчик получит после окончания работ. Исходный код, документацию, архитектурные схемы, CI/CD, тесты, инструкции по эксплуатации, доступы, инфраструктурные настройки и знания команды должны рассматриваться как часть результата, а не как второстепенные приложения к договору.
Мы бы также обязательно проверяли, что произойдёт после завершения первой фазы. Если подрядчик может объяснить, как система будет развиваться без постоянного увеличения команды, это один показатель зрелости. Если каждое изменение автоматически означает новые часы тех же специалистов, это уже другая экономическая модель.
В этом смысле показателен и общий сдвиг российского IT-рынка. CNews характеризует 2025–2026 годы как период перехода от приоритета скорости замены к экономической эффективности, безопасности, отказоустойчивости и гибкости архитектуры. Для крупного бизнеса это означает, что стоимость IT теперь всё сложнее оценивать только по цене внедрения: значение приобретает способность системы оставаться управляемой после запуска.
Поэтому дешёвый IT-подрядчик становится дорогим не потому, что низкая цена сама по себе плоха. Низкая стоимость может быть вполне рациональной, если она достигается за счёт эффективных процессов, зрелой архитектуры, автоматизации и правильного распределения ответственности. Проблема начинается тогда, когда низкая цена достигается за счёт того, что из проекта незаметно убираются аналитика, архитектурная проработка, тестирование, документация, резерв на развитие или сильные технические компетенции.
Именно поэтому мы считаем, что главный вопрос при выборе подрядчика должен звучать не «сколько стоит разработка?», а «сколько будет стоить результат на всём горизонте его эксплуатации и развития?». Если подрядчик способен ответить на этот вопрос вместе с заказчиком, показать архитектурные компромиссы и заранее обозначить будущие ограничения, его предложение можно сравнивать по существу. Если же вся экономика сводится к минимальной ставке и количеству часов, заказчик фактически сравнивает только входную цену, не видя большей части будущих расходов.
Это принципиальная смена оптики: задача не в том, чтобы найти самого дешёвого исполнителя. Задача — построить такую модель разработки, при которой стоимость IT-системы остаётся управляемой не только в момент подписания договора, но и после нескольких лет эксплуатации. Именно в этом, по нашему мнению, и проходит настоящая граница между экономией на IT и переносом расходов на будущее.
