Soporte y mantenimiento
Soporte y mantenimiento como servicio
El software no deja de necesitar ingenieros el día que sale a producción. Nos hacemos cargo del trabajo continuo (pruebas, pipelines, infraestructura, parches, pequeñas funcionalidades) de aplicaciones que ya están funcionando, incluidas las que no construimos nosotros.
- QATesting como servicio
- DevOpsPipelines e infraestructura
- Código heredadoBienvenido, no un impedimento
Qué cubrimos
Las tres cosas para las que los equipos se quedan antes sin capacidad
Coge una o las tres. Cada una la cubren ingenieros senior que hacen este trabajo de forma continua, no entre proyecto y proyecto.
QA como servicio
Estrategia de pruebas, baterías de regresión automatizadas y testing de release, en manos de gente cuyo trabajo es encontrar los problemas antes que tus usuarios.
Soporte DevOps
CI/CD, infraestructura como código, monitorización y alertas, mantenidos por ingenieros de guardia y no por quien lo montó el año pasado.
Mantenimiento de aplicaciones
Parches de seguridad, actualización de dependencias, corrección de errores y pequeñas funcionalidades en sistemas que están vivos y no se pueden rehacer de cero.
En la práctica
En qué consiste el trabajo de verdad
Cobertura de regresión automatizada
La batería de pruebas que te permite publicar un jueves. Escrita contra los recorridos que importan comercialmente, no para llegar a un porcentaje de cobertura.
Pruebas de release y de aceptación
Cada versión se ejercita contra escenarios y dispositivos reales antes de llegar a los clientes, con los defectos reportados de forma reproducible.
Pipelines que siguen en verde
Automatización de build, test y despliegue mantenida a medida que cambia tu stack, para que desplegar deje de ser un acto al que alguien tiene que asistir.
Monitorización, alertas y guardia
Te enteras por un cuadro de mando y no por un cliente, y hay un ingeniero con nombre que responde cuando salta la alerta.
Parcheo y actualización de dependencias
CVE, fin de vida de runtimes y subidas de versión de frameworks gestionados con calendario, antes de que se conviertan en una urgencia o en un hallazgo de auditoría.
Mejora incremental
Las pequeñas funcionalidades y correcciones que nunca llegan a una hoja de ruta, entregadas de forma continua para que el producto no se estanque sin que nadie lo note.
Cómo empezamos
Leemos el sistema antes de prometer nada sobre él
Hacerse cargo de software que no escribiste es un problema conocido con un método conocido. No es un taller de descubrimiento.
Auditar lo que hay
Código, infraestructura, tests, camino de despliegue y defectos conocidos. Recibes las conclusiones por escrito, sigas con nosotros o no.
Estabilizar los riesgos
Lo urgente que haya encontrado la auditoría: dependencias sin parchear, copias de seguridad que no existen, un despliegue que solo sabe hacer una persona. Resuelto primero.
Acordar el nivel de servicio
Tiempos de respuesta, horario de cobertura y capacidad mensual por escrito, dimensionados según lo que ese sistema vale para el negocio.
Operarlo de forma continua
Un ritmo mensual estable de QA, parcheo y pequeñas mejoras, con un informe de qué cambió y cuánto costó.
Preguntas frecuentes
Lo que se pregunta sobre los contratos de soporte
¿Mantenéis software que ha construido otra empresa?
Sí, y buena parte de este trabajo es exactamente eso. La fase de auditoría existe para poder ser honestos sobre el estado de lo que heredamos antes de que ninguna de las dos partes se comprometa.
Si la auditoría concluye que mantenerlo cuesta más que sustituir una parte, también te lo diremos, incluso cuando eso signifique un contrato más pequeño para nosotros.
¿Cómo se factura?
Como una cuota mensual que cubre una capacidad y un tiempo de respuesta acordados, que es lo que lo convierte en una línea de presupuesto en lugar de una serie de sorpresas. Cuando la carga es de verdad impredecible, facturamos por tiempo y materiales con un tope.
¿Podemos contratar solo el QA?
Sí. QA como servicio es con frecuencia lo primero que los equipos externalizan, porque es la disciplina que más se salta cuando los desarrolladores están bajo presión de entrega, y porque pide instintos distintos de los que hacen falta para escribir la funcionalidad.
¿Cuáles son vuestros tiempos de respuesta?
Se acuerdan en cada contrato contra horario laboral europeo, con niveles de severidad para que una caída en producción y un defecto estético no se traten como la misma petición. Hay cobertura ampliada cuando el sistema lo justifica.
¿Trabajáis junto a nuestros desarrolladores internos?
Normalmente sí. Un reparto habitual es que tu equipo lleve el producto nuevo mientras nosotros cargamos con el QA, los pipelines y el backlog de mantenimiento: justo el trabajo que, si no, les interrumpe toda la semana.
¿Y si más adelante queremos volver a llevarlo internamente?
Sigue siendo posible por diseño. El trabajo ocurre en tu repositorio y en tu cuenta de cloud, los tests y las definiciones de infraestructura son tuyos, y la documentación está escrita para que alguien recién incorporado pueda cogerlo sin tener que reservar una reunión con nosotros.
Cuéntanos qué tienes ya en producción
Una llamada con un ingeniero senior sobre el sistema que estás sosteniendo. Saldrás sabiendo qué implicaría mantenerlo como es debido.