Как собственник выигрывает переговоры с IT-компании

Переговоры с IT-компанией — это не переговоры о цене. Это переговоры о реальности. IT-подрядчик живёт в мире спринтов, бэклогов и «зависит от требований». Собственник — в мире дедлайнов, денег и последствий. Когда эти двое садятся за стол, говорят они вроде бы по-русски, но слышат разное. Один продаёт процесс. Другой покупает результат. Это разные вещи — и пока собственник не поймёт эту асимметрию, он будет проигрывать переговоры с IT-компанией не потому, что плохо торгуется, а потому что торгуется не о том.

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

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

Прежде чем читать дальше — вспомни последний разговор с IT-подрядчиком. Что обсуждали в первые двадцать минут? Скорее всего: функциональность, сроки, бюджет. Теперь вопрос: кто задавал вопросы, а кто отвечал?

В большинстве случаев собственник отвечает. IT-компания спрашивает. Это уже проигрышная позиция — и она устанавливается в первые минуты встречи.

IT-рынок устроен так, что подрядчики профессионально ведут первичные переговоры. Они делают это каждую неделю. Собственник покупает IT-систему раз в три–пять лет. Асимметрия опыта колоссальная. Добавь к этому асимметрию языка: «MVP», «технический долг», «архитектурные ограничения» — это не просто термины, это инструменты управления ожиданиями. Когда подрядчик говорит «архитектурные ограничения», он часто имеет в виду «мы не хотим переделывать то, что уже сделали».

Есть и третья асимметрия — асимметрия рисков. IT-компания рискует репутацией и, в худшем случае, неустойкой. Собственник рискует операционным провалом, потерянным временем и деньгами, которые уже не вернуть. Это разные ставки. И именно поэтому IT-переговоры нельзя вести как переговоры о поставке оборудования или аренде склада.

Пятый раз за последние полгода вижу одну и ту же картину: собственник приходит на переговоры с IT-компанией и первым делом называет бюджет. Иногда — ещё до того, как подрядчик задал хоть один вопрос. Дальше можно не продолжать — рамка уже задана не в его пользу.

Ловушки не очевидны. Каждая из них выглядит как разумное поведение — пока не видишь, что происходит на другой стороне стола.

Ловушка первая: доверие экспертизе вместо проверки обязательств.

Собственник нанимает IT-компанию именно потому, что сам не разбирается в технологиях. Это логично. Но из этого часто следует вывод: «раз они эксперты — им виднее». И переговоры превращаются в консультацию, где подрядчик объясняет, а клиент кивает. Экспертиза — это одно. Обязательства — другое. Можно быть блестящим разработчиком и при этом давать размытые обязательства. Именно это и нужно проверять.

Ловушка вторая: переговоры о функциях вместо переговоров о рисках.

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

Ловушка третья: спешка как слабость.

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

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

Если переговоры с подрядчиками — регулярная тема, в телеграм-канале разбираю похожие ситуации без воды: t.me/vvetrov

Вот тот вопрос, который я задаю в первые десять минут: «Расскажите о проекте, который у вас не получился. Что пошло не так?»

Это не провокация. Это диагностика. Зрелая IT-компания отвечает конкретно: называет проект (анонимно), описывает причины, говорит, что изменила в процессах. Незрелая — либо говорит «у нас всё получается», либо начинает рассказывать о «сложном клиенте». Оба ответа информативны. Первый означает, что компания не умеет анализировать провалы. Второй — что она не берёт ответственность.

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

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

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

Это не про жёсткость. Это про структуру разговора.

Инструмент первый: якорение через результат.

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

Инструмент второй: вопрос о провалах.

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

Инструмент третий: тест на «нет».

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

Инструмент четвёртый: разделение цены и ответственности.

Стандартная ошибка — торговаться о цене. Правильный вопрос: «Что входит в эту цену с точки зрения ответственности за результат?» Это разные вещи. IT-компания может снизить цену, убрав из контракта ответственность за интеграцию или за производительность системы. Ты получишь дешевле — и больше рисков. Разделяй эти два разговора.

Инструмент пятый: пауза.

Связанный материал: тактика молчания в переговорах

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

Из практики.

Максим, собственник производственного бизнеса с выручкой около 400 миллионов, пришёл на переговоры с IT-интегратором по внедрению ERP. Подрядчик с первых минут давил на уникальность проекта: «У вас нестандартные процессы, фиксированную цену дать невозможно, будем работать по времени и материалам.» Это стандартная позиция — и она перекладывает все риски на клиента.

Мы переформатировали переговоры через вопрос о провалах. Подрядчик назвал два проекта, которые «не пошли» — оба по модели time & material. Это стало точкой опоры: «Вы сами видите, что эта модель создаёт проблемы. Давайте зафиксируем первую фазу — аналитику и прототип — по фиксированной цене. Дальше — по вехам с чёткими критериями приёмки.»

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

Контракт с IT-компанией — это продолжение переговоров, не их завершение. Это важно понять до подписания.

Есть три пункта, которые IT-компании традиционно формулируют размыто — и которые стоит проговорить отдельно.

Критерии приёмки. «Система работает корректно» — это не критерий. «Система обрабатывает 500 заказов в час без ошибок при нагрузке X» — это критерий. Разница между этими формулировками — это разница между возможностью предъявить претензию и невозможностью.

Ответственность за интеграцию. Если система должна работать с другими продуктами — 1С, CRM, складским ПО — кто отвечает за то, что интеграция работает? Этот вопрос часто остаётся в серой зоне. Каждая сторона считает, что это проблема другой. Фиксируй явно.

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

Здесь обычно возникает возражение: «Жёсткие условия испортят отношения с подрядчиком.» Это один из самых устойчивых мифов в переговорах с IT. На практике — наоборот. Чёткие условия снижают количество конфликтов, потому что убирают зоны неопределённости, в которых конфликты и возникают. Хороший подрядчик предпочитает чёткие правила игры размытым обязательствам.

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

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

Есть ситуации, когда правильное решение — не договориться.

Три признака того, что переговоры уже проиграны — даже если они ещё продолжаются.

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

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

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

Уход из переговоров — это не поражение. Это решение. И его можно принять без конфликта: «Мы изучили ваше предложение. Пока не видим совпадения по подходу. Если что-то изменится — вернёмся.» Без объяснений, без извинений, без сжигания мостов.

Здесь обычно возникает возражение: «Но мы уже потратили время на переговоры — жалко уходить.» Это классическая ловушка невозвратных затрат. Время, потраченное на переговоры, уже потрачено — независимо от того, подпишешь ты контракт или нет. Вопрос только в том, сколько ещё потратишь.

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

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

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

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

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

Если IT-переговоры у тебя регулярно заканчиваются либо переплатой, либо испорченными отношениями — это не случайность.

Работаю с собственниками бизнесов от 80 миллионов выручки, которым нужна не теория, а разбор конкретной ситуации. Если это про тебя — напиши на hi@vvetrov.com: кто ты, что за проект, в чём вопрос. Беру не больше трёх новых заявок в неделю.

P.S. Если задача не моя — скажу честно и подскажу, куда идти.

Апрель 2026. Автор — Виталий Ветров, переговорщик и стратегический советник для предпринимателей.