Все одиннадцать признаков ниже видны до подписания договора и ни один из них не требует технических знаний. Они описывают поведение исполнителя, а не его технологии: как он отвечает на вопрос об объёме работ, что делает с неопределённостью, где готов зафиксировать обязательство письменно, а где переводит разговор. Проверка укладывается в один созвон и час работы с открытыми источниками.
Оговорка, без которой список был бы нечестным: мы сами подрядчик и живём с продажи внедрений. Критерии ниже написаны так, чтобы работать против нас тоже. Если бюро ПРОЦЕСС не проходит по какому-то пункту — это ваш аргумент в переговорах с нами, а не наш недосмотр. Наши этапы, схема оплаты и точка выхода описаны на странице как мы работаем, обязательства и границы ответственности — на странице гарантий. Требуйте того же уровня конкретики от любого исполнителя, включая нас: подрядчик, который не может показать своё устройство работы до договора, скорее всего, не показывает его и после.
Дальше — таблица из одиннадцати признаков с механикой каждого; четыре серые схемы отрасли и во что они обходятся в рублях; пять признаков, которые ошибочно считают тревожными; проверки за час без ИТ-специалиста; три формулировки договора, молча переносящие риск на заказчика; и что делать, если признак нашёлся, а подрядчик всё равно выглядит лучше остальных.
Одиннадцать признаков в одной таблице
Признаки сгруппированы по тому, где они проявляются: три читаются прямо в присланном коммерческом предложении, пять слышны на первом созвоне, три обнаруживаются в проекте договора. Ни один из них не является приговором в одиночку — тревожной становится комбинация из трёх и более.
| Признак | Что за ним стоит | Как проверить |
|---|---|---|
| 1. Цена названа до обследования процесса | Объём не считали: взяли типовую цифру и добавили запас. Реальный объём вскроется на второй месяц | Спросить, из каких работ сложилась сумма и какая доля приходится на интеграцию |
| 2. Срок назван на первом созвоне | То же самое во времени. Срок без обследования — это оценка чужих предположений о вашем процессе | Спросить, что именно будет работать в продуктиве в названную дату |
| 3. В предложении нет раздела «не входит в работу» | Границы объёма не зафиксированы. Всё спорное позже окажется доработкой за отдельные деньги | Попросить приложение со списком исключений и допущений |
| 4. Один человек на все роли | Продаёт, проектирует, разрабатывает и поддерживает одно лицо. Его болезнь или новый заказ останавливают проект целиком | Спросить, кто заменит его на две недели и кто отвечает за архитектуру |
| 5. Не спросил, кто владелец процесса | Проект пойдёт без человека, который принимает решения о правилах. Приёмка упрётся в «а мы так не работаем» | Отследить на созвоне: прозвучал вопрос о том, кто согласует правила, или нет |
| 6. Не задаёт вопросов про исключения и ошибки | Проектирует идеальный сценарий. Исключения составляют 10–30 % потока и стоят половину бюджета | Спросить, что система делает, когда смежная система не ответила |
| 7. Называет точность числом без указания данных | «Точность 98 %» без выборки и без определения ошибки — маркетинговое число, непроверяемое на приёмке | Спросить, на какой выборке измерено и что считается ошибкой |
| 8. Уходит от вопроса, что будет после запуска | Модель заработка — разовый проект. Через месяц эксплуатации отвечать на инциденты будет некому | Спросить про договор поддержки, время реакции и стоимость в месяц |
| 9. Отказывается дробить проект на этапы | Требуется весь бюджет вперёд по единственному акту. У заказчика нет ни одной точки, где можно остановиться | Предложить схему 20/30/30/20 и посмотреть на реакцию |
| 10. Не фиксирует допущения письменно | Устные договорённости об объёме исчезают при первом споре. Останется только текст договора | Попросить приложение «оценка действительна при следующих условиях» |
| 11. Уклоняется от вопроса об исходниках и доступах | Строится зависимость: сменить исполнителя нельзя без переписывания решения с нуля | Спросить прямо, кому принадлежат код, лицензии и учётные записи после оплаты |
Схема из трёх вертикальных зон слева направо, соединённых стрелкой «время до подписания». Зона 1 «Видно в коммерческом предложении — 3 признака»: цена до обследования, срок до обследования, нет раздела «не входит в работу». Зона 2 «Слышно на первом созвоне — 5 признаков»: один человек на все роли, не спросил про владельца процесса, нет вопросов про исключения, точность числом без данных, уход от вопроса про поддержку. Зона 3 «Видно в проекте договора — 3 признака»: отказ дробить на этапы, нет письменных допущений, уклонение от вопроса про исходники. Внизу подпись: «тревожна комбинация из трёх и более, а не один пункт». Чертёжный стиль, все подписи по-русски.
Механика у всех одиннадцати одна и та же: исполнитель избегает точки, в которой возникает обязательство. Цена до обследования — обязательство без объёма, от него легко отказаться позже. Отсутствие раздела «не входит в работу» — отказ очертить границы. Уклончивый ответ про исходники — отказ признать, что после оплаты решение принадлежит вам. Поэтому проверять надо не компетенцию, которую вы не оцените, а готовность фиксировать: всё, что подрядчик готов записать в приложение к договору, он с высокой вероятностью и сделает.
Четыре серые схемы, о которых не рассказывают
Это не мошенничество в юридическом смысле — формально всё исполняется. Но экономика сделки при этом другая, чем вы думаете, и разница остаётся у подрядчика.
- 1Схема 1. Коробочный продукт под видом заказной разработки
Подрядчик покупает готовое решение или отраслевой модуль по прайсу вендора, настраивает его и выставляет счёт как за разработку. Формально работа сделана, система работает. Признак: в смете нет строки лицензии, но есть строка «разработка модуля» на сумму, сопоставимую со всем проектом. Проверка занимает пятнадцать минут: спросите, есть ли на рынке готовый продукт, закрывающий эту задачу, и почему он не подходит. Внятный ответ — норма; раздражение — ответ сам по себе. Разницу между покупкой готового и заказом мы разбирали в материале про готовое SaaS и заказную разработку.
- 2Схема 2. Вознаграждение от вендора без раскрытия
Партнёрское вознаграждение за проданную лицензию на рынке составляет 10–25 % её стоимости и само по себе законно. Проблема возникает, когда оно не раскрыто: вы считаете, что получили независимую рекомендацию, а получили продажу. Признак: подрядчик рекомендует один продукт во всех ситуациях и не может назвать задачу, на которой этот продукт неуместен. Прямой вопрос — «получаете ли вы вознаграждение от вендора и в каком размере» — снимает тему за минуту. Отказ отвечать здесь информативнее любого ответа.
- 3Схема 3. Работа под учётной записью заказчика
Подрядчик просит логин и пароль администратора вместо создания именной учётной записи для себя. Причина обычно бытовая — так быстрее. Последствия не бытовые: в журнале системы все действия выглядят как ваши, разграничить ответственность при инциденте невозможно, а отозвать доступ можно только сменой общего пароля, то есть с остановкой работы. Правильная схема описана отдельно — именные доступы подрядчику с журналированием и чек-листом отзыва при завершении проекта.
- 4Схема 4. Привязка через инфраструктуру
Серверы, домены, платные подписки и лицензии оформляются на юридическое лицо подрядчика «чтобы вам было проще». Проще действительно становится — до первого разногласия. После него у вас нет прав ни на что, а переезд стоит дороже повторной разработки. Признак: в договоре нет пункта о передаче доступов, а на вопрос о смене исполнителя звучит «этого не потребуется». Норма выглядит иначе: инфраструктура и лицензии оформлены на вас, подрядчик получает доступ, а после запуска сдаёт его по описи.
Две вертикальные колонки одинаковой ширины. Левая «Выставлено — 620 000 ₽», одна сплошная заливка с подписью «разработка модуля». Правая «Справедливая цена — 380 000 ₽», разделена на два сегмента: «лицензия готового продукта 240 000 ₽» и «настройка, 40 часов × 3 500 ₽ = 140 000 ₽». Между колонками фигурная скобка с подписью «переплата 240 000 ₽, это 63 %». Единицы — рубли, все числа подписаны, чертёжный стиль.
Пять ложных тревог: это норма рынка, а не флаг
Половина отказов в малом бизнесе происходит по признакам, которые ничего не значат. Ниже — пять самых частых, с объяснением, почему они не работают.
- Маленькая команда. Три-пять инженеров — типичный размер бюро, которое делает внедрения на 300 000–1 500 000 ₽. Значение имеет не численность, а наличие замены на каждой роли и того, кто отвечает за архитектуру. Вопрос «кто продолжит проект, если ведущий инженер уйдёт в отпуск» отвечает на это точнее, чем цифра в штатном расписании.
- Нет офиса и личных встреч. Удалённый формат снимает 30–40 % накладных расходов из цены, и это единственное, что он меняет. Флагом является другое: отсутствие договора, реквизитов и закрывающих документов. Если подрядчик работает без офиса, но по договору с актами и ЭДО, к формату претензий нет.
- Не называет клиентов. Соглашение о конфиденциальности запрещает раскрывать заказчика, и это обычная практика в проектах с доступом к учётным данным. Вместо списка имён просите обезличенное описание задачи с цифрами: объём операций, срок, что интегрировали, что пошло не так. Придумать такое описание сложнее, чем список логотипов.
- Отказывается писать бесплатное техническое задание. Полноценное ТЗ — это 40–80 часов работы, то есть 150 000–300 000 ₽. Бесплатно его делают только с расчётом отбить в цене проекта или не делают вовсе, подсовывая шаблон. Нормальная схема — платное обследование отдельным этапом, после которого техническое задание остаётся у вас независимо от продолжения работы.
- Просит аванс за первый этап. Аванс 20–30 % от стоимости первого этапа — рыночная норма: подрядчик закрывает свои расходы на старте. Флагом является не аванс, а его размер и привязка: предоплата 70–100 % всего проекта до первого результата означает, что у вас не осталось ни одного рычага.
Сравнение в две колонки. Левая «Не флаг — норма рынка»: команда из 3–5 инженеров, работа без офиса, клиенты под NDA, платное техническое задание вместо бесплатного, аванс 20–30 % за первый этап. Правая «Флаг»: цена и срок до обследования, предоплата 70–100 % всего проекта, нет раздела «не входит в работу», один человек на все роли, уклонение от вопроса про исходники. Левая колонка помечена нейтрально, правая — штриховкой. Внизу подпись: «отказ по левой колонке стоит дороже, чем кажется». Все подписи по-русски.
Час в открытых источниках без ИТ-специалиста
Четыре проверки ниже делает собственник самостоятельно, бесплатно и до первого созвона. В подавляющем большинстве сделок малого бизнеса их не делает никто.
- 1Юридическое лицо и срок его жизни. Выписка из реестра юридических лиц запрашивается на сайте налоговой службы бесплатно. Смотрите три вещи: дата регистрации, основной вид деятельности и адрес. Компания моложе года — не приговор, но она не может иметь трёхлетнего опыта, о котором рассказывает на созвоне. Несовпадение заявленного опыта с датой регистрации — самый частый и самый простой в обнаружении обман.
- 2Судебные дела. Картотека арбитражных дел открыта и ищет по названию и ИНН за минуту. Один-два спора за пять лет — обычная жизнь. Смотреть надо на роль и на серию: если компания регулярно выступает ответчиком по искам о взыскании неотработанного аванса, это тот же сценарий, который предлагают вам.
- 3Соответствие заявленной команды размеру компании. Сведения о среднесписочной численности публикуются налоговой службой. Если на созвоне звучит «у нас двадцать инженеров», а по данным отчётности числится два человека, работа идёт через подряд и самозанятых. Само по себе это законно и распространено — но тогда вопрос «кто заменит ведущего инженера» становится не формальным, и ответ на него должен быть в договоре.
- 4Собственный продукт и открытые цены. Наличие у подрядчика страниц с составом работ, вилками цен и описанием этапов — слабый, но полезный признак: тот, кто публикует диапазоны бюджетов с составом работ по каждому, уже прошёл через объяснение, из чего они складываются. Отсутствие любых цифр на сайте не является флагом само по себе, но лишает вас точки отсчёта до созвона.
Ни одна из четырёх проверок не отвечает на вопрос, хорошо ли подрядчик проектирует системы. Они отвечают на другой вопрос — совпадает ли то, что вам рассказали, с тем, что можно увидеть со стороны. Расхождение здесь важнее, чем любая техническая оценка: если человек преувеличивает там, где это легко проверить, к оценкам объёма и сроков стоит относиться так же.
Три формулировки договора, переносящие риск на вас
Эти формулировки встречаются в типовых договорах на разработку и выглядят безобидно. Каждая из них означает, что при споре доказывать что-либо будете вы. Полный разбор структуры договора мы выносили в отдельный материал — что должно быть в договоре на разработку; здесь только три пункта, которые встречаются чаще всего.
| Как звучит в договоре | Что это означает на практике | Чем заменить |
|---|---|---|
| «Исполнитель выполняет работы в соответствии с пожеланиями Заказчика» | Измеримого результата нет. Приёмка превращается в спор о вкусах, в котором выигрывает тот, у кого текст договора | «Результат достигнут при выполнении приёмочных сценариев приложения №2: 200 документов, доля ошибок не выше 5 %» |
| «Приёмка осуществляется по факту выполнения работ» | Оплачивается активность, а не результат. Работы выполнены — значит, приняты, независимо от того, работает система или нет | «Этап принят после подписания акта по критериям приёмки; при недостижении критериев исполнитель дорабатывает за свой счёт в срок 10 рабочих дней» |
| «Аванс 70 % в течение 3 банковских дней с даты подписания» | Основная часть денег уходит до первого проверяемого результата. Рычагов на оставшемся сроке проекта не остаётся | Оплата 20/30/30/20 по принятым этапам либо безопасная сделка с резервированием суммы этапа до приёмки |
Формулировка законная и сама по себе нормальная, но её надо дочитать до конца: что именно понимается под результатом. Если в перечне только «работоспособная система», исходный код, схемы интеграций и учётные записи туда не входят — и после полной оплаты вы получите работающий чёрный ящик. Рабочая формулировка перечисляет состав передачи явно: исходный код, документация, схема обмена, инструкции, доступы к инфраструктуре и лицензии, оформленные на заказчика. У нас это отдельный пункт договора, и мы считаем правильным, чтобы вы требовали его от любого исполнителя: передача исходников не должна быть предметом переговоров в конце проекта.
Признак нашёлся, а подрядчик всё равно лучший
Это частая и вполне рабочая ситуация: у исполнителя нашлись два признака из одиннадцати, но по остальным параметрам он объективно сильнее конкурентов. Отказываться не обязательно — обязательно ограничить размер возможной потери. Ниже — во что обходится решение «подпишем как есть» на модельном проекте в 780 000 ₽ с авансом 60 %.
Ступенчатая диаграмма слева направо. Первая площадка «Плановый бюджет — 780 000 ₽». Далее три ступени с подписями: «невозвратный аванс 60 % — 468 000 ₽», «повторный запуск с нуля — 780 000 ₽», «разбор чужого решения, 20 часов × 3 000 ₽ — 60 000 ₽». Верхняя площадка подписана «фактические расходы 1 308 000 ₽, переплата 528 000 ₽». Сбоку вертикальная отметка «плюс 3,5 месяца без изменений в процессе». Единицы — рубли, чертёжный стиль, подписи по-русски.
Ограничить риск можно тремя приёмами, и все три работают независимо от того, что подрядчик о себе рассказывает. Первый — разбить оплату по принятым этапам: схема 20/30/30/20 означает, что в любой момент времени под риском находится стоимость одного текущего этапа, а не всего проекта. Второй — вставить точку выхода после прототипа: гипотеза проверяется на ваших данных до основной разработки, и при отрицательном результате вы останавливаетесь, потеряв 20–30 % бюджета вместо ста. Третий — начать с оплаченного пробного этапа на 50 000–150 000 ₽ с самостоятельно полезным результатом; как его выбрать и оформить, разобрано в материале про пробный этап с подрядчиком.
Из всех проверок в статье одна работает почти безошибочно: предложите разбить проект на этапы с оплатой по приёмке и правом остановиться после прототипа. Исполнитель, уверенный в своей оценке, соглашается — для него это способ показать результат раньше. Исполнитель, который назвал цифру наугад, начинает объяснять, почему именно в вашем случае это неприменимо. Аргументы бывают разные, смысл один: он не готов к точке, где вы можете уйти. Это относится и к нам — если мы когда-нибудь откажемся дробить проект, используйте это против нас.
Когда подрядчик не нужен
Самая дешёвая проверка подрядчика — обнаружить, что он не нужен. Четыре ситуации, в которых деньги правильнее не тратить вовсе.
- Задача закрывается настройкой того, что уже куплено. В типовых конфигурациях учётных систем и в коробочных CRM значительная часть запросов решается штатными правилами, шаблонами документов и автозадачами. Два дня в документации продукта или один платный час консультации партнёра вендора закрывают то, за что подрядчику платят 200 000–400 000 ₽ как за разработку.
- Объём операций ниже порога окупаемости. При 60–80 однотипных операциях в месяц и одном сотруднике, который справляется, внедрение не окупится за 24 месяца: стоимость системы почти не зависит от того, сколько операций она обрабатывает. Считать надо до запроса предложений — методика разобрана в материале про окупаемость автоматизации.
- Процесс не описан и меняется каждый месяц. Автоматизировать нестабильный процесс — значит зафиксировать в коде временное состояние. Сначала стоит потратить 3–5 рабочих дней на аудит процесса своими силами: участники, объём операций, время на операцию, точки ошибок. После этого часть задач отпадает сама, а оставшиеся оцениваются вдвое точнее.
- Некому владеть результатом. Если в компании нет человека, который отвечает за процесс и имеет право менять правила, система будет построена, запущена и заброшена. Это самая частая причина мёртвых внедрений, и подрядчик здесь бессилен — мы разбирали её отдельно в материале про отсутствие владельца процесса.
И последнее, неудобное для нашей стороны рынка. Одиннадцать признаков выше не гарантируют качества: подрядчик может пройти по всем пунктам и всё равно сделать посредственное решение. Они гарантируют другое — предсказуемость потери. Проект, разбитый на этапы, с письменными допущениями, точкой выхода и передачей исходников, в худшем случае обходится вам в стоимость одного этапа. Проект без этого в худшем случае обходится в весь бюджет плюс повторный запуск. Выбирайте не того, кто убедительнее рассказывает, а того, кто согласен на конструкцию, в которой его ошибка стоит дёшево вам, а не только ему.
Проверяют не компетенцию, которую вы всё равно не оцените, а готовность зафиксировать обязательство письменно.
