10 критериев выбора подрядчика на разработку: что проверить, чтобы не переплачивать за ошибки после старта

Сильные кейсы, привлекательная цена и хорошая презентация ещё не показывают, как подрядчик будет работать после старта. Если вам предстоит разработка программного обеспечения на заказ, стоит заранее проверить, как будет устроена работа после подписания договора. В DIGITAL SECTOR собрали 10 критериев, которые стоит проверить до финального выбора подрядчика

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

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

Мы изучили открытые тендеры на разработку и развитие веб-систем. В 90% из них были указаны технический стек или требования к архитектуре. В 70% встречались требования к интеграциям, безопасности, производительности или масштабируемости. Подтверждение опыта подрядчика запрашивали тоже в 70% тендеров.

Стоимость и сроки запрашивали в 60% случаев, состав или квалификацию команды — в 50%, условия поддержки после запуска — в 40%. А дальше частота резко снижалась. Передачу кода, прав или документации оговаривали в 30% тендеров, а регулярные встречи, демонстрации и приёмку результатов по этапам — только в 10%.

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

Чтобы оценить подрядчика, заказчику не обязательно разбираться в архитектуре или проверять код. Гораздо важнее задать правильные вопросы и посмотреть, насколько конкретно команда на них отвечает.

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

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

Поэтому хороший кейс стоит читать не как галерею готовых экранов. Смотрите, описаны ли в нём:

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

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

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

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

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

Компания по разработке ПО может быть большой, но заказчику важнее знать, кто именно будет работать над его проектом.

Если вы не технический специалист, список языков и фреймворков в презентации подрядчика мало помогает принять решение. Гораздо полезнее спросить: почему для проекта предлагается именно этот вариант?

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

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

Фраза «мы всегда делаем на этом» — слабое обоснование.

Точная цена после короткого брифа — не всегда хороший знак

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

Подрядчик не обязан бесплатно детально разбирать проект. Но он должен показать, на чём основана предварительная оценка.

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

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

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

«Аналитика — два месяца, разработка — четыре, тестирование — месяц» выглядит как план, но заказчику из него непонятно главное: что именно он увидит после каждого этапа.

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

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

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

Одна из неприятных ситуаций для заказчика — несколько месяцев слышать, что «всё идёт по плану», а впервые нормально увидеть систему почти перед запуском. Чем позже появляется обратная связь, тем дороже исправлять расхождения.

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

До старта должны быть понятны:

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

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

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

Важно и то, что происходит при проблемном релизе. Есть ли мониторинг? Резервные копии? Можно ли быстро вернуть предыдущую рабочую версию?

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

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

Сначала стоит разделить три разных типа работ.

Гарантия — исправление дефектов выполненной работы в рамках согласованных условий.

Поддержка — работа с инцидентами и эксплуатацией уже запущенной системы.

Развитие — новые функции и изменение требований.

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

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

Заказная разработка ПО не заканчивается релизом: поддержку и дальнейшее развитие лучше обсудить заранее.

Подробнее о SLA и зонах ответственности мы рассказывали в статье «Техническая поддержка сайтов: что входит в услугу, как определить SLA и зоны ответственности».

Допустим, один подрядчик оценил проект в 8 млн рублей, другой — в 11 млн. Кажется, что сравнить предложения легко. Но сначала нужно открыть состав работ.

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

При сравнении стоит посмотреть:

При сравнении предложений стоит учитывать и формат сотрудничества. Fixed Price — фиксированная стоимость за заранее согласованный объём работ. Такой вариант подходит, когда требования можно достаточно подробно определить до начала разработки. Retainer — долгосрочный формат, при котором за проектом закрепляется команда. Он подходит для систем, которые нужно регулярно развивать и где важно сохранить стабильный состав специалистов.

Форматы можно сочетать: например, предпроектную аналитику провести за фиксированную стоимость, а для дальнейшего развития системы закрепить команду в формате ретейнера. Важно заранее понимать, как в выбранном формате будут контролироваться объём работ и бюджет.

На этапе выбора подрядчика не требуется согласовать каждую юридическую формулировку. Но некоторые вещи лучше прояснить ещё до окончательного решения.

Договор на разработку ПО должен фиксировать тот порядок работы, который подрядчик описал на встречах и в коммерческом предложении.

Стоит заранее обсудить:

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

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

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

О том, что именно нужно передать новой команде и как проверить её готовность работать с проектом, мы подробно писали в статье «Как сменить подрядчика и не остановить веб-систему».

Перед финальным выбором пройдитесь по десяти вопросам.

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

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