Bailes con apoyo: tipos y formas de apoyo. Sistemas de soporte trabajando en batalla

Hola a todos! Mi nombre es Alexander Afenov y soy el líder del equipo de procesamiento de pedidos en Lamoda. Hoy quiero contarles cómo recaudamos el apoyo.

Primero, hablemos sobre cómo está incrustado en nuestros procesos y cómo, en general, planificamos nuestro trabajo, sprints e iteraciones.

Luego le diré de dónde puede venir el soporte y en qué tipos se divide.
Compartiré la experiencia de cómo dentro del equipo tratamos con cada tipo de soporte.

Al final, consideramos los pros y los contras de las prácticas que utilizamos y resumimos.


Mi equipo ahora tiene dos sistemas. El primero es una cosa grande y aterradora llamada Procesamiento de pedidos . Este es un sistema que automatiza el ciclo de vida de un pedido desde el proceso de creación hasta la entrega (o devolución).

El servicio está girando en PHP 7, envuelto en Docker y Kubernetes orquestados, pero se implementa en el marco Zend1 y piezas de Symfony 2. Aquellos que programan en PHP ahora pueden haberse estremecido. Por lo demás, explicaré que Zend1 es un marco que terminó hace un año y medio. Ya no es compatible y ni siquiera tiene parches de seguridad.

El proyecto es grande (más de 150 mil líneas de código) y no hace mucho su trabajo. Por ejemplo, no solo procesa pedidos, sino que, por alguna razón, envía correo, sms, empuja, transfiere datos a otros sistemas. Por lo tanto, lo estamos cortando en microservicios separados.

Lo primero que sacamos del monolito es la llamada herramienta de reembolso . Es el segundo servicio dirigido por mi equipo y es responsable de la devolución automática de dinero al cliente (más en el informe de mi colega) .

A pesar de que la herramienta de reembolso tiene una pila tecnológica moderna, todavía genera un montón de soporte debido al legado del procesamiento de pedidos.

Esto sucede debido al hecho de que tomamos un cierto proceso comercial, que solía construirse en muchos archivos de Excel, y lo transferimos a un nuevo sistema que funciona a través de Kafka, y también interactúa con un par de sistemas. Por supuesto, cuando introdujimos un nuevo sistema y cambiamos el proceso comercial, obtuvimos soporte. Y durante muchos años de trabajo con esto, hemos ganado algo de experiencia.

Creo que las personas se dividen en dos categorías: aquellas con un sistema de producción que genera apoyo y malditos mentirosos. Por lo tanto, compartiré experiencias que pueden ser útiles para optimizar sus procesos. Si las soluciones propuestas (en combinación o por separado) son adecuadas para usted, aparecerá más tiempo para el desarrollo de la funcionalidad de su sistema, el análisis de la acumulación técnica y no para trabajar con soporte.

Hablar sobre las herramientas utilizadas requerirá contexto, por lo que primero hablaremos sobre las más básicas.

Procesos y roles

¿Cómo trabajamos con apoyo y qué lugar ocupan nuestros sprints?

Cubos proporcionales es lo que yo llamo nuestros cubos .

Tomamos el 10% de la cartera técnica para que no se estanque y no se acumule indefinidamente.

Aproximadamente el 20% del sprint se toma para establecer algunos riesgos. Por ejemplo, alguien estaba haciendo una tarea, pero esta persona fue "atropellada por un autobús". El siguiente tendrá que volver a examinar el contexto. Como resultado, no entraremos en la evaluación, y todo será malo.

A continuación, ponemos el soporte planificado. Es decir, ya sabemos que algo está mal. Esto es algo que no se quema mucho y lo repararemos.

Pero lo más interesante es un soporte no planificado. Es decir, suponemos que algo puede romperse durante el período de iteración y dedicaremos tiempo a las reparaciones.

El 30% restante son proyectos.

Probablemente hayas notado que resulta más del 100%. Esto se debe al hecho de que siempre intentamos hacer más de lo que realmente podemos. A veces tenemos éxito, a veces no muy.

Parámetros principales de soporte

Evaluamos cada ticket de soporte de acuerdo con los siguientes parámetros:

1. Criticidad para los negocios. ¿Qué tan importante es esto para ellos y cuánto esto rompe el proceso de negocio?
2. SLA ¿Cuánto tiempo debemos tomar el problema para trabajar y resolverlo?
3. Prioridad

Si algo salió mal con los usuarios de nuestros sistemas, informan esto al servicio de soporte y aclaran que un incidente bloquea parcial o totalmente el proceso comercial. El soporte trae inmediatamente un nuevo ticket al sistema responsable y le da prioridad .

La criticidad y la prioridad son términos diferentes.

Tipos de prioridad

Bloqueador : algo rompió absolutamente todo, detuvo el negocio. Los pedidos no se crean, no entran en la entrega, no se aceptan pagos, etc.

Major es algo menos importante y puede repararse por más tiempo, ya que existen soluciones alternativas, caminos alternativos.

Trivial Por ejemplo, alguien escribe que nuestros botones están en un color desagradable y deben ser repintados. Hay una alta probabilidad de que tal boleto nunca se haga.

También existe un acuerdo de nivel de servicio , establecido por el servicio de soporte junto con el equipo y el propietario del sistema. Analizan qué línea de negocio se ha desglosado como parte de una queja específica. Si, por ejemplo, se han dejado de crear pedidos (el pan principal de la tienda en línea), entonces este problema tendrá una alta prioridad, que llamaremos P1. P es prioridad, la unidad es lo más importante.

P1 es un tipo de SLA, lo que significa que debemos tomar el problema para trabajar en media hora y resolverlo en un par de horas como máximo.

P2 es algo menos significativo que tenemos que tomar en un par de horas y decidir durante el día.

P3-P4 es algo que se ha descompuesto y no requiere reparaciones urgentes. Algún día puedes hacerlo, llevarlo a la siguiente iteración.

Y aquí llegamos a la prioridad establecida por el equipo. Puede ser un experto técnico, un ingeniero de soporte senior, cualquiera que se ocupe del problema.

Supongamos que actualmente tenemos 4 tareas con prioridad comercial principal. La persona del equipo, debido a su experiencia, pone un cierto valor numérico, que llamamos prioridad detallada . En base a esto, la placa de soporte se ordenará en el futuro. Es decir, en la parte superior habrá las tareas de mayor prioridad para el negocio, que aún están clasificadas por la comprensión del equipo de lo importante que es realmente y qué tan rápido puede hacerlo.

Entre los parámetros principales, parece que falta uno de los más importantes: una descripción normal . Muy a menudo, tenemos tareas de soporte iniciadas desde el sistema Sentry, donde caen errores, excepciones, etc. Una persona ve que hay un pequeño problema y crea un rompecabezas en Jira. Dado que nuestros sistemas están integrados entre sí, aparece una tarea en el rastreador de tareas, en la descripción de la cual solo hay un enlace a Sentry, y en el título hay un texto de error. Eso es todo.

¿Cómo debería trabajar alguien con esta tarea? No muy claro. Si agrega una buena descripción a esta tarea, sería de gran ayuda y ahorraría tiempo.

¿Quién rastrillará todo?

Y cuando se hace todo esto, surge la pregunta: ¿quién va a rastrillar este retraso acumulado maravillosamente ordenado? La respuesta es: ingeniero de soporte.

Puede escuchar con más detalle quién es el ingeniero de soporte y qué hace en mi charla "Hipoteca técnica: qué y quién debe liderar el equipo" con TeamLeadConf 2018.

Un ingeniero de soporte es un tipo que toma y repara las tareas de mayor prioridad de una cartera de soporte. Dado que todo está bellamente ordenado, creemos que en la parte superior está lo más importante, urgente y "horneado". Si no hay tareas, entonces él puede hacer una acumulación técnica.

¿Qué más está haciendo?

1. Intenta aislar y eliminar la causa raíz , es decir, la causa raíz del soporte. Cuando recibe regularmente boletos del mismo tipo, vale la pena considerar por qué sucede esto. Lo más probable es que en algún lugar haya un problema que pueda eliminarse y, por lo tanto, detener el flujo de tareas similares.

2. Establece las tareas de corrección y monitoreo .
Si el ingeniero de soporte no puede resolver el problema en un día o dos como máximo, entonces establece una tarea separada para él, que se incluye en el trabajo atrasado de desarrollo. Luego es evaluado por el equipo y entra en la iteración como un soporte planificado.

El monitoreo juega un papel importante para nosotros. Bloqueamos el monitoreo no solo en las métricas que estamos acostumbrados a monitorear de manera continua, sino que también las agregamos para localizar los problemas de mayor duración. En mi opinión, sería mejor si tuviéramos un monitoreo innecesario, que luego bebimos, que el problema se repetirá constantemente en forma de más y más boletos.

3. Buscando razones para la automatización .
Ejemplo : transferimos datos a nuestro sistema, que automatiza el trabajo del servicio de entrega. A veces resulta que incluso con el uso del canal de letra muerta y el reenvío, no podemos entregar información allí. Como resultado, tales órdenes cuelgan en algún lugar y deben ser reenviadas.

Este es un soporte típico que ocurre varias veces cada semana. Para resolver este problema, decidimos hacer una página separada con el botón "reenviar lista de pedidos". Ya no tenemos este apoyo. Es decir, pensaron que, automatizado, se lo dio al servicio de soporte.

El rol de un ingeniero de soporte se transfiere todas las semanas a otra persona; este es un requisito previo. Hacer ese trabajo por más tiempo es estrés, desmotivación y decadencia, porque constantemente está reparando algo y no aporta nada nuevo al sistema.

La regularidad como fuente de gracia.

Parece obvio, pero a menudo se olvida de todos modos. Para que todo funcione, es necesario que nuestros procesos se pongan en marcha y se observen regularmente.

Inspección de pedidos pendientes

¿Dónde obtendremos una reserva de soporte bellamente ordenada si nadie está mirando allí?

En el buen sentido, debe encontrarse con él una vez al mes y cerrar tareas con un estado trivial (que probablemente nunca alcanzará). Sé honesto contigo mismo y con el cliente. Si la acumulación de tareas debido a tales tareas crecerá infinitamente, luego tendrá que entrar en pánico para intentar cerrarlas. Esto no es muy bueno.

Fijación de prioridad detallada

Este es el proceso en el que evaluamos cuán crítica es una tarea. Entonces será la clasificación correcta, y el ingeniero de soporte tomará la tarea correcta desde arriba.

Batalla por la prioridad

Por ejemplo, establecen una tarea para usted y dicen: “Chicos, el informe mensual no se carga. Necesitamos tenerlo en una semana, pero no funciona. Por favor arreglalo. Prioridad P1. Debe decidir dentro de 2-3 horas ".

Y preguntas: “¿En serio? ¿De qué están hablando? Después de todo, hay una semana para arreglarlo. Bajemos a P2 y tendremos un par de días ".

A veces las personas piensan que no asumiremos la tarea, por lo que otorgan una alta prioridad especial. Pero sucede y viceversa. Por ejemplo, nos escriben que los pedidos no se crean y dan prioridad a P2. Este problema es mucho más grave, por lo tanto, vale la pena elevar la prioridad a P1. Es útil negociar a sabiendas en ambas direcciones.

Establecimiento de nuevas tareas.

Anteriormente, mencioné el sistema Sentry, que incluye tareas que ya están siendo criticadas por los clientes. Sin embargo, nosotros mismos anticipamos los problemas que surgen y agregamos las tareas a este trabajo atrasado.

Control de rendimiento de SLA

Para hacer esto, tenemos horarios que muestran que tenemos tareas, cuyo tiempo pronto expirará. Parece que estos acertijos tienen sentido en primer lugar.

Soporte Ingeniero Soporte

Ser un ingeniero de soporte es un proceso bastante deprimente, por lo que una persona debería ayudar. ¿Cómo podemos facilitarle la vida?

Transferencia del rol al siguiente del equipo

Necesitamos mantener un horario de quién hará esto la próxima semana. Sin embargo, ocurren momentos límite. Por ejemplo, una persona tomó una tarea el viernes y no tuvo tiempo de terminarla. Puede pasar tiempo la próxima semana, pero es mejor entregar la tarea a un nuevo ingeniero de soporte. Si arrastra el rastrillo acumulado durante dos semanas, la persona probablemente estará bastante desmotivada. Verá esto en la próxima reunión personal :)

Ayuda a encontrar la fuente del problema

A la gente le gusta simplemente realizar tareas, pero no se concentran en encontrar la causa raíz. Vale la pena hacer la pregunta: "Si cerró la tarea, ¿por qué surgió el problema inicialmente?". Esta práctica ayudará a encontrar la causa, eliminarla y posiblemente eliminar el flujo de dicho apoyo en el futuro.

La necesidad de una "mirada fresca"

Si una persona durante un cierto período de tiempo no puede lograr un resultado visible, entonces esta tarea debe transferirse a otra. Alguien más podrá ver el problema desde el otro lado, lo que puede conducir a la solución del problema de una manera diferente.

Pero este enfoque puede ocultar algunos aspectos psicológicos interesantes. Es decir, al tomar una tarea de una persona y dársela a otra, corre el riesgo de decir que él lo sabe mejor, por lo que se las arreglará. Tales cosas se presentan mejor de una manera diferente. Concéntrese en el hecho de que todos necesitamos resolver problemas con el sistema y no probarnos cuál de nosotros es más genial.

Desarrollo de herramientas para la automatización.

Aquellos que a menudo son ingenieros de soporte entienden que ya "no saben" realizar las mismas tareas típicas. Recientemente, uno de nuestros desarrolladores tiene su propio mini framework en Go. Él va a diferentes bases de datos, recopila datos, empuja algo en Kafka. Por lo tanto, pudo automatizar esta tarea lo más posible y facilitar la vida de los demás.

Fuentes de soporte

¿Hay tanto apoyo que a veces no pensamos de dónde viene tan a menudo?

Estabilización de nuevos sistemas y procesos.

Si ha traído algo nuevo, lo más probable es que se use incorrectamente. Te encontrarás con nuevos problemas y tu reserva de soporte se repondrá inmediatamente con tickets o tickets.

Soporte para sistemas más antiguos.

Por ejemplo, nuestro monolito. No puede quedarse quieto, como siempre agregamos, reescribimos, algo en él. Por supuesto, esto lleva a la creación de un nuevo soporte.

Falla técnica

Por ejemplo, la red desconectada. Parece que no tienes la culpa, pero sin duda vendrán a ti y te preguntarán por qué no se crearon los pedidos. Será necesario reparar, arreglar, modificar algo. Se requerirá intervención manual y, por lo tanto, se proporcionan nuevos tickets en la cartera de pedidos.

Factor humano

Tuvimos un caso cuando alguien pudo producir un mensaje en RabbitMQ que nuestro consumidor colgó, y todo dejó de funcionar. Esto nunca ha sucedido en los últimos 7 años, pero aquí de alguna manera se las arregló :)

El factor humano que condujo al fracaso.

Alguien con las palabras "lo arreglaré ahora" sacó el disco duro del servidor en el que giraba la facturación. Como resultado, obtuvimos lo que obtuvimos. Esta no es la experiencia de Lmoda, sino un caso real de mi práctica.

Tipos de soporte

Solicitud de análisis

Cuando preguntan regularmente sobre el estado de algo en la base de datos, solicitan cargar, recopilar un informe durante un período determinado, etc. Esto es un poco molesto, por lo que tiene una buena razón para pensar en la automatización y simplemente proporcionar una interfaz de usuario o estudiar la estructura de la empresa.

Por ejemplo, no descubrí de inmediato que la mayoría de los datos de pedidos que tenemos están almacenados en la base de datos Oracle del departamento de D&A, y todo se puede obtener desde allí. Tal soporte se automatiza a través de interfaces o se transfiere al departamento de análisis.


Solicitudes de cambio de datos

Las situaciones son diferentes e impredecibles. Digamos que nuestro cliente iba a pagar su pedido con una tarjeta. Cuando llegó el servicio de mensajería, cambió de opinión y decidió hacer esto en efectivo. O, por ejemplo, en algún lugar hubo un problema automatizado que debe cambiarse a mano. Necesitamos corregir estos datos.

Para hacer esto, intentamos crear nuevos identificadores de API, crear interfaces y, al máximo, eliminar estas tareas del desarrollo y de nuestro equipo de Operaciones. Esta es una práctica peligrosa, y la eliminamos a través de la interfaz y las mejoras de API.

Reparación de procesos de negocio.

Si hay una necesidad directa de editar algo en la base de datos, entonces hay un proceso comercial defectuoso. Esto podría suceder debido a una razón relacionada con TI o algo sale mal en el negocio. Tanto allí como hay ajustes necesarios. En este caso, debe dirigirse al cliente comercial y analizar si se puede hacer de manera diferente, o solicitar el desarrollo para reparar el proceso comercial.


La función X dejó de funcionar

Este es mi tipo de soporte favorito, porque es el más comprensible. Es decir, tuvimos algún tipo de cosa en el producto, pero se rompió y necesita ser reparado. Averigüe en qué liberación murió y por qué motivo. Repara y cierra el boleto. Todo es simple

Pero hay otro soporte: la función X no funciona . Puede parecer lo mismo, pero dicho en otras palabras. Sin embargo, esto no es así.

En esta situación, vienen a ti y te dicen que esto no funciona. Pasas uno o dos días resolviéndolo. Solo más tarde te diste cuenta de que esto nunca funcionó aquí . Simplemente no estaba en su sistema.

De otra manera, llamo a este tipo de soporte "zorro" cuando alguien astuto quiere deslizar una solicitud de función bajo la apariencia de una tarea de soporte. Esta es una historia regular que es muy dolorosa. Si no detiene esos momentos, resulta que su ingeniero de soporte o usted mismo están introduciendo una nueva funcionalidad, y los problemas reales de la acumulación de soporte siguen sin resolverse.

Incidente mayor

Esta es solo la historia del ataúd y el incendio de la turba, cuando algo se rompió en los sistemas de TI tan mal que surgió un proceso comercial específico.

Estudio de caso de nuestra práctica: nosotros, debido a un error en el código y a las pruebas automáticas imperfectas, comenzamos a enviar una cierta nota sobre el estado del pedido al servicio de mensajería externo, por lo que las personas no podían recoger su pedido en el punto de emisión. Ha afectado a miles de clientes. Tuvimos que retirar todos los pedidos, gastar dinero en ello. No pudimos venderlos y se perdió la lealtad del cliente. Este es un gran incidente que ha dañado el negocio.

Vale la pena trabajar con tales cosas de una manera especial, y les diré cómo lo hacemos.

¿Cómo saber que algo está pasando?

La opción más común en la industria es aprender de los usuarios . Él, por supuesto, es lo peor, porque significa que ya "hornean".Ven que nada funciona para usted y necesitan repararse urgentemente.

Quizás lo descubra en el servicio de soporte , que monitorea el monitoreo y notifica a la persona en servicio en el sistema.

Pero la mejor parte es descubrir de forma independiente por la presencia de monitoreo . Es decir, puede usar un sistema que rastrea la dinámica por métricas. Por ejemplo, si algo se puso rojo en un televisor suspendido, entonces, digamos, Rabbit murió.

Es genial, pero parece que esto no es suficiente. Muchos problemas pueden detectarse incluso en el camino, si monitorea ciertas tendencias.. Tuvimos un caso así cuando notamos en el monitor que en la mañana el consumo de memoria en el clúster Rabbit MQ comenzó a crecer. Entendimos que solo tenemos 16 gigabytes allí, y con tal dinámica en unas pocas horas la memoria terminará y todo se caerá.



Como vimos esa tendencia, nos alarmamos a tiempo. Resultó que teníamos un plugin de pala colgando y la memoria fluía. El problema se resolvió, mientras que se evitó mayor.

Si algo ya sucedió, y usted se entera al respecto, necesita localizarlo de alguna manera . Por supuesto, dependiendo del tamaño del equipo y de lo que está haciendo, puede hacer cosas diferentes. Pero creo que la movilización es muy importante .

Supongamos que tienes 5 personas en un equipo. Uno de ellos participó en el análisis de por qué nada funciona ahora, mientras que los cuatro restantes continúan viendo sus características. Como resultado, tiene sistemas rotos y un montón de nuevas características. Es genial, pero a veces vale la pena movilizar y organizar una lluvia de ideas. El examen de cada miembro del equipo puede reducir el tiempo durante el cual nada funciona.

Y después de que lograron sacar todo, comienza la etapa retrospectiva.

Retrospectiva

En Lamoda, en esta reunión, tenemos una persona a cargo de cada sistema involucrado en el incidente. Si es necesario, alguien de la empresa está presente, a veces incluso viene CTO. Y en esta reunión, hacemos una descripción de lo que sucedió exactamente y en qué sistema se encendió.

Luego viene el momento más divertido: el análisis de la secuencia de acciones. Es decir, lo que hicimos entre detección y extinción al minuto más cercano, si es posible.



Vemos que a las 13.05 se recibió una queja en el centro de llamadas. Alrededor de 13.13 quedó claro que era masivo. Y solo a las 14.50 el equipo asumió la tarea de trabajar. Antes de eso, por alguna razón, 1,5 horas era simple, aunque la tarea estaba establecida y se notificó al equipo. Parece que esta brecha en 1,5 horas podría reducirse y, por lo tanto, ahorrar millones de rublos en este incidente.

¿Por qué surgió este problema?

Los muchachos se levantaron y fueron a cenar sin llevar computadoras portátiles ni teléfonos, por lo que no estaban disponibles. Parece que algo vale la pena arreglar en este momento. Por ejemplo, lleve computadoras portátiles con usted, deje al oficial de servicio en caso de que haya una liberación importante.

También puede ver que la solución estaba en producción a las 16.55, lo cual también es extraño, ya que antes habían pasado más de 40 minutos. Cuando todo parece estar marcado, puede rodar, pero nosotros no.

¿Por qué está pasando esto?

Hemos estado realizando pruebas de integración durante mucho tiempo, aproximadamente media hora. Y en esta situación resulta que debes tomar una decisión. O despliega el sistema corregido y elimina el problema, o tal vez crea uno nuevo. O está esperando que los procesos CI / CD súper largos se desplacen y el lanzamiento entrará en batalla. Obviamente, en nuestro caso, necesitamos reducir el tiempo que lleva ejecutar todas las pruebas para poder ejecutar las pruebas más rápido y rodar más rápido, cuando todo esté verificado.

El siguiente punto es la evaluación de impacto.. Impacto es el impacto de este incidente en un negocio. Es decir, cuánto pierde la empresa en pedidos, en rublos, en loros, no importa. Esta es la cifra con la que luego puede entrar en el negocio y mostrar lo que sucede si TI no da tiempo para la estabilización, la automatización de pruebas y similares.

Luego la redacción de las acciones preventivas . Esto es importante porque de alguna manera debe garantizarse a sí mismo, a la gerencia y a cualquier otra persona, que esta misma cosa no se disparará esta noche, mañana, etc. Es decir, no necesita repetir el mismo incidente. Para hacer esto, formulamos acciones preventivas. Es decir, cómo logrará esto, cómo protegerse de él o anticiparlo.

También es necesario establecer plazos o versiones fijas .

Y luegocontrolar la ejecución Los planes son buenos, pero evitar el problema es mucho más importante.

En mi opinión, también es importante recordar que el apoyo habitual no es peor que el incidente mayor. Puede tomar un error grave con el que se molestó un día o más, caminar por las mismas estepas y comprender por qué sucedió, por qué tomó tanto tiempo decidir cómo evitarlo en el futuro. Usando el mismo patrón, puede obtener más efectivamente un soporte ordinario, que no se aplica a Incidentes Mayores.

Pros y contras subacuáticos

La presencia de soporte afecta bastante comprensiblemente el flujo de trabajo . Se distrae y enfurece, porque, por regla general, todos quieren cortar nuevas características. Sin embargo, en cambio, tienes que obtener toneladas de apoyo, estos establos Augean.

Por otro lado, cuando una persona se dedica a un soporte regular, se las arregla para sentir las partes más diferentes del sistema, porque el soporte está estructurado por la criticidad, pero no por los procesos comerciales. Esto le permite aumentar rápidamente la experiencia en el sistema .

¿Dónde conseguirlo todo el tiempo?

La respuesta inicial es: no está claro dónde. Y esto es cierto, porque depende mucho de cada negocio específico.

Lamoda fue organizada por varios directores gerentes, uno de los cuales supervisó TI. Pudo explicar a otros directores gerentes responsables de otras partes del negocio que si creamos un proveedor de servicios y una tienda en línea con nuestra propia automatización y desarrollo interno, es importante aprender cómo negociar con mucha anticipación sobre cómo interactúa el negocio con el departamento de TI. Y también logró transmitir que no debería intentar llenar los sprints con nuevas características en un 80%, sin dejar tiempo para la estabilización, el soporte o la acumulación de problemas. Pudo hacer esto y lograr un resultado.

Sin embargo, entiendo que no todos llegan tan lejos. Es por eso que creo que si aplicamos un enfoque retrospectivo al soporte serio, entonces será posible mostrarle a la empresa cuánto dinero se gasta simplemente porque TI no tiene suficientes recursos y tiempo para resolver problemas internos y obtener soporte.

Punto dulce

Creo que si aplica estos métodos, será más fácil anticipar la aparición de problemas y eliminar sus causas fundamentales y, en general, dejar de pisar el mismo rastrillo y luego alcanzar un estado muy interesante. Esta es una condición en la que cada nuevo tipo de soporte será nuevo para usted. Puede sonar irónico, divertido o lo que sea, pero realmente vale la pena porque comprenderá que no resuelve el mismo problema una y otra vez. Y espero que tengas éxito.