Casi toda primera conversación sobre un proyecto de software empieza con la misma pregunta: ¿cuánto costará? Es una pregunta justa, y es la que menos responsablemente puedo responder en una sola frase. Después de 25 años creando software para muchos tipos de empresas, he aprendido que una cifra dada antes de entender el problema no es una estimación. Es una conjetura que alguien pagará más adelante.
Este artículo no le da un precio, porque cualquier cifra que publicara aquí sería incorrecta para su proyecto. Lo que sí le da es la lista de factores que realmente mueven el costo, para que pueda juzgar un presupuesto cuando lo reciba y tomar las decisiones que reducen el costo sin perjudicar el resultado.
Por qué dos cotizaciones de “lo mismo” pueden diferir tanto
Si pide a tres empresas una cotización para “un portal de clientes”, puede recibir fácilmente tres cifras muy distintas. Rara vez es porque una cobre de más. Normalmente es porque cada una imaginó un portal diferente. Una supuso un inicio de sesión sencillo con una lista de facturas. Otra supuso acceso por roles, carga de documentos, notificaciones por correo, un área de administración y una pasarela de pago. La tercera supuso todo eso más una aplicación móvil.
El software es singular porque una misma frase describe productos cuyo esfuerzo difiere en un orden de magnitud. Por eso, la primera tarea de toda estimación honesta es convertir una frase en un alcance: una descripción escrita de lo que existirá cuando el trabajo termine. Desconfíe de cualquier precio que llegue sin uno.
Los principales factores de costo
1. Alcance: cuántas cosas hace
Cada función es un trabajo en sí: diseñarla, construirla, probarla y luego mantenerla funcionando mientras todo a su alrededor cambia. Además, las funciones interactúan entre sí. Agregar un quinto rol de usuario no cuesta una quinta parte más que el cuarto; afecta a todas las pantallas que verifican permisos. Cuando haga la lista de lo que desea, separe lo que necesita desde el primer día de lo que sería bueno tener más adelante. Esa sola distinción es la palanca de costos más eficaz que tiene.
2. Incertidumbre: qué tan bien se entiende el problema
Un problema bien entendido, como un formulario que guarda registros y envía un correo, puede estimarse con precisión. Un problema en el que nadie está seguro de cómo debería funcionar el proceso o cómo son los datos, no. La incertidumbre no hace imposible el trabajo, pero sí hace riesgoso un precio fijo para ambas partes. O bien el proveedor infla el precio para cubrir las incógnitas, o bien el proyecto deriva en disputas sobre lo que estaba incluido. Dedicar un poco de tiempo al principio a reducir la incertidumbre, mediante una fase breve de descubrimiento, un prototipo o una muestra de datos reales, suele ahorrar más de lo que cuesta.
3. Integraciones: con cuántos otros sistemas se conecta
Conectarse a pasarelas de pago, programas de contabilidad, CRM, servicios de mensajería o un portal gubernamental es donde las estimaciones fallan con más frecuencia. Cada sistema externo tiene sus propias reglas, sus propias particularidades y, a veces, su propio proceso de aprobación que nada tiene que ver con el código. Una API moderna bien documentada es sencilla. Un sistema antiguo sin documentación, o que solo exporta archivos, no lo es. Si su proyecto incluye integraciones, pida que se identifiquen de forma explícita en la estimación, junto con las aprobaciones que deba obtener.
4. Usuarios, datos y rendimiento
El software para diez usuarios internos y el software para diez mil clientes son problemas de ingeniería distintos. Más usuarios, más datos y más actividad simultánea exigen más atención al diseño de la base de datos, al almacenamiento en caché, al hosting y al monitoreo. La mayoría de las aplicaciones empresariales no necesitan una arquitectura exótica, pero conviene decirle al desarrollador con franqueza el volumen que espera, incluido dónde espera estar en dos o tres años, para que la base no quede demasiado pequeña.
5. Plataformas y dispositivos
Una aplicación web que funciona en navegadores de computadora y teléfono es una cosa. Las aplicaciones nativas de Android y iOS, el funcionamiento sin conexión, las notificaciones push y la publicación en las tiendas son otras. Herramientas multiplataforma como Flutter y React Native pueden compartir la mayor parte del código entre Android e iOS, por lo que a menudo son la opción sensata para aplicaciones de negocio, pero no hacen que el trabajo sea gratuito. Decida qué plataformas importan realmente a sus usuarios.
6. Expectativas de calidad, seguridad y cumplimiento
Las pruebas, la revisión de código, las copias de seguridad, el registro de eventos, el control de acceso y el refuerzo de la seguridad no son extras opcionales, aunque su profundidad varía. Un sistema que maneja pagos o datos personales requiere más cuidado que un sitio de presentación. Si tiene requisitos contractuales o regulatorios, dígaselo al desarrollador desde el principio; agregarlos tarde es mucho más costoso que diseñar con ellos en mente. Desconfíe de quien afirme tener certificaciones o garantías que no puede demostrar.
7. Migración de datos y sistemas existentes
Si está reemplazando un sistema existente, los datos antiguos deben trasladarse. Limpiar, mapear y validar esos datos suele subestimarse. Las hojas de cálculo llenas de entradas de texto libre, clientes duplicados y fechas inconsistentes requieren un esfuerzo real para convertirse en una base de datos limpia. Pregunte desde el principio cuántos de los datos antiguos realmente necesita.
8. Después del lanzamiento
El software no está terminado cuando se pone en funcionamiento. Los servidores necesitan parches, las bibliotecas necesitan actualizarse, los errores aparecen con el uso real y el negocio sigue cambiando. Presupueste el hosting, el mantenimiento y un flujo de pequeñas mejoras. Como regla general, considere la primera versión como el comienzo de una relación con el software y no como una compra que termina.
Cómo es un presupuesto honesto
Sea cual sea la cifra final, un presupuesto confiable tiene rasgos reconocibles. Describe el alcance en lenguaje claro, para que usted compruebe que coincide con lo que imaginó. Enumera los supuestos, como “el entorno de pruebas del proveedor de pagos estará disponible” o “usted proporcionará los datos de los productos en una hoja de cálculo”. Divide el trabajo en hitos para que usted vea el avance y, si es necesario, se detenga. Indica qué no está incluido. Y explica cómo se manejarán los cambios, porque los habrá.
Si la estimación es de precio fijo, debe indicar qué ocurre cuando cambian los requisitos. Si es de tiempo y materiales, debe dar un rango y describir cómo se le mantendrá informado del gasto. Nuestra guía sobre cómo elegir entre precio fijo y tiempo y materiales aborda esa decisión con más profundidad.
Cómo reducir el costo sin recortar el valor
- Empiece con menos de lo que cree necesitar. Una primera versión enfocada, usada por personas reales, le enseña más que una especificación larga. Puede añadir la segunda y la tercera tanda de funciones sabiendo qué importa.
- Aporte ejemplos reales desde el principio. Documentos de muestra, hojas de cálculo, capturas de pantalla del proceso actual y una lista de las excepciones incómodas eliminan la incertidumbre más rápido que las reuniones.
- Diga de qué no está seguro. Un desarrollador puede diseñar alrededor de una incógnita si se le informa. Las sorpresas son lo que cuesta dinero.
- Considere si realmente necesita software. A veces una herramienta estándar configurada, un pequeño script de automatización o un cambio en el proceso resuelven el problema a menor costo. Un buen desarrollador se lo dirá, aunque eso implique un proyecto más pequeño.
La respuesta honesta
El costo del software a la medida depende de lo que se desarrolle, de qué tan bien se comprenda, de cuántos otros sistemas toque y de cuánto tiempo piense mantenerlo en funcionamiento. Quien le dé una cifra firme antes de entender estos aspectos está adivinando o vendiendo algo estándar.
En IT Labs India ofrecemos una primera consulta gratuita y un presupuesto por escrito, sin tarifas publicadas, precisamente porque la cifra correcta solo existe una vez que hemos entendido su problema. Si desea iniciar esa conversación, puede conocer más sobre nuestro servicio de desarrollo de software a la medida o ponerse en contacto.