Как понять, что пора менять подрядчика по разработке — чек-лист из практики

Иногда подрядчик уходит с рынка сам — мы писали о таком случае: как взяли под поддержку продукт после ухода вендора и удержали его на плаву, пока заказчик решал, что делать дальше (Когда вендор уходит). Но куда чаще происходит не это. Подрядчик никуда не уходит — вы просто слишком долго терпите тревожные звоночки, прежде чем признаёте что пора искать замену.

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

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

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

Как проверить: посмотрите на последние три-четыре срыва сроков подряд. Если причина каждый раз формулируется как что-то уникальное и непредсказуемое — скорее всего, дело не в невезении.

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

Здоровая отчётность — это то, что согласовывается на старте проекта: какая именно, как часто, в каком формате. И меняется по вашему запросу, если формат перестал быть удобным.

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

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

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

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

Не обязательно сразу расторгать договор — резкая смена подрядчика посреди проекта создаёт свои риски. Более рабочий путь:

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

Проведите прямой разговор с конкретными вопросами — не «как дела на проекте», а «кто отвечает за X», «почему сдвинулся срок Y», «когда будет отчёт по Z». Реакция на эти вопросы скажет больше, чем сами ответы.

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

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