Qué hacer cuando un freelancer entrega código roto

Qué hacer cuando un freelancer entrega código roto

El código roto no es lo mismo que un error normal. Un error normal aparece en una función que en su mayoría funciona; el código roto puede detener un lanzamiento, bloquear un inicio de sesión o hacer que el archivo sea inutilizable desde el día 1. Esa diferencia importa porque tu próximo movimiento debe coincidir con el daño, no con tu estado de ánimo.

Comienza con una pregunta: ¿puede alguien usarlo de manera segura? Si la respuesta es no, trátalo como un problema de entrega, no como una tarea de pulido. Si la respuesta es sí, pero un camino falla, es probable que estés lidiando con un defecto que aún necesita corrección. Simple, pero útil.

¿Qué cuenta como 'código roto' frente a un error normal?

El código roto generalmente se presenta en 3 formas: trabajo incompleto, trabajo inestable o trabajo que no puede ejecutarse en la configuración acordada. Un botón de formulario que lanza un error al enviar es un error. Un flujo de pago que nunca llega al pago porque el freelancer omitió la validación, el archivo de enrutamiento o el gancho de API requerido es código roto.

Mira el alcance primero. Si el freelancer prometió un generador de páginas y solo entregó el encabezado, eso no es un defecto pequeño. Si el freelancer entregó un script que depende de un archivo que nunca se mencionó en ninguna parte, eso tampoco es un defecto pequeño. El código puede existir, pero la entrega sigue estando rota.

Una prueba práctica ayuda: ¿se puede juzgar el código en función del resultado acordado en menos de 5 minutos? Si necesitas conocimiento oculto, pasos de configuración secretos o una explicación privada para que funcione, el problema es más grande que un error tipográfico. Este es el punto donde muchos clientes deberían revisar sus notas y, si es necesario, comparar el problema con cómo contratar a un freelancer de manera segura para el próximo proyecto.

¿Qué deberías verificar primero antes de contactar al freelancer?

Reproduce el problema una vez antes de escribir. Dos veces es mejor. Usa el mismo navegador, el mismo dispositivo y la misma cuenta si es posible. Anota exactamente en qué hiciste clic, qué sucedió y dónde apareció la falla. “No funciona” es demasiado vago para ayudar a alguien.

Luego anota el entorno. Registra el nombre del navegador, la versión, el sistema operativo, la URL del servidor y si usaste staging o producción. Un camino de código que funciona en Chrome en una laptop puede fallar en Safari en un teléfono, y esa diferencia puede ahorrar mucho ida y vuelta más tarde.

Recoge la evidencia dura mientras aún está fresca: capturas de pantalla, mensajes de consola, registros del servidor, IDs de error y la marca de tiempo de la falla. Si el error aparece después de un despliegue, anota el archivo o versión exacta que recibiste. Estos detalles convierten una queja vaga en un informe utilizable.

No cambies tres cosas a la vez. Si editas la configuración, reemplazas el conjunto de datos y reinicias el servicio, nadie puede decir qué cambio causó la falla. Mantén un camino de prueba fijo.

¿Cómo deberías reportar código roto sin convertirlo en una discusión?

Mantén el primer mensaje corto, factual y con fecha. Una buena estructura es: 1) qué falló, 2) dónde falló, 3) qué esperabas, 4) qué necesitas a continuación. Eso es suficiente para abrir una conversación de reparación sin sonar acusatorio.

Ejemplo: “En el sitio de staging, el formulario de contacto devuelve un error 500 después de enviar. Esperaba que el formulario enviara el mensaje y mostrara una confirmación. Adjunto la captura de pantalla y el registro de la consola. Por favor, confirma la causa y envía una solución o una versión corregida.”

Esa redacción no deja espacio para el teatro. También evita la trampa de culpar al freelancer por la intención, lo cual no puedes probar de todos modos. Mantén la frase sobre el impacto concreta: “los clientes no pueden enviar pedidos”, “el panel de administración se congela” o “el archivo exportado está vacío.” Esos detalles importan más que las emociones.

Si el proyecto tocó trabajo de cara al público, el mensaje debe mencionar la consecuencia claramente. Una página de aterrizaje rota puede desperdiciar un presupuesto de marketing en horas; un proceso de pago roto puede costar ventas de inmediato. Nadie necesita un párrafo dramático para entender eso.

¿Qué prueba deberías compartir para que el freelancer pueda solucionarlo más rápido?

Envía los pasos para reproducir en orden, no como una historia. Paso 1: inicia sesión. Paso 2: abre el panel de control. Paso 3: haz clic en Exportar. Paso 4: la descarga falla. Ese tipo de lista permite al freelancer seguir tu camino exactamente.

Incluye los datos de prueba que desencadenaron el problema, como una cuenta de demostración, un registro de muestra o un nombre de archivo específico. Si el código depende de una configuración de idioma, una extensión de navegador o una variable de entorno específica, menciónalo. Un detalle faltante puede desperdiciar una tarde.

Comparte la información de la versión del entregable en sí. Si recibiste “v3”, dilo. Si el freelancer publicó un parche después de tu última revisión, indica qué parche. Si hay un repositorio privado, incluye el nombre de la rama y el hash del commit.

Los archivos ayudan, pero solo los correctos. Una captura de pantalla de una pantalla en blanco es útil. Una grabación de pantalla de 4 minutos puede ser aún mejor si muestra los clics y la falla en una sola pasada. Aquí es donde la frase reseñas de freelancers a veces se vuelve relevante, porque un patrón de traspasos poco claros a menudo aparece allí antes de que aparezca en el código.

¿Cuándo deberías pedir una solución, un retroceso o un reembolso?

Elige el remedio por gravedad, no por frustración. Si el error es menor y la base de código es utilizable de otra manera, pide una solución. Si el código roto bloquea un lanzamiento o corrompe datos, un retroceso puede ser el movimiento seguro más rápido. Si el entregable es inutilizable o inseguro de reparar, un reembolso se vuelve razonable.

Haz una pregunta directa: ¿se puede arreglar esto sin dañar otras partes del proyecto? Si la respuesta es incierta y el freelancer está adivinando, retroceder puede protegerte mejor que esperar. Un mal parche puede convertir un módulo roto en tres módulos rotos.

Los reembolsos no deberían ser la primera amenaza en el mensaje 1. Deben venir después de una revisión clara de la evidencia y los términos de entrega. Aún así, si el trabajo no puede ser reparado en el lugar, o el freelancer admite que la arquitectura está mal, deberías dejar de tratar el archivo como si estuviera a solo un paso de terminar.

Hay un aspecto práctico aquí. Si un lanzamiento está bloqueando ingresos, cada hora de retraso tiene un costo, incluso si no lo calculas al centavo. Si el proyecto es privado y de bajo riesgo, la solución puede esperar más tiempo. El contexto importa.

¿Qué pasa si el freelancer dice que el código funciona de su lado?

No trates esa respuesta como una pelea. Trátala como una pista. En muchos casos, el problema es un desajuste de entorno: una máquina tiene dependencias en caché, otra usa una versión diferente de Node, o un servidor oculta un archivo faltante detrás de un paso de configuración local.

Pide la configuración exacta que usó el freelancer. Solicita los números de versión, los pasos de instalación y cualquier paso manual que siguieron después de clonar o subir. Si dicen “funcionó localmente”, necesitas la receta local, no un consuelo. Ese es el objetivo principal.

A veces el código depende de una suposición silenciosa. El freelancer puede haber asumido que existe una cuenta de administrador, o que ya había un archivo de configuración presente, o que la base de datos ya contiene un registro semilla. Esas suposiciones deberían haber sido documentadas, pero ahora la tarea inmediata es exponerlas una por una.

Mantén el tono calmado, incluso si la respuesta parece evasiva. Una línea como “Por favor, envía los pasos exactos de configuración que usaste para que pueda compararlos con mi entorno” es suficiente. Si el freelancer es cooperativo, la brecha a menudo se cierra rápidamente. Si no, al menos sabes que el problema ya no es solo técnico.

¿Cuándo se convierte el código roto en un problema de entrega o de propiedad?

El código roto se convierte en un problema de entrega cuando los archivos llegan sin los pasos necesarios para ejecutarlos. Eso incluye notas de instalación faltantes, detalles de acceso faltantes, archivos de entorno faltantes y instrucciones de implementación faltantes. El código puede estar presente; la propiedad no.

Esto sucede a menudo en proyectos que dependen de un equipo, no de una sola persona. Un desarrollador envía un repositorio, pero las credenciales del servidor están en un mensaje privado. Un diseñador entrega un tema de sitio, pero la herramienta de construcción nunca se menciona. Un script de backend solo se ejecuta en la máquina del freelancer porque el resto de la configuración nunca se escribió.

En ese punto, el problema no es solo “arregla este error”. Es “¿puede mi equipo adoptar este trabajo en absoluto?” Si la respuesta es no, la entrega está incompleta, incluso si cada archivo parece ordenado. Aquí es donde las reglas de las reglas del sitio 24freelance.pro. freelance pueden ser un punto de referencia útil sobre cómo se deben manejar el trabajo, los archivos y la comunicación.

Algunos equipos también necesitan una lista de verificación de transferencia antes de aceptar el proyecto. Una línea para el acceso. Una línea para el hosting. Una línea para las credenciales de administrador. Una línea para la estructura de carpetas. Sin eso, la entrega puede fallar incluso cuando el código en sí es sólido.

¿Cómo evitas el mismo problema de entrega la próxima vez?

Escribe criterios de aceptación antes de que comience el trabajo. No un párrafo. Una lista. “El inicio de sesión tiene éxito con credenciales válidas.” “La exportación produce un CSV con 3 columnas.” “El formulario envía el correo electrónico y muestra un mensaje de éxito.” Esas líneas hacen que el código roto sea más fácil de detectar porque el objetivo es visible.

Pide casos de prueba por adelantado, especialmente para características con 2 o más ramas. Si el freelancer sabe cómo vas a probar, es más probable que construya para la verificación real, no para una imaginada. La revisión en staging también ayuda, porque detecta código roto antes de que alguien lo considere terminado.

Define “hecho” con una oración que incluya archivos, acceso y prueba. Por ejemplo: “Hecho significa que el código se ejecuta en nuestro servidor de staging, el README enumera los pasos de configuración y la cuenta de prueba verifica el flujo principal.” Esa definición no resolverá un mal trabajo, pero hará que el mal trabajo sea visible más pronto.

Para tareas complejas, pide una nota de entrega corta. Incluso 5 viñetas pueden ahorrarte más tarde: entorno, dependencias, límites conocidos, datos de prueba y quién es el responsable del siguiente paso. Pequeña solicitud, gran recompensa.

Un último hábito práctico: mantén el chat del proyecto y la lista final de archivos en el mismo lugar. Si el freelancer envía una corrección por correo electrónico, pero la nota de implementación está en el chat y la contraseña del servidor está en una hoja de cálculo, la entrega es frágil. Las entregas frágiles fallan bajo presión.