«Спасти проект от „специалиста“: инструкция по выживанию» — 3 февраля 2026 г. в 20:09:28.465
«Спасти проект от „специалиста“: инструкция по выживанию» Предыдущий пост был про диагностику проблемы. Этот — про что делать, если вы уже в этой ситуации. Вы передали проект, а получили груду скриптов, вечное «почти готово» и чувство глухой безысходности. Паника? Стоп. Дышите. Порядок действий ниже. Шаг 1: Прекратите давать новую работу Это первое и главное правило. Пока не понятен масштаб катастрофы, любые новые правки или задачи — это вода в бездонную бочку. Фиксируйтесь на текущем состоянии. Шаг 2: Запросите полный доступ и документы Требуйте прямо сейчас: Доступ к хостингу и домену. Доступ к репозиторию (Git, SVN). Доступ к админке сайта/CMS. Техническую документацию (если её нет — это уже диагноз). Хотя бы описание, как запустить проект локально. Если разработчик сопротивляется или тянет время («я скину вечером/завтра») — это мега-красный флаг. У вас должен быть полный контроль над вашим активом. Шаг 3: Проведите аудит силами другого специалиста Найдите независимого разработчика/архитектора и оплатите ему несколько часов на аудит. Его задача — дать ответы на вопросы: Работает ли оно вообще? Можно ли запустить проект с нуля по инструкции? Насколько код безопасен? Есть ли критические уязвимости? Насколько код поддерживаем? Это аккуратная структура или «спагетти-код», где всё связано со всем? Каков масштаб технического долга? Что можно патчить, а что нужно переписывать? Оценка трудозатрат на доведение до ума. Это не роскошь, это страховка. Отчёт аудитора — ваша главная козырная карта для дальнейших действий. Шаг 4: Примите стратегическое решение По результатам аудита у вас будет три основных пути: Вариант А (Лёгкие ранения): Код кривой, но проект работает. Действие: Нанимаете нового разработчика, передаёте ему аудит, плавно меняете команду. Со старым — обсуждаете фиксацию критических багов и формальную передачу дел. Вариант Б (Тяжёлые травмы): Проект еле дышит, каждая правка ломает две другие. Действие: Новому разработчику ставите задачу на рефакторинг и стабилизацию. Выделяете бюджет и время не на новые фичи, а на приведение в порядок того, что есть. Старого разработчика отстраняете от проекта. Вариант В (Клиническая смерть): Запуск невозможен, безопасность критически нарушена, архитектуры нет. Действие: Полная остановка. Принимаете горькое, но часто верное решение — не «латать труп», а начать заново с новой командой, используя старый проект лишь как нечёткий «референс функционала». Это может быть дешевле и быстрее в долгосрочной перспективе. Шаг 5: Проведите «развод» цивилизованно, но твёрдо Опирайтесь на факты из аудита, а не на эмоции. «В коде обнаружены X, Y, Z, что делает поддержку невозможной». Чётко обозначьте границы: «На этом этапе мы прекращаем сотрудничество. Ваша задача — обеспечить полный доступ и консультацию новому разработчику в течение N часов». Все договорённости — в письменном виде (даже в email). Философское послесловие: Как до этого не доводить? Дробление на этапы: Никогда не заказывайте «сайт». Заказывайте «прототип», затем «вёрстку», затем «базовую интеграцию». Оплата — по завершении каждого этапа. Проверяйте процесс, а не только результат: Попросите показать репозиторий, процесс деплоя, план работ. Компетентный специалист этим гордится и с радостью покажет. Техническое собеседование для фрилансера: Задайте 2-3 простых, но конкретных вопроса по его стеку. Не «знаете ли вы React?», а «как бы вы организовали подгрузку данных в этом типовом компоненте?». Смутная ответ — тревожный звоночек. Ищите не соло-гения, а командного игрока: Даже если человек работает один, он должен быть готов к код-ревью, общению и прозрачным процессам. Итог: Некомпетентность — это не приговор проекту. Это управленческий вызов. Хладнокровие, последовательность и привлечение третьих экспертов — ваш главный щит и меч.