Cómo definir el alcance de un proyecto de software antes de contratar a un desarrollador

La razón número uno por la que los proyectos de software superan el presupuesto:el alcance no se definió antes de que comenzara el desarrollo.No son malos desarrolladores. No es tecnología equivocada. Alcance poco claro. Un estudio del PMI de 2024 encontró que el 52% de los proyectos experimentan un aumento del alcance y, en promedio, esos proyectos superan el presupuesto en un 27%.

Si es un fundador y está a punto de contratar a un desarrollador o agencia de software, la actividad con mayor retorno de la inversión que puede realizar es redactar un alcance claro del proyecto de software antes de hablar con alguien sobre los plazos o los precios. Este documento se convierte en el contrato entre lo que espera y lo que se construye.

Este es el marco que utilizamos en Savi cuando realizamos sesiones de determinación del alcance de proyectos con clientes. Puedes hacerlo tú mismo en 2-4 horas.

Qué debe incluir un documento de alcance

El alcance de un buen proyecto de software cubre cinco áreas. Si te pierdes cualquiera de ellos, obtendrás citas que no coinciden con la realidad.

1. Roles de usuario.¿Quién utiliza el sistema? Una aplicación orientada al cliente con una función cuesta mucho menos que una plataforma con cinco funciones (cliente, proveedor, administrador, agente de soporte, superadministrador). Cada rol necesita sus propias vistas, permisos y reglas de acceso a datos. Enumere todos los roles, incluso los que crea que son obvios. "Administrador" no es obvio; puede significar 10 niveles de permiso diferentes.

2. Características por rol.Para cada rol de usuario, enumere las acciones específicas que pueden realizar. "El administrador puede administrar usuarios" es demasiado vago. "El administrador puede ver todos los usuarios, desactivar cuentas, restablecer contraseñas y exportar datos de usuario como CSV" es lo suficientemente específico como para estimarlo.

3. Integraciones.Todos los sistemas externos que toca su producto: pasarelas de pago, proveedores de correo electrónico, API de SMS, herramientas de análisis, sistemas CRM, software de contabilidad. Cada integración agrega entre $1000 y $4000 a un proyecto dependiendo de la calidad y complejidad de la API.

4. Bosquejo del modelo de datos.No necesita un esquema de base de datos. Necesita una descripción en lenguaje sencillo de sus objetos de datos principales y cómo se relacionan. "Un cliente tiene muchos pedidos. Un pedido tiene muchas líneas de pedido. Cada línea de pedido hace referencia a un producto. Un producto pertenece a una categoría". Esto lleva 20 minutos y evita 20 horas de malentendidos a mitad del proyecto.

5. Criterios de éxito.¿Cómo sabes que el proyecto está terminado? No "se siente completo". Resultados mensurables. "Un cliente puede crear una cuenta, buscar productos, agregar artículos al carrito, pagar con Stripe y recibir un correo electrónico de confirmación del pedido dentro de los 3 segundos posteriores al pago". Eso es comprobable. Ese es un límite de alcance.

Lo que NO debe incluir un documento de alcance

Los fundadores suelen especificar demasiado en las áreas equivocadas. Un documento de alcance no es una especificación técnica. Deja estos fuera:

Decisiones técnicas sobre el stack.No especifique "usar PostgreSQL con almacenamiento en caché de Redis e implementar en AWS". Ese es el trabajo del desarrollador. Tú defines lo que hace el sistema; ellos deciden cómo lo hace. Si dicta opciones tecnológicas sin contexto de ingeniería, limitará sus opciones o pagará por una pila que no se ajuste al problema.

Esquemas de bases de datos.El boceto de su modelo de datos describe las relaciones en un lenguaje sencillo. El desarrollador lo traduce en tablas, columnas e índices. Escribir un esquema antes de contratar a un ingeniero es como dibujar planos antes de contratar a un arquitecto.

Maquetas de interfaz de usuario con píxeles perfectos.Las estructuras alámbricas y los diseños aproximados son útiles. Archivos Figma con píxeles perfectos antes de determinar el alcance es prematuro. Rediseñarás el 40% de tus pantallas una vez que veas el flujo de usuarios en acción. Invierta en un diseño detallado después de determinar el alcance, no antes.

Cómo definir roles y flujos de usuarios

Utilice esta plantilla para cada característica de su documento de requisitos de software:

Ejemplos:

• como uncliente, puedo filtrar productos por categoría y rango de precios para encontrar lo que necesito en menos de 10 segundos.
• como unadministración, Puedo exportar todos los pedidos de los últimos 30 días como CSV para poder conciliarlos con mi software de contabilidad.
• como unproveedora, puedo establecer los precios de mis propios productos y el recuento de inventario para controlar mi tienda sin tener que contactar al soporte.

Este formato obliga a la especificidad. "Como administrador, puedo administrar productos" no le dice nada al desarrollador. "Como administrador, puedo crear, editar, archivar y eliminar productos con imágenes, descripciones, precios y recuentos de inventario", les dice exactamente qué crear.

Escribe entre 10 y 30 de estas afirmaciones. Esa es tu lista de características. Eso es lo que envía a los desarrolladores cuando solicitan cotizaciones.

Cómo priorizar funciones: el método MoSCoW

No construirás todo a la vez. No deberías. El método MoSCoW divide su lista de funciones en cuatro grupos:

Imprescindible:El producto no funciona sin estos. Si está creando una tienda de comercio electrónico, el pago es imprescindible. La autenticación de usuario es imprescindible. La lista de productos es imprescindible.

Debería tener:Importante pero el producto puede lanzarse sin ellos. Seguimiento de pedidos, notificaciones por correo electrónico, alertas de inventario. Mejoran la experiencia, pero los clientes aún pueden comprar cosas sin ellos.

Podría haber:Es bueno tenerlo si el tiempo y el presupuesto lo permiten. Listas de deseos, reseñas de productos, programas de referencia. Estas características aumentan la participación pero no afectan la funcionalidad principal.

No lo haré (esta ronda):Funciones que ha decidido posponer para una fase posterior. Aplicación móvil, soporte en varios idiomas, modelo de mercado. Escribirlos es importante; evita el desplazamiento del alcance al hacer que el límite sea explícito.

Un MVP bien definido contiene sólo los elementos imprescindibles y 1 o 2 elementos imprescindibles de alto impacto. Todo lo demás pasa a la fase 2. Este enfoque mantiene su primera construcción por debajo del presupuesto y lo lleva al mercado más rápido, para que pueda recopilar comentarios reales de los usuarios antes de construir más.

Cómo manejar las integraciones

Las integraciones son la parte que más comúnmente tiene un alcance insuficiente en la planificación de proyectos de software. Cada sistema externo al que se conecta su producto agrega complejidad, costo y posibles puntos de falla.

Para cada integración, documente tres detalles específicos:

• Que sistema:Raya, SendGrid, Twilio, Google Analytics, QuickBooks, etc.
• Qué datos fluyen dónde:"La información de pago del cliente va a Stripe. Stripe envía un webhook confirmando el pago. Nuestro sistema actualiza el estado del pedido y activa un correo electrónico de confirmación a través de SendGrid".
• Qué sucede cuando falla:"Si Stripe no funciona, muéstrele al cliente un mensaje de error y guarde su carrito. Vuelva a intentar el pago en 5 minutos".

La mayoría de los fundadores enumeran los dos primeros y omiten el tercero. El manejo de errores representa entre el 20 y el 30% del trabajo de integración. Si no lo define en el alcance, el desarrollador lo omite (mal) o adivina lo que quiere (también mal).

Establecer criterios de éxito

"El proyecto está terminado cuando funciona" no es un criterio de éxito. Es una receta para revisiones interminables. Defina resultados mensurables antes de que comience el desarrollo:

• Un nuevo usuario puede registrarse y completar su primera compra en menos de 3 minutos.
• El panel de administración carga todos los pedidos de los últimos 90 días en menos de 2 segundos.
• El sistema maneja 500 usuarios simultáneos sin tiempos de respuesta superiores a 1 segundo.
• Todas las transacciones de pago se registran con marcas de tiempo y se pueden exportar para su auditoría.
• La aplicación obtiene una puntuación superior a 90 en Google Lighthouse en cuanto a rendimiento y accesibilidad.

Estos criterios les brindan tanto a usted como a su desarrollador una línea de meta clara. Cuando se aprueba cada elemento de esta lista, el proyecto estará terminado. No hay debates subjetivos sobre si un botón "se siente bien". Resultados medibles, no sentimientos.

Errores comunes de alcance

Después de realizar cientos de sesiones de determinación del alcance del proyecto, estos son los patrones que conducen constantemente a excesos presupuestarios:

Escribir una novela en lugar de una lista de verificación.Un documento de requisitos de 40 páginas no aclara un proyecto. Hace que sea más difícil de estimar. Los desarrolladores hojean documentos extensos. Leen listas de verificación. Mantenga su documento de alcance en menos de 5 páginas con viñetas, historias de usuarios y una lista de funciones priorizadas.

Especificación de la interfaz de usuario antes de los flujos."Quiero un panel con una barra lateral y tres gráficos" describe una pantalla, no una función. Comience con los flujos de usuarios: ¿qué debe lograr el administrador? Luego, decida qué interfaz de usuario admite esos flujos. Las pantallas surgen de los flujos y no al revés.

Olvidar las necesidades administrativas y de backend.Los fundadores se obsesionan con la experiencia de cara al cliente y olvidan que alguien necesita gestionarla. Gestión de contenidos, moderación de usuarios, cumplimiento de pedidos, paneles de análisis, herramientas de soporte. El panel de administración suele ocupar entre el 30 y el 40 % del tiempo total de desarrollo. Si su documento de alcance solo describe la experiencia del cliente, su cotización será entre un 30% y un 40% demasiado baja.

No definir estados de error.¿Qué sucede cuando falla un pago? ¿Cuando un usuario ingresa un correo electrónico no válido? ¿Cuando la carga del archivo supera los 10 MB? ¿Cuándo la API devuelve un error 500? Cada estado de error necesita un comportamiento definido. Dejarlos sin definir no ahorra tiempo; crea errores que cuestan más corregir después del lanzamiento.

Una plantilla de alcance simple

Utilice esta lista de verificación como punto de partida al escribir los requisitos de software para su próximo proyecto:

¿Qué sucede después del alcance?

Una vez que su documento de alcance esté completo, estará listo para recibir cotizaciones. Envíe el mismo documento a 2-4 agencias o desarrolladores. Un alcance claro le permite comparar propuestas de manzanas con manzanas. Si una agencia cotiza $8 000 y otra cotiza $25 000 para el mismo alcance, puede hacer preguntas específicas sobre el motivo.

Aquí está la secuencia típica:

1. Envía tu documento de alcancea agencias preseleccionadas o autónomos. Incluya su cronograma y rango de presupuesto si tiene uno. La transparencia acelera el proceso.

2. Revisar propuestas.Compare en tres dimensiones: precio, cronograma y quién hace el trabajo. Una cotización de $10 000 de un ingeniero senior que realiza el envío en 4 semanas supera una cotización de $7 000 de un equipo junior que realiza el envío en 12 semanas. Lea más sobre la evaluación de agencias en nuestra guía sobrecómo contratar una agencia de desarrollo.

3. Aclarar los supuestos.Cada propuesta contiene suposiciones. "Asume Stripe para pagos". "Se suponen hasta 3 rondas de revisión para el diseño". "Se supone que el cliente proporciona fotografías del producto". Saquelos a la superficie antes de firmar. Las suposiciones no expresadas se convierten en disputas más adelante.

4. Iniciar el desarrollo.Con un alcance claro y una propuesta acordada, el desarrollo comienza sobre una base sólida. Se seguirán produciendo cambios, pero serán pequeños ajustes, no cambios de dirección fundamentales que arruinen el presupuesto.

¿Quiere comprender cómo el alcance del proyecto afecta los precios? Lea nuestro desglose decostos de desarrollo de software personalizado. Si está listo para redactar un documento completo de requisitos del producto, consulte nuestroguía de plantillas del PRD.

Preguntas frecuentes