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