Cómo evaluar una propuesta de desarrollo de software

Checklist rápido antes de firmar

• Alcance incluido y excluido.
• Supuestos y responsabilidades de cada parte.
• Hitos o cadencia de entregas.
• Entregables.
• Criterios de aceptación.
• Precio y costos recurrentes.
• Gestión de cambios.
• Corrección de bugs y soporte.
• Derechos sobre el software, licencias y acceso al código.
• Dependencias de terceros.
• Condiciones de terminación/salida del proveedor.

Qué debe incluir una propuesta de desarrollo de software

Antes de comparar precios, comparar si las propuestas siquiera contienen lo mismo. Estos son los elementos que una propuesta profesional debería tener por escrito, no dichos de palabra:

Alcance explícito (scope of work). Tiene que decir exactamente qué está incluido — funcionalidades, integraciones, documentación — y qué no. Una propuesta que describe el proyecto en términos generales (“una plataforma que ayude a tu equipo a gestionar X”) deja demasiado espacio para que cada parte entienda algo distinto, y esas discrepancias suelen aparecer recién a mitad de proyecto.

Cronograma dividido en fases. Discovery, diseño, desarrollo, testing, lanzamiento — cada fase con una fecha estimada. No hace falta que sea milimétrico, pero sin ninguna referencia temporal no tenés forma de saber si el proyecto va bien o se está atrasando hasta que ya es tarde.

Entregables claros por etapa. Qué te entregan en cada hito: mockups, código fuente, documentación, ambiente de pruebas. Si los entregables no están definidos, cualquier “eso no estaba incluido” se vuelve una discusión de interpretación en vez de un hecho verificable en el contrato.

Criterios de aceptación. Un entregable no debería definirse solo por su nombre. Conviene establecer qué condiciones debe cumplir para considerarse terminado, quién lo valida y qué ocurre si no cumple lo acordado. Esto reduce discusiones posteriores sobre si algo es un bug, una tarea pendiente o un pedido nuevo.

Supuestos documentados. Toda propuesta se arma sobre ciertas asunciones: que vas a tener disponible cierta información, que ciertas decisiones de negocio ya están tomadas, que contás con determinados accesos o datos. Una propuesta seria las escribe explícitamente, así ninguna de las dos partes se sorprende cuando algún supuesto resulta falso.

Propiedad intelectual, licencias y acceso al código. Tiene que quedar claro qué derechos recibe cada parte al finalizar el proyecto: qué desarrollos se ceden al cliente, qué componentes conserva o licencia el proveedor, qué elementos pertenecen a terceros y qué acceso tendrá el cliente al código fuente, archivos de diseño y documentación. No asumas que pagar una factura resuelve automáticamente todas estas cuestiones: leé qué establece el contrato.

En Paraguay, el artículo 14 de la Ley N° 1328/98 establece que, en las obras creadas en ejecución de un contrato por encargo, la titularidad de los derechos transferibles se rige por lo pactado entre las partes. La misma ley contiene además disposiciones específicas para los programas de ordenador (Ley N° 1328/98, DINAPI — Instructivo de Derecho de Autor para la Industria del Software). Por eso conviene que el contrato deje expresamente definido el alcance de cualquier cesión o licencia, en lugar de depender de interpretaciones posteriores — esto es información general, no asesoramiento jurídico para tu caso puntual.

También conviene identificar librerías, frameworks, componentes open source, APIs y otros elementos de terceros. El proveedor no puede transferirte como propios derechos que pertenecen a terceros; esos componentes siguen sujetos a sus respectivas licencias y condiciones, que pueden condicionar la explotación del software resultante (DINAPI — Instructivo de Derecho de Autor para la Industria del Software).

Costos incluidos y costos recurrentes. Además del desarrollo, la propuesta debería indicar qué costos quedan fuera o continúan después del lanzamiento: hosting/cloud, dominios, APIs de terceros, mensajería, licencias, almacenamiento, backups, monitoreo, soporte, mantenimiento, migración de datos o capacitación, cuando apliquen. Dos propuestas con el mismo precio inicial pueden tener costos operativos posteriores muy distintos.

Señales de alerta

Ninguna de estas señales descalifica automáticamente a un proveedor, pero si aparecen sin explicación, vale la pena preguntar antes de firmar:

• Precio cerrado sin relevamiento previo. Un precio cerrado puede ser razonable si el alcance ya está suficientemente definido. Si el proveedor cotiza sin haberse reunido con vos ni contar con requerimientos detallados, preguntá sobre qué alcance, supuestos y exclusiones construyó esa cifra.
• Alcance ambiguo o “todo incluido”. Propuestas que prometen mucho sin detallar generan fricción más adelante: cuando algo no se entrega, cada parte cree que la otra prometió distinto.
• Sin cronograma ni hitos. Como guía general (no una regla fija — hay proyectos chicos donde una gestión más informal funciona bien), la ausencia total de fechas o entregables intermedios suele dificultar medir el avance real hasta el final del proyecto.
• Precio muy por debajo del resto. Cuando varias cotizaciones caen en un rango similar y una es notablemente más baja, conviene indagar antes de firmar — puede haber una razón legítima (menor overhead, mayor eficiencia), pero también puede ser que la propuesta haya entendido un alcance distinto o excluido partidas que las otras cotizaciones sí contemplan, y que esas diferencias aparezcan después como cambios de alcance. No asumas ninguna de las dos sin preguntar.

Preguntas para hacerle al proveedor — incluidas las incómodas

Estas son preguntas que cualquier proveedor serio, Flexora incluida, tiene que poder responder con claridad. Si evaluás una propuesta de Flexora, hacenos exactamente las mismas preguntas que le harías a cualquier otro.

1. ¿Qué derechos recibo sobre el software cuando termina el proyecto? ¿Hay cesión de derechos patrimoniales, licencia de uso o una combinación? ¿Qué pasa con el código desarrollado específicamente para mí, los archivos de diseño, la documentación, los componentes preexistentes del proveedor y las dependencias de terceros? ¿Voy a tener acceso al repositorio y poder contratar a otro equipo para mantener el sistema si alguna vez lo necesito?
2. ¿Cómo se maneja un cambio de alcance una vez firmado el contrato? ¿Requiere aprobación por escrito? ¿Cómo se cotiza? No dejes estos cambios solamente en una conversación: documentalos mediante el mecanismo de aprobación previsto en el contrato.
3. ¿Qué pasa después de la entrega final? ¿Existe un período de corrección de defectos? ¿Qué considera el contrato un bug y qué considera un cambio o funcionalidad nueva? ¿Qué soporte o mantenimiento posterior está incluido y qué se contrata aparte?
4. ¿Qué equipo va a trabajar en mi proyecto? ¿Quién será responsable, qué perfiles y nivel de experiencia tendrá el equipo, y qué capacidad aproximada estará asignada?
5. ¿Qué pasa si el proyecto se atrasa? ¿Hay penalidades, hay comunicación proactiva, o te enterás cuando preguntás vos?
6. ¿Puedo hablar con un cliente anterior con un proyecto de tamaño y complejidad similar al mío? Si existen restricciones de confidencialidad, preguntá si pueden mostrar un caso anonimizado comparable, métricas verificables o alguna otra evidencia de experiencia relevante — la imposibilidad de compartir un contacto puntual no es automáticamente una señal negativa.

Si un proveedor —cualquiera— se pone incómodo o evasivo ante estas preguntas, es información tan valiosa como la propuesta misma.

Precio fijo vs. tiempo y materiales

Hay dos modelos de contratación principales, y entender la diferencia te ayuda a leer mejor cualquier propuesta:

Precio fijo (Fixed Price). Se acuerda un monto total, un alcance definido y un cronograma antes de empezar. Como orientación general, tiende a funcionar mejor cuando los requerimientos ya están bien definidos y estables — no es una regla estricta sobre duración de proyecto. La desventaja es que ofrece menos flexibilidad: un cambio que aumente o altere materialmente el alcance puede requerir renegociar precio, plazo o entregables. También puede acordarse una repriorización manteniendo las restricciones originales si ambas partes consideran equivalentes los cambios.

Tiempo y materiales (T&M). Pagás por el tiempo o la capacidad efectivamente utilizada, según las tarifas y condiciones acordadas. Puede facturarse por horas, días, capacidad de equipo u otra unidad definida en el contrato; cualquier gasto adicional debería quedar previsto. Da mucha más flexibilidad y es más apropiado cuando los requerimientos todavía están evolucionando o no están del todo claros. El riesgo, del lado del cliente, es que sin hitos de revisión periódica el presupuesto puede quedar abierto.

Modelo híbrido. Una opción híbrida es empezar con T&M para la etapa de discovery y especificación —cuando el alcance todavía se está definiendo— y pasar a precio fijo una vez que ese alcance queda claro. Puede reducir ciertos riesgos para ambas partes, aunque la conveniencia del modelo y la proporción de tiempo que conviene dedicar a cada etapa dependen del proyecto.

Ninguno de los dos modelos es “mejor” en abstracto — lo que importa es que el modelo elegido coincida con qué tan definidos están tus requerimientos hoy.

Los riesgos de elegir solo por precio

El precio más bajo no siempre sale más barato al final. Algunos riesgos que conviene revisar:

• Recorte o renegociación de alcance. Cuando una propuesta queda demasiado ajustada frente al trabajo real, puede ser necesario reducir, repriorizar o renegociar entregables. Por eso conviene comparar cuidadosamente qué incluye y excluye cada cotización.
• Costos adicionales vía pedidos de cambio. Cuando el alcance inicial no está suficientemente definido, algunas aclaraciones o necesidades que aparecen durante el proyecto pueden terminar tratándose como cambios adicionales y elevar el costo final.
• Posible impacto en calidad y mantenibilidad. Un precio muy ajustado puede significar menos tiempo dedicado a testing, documentación o buenas prácticas de seguridad, lo cual podría traducirse después en mayores costos de mantenimiento.

Estos riesgos no aparecen solo porque el precio sea bajo — pero si aparecen varias de estas señales juntas, vale la pena revisar con más detalle el alcance, los supuestos y las condiciones antes de decidir.

Cómo estructurar el pago

La estructura de pago debería acompañar el modelo de contratación. En un proyecto a precio fijo o por hitos, puede tener sentido vincular los pagos a entregables o etapas verificables. En T&M, es más habitual una facturación periódica acompañada de visibilidad sobre tiempo o capacidad consumida, avance, presupuesto utilizado y revisiones regulares. En un modelo híbrido pueden combinarse ambos mecanismos.

Los cambios que alteren precio, plazo, capacidad contratada o compromisos acordados deberían seguir el mecanismo de aprobación definido en el contrato y quedar documentados antes de ejecutarse.

Antes de firmar

Si ya decidiste que el desarrollo a medida es el camino correcto para tu empresa —tema que cubrimos en cuándo una empresa necesita software a medida (y cuándo no)— y ya tenés una idea de qué determina el precio en el mercado paraguayo, algo que desarrollamos en cuánto cuesta desarrollar software a medida en Paraguay, el paso que queda es leer la propuesta concreta que tenés en la mano con esta lista en el bolsillo.

Ninguna propuesta va a tener un puntaje perfecto en todos estos puntos, y eso no la descalifica automáticamente. Lo que sí importa es que el proveedor pueda explicar con claridad las partes que faltan, y que esté dispuesto a completarlas por escrito antes de que empieces a pagar. Si querés ver cómo estructuramos nosotros nuestras propuestas de software a medida, la misma lista de preguntas de esta guía aplica.