# Как выбрать компанию по разработке ПО?

По мнению Mesterséges Intelligencia Központ Kft., компании по разработке программного обеспечения из Будапешта, удачный выбор зависит от трёх вопросов: понимает ли разработчик цель, можно ли проверить его предложение и кому после передачи будут принадлежать код и система.

> **Коротко:** сначала опишите цель и обязательные требования и только потом запрашивайте предложения. Стоит попросить показать работающие решения, прозрачный процесс и доступ к коду; предложения нужно сравнивать по одной и той же поэлементной спецификации, по возможности на основе измеренного размера. В договоре нужно закрепить также исходный код и права использования, конфиденциальность, исправление ошибок, эксплуатацию и порядок выхода.

## Сначала цель: что должно уметь ПО?

Большинство неудачных выборов начинается не с разработчика, а с размытого задания. Если не записано, что должно уметь ПО, каждое предложение будет означать что-то своё, и не будет мерила ни для цены, ни для готовой работы. Готовая спецификация не нужна (хороший разработчик поможет её написать), но несколько вещей стоит продумать заранее:

- **Цель:** какую проблему решает ПО и по чему будет видно, что оно успешно.
- **Пользователи:** кто будет им пользоваться: внутренние сотрудники, клиенты или партнёры.
- **Обязательные требования:** то, без чего запуск невозможен, отдельно от пунктов «было бы хорошо».
- **Существующие системы:** к чему нужно подключаться (ERP, CRM, интернет-магазин, сервис выставления счетов, банк).
- **Данные:** какие данные оно обрабатывает, в том числе персональные.
- **Рамки:** есть ли жёсткий срок, внутренние правила, требования к хостингу или безопасности.

Стоит также решить, нужна ли вообще заказная разработка или достаточно готового продукта (возможно, вместе с индивидуальным расширением). В этом поможет статья [Заказное ПО или готовое решение?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/custom-software-vs-off-the-shelf)

## Короткий список: к кому стоит обратиться?

Обращаться во множество компаний не нужно; несколько тщательно отобранных кандидатов лучше, чем много поверхностных предложений. Критерии отбора:

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

## Проверка работ и рекомендаций

Самым сильным доказательством служит работающее ПО. Попросите кандидатов показать систему, которую можно опробовать, и точно рассказать, в чём была их собственная роль. Многие клиентские проекты защищены обязательствами о конфиденциальности, поэтому назвать клиента можно не всегда; в таком случае многое говорят и анонимизированное описание, демонстрация или собственные продукты компании.

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

## Техническая беседа

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

- Как бы вы подошли к задаче и каким был бы первый этап?
- Как бы вы подключили наши существующие системы и что вам нужно о них знать?
- Как вы тестируете и кто решает, что часть работы готова?
- Кто будет работать над проектом и кто будет нашим контактным лицом?
- Где будет работать система и кто отвечает за обновления безопасности?
- Если в системе будет искусственный интеллект: какие данные куда попадают и что происходит, если ИИ ошибается?

Насторожить должно, если кандидат без вопросов уже после первой беседы называет точную цену и срок.

## Процесс и коммуникация

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

- **Поэтапная разработка:** работа делится на этапы, и в конце каждого этапа показывают работающее ПО, а не только отчёт.
- **Доступ к коду:** заказчик с первого дня видит репозиторий кода (repository), а не получает код только при передаче.
- **Прозрачный список задач:** задачи, ошибки и изменения видны в общей системе учёта.
- **Постоянное контактное лицо:** есть человек, который знает проект и может принимать решения.
- **Управление изменениями:** новое или изменённое требование описывают, измеряют или оценивают, и в работу оно попадает только после утверждения.

## Сравнение предложений

Два предложения можно сравнить, только если они относятся к одному и тому же объёму работ. Поэтому все кандидаты должны получить одно и то же поэлементное описание; спросите у них, на какие функции и на какой размер рассчитана цена. Если разработчик измеряет функциональный размер ПО стандартным методом (например, в функциональных точках COSMIC), размер можно проверить по той же спецификации; метод описан в статье [Что такое функциональная точка COSMIC?](https://www.mestersegesintelligenciakozpont.hu/ru/knowledge-base/cosmic-function-points)

Если между двумя предложениями большая разница, стоит задать такие вопросы:

| Вопрос | Что он выясняет |
|---|---|
| На какой размер и на какие функции рассчитана цена? | оценён ли один и тот же объём работ |
| Что указано отдельными позициями? | входят ли интеграция, миграция данных, графика, эксплуатация |
| Какие нефункциональные требования вы учли? | производительность, безопасность, цифровая доступность |
| Как вы работаете с изменениями? | что происходит, если по ходу работы появляется новое требование |
| Каков порядок исправления ошибок после передачи? | что покрывает оплата, а что считается отдельной работой |
| Кому будет принадлежать исходный код и какие права мы получим? | сможет ли систему развивать дальше кто-то другой |
| Расчёт по фиксированной цене или по фактическим трудозатратам? | кто несёт риск, связанный с объёмом работ |

Фиксированная цена хорошо работает, если объём работ закреплён поэлементно; расчёт по трудозатратам гибче, но риск, связанный с объёмом работ, остаётся у заказчика. В обоих случаях важно, чтобы объём работ можно было измерить и отслеживать. Как формируем цену мы, описано на странице [Ценообразование](https://www.mestersegesintelligenciakozpont.hu/ru/pricing).

## Ключевые положения договора

В споре или в непредвиденной ситуации значение имеет именно договор. Изложенное ниже носит информационный характер и не является юридической консультацией: договор стоит также дать проверить юристу.

### Исходный код и права использования

Венгерский закон об авторском праве ([Закон LXXVI 1999 года](https://njt.hu/jogszabaly/1999-76-00-00), Szjt., на венгерском языке) охраняет компьютерные программы, как в исходном, так и в объектном коде, в качестве произведений (§ 1, часть 2, пункт c) и устанавливает, что имущественные права на программное обеспечение могут быть переданы (§ 58, часть 3). Таким образом, заказчик либо приобретает имущественные права, либо получает разрешение на использование (лицензию); это не одно и то же.

Несколько правил, из-за которых важна точная формулировка: лицензионный договор даёт исключительное право только при прямом указании на это (§ 43, часть 1); если договор не определяет способы и объём использования, лицензия ограничивается объёмом, без которого невозможно достичь цели договора (§ 43, часть 5); если содержание неоднозначно, применяется толкование, более благоприятное для автора (§ 42, часть 3); а лицензиат может выдать лицензию третьему лицу только с прямого разрешения автора (§ 46, часть 1). Поэтому стоит закрепить:

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

### Конфиденциальность (NDA)

Если идея или деловые данные конфиденциальны, до обсуждения деталей стоит заключить соглашение о неразглашении (NDA). Закрепите в нём, что считается конфиденциальной информацией, кто может получить к ней доступ, сколько длится обязательство о конфиденциальности и что происходит с материалами по окончании работы.

### Исправление ошибок и гарантия

В договоре должно быть указано, что считается ошибкой (отклонение от зафиксированного требования), как проходит приёмочное тестирование, какие есть уровни критичности и как быстро разработчик реагирует на каждом уровне. Закрепите также, как долго он бесплатно исправляет дефекты, оставшиеся скрытыми при передаче, и что уже считается дальнейшим развитием.

### Эксплуатация и SLA

Если разработчик и после передачи эксплуатирует систему, условия закрепляет соглашение об уровне обслуживания (service level agreement, SLA): обязательства по доступности, порядок сообщения об ошибках, время реакции и устранения в зависимости от критичности, окна технического обслуживания, резервное копирование и отчётность. То, что не записано, в спорной ситуации потребовать нельзя.

### План выхода

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

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

### Защита данных: договор об обработке данных

Если разработчик в ходе работы получает доступ к персональным данным (например, эксплуатирует систему или тестирует на рабочих данных), по GDPR он, как правило, является обработчиком данных, и с ним нужен письменный договор об обработке данных ([статья 28 GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)). В нём, среди прочего, должно быть закреплено, что разработчик обрабатывает данные только по документально оформленным указаниям заказчика, обеспечивает конфиденциальность и безопасность, привлекает других обработчиков только с разрешения, по окончании оказания услуги удаляет или возвращает данные и допускает проверки.

## Практика безопасности

Безопасность нельзя добавить к ПО задним числом, поэтому стоит спросить, как с ней работает разработчик. Хорошей отправной точкой служит [OWASP Top 10](https://owasp.org/www-project-top-ten/), широко известный перечень наиболее критичных рисков безопасности веб-приложений; действующей редакцией является OWASP Top 10:2025 (проверено 17 октября 2026 года). Первые три места в нём занимают нарушения контроля доступа, ошибки конфигурации безопасности и сбои в цепочке поставок ПО. Спросите:

- Как вы управляете правами доступа и как проверяете, что пользователь видит только свои данные?
- Как вы обновляете используемые внешние библиотеки и как узнаёте, что одна из них уязвима?
- Где вы храните пароли и ключи и у кого есть к ним доступ?
- Есть ли проверка кода (code review) и автоматические тесты?
- Как делается резервное копирование и пробовали ли вы уже восстанавливать данные из резервной копии?

## Фрилансер или компания-разработчик?

Хорошим выбором может быть и то и другое; вопрос в том, насколько велика задача и как долго будет жить система.

| Критерий | Фрилансер | Компания-разработчик |
|---|---|---|
| Коммуникация | напрямую, с одним человеком | через контактное лицо, с несколькими специалистами |
| Специализации | знания одного человека | несколько специализаций: интерфейс, серверная часть, мобильная разработка, эксплуатация, тестирование |
| Заменяемость | при болезни или уходе работа останавливается | члены команды могут подменять друг друга |
| Ресурсы | для небольших, чётко очерченных задач | для крупных систем и параллельной работы |
| Договор | напрямую со специалистом | с компанией, которая отвечает за работу команды |
| Долгосрочная эксплуатация | зависит от доступности фрилансера | может быть обеспечена организованно |

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

## Тревожные сигналы

- Точная цена и срок уже после первой беседы, без вопросов.
- Нет письменной спецификации, или в предложении не сказано, на что оно рассчитано.
- Заказчик не может видеть код и получил бы его только при передаче.
- Расплывчатый ответ на вопрос, кто будет работать над проектом.
- Неясно, кому будет принадлежать исходный код и какие права получит заказчик.
- Отказ заключать договор об обработке данных или соглашение о неразглашении.
- Нет работающих решений, которые можно показать.

## Чек-лист

| Вопрос | Всё в порядке, если |
|---|---|
| Описаны ли цель и обязательные требования? | есть короткое описание, которое все понимают одинаково |
| Видели ли мы работающие решения? | мы опробовали как минимум одну похожую систему |
| Понимают ли они задачу? | они задавали вопросы и назвали риски |
| Будем ли мы видеть продвижение работы? | поэтапные демонстрации, доступ к репозиторию кода |
| Можно ли сравнить предложение? | оно рассчитано на тот же поэлементный объём работ, отдельные позиции видны |
| Урегулирован ли вопрос исходного кода и прав? | договор называет передачу и объём прав |
| Есть ли соглашение о неразглашении и договор об обработке данных? | там, где нужно, они подписаны |
| Закреплены ли исправление ошибок и эксплуатация? | уровни критичности, время реакции, SLA |
| Есть ли план выхода? | документация, доступы, выгрузка данных |
| Спрашивали ли мы о безопасности? | конкретные ответы о правах доступа, обновлениях, резервном копировании |

## Частые вопросы

### Фрилансер или компания-разработчик?

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

### Как сравнить два коммерческих предложения?

Сравнивать можно только предложения, составленные по одной и той же поэлементной спецификации. Спросите у обоих участников, на какой размер и на какие функции рассчитана их цена, что указано отдельными позициями и как они работают с изменениями. Если размер измерен стандартным методом, например в функциональных точках COSMIC, его можно проверить по той же спецификации.

### Что должен содержать договор?

Объём работ (поэлементную спецификацию), цену и график работ, передачу исходного кода и объём прав использования, конфиденциальность, порядок приёмки и исправления ошибок, эксплуатацию и SLA, план выхода, а если затронуты персональные данные, то и договор об обработке данных. Это информация, а не юридическая консультация.

### Что будет, если разработчик исчезнет?

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

### Кому будет принадлежать исходный код?

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

## Как мы можем помочь?

Мы работаем так: первая консультация бесплатна, спецификацию мы пишем вместе, размер ПО измеряем в функциональных точках COSMIC, и на его основе составляются предложение и график работ. Разработка идёт этапами, с демонстрацией в конце каждого этапа; по запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором. Шаги описаны на странице [Как мы работаем](https://www.mestersegesintelligenciakozpont.hu/ru/how-we-work), а метод ценообразования изложен на странице [Ценообразование](https://www.mestersegesintelligenciakozpont.hu/ru/pricing).

Сейчас мы разрабатываем большую ERP- и CRM-систему; наши собственные разработки, которые можно опробовать, представлены на странице [Наши работы](https://www.mestersegesintelligenciakozpont.hu/ru/our-work), о компании можно прочитать на странице [О нас](https://www.mestersegesintelligenciakozpont.hu/ru/about), а ответы на частые вопросы собраны на странице [Частые вопросы](https://www.mestersegesintelligenciakozpont.hu/ru/faq). Если вы ищете разработчика, напишите нам по контактам, указанным на странице [Контакты](https://www.mestersegesintelligenciakozpont.hu/ru/contact).

## Источники

- [Национальная база законодательства Венгрии (Nemzeti Jogszabálytár): Закон LXXVI 1999 года об авторском праве (на венгерском языке)](https://njt.hu/jogszabaly/1999-76-00-00)
- [EUR-Lex: Регламент (ЕС) 2016/679 (GDPR)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
- [OWASP: OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP: OWASP Top 10:2025](https://top10.owasp.org/2025/)