Три вопроса отсеивают большинство. Первый: покажите этот же процесс на наших данных, а не на демо. Второй: что произойдёт, когда упадёт второй шаг цепочки. Третий: кому принадлежат исходники, доступы и данные после окончания работ. Если подрядчик уверенно отвечает на все три, разговор имеет смысл продолжать.
Ниже разобраны восемь вопросов целиком: зачем спрашивать, как звучит хороший ответ и как звучит плохой. Этим списком можно проверить любого исполнителя, включая меня. Он для того и написан.
Почему демо больше ничего не доказывает
Демо всегда работает. Его собирали на подготовленных данных, с простыми параметрами и без исключений, и в этом нет обмана: показать возможность иначе нельзя. Обман начинается там, где демо выдают за доказательство того, что система выдержит реальную работу.
Разница видна на цифрах эксплуатации. Цепочка, которая безупречно отработала тридцать раз на подготовленном наборе, в реальном потоке падает на первой же неделе: пришёл документ сканом, в названии компании оказалась опечатка, интеграция вернула ошибку вместо данных, а сотрудник отправил в систему архив за три года.
Поэтому правильная просьба звучит не «покажите демо», а «покажите, что произойдёт, когда упадёт второй шаг». Реакция на эту фразу говорит о подрядчике больше, чем всё предыдущее общение.
Восемь вопросов, которые стоит задать
| Вопрос | Хороший ответ | Плохой ответ |
|---|---|---|
| Покажите процесс на наших данных | «Дайте выгрузку за неделю, покажу через несколько дней. Часть, скорее всего, разберётся плохо, и мы увидим, что именно» | «У нас есть готовое демо, оно точно так же работает» |
| Что произойдёт, когда упадёт второй шаг | «Задача уйдёт в очередь к человеку с описанием сбоя и не пройдёт дальше как выполненная» | «Такого не бывает» или «система сама разберётся» |
| Кто отвечает за повторные попытки и проверку | «Три попытки с паузой, потом человек. Ответственный назначается по имени» | «Всё логируется», без объяснения, кто эти логи читает |
| Как докажете, что система изменилась, а не вернула «ок» | «После каждого действия перечитываем состояние и сверяем с ожидаемым» | «Мы проверяем код ответа сервера» |
| Что останется ручным после внедрения | Конкретный список с объяснением, почему именно это | «Практически ничего» или «всё будет автоматизировано» |
| Сколько это будет стоить в эксплуатации через год | Разбивка: вызовы модели, хостинг, сопровождение, порядок суммы | «Зависит от нагрузки», без единой цифры |
| Кому принадлежат исходники, доступы и данные | «Всё оформляется на вас с первого дня» | «Мы предоставляем доступ к нашей платформе» |
| Что будет, если мы уйдём к другому подрядчику | «Заберёте репозиторий и документацию, работать продолжит» | Пауза, потом разговор про «уникальность нашего решения» |
«Покажите этот же процесс на наших данных, а не на демо»
Зачем спрашивать: разница между показанным и реальным качеством и есть та величина, за которую вы потом платите. Хороший ответ включает признание, что часть данных разберётся плохо: это значит, что человек уже работал с чужим бардаком. Плохой ответ - предложение посмотреть демо ещё раз.
«Что произойдёт, когда упадёт второй шаг цепочки?»
Зачем спрашивать: сбои неизбежны, и вопрос только в том, спроектировали их или нет. Хороший ответ описывает конкретный маршрут: задача не исчезает, не проходит дальше как выполненная, уходит человеку с описанием проблемы. Плохой ответ - «такого не бывает» и любые вариации.
«Кто отвечает за повторные попытки и проверку результата?»
Зачем спрашивать: повторная попытка без ограничения превращается в бесконечный цикл и в счёт за вызовы модели. Хороший ответ называет число попыток, паузу между ними и человека, который разбирает то, что не прошло. Плохой ответ - «всё логируется»: логи, которые никто не читает, не отличаются от их отсутствия.
«Как вы докажете, что система действительно изменилась, а не вернула "ок"?»
Зачем спрашивать: это самая тихая поломка интеграций. Сервер отвечает «принято», а данные не изменились, потому что сработало правило автоматизации или не хватило прав. Хороший ответ: после действия состояние перечитывается и сверяется с ожидаемым. Плохой ответ: проверка кода ответа сервера, которая ничего не гарантирует.
«Что останется ручным после внедрения?»
Зачем спрашивать: честный исполнитель заранее очерчивает границу. Хороший ответ - конкретный список: разговор с недовольным клиентом, решения о деньгах, спорные случаи, редкие операции. Плохой ответ - обещание, что ручной работы не останется. Такое обещание означает, что процесс не смотрели.
«Сколько это будет стоить в эксплуатации через год?»
Зачем спрашивать: разработка это разовый платёж, а эксплуатация идёт постоянно, и по публичным разборам рынка первый год добавляет 30-50% к стоимости разработки. Хороший ответ разбивает сумму по статьям и называет порядок. Плохой ответ - «зависит от нагрузки» без единой цифры и без предложения посчитать.
«Кому принадлежат исходники, доступы и ключи?»
Зачем спрашивать: от этого зависит, останетесь ли вы с работающей системой или с подпиской на чужую. Хороший ответ: всё оформляется на компанию заказчика с первого дня. Плохой ответ: «мы предоставляем доступ к нашей платформе» - тогда вы покупаете не систему, а аренду.
«Что будет, если мы захотим уйти к другому подрядчику?»
Зачем спрашивать: это проверка предыдущего ответа делом. Хороший ответ спокойный: заберёте репозиторий и документацию, система продолжит работать. Плохой ответ начинается с паузы и переходит в рассказ об уникальности решения.
Красные флаги
Гарантия стопроцентной точности. Её не даёт никто, потому что дать невозможно. Обещание такой гарантии означает либо отсутствие опыта, либо расчёт на то, что вы не проверите.
Слово «нативная интеграция» без объяснения, что именно нативно. Чаще всего за ним стоит адрес, куда можно отправить данные, и пожелание удачи.
Отказ назвать порядок цены до подписания. Точную сумму без разбора процесса действительно назвать нельзя, а границу и то, что её двигает, назвать можно всегда.
Презентация вместо разговора о вашем процессе. Если на первой встрече вам сорок минут показывают слайды про возможности искусственного интеллекта и ни разу не спрашивают, как у вас устроена работа, дальше будет так же.
Обещание заменить сотрудников. Кроме того, что оно почти всегда ложное, оно ещё и гарантирует сопротивление внутри компании.
Нежелание отдавать исходники. Обсуждается это до договора, а не после сдачи.
Агентство, фрилансер или один специалист
| Вариант | В чём сильнее | В чём слабее | Кому подходит |
|---|---|---|---|
| Агентство | Объём, замена людей на проекте, формальные процессы | Вы говорите с менеджером, а не с исполнителем; задача теряется при передачах; дороже | Крупным компаниям с несколькими параллельными потоками работ |
| Один специалист | Прямой разговор с тем, кто пишет код; прозрачность; быстрые решения | Риск одного человека; ограничение по объёму; занятость | Малому и среднему бизнесу с понятной задачей |
| Фрилансер с биржи | Дёшево, быстро на старте | Часто продаётся сценарий вместо системы; сопровождения нет; исходники и документация как повезёт | Разовым мелким задачам, где цена ошибки низкая |
Дешевизна плохой ориентир, но и высокая цена ничего не гарантирует. Ориентир один: способность отвечать на восемь вопросов выше конкретно, а не общими словами.
Как устроен нормальный вход в работу
Здоровая схема состоит из трёх этапов. Сначала бесплатный разбор: подрядчик смотрит процесс и говорит, есть ли смысл. Потом небольшой платный шаг с фиксированной ценой на одной задаче. И только после него полное внедрение.
Смысл среднего этапа в том, что обе стороны платят за проверку гипотезы небольшими деньгами. Заказчик рискует суммой, которую не жалко, и получает право отказаться. Исполнитель видит реальные данные до того, как назовёт цену за большую работу.
Подрядчик, который предлагает сразу подписать договор на полное внедрение, либо не сомневается в задаче зря, либо рассчитывает, что вы не станете останавливать работу на середине из-за уже потраченных денег.
Что проверить в договоре
Кому принадлежат результаты. Формулировка должна называть исходный код, документацию и данные отдельно, а не ограничиваться словом «результаты работ».
Что считается приёмкой. Хорошо, когда критерий измеримый: система обрабатывает столько-то заявок в день с такой-то долей ручной проверки. Плохо, когда приёмка это подписанный акт без содержания.
Что происходит при отказе системы в первый месяц. Кто чинит, за чей счёт и в какой срок.
Кто платит за вызовы модели и хостинг. Эти расходы идут постоянно, и они должны быть названы до начала, а не появиться в первом счёте.
Что происходит при досрочном расторжении: что вы забираете и в каком виде.
Частые вопросы
Как понять, что подрядчик завышает цену?
Сравнить с публичными ориентирами рынка. Ориентиры и разбор того, что стоит внедрение и сколько стоит владеть системой, собраны на отдельной странице. Но низкая цена такой же плохой сигнал, как высокая: за суммы вдвое ниже рынка обычно продают сценарий из нескольких кнопок вместо системы, а разница всплывает на второй месяц эксплуатации. Проверять надо не цифру, а то, что в неё входит и что не входит.
Стоит ли брать подрядчика без кейсов в моей отрасли?
Обычно да, если он умеет разбирать процессы. Отраслевая специфика чаще живёт в требованиях к данным и в согласованиях, а не в технологии, и разбирается за неделю наблюдения. Исключение - регулируемые сферы вроде медицины и финансов: там опыт работы с требованиями отрасли экономит месяцы и снижает риск, который деньгами не закрывается.
Что важнее: технологии или понимание процесса?
Понимание процесса. Заказчик покупает исход, а не набор возможностей. Подрядчик, который перечисляет фреймворки и модели, но не задаёт вопросов о том, как у вас устроена работа, будет автоматизировать своё представление о вашем процессе. Обратный случай тоже бывает, но реже: человек, разобравшийся в процессе, обычно способен подобрать технологию, а не наоборот.
Можно ли сначала попробовать бесплатно?
Бесплатным бывает разбор: полчаса разговора, по итогам которого вам говорят, есть ли смысл. Бесплатной разработки не бывает, и предложение сделать первый проект даром - плохой знак: либо стоимость заложат в следующий этап, либо работу сделают по остаточному принципу. Нормальная схема - небольшой платный шаг с фиксированной ценой, где сумма известна заранее.
Как проверить, что подрядчик не пропадёт?
Проверять надо не человека, а устройство работы. Если исходники, доступы, ключи и документация лежат у вас с первого дня, а система работает на вашей инфраструктуре, исчезновение подрядчика становится неприятностью, а не катастрофой: систему подхватит другой разработчик по документации. Если же всё живёт на стороне исполнителя, никакие заверения в надёжности не помогут.
Что дальше
Этот список для того и написан, чтобы им можно было проверить любого. Если после восьми вопросов вы захотите задать их мне, у меня есть бесплатный разбор на тридцать минут: смотрим процесс, я отвечаю на всё перечисленное и говорю, где ИИ даст результат, а где не нужен. Что входит во внедрение под ключ, описано отдельно, а кто я и что делал - на странице обо мне.
Написать можно в Telegram или на почту hi@za-ai.ru.