Ya hemos hablado anteriormente de que como profesionales que somos (que no prostitutas) implementar metodologías basadas en el sentido común y las buenas prácticas en nuestro trabajo es muy importante. También hemos hablado sobre el por qué se hace necesario (al menos) escribir y validar casos de uso para tener un escudo ante los temidos poyaques que nuestros clientes lanzan sin piedad contra nosotros.
Así llegamos a la necesidad de escuchar realmente a nuestros clientes para poder comprender su negocio, su mercado, sus inquietudes, sus fortalezas y debilidades y en definitiva, poder ofrecer un servicio personalizado de calidad y no la solución que “más se ajuste según nuestro criterio”.
Hoy vamos a tratar un tema delicado sin duda. El post de hoy trata sobre la importancia de un buen servicio en nuestro trabajo autoempleado. Porque como ya hemos dicho en alguna otra ocasión, un trabajo técnico de calidad, no conlleva necesariamente un servicio de calidad. Si tu cliente siente que no te interesa su problema, que no eres capaz de ver lo singular de su situación y de su negocio, te aseguro que estamos hablando de un cliente perdido, por muy bien que programes en Java y muy chulos que te queden los algoritmos.
Satisfacción, satisfacción, satisfacción
El problema que tenemos muchos profesionales de la consultoría IT y el desarrollo de software es que tenemos un enorme ego. Ese ego tiene un hambre atroz y nos pide pan a cada instante. Nuestro primer instinto —como animales que somos al fin y al cabo—, es el de satisfacer esa necesidad irracional, alimentar nuestro ego, y eso es un grave error, porque no hemos montado una empresa de servicios IT para alimentar nuestro ego sino para ofrecer servicios profesionales a nuestros clientes.
Nosotros conocemos la tecnología, conocemos el lenguaje de desarrollo, conocemos la arquitectura de sistemas, en definitiva, nosotros somos grandes conocedores de la tecnología y la técnica necesaria para concluir con éxito el proyecto del cliente. Lo que nosotros no conocemos en su situación particular, su forma de entender y utilizar la tecnología, sus necesidades, su mercado, sus procesos productivos y de negocio, no conocemos su realidad de negocio y por eso debemos preguntarle, escucharle e incluirle en nuestros procesos productivos como parte fundamental del equipo de desarrollo.
Por norma general, al cliente le importa bien poco si utilizamos .NET, Java, Python, C++ tal framework o tal otro, tal arquitectura de sistemas o tal otra. Lo que al cliente le importa es que resolvamos su problema y no el problema. Porque el problema es genérico, es reproducible, es parametrizable, es automatizable, es procesable, y para resolverlo no es necesario un profesional experto que le asesore. Sin embargo, su problema es algo singular, único, personal, complejo y es necesario que un experto analice la situación de sus procesos y su realidad de negocio para asesorarle en la implementación de la mejor solución posible para solucionar su problemática específica y no en una solución sesgada o impuesta por programas de partnership o fanboyismo hacia tal o cual tecnología.
Por eso somos consultores, por eso somos profesionales, por eso somos expertos. Es necesario dar servicio no solo a la problemática específica de nuestro cliente, sino también al cliente en sí. Un servicio de calidad se consigue aplicándolo al cliente. Implementar una solución es solamente eso, no implica que nuestro cliente haya quedado satisfecho o satisfecha porque su satisfacción no depende solo de la calidad de un trabajo técnico que seguramente ni siquiera comprenda en profundidad.
La fórmula
La satisfacción puede medirse a través de la fórmula: Satisfacción = Percepción – Espectativas. Si el cliente percibe un nivel de calidad en un servicio pero sus espectativas eran superiores o diferentes, tendremos un cliente insatisfecho y hasta es posible que cabreado. Esto se entiende muy bien a través de un sencillo ejemplo:
Supongamos que hemos creado una aplicación a medida para un cliente y hemos sobrepasado el tiempo de entrega porque hemos cambiado en una parte del proceso de desarrollo de una tecnología basada en COBOL (por ejmplo) a otra basada en .NET que aporta unas mejoras considerables y además hemos implementado un algoritmo de la ostia y divino de la muerte para la ordenación de gamusinos salvajes implementando un árbol binario que tal y que cual.
El cliente no entiende la diferencia entre COBOL y .NET, y si se la explicamos hasta que la entienda, no es su problema, él o ella no ha decidido usar una u otra tecnología, tampoco le importa que se haya hecho un algoritmo divino ni en que está basado. Lo que le importa es que ha habido un retraso en la entrega y que la aplicación no cubría la funcionalidad acordada para el mes acordado, sus espectativas eran tener la aplicación en producción para el mes de Julio y la percepción es que no va a poder tenerla hasta Agosto por lo tanto, y aplicando la fórmula satisfacción = percepción – expectativas nos da un resultado negativo.
El primer paso es reconocerlo
¿Y esto de quien es culpa?. Pues es culpa nuestra por no haber sabido escuchar al cliente y haber comprendido realmente sus necesidades. El cliente no necesitaba una aplicación específicamente en .NET, tampoco necesitaba que se implementara un algoritmo de la ostia en su aplicación. Necesitaba que la aplicación cubriera sus necesidades de negocio y su despliegue en la fecha acordada. Obviamente, hemos fallado como profesional porque nuestro ego ha sido más importante que el proyecto y la realidad del cliente.
En algunas ocasiones es posible que el cliente no sea capaz de percibir nuestra excepcional habilidad a la hora de ejecutar nuestro trabajo. O quizás hemos dedicado ingentes cantidades de tiempo a solucionar contingencias que el cliente no es capaz de ver y está enfadado con nosotros en lugar de estar agradecido. Eso ocurre por no implicar al cliente en nuestros procesos y por no conocer en profundidad su problemática, si la conociéramos no habríamos dedicado tiempo a solucionar contingencias porque no debieran haberse producido y de haberlo hecho debieran de haber sido mínimas en un marco de trabajo ágil junto al cliente.
Y esto último no solo se da con clientes poco sofisticados incapaces de entender la complejidad de nuestra labor. También se dan casos de profesionales que están completamente orientados por sus propios valores y ego en lugar de por las verdaderas necesidades del cliente que son apartadas a un segundo plano eclipsadas por la necesidad del profesional de construir un monumento a su propia genialidad y habilidad. Obviamente estas relaciones acaba rotas y es común escuchar por parte de estos profesionales la típica excusa “Podríamos haber hecho un gran trabajo si el cliente no se hubiera metido por medio”.
Existe por tanto una necesidad real de mantenernos centrados en la visión del producto del cliente y no en nuestros propios ombligos, somos asesores debemos comportarnos como tal.
¿Cómo añadir valor a nuestro servicio?
No existen fórmulas mágicas para llegar al éxito, pero lo que está claro es que el éxito de cualquier proyecto IT pasa necesariamente y de forma obligada porque cubra las necesidades reales del cliente y no las nuestras.
Reuniones
Explica claramente y documenta lo que vayas a hacer, asegúrate de que el proceso es entendido por adelantado. Planifica las reuniones por adelantado. Establece un orden del día y unas metas específicas por adelantado y hazlas llegar al cliente. Envía la información relevante por adelantado, informes, gráficas, etc. Utiliza las reuniones para debatir no para presentar informes. Monitoriza los avances de lo acordado en las reuniones conforme se vaya adelantando en el trabajo.
Informes
Asegúrate de que todos los informes, tablas, gráficas, sumarios de progreso, resúmenes, diagramas, casos de uso y demás documentación que generes pueda ser reutilizado por el cliente de forma interna sin necesidad de cambios.
Se accesible, no eres una estrella del rock
Avisa al cliente si no vas a estar disponible por lo que sea. Asegúrate de que todo el mundo en tu organización (si es que tienes una) sabe donde estás y como localizarte en horario laboral. Procura que el cliente se sienta cómodo con otras personas de tu equipo cuando tú no estés.
Comunícate
No le hables en jerga técnica al cliente, ni lo entiende ni le importa. Puedes seguir algunas tácticas para aprender a comunicarte con los clientes ( y con otros seres humanos, que seguro que te viene muy bien :P ):
-
Aprende a convencer no a afirmar
-
Ayuda a los clientes a entender lo que dices y haces
-
Imbuye a los cliente con razonamientos y no con conclusiones, consigue que el cliente llegue a las conclusiones por si mismo
-
Informa al cliente sobre aquello que ellos consideran de mayor importancia
-
Evangeliza a los clientes para que utilicen de forma activa nuestros entregables
Conclusión
Puedes pensar que poner en práctica todo esto es una pérdida de tiempo que te enviará derecho al infierno sin pasar por la casilla de salida, y estás en tu derecho de pensarlo pero, ¿si tú fueras el cliente, te importarían todas estas cuestiones?, ¿te gusta que tus proveedores te traten de manera específica o como a otro elemento facturable más?, ¿crees que alguna de estas cuestiones no es razonable cuando el cliente eres tú?.
La verdad es que a veces el conseguir la excelencia en las relaciones con nuestros clientes es tan sencillo como recordar todo aquello que nos desagrada cuando nosotros somos el cliente y procurar no reproducirlo. Un paso muy importante para llegar a construir relaciones duraderas y estables con nuestros clientes es eliminar por completo todas aquellas necesidades que como único fin persiguen enaltecer nuestro propio ego. Ya tendremos tiempo para eso.
En Genbeta Dev | Trabajar como Desarrollador
