Alcance de proyecto: qué definir antes de contratar a un dev

Antes de entregar tu software a alguien para que lo construya, hay un documento que decide si vas a recibir lo que pagaste. Cómo escribir un alcance de proyecto que protege el presupuesto de un fundador no técnico.

Camila tenía tres bullets en un audio de WhatsApp. “Una app de agendamiento para la clínica, con pago y recordatorio por mensaje.” El freelance escuchó, mandó un presupuesto de 28.000 euros y un plazo de ocho semanas. Ella aprobó. Cuatro meses después el número estaba en 51.000 euros, la app todavía no estaba en línea, y los dos discutían por mensaje si “informe de facturación” había estado o no incluido en el trato original.

Nadie mintió. Nadie fue incompetente. El problema es que el alcance del proyecto vivía en la cabeza de Camila, y nadie lo sacó nunca de ahí para ponerlo en papel. Cada vez que ella pedía “solo una cosita más”, el freelance decía que sí, porque no había ninguna línea escrita que dijera dónde terminaba el trabajo. El alcance no se violó. Nunca existió.

Para un fundador que no programa, el alcance de proyecto es el documento más barato y más subestimado de la construcción de software. Un alcance de proyecto es el documento que define, por escrito, qué se entrega, qué queda fuera y qué cuenta como terminado, antes de que exista una sola línea de código. Para un fundador no técnico, es el documento más barato y más subestimado del build. Es el contrato entre el problema que está en tu cabeza y el código que escribe otra persona. Cuando es bueno, el presupuesto se sostiene y la conversación con quien construye se mantiene civilizada. Cuando es vago, cada “imprevisto” se vuelve una negociación, y casi siempre pierdes.

Qué es el alcance de un proyecto

El alcance de un proyecto es el documento que define los límites del trabajo: qué se va a entregar, qué no, y qué resultados cuentan como “terminado”. Responde tres preguntas antes de que exista código: qué problema resuelve el software, qué está dentro del trato y qué queda fuera. Es la frontera del proyecto, dibujada por escrito.

Fíjate en la palabra “frontera”. Un alcance no es una lista de deseos ni una descripción entusiasmada del producto de tus sueños. Es un cerco. Dice “esto sí, aquello no”, y el “aquello no” importa tanto como el “esto sí”. La mayor parte del dinero que desaparece en proyectos de software desaparece en el espacio gris entre lo que el fundador imaginó y lo que el desarrollador entendió. El alcance existe para borrar ese gris.

Las guías de gestión de proyectos suelen tratar el alcance como una formalidad de cronograma, algo que un gerente certificado rellena en una plantilla. Para el fundador no técnico, es otra cosa: es la traducción de tu intención a un lenguaje que sobrevive a un desacuerdo. Si tú y quien construye chocan dentro de tres meses, y en algún momento van a discrepar sobre algo, el alcance es el único documento que zanja la discusión sin rencor.

Alcance del producto y alcance del proyecto: la diferencia que ahorra dinero

Vale la pena separar dos términos que viven pegados y confunden a todo el mundo. El alcance del producto describe el “qué”: las funcionalidades, las pantallas, lo que el usuario final puede hacer. Agendar una cita, pagar con tarjeta, recibir un recordatorio. El alcance del proyecto describe el “cómo” y el “hasta dónde”: el trabajo necesario para entregar ese producto, incluyendo lo que está dentro del contrato y lo que no.

En la práctica un fundador necesita los dos, pero falla más en el segundo. Casi cualquiera puede listar lo que la app debe hacer. Casi nadie escribe lo que el proyecto no incluye. Y es justo ahí donde el presupuesto estalla: no en las funcionalidades que listaste, sino en las que diste por obvias y el desarrollador dio por fuera.

Un ejemplo concreto. “La app envía un recordatorio por mensaje” es alcance de producto. Ahora vienen las preguntas de alcance de proyecto: ¿el recordatorio va por SMS, por WhatsApp o por correo? ¿Quién paga la cuenta de la API de mensajería? Si la clínica quiere cambiar el texto del recordatorio por su cuenta, eso es un panel de configuración, ¿y está en el trato? Cada una de esas respuestas cuesta horas de trabajo. Un alcance que se detiene en “envía un recordatorio” dejó tres decisiones de dinero abiertas, y en todas el silencio se lee a favor de quien cobra por hora.

Por qué el alcance es el seguro más barato que un fundador puede comprar

Piensa en el alcance como un seguro. Gastas algunas horas escribiendo un documento que, en el mejor caso, parece innecesario porque nada salió mal. Pero el costo de no tenerlo aparece siempre en el peor momento: cuando el dinero ya se gastó, el plazo ya estalló, y lo único que queda para resolver la disputa es la memoria selectiva de dos personas cansadas.

Los fundadores no técnicos están especialmente expuestos aquí por una razón simple: no puedes juzgar el trabajo por el código. No abres el repositorio para comprobar que todo está. Tu única ancla de “esto se entregó según lo acordado” es el documento que describe lo acordado. Si no existe, estás confiando por completo en la buena fe y la buena memoria del otro lado, y ambas se desgastan rápido bajo presión de plazo.

Hay un nombre para lo que pasa cuando el alcance es flojo: scope creep, el crecimiento silencioso del trabajo sin que nadie renegocie el precio. El alcance de proyecto es el antídoto. No porque impida cambios, ya que todo proyecto cambia, sino porque convierte cada cambio en una decisión consciente, con precio y plazo sobre la mesa, en vez de un “ya que estamos” que nadie cobró.

¿Y el costo de escribir uno? Casi nada. Algunas horas tuyas, quizás una conversación estructurada con quien va a construir. Comparado con 23.000 euros de sobrecosto como el de Camila, es el mejor retorno por hora que un fundador consigue en la fase de build.

Qué entra de verdad en un alcance de software

Las guías genéricas te dirán que un alcance tiene “siete elementos” y listarán cosas como justificación, hitos y estructura de desglose del trabajo. Eso es vocabulario de gerente de proyecto certificado, y para una clínica que contrata una app, es peso muerto. El alcance de un software, escrito por un fundador para quien construye, necesita seis cosas, y ninguna es un diagrama bonito.

La primera es el problema. Una o dos frases sobre lo que está roto hoy y qué resultado de negocio esperas. “Hoy la recepción agenda en un cuaderno y pierde el 15% de las citas por falta de confirmación; quiero recortar el no-show a la mitad.” Eso ancla todas las decisiones siguientes.

La segunda son los usuarios. ¿Quién toca el sistema? ¿Recepcionista, paciente, dueño de la clínica? Cada tipo de usuario es un conjunto de pantallas y permisos. Olvidar a uno es la forma más común de descubrir un tercio más de trabajo a mitad de camino.

La tercera es lo que está dentro: la lista de funcionalidades, descritas en verbos concretos. “El paciente agenda, reagenda y cancela una cita.” “El sistema cobra en la tarjeta en el momento del agendamiento.” Huye de verbos vagos como “gestionar”, “optimizar” o “integrar”. Parecen específicos y no lo son; cada uno esconde una semana de trabajo no acordado.

La cuarta es lo que está fuera, y merece su propia sección, porque es la parte que casi todo alcance olvida y casi todo presupuesto echa de menos.

La quinta son los criterios de terminado. ¿Cómo vas a saber que una funcionalidad está entregada? “Agendamiento listo” es discutible. “Un paciente puede agendar desde el móvil, recibe confirmación, y la cita aparece en la agenda de la recepción en tiempo real” es verificable. Sin eso, “listo” se vuelve opinión, y vas a perder la discusión de opinión con la persona que escribió el código.

La sexta son los supuestos y dependencias. ¿Vas a aportar los textos y el logo? ¿La clínica ya tiene una cuenta en la pasarela de pago o eso entra en el proyecto? ¿La app depende de algún sistema que ya existe? Un supuesto no escrito es riesgo transferido a ti sin que lo sepas.

Si quieres ir más a fondo en cada funcionalidad una vez cerrado el alcance, el siguiente documento es el documento de requisitos, que detalla el comportamiento de cada pantalla. El alcance es la frontera; los requisitos son el mapa de lo que vive dentro de ella.

La lista de “fuera del alcance” es tu arma secreta

Si solo logras escribir una sección del alcance, escribe esta. La lista de fuera del alcance, lo que el proyecto explícitamente no incluye, es el ítem más poderoso y más ignorado de todo el documento.

La razón es psicológica. Cuando listas lo que está dentro, creas una expectativa. Pero la cabeza de un fundador trabaja por asociación: pediste agendamiento, así que “obviamente” el sistema tiene un informe de cuántas citas se hicieron, ¿verdad? Para ti es obvio. Para quien presupuestó solo el agendamiento, es trabajo nuevo. La lista de fuera del alcance mata esa ambigüedad antes de que se vuelva factura.

Escribir “fuera del alcance” también cambia la conversación de quien construye. En vez de que el desarrollador diga no a cada pedido, lo que crea fricción y te hace sentir mal pidiendo, el documento ya dijo no por escrito, de forma neutral, al inicio, cuando nadie estaba emocionalmente involucrado. “Informes financieros, integración con el sistema contable y app para iOS están fuera de este alcance y pueden presupuestarse en una fase siguiente.” Ahora, cuando pidas el informe, ambos saben que es una fase nueva con su propio precio, y no una traición al trato.

Los fundadores experimentados tratan la lista de fuera del alcance como el lugar donde guardan las buenas ideas para después. No estás diciendo nunca. Estás diciendo ahora no, y numerando la fila. Eso protege el presupuesto de esta fase sin matar la ambición del producto.

Cómo escribir un alcance de proyecto: un ejemplo real

Vamos a montar uno, corto, con el caso de la clínica. No hace falta software caro ni plantilla de consultoría. Un documento de una a dos páginas resuelve.

Problema: la recepción agenda en cuaderno y por teléfono; el 15% de las citas se vuelven no-show por falta de confirmación. Meta: bajar el no-show a menos del 8% en tres meses.

Usuarios: paciente (agenda y confirma), recepcionista (ve la agenda del día, reagenda), dueño de la clínica (ve la facturación del mes).

Dentro del alcance: paciente agenda, reagenda y cancela desde el móvil; el sistema cobra la señal en la tarjeta al agendar; el sistema envía un recordatorio por WhatsApp 24h antes; la recepción ve la agenda del día en tiempo real; el dueño ve el total facturado en el mes.

Fuera del alcance (fase 2 o nunca): historia clínica electrónica; integración con el sistema contable; app nativa para iOS y Android (la v1 es web en el móvil); informes más allá de la facturación mensual; registro de convenios.

Criterios de terminado: un paciente real puede agendar, pagar la señal y recibir la confirmación por WhatsApp sin ayuda; la cita aparece en la agenda de la recepción en hasta cinco segundos; el recordatorio se dispara solo 24h antes.

Supuestos: la clínica aporta logo, textos y la cuenta de la pasarela de pago; el contenido médico no lo valida el desarrollador; el hosting corre por cuenta de quien construye durante los tres primeros meses.

Eso es un alcance. Cabe en una página, cualquiera lo lee en tres minutos, y ya elimina las tres peleas más caras del proyecto de Camila: el informe que ella creía incluido, la app nativa que dio por supuesta, y quién pagaba la cuenta de WhatsApp. Antes de entregar esto a una software house o a un freelance, vale la pena hacer un levantamiento de requisitos honesto, hablando con quien va a usar el sistema todos los días. Un alcance se sostiene mucho mejor cuando nace de lo que la gente realmente hace, y no de lo que tú imaginas que hace.

Los cuatro errores que estallan el presupuesto

Tras leer decenas de alcances que salieron mal, aparecen los mismos cuatro errores.

El primero es el verbo vago. “El sistema gestiona los pacientes” puede significar un registro simple o un CRM completo con historial, segmentación y automatización. La diferencia entre los dos es un mes de trabajo. Cada vez que un ítem del alcance use gestionar, integrar, optimizar o procesar, detente y describe la acción concreta.

El segundo es la ausencia de la lista de fuera. Ya hablamos de ella, pero vale repetirlo, porque es el error que más cuesta. Un alcance sin frontera de salida no es un alcance. Es una carta de buenas intenciones que el tiempo va a estirar.

El tercero es confundir alcance con plazo. “Lo quiero listo en dos meses” no es alcance, es deseo. El plazo sale del alcance, no al revés. Cuando fijas la fecha antes de definir el trabajo, una de dos cosas cede: o el alcance se encoge sin que lo notes, o la calidad se desploma para caber en la fecha.

El cuarto es tratar el alcance como inmutable. El error opuesto, e igual de caro. Un buen alcance no congela el proyecto; crea un proceso para cambiarlo. La regla es simple: el cambio se permite, siempre que entre como decisión explícita, con impacto de precio y plazo acordado antes de volverse código. El alcance no impide el cambio. Impide el cambio gratis y silencioso.

Alcance, requisitos y contrato no son lo mismo

Tres documentos diferentes que los fundadores suelen amasar en uno, vale la pena separarlos.

El alcance es la frontera: qué entra, qué sale, qué cuenta como terminado. Es corto, estratégico, se lee en minutos.

Los requisitos son el detalle de cada ítem dentro de la frontera: cómo se comporta cada pantalla, qué pasa cuando la tarjeta es rechazada, qué campos son obligatorios. Es largo, técnico en el sentido de detallado, y casi siempre se escribe después del alcance.

El contrato es el documento jurídico que amarra precio, plazo, propiedad del código y qué pasa si algo sale mal. El alcance suele volverse un anexo del contrato, justamente para que “lo acordado” tenga valor formal. Vale la pena leer a quien ya defendió, hace más de veinte años, que escribir la especificación funcional antes de construir es más barato que descubrirla construyendo. El argumento envejeció bien.

El orden importa. Alcance primero, requisitos después, contrato amarrando los dos. Saltarse el alcance e ir directo al contrato es firmar un número sin saber exactamente qué compra. Es como cerrar la reforma de una casa al precio del metro cuadrado sin decir cuántas habitaciones.

Preguntas frecuentes

¿Qué es el alcance de un proyecto?

Es el documento que define los límites del trabajo: qué se va a entregar, qué queda fuera, y qué resultados cuentan como completados. Para un proyecto de software, traduce la intención del fundador en una frontera escrita, antes de que exista código, para que ambas partes sepan exactamente qué está y qué no está en el trato.

¿Cómo hacer un alcance de proyecto, con ejemplo?

Escribe una a dos páginas con seis bloques: el problema y la meta de negocio; los usuarios; lo que está dentro (en verbos concretos); lo que está fuera; los criterios de terminado; y los supuestos y dependencias. En el ejemplo de la clínica de agendamiento, “dentro” incluye agendar, cobrar la señal y enviar recordatorio; “fuera” incluye historia clínica y app nativa; “terminado” significa un paciente real agendando y pagando sin ayuda. Cabe en una página y elimina las peleas más caras antes de que ocurran.

¿Cuál es la diferencia entre alcance del producto y alcance del proyecto?

El alcance del producto describe el “qué”: las funcionalidades y lo que el usuario puede hacer. El alcance del proyecto describe el “cómo” y el “hasta dónde”: el trabajo necesario para entregar ese producto, incluyendo lo que está dentro y fuera del contrato. Los fundadores fallan más en el segundo, porque es fácil listar funcionalidades y difícil escribir lo que el proyecto no incluye.

¿Cuáles son los elementos de un alcance de proyecto de software?

Las guías genéricas citan siete elementos de gestión de proyectos, pero para un software contratado por un fundador, seis bastan: el problema, los usuarios, lo que está dentro, lo que está fuera, los criterios de terminado, y los supuestos y dependencias. La lista de “fuera del alcance” es la más importante y la más olvidada; es la que impide que ideas asociadas se vuelvan trabajo no cobrado.

¿Alcance es lo mismo que requisitos?

No. El alcance es la frontera del proyecto, corto y estratégico. Los requisitos son el detalle de cada ítem dentro de esa frontera, largo y específico, escrito después del alcance. El alcance dice que existe una pantalla de agendamiento; los requisitos describen cómo se comporta cuando el pago falla. Ambos son necesarios, pero sirven a propósitos diferentes y casi nunca caben en el mismo documento.