Antes de buscar proveedores, define qué necesitas resolver
Una comparación útil no comienza con una lista de tecnologías. Describe el problema, quién lo vive, qué resultado espera la empresa y qué restricciones existen. Esta información permite distinguir entre proveedores que entienden la operación y aquellos que solo responden con una lista de funciones.
Define también quién tomará decisiones dentro de tu empresa. El mejor proveedor no puede compensar indefinidamente la ausencia de usuarios disponibles, prioridades claras o una persona responsable del producto.
Siete aspectos que debes evaluar
1. Capacidad de entender el negocio
Observa la calidad de sus preguntas. Debe investigar procesos, usuarios, excepciones y resultados antes de recomendar una arquitectura.
2. Proceso de trabajo visible
Pregunta cómo convierte una necesidad en alcance, cómo demuestra avances y cómo gestiona cambios. Debes poder revisar entregables durante el proyecto, no solo al final.
3. Experiencia relevante
No busques únicamente un proyecto idéntico. Evalúa si ha resuelto complejidades parecidas: integraciones, permisos, datos sensibles, operación multisucursal o productos con crecimiento.
4. Calidad y pruebas
Solicita que explique revisión de código, ambientes, pruebas, respaldos, monitoreo y despliegues. Las respuestas deberían ser concretas y proporcionales al riesgo.
5. Seguridad desde el diseño
La seguridad debe formar parte de requisitos, arquitectura y pruebas. La guía Secure by Demand de CISA propone que los compradores pregunten explícitamente por las prácticas de seguridad del fabricante. Para aplicaciones web, OWASP ASVS ofrece una base para verificar controles y requisitos de desarrollo seguro.
6. Propiedad y continuidad
Aclara quién será propietario del código, diseños, datos y documentación; dónde se alojarán los repositorios; y cómo podrá continuar otro equipo si la relación termina.
7. Soporte posterior
Define garantía, tiempos de atención, monitoreo, actualizaciones y mecanismo para nuevas solicitudes. Publicar no es el final del ciclo de vida.
Preguntas para una reunión de evaluación
- ¿Qué necesitan conocer antes de estimar?
- ¿Cómo validaremos alcance y experiencia de usuario?
- ¿Con qué frecuencia veremos software funcionando?
- ¿Cómo gestionan cambios, riesgos y decisiones?
- ¿Qué pruebas y controles de seguridad incluyen?
- ¿Quién tendrá acceso al repositorio y la infraestructura?
- ¿Qué documentación recibiremos?
- ¿Cómo funciona la garantía y el mantenimiento?
Señales de alerta
- Promete fecha y precio cerrado sin investigar el problema.
- No explica supuestos ni exclusiones.
- Evita mostrar avances hasta el final.
- La seguridad se ofrece como paquete opcional.
- El código y la infraestructura solo pueden permanecer en cuentas del proveedor.
- No existe proceso para respaldos, incidentes o entrega de documentación.
Cómo comparar propuestas diferentes
Crea una matriz con alcance, entregables, supuestos, equipo, calendario, seguridad, propiedad, soporte y costo total. Asigna mayor peso a lo que representa riesgo para tu negocio. Una propuesta más cara puede ser mejor si incluye migración, pruebas y continuidad que otra omite.
Solicita una conversación de aclaración y registra por escrito los acuerdos. No conviertas la selección en una competencia de documentos comerciales: evalúa cómo sería trabajar con ese equipo cuando aparezca un problema difícil.
Puntos básicos del acuerdo
El contrato debe reflejar alcance, pagos vinculados a entregables, confidencialidad, propiedad intelectual, tratamiento de datos, control de cambios, aceptación, garantías y condiciones de salida. Para asuntos legales específicos consulta a un profesional competente en tu jurisdicción.
Preguntas frecuentes
¿Debo elegir al proveedor más económico?
No necesariamente. Compara el resultado completo, riesgos cubiertos, costos posteriores y capacidad de continuidad.
¿Es indispensable que use una tecnología específica?
Solo si existe una restricción real. Es más importante que justifique la arquitectura según el contexto y que tu organización pueda mantenerla.
¿Quién debe ser dueño del código?
Debe quedar explícito en el contrato. En desarrollos financiados por el cliente suele negociarse la propiedad o una licencia suficiente para garantizar continuidad.
¿Necesitas llevarlo a tu operación?
Podemos ayudarte a convertir este enfoque en un alcance y una ruta concreta.
Conocer Definición y planeación de proyectos →
