GreenCore 
Тендеры и лиды
Информация
Выбор IT-подрядчика в России долгое время строился вокруг довольно простого набора параметров: стоимость часа, количество разработчиков, стек технологий, портфолио и несколько знакомых логотипов в презентации. Такой подход ещё может работать для небольшой задачи с понятным ТЗ, но в корпоративной разработке он становится источником системного риска. Подрядчик может идеально соответствовать формальным требованиям тендера и при этом оказаться совершенно неподходящим для конкретного IT-ландшафта, архитектуры и темпа бизнеса.
Мы считаем, что до подписания договора заказчику нужно оценивать не столько самого подрядчика, сколько вероятность того, что конкретная команда сможет предсказуемо довести конкретную задачу до нужного бизнес-результата. Это принципиально разные вещи. Российский рынок заказной разработки в 2025–2026 годах как раз движется в эту сторону: CNews отмечает, что заказчики всё чаще ждут от исполнителя полного цикла — от аналитики и проектирования до интеграции, внедрения и сопровождения — и хотят заранее понимать сроки, риски и экономику проекта. Одновременно стоимость часа перестаёт быть самостоятельным критерием выбора: на первый план выходят стабильность поставки, качество, предсказуемость сроков и практический результат.
Для российского бизнеса это особенно важно ещё и потому, что подрядчик всё чаще подключается не к чистому проекту «с нуля», а к уже существующей системе. Внутри компании есть 1С, CRM, внутренние сервисы, API, базы данных, legacy, собственные команды разработки, требования безопасности и накопленный технический долг. Поэтому вопрос «умеет ли этот подрядчик писать на Python?» значительно менее полезен, чем вопрос «понимает ли он последствия подключения Python-сервиса к нашей существующей архитектуре?». Именно с такой логики, на наш взгляд, и стоит начинать техническую проверку исполнителя.
На этапе выбора подрядчика компании часто смотрят на то, что проще всего сравнить: количество сотрудников, годы на рынке, список клиентов, технологии, сертификаты, стоимость специалистов и красивые описания проектов. Все эти показатели имеют значение, но сами по себе не отвечают на главный вопрос: сможет ли подрядчик работать именно в вашей среде.
Например, наличие сотни разработчиков ничего не говорит о том, кто именно будет работать над проектом. В презентации можно показать сильную команду, а после подписания договора получить специалистов, которые ранее не сталкивались с похожей архитектурой. Аналогично работает и портфолио. Наличие пяти проектов на Java ещё не означает, что команда умеет поддерживать высоконагруженную корпоративную систему с десятками интеграций, если именно такой сценарий предстоит заказчику.
Мы бы поэтому разделяли две проверки: проверку компании и проверку проектной команды. Первая отвечает на вопрос, существует ли у подрядчика необходимая организационная и финансовая база. Вторая — действительно ли конкретные люди способны решить поставленную задачу.
На российском рынке уже есть инструменты для первичной проверки масштаба и опыта поставщиков. Например, CNews при анализе компаний заказной разработки учитывает не только количество реализованных проектов, но и отраслевые компетенции, численность разработчиков, технологический стек, стоимость услуг и другие параметры. Сам факт того, что рынок профессионально сравнивается сразу по нескольким измерениям, показателен: одной характеристики для оценки подрядчика недостаточно.
При этом мы бы не превращали проверку в попытку найти «идеальную IT-компанию». У каждого подрядчика есть специализация. Намного важнее понять, совпадает ли эта специализация с задачей заказчика. Если компания привыкла создавать MVP, а заказчику нужна многолетняя эксплуатация критичной корпоративной системы, проблема может возникнуть даже при очень сильной команде. Если подрядчик специализируется на поддержке legacy, а бизнесу нужен быстрый запуск нового продукта, ситуация будет обратной.
На наш взгляд, самая полезная проверка начинается ещё до обсуждения финальной цены. CTO или технический руководитель заказчика должен посмотреть, как подрядчик мыслит о задаче. Причём здесь важно не получить ещё одну презентацию на 50 слайдов, а создать ситуацию, в которой подрядчику придётся принимать реальные технические решения.
Первый индикатор — способность задавать неудобные вопросы. Хороший подрядчик не должен сразу соглашаться со всем, что находится в техническом задании. Если ему показывают архитектуру, в которой есть очевидные ограничения, он должен их обозначить. Если бизнес требует сделать систему за два месяца, но исходные требования предполагают четыре месяца работ, это должно прозвучать до подписания договора, а не после первого спринта.
Второй индикатор — способность объяснить архитектурные решения языком последствий для бизнеса. Не «мы предлагаем микросервисную архитектуру», а «при такой нагрузке и количестве интеграций это позволит независимо масштабировать отдельные компоненты, но увеличит требования к DevOps и наблюдаемости». Не «давайте вынесем сервис отдельно», а «это снизит связанность с существующей системой, однако добавит ещё один контур мониторинга и поддержки». Именно в таких объяснениях становится видно, действительно ли перед нами инженерная команда или просто продавец набора технологий.
Третий индикатор — отношение к неопределённости. В реальном enterprise-проекте невозможно заранее знать абсолютно всё. Если подрядчик обещает окончательную стоимость и сроки ещё до изучения архитектуры, требований, интеграций и ограничений, это повод как минимум спросить, на чём основана такая уверенность. Иногда честная формулировка «сначала проведём техническое обследование, после чего зафиксируем оценку» гораздо ценнее красивого обещания.
Именно этот принцип мы считаем одним из ключевых в подходе CTO GreenCore. Публично описывая свою модель работы, компания делает акцент на диагностике, прозрачной архитектуре сотрудничества с первого дня, понимании бизнес-контекста и подборе специалистов с релевантным опытом и архитектурным контекстом. На сайте GreenCore отдельно подчёркивается, что решения должны приниматься с горизонтом развития системы, а не только под текущую задачу. В профиле компании на Ruward этот же подход сформулирован через последовательность «сначала понять, зачем нужен продукт, затем предложить решение», а также через ответственность за результат, а не за количество потраченных часов.
Для нас это принципиальная граница между техническим подрядчиком и просто поставщиком ресурсов. Если перед договором команда способна провести содержательный технический диалог, обнаружить ограничения и объяснить последствия решений, то у заказчика появляется материал для объективной оценки. Если же разговор всё время сводится к количеству специалистов, ставке и срокам выхода людей, технический риск фактически остаётся непроверенным.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13768 тендеров
проведено за восемь лет работы нашего сайта.
Одна из самых частых ошибок заказчика — подписать договор с компанией, а уже потом выяснить, кто именно будет выполнять работу. Мы считаем правильным обратный порядок: ещё до контракта необходимо увидеть хотя бы ключевых участников проекта и понять, какую ответственность каждый из них будет нести.
Для крупного проекта обычно имеет смысл отдельно проверять архитектора, технического руководителя, аналитика или BA, PM, ключевых разработчиков и QA. Не обязательно проводить полноценные собеседования с каждым человеком, но заказчик должен понимать уровень специалистов и их реальный опыт. Особенно важно выяснить, работали ли они с системами сопоставимой сложности, интеграциями, нагрузкой, миграциями, безопасностью и существующим legacy.
Здесь полезно задавать не теоретические вопросы вроде «знаете ли вы Kubernetes?», а вопросы по конкретному проекту. Что произойдёт, если одна из интеграций станет недоступна? Как будет организована повторная обработка данных? Где будет находиться источник истины? Как устроить rollback? Как контролировать изменение схемы данных? Что произойдёт с системой при двукратном росте нагрузки? Как будет происходить передача проекта внутренней команде? Какие технические решения подрядчик считает наиболее рискованными?
Ответы на такие вопросы гораздо сложнее подготовить маркетинговым отделом. И именно поэтому они хорошо показывают реальную инженерную зрелость.
При этом проверять нужно не только hard skills. B1 в исследовании российского аутсорсинга 2026 года фиксирует, что компании всё больше рассматривают аутсорсинг как инструмент повышения экономической эффективности и получения доступа к экспертизе: эти факторы назвали 70% и 62% респондентов соответственно. Одновременно растут требования к квалификации персонала исполнителя. Это важный сигнал: заказчик покупает у подрядчика не количество человеко-часов, а доступ к компетенциям, которых ему не хватает внутри.
Поэтому перед подписанием договора мы бы обязательно проверяли не только состав команды, но и модель её управления. Кто принимает технические решения? Кто имеет право менять состав команды? Кто отвечает за качество? Кто отвечает за сроки? Кто является точкой эскалации? Может ли архитектор напрямую обсуждать с заказчиком принципиальные изменения? Что происходит, если ключевой специалист уходит? Чем быстрее на эти вопросы можно получить конкретные ответы, тем ниже вероятность, что после старта проекта зоны ответственности начнут размываться.
Стоимость проекта часто воспринимается как финансовый вопрос, хотя значительная часть будущей экономики закладывается именно техническими решениями. Дешёвая архитектура на старте может оказаться дорогой в эксплуатации, а высокая ставка сильной команды — наоборот, снизить общую стоимость изменений, если разработка будет идти быстрее и без накопления критического технического долга.
Российский рынок заказной разработки сейчас особенно хорошо показывает эту проблему. По данным CNewsMarket, средняя ставка дня разработчика, выставляемая заказчикам аутсорсерами, в 2025 году снизилась с 29,6 тыс. до 24,9 тыс. рублей, то есть на 15,7%. Для DevOps снижение составило 13,3%, для руководителей проектов — 12,9%. CNews связывает это с усилением конкуренции и изменением экономики проектов. Само по себе снижение ставки не означает снижения стоимости владения системой: если подрядчик экономит на архитектуре, тестировании, аналитике или сильном техническом руководстве, заказчик может заплатить за эту экономию уже после запуска.
Именно поэтому мы считаем полезным до договора обсуждать не только бюджет разработки, но и будущую стоимость изменений. Сколько будет стоить добавить новый интеграционный контур? Насколько сложно заменить отдельный компонент? Как будет масштабироваться система? Что произойдёт при увеличении нагрузки? Сколько потребуется времени на исправление критического дефекта? Кто будет сопровождать инфраструктуру? Какие компетенции останутся у заказчика после завершения проекта?
Исследование LDM о корпоративной разработке в России показывает, насколько тесно связаны архитектура и управляемость разработки: в исследовании участвовали 50 интервью и более 100 специалистов, преимущественно из финансового сектора, ритейла и промышленности, а ключевым запросом рынка назван именно управляемый time-to-market без роста технического долга. Для выбора подрядчика это означает довольно простую вещь: архитектуру нельзя оставлять исключительно на этапе реализации. Она должна быть частью процесса выбора исполнителя.
В GreenCore мы исходим именно из этой логики: сначала нужно понять контекст системы, ограничения и предполагаемую траекторию развития, а уже потом обсуждать модель реализации и стоимость. Такой подход позволяет сравнивать подрядчиков не по принципу «кто дешевле за час», а по потенциальной стоимости достижения результата. Это гораздо ближе к реальной экономике IT-проекта.
На наш взгляд, зрелый выбор подрядчика заканчивается не тогда, когда согласована цена. Он заканчивается тогда, когда обе стороны одинаково понимают, что именно будет происходить после подписания договора.
До начала работ должны быть зафиксированы как минимум границы ответственности, состав команды и роли ключевых специалистов, модель управления проектом, порядок изменения требований, критерии приёмки, требования к качеству и тестированию, правила работы с инфраструктурой и данными, порядок передачи результатов, условия поддержки и развития, а также то, что происходит при изменении сроков или объёма проекта.
Особое внимание стоит уделять механизму изменения требований. Если любой новый запрос превращается в отдельный конфликт вокруг бюджета, значит, модель сотрудничества была плохо продумана изначально. В корпоративной разработке изменения неизбежны. Вопрос не в том, удастся ли их избежать, а в том, насколько прозрачно компания сможет понять их влияние на сроки, стоимость и архитектуру.
Не менее важна и процедура приёмки. Формулировка «система должна работать стабильно» практически бесполезна. Гораздо лучше определить измеримые критерии: допустимое время ответа, сценарии отказоустойчивости, требования к нагрузке, покрытие тестами для критических компонентов, перечень интеграций, допустимое количество дефектов и условия перехода между этапами.
CNews отмечает, что в современной заказной разработке качество всё чаще рассматривается как фактор сроков и рисков, а не как отдельная функция, которую можно оставить на конец проекта. Ошибки в корпоративных системах с большим количеством интеграций способны быстро превращаться в дополнительные затраты и задержки.
В итоге мы бы сформулировали критерий выбора IT-подрядчика несколько иначе, чем это принято в классическом тендерном подходе. Нас интересует не то, насколько убедительно подрядчик выглядит до сделки, а насколько прозрачно устроена будущая работа после неё. Хороший подрядчик должен быть способен показать не только разработчиков и портфолио, но и ход своих мыслей: как он понимает задачу, какие риски видит, почему предлагает именно такую архитектуру, где проходит граница ответственности, как будет измеряться результат и что произойдёт, если исходные предположения окажутся неверными.
Именно такой подход, на наш взгляд, сегодня становится особенно актуальным для российского IT-рынка. Заказная разработка постепенно перестаёт быть покупкой набора специалистов или человеко-часов. Заказчик покупает способность внешней команды работать внутри сложной системы, принимать технические решения и делать это предсказуемо с точки зрения сроков, качества и экономики. Поэтому лучший момент для обнаружения проблем с подрядчиком — не первый месяц после подписания договора, а несколько недель до него. Именно тогда ещё можно спокойно задать неудобные вопросы, изменить состав команды, пересмотреть архитектуру или вообще отказаться от сотрудничества без стоимости уже совершённой ошибки.
