BATNA в переговорах с IT-компанией — это не теория из учебника по Гарвардскому методу. Это единственное, что не даёт тебе согласиться на условия, которые ты потом будешь разбирать с юристом. Фаундеры, которые входят в переговоры с разработчиком или IT-подрядчиком без проработанной альтернативы, проигрывают не потому что плохо торгуются. Они проигрывают потому что не знают, когда уходить — и остаются за столом дольше, чем нужно.
Этот гайд — пошаговый алгоритм определения BATNA до того, как ты сядешь за стол. Шесть шагов, конкретные инструменты, примеры из практики. В конце — одна ошибка, которую делают даже опытные фаундеры: они укрепляют BATNA, но раскрывают её в неправильный момент. Об этом отдельно.
1. Зачем фаундеру BATNA именно в IT-переговорах 2. Шаг 1. Сформулируй, что именно ты покупаешь 3. Шаг 2. Составь карту альтернатив — все варианты, включая плохие 4. Шаг 3. Оцени каждую альтернативу по трём параметрам 5. Шаг 4. Определи точку выхода — ZOPA и reservation point 6. Шаг 5. Укрепи BATNA до переговоров — и сделай это видимым 7. Частые вопросы
Четвёртый раз за квартал вижу одну и ту же картину. Фаундер входит в переговоры с IT-подрядчиком без единой альтернативы на руках. Не потому что ленился готовиться. Потому что искренне верит: «этот подрядчик уникален», «у них нужная экспертиза», «другие не потянут». И это убеждение — не факт. Это позиция нужды, которую опытный переговорщик на другой стороне считывает за первые десять минут.
IT-переговоры структурно асимметричны. Подрядчик приходит с портфелем клиентов, референсами, загрузкой на три месяца вперёд. Фаундер приходит с болью: продукт нужно запустить, инвесторы ждут, команда смотрит. Эта асимметрия не означает, что ты обречён. Она означает, что без BATNA ты торгуешься с позиции нужды — и любой опытный переговорщик это использует.
Прежде чем читать дальше — вспомни последние переговоры с IT-подрядчиком или разработчиком. Была ли у тебя альтернатива, которую ты мог назвать одним предложением? Не «ну, можно было бы поискать других» — а конкретная, оценённая, реалистичная альтернатива.
Если нет — ты не один. Но это не оправдание.
Разница между переговорами с IT-компанией и, скажем, переговорами с поставщиком сырья в том, что IT-рынок непрозрачен. Ценообразование непредсказуемо. Компетенции сложно верифицировать до начала работы. Это создаёт информационную асимметрию поверх позиционной. И именно поэтому BATNA здесь важнее, чем в большинстве других переговорных контекстов: она компенсирует не только позиционную слабость, но и информационную.
Есть ещё один нюанс, который редко обсуждают. В IT-переговорах подрядчик часто знает, что у тебя нет альтернативы — потому что ты сам это показываешь. Сроками. Срочностью. Количеством встреч, которые ты инициируешь. Деталями технического задания, которые ты присылаешь до подписания NDA. BATNA — это не только инструмент принятия решений. Это сигнал, который меняет поведение другой стороны.
Дальше — как её построить. Начнём с места, где большинство ошибается ещё до первой встречи.
Большинство фаундеров входят в переговоры с IT-компанией с размытым запросом. «Нам нужна разработка мобильного приложения». «Хотим автоматизировать процессинг». «Ищем команду под продукт». Это не задача — это направление. И пока задача не сформулирована точно, BATNA построить невозможно: ты не знаешь, что именно ищешь в альтернативах.
Здесь важно разделить два понятия, которые в IT-переговорах постоянно путают: output и outcome.
Output — это то, что подрядчик делает. Написанный код, задеплоенное приложение, настроенная инфраструктура. Outcome — это то, что происходит с твоим бизнесом в результате. Снижение времени обработки заявки с 4 часов до 20 минут. Конверсия из регистрации в первую оплату — 12% вместо 4%. Возможность масштабировать нагрузку без найма.
Когда ты покупаешь output — ты торгуешься за часы, стек, команду. Когда ты покупаешь outcome — ты торгуешься за результат. Это разные переговоры. И BATNA в них строится по-разному.
Декомпозиция задачи до outcome делает несколько вещей одновременно. Во-первых, она сужает круг подрядчиков, которые реально могут помочь — и расширяет круг тех, кого ты раньше не рассматривал. Во-вторых, она даёт тебе критерий оценки альтернатив: не «кто дешевле напишет код», а «кто быстрее приведёт к нужному бизнес-результату». В-третьих, она меняет разговор за столом — с технического на стратегический.
Практический инструмент: перед тем как составлять карту альтернатив, запиши ответы на три вопроса.
Третий вопрос — самый важный для BATNA. Он показывает реальную цену бездействия. И часто оказывается, что цена бездействия ниже, чем фаундер думал. Это меняет переговорную позицию радикально.
Когда задача сформулирована через outcome — можно строить карту альтернатив. И здесь начинается самое интересное.
Здесь обычно возникает возражение: «У меня нет альтернатив — этот подрядчик уникален». Слышу это регулярно. Иногда это правда — в узких нишах с редкой экспертизой альтернативы действительно ограничены. Но чаще это когнитивное искажение: мы перестаём искать альтернативы, как только нашли «подходящего» кандидата. Карта альтернатив — это принудительное упражнение против этого искажения.
Правило первое: записывай все варианты, включая те, которые кажутся плохими. Плохая альтернатива лучше отсутствия альтернативы — потому что она даёт точку отсчёта.
Типичная карта альтернатив для IT-переговоров выглядит так:
Другие подрядчики. Очевидный вариант, который тем не менее часто не прорабатывается до конца. Не «можно поискать других», а конкретные компании с конкретными оценками стоимости и сроков. Минимум три. Лучше пять.
Инхаус-команда. Нанять разработчиков в штат. Дороже в моменте, дешевле на горизонте двух лет при постоянной потребности. Требует времени на найм — это реальное ограничение, которое нужно оценить честно.
Отложить проект. Звучит как капитуляция. На самом деле это легитимная альтернатива, если цена бездействия ниже цены плохой сделки. Иногда «не сейчас» — лучшее решение.
Купить готовое решение. SaaS, no-code, готовая платформа. Не всегда подходит, но часто не рассматривается просто потому что «мы хотим своё».
Партнёрство с долей. Технический сооснователь или CTO на equity вместо cash. Меняет структуру сделки полностью — и иногда это именно то, что нужно.
Гибридная модель. Часть задач — подрядчик, часть — инхаус или фриланс. Снижает зависимость от одного поставщика.
Антон — фаундер B2B SaaS в сфере логистики, бизнес около трёх лет, выручка чуть выше 100 миллионов. Пришёл на разбор после того, как подписал контракт с IT-подрядчиком на условиях, которые его не устраивали. Когда я спросил, почему согласился — ответил: «Не было вариантов». Мы потратили сорок минут на то, чтобы составить карту альтернатив ретроспективно. Нашли четыре реальных варианта, которые он не рассматривал — включая готовое решение, которое закрывало 80% задачи за треть цены. Он не знал о нём, потому что не искал: был уверен, что нужна кастомная разработка. Контракт к тому моменту был подписан.
Это не исключение. Это правило. Карта альтернатив строится до переговоров — не после.
Важный нюанс: альтернативы нужно не просто перечислить, но и верифицировать. «Можно нанять инхаус» — это не альтернатива. «Можно нанять двух middle-разработчиков за 300 тысяч в месяц, первый выйдет через шесть недель» — это альтернатива. Разница в том, что второй вариант можно сравнивать с предложением подрядчика.
Карта составлена. Теперь нужно понять, какая из альтернатив реально лучшая — и это не всегда та, что кажется очевидной.
Здесь обычно возникает второе возражение: «BATNA — это для крупных сделок, у меня небольшой проект». Оценка альтернатив кажется избыточной, когда речь идёт о контракте на два-три миллиона. Но именно в небольших сделках фаундеры чаще всего соглашаются на плохие условия — потому что не считают, что игра стоит свеч. А потом обнаруживают, что «небольшой проект» растянулся на год и стоил в три раза больше бюджета.
Три параметра оценки:
Насколько вероятно, что эта альтернатива реально реализуема в твоей ситуации? Не в теории — на практике, с учётом твоих ресурсов, команды и временного окна. Инхаус-найм реалистичен, если у тебя есть HR-функция и время. Нереалистичен, если тебе нужен результат через восемь недель.
Оцени по шкале от 1 до 5. Альтернативы с оценкой 1–2 — оставь в списке, но не строй на них BATNA.
Что ты теряешь, если выбираешь эту альтернативу вместо текущего переговорного варианта? Время, деньги, качество, скорость выхода на рынок. Стоимость переключения — это не только прямые затраты. Это упущенная выручка за период задержки, стоимость управленческого внимания, риски.
Один из коллег, с которым я обсуждал асимметрию IT-переговоров несколько месяцев назад, сформулировал точно: «Фаундеры считают стоимость альтернативы в деньгах. Подрядчики считают её в твоём времени». Это важное наблюдение — потому что время фаундера в большинстве случаев дороже денег.
Когда альтернатива начнёт давать результат? Это критично, потому что BATNA должна быть реализуема в твоём временном окне. Если переговоры идут сейчас, а лучшая альтернатива реализуется через полгода — она не BATNA для этих переговоров. Она BATNA для следующих.
После оценки по трём параметрам у тебя есть взвешенный список. Лучшая альтернатива по совокупности трёх параметров — это и есть твоя BATNA. Не самая дешёвая. Не самая быстрая. Лучшая с учётом реалистичности, стоимости переключения и временного горизонта.
Если хочешь пройти этот процесс структурированно — в negotiation-framework есть шаблон карты альтернатив, адаптированный под IT-сделки. Скачать бесплатно.
BATNA — это не просто «лучшая альтернатива». Это основа для определения reservation point — точки, ниже которой ты не опускаешься. Это конкретная граница: условия, при которых ты встаёшь и уходишь.
Большинство фаундеров не формулируют reservation point явно. Они чувствуют дискомфорт, когда условия ухудшаются — но не имеют чёткого критерия выхода. Это приводит к тому, что они остаются за столом дольше, чем нужно, делают уступки, которые не планировали, и в итоге подписывают то, что изначально не хотели подписывать.
Reservation point формулируется через BATNA. Логика простая: если предложение подрядчика хуже, чем твоя BATNA — ты уходишь. Если лучше — остаёшься и торгуешься дальше.
Но здесь есть нюанс, который важно понять. Reservation point — это не «минимальная цена, которую я готов заплатить». Это многомерная граница. В IT-переговорах она обычно включает несколько параметров одновременно: цена, сроки, условия приёмки, ответственность за задержки, права на код, условия расторжения.
Практический инструмент: запиши reservation point по каждому параметру отдельно. Потом определи, какие параметры критичны (без них сделка невозможна), а какие — желательны (готов уступить в обмен на улучшение по критичным).
ZOPA (Zone of Possible Agreement) — это пространство между твоим reservation point и reservation point подрядчика. Если ZOPA существует — сделка возможна. Если нет — лучшая стратегия это признать и уйти.
Проблема в том, что ты не знаешь reservation point другой стороны. Но ты можешь его оценить. Загрузка команды подрядчика, их текущие клиенты, рыночные ставки, публичные кейсы — всё это даёт информацию о том, насколько им нужна эта сделка. Подробнее о том, как собирать эту информацию до встречи, — в материале про разведку перед переговорами.
Михаил — управляющий партнёр в производственном холдинге, искал IT-подрядчика под автоматизацию складской логистики. Бюджет был определён, сроки — жёсткие. Reservation point по цене он сформулировал чётко. Но не сформулировал reservation point по срокам и условиям приёмки. В итоге подписал контракт в рамках бюджета — и через четыре месяца обнаружил, что условия приёмки написаны так, что подрядчик может бесконечно переносить сдачу без штрафных санкций. Это был не обман — это была его ошибка в формулировке reservation point. Сделка состоялась. Но она стоила дороже, чем его BATNA.
Когда reservation point определён — можно думать о том, как сделать BATNA сильнее. И здесь начинается работа, которую большинство фаундеров не делают.
BATNA — не статичная вещь. Её можно улучшить до начала переговоров. И это одна из самых недооценённых частей подготовки.
Три способа укрепить BATNA в IT-переговорах:
Параллельные переговоры. Веди переговоры с несколькими подрядчиками одновременно. Это не манипуляция — это стандартная практика в любых закупках. Параллельные переговоры делают две вещи: они дают тебе реальные альтернативы с реальными цифрами, и они меняют динамику за каждым столом. Подрядчик, который знает, что ты разговариваешь с другими, ведёт себя иначе.
Верификация альтернатив. Недостаточно знать, что альтернатива существует. Нужно, чтобы она была верифицирована: предварительное предложение получено, сроки подтверждены, стоимость зафиксирована хотя бы в переписке. Верифицированная альтернатива — сильная BATNA. Гипотетическая альтернатива — слабая.
Снижение зависимости. Если ты можешь отложить часть задачи, разбить проект на этапы или снизить срочность — это укрепляет BATNA. Срочность — главный враг переговорной позиции. Подрядчик, который видит, что тебе «нужно вчера», использует это.
Теперь — обещанная ошибка, которую делают даже опытные фаундеры.
Они укрепляют BATNA. Но раскрывают её в неправильный момент.
Раскрыть BATNA слишком рано — значит показать карты до того, как другая сторона сделала своё предложение. Раскрыть слишком поздно — значит упустить момент, когда это могло изменить динамику. Правильный момент — когда переговоры зашли в тупик или когда другая сторона давит на тебя, рассчитывая на отсутствие альтернатив.
Формулировка имеет значение. Не «у меня есть другие варианты» — это звучит как блеф. А «я параллельно рассматриваю несколько предложений, и мне нужно принять решение до конца недели» — это факт, который меняет переговорную динамику без агрессии.
Здесь обычно возникает третье возражение: «Я уже в процессе переговоров, поздно готовить BATNA». Это не так. Переговоры — это процесс, а не событие. Пока контракт не подписан, ты можешь параллельно верифицировать альтернативы. Это займёт время — но это время окупится.
И последнее: никогда не блефуй о BATNA. Если ты говоришь «у меня есть предложение от другой компании» — оно должно существовать. Блеф в переговорах с IT-подрядчиком — это высокий риск при низком выигрыше. Рынок небольшой, репутация важна, и опытный переговорщик проверит.
Подробнее о том, как анализировать интересы другой стороны перед встречей, — в материале «Анализ интересов другой стороны перед встречей».
Не обязательно — и чаще всего не нужно. Достаточно сигнализировать о наличии альтернатив косвенно: через сроки принятия решения, через вопросы, которые ты задаёшь, через спокойствие в момент, когда другая сторона давит. Прямое раскрытие BATNA уместно, когда переговоры зашли в тупик и ты хочешь изменить динамику — но только если альтернатива реальна и верифицирована.
Это означает, что BATNA слабая — и это честная оценка твоей переговорной позиции. В этом случае задача не «сделать вид, что есть альтернативы», а укрепить BATNA до переговоров: найти дополнительные варианты, снизить срочность, разбить проект на этапы. Если укрепить не получается — входи в переговоры с пониманием своей слабой позиции и фокусируйся на условиях, которые снижают риски при плохом исходе.
После каждой значимой встречи. Переговоры меняют информацию: ты узнаёшь больше о позиции другой стороны, о реальных ограничениях, о том, что для них важно. Это может изменить оценку твоих альтернатив. BATNA — живой инструмент, не документ, который написал один раз и забыл.
В начале я написал, что фаундеры проигрывают не потому что плохо торгуются. Теперь видно почему: они торгуются без точки выхода. BATNA — это не переговорный трюк. Это структура, которая позволяет принимать решения рационально, а не под давлением момента. Шесть шагов в этом гайде — не теория. Это то, что я прохожу с клиентами перед каждыми значимыми переговорами.
Если ты входишь в переговоры с IT-компанией в ближайшие несколько недель — и пока не можешь назвать свою BATNA одним предложением — приходи на 20-минутную стратегическую сессию. Там не будет продажи. Будет короткий разбор твоей ситуации, и я скажу, работаю я с такой задачей или нет.
Работаю с фаундерами и CEO бизнесов от 80 миллионов выручки, которым нужна не теория, а конкретная подготовка к конкретной сделке. Беру не более 3 заявок в неделю.
Напиши на hi@vvetrov.com: кто ты, что за сделка, в чём вопрос.
P.S. Если задача не моя — скажу честно и направлю к тому, кто работает с такими кейсами.
Апрель 2026. Автор — Виталий Ветров, переговорщик и стратегический советник для предпринимателей.