Большинство CEO приходят на переговоры с IT-компанией с ТЗ в руках и бюджетом в голове. Это уже проигрышная позиция — не потому что ТЗ плохое, а потому что IT-подрядчик провёл сотни таких встреч, а вы — единицы. Асимметрия опыта решает раньше, чем вы успеваете открыть рот.
Есть один вопрос, который я задаю на любых переговорах с IT — он меняет всю динамику встречи. Об этом — в шаге 3.
В этом гайде — пошаговая логика, которая выравнивает позиции до начала разговора о деньгах. Не техническая грамотность, не скрипты. Переговорная структура, которую можно применить уже на следующей встрече.
Третий раз за последние полгода вижу одну и ту же картину: CEO приходит на переговоры с IT-подрядчиком подготовленным технически — изучил стек, прочитал кейсы, сравнил цены. И проигрывает переговорно. Не потому что слабый переговорщик. Потому что готовился не к тем вещам.
IT-переговоры — это не переговоры о цене. Это переговоры о неопределённости. Подрядчик продаёт вам будущее, которого ещё нет. Он знает, сколько стоит его время. Вы не знаете, сколько стоит ваша проблема в его руках. Это фундаментальная асимметрия — и она работает против вас с первой минуты встречи.
Второй момент: IT-компании продают процесс, а не результат. «Мы разработаем», «мы внедрим», «мы настроим» — это всё глаголы без финальной точки. Когда вы покупаете станок, вы знаете, что получите станок. Когда покупаете разработку — вы покупаете обещание, завёрнутое в методологию.
Цена ошибки здесь — не деньги. Деньги вернуть можно, иногда через суд. Время — нет. Проект, который «почти готов» восемь месяцев, убивает не бюджет, а стратегический цикл компании. Именно поэтому переговоры с IT-подрядчиком требуют отдельной подготовки — даже если вы опытный переговорщик в своей отрасли.
Прежде чем читать дальше — вспомни последние переговоры с IT-компанией или подрядчиком любого рода. Что вы обсуждали в первые 20 минут? Скорее всего — их возможности, их опыт, их портфолио. Не вашу задачу. Это уже их сценарий.
Первая ошибка CEO в переговорах с IT — приходить с ТЗ вместо описания проблемы. ТЗ — это уже ваше решение. Когда вы его показываете, вы сужаете переговорное пространство до «сколько стоит сделать именно это». Подрядчик перестаёт думать о вашей задаче и начинает считать часы.
Есть три типа IT-контрактов, и они принципиально разные по логике переговоров. Первый — Time & Material: вы платите за время, риск неопределённости на вас. Второй — Fixed Price: вы платите за результат, риск неопределённости на подрядчике, поэтому цена выше. Третий — Retainer: вы покупаете доступность команды, риск делится. Большинство CEO не знают, какой тип им нужен, и соглашаются на тот, который предлагает подрядчик. Это не нейтральный выбор — это выбор в пользу подрядчика.
Правильный вопрос перед встречей: что является результатом, который я могу измерить? Не «сделать CRM», а «сократить время обработки заявки с 4 часов до 40 минут». Не «интегрировать системы», а «менеджер видит полную историю клиента в одном окне». Когда у вас есть измеримый результат — вы можете торговаться за него, а не за объём работ.
Это меняет всю переговорную динамику. Но только если вы успеете занять эту позицию до того, как подрядчик начнёт вести встречу по своему сценарию.
Переговорная позиция — это не список требований. Это понимание своих альтернатив и чужих ограничений. Без этого вы торгуетесь вслепую.
BATNA в IT-переговорах работает иначе, чем в классических сделках. Ваша лучшая альтернатива — не «найти другого подрядчика». Это слишком абстрактно. Конкретная BATNA: «Мы берём двух штатных разработчиков на 6 месяцев и делаем MVP своими силами». Или: «Мы откладываем проект на квартал и пересматриваем приоритеты». Когда у вас есть реальная альтернатива с реальными цифрами — вы перестаёте бояться сказать «нет».
Ценовые якоря — главный инструмент IT-компаний на первой встрече. Подрядчик называет цифру первым — и всё дальнейшее обсуждение идёт вокруг неё. Стандартный приём: «Обычно такой проект стоит от X до Y, но для вас мы можем...» Якорь установлен. Противоядие — называть свой якорь первым или немедленно сбивать чужой: «Я слышал другие цифры на рынке, давайте разберём, из чего складывается стоимость».
Есть три вещи, которые нельзя показывать до подписания. Первое — дедлайн. Если подрядчик знает, что вам нужно к октябрю, он будет тянуть переговоры до сентября. Второе — бюджет. «У нас заложено 3 миллиона» — это не переговорная позиция, это потолок, к которому подрядчик немедленно подтянет свою оценку. Третье — безальтернативность. «Вы единственные, кто нам подходит» — это капитуляция до начала переговоров.
Здесь обычно возникает возражение: «Но если я скрываю бюджет — мы будем ходить по кругу». Это обоснованное беспокойство. Но разница между «у нас 3 миллиона» и «мы готовы к разумным инвестициям при чётком результате» — принципиальная. Второй вариант не скрывает бюджет, он переводит разговор в плоскость ценности.
→ Если хочешь разобрать свою конкретную ситуацию до переговоров — есть формат стратегического спринта. 90 минут, один вопрос, конкретный план. Подробности: /services/negotiations/
Кто задаёт вопросы — тот управляет встречей. Это не метафора, это механика. Когда IT-менеджер по продажам спрашивает «расскажите о вашем бизнесе» — он берёт управление. Вы начинаете объяснять, он начинает оценивать. Позиции зафиксированы: он эксперт, вы клиент.
Простой способ перехватить инициативу — начать встречу со своего вопроса, до того как они начали свою презентацию. Не «расскажите о себе», а конкретный: «Покажите мне проект, который провалился, и что вы из него вынесли». Это не агрессия. Это диагностика. Компания, которая не может ответить на этот вопрос честно — либо не имеет опыта неудач (читай: опыта вообще), либо не готова к честному разговору.
Вот история из практики. Алексей — CEO производственного холдинга с выручкой около 400 миллионов — пришёл на переговоры с крупным IT-интегратором с готовым ТЗ на 40 страниц. Первая встреча прошла по сценарию подрядчика: презентация, кейсы, «мы понимаем специфику производства». Алексей вышел с ощущением, что его послушали, но не услышали. Коммерческое предложение пришло через неделю — на 30% выше ожидаемого, с размытыми milestone-ами и формулировкой «объём работ уточняется в процессе».
На вторую встречу он пришёл иначе. Без ТЗ. С тремя вопросами. Первый: «Что в нашем проекте вас беспокоит больше всего?» Второй: «Какой результат вы готовы гарантировать письменно?» Третий — тот самый вопрос, о котором я упоминал в начале: «Если через полгода проект не достигнет результата — что происходит с деньгами?» Динамика встречи изменилась полностью. Итоговая цена оказалась на 18% ниже первого предложения, а контракт — с чёткими точками выхода.
Как читать паузы и уклонения: если на вопрос о гарантиях подрядчик начинает говорить о «сложности проекта» и «зависимости от вашей команды» — это не объяснение, это перекладывание риска. Фиксируйте это. Не как повод для конфликта, а как информацию о том, с кем вы разговариваете.
Цена — последнее, что обсуждают сильные переговорщики. Не потому что деньги не важны. Потому что цена без условий — бессмысленная цифра. Три миллиона за проект «под ключ» и три миллиона за проект с milestone-ами, правом аудита и штрафами за срыв сроков — это разные сделки.
Здесь обычно возникает второе возражение: «IT-компании всё равно сделают по-своему, что бы ни было в контракте». Это частично правда. Но контракт с правильными условиями меняет не поведение подрядчика — он меняет вашу позицию при любом исходе. Вы либо получаете то, что договорились, либо получаете рычаг.
Что включить в контракт помимо суммы. Первое — определение результата в измеримых показателях, не в объёме работ. Второе — milestone-логика с промежуточными платежами: не более 30% аванса, остальное — по этапам. Третье — право на аудит кода или промежуточных результатов. Четвёртое — условия выхода: что происходит с наработками, если вы расстаётесь на середине. Пятое — SLA на постпроектную поддержку с конкретными сроками реакции.
Milestone-логика — это не недоверие к подрядчику. Это структура, которая защищает обе стороны. Хороший подрядчик её примет. Плохой — будет сопротивляться, объясняя это «спецификой разработки». Это тоже диагностика.
Коллега, с которым я разбирал несколько IT-контрактов в прошлом году — медиатор с опытом в технологических спорах — сформулировал это точно: «Большинство конфликтов с IT-подрядчиками начинаются не в момент срыва, а в момент подписания. Люди подписывают то, что не понимают, надеясь на отношения».
Есть признаки, по которым я понимаю, что подрядчик не подходит — независимо от цены и портфолио. Первый: они не задают вопросов о вашем бизнесе. Хороший подрядчик хочет понять задачу, плохой — закрыть сделку. Второй: они не могут объяснить риски проекта простым языком. Если на вопрос «что может пойти не так» вы получаете маркетинговый ответ — это красный флаг. Третий: они давят на срочность. «Мы можем взять вас только до конца месяца» — классическая манипуляция дефицитом. Подробнее о том, как распознавать такие приёмы — в материале «Давление и блеф: как распознать тактику контрагента».
Как выйти без конфликта, если понял, что не то. Не объясняйте причины подробно. «Мы приняли решение пересмотреть подход к проекту» — достаточно. Не сжигайте мосты: IT-рынок небольшой, этот подрядчик может оказаться правильным через год. Не затягивайте: чем дольше вы «думаете» после того, как решение принято — тем сложнее выход.
Финальный чек перед подписанием — пять вопросов. Первый: я могу объяснить результат этого контракта в одном предложении? Второй: я знаю, что происходит с деньгами и наработками, если мы расстаёмся досрочно? Третий: в контракте есть измеримые milestone-ы с датами? Четвёртый: я понимаю, кто конкретно будет работать над проектом — не «команда», а люди? Пятый: у меня есть право выйти из контракта без штрафа, если подрядчик нарушает условия?
Если на любой из этих вопросов ответ «нет» или «не уверен» — не подписывайте. Переговоры ещё не закончены.
Подробнее о том, как перехватывать инициативу в переговорах любого типа — в материале «Как перехватить инициативу в переговорах».
На первую встречу — нет. Юрист нужен при работе с контрактом, не при выстраивании переговорной позиции. Если вы берёте юриста на первую встречу — вы сигнализируете о недоверии до начала отношений. Это меняет динамику не в вашу пользу. Юрист нужен перед подписанием — и желательно тот, кто понимает специфику IT-контрактов, а не только гражданское право.
Это стандартная позиция для Time & Material контрактов. Она не означает, что вы не можете торговаться. Торгуйтесь за ставку, за cap (максимальный бюджет), за право остановить проект в любой момент без штрафа. «Нет фиксированной цены» — не повод соглашаться на неограниченный бюджет.
Это не недостаток — это нормальная позиция CEO. Ваша задача — не понимать технологии, а понимать результат и риски. Задавайте вопросы о результате, а не о процессе. «Как вы это сделаете» — вопрос для технического директора. «Что я получу и когда» — вопрос для CEO. Если подрядчик использует техническую сложность как аргумент в переговорах — это манипуляция, а не объяснение.
В начале я написал, что асимметрия опыта решает до начала разговора о деньгах. Теперь ты видишь, как именно её выровнять — не техническими знаниями, а переговорной структурой. Пять шагов: понять, что покупаешь. Собрать позицию до встречи. Управлять первой встречей. Торговаться по условиям, а не по цене. Закрыть или выйти без потерь.
Это не гарантия идеального контракта. Это способ не проиграть переговоры до того, как они начались.
Если у тебя сейчас идут или предстоят переговоры с IT-компанией — и ты чувствуешь, что позиция слабее, чем хотелось бы — приходи на стратегический спринт. 90 минут: разбираем твою конкретную ситуацию, определяем переговорную позицию, готовим структуру встречи.
Работаю с CEO и собственниками бизнесов от 80 миллионов выручки. Не с теми, кто ищет скрипт — с теми, кто хочет понять логику.
Беру не более 3 заявок на стратегический спринт в неделю. Напиши на hi@vvetrov.com: кто ты, что за проект, в чём затык.
P.S. Если ситуация не моя — скажу честно и порекомендую, к кому идти.
Июнь 2026. Автор — Виталий Ветров, переговорщик и стратегический советник для предпринимателей.