Plantilla de alcance de proyecto: el brief que nos gustaría recibir

La mayoría de los briefs que recibimos ocupan dos líneas, o cuarenta páginas.

El brief de dos líneas esconde las decisiones. El de cuarenta las entierra bajo pantallas y listas de funcionalidades. En ambos casos, usted recibe tres presupuestos imposibles de comparar, de un mes a seis, y elige por precio o por intuición. Seis meses después, la app funciona y nadie en el terreno la abre.

Este es el documento que nos gustaría recibir antes de una primera llamada. Diez apartados, una línea de ejemplo en cada uno, dos páginas en total. Se escribe en una tarde, para una app o para un proyecto de IA.

Los diez apartados: qué construimos, qué no construimos, criterios de éxito, usuarios, datos, integraciones, restricciones, plazo, horquilla de presupuesto, responsable tras el lanzamiento.

Por qué el brief decide el precio

Cada presupuesto que recibe es una apuesta sobre lo que usted quiso decir. Cuando el brief es vago, cada estudio rellena los huecos a su manera, y acaba comparando tres proyectos distintos con tres precios distintos.

Los huecos vuelven más tarde. Una funcionalidad que nadie mencionó aparece en la cuarta semana, la planificación se mueve y la conversación pasa a ser quién la paga.

Cuando un proyecto se retrasa, la causa rara vez es el código. Es una decisión que nadie dejó por escrito.

Un buen alcance no necesita ser largo. Necesita responder a las preguntas que quien construye hará de todos modos, antes de la primera línea de código.

Las líneas de ejemplo siguen un proyecto imaginario: una empresa con 40 técnicos de campo que quiere una app móvil para registrar sus intervenciones, con IA que redacta el informe a partir de una nota de voz.

Qué construye, qué no, y cómo lo mide

1. Qué construimos. Un párrafo, en palabras sencillas. Describa qué cambia para alguien un martes por la mañana, no las pantallas.

Los técnicos graban una nota de voz después de cada intervención. La app la convierte en un informe estructurado y lo envía al cliente el mismo día.

2. Qué no construimos. Es la línea que la mayoría de los briefs se salta, y la que más dinero ahorra. Anote las funcionalidades que se han comentado y que se dejan de lado por ahora.

Ni facturación, ni planificación de agenda, ni mapas sin conexión en la primera versión. La herramienta de planificación se queda como está.

3. Criterios de éxito. Cómo sabrá, tres meses después del lanzamiento, que ha funcionado. Una o dos cifras, con el valor actual al lado.

Los informes llegan a los clientes en menos de 24 horas, frente a 5 días hoy. Los técnicos dedican menos de 5 minutos a cada informe.

Para una funcionalidad de IA, añada el error que puede asumir y quién lo detecta.

Un informe erróneo cuesta una llamada, no un pleito. La responsable de oficina revisa todos los informes el primer mes y después 1 de cada 10.

Si no puede escribir un criterio de éxito, el proyecto no está listo para construirse. Quizá esté listo para una auditoría.

Quién lo usa, y con qué

4. Usuarios. Quién abre el producto, con qué frecuencia, en qué dispositivo y cuánta paciencia tiene. Nombre los roles y, aproximadamente, cuántas personas hay en cada uno.

40 técnicos con móviles Android, a menudo con guantes. 3 responsables de oficina en ordenador que revisan y corrigen los informes.

5. Datos. Qué existe hoy, dónde está, de quién es y en qué estado se encuentra. En un proyecto de IA, este apartado decide la mayor parte de la viabilidad.

3 años de informes en PDF en una unidad compartida, escritos a mano y pasados a limpio después. Lista de clientes en el CRM. Ninguna grabación hasta ahora.

Adjunte 20 ejemplos reales al brief: 20 informes antiguos, 20 correos, 20 incidencias. Diez minutos de datos reales le dicen más a quien construye que diez páginas de descripción.

Indique adónde pueden ir los datos. Alojarlos en Europa, en su propia nube o en sus propios servidores cambia la arquitectura, así que va en el brief, no en la revisión del contrato.

6. Integraciones. Cada herramienta de la que el producto lee o en la que escribe. Añada quién gestiona cada una y si tiene una API que usted haya visto funcionar de verdad.

Leer los clientes del CRM. Escribir en él los informes terminados. Enviar los correos con el proveedor actual. La administradora del CRM es nuestra responsable de oficina.

Los límites: restricciones, plazo, presupuesto

7. Restricciones. Las reglas que no puede cambiar: normativa, política de seguridad, la tecnología que su equipo ya mantiene, accesibilidad, idiomas.

Los datos de clientes se quedan en la UE. El equipo de sistemas mantiene la app tras el lanzamiento, así que usa la tecnología que ya conoce.

8. Plazo. Una fecha, y el motivo de esa fecha. Una feria, una renovación de contrato o una temporada le dicen a quien construye qué se puede recortar y qué no.

Primera versión usada por 5 técnicos antes de marzo, cuando empieza la temporada alta. Despliegue completo en junio.

Nuestras primeras versiones suelen estar en producción entre 3 y 6 semanas después del arranque. Funciona porque la lista de «lo que no construimos» es larga. Un brief que lo mete todo en la primera versión rara vez sale tan rápido.

9. Horquilla de presupuesto. Dé una horquilla. Sin ella, recibe propuestas a la medida de la comodidad del estudio, no de su problema.

Una cifra mínima y una máxima para la primera versión. Costes de funcionamiento presupuestados aparte, por mes.

Si no tiene idea de qué horquilla es realista, es una pregunta legítima para la llamada de auditoría. Una horquilla no debilita su negociación. Permite que quienes construyen le digan qué cabe dentro y qué no.

10. Responsable tras el lanzamiento. La persona que decide qué pasa con el producto una vez en marcha. También quién lo arregla cuando falla un sábado y quién paga cada mes las llamadas al modelo.

El director de operaciones es el responsable del producto. El equipo de sistemas asume el mantenimiento tras tres meses de soporte del estudio.

Tres cosas que conviene dejar fuera:

• Maquetas de pantallas. Deciden el diseño antes de que el problema esté claro.
• La tecnología, salvo que su equipo tenga que mantenerla (véase el apartado 7).
• Una lista de deseos de IA. «La IA debe responder a todas las preguntas de los clientes» es un deseo. «Redacta respuestas a las 5 preguntas más frecuentes y una persona las envía» es un alcance.

La plantilla, lista para copiar

Cópiela en un documento y envíela a quien lleve el proyecto. Los huecos que deje son el orden del día de su primera reunión.

ALCANCE DEL PROYECTO: [nombre del proyecto]
Fecha: [fecha]  ·  Redactado por: [nombre, cargo]

1. Qué construimos
   [Qué cambia, para quién, en un párrafo]

2. Qué no construimos
   [Funcionalidades comentadas y dejadas de lado por ahora]

3. Criterios de éxito
   [1 o 2 cifras, valor actual y objetivo; para IA: tasa de error aceptable y quién revisa]

4. Usuarios
   [Roles, número de personas, dispositivo, contexto de uso]

5. Datos
   [Qué existe, dónde está, de quién es, en qué estado, dónde puede alojarse]

6. Integraciones
   [Herramientas de las que leer o en las que escribir, responsable de cada una, API comprobada: sí / no]

7. Restricciones
   [Normativa, seguridad, tecnología existente, idiomas, accesibilidad]

8. Plazo
   [Fecha objetivo y su motivo]

9. Horquilla de presupuesto
   [Mínimo y máximo, primera versión y costes de funcionamiento por separado]

10. Responsable tras el lanzamiento
   [Una persona con nombre, más quién mantiene y quién paga los costes de funcionamiento]

Deje un apartado vacío si no lo sabe. Un hueco honesto es más útil que una suposición, y le muestra a quien construye dónde están las primeras preguntas.

Si prefiere no redactarlo solo

La auditoría gratuita termina con un documento que responde a los dos primeros apartados de esta plantilla, los difíciles: qué merece la pena construir y qué no. Es una hora sobre su negocio y después un informe breve. Si seguimos adelante, el primer paso es un alcance por escrito: qué construimos, qué no y cuándo sale.

Envíe su borrador, aunque esté a medio rellenar, desde la página de contacto. La hora de auditoría se dedica entonces a decidir, no a descubrir. Si aún no tiene borrador, rellenamos juntos los primeros apartados, y los huecos nos dicen por dónde empezar.