Qué reviso en una propuesta de software antes de que la firmes

Qué es una segunda opinión técnica

Una segunda opinión técnica es la lectura independiente de una propuesta, un presupuesto o un plan de software que ha preparado otro proveedor, hecha antes de aceptarlo. Quien la hace no ha redactado la oferta ni tiene que defenderla. Comprueba si el trabajo descrito se puede construir tal como se plantea y si el documento deja por escrito lo que vas a recibir, cómo se comprobará y qué ocurrirá después de la entrega.

Tiene más sentido cuando vas a firmar sin nadie técnico al lado: una startup que encarga su primera versión o una pyme que compara dos ofertas para sustituir una herramienta. También puede servir a una empresa con equipo técnico cuando el proyecto entra en un terreno que nadie conoce bien por dentro. Con ella decides, o pides cambios, sabiendo qué deja abierto el documento.

Lo que entra, lo que no y lo que se da por supuesto

Empiezo por la lista de funcionalidades. Busco frases que cada parte puede leer a su manera: «gestión de usuarios», «integración con el ERP», «panel de administración». ¿Cuántos tipos de usuario hay y qué puede hacer cada uno? ¿La integración lee datos, los escribe o ambas cosas, y cada cuánto? Si el documento no lo aclara, el precio puede corresponder a una versión bastante más corta que la que tienes en la cabeza.

Las exclusiones las leo con la misma atención. Algunas están escritas y otras solo aparecen por omisión: migrar los datos del sistema anterior, cargar contenidos, adaptar la aplicación al móvil, traducirla o preparar un entorno de pruebas. Anoto también qué tiene que aportar tu empresa y en qué fecha, porque un acceso que llega tarde o unos datos de ejemplo que no aparecen mueven todo el calendario. Y miro cómo se tratarán los cambios a mitad de proyecto: quién los valora, con qué precio y cuántas rondas de revisión incluye el presupuesto.

Cómo se acepta cada entrega

Una propuesta debería decir cuándo se considera terminada cada parte. Compruebo si hay criterios de aceptación que se puedan verificar sin interpretarlos, en qué entorno revisarás la entrega, cuánto tiempo tienes para hacerlo y qué pasa con los errores que aparezcan después de aceptarla. Una garantía que no define qué es un error ni en cuánto tiempo se corrige deja a las dos partes discutiendo.

Si los pagos van ligados a hitos, reviso que cada hito corresponda a algo que puedas comprobar tú, como un recorrido completo que ya funciona. Un porcentaje de avance que solo puede medir el proveedor es difícil de discutir. En cómo acotar un MVP en fases con entrega comprobable explico cómo escribo esos criterios cuando la propuesta es mía.

Código, cuentas y dependencias

Aquí están las preguntas que más cuesta resolver cuando ya hay un desacuerdo. ¿A nombre de quién quedan el repositorio del código, el dominio, el servidor o la cuenta del proveedor de nube y, si es una aplicación móvil, las cuentas de las tiendas? ¿Recibirás las credenciales de administración o solo un usuario con permisos limitados? Si un día cambias de proveedor, deberías poder llevarte la aplicación y sus datos sin depender del proveedor anterior.

La propiedad del código merece una cláusula propia. Quién tiene los derechos sobre el código y con qué alcance es una cuestión jurídica que conviene revisar con tu asesor; esta nota no es asesoramiento legal. Mi parte es comprobar que la propuesta lo deja por escrito y que coincide con lo que esperas.

También identifico de qué depende la aplicación. Puede apoyarse en una plataforma o en módulos propios del proveedor que no se entregan con el código, en servicios externos con cuota mensual o en bibliotecas de terceros, y cada dependencia trae sus condiciones. El código abierto también tiene licencia: la lista de licencias aprobadas por la Open Source Initiative permite comprobar si la licencia que declara un componente está aprobada por esa organización, aunque sus condiciones hay que leerlas igualmente. Si la propuesta integra datos de una fuente externa, en qué reviso antes de integrar una fuente de datos explico qué permisos compruebo.

Mantenimiento y lo que pasa después de la entrega

Hay presupuestos que terminan el día de la entrega. La aplicación seguirá necesitando servidor, actualizaciones de seguridad y alguien que atienda un fallo. Reviso qué incluye el mantenimiento, si lo hay, qué costes recurrentes pagarás tú directamente y cuáles factura el proveedor, y por qué vía se piden las correcciones.

Miro también qué documentación se entrega. Si no explica cómo instalar, configurar y desplegar la aplicación, cualquier cambio futuro dependerá de la misma persona.

Preguntas que conviene llevar al proveedor

De la revisión sale una lista de preguntas pensada para tu caso. Algunas se repiten en muchas propuestas:

• ¿Qué funcionalidades incluye cada fase y cuáles quedan para más adelante?
• ¿Cómo se acepta una entrega y qué ocurre con los errores que aparezcan después?
• ¿A nombre de quién estarán el código, el repositorio y las cuentas de infraestructura?
• ¿Qué componentes o servicios de terceros necesita la aplicación y cuánto cuestan al mes?
• ¿Qué tengo que aportar yo y en qué fechas?
• ¿Cómo se presupuesta un cambio que surja a mitad del proyecto?
• ¿Qué documentación recibiré para que otra persona pueda continuar el trabajo?

Una respuesta vaga no convierte por sí sola la propuesta en mala. A veces el proveedor lo tiene resuelto y simplemente no lo escribió. Lo que conviene es que la respuesta acabe en el documento que firmas.

Cómo comparar dos o tres proveedores de software

Comparar el precio final de varias ofertas sirve de poco si cada una describe un trabajo distinto. Antes de mirar importes, pongo las propuestas en las mismas filas: qué funcionalidades incluye cada una, qué deja fuera, cómo se acepta cada entrega, a nombre de quién quedan el código y las cuentas, qué dependencias de terceros trae y qué cuesta mantener la aplicación el primer año.

Cuando una oferta no responde a una de esas filas, lo anoto como pregunta para ese proveedor, no como un punto en contra. A veces la diferencia de precio se explica sola: una incluye la migración de datos o las pruebas y otra no. Si todas las propuestas parten de un documento de requisitos tuyo, conviene revisarlo primero, porque las ambigüedades de ese documento se trasladan a todas las respuestas.

Si cambias de proveedor a mitad del proyecto

Cuando un proyecto pasa de un proveedor a otro, lo que más se pierde es lo que nadie dejó escrito. Antes de que el anterior se desvincule, conviene reunir el acceso al repositorio con todo su historial, las credenciales de administración de los servidores, del dominio y de los servicios externos, la documentación para instalar y publicar la aplicación, una copia de los datos y la lista de lo que quedó a medias o con errores conocidos.

Con eso reviso si la aplicación se puede instalar desde cero en un entorno nuevo y qué partes dependen de algo que no se ha entregado. Esa comprobación es la que necesita el proveedor siguiente para presupuestar con fundamento, y te dice qué reclamar mientras todavía puedes hacerlo.

Qué entrego y qué queda fuera

Trabajo en remoto con la propuesta, el presupuesto y los anexos que me facilites. Si existe un sistema anterior o un prototipo, puedo mirarlo cuando me des acceso. Entrego un informe escrito que separa los puntos bien resueltos de los ambiguos y de los que faltan, señala los riesgos técnicos que veo y recoge las preguntas para el proveedor; si te resulta útil, lo comentamos por videoconferencia. Cuando comparas dos ofertas, las reviso con los mismos criterios para que puedas ponerlas una al lado de la otra.

Quedan fuera la revisión jurídica del contrato, una auditoría de seguridad o de cumplimiento normativo y la negociación con el proveedor en tu nombre. Tampoco manejo una referencia de precios de mercado para decirte si el importe es caro, aunque sí puedo señalar partidas que no se corresponden con el trabajo descrito. Si me falta información para opinar sobre algo, el informe lo dice.

Una primera fase puede limitarse a eso: leer la propuesta y sus anexos, preparar el informe con las preguntas y comentarlo contigo antes de que respondas al proveedor. Te sirve igual si firmas con él, si pides cambios o si buscas otra oferta. Cómo planteo el resto de revisiones y decisiones de arquitectura lo explico en la página de consultoría y arquitectura tecnológica.