Что делать, если фрилансер сдал сломанный код

Что делать, если фрилансер сдал сломанный код

Сломанный код — это не то же самое, что обычная ошибка. Обычный баг возникает в функции, которая в целом работает; сломанный код может остановить релиз, заблокировать вход в систему или сделать файл непригодным к использованию уже в первый день. Это различие важно, потому что ваш следующий шаг должен соответствовать ущербу, а не настроению, и именно поэтому запрос что делать если фрилансер сдал сломанный код обычно начинается не с эмоций, а с оценки масштаба проблемы.

Начните с одного вопроса: кто-нибудь вообще может безопасно этим пользоваться? Если ответ — нет, воспринимайте это как проблему сдачи результата, а не как задачу на полировку. Если ответ — да, но ломается один из сценариев, скорее всего, речь о дефекте, который всё ещё нужно исправлять. Просто, но полезно.

Что считается «сломанный код» и чем он отличается от обычного бага?

Сломанный код обычно проявляется в 3 формах: незавершённая работа, нестабильная работа или работа, которая не запускается в согласованной среде. Кнопка формы, которая выдаёт ошибку при отправке, — это баг. А вот сценарий оформления заказа, который так и не доходит до оплаты, потому что фрилансер пропустил валидацию, файл маршрутизации или обязательный API-хук, — это уже сломанный код.

Сначала смотрите на масштаб. Если фрилансер обещал конструктор страниц, а сдал только шапку сайта, это не мелкий дефект. Если фрилансер прислал скрипт, который зависит от файла, нигде не упомянутого в договорённости, это тоже не мелкий дефект. Код может существовать, но поставка всё равно сломана.

Полезна простая проверка: можно ли оценить код по согласованному результату меньше чем за 5 минут? Если вам нужны скрытые знания, секретные шаги настройки или личное объяснение, чтобы оно вообще заработало, проблема серьёзнее, чем опечатка. В этот момент многим клиентам стоит вернуться к своим заметкам и при необходимости сопоставить ситуацию с тем, как безопасно нанимать фрилансера для следующего проекта.

Что нужно проверить в первую очередь перед обращением к фрилансеру?

Сначала воспроизведите проблему один раз, прежде чем писать. Два раза — ещё лучше. Используйте тот же браузер, то же устройство и, если возможно, тот же аккаунт. Запишите, что именно вы нажали, что произошло и где проявился сбой. Фраза «не работает» слишком расплывчата, чтобы кому-то помочь.

Затем зафиксируйте среду. Укажите название и версию браузера, операционную систему, URL сервера и то, использовали ли вы staging или production. Код, который работает в Chrome на ноутбуке, может падать в Safari на телефоне, и это различие потом сэкономит много времени на переписку.

Соберите доказательства, пока они ещё свежие: скриншоты, сообщения из консоли, логи сервера, ID ошибок и время сбоя. Если баг появился после деплоя, отметьте точный файл или версию, которую вы получили. Эти детали превращают расплывчатую жалобу в полезный отчёт.

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

Как сообщить о сломанном коде, не превращая это в спор?

Первое сообщение должно быть коротким, фактическим и с датой. Хорошая структура такая: 1) что сломалось, 2) где сломалось, 3) что вы ожидали, 4) что вам нужно дальше. Этого достаточно, чтобы начать разговор об исправлении без обвинительного тона.

Пример: «На staging-сайте контактная форма после отправки возвращает ошибку 500. Я ожидал, что форма отправит сообщение и покажет подтверждение. Я приложил скриншот и лог консоли. Пожалуйста, подтвердите причину и пришлите исправление или корректную сборку».

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

Если проект затрагивает публичный интерфейс, в сообщении нужно ясно указать последствия. Сломанная посадочная страница может сжечь маркетинговый бюджет за несколько часов; сломанная корзина — сразу лишить продаж. Драматичный абзац тут не нужен, чтобы понять масштаб проблемы.

Какие доказательства стоит приложить, чтобы фрилансер быстрее всё исправил?

Присылайте шаги воспроизведения по порядку, а не в виде истории. Шаг 1: войти в систему. Шаг 2: открыть панель управления. Шаг 3: нажать Export. Шаг 4: загрузка не срабатывает. Такой список позволяет фрилансеру точно повторить ваш путь.

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

Передайте информацию о версии самого результата. Если вы получили «v3», так и скажите. Если фрилансер выкатил патч после вашего последнего просмотра, укажите какой именно. Если есть приватный репозиторий, добавьте название ветки и хэш коммита.

Файлы полезны, но только правильные. Скриншот пустого экрана помогает. Короткая запись экрана на 4 минуты может быть ещё лучше, если на ней в одном проходе видны клики и сбой. Именно здесь фраза отзывы о фрилансере иногда становится важной, потому что шаблон неясной передачи задач часто заметен там раньше, чем в коде.

Когда нужно просить исправление, откат или возврат денег?

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

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

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

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

Что делать, если фрилансер говорит, что у него код работает?

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

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

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

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

Когда сломанный код становится проблемой передачи или владения?

Сломанный код превращается в проблему передачи, когда файлы приходят без шагов, необходимых для запуска. Сюда входят отсутствующие инструкции по установке, отсутствующие данные доступа, отсутствующие файлы окружения и отсутствующие инструкции по деплою. Код может быть на месте; владения им — нет.

Это часто случается в проектах, которые зависят от команды, а не от одного человека. Разработчик отправляет репозиторий, но учётные данные сервера остаются в личном сообщении. Дизайнер передаёт тему сайта, но инструмент сборки нигде не указан. Бэкенд-скрипт запускается только на машине фрилансера, потому что остальная настройка нигде не была записана.

В этот момент проблема уже не сводится к «исправьте баг». Вопрос в другом: «Может ли моя команда вообще принять эту работу?» Если ответ — нет, поставка неполная, даже если все файлы выглядят аккуратно. Здесь правила правила сайта 24freelance.pro. freelance могут быть полезной отправной точкой для понимания того, как должны быть организованы работа, файлы и коммуникация.

Некоторым командам также нужен чек-лист передачи перед принятием проекта. Одна строка для доступа. Одна — для хостинга. Одна — для учётных данных администратора. Одна — для структуры папок. Без этого передача может сорваться, даже если сам код хорош.

Как не допустить той же проблемы со сдачей в следующий раз?

Сформулируйте критерии приёмки до начала работы. Не абзац. Список. «Вход выполняется с корректными данными». «Экспорт создаёт CSV с 3 колонками». «Форма отправляет письмо и показывает сообщение об успешной отправке». Такие строки помогают легче заметить сломанный код, потому что цель видна заранее.

Заранее попросите тест-кейсы, особенно для функций с 2 и более ветками. Если фрилансер знает, как именно вы будете проверять, он с большей вероятностью будет строить решение под реальную проверку, а не под воображаемую. Проверка на staging тоже помогает, потому что она ловит сломанный код до того, как кто-то назовёт работу готовой.

Определите «готово» одной фразой, в которой есть файлы, доступ и подтверждение. Например: «Готово означает, что код запускается на нашем staging-сервере, в README описаны шаги настройки, а тестовый аккаунт подтверждает основной сценарий». Такое определение не спасёт от плохой работы, но сделает её заметной раньше.

Для сложных задач попросите короткую заметку о передаче проекта. Даже 5 пунктов могут потом сэкономить вам время: окружение, зависимости, известные ограничения, тестовые данные и кто отвечает за следующий шаг. Маленькая просьба, большой эффект.

И ещё одна практичная привычка: держите чат по проекту и финальный список файлов в одном месте. Если фрилансер присылает исправление по почте, а заметка по деплою лежит в чате, а пароль к серверу — в таблице, передача становится хрупкой. Хрупкая передача ломается под нагрузкой.