Вступление. Исповедь «бывших»

Мы работаем в вебе больше 15 лет. За это время мы сменили несколько команд, пережили пять «священных войн» фреймворков и похоронили три собственных стартапа. Но самый ценный опыт нам дали не успешные проекты, а те самые «скелеты в шкафу» — проекты, которые мы принимали на поддержку от других подрядчиков.

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

Мы знаем, как выбрать подрядчика, потому что мы сами были и заказчиками, и исполнителями. Эта статья — не скучный чек-лист с пунктами «посмотрите портфолио». Это инструкция по вскрытию «черного ящика» под названием «IT-аутсорсинг».

Часть 1. «Археология» или почему портфолио — это ловушка

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

Необычный пример: Один наш клиент пришел к нам с портфолио студии, где были «Сбер» и «Яндекс» в кейсах. Оказалось, что студия делала для Сбера… внутреннюю страницу 404 для корпоративного портала, а для Яндекса — баннер. Объем работ — 2 часа. А нам предстояло делать ядро CRM-системы.

Как проверять реальный опыт?

  1. Просите ссылку на живые проекты, а не на скриншоты. Зайдите в них как пользователь - так вы сможете объективно оценить работу.
  2. Спрашивайте не «что вы сделали?», а «как вы это делали?» Вопрос к техническому специалист: «Какой была архитектура базы данных в проекте Х и почему вы выбрали именно ее?» Если он начинает мяться и переводить тему на дизайн — это красный флаг. Профи помнит боль своего кода годами.

Часть 2. Техническое собеседование для чайников (или как устроить стресс-тест)

Вы не обязаны знать PHP или Python. Но вы обязаны знать, как задавать правильные вопросы. Мы называем это «методом трех слоев».

Слой 1. Вопрос про «Красную кнопку»

Спросите: «Представьте, что в час пик наш сайт ложится от нагрузки. С чего вы начнете расследование?»

  • Плохой ответ: «Увеличим серверные мощности» (значит, они умеют только закидывать деньги на железо).

  • Хороший ответ: «Посмотрю медленные запросы в БД, проверю кеширование и логи nginx. Сделаю профилирование кода».

  • Лучший ответ: «Я сначала проверю, не забыли ли мы поставить очередь для отправки писем и не висит ли внешний API платежей, потому что чаще всего падает не код, а интеграция».

Слой 2. Тест на «Правки»

В разработке правки — это святое. Покажите им скриншот макета и скажите: «Вам нужно подвинуть блок с формой на 15 пикселей вправо и поменять шрифт кнопки. Сколько это стоит и как долго делается?»

Если вам называют сумму больше 1000 рублей и срок более 2 часов — бегите. Честный подрядчик скажет: «Это 10 минут, мы сделаем бесплатно в рамках поддержки». Если он начинает рассказывать про сложности адаптивной верстки — он либо дурит вас, либо у него настолько плохо написан код, что любой чих требует пересборки всего проекта. Вам такой не нужен.

Слой 3. Тест на «Документацию»

Спросите: «Где лежит ваша документация по проекту? Покажите мне схему взаимодействия микросервисов (или структуру папок).»

В 90% случаев вам покажут Google-документ с паролем от админки. Это провал.
Профессиональная команда ведет документацию как часть кода. Если разработчик уволен (а он уволится, это факт), оставшиеся должны понять, как работает логика за 5 минут. Ищите команды, которые используют Swagger/OpenAPI для API и генерируют документацию автоматически.

Часть 3. Самый сложный вопрос: «Умеете ли вы говорить НЕТ?»

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

Ситуация из жизни:
Клиент попросил сделать бесконечный скролл на странице каталога из 10 000 товаров, совмещенный со сложной фильтрацией по цене. Первая студия сказала: «Ок, сделаем!» и ушла в закат через 3 месяца с багой, где скролл работал, но фильтр сбрасывался каждый раз.
Вторая студия (нынешняя) сказала: «Нет, это убьет производительность на мобилках. Давайте сделаем постраничную пагинацию с предзагрузкой следующей страницы (infinite scroll с пагинацией) и добавим кнопку "Показать все", но скроем ее для неавторизованных». Они показали цифры нагрузки, и клиент согласился.

Как проверить эту компетенцию на собеседовании?

Опишите реальную (или выдуманную) спорную задачу. Например: «Мы хотим хранить историю изменения цены товара каждый раз, когда пользователь кликает на кнопку, в 20 разных таблицах». Спросите: «Как вы это реализуете?»
Настоящий техдир начнет задавать встречные вопросы: «Зачем вам 20 таблиц? Может, хватит одной с полем action? А точно ли нужно логировать каждый клик, может, только фактические изменения?»

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

Часть 4. Техподдержка. Инструкция по выживанию

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

Разделим подрядчиков на два типа:

  1. «Пожарные». Сидят в телеграме. На сообщение «Упал сайт» приезжают через 3 часа и тушат. Часто это фрилансеры или маленькие студии.
  2. «Сантехники». Приходят раз в месяц, все проверяют, "смазывают" механизмы, обновляют версии библиотек, даже если ничего не сломалось.

Выбирайте «Сантехников». Потому что профессиональные болезни сайта (незакрытые дыры безопасности, устаревшие SSL-сертификаты, переполнение логов) убивают сайт чаще, чем кривые руки верстальщика.

Необычный способ проверки SLA (уровня сервиса):

Не спрашивайте: «Как быстро вы отвечаете?»
Спросите: «Расскажите случай, когда вы не уложились в срок реакции. Что произошло и как вы это исправляли?»

Если вам говорят «Мы никогда не опаздываем» — это ложь. Все опаздывают. Честные назовут дату, скажут, что это была проблема провайдера или сложный баг, и продемонстрируют, что пересмотрели свои регламенты.

Пункт о разделении ответственности (критично):

В договоре должно быть черным по белому написано, кто отвечает за работоспособность внешних сервисов.
Пример: Вы подключили оплату через эквайринг. У эквайринга сбой. Сайт не принимает деньги.
Плохой подрядчик выставит вам счет за «внеплановую диагностику» и будет перекладывать вину.
Хороший подрядчик пропишет, что мониторинг внешних сервисов — его обязанность, и в случае сбоя он автоматически переключит вас на резервный шлюз (если это возможно), либо просто проинформирует вас без дополнительной оплаты, потому что это входит в базовую ставку.

Часть 5. Тест на «Наследство» (самый страшный)

Рано или поздно вы захотите уйти от этого подрядчика. Это нормально. Как проверить, есть ли у вас будущее?

Задайте вопрос: «Мы хотим провести аудит кода сторонней командой. Предоставите ли вы полный доступ к репозиторию и документации?»

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

Профессиональная команда скажет: «Конечно. Вот ссылка на репозиторий, вот инструкция по развертыванию локального стенда. Мы также готовы провести митинг с новой командой, чтобы передать знания (за отдельные деньги, но мы это предлагаем сами)».

Золотое правило: В договоре должно быть прописано право на передачу кода и базы данных в машиночитаемом виде (SQL dump) в любой момент, без штрафов. Если этого пункта нет — не подписывайте договор. Вы покупаете не сайт, вы покупаете «поводок».

Часть 6. Астрология и бизнес-метрики

Напоследок — о самом важном, о чем забывают 99% статей.

Спросите подрядчика: «Как рост посещаемости на 1000% повлияет на стоимость вашей поддержки?»

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

Финальный блиц-опрос (всего 3 вопроса):

  1. Назовите три ваши самые серьезные ошибки в прошлом году. (Если ошибок нет — вы разговариваете с роботом или дилетантом).
  2. Как вы обновляете ядро CMS (если она есть) при выходе критической уязвимости в выходные? (Процесс должен быть расписан).
  3. Покажите скриншот вашего мониторинга (Zabbix, Grafana). Если там пусто или установлен только Яндекс.Метрика — они видят сайт как слепой котенок. Нужен мониторинг сервера: память, CPU, IOPS, количество открытых соединений.

Заключение. Уравнение с двумя неизвестными

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

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

Проведите этот мини-экзамен. Если студия проходит хотя бы 7 из 10 пунктов — подписывайте договор. Если проваливается на тесте с «бесплатной правкой на 15 пикселей» — бегите дальше, там болото.

Мы прошли через это. Мы наступали на эти грабли, и у нас на лбу все еще есть шишки. Но теперь мы точно знаем: лучше переплатить 20% за прозрачность и честность, чем потом платить 200% за героическое переписывание кода очередному «спасителю».

Удачного выбора. И пусть ваш код будет чистым, а аптайм - 100%.