Brief de software: cómo obtener presupuestos comparables

Un brief sirve para que las respuestas sean comparables

Un brief de proyecto tiene una sola función: que varios socios entiendan su problema lo bastante bien como para proponer una forma de resolverlo, con una estimación en la que pueda confiar. Si cada socio rellena los huecos con sus propias suposiciones, las propuestas difieren en alcance y no en calidad, y la más barata suele ser la que menos incluyó.

Por eso el brief debe ser preciso sobre el problema y modesto sobre la solución. Describa lo que tiene que ser cierto cuando el proyecto termine y deje que los socios expliquen cómo llegarían hasta ahí. Sus respuestas a esa parte abierta son lo más útil que leerá.

Empiece por el problema de negocio y por cómo medirá el éxito

Abra con el motivo por el que existe el proyecto: qué no funciona hoy, a quién afecta y cuánto le cuesta dejarlo como está. Decir que su equipo de operaciones vuelve a teclear en el ERP cada pedido que llega por correo le dice a un socio mucho más que pedir un portal de gestión de pedidos.

Después, diga cómo juzgará el éxito. Elija unos pocos resultados observables, como el tiempo ahorrado por pedido, los errores que dejan de llegar a los clientes o una fecha en la que se pueda apagar un sistema antiguo. Estos criterios se convierten después en los criterios de aceptación de los hitos, así que escríbalos de forma que alguien pueda comprobarlos.

Describa usuarios, sistemas y datos antes que funcionalidades

El trabajo de integración y de datos es fácil de subestimar cuando un socio no puede verlo. Antes de enumerar funcionalidades, describa quién usará el software, con qué sistemas debe funcionar y qué datos maneja. Las lagunas en esta parte vuelven más tarde en forma de solicitudes de cambio.

• Usuarios: quiénes son, cuántos aproximadamente, y dónde y con qué dispositivos trabajan.
• Sistemas existentes: cuáles son, de quién son y si ofrecen una API documentada o solo una base de datos y exportaciones de archivos.
• Datos: cuáles son personales, confidenciales o regulados, dónde están hoy y qué volumen hay que migrar.
• Operación: quién gestionará el software tras el lanzamiento y qué normas de alojamiento o de nube tiene ya su empresa.
• Restricciones: idiomas, necesidades de accesibilidad, estándares de seguridad y cualquier plazo que no pueda moverse, con su motivo.

Comparta una horquilla de presupuesto y el plazo que de verdad importa

Muchos compradores se guardan el presupuesto para ver qué proponen los socios. El resultado son propuestas para proyectos distintos: un socio diseña para lo mínimo, otro para todo lo que usted mencionó. Una horquilla, aunque sea amplia, permite a cada socio proponer el mejor proyecto que cabe en ella y decirle claramente si no cabe.

Haga lo mismo con los plazos. Diga qué fecha es fija y por qué, como un contrato que vence o un plazo regulatorio, y qué fechas son solo preferencias. Un socio solo puede planificar en torno a una fecha inamovible si sabe cuál es.

Marque lo que es fijo y deje abierto el resto

Etiquete cada requisito como fijo, preferente o abierto. Fijo significa que una propuesta no es válida sin él, como el alojamiento en la UE o el inicio de sesión a través de su proveedor de identidad actual. Preferente significa que tiene un motivo, pero consideraría una alternativa. Abierto significa que quiere la recomendación del socio.

Deje abierta la tecnología salvo que tenga un motivo real para fijarla, como un equipo interno que mantendrá el código o una plataforma que su empresa ha adoptado como estándar. Cuando fije una elección, explique por qué, para que los socios no dediquen su propuesta a rebatirla.

Por último, pida a todos los socios que respondan con la misma estructura: su comprensión del problema, el enfoque, las fases y los hitos, las hipótesis, los riesgos, el equipo y el modelo comercial. Una estructura común es lo que, en la práctica, hace comparables las propuestas.

Errores que hacen imposible comparar las propuestas

Muchas propuestas inservibles responden a un brief que las provocó. Elimine estos patrones antes de enviar el suyo.

• Una lista de funcionalidades sin definición del problema, de modo que cada socio adivina sus prioridades.
• Una especificación larga que fija la solución antes de que nadie haya examinado el problema.
• Ninguna mención de los sistemas existentes ni de la migración de datos, que después vuelven como solicitudes de cambio.
• Detalles adicionales dados a algunos socios por teléfono, de modo que sus propuestas responden a preguntas distintas.
• Palabras como «sencillo», «estándar» o «como una app conocida», que significan algo distinto para cada lector.
• Ningún plazo para las preguntas, o respuestas compartidas solo con el socio que preguntó.

Invite a hacer preguntas y léalas como parte de la evaluación

Dé a los socios un plazo fijo para hacer preguntas, responda por escrito y envíe cada respuesta a todos. Las preguntas ya dicen algo por sí mismas: un socio que pregunta por sus datos, sus usuarios y sus criterios de aceptación ya está pensando en la entrega.

Si el problema todavía es demasiado incierto para describirlo bien, dígalo y pida una fase de descubrimiento breve y de pago en lugar de una propuesta completa. Un presupuesto cerrado construido sobre conjeturas esconde las incógnitas en su margen de riesgo; una fase de descubrimiento sustituye las conjeturas por hechos. Si quiere que unos ingenieros lean su brief, o que respondan a él, puede enviarlo a través de nuestro formulario «Empezar un proyecto».

Preguntas frecuentes