Evite sobrecostes de más del 50 %: RFP de desarrollo de software lista para contratación
Evite sobrecostes de más del 50 %: RFP de desarrollo de software lista para contratación. Una RFP de desarrollo de software consigue la mejor propuesta de un proveedor cuando indica el resultado empresarial que se busca, un intervalo presupuestario realista y un plan de entrega por fases basado primero en un MVP.
Una RFP de desarrollo de software consigue la mejor propuesta de un proveedor cuando indica el resultado empresarial que se busca, un intervalo presupuestario realista y un plan de entrega por fases basado primero en un MVP. Debe exigir por escrito el enfoque técnico, las credenciales del equipo, los hitos de entrega y los compromisos de seguridad de cada proveedor. Evalúe las respuestas con una matriz ponderada que sitúe la adecuación técnica y la seguridad por delante de la cifra más baja de la página, siguiendo las recomendaciones de expertos sobre criterios de selección de proveedores de software.
Conclusiones clave
Una RFP de desarrollo de software bien estructurada expone claramente los resultados empresariales, el alcance y los requisitos para atraer propuestas detalladas y realistas que se ajusten a los objetivos del proyecto y a los estándares de seguridad.
| Aspecto | Detalles |
|---|---|
| Planteamiento claro del problema | Defina el resultado empresarial y las métricas de éxito medibles para orientar a los proveedores en la entrega de soluciones pertinentes. |
| Alcance y criterios de aceptación explícitos | Especifique lo incluido en el alcance, lo excluido, las hipótesis y los criterios de aceptación, con parámetros de rendimiento concretos. |
| Evaluación técnica y de seguridad | Utilice una matriz ponderada que priorice la adecuación técnica, la seguridad y la experiencia demostrada por encima del precio por sí solo. |
| Plan de entrega por fases | Defina un enfoque por fases que comience con un MVP para comprobar la capacidad del proveedor antes de asumir un compromiso completo. |
| Enfoque Ridiculous Engineering | Aproveche los servicios de Ridiculous Engineering para la redacción experta de RFP, la evaluación de propuestas o el apoyo a la entrega del proyecto. |
Índice
- Qué incluir en una RFP de desarrollo de software
- Una estructura y una plantilla prácticas de RFP que puede enviar hoy mismo
- Cómo evaluar propuestas sin hacer suposiciones
- Inclusión de requisitos de seguridad y de la cadena de suministro
- Calendario, expectativas de costes y errores que deben evitarse
- Consideraciones legales y contractuales
- Cómo puede ayudar Ridiculous Engineering
- Fuentes
- Preguntas frecuentes
Qué incluir en una RFP de desarrollo de software
Un planteamiento claro del problema es la base del documento. Indique el resultado empresarial que pretende lograr y vincúlelo a una métrica de éxito medible, ya sea reducir el tiempo de procesamiento manual, disminuir las solicitudes al soporte o alcanzar una tasa de conversión específica. Los proveedores redactan propuestas más precisas cuando saben cómo se define «terminado» en términos empresariales, no solo en términos de funcionalidades.
A continuación viene el alcance, y la ambigüedad en este punto provoca más disputas presupuestarias que cualquier otro aspecto del documento. Especifique qué está incluido en el alcance, qué queda explícitamente excluido y qué hipótesis está formulando sobre los datos, las integraciones y los sistemas existentes. Asocie cada funcionalidad importante a unos criterios de aceptación para que nadie discuta sobre qué significa «terminado» seis meses después.
Los requisitos funcionales se entienden mejor como historias de usuario breves que como listas densas de funcionalidades. Algunos ejemplos:
- Como responsable de operaciones, puedo consultar los niveles de inventario en tiempo real en todas las ubicaciones de almacén.
- Como cliente, puedo restablecer mi contraseña sin ponerme en contacto con el soporte.
- Como administrador, puedo exportar informes de uso filtrados por intervalo de fechas y departamento.
Los requisitos no funcionales merecen el mismo nivel de especificidad. El lenguaje impreciso, como «el sistema debe ser rápido», no ofrece a los proveedores ninguna base sobre la que preparar una oferta. Estas cifras se convertirán más adelante en sus pruebas de aceptación, así que conviene definirlas correctamente desde ahora.
Por último, la dimensión contractual es tan importante como la técnica. Incluya la titularidad de la propiedad intelectual (usted quiere el código, no una licencia para usarlo), los horarios de soporte, los acuerdos de nivel de servicio, los plazos para corregir defectos y un proceso definido de control de cambios para ajustar el alcance durante el proyecto. Omitir esta sección es la forma en que los «arreglos rápidos» terminan convirtiéndose en disputas de facturación.
Una estructura y una plantilla prácticas para una solicitud de propuestas que puede enviar hoy
Mantenga el documento principal conciso y traslade el material complementario a los anexos. Un proveedor que evalúa diez propuestas leerá atentamente las tres primeras páginas y hojea el resto, así que coloque al principio lo más importante.
- Resumen ejecutivo: un párrafo sobre el problema empresarial y el resultado deseado.
- Objetivos: los objetivos medibles que debe alcanzar el proyecto.
- Alcance: lo incluido, lo excluido y las suposiciones.
- Requisitos: funcionales y no funcionales, como se ha explicado anteriormente.
- Entregables: qué se entrega y cuándo.
- Criterios de aceptación: cómo verificará cada entregable.
- Plantilla de precios: un formato uniforme que todos los proveedores completan de la misma manera.
- Criterios de evaluación: la rúbrica con la que se puntuarán los proveedores.
- Cronograma: plazos de respuesta, periodos de preguntas y respuestas y fecha prevista de inicio.
- Condiciones legales: propiedad intelectual, confidencialidad, responsabilidad y cláusulas de rescisión.
Los diagramas de arquitectura, los datos de muestra anonimizados, las especificaciones de API y las personas usuarias deben incluirse en los anexos, no en el cuerpo principal. Así, la solicitud de propuestas principal sigue siendo fácil de leer y, al mismo tiempo, ofrece a los proveedores serios el nivel de detalle técnico que necesitan para calcular el alcance con precisión.
Un ejemplo de criterio de aceptación: «El panel de informes debe cargar los resultados filtrados en un máximo de 2 segundos para conjuntos de datos de hasta 50.000 registros y exportarlos a CSV sin pérdida de datos». Es lo bastante específico para poder probarlo, pero no tanto como para imponer la implementación.
En cuanto a los precios, pida a todos los proveedores que completen la misma tabla: concepto, descripción, horas estimadas, tarifa por hora o fija y total. Un formato uniforme es la única manera de comparar las ofertas en igualdad de condiciones, en lugar de tener que adivinar qué incluye cada una.
La mayoría de las solicitudes de propuestas bien gestionadas no supera las 15 páginas de contenido principal, más los anexos, y suele ofrecer plazos de respuesta de unas semanas. Los plazos más cortos favorecen a los proveedores que inflan las estimaciones para evitar riesgos, mientras que los más largos rara vez producen respuestas mejores, sino simplemente más tardías.
Cómo evaluar propuestas sin hacer suposiciones
Una matriz de puntuación ponderada convierte la evaluación de propuestas de una decisión intuitiva en una decisión justificable. Observe que el coste aparece cerca del final, no al principio. Es intencionado. Las buenas prácticas de compras desaconsejan seleccionar al proveedor que presenta la oferta más baja para trabajos de software complejos, ya que los precios inferiores a lo razonable suelen manifestarse más adelante en forma de plazos incumplidos o deuda de seguridad.
Organice la rúbrica en torno a filas que obliguen a los proveedores a ser específicos:
- Adecuación de la arquitectura: ¿la pila tecnológica propuesta se ajusta a sus necesidades de escala e integración?
- Experiencia en proyectos similares: ¿han creado algo comparable y pueden demostrarlo?
- Realismo del plan de entrega: ¿los hitos están respaldados por un desglose creíble o se trata simplemente de un diagrama de Gantt con cifras redondeadas?
- Enfoque de control de calidad y pruebas: ¿cuál es su filosofía sobre la cobertura de pruebas, más allá de las herramientas que utilizan?
- Madurez de DevOps y CI/CD: ¿cómo entregan el código y con qué frecuencia?
- Controles de seguridad y preparación para SBOM: ¿pueden generar una y ya disponen de ella?
- Referencias y estabilidad financiera: ¿seguirá este proveedor en activo dentro de 18 meses?
Una vez obtenidas las puntuaciones, organice un breve taller de descubrimiento o una ronda de preguntas y respuestas para aclarar dudas con los dos o tres finalistas principales. Aquí es donde más se aprende. Los proveedores que hacen preguntas precisas sobre su modelo de datos o cuestionan un plazo poco realista suelen ser quienes le dirán la verdad a mitad del proyecto, no solo en el inicio. Los proveedores que aceptan todo sin plantear una sola pregunta aclaratoria merecen una segunda revisión, aunque por las razones equivocadas.
Pida a cada finalista diagramas de arquitectura y un calendario de implementación basado en hitos; después, puntúe el realismo en lugar de la exhaustividad. Una propuesta que admite incertidumbre en un área y explica cómo reducirá el riesgo suele ser mejor que otra que promete la perfección sobre el papel. Nuestro marco de 12 puntos para elegir una empresa de desarrollo de software a medida lo explica con más detalle si desea un segundo punto de referencia.
Integración de los requisitos de seguridad y de la cadena de suministro
La seguridad debe figurar en la RFP como un requisito puntuable, no como una ocurrencia tardía añadida a las condiciones legales. Consulte el Marco de desarrollo de software seguro del NIST, conocido como SSDF o NIST SP 800-218, y pida a los proveedores que certifiquen que sus prácticas están alineadas con las categorías Prepare, Protect, Produce y Respond, en lugar de exigir una cadena de herramientas específica. Los requisitos basados en resultados envejecen mejor que las listas de herramientas, ya que las herramientas cambian cada pocos años y los resultados no.
Exija una lista de materiales de software, una política documentada de divulgación y aplicación de parches de vulnerabilidades, pruebas de los controles de seguridad del flujo de CI/CD y un plazo de corrección establecido para las vulnerabilidades descubiertas después del lanzamiento. Guía de adquisición de software de CISA recomienda exigir responsabilidades a los proveedores por los resultados de seguridad mediante el lenguaje de contratación; incorporar ahora ese lenguaje a su RFP es mucho más barato que negociarlo después de una brecha. La misma guía sugiere documentar las decisiones de aceptación de riesgos con la aprobación formal de un ejecutivo siempre que un proveedor no pueda cumplir plenamente un control, de modo que haya un responsable claro de esa decisión, en lugar de encogerse de hombros seis meses después.
Consejo profesional: Pida a los proveedores un ejemplo de SBOM de un proyecto anterior, en lugar de conformarse con la promesa de que pueden generar uno. Si nunca han generado uno, esa también es información útil.
Puntúe la seguridad en una fila independiente de la rúbrica y solicite pruebas: políticas de ejemplo, una descripción de un incidente anterior y de cómo se gestionó, o una evaluación de seguridad de terceros si existe.
Calendario, expectativas de costes y errores que deben evitarse
Un calendario realista para una RFP pasa por seis fases: preparación, preguntas y respuestas con los proveedores, periodo de presentación de propuestas, evaluación, negociación e inicio. La mayoría de las organizaciones subestima las fases de evaluación y negociación, que juntas suelen tardar tanto como el propio periodo de presentación de propuestas.
Publicar de antemano un intervalo presupuestario ahorra tiempo a todos. Los proveedores que no pueden trabajar dentro de su intervalo se descartan por sí solos antes de redactar una propuesta de 20 páginas, y usted evita la incómoda conversación en la que una oferta que suena excelente acaba costando 3 veces su presupuesto. Uno de cada tres proyectos de TI supera el presupuesto en un 50 % o más, exactamente el tipo de desviación que una definición más clara del alcance y un intervalo publicado pretenden evitar.
Errores comunes que conviene evitar:
- Criterios de aceptación ambiguos que dejan abierto a debate qué significa «terminado».
- Omitir los CV del equipo, de modo que evalúa el folleto de la empresa en lugar de a las personas que realmente escribirán su código.
- Tratar la seguridad como una casilla de verificación en lugar de como un requisito puntuable.
- No incluir hitos de entrega, lo que elimina su único sistema de alerta temprana.
- Especificar en exceso los detalles de implementación y dictar accidentalmente una solución técnica peor.
Defina un MVP inicial o una Fase 1 en torno a un resultado medible. Es la forma más barata de comprobar la capacidad real de entrega de un proveedor antes de firmar nada de mayor duración.
Consideraciones legales y contractuales
La sección de condiciones legales de una RFP establece expectativas que resultan mucho más caras de renegociar después que de definir correctamente desde el principio. La propiedad intelectual debe indicar claramente que usted es propietario del código, los diseños y la documentación producidos en virtud del contrato, no que dispone de una licencia para utilizarlos. Las cláusulas de confidencialidad y tratamiento de datos son más importantes que nunca cuando un proveedor tendrá acceso a datos de clientes o a lógica empresarial propia.
Las condiciones de responsabilidad e indemnización deben reflejar el perfil de riesgo real del proyecto. Un proveedor que desarrolla una herramienta interna de informes asume un riesgo distinto del de uno que gestiona el procesamiento de pagos, y el lenguaje de su contrato debe ajustarse en consecuencia. Las cláusulas de rescisión deben especificar qué sucede con el código, la documentación y las credenciales de acceso si cualquiera de las partes se retira a mitad del proyecto, ya que una cláusula de salida poco clara convierte una mala elección de proveedor en una disputa legal.
Los acuerdos de nivel de servicio deben figurar en el contrato, no solo en la RFP, con tiempos de respuesta específicos para cada nivel de gravedad de los defectos y un proceso definido para los cambios de alcance una vez iniciado el trabajo. La investigación de la GAO sobre adquisiciones ágiles señala que los programas basados en casos de negocio iterativos y una evaluación continua gestionan mejor el riesgo que los contratos fijos y cerrados, algo que conviene reflejar en la forma de estructurar los hitos de pago y el control de cambios. Nuestra guía de contratación pública incluye ejemplos de lenguaje contractual si desea una plantilla inicial en lugar de una página en blanco.
Cómo puede ayudar Ridiculous Engineering
Redactar una RFP sólida es un proyecto. Cumplirla es otro, y es el que realmente importa. Ridiculous Engineering ofrece servicios para ayudar a los equipos a redactar RFP y puntuar propuestas como asesor independiente, o para actuar como socio de entrega, incluidos ingenieros sénior y especialistas en seguridad desde el principio. Tanto si necesita una segunda opinión para evaluar proveedores como si necesita un equipo que construya el producto, empiece por Desarrollo de software a medida o póngase en contacto a través de Consultoría de software y apoyo a la entrega para hablar sobre su situación.
Fuentes
- Marco de desarrollo de software seguro | CSRC
- Guía de adquisición de software: para consumidores empresariales gubernamentales | CISA
- Adquisiciones de software de defensa: cambios necesarios en los requisitos, la supervisión y las herramientas para los programas de armamento | U.S. GAO
Preguntas frecuentes
¿Cuál es la diferencia entre una RFP y una RFQ?
Una RFP, o solicitud de propuesta, pide a los proveedores que propongan un enfoque técnico y una solución para un problema empresarial, mientras que una RFQ, o solicitud de cotización, les pide que calculen el precio de una solución que usted ya ha especificado por completo. Utilice una RFP cuando necesite que los proveedores resuelvan un problema de forma creativa, y una RFQ cuando los requisitos estén completamente definidos y el precio sea el factor decisivo.
¿Cuáles son los 7 pasos de una RFP?
Las definiciones varían, pero una versión habitual incluye: definir los objetivos, redactar los requisitos y el alcance, publicar la RFP, organizar una sesión de preguntas y respuestas con los proveedores, recopilar las propuestas, evaluar y puntuar las respuestas, y después negociar y seleccionar un proveedor. Algunas organizaciones añaden una reunión inicial formal como octavo paso una vez firmado el contrato.
¿Cuánto cuesta una RFP?
No existe una respuesta fija, ya que el coste depende del tiempo interno dedicado a redactarla y evaluarla, no de una tarifa pagada a terceros. Las organizaciones que omiten una definición clara del alcance desde el principio suelen pagar indirectamente mediante sobrecostes de los proveedores, por lo que resulta tan importante publicar un rango presupuestario y adoptar un enfoque de MVP por fases.
¿Cuáles son los errores habituales que deben evitarse en una RFP?
Los errores más frecuentes son unos criterios de aceptación imprecisos, no comprobar las credenciales del equipo del proveedor, tratar la seguridad como una cuestión secundaria en lugar de como una categoría puntuable y omitir por completo los hitos de entrega. Especificar en exceso los detalles de implementación es otra trampa habitual, ya que puede obligar a los proveedores a adoptar una solución técnica peor que la que propondrían de otro modo.