Cómo escribir un alcance de proyecto que realmente evite el scope creep

El scope creep no empieza cuando un cliente pide una función extra en la cuarta semana. Empieza cuando escribiste “rediseño del sitio web” en el contrato y cada uno tenía una imagen diferente en la cabeza.

Un alcance de proyecto bien redactado no evita que los clientes pidan más. Deja claro cuándo lo hacen.

El verdadero propósito del alcance

La mayoría de los freelancers tratan el alcance como un trámite — un resumen de lo discutido en el brief. No es para eso.

El alcance del proyecto es una definición compartida de “terminado”. Cuando el proyecto concluye, ambas partes deben poder leer el documento y coincidir: sí, esto se entregó. Cualquier desacuerdo en el momento de facturar significa que el documento no era suficientemente preciso.

Escríbelo para la persona de contabilidad que nunca asistió a ninguna reunión, no para la persona con la que hiciste la llamada de inicio.

Qué incluir

Entregables, no actividades. “Tres rondas de entrevistas con usuarios” es una actividad. “Un informe de investigación que sintetiza los resultados de tres entrevistas con usuarios, con una lista priorizada de puntos de fricción” es un entregable. Los entregables tienen fin. Las actividades no.

Exclusiones explícitas. La parte más útil de un alcance es lo que no está incluido. Si el SEO no está en el alcance, dilo. Si el soporte post-lanzamiento no está incluido, dilo. Los clientes suelen asumir que el trabajo adyacente está incluido por defecto — nombrar explícitamente lo que queda fuera elimina esas suposiciones.

Rondas de revisiones. Cuántas, qué cuenta como ronda, y qué pasa cuando se superan. “Dos rondas de revisiones” no dice nada sin definir qué es una ronda. “Dos rondas de revisiones, definidas como un conjunto consolidado de comentarios por ronda, respondido en cinco días hábiles” es suficientemente preciso para hacerse cumplir. Tener la definición por escrito ayuda — pero saber qué decir cuando un cliente pone a prueba ese límite es igual de importante.

Criterios de aceptación. Para cada entregable principal, ¿cómo es “terminado”? No subjetivo (“el cliente está satisfecho”) — observable. “Wireframes aprobados por escrito por el cliente” o “tres opciones de logotipo finales entregadas en archivos vectoriales” son criterios verificables.

Qué aporta el cliente y cuándo. Acceso a cuentas, recursos existentes, contenidos, aprobaciones. Las fechas de entrega en tu cronograma dependen a menudo de los materiales del cliente. Si llegan tarde, el cronograma se desplaza. Indícalo explícitamente.

La conversación que hace que funcione

Puedes redactar un alcance perfecto y acabar igualmente en un conflicto si lo envías como PDF con “solo firma aquí.”

Repasa el documento en una llamada antes de que empiece el proyecto. Concretamente: “Quiero asegurarme de que tenemos la misma imagen de lo que está incluido y lo que no. ¿Podemos ir sección por sección?” Esto detecta malentendidos antes de que se conviertan en problemas. Los clientes que leen el documento solos suelen hojearlo. Los que lo discuten en una llamada lo entienden.

La referencia a los cambios de alcance

Añade una frase al documento: “El trabajo no descrito en este documento se presupuestará por separado por escrito antes de su ejecución.”

Esta frase hace dos cosas. Establece que el documento es el límite. E introduce el orden de cambio como mecanismo para añadir trabajo — antes de que nunca lo necesites. Si el proyecto se cancela antes de completarse, una cláusula de cancelación en el contrato garantiza la compensación por el trabajo ya realizado. Cuando un cliente pide algo fuera del alcance, la respuesta se convierte en “eso parece útil, te mando un presupuesto adicional” en lugar de una explicación de por qué no puedes simplemente añadirlo.

Lo que la mayoría de los alcances falla

Describen lo que harás, no lo que existirá al final.

Un documento que dice “el diseñador producirá conceptos para la página de inicio” deja abiertos el número, el formato y el nivel de fidelidad. Un documento que dice “dos conceptos de página de inicio entregados como mockups de alta fidelidad en Figma, cubriendo breakpoints de escritorio y móvil” cierra todas esas preguntas.

La prueba: ¿puede alguien que no sabe nada del proyecto leer el documento y saber exactamente qué se entregará? Si la respuesta requiere contexto de otras conversaciones, el documento necesita más especificidad.

Timescanner registra las horas reales por cliente y proyecto — para que, si surge un conflicto sobre el alcance, tengas el historial documentado del tiempo dedicado, no una reconstrucción de memoria. Compatible con cualquier calendario iCal.