«Пропустили один пункт договора», или как уйти по проекту в минус на 30% бюджета.
Проект по разработке приложения для ведения финансового учёта был принят клиентом. Клиент был доволен. Мы уже выдыхали. А через минуту стало понятно, что этот проект уйдёт в минус. Не из-за ошибок в разработке или коде и не из-за плохого прода — а из-за одного малейшего пункта в договоре, который никто не обсудил и не сказал.
Вот тут мы и прое...Предыстория.
Это было в самом начале пути продуктовой команды цифрового агентства. Рынок только нагревался, громких кейсов почти не было, а любой крупный клиент считался билетом в высшую лигу. И наконец клиент появился.
Большой. Известный. С весомым именем - которое, разумеется, здесь мы не называем, назовем его ООО "Зайчики".
Меня зовут Кирилл, учусь в НИУ ВШЭ, работаю продуктовым-аналитиком в цифровом агентстве.
Время рассказать одну нетривиальную и поучительную историю - "факап одного проекта".
Сделка
Этот проект изначально был сделкой почти без денег.
Мы договорились о цене, при которой заработок был символическим - в лучшем случае 3-5%. Осознанно. Нам был важен не доход, а сам факт работы с крупным клиентом. Кейс в портфолио разработчиков. Логотип. Возможность показать, что мы умеем работать на серьёзном уровне, а не на уровне вайб-кодинга...
Классическая история «работаем на имя». Может тут факап?
Проект был сложным. Много требований, много ожиданий, много правок, бэклог разрывался. Разработка заняла больше времени и ресурсов, чем хотелось бы, но это никого не удивляло - мы знали, на что идём.
К дедлайну продукт был готов.
Презентация
Мы приехали на финальную приёмку. Показали функционал. Прошлись по сценариям. Ответили на вопросы.
Заказчик, директор ООО "Зайчики", внимательно смотрел, кивал, уточнял детали. В какой-то момент сказал фразу, ради которой всё это и затевалось:
« — Всё отлично. Принимаем.»
Внутри — облегчение. Проект закрыт. Можно выдохнуть. ВСЁ...
А где факап?
Мы уже начали сворачиваться, когда он, как будто между делом, обратился к ассистенту:
« — Принеси, пожалуйста, компьютер на Linux'е.»
В этот момент стало тревожно. Не из-за самой просьбы, а потому что в голове мгновенно всплыл договор. И за пару секунд стало ясно: в нём был пункт про дополнительную версию продукта под другой формат —это была адаптация под Linux.
Формально — всё корректно, юридически тоже.
Но фактически:
- команда делала одно,
- продавали другое,
- а этот пункт никто не проговорил как полноценную часть проекта.
На чём можно поучиться из этой ситуации?
Дальше всё пошло по предсказуемому сценарию:
— срочные доработки,
— сдвиги сроков,
— штрафы,
— давление со стороны клиента.
Проект, который изначально делался почти без прибыли, быстро ушёл в минус. В итоге мы потеряли около 30% бюджета.
Не из-за плохого продукта. Не из-за ошибок в разработке. А из-за банально одного непроговорённого абзаца.
Вот и классическая ловушка.
Сначала казалось, что проблема в договоре. Но если смотреть честно — ошибка была глубже.
Мы попали в классическую ловушку "работы на имя":
- продажи закрывали сделку,
- проектная команда жила своим пониманием объёма,
- а общей точки синхронизации не было.
Каждый считал, что «это и слону понятно». Но в бизнесе такие предположения всегда заканчиваются одинаково.
Особенно опасно это в проектах с минимальной маржой. У них нет запаса:
- ни по деньгам,
- ни по времени,
- ни по ошибкам.
Любое дополнительное требование мгновенно делает такой проект убыточным.
Что мы поняли после?
Этот проект был болезненным, но полезным. После него мы пересобрали процесс:
- договор всегда разбирается вместе с проектной командой;
- каждый пункт переводится в конкретные сценарии работ;
- пограничные требования фиксируются отдельно;
- проекты «на имя» проходят более жёсткую проверку, чем прибыльные.
Старт некоторых проектов стал медленнее. Зато сюрпризов стало в разы меньше.
Главный вывод.
Мораль сей басни такова.
Большинство проблем в проектах начинаются не на этапе разработки не на финальной презентации.
Они начинаются в тот момент, когда кажется, что «и так всё понятно».
Иногда одна фраза в конце встречи стоит дороже всего проекта.
После этого кейса мы всегда в конце финальной встречи проговариваем объём работ вслух и задаём один простой вопрос:
«— Есть ли что-то в текущих договорённостях, что вы ожидаете увидеть в продукте, но что мы сегодня не обсудили отдельно?»
Если появляются новые детали, мы фиксируем их сразу или выносим в отдельный этап. Эта минута уточнений почти всегда дешевле, чем переделки и споры после приёмки.