Cómo leer una propuesta de desarrollo

Una propuesta completa tiene las mismas secciones básicas, la escriba quien la escriba. Use esta tabla como mapa mientras la lee.

Un buen alcance describe lo que puede hacer un usuario, no solo los nombres de las pantallas. «Los usuarios se registran con correo o con Google y pueden restablecer su contraseña» se puede comprobar. «Módulo de autenticación», no.

Busque que los roles de usuario, los flujos principales y las herramientas de administración aparezcan por separado. Los paneles de administración se olvidan con facilidad en un brief y son caros de añadir después.

Por ejemplo, ProAnalizy convierte resultados de análisis clínicos en explicaciones fáciles de entender. Su flujo principal se puede escribir como resultado: un visitante sube un PDF, JPG o PNG de un análisis y recibe una explicación, sin registrarse. Una línea así le dice a ambas partes qué significa exactamente «terminado».

Una propuesta clara enumera lo que no está incluido. Las exclusiones típicas son la redacción de textos, las traducciones, la publicación en tiendas de aplicaciones, las suscripciones a servicios externos y el alojamiento tras el lanzamiento.

Si no hay sección de exclusiones, pídala. Todo lo que usted daba por incluido y no lo estaba volverá más tarde como una solicitud de cambio, cuando tenga menos margen para negociar.

Las traducciones son un buen ejemplo de trabajo que se esconde en una línea imprecisa. CarPixly se lanzó en inglés, alemán y ruso, y eso implicó textos de la interfaz, mensajes de error, pasos de instalación y preguntas frecuentes, además de botones preparados para las etiquetas alemanas, más largas. Una propuesta que solo dice «multilingüe» deja todo eso abierto a interpretación.

No necesita ser ingeniero, pero después de leer la propuesta debería poder responder estas preguntas:

• ¿Con qué se construirá y por qué esa tecnología encaja con su producto en concreto?
• ¿De quién son el código y las cuentas: repositorio, alojamiento, dominio, tiendas de aplicaciones, analítica?
• ¿Dónde estará alojado y cuánto costará aproximadamente cada mes tras el lanzamiento?
• ¿Estará el código lo bastante documentado para que otro desarrollador pueda hacerse cargo?
• ¿Cómo gestiona el equipo los riesgos de seguridad habituales, como los del OWASP Top 10?

Una buena agencia explica sus decisiones en lenguaje claro. «Es lo que usamos siempre» no es un motivo.

En cuanto a la propiedad, pida que el repositorio esté en la cuenta de su organización desde el primer día. Moverlo después es posible, como muestra la guía de GitHub para transferir un repositorio, pero depende de la buena voluntad de la otra parte.

Una sola fecha de entrega dice muy poco. Busque hitos con algo que pueda ver en cada uno: diseños aprobados, una versión funcional en un enlace de prueba, una versión lista para el lanzamiento.

Pregunte con qué frecuencia verá el avance. Las reuniones semanales son un mínimo razonable; una única demostración al final es un riesgo. En Sakura, los clientes reciben cada semana una versión que pueden recorrer, así los problemas aparecen cuando todavía son baratos de corregir.

Compruebe que el plazo incluya también su parte. Las revisiones, las rondas de comentarios y los contenidos que usted debe aportar llevan tiempo, y un plan que los ignora se retrasará.

¿Está comparando propuestas ahora mismo? Envíenos su brief y recibirá una escrita con este estándar, para ponerla junto a las demás.

Compruebe si la propuesta menciona pruebas, rendimiento y accesibilidad, o solo funciones. Busque datos concretos:

• ¿Qué navegadores y dispositivos son compatibles?
• ¿Qué rendimiento debería alcanzar el producto? Las Core Web Vitals de Google son una referencia habitual: el contenido carga en 2,5 segundos y las interacciones responden en 200 milisegundos.
• ¿Quién prueba el producto antes del lanzamiento y cómo se informan y corrigen los errores?
• ¿Se incluye una accesibilidad básica, como el uso con teclado y un contraste legible?

Si «terminado» no está definido, las últimas semanas del proyecto se convierten en una discusión. Una definición por escrito las convierte en una lista de comprobación.

Confirme exactamente qué cubre el precio y cómo se reparten los pagos. Un anticipo y pagos vinculados a hitos es lo habitual; el 100% por adelantado, no.

Busque el proceso de cambios. Debería explicar cómo se estiman y aprueban las nuevas peticiones antes de que alguien empiece a trabajar en ellas. Sin él, cada cambio se convierte en una negociación.

Revise también las condiciones de salida. Una propuesta justa le permite detenerse entre hitos sin pagar el trabajo que no ha empezado. Para profundizar en los dos modelos de precio principales, lea precio cerrado o por horas.

Muchas propuestas terminan el día del lanzamiento. Pregunte qué viene después: ¿hay un periodo de soporte para errores, cuánto dura y cómo se cobra el trabajo continuo?

Un lanzamiento sin un plan de correcciones y actualizaciones es justo donde muchos productos se estancan sin hacer ruido. Cada proyecto de Sakura incluye un periodo de garantía definido; después, un plan de soporte mensual cubre actualizaciones, correcciones y nuevas funciones.

Algunos problemas se ven en la propia página, antes de cualquier llamada. Lea la propuesta una vez buscando solo esto:

• Un total sin desglose. No sabe qué está pagando ni qué recortar si el presupuesto no alcanza.
• Palabras que no se pueden comprobar. «Moderno», «escalable» y «fácil de usar» no describen nada que pueda probar en la entrega.
• Un plazo con una sola fecha. Si no hay nada que ver por el camino, no tendrá ningún aviso cuando las cosas se retrasen.
• Ninguna mención de quién es dueño de qué. El silencio sobre el código y las cuentas suele significar que se quedan con la agencia.
• Todo incluido, nada excluido. Ningún proyecto real es tan simple, así que las exclusiones simplemente no están escritas.

Una señal de alerta es una pregunta que hacer. Tres o más suelen indicar que la agencia no ha entendido el proyecto lo suficiente como para presupuestarlo.

Una propuesta es un borrador, no una oferta definitiva. Las buenas agencias esperan preguntas y actualizan el documento, y la forma en que responden forma parte de su evaluación.

• Pida un desglose por fases o por flujos. Muestra adónde va el dinero y le da opciones si el total es demasiado alto.
• Pregunte qué recortarían primero. Una respuesta pensada demuestra que entienden qué partes de su producto importan más.
• Pida dividir el proyecto. Una primera fase con diseño y prototipo reduce el riesgo de comprometerse de golpe con todo el desarrollo.
• Pida reescribir las líneas imprecisas como resultados. «Los usuarios pueden exportar un informe en PDF» en lugar de «módulo de informes».

Si una agencia se niega a aclarar algo por escrito antes de firmar, después será todavía más difícil conseguir claridad.

Ponga las propuestas en una tabla sencilla, una columna para cada una, y rellene las mismas filas: alcance, exclusiones, plazo, hitos, calendario de pagos, proceso de cambios, propiedad y soporte tras el lanzamiento.

Las celdas vacías son el resultado más útil de este ejercicio. Muestran dónde guarda silencio una propuesta, y cada silencio es una pregunta que hacer antes de comparar precios.

Solo entonces compare los totales. Si una propuesta es mucho más barata, busque lo que deja fuera.

Si una es mucho más cara, pregunte qué incluye que las demás no tengan. A veces la diferencia es un periodo de soporte o una fase de diseño que de verdad necesita.

Llévelas a su última llamada con la agencia. Si las respuestas son claras y concretas, está listo para firmar.

• ¿Qué queda exactamente fuera de este precio?
• ¿Quién trabajará en el proyecto día a día?
• ¿Qué pasa si necesitamos cambiar el alcance?
• ¿De quién son al final el código y todas las cuentas?
• ¿Qué soporte se incluye después del lanzamiento?

Si todavía está eligiendo entre agencias, nuestra guía sobre cómo elegir una agencia de desarrollo explica qué revisar antes incluso de pedir propuestas. Y cuando quiera una propuesta que cumpla este estándar, cuéntenos sobre su proyecto.