Considerar al personal de soporte al usuario final como partes interesadas con sus propios conocimientos y necesidades crea mejores implementaciones para todos
por Isaac Sacolick
Los equipos de desarrollo ágiles (agile development) tienen como objetivo desarrollar capacidades innovadoras, mientras que los equipos de devops se esfuerzan por lanzar código para producción con mayor frecuencia. Pero la responsabilidad a menudo se detiene en la mesa de servicio de TI y los equipos de soporte al cliente, que deben responder a los incidentes, problemas y solicitudes de las aplicaciones.
Lanzamiento con demasiada frecuencia con defectos, cuellos de botella de rendimiento o problemas de seguridad, y los usuarios finales pueden inundar los equipos de servicio y soporte con incidentes. Incluso cuando los equipos de devops implementan cambios confiables, aún tienen la responsabilidad de ayudar a los equipos de soporte a brindar un excelente servicio al cliente o soporte al usuario final.
¿Cómo se ve eso en la práctica? Requiere un proceso de administración de versiones integral en el que una implementación de producción no se marca como realizada hasta que los equipos de soporte brindan comentarios sobre el éxito general de la implementación y comprenden los problemas.
Para lograr este nivel de colaboración, los equipos de desarrollo ágiles que se comprometan con una cultura devops deben considerar las siguientes mejores prácticas.
1. Definir y establecer expectativas en torno a lanzamientos de alta calidad.
Esto puede parecer obvio, pero en la práctica elude a muchos equipos de desarrollo debido a la complejidad de los entornos, las demandas comerciales de liberar capacidades demasiado rápido o las brechas en las pruebas.
Con demasiada frecuencia, encuentro una brecha cultural. Si publica el código hoy, pero debe parchearlo uno o dos días después debido a defectos o problemas de soporte al usuario final, ¿la versión original se considera un éxito? La respuesta debería ser no. Una vez que el equipo de devops lanza, debe haber una expectativa de que la implementación sea de alta calidad y que el equipo pueda pasar al siguiente conjunto de prioridades de desarrollo. Una vez que el equipo acepta parchear, realizar una versión de emergencia de “reparación”, revisar o ejecutar una implementación no programada, el equipo debe etiquetar la versión original como una implementación fallida o degradada.
Este principio alienta a los equipos de devops a revisar los flujos de aplicaciones, mejorar la automatización de las pruebas , desarrollar conjuntos de datos de prueba más sólidos, emplear pruebas de seguridad de cambio a la izquierda e invertir en el marcado de funciones .
WHITEPAPERS RECOMENDADOS
2. Comunicar los horarios de implementación y compartir notas de la versión
Pregunte a muchos equipos de atención al cliente y de la mesa de servicio de TI sobre los programas de implementación y le dirán que a menudo son los últimos en enterarse de los planes de los equipos de desarrollo. Las personas que trabajan en estas funciones a menudo no tienen acceso a Jira, Microsoft Teams, Jenkins u otras herramientas que los equipos de devops usan para planificar y ejecutar lanzamientos. Incluso cuando los equipos de DevOps configuran alertas por correo electrónico para informar a los equipos de soporte sobre las implementaciones planificadas y ejecutadas, los correos electrónicos y las notas de la versión suelen estar llenos de jerga técnica inútil.
Los equipos de Devops deben adaptar específicamente las comunicaciones o colaboraciones de planificación, lanzamiento e implementación a sus audiencias. Para los equipos de atención al cliente y de la mesa de servicio, las comunicaciones deben centrarse en cómo la versión afecta a los usuarios finales.
Los equipos de Devops también deben anticipar el impacto de los cambios en los usuarios finales y educar a los equipos de soporte. Cuando la experiencia del usuario o el flujo de trabajo de una aplicación cambian significativamente, incorporar equipos de soporte con anticipación para revisar, comprender y experimentar los cambios en sí mismos puede ayudarlos a actualizar los procesos de soporte.
3. Invierta en monitoreo de aplicaciones y AIops
Consideremos dos escenarios. Un equipo de devops monitorea sus entornos de múltiples nubes y sabe cuándo los servidores, el almacenamiento, las redes y los contenedores experimentan problemas. Han centralizado los registros de aplicaciones, pero no han configurado informes o alertas de ellos, ni han configurado monitores de aplicaciones. La mayoría de las veces, cuando un incidente o problema afecta a los usuarios finales, es la mesa de servicio y los equipos de soporte los que derivan el problema a las operaciones de TI, SRE (ingenieros de confiabilidad del sitio) o el equipo de DevOps.
Esa no es una buena situación, pero tampoco lo es el otro extremo cuando los equipos operativos de TI configuran demasiados sistemas y alertas de aplicaciones. Un incidente puede disparar docenas de monitores y alertas, lo que dificulta determinar la causa subyacente y seleccionar un curso de acción. En este escenario, el equipo de TI puede beneficiarse de la implementación de una solución AIops , como Big Panda o Moogsoft, que agrega alertas, aplica aprendizaje automático para correlacionar datos de monitoreo y automatiza pasos para abordar problemas comunes.
El objetivo debe ser minimizar el impacto en los usuarios finales y reducir las condiciones en las que tienen que abrir tickets de soporte para incidentes de aplicaciones.
4. Proporcionar herramientas de administración de autoservicio, capacidades de consulta e informes.
Este es otro principio de desarrollo de aplicaciones: evite lanzar funciones que no tengan herramientas administrativas, flujos de trabajo o informes para ayudar a los usuarios finales. Los propietarios de productos ágiles priorizan rápidamente el desarrollo de una función, pero a veces tardan en invertir en sus funciones de soporte.
No es “suficientemente bueno” si las mesas de servicio o los equipos de soporte deben abrir tickets con otras áreas de TI para ejecutar una consulta, exportar datos, cambiar manualmente datos en una base de datos o ejecutar un trabajo por lotes. Todas estas son formas de deuda operativa o técnica.
Los propietarios de productos ágiles deben tratar a la mesa de servicio y los equipos de soporte como a otras partes interesadas y deben capturar y priorizar sus requisitos. Idealmente, los principios ágiles o la gobernanza definen qué herramientas se requieren, cuándo se invierten nuevas capacidades o cuándo se mejoran las funciones existentes.
5. Revise los tickets de la mesa de servicio y priorice la reparación de defectos
Los ejecutivos de TI solicitan a los equipos de desarrollo que se basen en datos, y un buen lugar para comenzar es programar revisiones periódicas de los problemas y solicitudes que se informan al servicio de atención al cliente y a los equipos de atención al cliente. Idealmente, los equipos de DevOps deberían buscar automatizar los flujos desde el sistema de tickets de la mesa de servicio como defectos o solicitudes de funciones en los trabajos pendientes de los equipos de desarrollo ágiles.
Los equipos de desarrollo ágiles deben utilizar estos comentarios para priorizar sus trabajos pendientes. Aprovechar la retroalimentación, especialmente de los clientes y usuarios finales, es un principio clave de scrum y otras metodologías ágiles.
Los equipos de desarrollo deben considerar estos problemas desde varios puntos de vista. Algunos problemas sistémicos afectan a muchos usuarios finales o dan lugar a múltiples tickets de la mesa de servicio, lo que facilita la priorización de las mejoras. Otros son como agujas en un pajar, pero estos valores atípicos aún impactan a los clientes estratégicos o los procesos comerciales críticos.
Los equipos de desarrollo pueden tener un tiempo limitado asignado para abordar todos los problemas, pero puede haber otras opciones para proporcionar soluciones, herramientas operativas simples o mejor documentación para ayudar a los empleados de la mesa de servicio.
A veces, puede ser suficiente ser empático con las personas que trabajan en la mesa de soporte y servicio y en la primera línea con los clientes y usuarios finales. Por lo tanto, antes de agregar una nueva función, mejorar la tubería de CI / CD (integración continua / implementación continua) o agregar una nueva tecnología , considere estas mejores prácticas que pueden mejorar la satisfacción del usuario final y ayudar a los equipos de servicio y soporte.Relacionado:
Sobre el autor:
Isaac Sacolick es el autor de Driving Digital: The Leader’s Guide to Business Transformation through Technology , que cubre muchas prácticas como ágil, devops y ciencia de datos que son fundamentales para programas exitosos de transformación digital. Sacolick es un reconocido CIO social superior, bloguero desde hace mucho tiempo en Social, Agile and Transformation y CIO.com , y presidente de StarCIO.
Fuente: https://www.infoworld.com/article/3575862/5-ways-agile-devops-teams-can-support-it-service-desks.html