Поиск по практике
Найдите практические примеры, кейсы и методики
Как через переговоры мы вернули 4,5 млн рублей по IT-контракту IT-заказчик
IT-компания разрабатывала программный продукт для нашего клиента. Проект затянулся, результат был не готов к внедрению. В какой-то момент разработчик заявил: «Всё сложно, давайте положим проект на полку, а когда у вас всё будет готово для внедрения — доработаем». И вместо этого потребовал доплату. Я вникла во все обстоятельства, изучила продукт, его структуру и архитектуру. Нашла слабые стороны проекта. Подготовила юридическую позицию и провела переговоры. В результате IT-компания согласилась на расторжение договора и возврат 4 500 000 рублей. Без длительного суда, без лишних затрат.
Что произошло: Заказчик заключил договор с IT-компанией на разработку программного продукта. Был перечислен аванс — крупная сумма. Разработка шла тяжело, сроки срывались. В итоге разработчик заявил, что продукт не может быть внедрён в текущем состоянии, и предложил:
- «Положить проект на полку»
- Дождаться, пока у заказчика «всё будет готово для внедрения»
- А потом — доплатить и доработать
Проблема в том, что разработчик не называл ни сроков, ни конкретных условий, при которых проект можно будет «достать с полки». А технологический прогресс не стоит на месте. Пока продукт лежит — рынок меняется, технологии устаревают, потребности бизнеса трансформируются.
📌 Что предложил разработчик: Фактически — бессрочную заморозку проекта с перспективой доплаты в будущем. Никаких гарантий, что продукт когда-либо будет готов к использованию.
⚠️ Почему это было невыгодно заказчику:
- Продукт не пригоден к внедрению сейчас — деньги заморожены
- Технологии устаревают — через год продукт может потерять актуальность
- Доплата за доработку — неопределённая сумма
- Разработчик не брал на себя обязательства по срокам
- Итог: заказчик мог остаться и без денег, и без работающего продукта
Я не просто взяла договор и пошла в суд. Я подготовилась к переговорам так, как будто это уже суд.
Что было сделано:
- Изучила техническое задание и договор разработки — до каждой буквы
- Разобралась в структуре продукта, его архитектуре, зависимостях
- Поняла, что именно мешает внедрению — технические ограничения, недоделки, логические ошибки
- Нашла слабые стороны проекта — то, что разработчик не смог бы объяснить в суде
- Сформулировала юридическую позицию: раз продукт нельзя внедрить сейчас и неизвестно, когда это станет возможно — значит, обязательство не исполнено, а аванс подлежит возврату
Ключевой вывод: В IT-контрактах недостаточно просто сказать «не работает». Нужно доказать, почему не работает, что именно не соответствует ТЗ и почему это нельзя исправить в разумный срок. Мы подготовили такие доказательства.
Мы не стали сразу идти в суд — это дорого, долго и непредсказуемо. Я подготовила пакет документов и вышла на переговоры с IT-компанией.
Что я предъявила на переговорах:
- Развёрнутый анализ договора с указанием неисполненных обязательств
- Технический разбор продукта — какие именно модули не работают, почему внедрение невозможно
- Ссылки на технологическую устареваемость — почему «положить на полку» не является решением
- Правовое обоснование: при таком положении дел заказчик вправе требовать возврата аванса
- Альтернативный сценарий: если не договоримся — идём в суд, где у нас сильная позиция, а у IT-компании — слабая
📌 Психологический момент: IT-компания предлагала «положить на полку», потому что хотела сохранить деньги, не доделывая работу. На переговорах я показала, что этот сценарий для них — худший. Либо они возвращают деньги сейчас и спокойно закрывают вопрос, либо мы идём в суд, где они с большой вероятностью проигрывают и теряют не только деньги, но и репутацию.
🏆 Результат переговоров: IT-компания согласилась на расторжение договора и возврат 4 500 000 рублей. Мы подписали соглашение о расторжении, деньги вернулись на счёт заказчика. Без суда, без экспертиз, без многомесячных тяжб.
В IT-сфере, как нигде, актуальна поговорка: «прогресс не стоит на месте». Пока ваш продукт «лежит на полке»:
- Обновляются библиотеки и фреймворки
- Меняются стандарты безопасности
- Устаревают интеграции с внешними сервисами
- Появляются новые технологии, которые делают ваш продукт неконкурентоспособным
📊 Реальность такова: Продукт, который нельзя внедрить сейчас, с высокой вероятностью не будет нужен и через год. Хранить его не имеет смысла. Лучше вернуть деньги и направить их на актуальные решения.
Наш клиент так и поступил. Вместо того чтобы годами ждать «условно готового» продукта и доплачивать за доработки, он вернул деньги и инвестировал их в работающее решение.
❌ Если бы согласились на условия разработчика
- Проект заморожен на неопределённый срок
- Нужно доплатить за доработки (сумма неизвестна)
- Когда продукт «дозреет» — непонятно
- Технологии устареют — продукт потеряет актуальность
- Деньги заморожены, результат отсутствует
- Итог: убыток более 4,5 млн руб. + потеря времени
⚖️ Если бы пошли в суд
- Хорошие шансы на победу, но не 100%
- Судебные расходы: пошлины, экспертизы, юристы
- Срок: от 6 до 12 месяцев
- Нервные затраты, риск апелляции
- Возврат денег — только после исполнительного производства
- Итог: победа, но дорого и долго
✅ А мы сделали иначе
- Провели глубокий анализ договора и продукта
- Подготовили сильную юридическую позицию
- Вышли на переговоры с IT-компанией
- Обосновали, почему их позиция слаба
- Добились расторжения и возврата 4,5 млн руб.
- Итог: деньги на счету, суда не было
Мы не просили — мы аргументировали. Показали IT-компании, что суд для них будет хуже, чем добровольный возврат. И они согласились.
Нельзя выиграть переговоры, не понимая, что именно разрабатывалось, как оно устроено и почему не работает. Я изучила структуру, архитектуру и нашла слабые места.
Прогресс не стоит на месте. Продукт, который нельзя внедрить сейчас, скорее всего, будет бесполезен и через год. Мы убедили в этом IT-компанию.
Мы пришли на переговоры с полным пакетом: анализ договора, технический разбор, правовое обоснование. Слабые аргументы IT-компании рассыпались.
Что я вынесла из этого дела:
IT-контракты — одни из самых сложных. В них важно не только юридически грамотно составить договор, но и понимать, что именно разрабатывается. Без погружения в продукт, его структуру, архитектуру — невозможно доказать, что результат не соответствует ожиданиям.
В этом кейсе мы не просто «пошли в суд». Мы разобрали продукт на части, нашли его слабые места, подготовили юридическую позицию и вышли на переговоры. И IT-компания, оценив свои риски, согласилась расторгнуть договор и вернуть деньги.
Потому что прогресс не стоит на месте. Пока продукт лежит — технологии уходят вперёд. Через год он будет не просто нерабочим, а устаревшим. Хранить такие продукты бессмысленно.
Что делать, чтобы не попасть в такую ситуацию?
- Чётко прописывать в ТЗ критерии готовности продукта
- Фиксировать сроки и этапы сдачи
- Предусматривать право отказа от договора при невозможности внедрения
- При споре — не тянуть, а готовить позицию и выходить на переговоры
Запомните: Разработчик, который предлагает «положить проект на полку» и доплатить потом — не решит вашу задачу. Вы рискуете потерять и деньги, и время, и актуальность продукта. Но иногда проблему можно решить переговорами — если правильно подготовиться. Я помогу проанализировать IT-контракт, найти слабые места оппонента и добиться расторжения с возвратом денег.
© Олеся Звягина — Бизнес-медиатор, переговорщик
Материалы защищены авторским правом. Использование только с разрешения