Как выбрать подрядчика для разработки ПО: чек-лист для бизнеса

# Как выбрать подрядчика для разработки ПО: чек-лист для бизнеса Выбрать хорошего разработчика сложнее чем выглядит. За последние 5 лет я видел компании теряющие миллионы потому что выбрали неправильного подрядчика. Иногда это было дешёвой аутсорс-компанией, которая сбежала с деньгами. Иногда это была дорогая фирма, которая не поняла требования и написала неправильный код. А иногда это была даже дорогая фирма, которая заперла код в своём Git и хотела вечный сапорт. В этой статье я собрал чек-лист, который помогает оценить подрядчика за неделю и избежать самых больших ошибок. ## Этап 1: Проверка портфолио и кейсов Первое, что нужно сделать — посмотреть, что сделала компания раньше. Но не просто посмотреть сайт с красивыми картинками. Нужно посмотреть реальные проекты. **Вопросы, которые нужно задать:** - Могу ли я поговорить с клиентом, которого они ссылаются? (красный флаг если они говорят что не могут из-за NDA) - Сколько проектов они сделали в моей индустрии? - Какой был средний размер проекта по бюджету и времени? - Какой был в среднем율 сроков и бюджета? (если они говорят никогда не превышали — это ложь) **Что смотреть в кейсах:** - Технологии, которые они использовали, соответствуют моим требованиям? - Результаты реальные? (проверьте если возможно сами) - Есть ли количественные метрики улучшения? (если только красивые слова без цифр — подозрительно) - Кто был lead разработчик и всё ещё работает в компании? (ротация кадров — плохой знак) ## Этап 2: Техническая оценка После того как выбрали 2–3 кандидатов, нужно техническую оценку их способностей. Проведите tech screening. **Что проверить:** - Дайте им небольшую задачу (код-чеку на 2–3 часа) и посмотрите как они решают - Попросите их объяснить архитектуру одного из их проектов - Спросите как они обрабатывают технический долг - Спросите о системе контроля качества: есть ли код-ревью, юнит-тесты, CI/CD? Хороший подрядчик сможет объяснить свои технические решения простым языком. Если они начинают нести чушь или не могут ответить на вопросы — уходите дальше. ## Этап 3: Финансовая проверка Много компаний разоряются или сбегают потому что их финансовое положение плохо. Перед подписанием контракта проверьте: **Что проверить:** - Есть ли у них опыт работы по долгосрочным контрактам? (если только краткосрочные проекты — они могут быть не стабильны) - Каков размер команды и насколько она стабильна? (если ротация более 30% в год — плохо) - Есть ли у них резервный бюджет на неожиданные расходы? (они должны быть в состоянии пережить неудачный проект) - Какой их средний размер проекта? (если вы первый большой проект — риск выше) Попросите рекомендации от других клиентов. Не рекомендации, которые они дали, а поговорите со случайными клиентами, которых нашли. ## Этап 4: Управление проектами и коммуникация Технология — половина успеха. Другая половина — может ли подрядчик общаться и управлять проектом. **Что проверить:** - Какая у них методология? (Agile, Waterfall, что-то ещё?) - Как часто они дают отчёты? (еженедельно минимум) - Кто будет вашей точкой контакта? (должна быть одна ответственная персона) - Как они обрабатывают changes? (есть ли процесс или будут всё менять в последний момент?) - Какой их SLA на ответы на вопросы? (в день рабочий минимум) Попросите начать с пилотного проекта. Не берите сразу контракт на год. Сначала сделайте 1–2 месячный проект и поймите как вы работаете вместе. ## Этап 5: Контрактные условия Вот где много компаний делают ошибки. Неправильно составленный контракт может привести к конфликтам и потере денег. **Что должно быть в контракте:** - Описание scope: что именно будет сделано? (не "разработка приложения", а "разработка iOS-приложения с функциями A, B, C") - Фиксированная цена или time-and-materials? (фиксированная лучше для понимания рисков) - Сроки: когда нужно завершить каждый этап? (с штрафами за просрочку) - Условия платежа: сколько аванса, сколько по этапам, сколько в конце? (типовая схема: 30% аванс, 40% в середине, 30% в конце) - Что будет если они не выполнят требования? (должны быть штрафы) - Кто владелец кода? (вы должны быть владельцем всего кода, а не подрядчик) - Поддержка после запуска: есть ли бесплатная поддержка и на сколько месяцев? Многие разработчики сопротивляются штрафам за просрочку. Это красный флаг. Если они не готовы ручаться за сроки — они не уверены в своих силах. ## Этап 6: Первые 2 недели После подписания контракта первые 2 недели — критичны. Вот что нужно проверить: - Назначен ли lead разработчик и tech lead? - Есть ли план первых 2 недель? - Совпадают ли требования в контракте с тем что они понимают? - Создана ли система контроля версий и CI/CD? - Установлены ли регулярные встречи с отчётами? Если в первые 2 недели что-то не так — перерывайте контракт. Лучше потерять авансовый платёж чем потом 6 месяцев менять чужой код. ## Красные флаги, которые должны вас насторожить - "Мы никогда не превышаем сроки" — ложь, любой проект имеет неопределённость - "Нельзя поговорить с клиентом" — почему? Если нечего скрывать — клиент согласится - "Цена зависит от количества строк кода" — это неправильный метрик, люди работают, а не код - "Нет письменного контракта, только устная договорённость" — уходите дальше - "Мы используем последние технологии на рынке" — технология это инструмент, а не цель - "Уже 6 месяцев как началась разработка, но ничего не работает" — признак проблем в управлении ## Заключение Выбрать хорошего разработчика невозможно на 100%. Но если вы примените этот чек-лист, вы избежите самых больших ошибок. Помните: дешёвый разработчик часто дороже всего. Главное правило: если что-то чувствуется неправильно в первые 2 недели — скорее всего это неправильно и будет только хуже. Доверяйте своему чувству и не стесняйтесь менять подрядчика если нужно.