Как выбрать разработчика системы автоматизации: 7 вопросов, на которые должен ответить подрядчик

Почему большинство проектов автоматизации проваливаются не на этапе разработки?

Проект не умирает, когда система не работает технически. Он умирает, когда системой не пользуются. Рабочие обходят её, мастера ведут журналы в Excel, директор видит красивые дашборды с выдуманными данными.

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

Выбор разработчика — это не сравнение портфолио и цен. Это проверка того, как он работает с процессом. Вот семь вопросов, которые помогают отделить тех, кто умеет, от тех, кто только обещает.

Вопрос 1: Вы едете на производство перед началом разработки?

Правильный ответ: «Да, обязательно. Хожу по цеху, разговариваю с мастерами, смотрю, как реально выполняются операции».

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

Без погружения система будет спроектирована под идеальную схему, которой не существует.

Вопрос 2: Кто будет владеть исходным кодом после проекта?

Правильный ответ: «Заказчик. Код передаётся по договору, без обременений».

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

Передача исходного кода — это страховка. Не потому, что вы обязательно будете дорабатывать сами. А потому, что у вас есть выбор.

Вопрос 3: Как часто я буду видеть рабочий результат?

Правильный ответ: «Каждые 2 недели — демо рабочего функционала, не слайды».

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

Итерационная разработка — это когда через 2 недели у вас в руках рабочий экран, через 4 — рабочий процесс, через 6 — MVP, которое можно запускать в эксплуатацию. Ошибки в требованиях выявляются рано, когда их исправление стоит копейки.

Вопрос 4: Сколько проектов доведено до эксплуатации, а не просто написано?

Правильный ответ: конкретное число и конкретные кейсы.

«Мы разработали 50 систем» — это не ответ. Разработать и запустить — разные вещи. Система, которая написана, но не работает в эксплуатации — это не проект, это эксперимент.

Спросите про кейсы: какое производство, сколько пользователей, сколько лет работает. Попросите контакт клиента. Если разработчик не может дать ни один контакт — это повод задуматься.

Вопрос 5: Что happens, когда ваши доработки закончатся?

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

Зависимость от разработчика — главная боль после внедрения. Если каждый раз, когда нужно добавить поле или поменять отчёт, вы должны звонить разработчику и ждать неделями — вы не владеете системой, она владеет вами.

Хороший разработчик закладывает независимость: документация, чистая архитектура, стандартный стек технологий. Вы должны иметь возможность нанять junior-разработчика для мелких доработок.

Вопрос 6: Как вы считаете стоимость — фиксированную или по часам?

Правильный ответ: «Фиксированная оценка по этапам. Каждый этап — конкретный результат, конкретная цена, конкретный срок».

Почасовая оплата — это открытый чек. Вы не знаете, сколько заплатите в итоге. Разработчик не мотивирован делать быстро — чем дольше, тем больше заработает.

Фиксированная оценка по этапам — обе стороны понимают, что и за сколько. Если требования меняются — оценивается дополнительно, прозрачно. Нет сюрпризов в счёте.

Вопрос 7: Что вы делаете, если система не приживается у пользователей?

Правильный ответ: «Дорабатываем интерфейс под обратную связь. Проводим обучение. Анализируем, где система не соответствует реальному процессу — и исправляем».

Если разработчик говорит «мы сдали систему, дальше ваши проблемы» — это не партнёр. Внедрение — не момент сдачи, а момент, когда люди начинают пользоваться. Иногда нужно 2–3 итерации доработок интерфейса, прежде чем система приживается.

Что ещё стоит проверить?

Стек технологий. Python, FastAPI, PostgreSQL — стандартный стек, любой разработчик разберётся. Proprietary framework — зависимость навсегда.
Гарантия. Минимум 3 месяца бесплатного исправления багов после сдачи.
Договор. Все условия — в договоре, включая передачу кода, сроки, ответственность.
Портфолио в вашей отрасли. Не обязательно точно такое же производство, но опыт в manufacturing/warehouse — важен.