En lo relativo al soporte post-venta, hay fundamentalmente dos tipos de empresas TIC: las que planean dar un soporte fanático y las que planean no dar ninguno en absoluto.
Las empresas que se decantan por el soporte fanático buscan la lealtad de sus clientes: que renueven siempre sus contratos y que hablen bien de la empresa a otros clientes potenciales; mientras que las empresas que pretenden no dar soporte buscan el máximo de rentabilidad por operación. No está demostrado, en mi opinión, que invertir en la relación a largo plazo con el cliente sea siempre la mejor opción. Los bancos y las telcos casi invariablemente trabajan sólo la relación a corto plazo y obtienen pingües beneficios sostenidos en el tiempo con esa política, no sé si gracias a sus oligopolios o a que los clientes también buscan casi siempre la mejor oferta a corto.
El soporte de calidad es muy costoso y a menudo difícil de facturar con buen margen. Por consiguiente, no es de extrañar que muchos emprendedores pretendan posicionar su start up en el grupo de las empresas que no dan soporte. Por desgracia para estos emprendedores, muchos de ellos también pretenden seguir una metodología lean y empezar con un mínimo producto viable. Y si el producto es lean entonces (asumámoslo) será también al menos un poco crapy y, por consiguiente, todo lo que se ahorre en desarrollo inicial se pagará después en soporte, es decir, el lean es sólo una forma de diferir el gasto, lo cual no es necesariamente malo (sobre todo cuando no se dispone de caja al principio) siempre y cuando se sea consciente de la cantidad de deuda técnica que se va acumulando. Y me gustaría ampliar el concepto de deuda técnica no sólo a lo que los agilistas entienden por ella sino también al conjunto de cosas que el producto debería hacer y no hace, definiendo «cosas que debería hacer» como que si le hechas una moneda a la máquina expendedora te entrege tu lata de Coca-Cola sin necesidad de que llames al de soporte para que le dé dos patas que hagan caer la lata del dispensador.
Metodologías Oficiales
Para los más puristas, las metodologías oficiales de servicio post-venta son el libro de soporte de servicio de ITIL e ISO 20000, aunque a menos que uno haya sido condenado a largos años de prisión sin nada mejor que hacer que leer, o la empresa pague curso para escaquearse una semana del trabajo, yo no le recomiendo a nadie que empiece por ahí.
Desconozco si existe algo similar a Agile para el soporte post venta. De manera que tendremos que ir improvisando. Aunque lo que sí puede encontrarse con facilidad son decenas de sistemas para la gestión de tickets de soporte tanto Open Source (Bugzilla, Redmine, Trac) como SaaS (Zendesk, JIRA). JIRA tiene muy buenas integraciones tanto con SaaS para Git como con productos de monitorización estilo Sentry, pero las herramientas podrían merecer un post entero sobre sus funcionalidades, de modo que aquí no me voy a detener en ellas, sino que haré un resumen de lo esencial a tener en cuenta cuando se organiza el soporte con independencia de la herramienta que se use.
Capas de soporte
Lo habitual es tener al menos dos capas del soporte: el que prestan los técnicos de soporte y el que prestan los desarrolladores.
Dependiendo de la cantidad de clientes que tenga la empresa, las incidencias pueden agruparse por proyecto, por cliente, por nivel de servicio contratado (silver, gold, etc.) o por el número de ocurrencias de la misma incidencia durante un intervalo de tiempo.
Es necesario que los programadores tengan un porcentaje de su tiempo destinado a corregir bugs. En una empresa sin un producto maduro, este porcentaje puede ser tanto como un 40% del tiempo. «Maduro» significa que el producto tiene al menos 4 años de vida y es estable sin necesidad de ninguna intervención a menos que se produzca un fallo en el hardware o en la red.
La clasificación de incidencias en dos «torrentes»: el torrente del departamento de servicio post-venta, y el «torrente» del departamento de I+D es de especial importancia en las empresas que venden SaaS pues en estas compañías no existe una relación directa entre la estructura coste del servicio y el esquema de facturación a los clientes. Por ejemplo, si se tienen 30 técnicos de soporte, 30 desarrolladores y 250 clientes todos en SaaS en fácil perder la cuenta de cuánto tiempo están dedicando realmente los desarrolladores a mejorar el producto versus cuánto tiempo están dedicando a corregir errores o implementar funcionalidades no facturables, o interesantes únicamente para un cliente, que sólo hacen el producto más costoso de mantener pero no más rentable a largo plazo.
Acuerdos de nivel de soporte
Las empresas que proporcionan servicios de pago están sujetas a acuerdos de nivel de servicio SLA (Service Level Agreements). El SLA dice básicamente que ante una incidencia X el proveedor responderá en un tiempo T y destinará los recursos R a la tarea.
Es importante recalcar que el SLA lo que garantiza es una respuesta y no una solución en un tiempo máximo.
Mi recomendación es que (a falta de requerimientos específicos del cliente) el SLA del soporte de primer nivel incluya sólo cuatro niveles de incidencias:
Crítica: El proveedor responderá en un máximo de 15 minutos.
Urgente: El proveedor responderá en un máximo de 2 horas.
Importante: El proveedor responderá en un máximo de 24 horas.
Media: El proveedor responderá en un máximo de 72 horas.
Qué, básicamente, se corresponden con lo que vas a hacer ahora mismo, lo que vas a hacer hoy antes de irte a casa, lo que puedes dejar para mañana, y lo que puedes dejar para la semana próxima. La existencia de una prioridad baja a mi personalmente no me parece conveniente ya que a nadie le gusta que le atiendan con baja prioridad ¿no?
Con respecto a los tickets del soporte de segundo nivel prestado por los desarrolladores, mi consejo es que se organicen los niveles de prioridad bien del 1 (ahora mismo) al 100 (cuando el infierno se congele) bien sin prioridades y sólo por sprints. El motivo es que es habitual que un programador tenga entre 10 y 40 tareas pendientes simultáneamente. Luego la disponibilidad de un rango amplio de prioridades permite a los gerentes y técnicos de soporte ver con claridad qué estará haciendo el desarrolador en el futuro próximo. Alternativamente, o complementariamente, cada tarea se puede asignar a un sprint o (si es muy urgente) a un parche (hotfix). Con sprints cada dos semanas pues lo que sabe el observador es si una determinada funcionalidad o corrección estará disponible tras el sprint del próximo viernes o tendrá que esperar dos semanas adicionales a menos que consiga meterlo en un parche urgente.
La asignación de prioridades a las incidencias debe hacerse siempre desde la óptica de los daños que está causando en el cliente y no desde la óptica de cuán grave es del desarrollador. Esto lo puedo ilustrar con un ejemplo reciente: desde hace meses teníamos un sistema en funcionamiento para la gestión de órdenes de compra, uno de los campos de estas órdenes es el código aduanero, este código aduanero no estaba siendo rellenado por el sistema pero, por casualidad, todos los usuarios sólo hacían compras domésticas ergo no necesitaban dicho código, hasta que un día vendimos el uso a un cliente y sus proveedores que hacían órdenes de compra internacionales, inmediatamente llegó un reporte de error que decía «el código aduanero no está siendo rellenado», revisamos el sistema y encontramos que el error era cierto pero, como llevaba sin funcionar desde el principio de los tiempos, no le dimos importancia al hallazgo; en pocos días empezaron a acumularse cetenares de órdenes de compra que no podían despacharse por falta del código aduanero, y para cada órden de compra el proveedor y el cliente tenían que comunicarse el código por email o por teléfono, lo que generaba horas perdidas entre el cliente y sus proveedores para rellenar un campo que debería estar en el sistema desde el principio, la moraleja es que lo que desde el equipo de desarrollo se veía como un nimio mal funcionamiento para el cliente era un error gordísimo que había que corregir perentoriamente.
Devops
En teoría, la correción de bugs debería ser siempre más prioritaria que la introducción de nuevas funcionalidades. En la práctica lo que sucede es que a menudo algunos desarrolladores son considerados (erróneamente) como demasiado valiosos para que pierdan el tiempo corrigiendo bugs. Esto es un error, y, de hecho, en las grandes empresas como Microsoft, Google o Facebook se penaliza mucho más la introducción de bugs de lo que se premia una brillante productividad, y, además, el que lo rompe lo arregla. La pega de este sistema es que los programadores pueden argumentar que no produjeron los story points del sprint porque estaban corrigiendo bugs o, inversamente que no pudieron corregir los bugs porque tenían que entregar los story points.
Si no es el caso que cada programador tenga que arreglar siempre los errores que haya introducido entonces mi opinión es que lo mejor es organizar grupos de DevOps (development & operations) en los cuales un grupo de programadores presta el soporte de segundo nivel y otro se encarga de los nuevos desarrollos. Si la empresa es lo bastante pequeña es bueno que los turnos de devops sean rotativos de manera que nadie se acostumbre a no innovar ni desarrollar nada nuevo ni tampoco sólo a desarrollar sin sufrir nunca las consecuencias de la falta de cuidado programando.
Monitorización
Cualquier sistema cuya misión sea otra que la de matar a los técnicos de soporte de un infarto debe contar con sistemas de monitorización. La monitorización debe ser de dos tipos: pasiva y activa.
La monitorización pasiva consiste en alertar de errores que se han producido. Por ejemplo, cuando salta un error 500 en una página web, o el servidor de repente no es accesible o falla una transacción de escritura en la base de datos.
La monitorización activa consiste vigilar que el sistema se está comportando con normalidad. Por ejemplo, que el número de páginas servidas por minuto se mantiene dentro de un rango, pues lo contrario podría indicar un ataque o un fallo en algún DNS que impide alcanzar el servidor. O contar el número de pedidos que se han enviado a cada dirección postal en la última semana por si alguien está haciendo compras fraudulentas.
Gestión Emocional del Cliente
En la teoría, las herramientas deben permitir que el proveedor mantenga una conversación con el cliente a lo largo del tiempo con independencia de quienes sean los interlocutores de las partes. En la práctica es mejor asignar algo así como el «técnico de soporte de cabecera» del cliente de manera que los interlocutores de las partes se conozcan y estén acostumbrados a trabajar juntos. Según todos los estudios la mayoría de los clientes prefieren el soporte telefónico. Yo personalmente lo detesto como usuario, pero debo ser la excepción que confirma la regla. Lo fundamental para gestionar al cliente es que no se sienta nunca abandonado. Si abre una incidencia crítica hay que responderle inmediatamente aunque sólo sea para decirle «OK, estamos en ello…» y si tiene una incidencia abierta que se está demorando también hay que llamarle para informarle de que se sigue trabajando en ella aunque no se haya producido ningún avance significativo.
Algunos gurús del CRM afirman que los clientes quieren soluciones, no explicaciones. En mi experiencia, esto, en general, no es cierto. Los clientes pueden tolerar muchísimo más los errores y las deficiencias en el servicio si entiende la causa de ellos. Y, aún más que eso, los clientes veteranos en comprar servicios TIC no sólo quieren saber por qué sucedió algo sino también las medidas que se van a adoptar para que no vuelva a suceder en el futuro.
Métricas
El tratamiento estadístico de defectos software es una ciencia en sí misma con estándares como ISO/IEC 25010 o IEEE 1061-1998. Aquí sólo voy a repasar lo esencial que debe contener un cuadro de mando con KPIs de métricas de soporte.
Se deben recoger tres tipos de métricas: financieras, operativas y de satisfacción del cliente. Voy a omitir algunas métricas clásicas en atención al cliente que no son propiamente aplicables a empresas TIC tales como el número de incidencias entrantes por canal o la tasa de clientes que cuelga el teléfono antes de ser atendidos por un técnico. Si la empresa es de las que aspira a no prestar ningún soporte en absoluto entonces el objetivo es que el cliente se resuelva él mismo la incidencia y se miden cosas como cantidad de veces que el cliente fué capaz de encontrar una solución mediante el uso de un buscador o inteligencia artificial, yo personalmente detesto cuando intento hablar con un humano y me contesta R2D2, de modo que ni voy a comentar las métricas de calidad de los agentes robotizados de soporte, si la empresa aspira a no prestar soporte entonces es que en primer lugar el cliente no debería estar en necesidad de buscar ninguna ayuda.
• Margen: Diferencia entre ingresos y gastos por soporte.
• Coste de la mano de obra: Coste salarial por hora multiplicado por número de horas imputadas al soporte.
• Incidencias por unidad de tiempo: Es normal que a medida que la empresa crece crezca también el número de incidencias de primer nivel (cosas del estilo «he perdido mi contraseña» etc.) lo que no debe crecer al mismo ritmo son las incidencias que traspasan el primer nivel y llegan al segundo pues esto indica que el producto se está volviendo imposible de mantener. El número de incidencias por unidad de tiempo, en general, se puede decir que será igual o superior al período de tiempo inmediatamente anterior. Es decir, sin en una semana se han descubierto 30 bugs entonces hay que presuponer que en la siguiente se encontrarán 30 más.
• Nuevas incidencias por release: Correlacionadas con los story points de manera que se aprecie cuantos bugs por story point se han introducido en cada release. Ya lo he comentado al referirme a la métrica de incidencias por unidad de tiempo pero es tan importante que lo repetiré: la tendencia en el número de incidencias de segundo nivel por release debe ser decreciente, lo contrario significa que se está dirigiendo el desarrollo del producto hacia una situación que lo hará imposible de mantener.
• Grado de cumplimiento del acuerdo de nivel de servicio: Porcentaje de incidencias que se respondieron dentro de los límites de tiempos según su prioridad fijados por el SLA.
• Incidencias resueltas en el primer contacto: Es decir, aquellas para las que el cliente obtuvo una solución exitosa en la primera respuesta que se le proporcionó.
• Incidencias no resueltas acorde a su severidad: Aunque el SLA no lo especifique, debe existir una cota máxima de tiempo interna para resolver cada incidencia según su severidad.
• Tiempo medio de resolución: Para aplicar esta métrica conviene eliminar las incidencias resueltas en el primer contacto y las incidencias no resueltas acorde a su severidad para no distorsionar la media.
• Tasa de conversión de las incidencias de nivel 1 en incidencias de nivel 2: Esto mide la calidad de las herramientas de que disponen los técnicos de soporte las cuales les permiten solucionar el problema del cliente sin necesidad de perturbar al equipo de desarrollo.
• Número de incidencias abiertas por técnico: Se cuentan sólo las que están abiertas, no las totales, como una medida de cuántas tareas simultáneas debe realizar cada persona.
• Número de incidencias abiertas por cliente: Permite relacionar el nivel de ruido causado por un cliente con la cantidad de dinero que está pagando por el soporte.
• Grado de satisfacción del cliente con el servicio: Se suele obtener mediante una breve encuesta realizada tras el cierre de la incidencia estilo «En una escala del 1 al 10 usted ¿cómo valoraría la calidad del soporte recibido?».
Pingback: Muerte por agilismo | La Pastilla Roja