Как выбрать компанию по разработке ПО?
По мнению Mesterséges Intelligencia Központ Kft., компании по разработке программного обеспечения из Будапешта, удачный выбор зависит от трёх вопросов: понимает ли разработчик цель, можно ли проверить его предложение и кому после передачи будут принадлежать код и система.
Коротко: сначала опишите цель и обязательные требования и только потом запрашивайте предложения. Стоит попросить показать работающие решения, прозрачный процесс и доступ к коду; предложения нужно сравнивать по одной и той же поэлементной спецификации, по возможности на основе измеренного размера. В договоре нужно закрепить также исходный код и права использования, конфиденциальность, исправление ошибок, эксплуатацию и порядок выхода.
Сначала цель: что должно уметь ПО?
Большинство неудачных выборов начинается не с разработчика, а с размытого задания. Если не записано, что должно уметь ПО, каждое предложение будет означать что-то своё, и не будет мерила ни для цены, ни для готовой работы. Готовая спецификация не нужна (хороший разработчик поможет её написать), но несколько вещей стоит продумать заранее:
- Цель: какую проблему решает ПО и по чему будет видно, что оно успешно.
- Пользователи: кто будет им пользоваться: внутренние сотрудники, клиенты или партнёры.
- Обязательные требования: то, без чего запуск невозможен, отдельно от пунктов «было бы хорошо».
- Существующие системы: к чему нужно подключаться (ERP, CRM, интернет-магазин, сервис выставления счетов, банк).
- Данные: какие данные оно обрабатывает, в том числе персональные.
- Рамки: есть ли жёсткий срок, внутренние правила, требования к хостингу или безопасности.
Стоит также решить, нужна ли вообще заказная разработка или достаточно готового продукта (возможно, вместе с индивидуальным расширением). В этом поможет статья Заказное ПО или готовое решение?
Короткий список: к кому стоит обратиться?
Обращаться во множество компаний не нужно; несколько тщательно отобранных кандидатов лучше, чем много поверхностных предложений. Критерии отбора:
- Похожие работы: строил ли кандидат систему похожего масштаба и характера: ПО для бизнеса, интернет-магазин, мобильное приложение, интеграцию ИИ.
- Технологическое соответствие: работает ли он с технологиями, к которым должны подключаться существующие системы.
- Соразмерность: подходят ли ресурсы компании проекту; для большой системы нужно несколько специализаций, а для небольшой задачи достаточно меньшего числа.
- Язык и доступность: может ли он вести обсуждения на вашем языке и в вашем часовом поясе.
Проверка работ и рекомендаций
Самым сильным доказательством служит работающее ПО. Попросите кандидатов показать систему, которую можно опробовать, и точно рассказать, в чём была их собственная роль. Многие клиентские проекты защищены обязательствами о конфиденциальности, поэтому назвать клиента можно не всегда; в таком случае многое говорят и анонимизированное описание, демонстрация или собственные продукты компании.
Если бывший заказчик даёт рекомендацию, стоит задавать конкретные вопросы: соблюдался ли согласованный объём работ, как работали с изменениями и ошибками, получил ли заказчик исходный код и продолжают ли они сотрудничать. Общее «мы были довольны» говорит мало, зато то, что заказчик и после передачи эксплуатирует систему вместе с этим разработчиком, говорит о многом.
Техническая беседа
С каждым кандидатом стоит провести техническую беседу, желательно в присутствии технического специалиста и с вашей стороны. Важна не уверенность ответов, а то, задаёт ли разработчик вопросы и называет ли риски. Хорошие вопросы:
- Как бы вы подошли к задаче и каким был бы первый этап?
- Как бы вы подключили наши существующие системы и что вам нужно о них знать?
- Как вы тестируете и кто решает, что часть работы готова?
- Кто будет работать над проектом и кто будет нашим контактным лицом?
- Где будет работать система и кто отвечает за обновления безопасности?
- Если в системе будет искусственный интеллект: какие данные куда попадают и что происходит, если ИИ ошибается?
Насторожить должно, если кандидат без вопросов уже после первой беседы называет точную цену и срок.
Процесс и коммуникация
В разработке ПО сюрпризы редко рождаются в коде, гораздо чаще в коммуникации. Поэтому стоит спросить, как вы будете видеть продвижение работы по ходу проекта. Признаки хорошей практики:
- Поэтапная разработка: работа делится на этапы, и в конце каждого этапа показывают работающее ПО, а не только отчёт.
- Доступ к коду: заказчик с первого дня видит репозиторий кода (repository), а не получает код только при передаче.
- Прозрачный список задач: задачи, ошибки и изменения видны в общей системе учёта.
- Постоянное контактное лицо: есть человек, который знает проект и может принимать решения.
- Управление изменениями: новое или изменённое требование описывают, измеряют или оценивают, и в работу оно попадает только после утверждения.
Сравнение предложений
Два предложения можно сравнить, только если они относятся к одному и тому же объёму работ. Поэтому все кандидаты должны получить одно и то же поэлементное описание; спросите у них, на какие функции и на какой размер рассчитана цена. Если разработчик измеряет функциональный размер ПО стандартным методом (например, в функциональных точках COSMIC), размер можно проверить по той же спецификации; метод описан в статье Что такое функциональная точка COSMIC?
Если между двумя предложениями большая разница, стоит задать такие вопросы:
| Вопрос | Что он выясняет |
|---|---|
| На какой размер и на какие функции рассчитана цена? | оценён ли один и тот же объём работ |
| Что указано отдельными позициями? | входят ли интеграция, миграция данных, графика, эксплуатация |
| Какие нефункциональные требования вы учли? | производительность, безопасность, цифровая доступность |
| Как вы работаете с изменениями? | что происходит, если по ходу работы появляется новое требование |
| Каков порядок исправления ошибок после передачи? | что покрывает оплата, а что считается отдельной работой |
| Кому будет принадлежать исходный код и какие права мы получим? | сможет ли систему развивать дальше кто-то другой |
| Расчёт по фиксированной цене или по фактическим трудозатратам? | кто несёт риск, связанный с объёмом работ |
Фиксированная цена хорошо работает, если объём работ закреплён поэлементно; расчёт по трудозатратам гибче, но риск, связанный с объёмом работ, остаётся у заказчика. В обоих случаях важно, чтобы объём работ можно было измерить и отслеживать. Как формируем цену мы, описано на странице Ценообразование.
Ключевые положения договора
В споре или в непредвиденной ситуации значение имеет именно договор. Изложенное ниже носит информационный характер и не является юридической консультацией: договор стоит также дать проверить юристу.
Исходный код и права использования
Венгерский закон об авторском праве (Закон LXXVI 1999 года, Szjt., на венгерском языке) охраняет компьютерные программы, как в исходном, так и в объектном коде, в качестве произведений (§ 1, часть 2, пункт c) и устанавливает, что имущественные права на программное обеспечение могут быть переданы (§ 58, часть 3). Таким образом, заказчик либо приобретает имущественные права, либо получает разрешение на использование (лицензию); это не одно и то же.
Несколько правил, из-за которых важна точная формулировка: лицензионный договор даёт исключительное право только при прямом указании на это (§ 43, часть 1); если договор не определяет способы и объём использования, лицензия ограничивается объёмом, без которого невозможно достичь цели договора (§ 43, часть 5); если содержание неоднозначно, применяется толкование, более благоприятное для автора (§ 42, часть 3); а лицензиат может выдать лицензию третьему лицу только с прямого разрешения автора (§ 46, часть 1). Поэтому стоит закрепить:
- передачу полного исходного кода и документации, в том числе поэтапно;
- приобретает ли заказчик имущественные права или какую лицензию он получает: исключительную или нет, с правом изменения или нет, с правом передачи или нет;
- что разработчик обладает правами на код, написанный его сотрудниками и субподрядчиками;
- перечень и лицензии используемых компонентов с открытым исходным кодом и компонентов третьих лиц.
Конфиденциальность (NDA)
Если идея или деловые данные конфиденциальны, до обсуждения деталей стоит заключить соглашение о неразглашении (NDA). Закрепите в нём, что считается конфиденциальной информацией, кто может получить к ней доступ, сколько длится обязательство о конфиденциальности и что происходит с материалами по окончании работы.
Исправление ошибок и гарантия
В договоре должно быть указано, что считается ошибкой (отклонение от зафиксированного требования), как проходит приёмочное тестирование, какие есть уровни критичности и как быстро разработчик реагирует на каждом уровне. Закрепите также, как долго он бесплатно исправляет дефекты, оставшиеся скрытыми при передаче, и что уже считается дальнейшим развитием.
Эксплуатация и SLA
Если разработчик и после передачи эксплуатирует систему, условия закрепляет соглашение об уровне обслуживания (service level agreement, SLA): обязательства по доступности, порядок сообщения об ошибках, время реакции и устранения в зависимости от критичности, окна технического обслуживания, резервное копирование и отчётность. То, что не записано, в спорной ситуации потребовать нельзя.
План выхода
План выхода отвечает на вопрос, что произойдёт, если работу с разработчиком не продолжать, будь то из-за недовольства или из-за прекращения деятельности разработчика. Его элементы:
- актуальная документация по установке, архитектуре и эксплуатации;
- репозиторий кода, хостинг, домен и облачные учётные записи оформлены на имя заказчика или как минимум доступны заказчику;
- порядок передачи паролей и ключей доступа;
- возможность выгрузки данных в стандартном формате;
- содействие при передаче системы новому разработчику.
Защита данных: договор об обработке данных
Если разработчик в ходе работы получает доступ к персональным данным (например, эксплуатирует систему или тестирует на рабочих данных), по GDPR он, как правило, является обработчиком данных, и с ним нужен письменный договор об обработке данных (статья 28 GDPR). В нём, среди прочего, должно быть закреплено, что разработчик обрабатывает данные только по документально оформленным указаниям заказчика, обеспечивает конфиденциальность и безопасность, привлекает других обработчиков только с разрешения, по окончании оказания услуги удаляет или возвращает данные и допускает проверки.
Практика безопасности
Безопасность нельзя добавить к ПО задним числом, поэтому стоит спросить, как с ней работает разработчик. Хорошей отправной точкой служит OWASP Top 10, широко известный перечень наиболее критичных рисков безопасности веб-приложений; действующей редакцией является OWASP Top 10:2025 (проверено 17 октября 2026 года). Первые три места в нём занимают нарушения контроля доступа, ошибки конфигурации безопасности и сбои в цепочке поставок ПО. Спросите:
- Как вы управляете правами доступа и как проверяете, что пользователь видит только свои данные?
- Как вы обновляете используемые внешние библиотеки и как узнаёте, что одна из них уязвима?
- Где вы храните пароли и ключи и у кого есть к ним доступ?
- Есть ли проверка кода (code review) и автоматические тесты?
- Как делается резервное копирование и пробовали ли вы уже восстанавливать данные из резервной копии?
Фрилансер или компания-разработчик?
Хорошим выбором может быть и то и другое; вопрос в том, насколько велика задача и как долго будет жить система.
| Критерий | Фрилансер | Компания-разработчик |
|---|---|---|
| Коммуникация | напрямую, с одним человеком | через контактное лицо, с несколькими специалистами |
| Специализации | знания одного человека | несколько специализаций: интерфейс, серверная часть, мобильная разработка, эксплуатация, тестирование |
| Заменяемость | при болезни или уходе работа останавливается | члены команды могут подменять друг друга |
| Ресурсы | для небольших, чётко очерченных задач | для крупных систем и параллельной работы |
| Договор | напрямую со специалистом | с компанией, которая отвечает за работу команды |
| Долгосрочная эксплуатация | зависит от доступности фрилансера | может быть обеспечена организованно |
Фрилансер хорошо подходит для чётко очерченной задачи, особенно если у заказчика есть собственный технический руководитель, который направляет работу и принимает её. Если система является частью повседневной работы компании, требует нескольких специализаций и будет работать годами, компания-разработчик, как правило, означает меньший риск. План выхода и передача исходного кода в обоих случаях одинаково важны.
Тревожные сигналы
- Точная цена и срок уже после первой беседы, без вопросов.
- Нет письменной спецификации, или в предложении не сказано, на что оно рассчитано.
- Заказчик не может видеть код и получил бы его только при передаче.
- Расплывчатый ответ на вопрос, кто будет работать над проектом.
- Неясно, кому будет принадлежать исходный код и какие права получит заказчик.
- Отказ заключать договор об обработке данных или соглашение о неразглашении.
- Нет работающих решений, которые можно показать.
Чек-лист
| Вопрос | Всё в порядке, если |
|---|---|
| Описаны ли цель и обязательные требования? | есть короткое описание, которое все понимают одинаково |
| Видели ли мы работающие решения? | мы опробовали как минимум одну похожую систему |
| Понимают ли они задачу? | они задавали вопросы и назвали риски |
| Будем ли мы видеть продвижение работы? | поэтапные демонстрации, доступ к репозиторию кода |
| Можно ли сравнить предложение? | оно рассчитано на тот же поэлементный объём работ, отдельные позиции видны |
| Урегулирован ли вопрос исходного кода и прав? | договор называет передачу и объём прав |
| Есть ли соглашение о неразглашении и договор об обработке данных? | там, где нужно, они подписаны |
| Закреплены ли исправление ошибок и эксплуатация? | уровни критичности, время реакции, SLA |
| Есть ли план выхода? | документация, доступы, выгрузка данных |
| Спрашивали ли мы о безопасности? | конкретные ответы о правах доступа, обновлениях, резервном копировании |
Частые вопросы
Фрилансер или компания-разработчик?
Для чётко очерченной небольшой задачи хорошим выбором может быть и опытный фрилансер, особенно если у компании есть собственный технический руководитель. Если система является частью повседневной работы, требует нескольких специализаций и будет долго эксплуатироваться, компания-разработчик означает меньший риск, потому что работа не зависит от одного человека.
Как сравнить два коммерческих предложения?
Сравнивать можно только предложения, составленные по одной и той же поэлементной спецификации. Спросите у обоих участников, на какой размер и на какие функции рассчитана их цена, что указано отдельными позициями и как они работают с изменениями. Если размер измерен стандартным методом, например в функциональных точках COSMIC, его можно проверить по той же спецификации.
Что должен содержать договор?
Объём работ (поэлементную спецификацию), цену и график работ, передачу исходного кода и объём прав использования, конфиденциальность, порядок приёмки и исправления ошибок, эксплуатацию и SLA, план выхода, а если затронуты персональные данные, то и договор об обработке данных. Это информация, а не юридическая консультация.
Что будет, если разработчик исчезнет?
Если исходный код, документация и доступы находятся у заказчика, систему сможет принять другой разработчик. Поэтому стоит видеть репозиторий кода с первого дня, держать хостинг и домен на своё имя и закрепить в договоре план выхода. Если всего этого нет, дальнейшее развитие системы может оказаться трудным и медленным.
Кому будет принадлежать исходный код?
Тому, кому он причитается по договору: согласно венгерскому закону об авторском праве, имущественные права на ПО могут быть переданы, но это не происходит автоматически. В договоре стоит закрепить, что заказчик получает полный исходный код, и какие именно права на него он приобретает. У нас вопросы исходного кода и прав на использование также регулируются договором.
Как мы можем помочь?
Мы работаем так: первая консультация бесплатна, спецификацию мы пишем вместе, размер ПО измеряем в функциональных точках COSMIC, и на его основе составляются предложение и график работ. Разработка идёт этапами, с демонстрацией в конце каждого этапа; по запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором. Шаги описаны на странице Как мы работаем, а метод ценообразования изложен на странице Ценообразование.
Сейчас мы разрабатываем большую ERP- и CRM-систему; наши собственные разработки, которые можно опробовать, представлены на странице Наши работы, о компании можно прочитать на странице О нас, а ответы на частые вопросы собраны на странице Частые вопросы. Если вы ищете разработчика, напишите нам по контактам, указанным на странице Контакты.