Технологии
Разработка программного обеспечения на заказ: как выбрать подрядчика
Сильные кейсы, подходящий стек и сопоставимая цена ещё не показывают, как подрядчик будет работать после старта проекта. Состав команды может измениться, сроки и бюджет — пересматриваться, а порядок контроля и передачи результата — остаться неясным. В статье разберём, по каким критериям оценить подрядчика, если предстоит разработка ПО на заказ, модернизация или развитие действующей веб-системы.
Какие критерии заказчики используют при выборе подрядчика
Чтобы понять, как компании сравнивают подрядчиков, мы изучили открытые тендеры на разработку и развитие веб-систем. Из требований заказчиков складывается базовый список критериев:
- Соответствует ли предлагаемое решение техническим требованиям проекта. В 90% тендеров был указан стек или требования к архитектуре, в 70% — к интеграциям, безопасности, производительности или масштабируемости.
- Есть ли у подрядчика релевантный опыт. Кейсы или другое подтверждение опыта запрашивали в 70% тендеров.
- Понятны ли стоимость и сроки. Их просили раскрыть в 60% случаев.
- Есть ли у подрядчика специалисты нужной квалификации. Состав или требования к команде указывали в 50% тендеров.
- Готов ли подрядчик поддерживать систему после запуска. Этот пункт встречался в 40% тендеров.
- Что получит заказчик после завершения работ. Передачу исходного кода, прав или технической документации оговаривали в 30% случаев.
- Как заказчик сможет контролировать работу. Регулярные встречи, демонстрации и приёмку результатов по этапам упоминали только в 10% тендеров.
Этот вывод согласуется с исследованием «Рейтинга Рунета», основанным на более чем 80 глубинных интервью с топ-менеджерами крупных компаний, работающих с digital-подрядчиками. Для всех опрошенных были важны опыт и экспертиза, подтверждённые кейсами. При оценке уже начавшейся работы заказчики называли и другие критерии: вовлечённость, соблюдение сроков, стабильность команды, ответственность и качество коммуникации.
Далее разберём, как оценить и выбрать подрядчика по критериям, которые не всегда очевидны: составу команды, процессу работы, условиям поддержки и передачи результата.
Как оценить опыт, команду и технологии подрядчика
Компания по разработке программного обеспечения может иметь сильное портфолио, но проект выполняют конкретные специалисты. Поэтому сначала нужно сопоставить опыт исполнителя с задачей, затем оценить проектную команду и только после этого переходить к предлагаемым технологиям.
Оцениваем опыт подрядчика на проектах сопоставимой сложности
Проект из той же отрасли не всегда релевантен. Простой промосайт для банка и высоконагруженный личный кабинет для финансовой компании относятся к одному рынку, но требуют разной архитектуры, состава команды и уровня ответственности. И наоборот, опыт в другой отрасли может быть полезен, если подрядчик уже решал задачи сопоставимого масштаба.
При оценке опыта важнее понять, насколько проект похож на ваш по масштабу и рискам. Корпоративная система с несколькими интеграциями и требованиями к непрерывной работе может быть более релевантным примером, чем сайт из той же отрасли. Отдельно стоит уточнить, за какую часть результата отвечал подрядчик: за весь проект или только за отдельный этап.
Хороший кейс объясняет исходную проблему, ограничения и принятые решения, а не только показывает готовый продукт. Если проект защищён NDA, подрядчик может рассказать о нём без названия заказчика и закрытых показателей. Даже в обезличенном описании должно быть понятно, какую задачу решала команда и чем этот опыт полезен для вашего проекта.
Полезно попросить исполнителя разобрать один или два релевантных проекта на встрече. Вопросы о возникших сложностях и причинах выбранных решений помогут понять, стоит ли за кейсом реальный опыт команды или только подготовленное описание из портфолио.
Конструктор финансовых моделей для СберИнфры
Как DIGITAL SECTOR объединил веб-интерфейс, Excel-модели и автоматические расчёты в одной системе.
Читать кейс →
Оцениваем состав и квалификацию проектной команды
До выбора подрядчика важно понять, кто войдёт в проектную команду и за что будет отвечать. Для сложной веб-системы одних разработчиков обычно недостаточно. Аналитик прорабатывает требования, тестировщики проверяют качество реализации, DevOps-инженер отвечает за инфраструктуру. В зависимости от проекта также может понадобиться UX/UI-дизайнер. Не все специалисты нужны постоянно, поэтому подрядчик должен объяснить, кто и на каком этапе подключится к работе.
Со стороны подрядчика должен быть назначен менеджер, который управляет сроками, бюджетом и качеством проекта. Для заказчика он становится единой точкой контакта и координирует работу команды. Важно уточнить, есть ли у него опыт управления проектами сопоставимого масштаба. На сложных проектах с большой командой или несколькими направлениями разработки могут работать несколько менеджеров под руководством групп-хеда.
Запросите предполагаемый состав команды и загрузку ключевых специалистов. Уточните, кто будет вести проект, кто принимает ключевые технические решения и отвечает за организацию выпуска релизов, привлекает ли компания субподрядчиков и как нового специалиста введут в курс дела при замене.
На раннем этапе подрядчик не всегда может назвать всех специалистов поимённо. В таком случае можно зафиксировать обязательные роли, требования к квалификации, схему управления проектом и порядок согласования замены. Если компания не готова описать команду и ответственных даже на уровне ролей, оценить её способность выполнить проект будет сложно.
Проверяем, как подрядчик подбирает технологии под задачу
Широкий технологический стек сам по себе не говорит о качестве решения. Важно, чтобы подрядчик не предлагал привычную ему технологию по умолчанию, а учитывал особенности проекта и уже существующей системы.
Попросите объяснить, почему выбран именно этот язык, фреймворк или CMS и какие альтернативы рассматривались. Подрядчик должен показать, как его предложение повлияет на сроки, стоимость разработки и дальнейшую поддержку. Важно также понимать, насколько легко будет найти специалистов для развития системы и не возникнет ли зависимость от одного поставщика.
Для действующей системы полная замена технологий нужна не всегда. Иногда разумнее сохранить текущий стек и устранить его слабые места. Если отдельные компоненты всё же необходимо заменить, подрядчик должен предложить поэтапный переход без остановки всей системы.
Если выбор объясняется только фразой «мы всегда работаем на этом стеке», а команда не может назвать ограничения своего решения, сравнивать такое предложение с другими будет сложно.
Сколько стоит отложенная модернизация веб-системы
Разбираем, из чего складывается цена отсрочки и как понять, когда систему действительно пора модернизировать.
Читать статью →
Как оценить процесс работы
Опытная команда и подходящие технологии ещё не гарантируют управляемый проект. Важно понять, как подрядчик уточняет задачу, фиксирует допущения и показывает заказчику результат по ходу работы.
Проверяем, на чём основана предварительная оценка
Предварительная оценка не заменяет полноценное обследование. Подрядчик не обязан бесплатно изучать весь код и инфраструктуру, но должен запросить достаточно информации, чтобы показать, что вошло в оценку, а что осталось за её пределами.
Для нового проекта он уточняет бизнес-цели, основные сценарии работы системы и предполагаемые интеграции. Если система уже существует, подрядчику также понадобятся сведения о её архитектуре, документации и известных проблемах. Доступ к исходному коду и инфраструктуре можно предоставить после оформления условий конфиденциальности и только в необходимом объёме.
Точная стоимость и срок, рассчитанные по короткому брифу, должны насторожить. Если данных недостаточно, подрядчик должен назвать диапазон и объяснить, какие допущения заложены в оценку и из-за чего она может измениться.
Для сложной или плохо документированной системы может потребоваться отдельное платное обследование. До его начала важно согласовать, что получит заказчик: уточнённые требования, выявленные риски и план дальнейших работ. Материалов должно быть достаточно, чтобы продолжить проект с другой командой.
Проверяем план работ и результат каждого этапа
После предварительной оценки подрядчик должен описать этапы разработки ПО, их сроки и ожидаемые результаты. Формулировки «аналитика», «разработка» или «тестирование» сами по себе не объясняют, что именно получит заказчик и как сможет проверить готовность результата.
У каждого этапа должен быть понятный итог. После аналитики это могут быть согласованные требования и схема интеграций, после проектирования — прототипы и ключевые архитектурные решения. Итерация разработки должна завершаться работающей частью системы, доступной для проверки в тестовой среде. Перед запуском подрядчик должен представить результаты тестирования и план действий на случай критической ошибки.
В плане также должны быть видны зависимости между работами и моменты, когда от заказчика потребуются данные или решения. Если приоритеты изменятся, подрядчик должен объяснить, как это повлияет на следующие этапы, сроки и бюджет.
План не обязан оставаться неизменным на протяжении всего проекта. Его задача — дать сторонам общий ориентир и заранее показать последствия изменений.
Проверяем, как подрядчик организует взаимодействие и контроль
Контроль не должен сводиться к итоговой приёмке через несколько месяцев. Но и постоянно вмешиваться в работу разработчиков заказчику не нужно. Управляемый процесс строится на регулярных контрольных точках и одном пространстве, где зафиксированы актуальные задачи, требования и принятые решения.
До начала работ подрядчик должен объяснить, как часто будут проходить рабочие встречи и демонстрации, где заказчик сможет увидеть статус задач и кто будет основной точкой контакта со стороны подрядчика. Отдельно стоит согласовать, как команда сообщает об отклонениях от сроков или бюджета, по какому каналу передавать срочные вопросы и кто с обеих сторон принимает решения по проекту.
Регулярные демонстрации помогают проверить, выполнены ли задачи и решает ли новая функция исходную проблему. Чем раньше обнаружено расхождение, тем меньше уже выполненных работ придётся пересматривать.
Если подрядчик не предоставляет доступ к задачам, не фиксирует договорённости и планирует показать результат только в конце проекта, заказчику будет сложно контролировать ход работ.
Проверяем подход к тестированию, безопасности и стабильности
Фраза «мы всё тестируем» мало говорит о качестве. Подрядчик должен объяснить, как изменение проходит путь от написания кода до выпуска: кто проверяет код, где тестируется новая функция и какие проверки выполняются перед релизом. Качество нужно контролировать на протяжении всей разработки, а не оставлять проверку на период перед запуском.
Набор проверок зависит от рисков конкретной системы. Для сервиса с пиками посещаемости важно нагрузочное тестирование, для системы с чувствительными данными — проверка прав доступа и фиксация действий пользователей. Интеграции нужно тестировать и при штатной работе, и при ошибках или недоступности внешнего сервиса.
Одних тестов для стабильности системы недостаточно. Подрядчик должен объяснить, как организованы мониторинг, резервное копирование и возврат к предыдущей версии при неудачном релизе. Это показывает, сможет ли команда быстро обнаружить проблему и восстановить работу системы.
Требования безопасности важно учитывать до начала разработки соответствующих функций, поскольку они влияют на архитектуру, хранение данных и доступы. Также стоит заранее уточнить, как подрядчик отличает дефект от нового требования и в какие сроки устраняет ошибки.
Нагрузочное тестирование сайта: как DIGITAL SECTOR повысил устойчивость интернет-магазина в 10 раз
Как команда нашла узкие места работающего интернет-магазина, устранила причины сбоев и подтвердила результат повторным тестированием.
Читать статью →
Проверяем условия поддержки и дальнейшего развития
Запуск не завершает жизненный цикл веб-системы. После него могут возникать ошибки и инциденты, а обновления зависимостей или изменения внешних сервисов требуют доработок. Поэтому ещё при выборе подрядчика важно понять, как он будет поддерживать систему после запуска.
Сначала уточните срок гарантии и какие ошибки подрядчик исправляет в её рамках. В условиях поддержки нужно разграничить гарантийные дефекты, инциденты в работающей системе и новые требования: для них могут действовать разные сроки и правила оплаты.
При сравнении условий SLA одного времени реакции недостаточно. Оно может означать лишь подтверждение, что обращение принято. Для критичной системы нужно понимать, когда команда начнёт устранять проблему, как будет информировать заказчика и в какой срок планирует восстановить работу сервиса.
Долгосрочная поддержка не должна делать заказчика зависимым от одного исполнителя. Подрядчик должен быть готов передать проект другой команде, если в будущем компания решит его сменить.
Техническая поддержка сайтов: что входит в услугу, как определить SLA и зоны ответственности
Разбираем, чем поддержка отличается от гарантии, что нужно зафиксировать в SLA и как распределить ответственность между заказчиком и подрядчиком.
Читать статью →
Что проверить перед финальным выбором подрядчика
Коммерческое предложение показывает, что подрядчик предлагает сделать и как сформировал оценку. До финального выбора стоит обсудить и условия, которые повлияют на работу после старта: как стороны будут принимать результат, согласовывать изменения и передавать материалы. На этом этапе не нужно согласовывать весь договор — важно понять, готов ли исполнитель закрепить ключевые договорённости.
Сравниваем состав коммерческих предложений
Итоговые суммы нельзя сравнивать, пока неясно, что в них входит. Одна компания по разработке ПО может учесть аналитику, управление проектом, тестирование и запуск, а другая — только разработку. В таком случае более низкая цена говорит не об экономии, а о меньшем объёме расчёта.
В предложении должны быть обозначены границы проекта, результаты этапов и допущения, на которых основана оценка. Важно также понять, какая команда заложена в стоимость, какие расходы оплачиваются отдельно и что подрядчик ожидает от заказчика для соблюдения сроков.
Модель оплаты зависит от характера проекта. Фиксированная стоимость подходит, когда объём подробно описан и вряд ли изменится. Для долгосрочного развития системы подходит ретейнер: за проектом на длительный период закрепляется полноценная команда с согласованной загрузкой и ежемесячным бюджетом, а заказчик может менять приоритеты в пределах этой загрузки. Возможен комбинированный вариант: отдельное обследование с фиксированным результатом, затем разработка по фиксированным этапам или в формате ретейнера.
Если оценки заметно различаются, попросите подрядчиков объяснить расчёт по одним и тем же этапам. Так станет понятно, чем вызвана разница: подходом, составом команды или тем, что часть работ не учтена.
Проверяем, готов ли подрядчик закрепить ключевые условия
До финального выбора запросите проект договора или перечень условий, которые подрядчик предлагает зафиксировать перед началом работ. Заранее обсудите порядок приёмки, оценки новых требований, передачи исходного кода, документации и доступов, а также условия перехода исключительных прав.
Договор на разработку ПО должен отражать реальные договорённости сторон. Если порядок работы остаётся только в переписке или подрядчик предлагает определить его после старта, заказчику будет сложнее оценить риски и сопоставить предложения.
Отдельно уточните, что произойдёт при приостановке проекта или смене исполнителя. Учётные записи для критически важных ресурсов лучше изначально оформлять на заказчика. Для готовых модулей подрядчика, сторонних продуктов и компонентов с открытым исходным кодом нужно заранее определить лицензионные ограничения.
Юридические формулировки можно проверить с профильным специалистом. На этапе выбора важнее понять, отвечает ли подрядчик на эти вопросы прямо и готов ли закрепить договорённости письменно.
Как сменить подрядчика и не остановить веб-систему
Что проверить при передаче работающей системы новой команде и почему одного кода и документации для этого недостаточно.
Читать статью →
Чек-лист для сравнения подрядчиков
Перед финальным выбором проверьте:
- Есть ли у компании проекты, сопоставимые с вашей задачей по масштабу, интеграциям и рискам?
- Понятно ли, какие специалисты войдут в команду, кто со стороны подрядчика управляет сроками, бюджетом и качеством и как будет согласована замена участников?
- Объяснил ли подрядчик выбор технологий, возможные альтернативы и ограничения решения?
- Запросил ли он достаточно данных и обозначил ли допущения предварительной оценки?
- Разбит ли план на этапы с проверяемыми результатами?
- Понятно ли, кто является основной точкой контакта, где отслеживать задачи, как часто проходят демонстрации и как команда сообщает об отклонениях?
- Соответствуют ли тестирование, безопасность и меры стабильности рискам вашей системы?
- Разделены ли условия гарантии, поддержки и новых доработок? Понятны ли сроки работы с критическими инцидентами?
- Позволяет ли коммерческое предложение сравнить состав работ, команду, модель оплаты и дополнительные расходы?
- Готов ли подрядчик закрепить порядок приёмки и изменений, права и передачу кода, документации и доступов?
Если на часть вопросов пока нет ответа, это не всегда означает, что подрядчик не подходит. Важно, может ли он объяснить, каких данных не хватает, предложить способ их получить и после этого зафиксировать договорённости.
Если вы выбираете подрядчика для разработки новой системы, модернизации или продолжения проекта после другого исполнителя, обсудите задачу с командой DIGITAL SECTOR. Мы уточним основные требования и расскажем, какая информация понадобится для предварительной оценки.
Согласен