Как выбрать подрядчика на разработку приложения

Коротко: Чтобы правильно выбрать подрядчика на разработку приложения, необходимо сопоставить сложность ТЗ с методологией работы (Agile или Waterfall), проверить наличие компетенций в требованиях реестра российского ПО и жестко закрепить в договоре передачу прав на исходный код. Оценка должна включать аудит портфолио, проверку совместимости софта с доверенными ОС и детальный разбор сметы.

Кстати, в AmSales мы делаем разработку мобильных приложений и разработку сайтов под ключ под ключ. Если нужна помощь - напишите нам.

Анализ ТЗ: проверка на полноту и реализуемость

Техническое задание на разработку ПО - это фундамент, на котором строится вся экономика проекта. Если на этапе обсуждения вы слышите от разработчиков "мы сами все продумаем", это повод насторожиться. В идеальном сценарии ТЗ описывает не только то, что пользователь видит на экране, но и то, что происходит "под капотом": логику обработки данных, интеграции с внешними сервисами и требования к нагрузке.

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

Ключевые элементы качественного ТЗ

Хорошее техническое задание включает в себя несколько критических блоков:

• Описание архитектуры и стека технологий (на чем пишем, какие базы данных используем).
• Функциональные требования (что система делает).
• Нефункциональные требования (скорость отклика, безопасность, масштабируемость).
• Описание API и протоколов взаимодействия с другими системами.
• Требования к интерфейсу (UI) и пользовательскому опыту (UX).

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

Важно помнить, что ТЗ - это не статичный документ. В коммерческой разработке оно часто эволюционирует, но базовые параметры, такие как интеграции и требования к безопасности, должны быть зафиксированы максимально подробно. Чем меньше в документе формулировок типа "быстро", "красиво" или "удобно", тем меньше шансов на конфликт при приемке.

ГОСТ 34.602-2020 или гибкая разработка: что выбрать

Выбор методологии определяет не только темп работы, но и то, как вы будете управлять ожиданиями и бюджетом. В российской практике часто возникает дилемма: следовать строгому стандарту или использовать гибкие подходы. Важно понимать, что ГОСТ 34.602-2020, который регулирует порядок создания автоматизированных систем, не является обязательным для любого коммерческого проекта. Его стоит внедрять только если это прямо прописано в вашем договоре или если вы создаете критически важную инфраструктурную систему для крупного предприятия.

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

Сравнение подходов к разработке

Agile (Scrum, Kanban) лучше подходит для стартапов и инновационных продуктов, где требования размыты. Вы работаете короткими спринтами, после каждого из которых имеете работающий инкремент продукта. Это позволяет быстро тестировать гипотезы. Однако в этом случае вам нужно быть готовым к тому, что финальная стоимость и дата релиза будут плавающими. Для бизнеса, которому важна жесткая финансовая дисциплина, Agile требует очень сильного внутреннего менеджера продукта, который будет контролировать приоритеты задач.

На практике часто используют гибридный подход. Основные вехи (milestones) и критические интеграции фиксируются по жесткой модели, а визуальная часть и пользовательские сценарии дорабатываются итерационно. Это позволяет сохранить контроль над бюджетом, не теряя в гибкости продукта.

Юридические тонкости договора на разработку ПО

В российском законодательстве не существует единого понятия "договор на разработку программного обеспечения". Юристы обычно собирают конструкцию из нескольких договоров: договора подряда (на создание кода), договора возмездного оказания услуг (на проектирование, консалтинг) и договора авторского заказа (на передачу исключительных прав). Если вы подпишете просто "договор на услуги", вы рискуете столкнуться с тем, что по закону вы получите только "услугу по консультации", а не сам продукт.

Самое важное в таком документе - четкое разграничение между процессом и результатом. Процесс - это когда разработчик "старается", а результат - это когда у вас на руках есть работающее приложение, соответствующее ТЗ. В договоре должна быть прописана процедура приемки-передачи: как именно вы проверяете софт, в какие сроки должны быть предъявлены претензии и что считается моментом исполнения обязательств.

На что обратить внимание в тексте договора

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

1. Порядок изменения объема работ (Change Request). Как фиксируется стоимость новых функций?
2. Ответственность сторон за срыв сроков и баги. Есть ли штрафные санкции?
3. Порядок расторжения договора. Можете ли вы прекратить работу, если видите, что команда не справляется, и как при этом будут оплачены уже сделанные этапы?
4. Гарантийный период. Сколько времени подрядчик обязан исправлять найденные дефекты бесплатно?

Частая ошибка - отсутствие в договоре ссылки на техническое задание как на неотъемлемую часть. Без этого ТЗ юридически может не иметь силы, и доказать в суде, что приложение работает "не так, как мы договаривались", будет практически невозможно. ТЗ должно быть подписано обеими сторонами и являться приложением к договору.

Также не забудьте про интеллектуальную собственность. Если в договоре не указано прямо, что исключительные права переходят к вам, по умолчанию они могут остаться у разработчика как у автора. Это создаст огромные проблемы при попытке продать компанию или привлечь инвестиции в будущем.

Как зафиксировать передачу прав на исходный код

Владение работающим приложением - это только половина дела. Настоящая ценность бизнеса заключается в праве распоряжаться его кодом. Если вы не зафиксировали передачу прав, вы становитесь "заложником" разработчика. Любое изменение в приложении или перенос на другую команду будет стоить вам огромных денег, так как вы фактически будете использовать чужую собственность.

В договоре необходимо прямо перечислить объекты передачи. Недостаточно написать "права на ПО". Нужно указать: исходный код (source code), объектный код, техническую документацию, базы данных, интерфейсы, а также все подготовительные материалы и библиотеки, которые были созданы специально под ваш проект. Если разработчик использует сторонние open-source библиотеки, это тоже должно быть зафиксировано, чтобы вы понимали, какие лицензионные ограничения накладываются на ваш продукт.

Механизм передачи прав

Передача прав должна подтверждаться документально. Обычно это происходит через двусторонний Акт приема-передачи результатов работ. В этом акте должно быть четко указано, что с момента его подписания исключительное право на результаты интеллектуальной деятельности переходит к Заказчику в полном объеме. Рекомендуется также прописать способ передачи кода: например, через передачу прав доступа к репозиторию (GitLab, GitHub) под вашим контролем.

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

Также проверьте, как в договоре прописаны права на "предшествующий код" (background IP). Это те наработки, которые у разработчика уже были до начала вашего проекта (их собственные фреймворки, модули). Вы не сможете ими владеть, но вы должны получить бессрочную, безвозмездную и неисключительную лицензию на их использование в составе вашего приложения, иначе вы не сможете легально эксплуатировать продукт.

Новые требования к российскому ПО и реестру

Если вы планируете работать с государственным сектором или крупными корпорациями, вопрос включения вашего приложения в Реестр российского ПО становится критическим. С 1 марта 2026 года правила игры существенно изменились. Теперь недостаточно просто иметь российское юрлицо. Введено новое требование по контролю: критерий российского происхождения теперь основывается на владении долей, обеспечивающей контроль не менее 50% голосов в компании-разработчике.

Еще один важный аспект - совместимость с доверенными операционными системами. Согласно постановлению Правительства РФ от 28.11.2025 № 1937, это требование вводится поэтапно. Если ваше приложение относится к офисному софту, требования по совместимости уже действуют. Для прикладного и отраслевого ПО (к которому относится большинство мобильных приложений) крайний срок перехода на совместимость с доверенными ОС установлен на 1 июня 2027 года. Для промышленного софта сроки еще более поздние - с 1 января 2028 года.

Как подать заявку в реестр сегодня

На 18 октября 2026 года процедура подачи заявки выглядит следующим образом:

1. Подготовка полного пакета документов, подтверждающих происхождение кода и структуру владения компанией.
2. Наличие подтвержденной учетной записи на портале "Госуслуги".
3. Использование действующей усиленной квалифицированной электронной подписи (УКЭП) для подписания документов.
4. Подача заявки через личный кабинет на сайте реестра, который ведет Минцифры России.

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

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

Оценка компетенций команды и проверка портфолио

Когда вы переходите к выбору конкретной компании, не верьте красивым презентациям. Портфолио может быть составлено из проектов, которые были реализованы силами других команд или которые не дошли до релиза. Чтобы понять реальный уровень подрядчика, нужно смотреть глубже. Просите не просто ссылки на App Store или Google Play, а кейсы с описанием конкретных задач и технологий.

Хороший кейс в портфолио - это история решения проблемы. Например: "Разработали приложение для логистики, которое позволило сократить время обработки заказов на 20% за счет внедрения алгоритма оптимизации маршрутов". Если в портфолио только "дизайнерские" проекты с красивыми картинками, но без сложной логики, то для серьезного бизнес-приложения такая команда может не подойти.

Как проводить интервью с техническими специалистами

Не ограничивайтесь общением с менеджером по продажам. Вам нужно поговорить с тимлидом или архитектором, который будет непосредственно руководить разработкой. Задайте им несколько проверочных вопросов:

• Какой стек технологий вы рекомендуете для нашего типа нагрузки и почему?
• Как вы планируете обеспечивать безопасность данных пользователей?
• Как организован процесс тестирования (Unit-тесты, интеграционное тестирование, нагрузочное тестирование)?
• Как вы будете передавать нам документацию и код?

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

Еще один полезный прием - попросить провести небольшой платный пилотный проект (PoC - Proof of Concept). Это небольшая задача на 2-4 недели, которая позволит вам увидеть команду в деле, оценить их коммуникацию и качество кода до того, как вы подпишете основной контракт на миллионы рублей.

Типичные ошибки при выборе разработчика приложения

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

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

Другие критические промахи

К списку типичных ошибок можно добавить следующие:

1. Игнорирование этапа проектирования. Попытка сразу перейти к написанию кода без проработки UX/UI и архитектуры приводит к тому, что на середине проекта приходится все переделывать.
2. Отсутствие контроля за репозиторием. Если код хранится только на серверах подрядчика, а у вас нет доступа к Git-репозиторию, вы находитесь в заложниках.
3. Неправильный выбор модели оплаты. Выбор Fixed Price для проекта с постоянно меняющимися требованиями - прямой путь к бесконечным спорам о стоимости изменений.
4. Забытые требования по безопасности. Игнорирование защиты персональных данных (ФЗ-152) может привести к огромным штрафам и блокировкам со стороны регуляторов.

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

Этапы контроля качества и приемки готового продукта

Приемка приложения - это не просто нажатие кнопки "Одобрить" в конце проекта. Это многоуровневый процесс, который должен быть четко регламентирован в договоре. Если вы принимаете продукт только по визуальному сходству с макетами, вы пропускаете 90% проблем, которые всплывут в первый же день реальной эксплуатации.

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

Профессиональный подход к приемке

Для качественной приемки необходимо задействовать несколько направлений контроля:

• QA-тестирование (Quality Assurance): проверка продукта на наличие багов, ошибок логики и несоответствий интерфейса.
• Нагрузочное тестирование: проверка того, как приложение ведет себя при одновременной работе 100, 1000 или 10 000 пользователей.
• Тестирование безопасности: проверка на уязвимости, устойчивость к взлому и корректность хранения персональных данных.
• Приемочное тестирование (UAT - User Acceptance Testing): проверка продукта конечными пользователями или сотрудниками вашей компании, чтобы убедиться, что интерфейс удобен и понятен.

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

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

Что запомнить:

• ТЗ должно быть максимально детальным и являться частью договора.
• Проверяйте соответствие ПО новым требованиям реестра (контроль 50% голосов и совместимость с доверенными ОС).
• Исключительные права на код должны переходить к вам по акту приема-передачи.
• Выбирайте методологию (Agile или Waterfall) исходя из стабильности ваших требований.
• Приемка должна включать не только визуальный осмотр, но и глубокое техническое тестирование.