Собственнику без ИТ-специалиста бесполезно проверять технологии: любую названную ему архитектуру он не оценит, а любой уверенный ответ примет за компетентный. Проверять надо поведение, и здесь у него преимущество перед любым техническим экспертом — он двадцать лет читает людей на переговорах. Следы инженерного мышления видны без словаря: как человек обращается с неопределённостью, что он делает, когда не знает ответа, и какие вопросы задаёт вам сам.

Пять проверок ниже занимают один созвон и не требуют ни одного технического термина. Ещё три способа купить внешнюю оценку стоят от 8 000 до 40 000 ₽ — заметно дешевле, чем нанимать ИТ-директора ради одного проекта. И отдельный честный раздел: три вещи, которые без специалиста не проверяются никак, и чем их компенсировать в договоре.

Мы сами подрядчик, поэтому оговорка обязательна: все проверки написаны так, чтобы применяться к нам тоже. Наши этапы, их длительность и результат каждого выложены на странице как мы работаем, обязательства и границы ответственности — на странице гарантий. Если на созвоне с нами вы не получите ответов в том виде, который описан ниже, — это ваш аргумент, а не наш.

Пять проверок, для которых не нужен технический язык

Все пять задаются на первом созвоне и занимают вместе минут двадцать. Оценивается не содержание ответа, а его структура: есть ли в нём границы, числа и условия.

  1. 1
    1. «Объясните ваше решение на языке моего процесса»

    Попросите пересказать предлагаемое решение так, чтобы это понял ваш кладовщик или бухгалтер: что приходит на вход, что происходит дальше, что получается на выходе, кто и когда вмешивается. Тот, кто разобрался в процессе, делает это за три минуты и без единого термина. Тот, кто не разобрался, уходит в архитектуру, потому что там его не проверить. Это самый информативный из пяти вопросов: невозможность объяснить просто почти всегда означает, что упрощать пока нечего.

  2. 2
    2. «Что произойдёт, если учётная система не ответит десять минут?»

    Любая система живёт среди чужих сервисов, которые падают, обновляются и меняют форматы. Рабочий ответ содержит четыре элемента: заявка попадает в очередь, делается несколько повторных попыток, событие пишется в журнал, ответственному уходит уведомление. Ответ «такого не бывает» или «мы всё протестируем» означает, что исключения не проектировались, а на них приходится 10–30 % потока и примерно половина бюджета. Подставляйте в вопрос любую смежную систему: телефонию, банк, маркетплейс.

  3. 3
    3. «Назовите три риска этого проекта»

    У инженера риски есть всегда, и они конкретны: качество справочников, доступность интерфейса обмена, отсутствие человека, который принимает решения о правилах, сезонная нагрузка. Он назовёт их сам и скажет, как каждый снимается. Ответ «рисков не вижу, задача типовая» — не уверенность, а отсутствие обследования: типовых процессов не бывает, различия начинаются на втором вопросе. Отдельно отметьте, назвал ли он риски на вашей стороне — это признак того, что он видел, как проекты умирают.

  4. 4
    4. «Расскажите про самый дорогой провал в вашей практике»

    Вопрос проверяет не опыт неудач, а способность о них говорить. Правильный ответ конкретен: что взялись делать, где ошиблись в оценке, сколько это стоило и что изменили в работе после. Ответ «провалов не было» означает одно из двух — либо проектов было мало, либо человек не считает провалом то, что заказчик считает. Обе версии стоит уточнить, потому что оценивать ваш проект будет тот же самый человек.

  5. 5
    5. «Покажите, как вы планируете приёмку»

    Просите не документ, а описание словами: на какой выборке проверяем, что считается ошибкой, какой порог допустим, кто подписывает. Готовый ответ звучит примерно так: «200 ваших реальных документов, ошибкой считается неверно извлечённое поле, порог — не выше 5 % ошибок, подписывает главный бухгалтер». Если приёмка описывается как «покажем, что работает», это демонстрация, а демонстрация проходит всегда. Как формулировать критерии заранее, разобрано в материале про приёмку работ по автоматизации.

сравнениеkak-proverit-podryadchika-bez-it-spetsialista--01
Пять вопросов подрядчику и разница между ответом инженера и ответом продавца

Таблица-сравнение из пяти строк и трёх колонок. Колонка 1 «Вопрос»: объясните решение на языке процесса; что при отказе учётной системы; назовите три риска; самый дорогой провал; как планируете приёмку. Колонка 2 «Ответ инженера»: пересказ без терминов за 3 минуты; очередь, повтор, журнал, уведомление; три конкретных риска, часть на стороне заказчика; провал с числами и выводом; 200 документов, порог 5 %, подписывает бухгалтер. Колонка 3 «Ответ продавца»: уход в архитектуру; «такого не бывает»; «задача типовая»; «провалов не было»; «покажем, что работает». Колонка 3 помечена штриховкой. Все подписи по-русски.

Оценивается не содержание ответа, а его структура: границы, числа, условия

Считать результат просто: из пяти вопросов три должны получить структурный ответ. Структурный — значит содержащий либо число, либо условие, либо границу. «Очередь и три повторные попытки, после этого уведомление ответственному» — структурный. «Мы всё предусмотрим» — нет. Двух структурных ответов из пяти достаточно, чтобы продолжать разговор, но не достаточно, чтобы подписывать договор без пробного этапа. Ноль или один — разговор закончен независимо от того, насколько приятным было общение: приятность и есть основной инструмент продажи в этой отрасли, и полагаться на неё нельзя.

Тест на честность оценки

Самая быстрая проверка из всех: задайте заведомо неопределённый вопрос об объёме и посмотрите, что человек с ним сделает. Например: «Сколько будет стоить бот для приёма заявок?» — не называя ни канала, ни потока, ни учётной системы.

Что должно прозвучать в ответ

Инженер задаёт 5–7 встречных вопросов и только потом называет диапазон: сколько обращений в месяц, из каких каналов они приходят, какая учётная система и есть ли у неё интерфейс обмена, кто в компании отвечает за правила обработки, что происходит с нестандартными обращениями сейчас, нужно ли писать ответы клиенту от лица компании. Продавец называет вилку сразу — и это не признак опыта, а признак того, что вилка не зависит от вашего ответа. Проверьте на нас тем же способом: если мы назовём цену раньше, чем спросим про объём и исключения, вы имеете полное право нам не поверить.

Важная поправка: назвать порядок величины сразу — нормально и полезно. «Такие задачи обычно стоят от 200 000 до 600 000 ₽, но до обследования это не оценка, а ориентир рынка» — честный ответ, он экономит время обеим сторонам. Нечестен другой вариант: точная цифра с точностью до тысячи, поданная как расчёт. Разница между ориентиром и оценкой — в том, названы ли условия, при которых цифра действительна; про сам механизм разброса мы писали в материале про чтение сметы на автоматизацию.

Как прочитать чужое техническое задание за час

Не пытайтесь понять термины — их можно пропускать. Ищите границы: где заканчивается ответственность исполнителя и начинается ваша. Час на документ, шесть вещей, каждая проверяется поиском по тексту.

Что искатьХороший признакПлохой признак
Границы объёмаЕсть раздел «не входит в работу» с перечислениемРаздела нет: всё спорное автоматически окажется доработкой
Источники данныхПо каждому полю сказано, откуда оно берётся и что делать при пустом значении«Данные поступают из учётной системы» без уточнения справочников и форматов
Поведение при ошибкеОписаны повторные попытки, очередь, журнал и кому уходит уведомлениеОписан только успешный сценарий
Критерии приёмкиНазваны выборка, определение ошибки и допустимый порог«Система работает корректно» или «в соответствии с пожеланиями заказчика»
Роли и праваПеречислено, кто что видит и кто что может изменитьРоли не упомянуты: система запустится с одним общим доступом
Порядок приёмкиУказано, кто подписывает, в какой срок и что происходит при отказе принятьПриёмка описана как демонстрация работы
разбор экранаkak-proverit-podryadchika-bez-it-spetsialista--02
Схема структуры технического задания: шесть зон, которые проверяет заказчик

Абстрактный разворот документа без читаемого мелкого текста, разбитый на зоны с выносками. Зона 1 «Границы объёма — есть ли раздел „не входит в работу“». Зона 2 «Источники данных — откуда берётся каждое поле». Зона 3 «Поведение при ошибке — повтор, очередь, журнал, уведомление». Зона 4 «Критерии приёмки — выборка, определение ошибки, порог». Зона 5 «Роли и права — кто что видит и меняет». Зона 6 «Порядок приёмки — кто подписывает и что при отказе». Сбоку пометка «час на документ». Чертёжный стиль, подписи по-русски.

Читать чужое ТЗ надо не подряд, а по шести местам

Если пять из шести зон в документе пусты, обсуждать цену рано: перед вами не техническое задание, а описание намерений. Такой документ не защищает ни вас, ни исполнителя — при первом же расхождении спорить будет не о чем. Что должно быть в полноценном документе и почему он становится приложением к договору, разобрано отдельно — структура ТЗ по разделам.

Три способа купить внешнюю оценку

Нанимать ИТ-директора ради одного проекта дорого и бессмысленно. Экспертиза покупается порциями — вопрос только в том, какую и за сколько.

СпособЧто даётЦенаОграничение
Платная консультация независимого архитектора, 2–4 часаРазбор предложенной архитектуры и ТЗ, список рисков, вопросы к подрядчику4 000–8 000 ₽ в час, итого 8 000–32 000 ₽Отвечает за мнение, а не за проект. Нужен конкретный вопрос, а не «посмотрите вообще»
Знакомый технический руководитель из другой компанииВзгляд практика, который видел похожие внедрения изнутри0 ₽ или ответная услугаНет обязательств и нет времени. Часто оценивает «как сделал бы я», а не «сработает ли это»
Второй подрядчик как рецензент технического заданияРазбор по составу работ, допущениям и пропущенным строкам20 000–40 000 ₽Конфликт интересов: рецензент заинтересован в разгроме. Требуйте письменных замечаний с обоснованием каждого

Третий способ работает только при одном условии: рецензию надо оплачивать. Бесплатное мнение конкурента — это коммерческое предложение в форме критики, и стоит оно ровно столько, сколько за него заплачено. Оплаченная рецензия с требованием обосновать каждое замечание меняет жанр: рецензент рискует репутацией за пустые придирки. Формулируйте задачу узко — «перечислите работы, которых нет в этом документе, и оцените каждую» — иначе получите общие рассуждения об архитектуре.

Порядок покупки экспертизы тоже имеет значение. Сначала — консультация архитектора по вашему вопросу, а не по чужому документу: «правильно ли вообще решать эту задачу через обмен с учётной системой, или дешевле поменять регламент». Такой разговор часто закрывает половину проекта до его начала. Дальше — рецензия конкретного технического задания, когда оно уже есть на руках. И только потом пробный этап: он самый дорогой из трёх и имеет смысл, когда первые два не нашли причин остановиться. Обратный порядок — сначала пробный этап, потом рецензия — обходится дороже и обычно приводит к тому, что рецензия уже никому не нужна.

Сколько стоит проверка проекта на 900 000 ₽
Консультация независимого архитектора, 3 часа × 6 000 ₽18 000 ₽
Оплаченная рецензия технического задания вторым подрядчиком25 000 ₽
Короткий платный этап с измеримым результатом90 000 ₽
Итого133 000 ₽ — 15 % бюджета. Для сравнения: провал, обнаруженный на пятом месяце, оставляет невозвратными 540 000 ₽ выплаченных денег и четыре месяца, за которые процесс не изменился
графикkak-proverit-podryadchika-bez-it-spetsialista--03
Стоимость проверки 133 тысячи против потерь 540 тысяч при провале проекта

Две вертикальные колонки. Левая «Проверка — 133 000 ₽», разделена на три сегмента с подписями: «консультация архитектора, 3 часа × 6 000 ₽ = 18 000 ₽», «рецензия ТЗ вторым подрядчиком 25 000 ₽», «короткий платный этап 90 000 ₽». Правая «Провал на пятом месяце — 540 000 ₽», сплошная заливка со штриховкой, подпись «выплачено 60 % бюджета проекта в 900 000 ₽». Сбоку подпись «плюс четыре месяца без изменений в процессе». Над левой колонкой пометка «15 % бюджета». Единицы — рубли, подписи по-русски.

Проверка — это не расход, а покупка права остановиться вовремя

Проверка через результат, а не через слова

Самый надёжный способ проверки не требует экспертизы вообще: закажите маленький оплаченный кусок работы с измеримым результатом и оцените не решение, а поведение исполнителя на дистанции в две-четыре недели. Скорость реакции, качество задаваемых вопросов, честность при первой возникшей сложности, соблюдение обещанного срока — всё это видно собственнику без всякого технического образования.

Критерий приёмки такого этапа формулируется в терминах вашего процесса, а не системы. Не «настроить обмен», а «за три недели получить карту процесса приёма заявок с объёмом операций, временем на каждую и списком мест, где заявки теряются». Не «сделать распознавание», а «прогнать 200 наших накладных и показать долю верно извлечённых полей». Как выбрать задачу, чтобы она была полезна сама по себе даже при отказе от дальнейшей работы, разобрано в материале про пробный этап с подрядчиком.

Четыре наблюдения за поведением стоят дороже любой технической оценки, потому что предсказывают именно то, что вас ждёт дальше. Первое — скорость реакции: сколько проходит от вашего вопроса до ответа на второй неделе, а не на первой. Второе — качество вопросов: спрашивает ли исполнитель про исключения и про то, кто принимает решения, или молча делает по своему представлению. Третье — честность при первой сложности: сообщил ли он сам, что что-то идёт не по плану, или вы узнали об этом, когда срок уже прошёл. Четвёртое — соблюдение обещанного срока на маленьком куске: тот, кто сорвал две недели, сорвёт и четыре месяца.

Чего не проверить без специалиста в принципе

Честная часть. Три вещи собственнику недоступны, и никакие вопросы на созвоне их не заменяют.

  • Качество кода. Читаемость, структура, тесты, отсутствие копий одного и того же в пяти местах. Плохой код работает ровно так же, как хороший, — разница проявляется через год, когда любая правка начинает стоить втрое дороже.
  • Архитектурная долговечность. Выдержит ли решение добавление второго склада, третьего канала, десятикратного роста номенклатуры. Со стороны это не видно никак: система, рассчитанная на один сценарий, и система, рассчитанная на развитие, на демонстрации выглядят одинаково.
  • Надёжность под нагрузкой. Что произойдёт в сезон, когда поток вырастет втрое, или в момент, когда маркетплейс отдаст десять тысяч заказов за час. Проверяется нагрузочным испытанием, а не разговором.
Чем это компенсируется, если экспертизы нет

Не экспертизой, а условиями договора — и это тот случай, когда бумага реально работает. Первое: обязательная передача исходного кода, схем интеграций и документации по договору, чтобы систему могла подхватить другая команда; без этого пункта плохое качество кода превращается в пожизненную привязку к исполнителю. Второе: гарантийный срок и SLA на дефекты — расхождения с ТЗ устраняются за счёт подрядчика, а не за ваш. Третье: нагрузочный порог прямо в критериях приёмки — «система обрабатывает 500 документов в час при доле ошибок не выше 5 %»; проверить результат вы сможете, даже не понимая, как он достигнут. Четвёртое: точка выхода после прототипа, чтобы ошибка стоила 20–30 % бюджета, а не весь проект. Все четыре пункта есть в наших гарантиях — и именно их стоит требовать от любого подрядчика, а не только от нас.

сравнениеkak-proverit-podryadchika-bez-it-spetsialista--04
Что собственник проверяет сам и что компенсируется условиями договора

Сравнение в две колонки. Левая «Проверяется собственником»: объяснение решения на языке процесса, поведение при отказе смежной системы, три названных риска, разбор прошлого провала, план приёмки, поведение на пробном этапе. Правая «Не проверяется — компенсируется договором»: качество кода → передача исходников и документации; архитектурная долговечность → фиксированная смета этапа и точка выхода после прототипа; надёжность под нагрузкой → нагрузочный порог в критериях приёмки, 500 документов в час при доле ошибок не выше 5 %; долгая эксплуатация → гарантия и SLA на дефекты. Чертёжный стиль, подписи по-русски.

Непроверяемое не исчезает — оно переносится в договор

Когда проверять некого: подрядчик не нужен

Прежде чем тратить время на проверку исполнителей, стоит убедиться, что исполнитель вообще требуется. Четыре ситуации, в которых ответ отрицательный.

  • Задача решается настройкой уже купленного. Правила распределения, шаблоны документов, автозадачи и уведомления есть в коробочных CRM и типовых конфигурациях учётных систем. Один платный час консультации партнёра вендора закрывает то, что подрядчик оценит в 150 000–300 000 ₽ как разработку.
  • Операций меньше порога окупаемости. При 60–80 однотипных операциях в месяц внедрение не окупится за 24 месяца: цена системы почти не зависит от объёма потока. Порог считается своими силами по методике из материала про окупаемость автоматизации — на это уходит вечер.
  • Процесс не описан. Проверять подрядчика на неописанном процессе бессмысленно: вы не сможете оценить ни одного его ответа, потому что сами не знаете правильного. Сначала аудит процесса своими силами за 3–5 рабочих дней, потом разговоры с исполнителями.
  • Нужна разовая работа, а не система. Единичная выгрузка, сверка перед закрытием года, перенос данных при смене программы — это несколько часов почасовой помощи, а не проект с этапами, приёмкой и договором поддержки.

И вывод, который нам самим невыгоден. Ни одна проверка из этой статьи не гарантирует, что подрядчик сделает хорошо. Все они вместе гарантируют другое: вы узнаете о проблеме раньше, чем потратите весь бюджет. Именно поэтому наиболее ценны не вопросы на созвоне, а конструкция сделки — этапы, критерии приёмки, точка выхода и передача исходников. Хороший исполнитель на неё соглашается, потому что она защищает и его тоже. Тот, кто отказывается, сообщил вам о себе больше, чем любая техническая экспертиза за 40 000 ₽.

Собственник не оценит архитектуру, но безошибочно отличит человека, который знает границы своего ответа, от человека, у которого их нет.