Когда стоит менять подрядчика на проекте?
Наиболее эффективно, когда один подрядчик ведет проект на всем его пути: знает контекст, архитектуру и бизнес-логику. Но по мере роста проекта требования усложняются — и не каждая команда успевает адаптироваться.
В такие моменты смена подрядчика — нормальный шаг, чтобы вернуть контроль над продуктом и двигаться дальше быстрее
Сигналы, что пора менять подрядчика: 🔵дедлайны регулярно сдвигаются без понятных причин 🔵команда не справляется с задачами нового уровня 🔵нет прозрачности: сложно понять, как устроен продукт и почему все долго 🔵изменения становятся дороже, а внедряются медленнее
Один из таких кейсов был у нас: К нам пришел заказчик с прогрессивным веб-приложением (PWA) после предыдущего подрядчика. PWA — это приложение, которое выглядит и функционирует как нативное, хотя создано на основе веб-технологий.
Проект был в нестабильном состоянии: сроки затягивались, критические ошибки не исправлялись, документации практически не было.
На этапе аудита стало понятно: проблемы на всех уровнях — устаревшие библиотеки, отсутствие документации и некорректные технические решения.
Мы системно переработали приложение, за пару месяцев привели его в стабильное состояние и подготовили к дальнейшему масштабированию.
Если вы замечаете похожие сигналы — напишите нам, поможем оценить ситуацию и предложим решение
В этом посте были ссылки, но мы их удалили по правилам Сетки
