Decidir qué navegadores, dispositivos y versiones admite una aplicación parece una tarea técnica, pero sus consecuencias afectan al producto, al negocio y a la operación. Una lista demasiado amplia puede consumir capacidad de desarrollo y pruebas; una demasiado restrictiva puede dejar fuera a usuarios importantes o incumplir compromisos con clientes.
La respuesta no consiste en perseguir cada lanzamiento ni en elegir una versión por costumbre. Consiste en documentar qué entornos tienen soporte, con qué nivel de garantía y bajo qué condiciones se revisará la decisión. Esta matriz convierte una discusión recurrente en un criterio compartido.
La compatibilidad es una decisión de producto y operación
Un entorno compatible no es simplemente uno en el que la aplicación se abre. También importa si sus funciones principales operan correctamente, si la experiencia es aceptable y si el equipo puede detectar y resolver problemas. Por eso, la decisión debe reflejar el uso real y la capacidad de mantenimiento, no solo una preferencia técnica.
Empieza por identificar qué consecuencias tendría un fallo. En una herramienta interna quizá sea razonable ofrecer una alternativa temporal; en un flujo de compra o en una aplicación crítica para el trabajo, el impacto puede ser mayor. También pueden existir compromisos contractuales, políticas de seguridad o requisitos de accesibilidad que condicionen qué entornos deben contemplarse.
Acuerda quién propone, quién valida y quién aprueba la matriz. Producto puede priorizar necesidades y segmentos; tecnología, evaluar viabilidad y riesgos; soporte y negocio, aportar incidentes y compromisos con usuarios. Sin un responsable de decisión, las excepciones tienden a crecer sin que nadie asuma su coste.
Reúne evidencia antes de elegir versiones
La primera fuente es el contexto de uso. Averigua qué navegadores y dispositivos utilizan los usuarios para tareas relevantes, no solo cuáles aparecen con mayor frecuencia en el tráfico general. Distingue, por ejemplo, entre iniciar sesión, completar una operación crítica y consultar contenido. Un entorno poco frecuente puede ser imprescindible para un cliente o un proceso específico.
Contrasta varias señales:
- Analítica de uso: identifica navegadores, sistemas operativos, tamaños de pantalla y patrones de uso disponibles. Interpreta los datos con cautela: pueden excluir usuarios que no consienten medición o que no completan la carga.
- Soporte y ventas: revisa incidencias repetidas, necesidades declaradas por clientes y acuerdos existentes. Separa una petición aislada de un requisito respaldado por evidencia.
- Requisitos técnicos: registra dependencias del producto, funciones del navegador necesarias, políticas de seguridad y restricciones de dispositivos administrados.
- Capacidad del equipo: estima el esfuerzo de desarrollo, pruebas, diagnóstico y mantenimiento. Un entorno adicional implica más que añadirlo a una lista.
Si faltan datos, anótalo como incertidumbre. Puedes validar la necesidad mediante entrevistas, registros de soporte o una prueba acotada. No conviertas la ausencia de evidencia en una afirmación de que nadie usa ese entorno.
Define criterios y niveles de soporte
Fija criterios que se puedan aplicar de forma consistente. Entre ellos pueden estar la proporción y relevancia de uso, la criticidad de las tareas, la compatibilidad con las tecnologías necesarias, el riesgo de seguridad, los requisitos de clientes y el coste de mantener pruebas. No hace falta reducirlos a una puntuación única: una obligación contractual, por ejemplo, puede prevalecer sobre el volumen de uso.
Es útil distinguir tres niveles:
- Soporte garantizado: el entorno forma parte del compromiso publicado. Las funciones principales se prueban y los defectos reproducibles se gestionan según el proceso normal del producto.
- Validado: el equipo ha comprobado un conjunto definido de flujos, pero no promete cobertura completa ni priorización equivalente ante cualquier problema. Especifica qué se validó y qué límites se conocen.
- No soportado: el equipo no prueba ni garantiza el funcionamiento. Si la aplicación permite el acceso, indícalo sin sugerir que la experiencia está cubierta.
Evita expresiones ambiguas como “compatible con todos los navegadores modernos”. Indica nombres y versiones, o un criterio verificable para determinar las versiones admitidas. Si el soporte se basa en versiones recientes, define cómo se calcula ese periodo y dónde se publica. La precisión evita que usuarios y equipos interpreten de forma distinta una promesa.
Equilibra el coste de mantener entornos antiguos
Soportar versiones antiguas puede exigir soluciones alternativas, más combinaciones de prueba y atención a defectos que no aparecen en entornos actuales. Pero retirarlas también tiene coste: usuarios afectados, operaciones interrumpidas, pérdida de acceso y trabajo de comunicación o migración. La decisión debe comparar ambos lados, no tratar la reducción de mantenimiento como un beneficio automático.
Señales para reconsiderar un entorno incluyen un uso persistentemente bajo, ausencia de requisitos conocidos, fallos de seguridad relevantes, limitaciones que bloquean cambios necesarios o una carga de pruebas desproporcionada. Ninguna señal basta por sí sola. Comprueba si los datos representan a la población afectada y si existe una alternativa viable, como actualizar el dispositivo, usar otro navegador o acordar una transición con el cliente.
Antes de retirar soporte, identifica las tareas que podrían dejar de funcionar, el número y tipo de usuarios potencialmente afectados, las dependencias internas y la fecha de cambio. Define si habrá periodo de aviso, canal de consulta o excepción temporal. Una excepción debe tener propietario, motivo, alcance y fecha de revisión; de otro modo, se convierte fácilmente en soporte indefinido.
Valida la matriz y comunícala con claridad
La matriz debe corresponderse con pruebas reales. Para cada entorno garantizado, decide qué flujos críticos se verifican y en qué momento: antes de publicar, en pruebas automatizadas cuando sean adecuadas y en comprobaciones manuales para comportamientos que lo requieran. No es necesario probar todas las combinaciones posibles de dispositivo, versión y configuración, pero sí explicar qué cobertura se eligió y qué riesgo queda fuera.
Prioriza los recorridos que afectan a resultados importantes: acceso, operación principal, formularios, pagos si existen y recuperación ante errores. Comprueba también la presentación en tamaños de pantalla relevantes, la navegación con teclado y los mensajes ante funciones no disponibles. Las herramientas de analítica y rendimiento pueden aportar señales, pero no sustituyen la comprobación funcional ni la investigación de incidentes.
Publica la matriz en un lugar accesible para usuarios y equipos internos. Incluye la fecha de actualización, los niveles de soporte, las limitaciones conocidas, alternativas recomendadas y un canal para informar de problemas. Si un entorno no soportado puede acceder a la aplicación, explica que el funcionamiento no está garantizado; no presentes una advertencia como si fuera una validación.
Plantilla práctica y ciclo de revisión
Una matriz útil puede mantenerse en una tabla interna y resumirse en la documentación para usuarios. Registra, como mínimo:
- Entorno: navegador o aplicación, sistema operativo, dispositivo y versión o regla de actualización.
- Nivel de soporte: garantizado, validado o no soportado.
- Evidencia y riesgo: uso observado, requisitos conocidos, limitaciones y flujos comprobados.
- Responsable: persona o equipo que mantiene la decisión y coordina incidentes.
- Condición de revisión: fecha acordada o cambio que obliga a reevaluar, como una nueva dependencia, un incidente o un requisito de cliente.
Revisa la matriz en una cadencia acordada y también ante cambios relevantes; no hace falta cambiarla cada vez que aparece una nueva versión. Antes de actualizarla, evalúa impacto, pruebas necesarias, comunicación y alternativas. Después, conserva el motivo de la decisión para que el siguiente ciclo no empiece desde cero.
El resultado no es una promesa de funcionamiento perfecto en cualquier equipo. Es una definición explícita de dónde invierte el equipo en validar y mantener el producto, qué incertidumbre acepta y cómo responderá si cambian las necesidades. Esa claridad permite tomar decisiones proporcionadas y corregirlas con menos sorpresas.