Разработка ПО на заказ: как выбрать подходящую команду

Молдавская компания, как правило, приходит к идее программного обеспечения на заказ по одной конкретной причине: внутренний процесс вырос за пределы того, что может удержать Excel-файл или готовая система, либо клиенты требуют функциональность, которую ни один продукт на рынке не предлагает именно так, как нужно компании. Следующий вопрос — не «сколько это стоит», а менее обсуждаемый: кто на самом деле строит это программное обеспечение и по какой форме договора. Это решает, больше чем первоначальный бюджет, закончится ли проект рабочим продуктом, которым компания владеет, или оплаченным счётом и приложением, которое никто внутри не может изменить без первоначального подрядчика.

Три способа построить, а не один

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

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

Внешняя команда (агентство или компания-разработчик). Обычно стоит дороже за час, чем фрилансер, потому что цена включает управление проектом, тестирование и, в большинстве случаев, резерв — кто-то другой из команды может продолжить работу, если один человек недоступен. Для проекта с реальным бюджетом и ставками эта дополнительная стоимость покупает устойчивость, а не просто «бренд».

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

Фиксированная цена против time & material: это не взаимозаменяемые понятия

Две модели контрактации отвечают на разные вопросы, а путаница между ними — источник многих конфликтов между клиентами и подрядчиками.

Фиксированная цена (fixed price) означает, что подрядчик оценивает весь проект на основе заранее установленного документа требований и предлагает общую цену, независимо от того, сколько реальных часов будет потрачено. Работает хорошо, когда требования уже чёткие, устойчивые и детально документированы — потому что подрядчик берёт на себя риск неверной оценки, но обычно отказывается от любого изменения объёма работ без формального пересмотра цены.

Time & material (T&M) означает оплату на основе фактически отработанных часов по установленной ставке, без заранее зафиксированной общей цены. Это подходящая модель, когда продукт определяется по ходу работы — сложные приложения с множеством проектных решений, которые становятся ясны только в процессе разработки — потому что она позволяет корректировать требования без пересмотра всего договора при каждом небольшом изменении. Риск, однако, переходит к клиенту: проект без установленного максимального бюджета и без регулярных отчётов о прогрессе может расти неконтролируемо.

Практический вариант, часто используемый, сочетает оба подхода: фиксированная цена для этапа анализа и дизайна, затем time & material для самой разработки, с согласованным максимальным потолком бюджета, пересматриваемым на каждом этапе (спринте). Независимо от модели, договор должен явно указывать, что происходит при изменении требований по ходу работы — потому что на практике они меняются почти всегда.

Кто владеет исходным кодом в конце — чаще всего упускаемый вопрос

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

Три простые меры предотвращают эту ситуацию: - Письменное условие о полной передаче прав в договоре, а не просто устное обещание, что «конечно, это ваше». - Реальный доступ к репозиторию кода (например, на GitHub или GitLab) на протяжении всей разработки, а не только архив, отправленный в конце — постоянный доступ также показывает, что реально строится, а не только то, что сообщается. - Минимальная техническая документация, передаваемая в конце проекта: как устанавливается приложение, какие зависимости оно использует, как делать резервную копию и восстановление. Без неё любому новому подрядчику нужны недели только на то, чтобы понять, что уже существует.

Как на практике проходит серьёзный проект разработки на заказ

• 1. Обсуждение для выяснения деталей — подрядчик понимает реальный процесс компании, а не только список запрошенных функций; многие первоначальные требования уточняются или отбрасываются на этом этапе, до того как они обойдутся во время разработки.
• 2. Документ требований и оценка — что строится, в каком порядке, и что явно остаётся за пределами первоначального проекта (scope), чтобы избежать неконтролируемого расширения работ по ходу дела.
• 3. Дизайн и прототип, проверенный с компанией до написания производственного кода — намного дешевле исправить неверный экран на бумаге, чем уже построенную функциональность.
• 4. Итеративная разработка, как правило, циклами (спринтами) по одной-две недели, с рабочей версией для проверки в конце каждого цикла, а не единой поставкой в конце всего проекта.
• 5. Тестирование, как техническое (автоматическое), так и приёмочное со стороны компании (UAT — user acceptance testing), перед запуском, а не после первых жалоб пользователей.
• 6. Запуск, как правило, постепенный — ограниченная группа пользователей до всего персонала — чтобы ограничить влияние ошибки, не обнаруженной при тестировании.
• 7. Передача и поддержка, с документацией и доступом, описанными выше, и отдельным чётким договором о том, что происходит после запуска.

Предупреждающие сигналы при выборе подрядчика

• Отсутствие письменного документа требований — только устное обсуждение и общая оценка, без ничего, на что можно сослаться, если проект отклонится от курса.
• Нежелание явно обсуждать права на код — серьёзный подрядчик не избегает этого разговора, потому что это стандартный вопрос, а не деликатный.
• Отсутствие отдельной тестовой среды (staging) от продакшена — любое изменение, протестированное прямо на живой системе, рискует затронуть реальных пользователей.
• Отсутствие автоматических тестов или плана тестирования для критических функций — признак того, что ошибки будут обнаружены клиентами, а не подрядчиком.
• Отсутствие обсуждённого плана поддержки до запуска — как если бы приложение само себя обслуживало после поставки.
• Цена значительно ниже средней по другим предложениям без чёткого объяснения причины — как правило, означает сокращённый объём, более низкое качество или скрытые дополнительные расходы позже.

Что подготовить перед обращением к подрядчику

• Бизнес-цель, а не только технический список — какую реальную проблему решает приложение, для кого, и как измеряется успех.
• Обязательные функции против «было бы хорошо», чётко разделённые — подрядчик может намного точнее оценить объём, который явно отличает то, что должно быть с запуска, от того, что может появиться на более позднем этапе.
• Реалистичный диапазон бюджета, не обязательно точную цифру, но достаточно чёткий, чтобы подрядчик мог сказать уже после первого разговора, укладывается ли проект в него.
• Кто принимает решения со стороны компании — единая точка контакта с полномочиями принятия решений значительно ускоряет проект по сравнению с согласованиями, проходящими через несколько человек на каждом шаге.
• Существующие системы, с которыми приложение должно интегрироваться — 1С, CRM, существующий сайт — упомянутые явно с первого обсуждения, а не обнаруженные на середине разработки.

Наши услуги по веб- и программной разработке охватывают именно такой тип проекта, от первоначального обсуждения до запуска и постоянной поддержки. Для компаний, у которых уже есть представление о стоимости перед запросом предложений, гид о том, сколько стоит создание сайта в Молдове объясняет структуру цены для более простых проектов онлайн-присутствия; для поддержки и ежедневного администрирования приложения после запуска наши услуги по ИТ-аутсорсингу покрывают компонент непрерывной работы.

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

Сколько стоит разработка программного обеспечения на заказ? Полностью зависит от сложности, количества интеграций с другими системами и объёма часов разработки, тестирования и дизайна — единого рыночного тарифа, который можно привести здесь без риска ввести в заблуждение, не существует. Запросите письменные предложения у двух-трёх подрядчиков на основе одного документа требований.

Фиксированная цена или time & material — что выбрать? Фиксированная цена работает хорошо, когда требования уже чёткие и устойчивые. Time & material больше подходит, когда продукт определяется по ходу работы, через итерации, потому что требования могут меняться без пересмотра всего договора.

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

Фрилансер, внешняя команда или штатный сотрудник — что подходит небольшой компании? Штатный сотрудник имеет смысл только для постоянной потребности в разработке. Для проекта с чётким началом и концом фрилансер дешевле, но рискованнее с точки зрения непрерывности, а внешняя команда обычно стоит дороже за час, но снижает риск застоя.

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

Выбирайте структуру договора раньше, чем подрядчика

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

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