Меня бесит эта ситуация. Не заказчик — ситуация.
Выглядит она так. Приходит компания с задачей: «нужна система с ИИ, которая будет анализировать наши данные и помогать принимать решения». Дальше — «назовите точную сумму и срок». Я объясняю, почему сумму назвать нельзя. Мне отвечают: «ну хотя бы примерно». Я объясняю, почему и примерно нельзя. Мне отвечают: «а конкуренты назвали».
И вот тут начинается самое тухлое. Потому что дальше по сценарию я должен либо назвать цифру с потолка и стать одним из тех, кто потом будет выкатывать допсоглашения, либо не назвать — и выглядеть человеком, который увиливает. Оба варианта плохие. Заказчик, кстати, тоже в ловушке: ему цифра нужна не из вредности, а потому что без неё его внутренняя машина не работает.
То есть бесит не человек напротив. Бесит ритуал, в котором обе стороны обязаны участвовать и обе тратят на него месяцы.
Ниже — попытка разобрать этот ритуал по косточкам и предложить, что с ним делать. С примерами.
Сначала о мотиве — я его долго понимал неправильно
Раньше я думал, что люди, которые требуют точную цену без описания задачи, просто хотят халявы. Хотят, чтобы подрядчик бесплатно сделал за них половину работы, а они потом пойдут с этим по рынку.
Иногда так и есть. Но чаще — нет.
Чаще напротив сидит человек, у которого своя проблема. Ему нужно провести бюджет через финансовый комитет. У него есть форма, в которой поле «сумма» обязательное. Он физически не может прийти к финдиру и сказать «стоимость выяснится в процессе» — ему просто не подпишут, и он это знает по опыту. Он не жадничает. Он застрял в собственной процедуре и ищет любой способ из неё выбраться.
Это меняет разговор целиком. Потому что у такой проблемы есть решение — и оно, что важно, на стороне подрядчика тоже.
Двухступенчатый бюджет. Сначала проводим маленькую сумму — на исследование и ТЗ. Она обычно проходит по упрощённой процедуре, без комитетов и тендеров, потому что мелочь. Потом, уже с готовым документом на руках, идём за основным бюджетом — и там сумма обоснованная, с расчётом, а не с потолка.
Более того: подрядчик может написать эту служебку сам. Полстраницы текста, объясняющего, почему первый этап отдельный и что будет на выходе. Отдать заказчику, чтобы он пошёл с ней к начальству. Занимает двадцать минут, снимает половину сопротивления и делает тебя союзником, а не препятствием.
Вот это сильная позиция. А «я не понимаю, чего вы добиваетесь» — слабая, потому что ты всё понимаешь, просто злишься.
Правило: не знаешь — делай этап, который даёт ответ
У каждого «мы не знаем» есть свой инструмент. Их четыре, и они не заменяют друг друга.
Не знаешь, какой функционал нужен → пиши ТЗ. Не знаешь, сработаешься ли с подрядчиком → проводи установочную сессию. Не знаешь, правильная ли идея → делай проектировку. Не знаешь, зайдёт ли идея людям → делай MVP.
Секретного пятого варианта, где ты получаешь твёрдую цену на то, о чём ещё не думал, не существует.
Не знаешь, какой функционал нужен — пиши ТЗ
Главное заблуждение: люди думают, что ТЗ пишут, когда уже всё понятно. Типа зафиксировать на бумаге то, что и так в голове.
Нет. ТЗ — это процесс, в котором понимание появляется. Ты не пишешь ТЗ, потому что знаешь. Ты знаешь, потому что написал ТЗ.
Живой пример. Производство мебели. Формулировка задачи целиком: «нужен личный кабинет для дилеров». На вопрос «что там должно быть» — «ну, всё что нужно дилеру».
Садимся писать. И начинается:
— Дилер видит заказы других дилеров своего региона? — Нет. Хотя стоп. Региональный руководитель должен, он же план ведёт. — Значит, минимум две роли. Кто заводит регионального руководителя? — Наш менеджер. — То есть нужна админка с управлением ролями. Цены у всех дилеров одинаковые? — Нет конечно, категории от объёма зависят. — Категория пересчитывается автоматически по обороту или руками? — (пауза) …а как лучше?
Вот в этой паузе и рождается проект. Начали с одной строчки — через две недели получили сорок страниц с ролевой моделью, статусами, интеграцией с 1С (о ней в первом разговоре вообще не вспоминали) и логикой пересчёта скидок. Итоговая цена отличалась от первоначальных ожиданий примерно втрое.
Не потому что накрутили. Потому что в голове был «личный кабинет», а в реальности — учётная система с ограниченным доступом.
Описание изображения в тексте (после этого раздела): Схема-сравнение на светлом фоне. Слева — маленький жёлтый прямоугольник «Личный кабинет» (как задачу видит заказчик). Справа — та же надпись, вокруг которой разрослось дерево из 15–20 связанных блоков: роли, статусы, интеграция 1С, уведомления, скидки, отчёты. Подпись: «Одна фраза в брифе = два месяца разработки».
Не знаешь, сработаетесь ли — установочная сессия
Единственный бесплатный этап в списке. И почему-то именно его чаще всего пропускают — «давайте сразу к делу».
Это не собеседование. Никто никого не оценивает. Это разговор про то, как вы оба устроены: кто принимает финальное решение, сколько людей будет согласовывать макеты, что бесило в прошлом подрядчике, как быстро вы отвечаете, готовы ли к тому, что первый вариант будет не тот.
Кейс, после которого я сделал эту сессию обязательной. Сеть автосервисов. Всё обсудили, ударили по рукам, начали делать. На третьей неделе выясняется, что человек, с которым я всё согласовывал, — операционный директор, а решает собственник. Который был в отпуске, вернулся, посмотрел и сказал: «Я это себе вообще по-другому представлял».
Три недели работы в мусорку. Не потому что кто-то плохой, а потому что на старте не прозвучал один вопрос: кто скажет финальное «да»?
Час-полтора времени, ноль рублей, иногда экономит месяцы.
Не знаешь, правильная ли идея — проектировка
Проектировка — это когда твоё видение накладывается на реальность рынка. И иногда реальность его слегка корректирует. Молотком.
Клиент хотел B2B-маркетплейс в узкой промышленной нише. Идея красивая: закупщики находят поставщиков, всё прозрачно, комиссия со сделок.
Начали с ресёрча — обзвонили полтора десятка закупщиков и спросили, как они выбирают поставщика сейчас. Ответы были примерно одинаковые: «Ну, у меня Серёга есть, я у Серёги беру». Восемь из десяти закупок шли через личные связи, выстроенные годами. Никакой маркетплейс это не разрушит, потому что дело не в цене, а в том, кто отгрузит в пятницу вечером, когда горит.
Проект не умер, он изменился: вместо маркетплейса «для всех» сделали закрытую тендерную площадку для уже существующей базы контрагентов. Клиент перестал завоёвывать рынок и начал автоматизировать то, что и так работало. Взлетело.
Проектировка стоила условно 15% бюджета и сэкономила весь бюджет целиком.
Не знаешь, зайдёт ли людям — MVP
MVP — это не «дешёвая версия продукта». Это инструмент для получения ответа на конкретный вопрос. И вопрос нужно сформулировать до старта, а ещё лучше — заранее договориться, какой ответ считается «да», а какой «нет».
Идея — приложение для записи к мастерам в небольших городах. Полноценная разработка: полгода и семизначная сумма. Вместо этого собрали за три недели один экран, список из двадцати мастеров одного района и кнопку «записаться», которая отправляла сообщение администратору в телеграм. Никакой автоматизации, всё руками.
Критерий успеха договорили заранее: если из первых 200 пользователей хотя бы 15% запишутся повторно — идём в разработку.
Вернулись 12 из 200. Шесть процентов. Проект закрыли. Клиент расстроился на пару дней, потом посчитал, сколько он не потратил, и расстраиваться перестал.
Бывает и наоборот: MVP делают прямо внутри проектировки — чтобы наглядно показать, как будет выглядеть продукт, и снять половину разногласий заранее. Тоже рабочая схема.
Почему всё это платное — и что заказчик получает взамен
Вот здесь и начинается главный спор. И, справедливости ради, спорят не на пустом месте.
Настоящая причина сопротивления — обычно не жадность. Это шрамы. Человек уже платил за «дискавери», получил сорок страниц воды с картинками из интернета, а потом подрядчик всё равно сказал «это в объём не входило». Рынок паршивых проектировок существует, он большой, и заказчик защищается от него, а не от тебя лично.
Понимать это — надо. Но дальше нужно сказать вторую половину, и её обычно стесняются говорить.
Твой негативный опыт — не мой долг. Если тебя сто раз обманули, это не значит, что сто первый подрядчик обязан бесплатно сделать часть работы, потому что ты пострадал. Исследование стоит времени команды независимо от того, как с тобой обошлись предыдущие. Сочувствие — да. Скидка за чужие грехи — нет.
Правильный ответ на шрамы — не бесплатная работа, а прозрачные условия. Вот что должно быть проговорено до подписания, и вот что снимает сопротивление лучше любых аргументов:
- Что конкретно на выходе. Не «документ», а перечень: схема ролей, карта экранов, описание сценариев, требования к интеграциям, оценка по этапам. Список артефактов, который можно проверить.
- Чей это результат. ТЗ принадлежит заказчику. Решил делать не у нас — забрал и ушёл, хоть на тендер с ним иди. Именно для этого оно и нужно: чтобы сравнивать не фантазии подрядчиков, а предложения по одному документу.
- Зачёт стоимости. Если разработку делаем мы — часть стоимости ТЗ идёт в зачёт основного договора. Это честно и снимает подозрение, что этап придуман ради денег.
- Что считается провалом этапа. Заранее. Пока все ещё вежливые.
Одно предложение про зачёт стоимости работает лучше, чем три абзаца рассуждений о профессионализме. Проверено.
А вот на что соглашаться не надо никогда — на бесплатную «предварительную оценку по-серьёзному». Потому что у подрядчика в этой ситуации всего три пути: заложить огромный риск и назвать пугающую цифру, занизить и потом добирать допсоглашениями, или отказаться. Третий вариант самый честный, и я к нему прихожу всё чаще.
Аналогия: сколько стоит «сделать нам свою нейросеть»
Обычно в этом месте рассказывают про стоматолога и архитектора. Плохие аналогии: стоматолог даёт прайс по позициям, архитектор берёт процент от сметы. Оба называют цифру заранее, и заказчик это прекрасно знает.
Возьмём честную. Представь, к тебе приходят и говорят: «Хотим свою языковую модель, локальную, чтобы данные наружу не уходили. Сколько?»
Правильный ответ — «а что именно вы хотите?», и вот почему:
- Взять готовую открытую модель и просто развернуть на своём сервере — это работа на неделю. Основные деньги уйдут на железо.
- Дообучить её на своей базе документов — уже сложнее, но реально: нужен подготовленный датасет, несколько итераций, оценка качества. Недели, не месяцы.
- Обучить модель с нуля под свою задачу — это бюджет уровня научной лаборатории, команда исследователей и год-два.
Три ответа на один вопрос. Разница между первым и третьим — в тысячи раз. И пока не понятно, какой сценарий нужен, любая цифра — это фантазия. Причём даже второй, самый «нормальный» вариант упирается в вопрос, на который до аудита ответа нет: а данные-то в каком состоянии? Потому что если базы документов по факту нет, а есть три папки на разных компьютерах и половина в сканах — то это не дообучение модели, а сначала полгода наведения порядка в данных.
Никакой конус неопределённости тут не поможет. Он работает, когда известен класс задачи. Здесь неизвестен даже класс.
Описание изображения в тексте (после этого раздела): Тёмный фон. Три горизонтальные полосы разной длины, идущие от общей точки слева. Первая короткая, подпись «Развернуть готовую модель». Вторая заметно длиннее — «Дообучить на своих данных». Третья уходит за правый край кадра со стрелкой — «Обучить с нуля». Все три выходят из одного жёлтого круга с надписью «Хотим свою нейросеть». Подпись внизу: «Один вопрос. Три ответа. Разница в тысячи раз».
Что делать, если цену назвать действительно нельзя
Здесь я поправлю сам себя, потому что «точную сумму никто и никогда не скажет» — фраза правильная, но звучит как отговорка.
Уточню: нельзя назвать цену продукта. Можно и нужно назвать цену следующего шага.
Если задача исследовательская — а «система с ИИ, которая анализирует наши данные» почти всегда исследовательская — первым продаётся не разработка, а аудит данных. Фиксированная цена, фиксированный срок, три-четыре недели. На выходе документ, который отвечает на вопросы, без которых оценка невозможна физически:
- Какие данные есть в реальности. Сколько записей, за какой период, в каком формате, лежат централизованно или по разным машинам.
- Есть ли связка с результатом. Самое важное. Модель учится на паре «вход → правильный ответ». Если правильного ответа в машиночитаемом виде нет — датасета нет, и первый год проекта уйдёт на его создание вручную. Это отдельный проект с отдельным бюджетом.
- Согласны ли эксперты между собой. Дай нескольким специалистам одну выборку вслепую. Сходятся в 60% случаев — потолок модели примерно там же. Об этом честнее узнать в начале.
- В каком правовом контуре живёт продукт. Особенно если речь про медицину, финансы или персональные данные. Внутренний инструмент «в помощь специалисту, решение принимает человек» и сертифицированный продукт — это разные вселенные по деньгам и срокам. Иногда сертификация дороже всей разработки.
- Что считается успехом. Конкретной цифрой на конкретной выборке. Не «система должна помогать», а «точность не ниже X на отложенных данных объёмом Y».
И только после этого — оценка пилота. Не всего продукта, а пилота, с правом остановиться.
Так ты не врёшь про цену и не выглядишь увиливающим. Ты говоришь: стоимость системы назвать невозможно, вот почему; стоимость шага, который сделает её вычислимой, — такая-то; срок такой-то; результат такой-то.
Для типовых задач, кстати, всё проще, и цифры называются сразу. Лендинг — от 39 000 ₽, ТЗ там описывается голосом за двадцать минут. Корпоративный сайт — 80 000–200 000 ₽. Интернет-магазин — 150 000–500 000 ₽. Вилки широкие, но существуют, потому что это продукты с известной анатомией. А «система с ИИ» — не продукт, это направление движения. Ценника на направление движения не бывает.
Какую бы методологию ни выбрали — ТЗ всё равно будет
Отдельно про любимое возражение: «мы работаем по Agile, там ТЗ не нужно».
В Agile ТЗ тоже есть, просто называется бэклогом и пишется кусками. User story — это ТЗ на одну функцию. Acceptance criteria — раздел «требования к приёмке». Ты не отменил документ, ты нарезал его на карточки и растянул во времени. И если общую архитектуру никто заранее не продумал — на пятом спринте выяснится, что базу данных надо переделывать, потому что в первом про мультиязычность не подумали.
Fixed price, Time & Material, Agile, водопад — везде первым шагом идёт описание того, что делаем. Меняется глубина и момент, когда ты это описываешь. Не сам факт.
Любой документооборот в итоге упрётся в ТЗ. А чтобы его написать, нужно спроектировать систему. Насколько глубоко — вопрос бюджета и хотелок. Круг замкнулся, обходного пути нет.
Это не проект. Это прикладное исследование
И вот главное, что я хочу сказать всем, кто приходит с задачами про ИИ.
То, что вы описываете, — не проектная работа. Даже не стартап, если честно. У стартапа хотя бы понятно, что строить, неизвестно только, купят ли. У вас неизвестно, возможно ли построить это в принципе.
Никто не скажет, насколько хорошо будет работать система, даже обучив её наполовину. Метрика на тестовой выборке 87% — а на ваших боевых данных, где половина полей заполнена криво, а вторая половина заполнена «как менеджер понял, так и записал», будет 61%. И это выяснится только по факту.
Это огромный подводный валун, с которым придётся считаться всем. Обойти нельзя. Можно только договориться, что он есть.
Это плата за использование технологий, которые развиваются очень быстро — настолько быстро, что часть рынка вообще считает происходящее пузырём. Библиотека, на которой вы стартовали, за девять месяцев дважды сменит мажорную версию. Модель, лучшая на старте, к релизу окажется устаревшей и вдвое дороже в эксплуатации.
Как с этим жить:
- Отдельный исследовательский этап с гипотезами, критериями и жёстким дедлайном. Не «делаем ИИ», а «за четыре недели проверяем, вытягивает ли модель точность выше 80% на исторических данных».
- Право остановиться после каждого этапа. В договоре, а не в переписке.
- Заранее оговорённый провал. Что именно считается «не получилось» и что происходит дальше.
Это не страховка от неудачи. Это способ сделать неудачу дешёвой и быстрой, если она случится.
Чек-лист: как выглядит нормальный старт
- Провели установочную сессию, выяснили, кто принимает финальное решение
- Сформулировали проблему, а не решение (не «нужна система», а «специалисты тратят 4 часа в день на ручную работу»)
- Заказчик понял и провёл двухступенчатый бюджет: сначала маленький на исследование, потом основной
- Подрядчик письменно зафиксировал, что будет на выходе первого этапа — списком артефактов
- Договорились, что результат этапа принадлежит заказчику и уходит вместе с ним
- Договорились о зачёте части стоимости в основной договор
- Критерии успеха записаны цифрами, а не ощущениями
- В плане есть точки, где можно остановиться без скандала
- Для исследовательских задач принято и записано: финальный результат заранее неизвестен
FAQ
Сколько стоит разработка ТЗ? Зависит от масштаба: от нескольких десятков тысяч за небольшой сервис до 10–20% бюджета разработки для крупной системы. Сроки — от недели до полутора-двух месяцев. Для исследовательских задач первым идёт не ТЗ, а аудит данных, и он оценивается отдельно.
Если я закажу ТЗ у вас, я обязан делать проект у вас? Нет. Документ ваш, забирайте и идите с ним куда хотите. Более того, нормальное ТЗ для того и нужно — чтобы получить сопоставимые предложения от разных подрядчиков и сравнить цифры, а не обещания.
Можно обойтись без ТЗ вообще? Можно, если задача типовая и небольшая: лендинг, визитка, доработка существующего модуля. Достаточно брифа и разговора. Как только появляются роли, интеграции или бизнес-логика — без ТЗ проект превращается в лотерею.
У нас нет бюджета на все этапы. Что делать? Резать не этапы, а глубину. Проектировка на неделю вместо месяца, ТЗ на ключевой модуль вместо всей системы, MVP на одном сценарии вместо пяти. Это работает. А «давайте пропустим ТЗ и сразу начнём» — не работает никогда.
Мы уже платили за проектировку другому подрядчику и получили пустышку. Почему сейчас должно быть иначе? Потому что до начала работ фиксируется конкретный перечень результатов, а не абстрактный «документ». Есть список артефактов, есть критерии приёмки, есть условие зачёта стоимости. Если на выходе получается не то, что описано, — это видно сразу и обсуждается по списку, а не по ощущениям.
Что дальше
Если у тебя задача, которая пока звучит как «нам нужна система, которая…» — приходи, обсудим на установочной сессии. Бесплатно, без обязательств и без попыток что-то продать. Разберёмся, что у тебя: проект, стартап или всё-таки исследование. Это три разных разговора про деньги.
А Квадрат — студия разработки и дизайна из Уфы. Пишем ТЗ, проектируем, спорим с заказчиками и иногда пишем об этом статьи.