Creemos firmemente en la unión de fuerzas. Al fin y al cabo, se puede aprender mucho de y con los demás. Además, diferentes perspectivas sobre un mismo tema ayudan enormemente a tomar una decisión equilibrada..
El desarrollo y el apoyo son esenciales para ofrecer las mejores soluciones a los clientes
En Easy LMS, el desarrollo y la asistencia son esenciales para ofrecer las mejores soluciones a los clientes. Ya trabajaban juntos, pero eran equipos separados.
Hasta junio de 2021, así es como trabajaban juntos en pocas palabras: simplificado y sin matices ?. Support se encargaba de atender a nuestros clientes lo mejor posible. Pasaban mucho tiempo enumerándoles y ayudándoles a alcanzar sus objetivos de formación. Parte de esto era responder a sus preguntas en el chat o en la demo y registrar sus bugs y peticiones de características. ¡Atarlo y listo! Entonces entraba en escena el propietario del producto. Basándose en la información registrada por los consultores y en su visión del producto, decidía qué característica se construiría a continuación y lanzaba su solución al equipo de desarrollo. Los desarrolladores crearon la solución, rara vez con la ayuda y el asesoramiento del equipo de soporte, y la pusieron en marcha. Por último, los consultores actualizaron todo el contenido relacionado. Listo.
Aprovechar mejor los puntos fuertes del equipo
Como pueden leer, podíamos aprovechar mejor los puntos fuertes de los equipos. Por eso decidimos llevar la colaboración al siguiente nivel. Nació un nuevo equipo: un equipo de resolución de problemas que incluye miembros de desarrollo y soporte. Además, en el equipo participan un diseñador de UX y un Product Owner.
Entrevista con el equipo Jabba
En este momento, tenemos dos equipos de resolución de problemas: el equipo Jabba (el nombre está formado por todas las iniciales de los miembros del equipo) y SummerKnowly (llamado así por nuestra mascota). Anna y Joey son miembros del equipo Jabba. Junto con Caroline, búho de la comunicación, hablan de los detalles de la colaboración mejorada.
Caroline: Desde junio de 2021, tenemos los equipos de resolución de problemas. Anna, ¿puedes explicarnos cómo procesan hoy en día los equipos las preguntas de los clientes?.
Anna: "Soporte sigue procesando las preguntas de los clientes; somos el primer punto de contacto. Les respondemos y les ayudamos. Si un cliente informa de un error, intentamos reproducirlo con ayuda de desarrollo y, si lo conseguimos, lo registramos como error y marcamos la urgencia y el impacto.
Para las solicitudes de características, es lo mismo que para los errores, además del paso de reproducción. Enviamos una solicitud de funcionalidad lo más detallada posible a Productboard, una herramienta que gestiona todas nuestras solicitudes de funcionalidad. Nuestro Product Owner Jeroen y UX Designer & Researcher Dyann las procesan y sopesan y valoran cuidadosamente la solicitud de función en relación con el propósito de nuestra empresa. El resultado es una lista de nuevas funciones por crear".
Caroline: Vale, esto se parece un poco al proceso antiguo; además, hay más comunicación e interacción. Entonces, ¿cuándo entra el desarrollo en el proceso?.
Aportamos diferentes perspectivas
Joey: "En este momento. En lugar del propietario del producto, los equipos son responsables de en qué trabajar y de la solución elegida. De nuestro equipo de resolución de problemas, Anna y yo somos responsables de elegir en qué trabajar a continuación como equipo. Aquí aportamos perspectivas diferentes. Anna sabe lo que necesita un cliente, mientras que yo tengo un buen sentido de la complejidad de una petición".
"Priorizamos los fallos frente a las posibles nuevas funciones y decidimos en qué trabajar en función de la urgencia temporal. Cuando hemos elegido, anotamos la circunstancia actual del problema y el resultado de esa circunstancia, para que el resto del equipo sepa por qué es urgente resolver el problema. A continuación, el resto del equipo entra a discutir la solución y la anota. Dyann, nuestra UX Designer & Researcher, se une a menudo a la conversación para asegurarse de que la solución elegida es fácil de usar y de entender. El debate es valioso por las múltiples perspectivas que aportamos. Todo el mundo puede opinar. Después, enviamos nuestra propuesta al propietario del producto para que la apruebe".
Caroline: ¿Siempre obtienes la aprobación de inmediato?
Joey: "La mayoría de las veces. Si no se aprueba, Jeroen tendrá algunas preguntas que intentamos responder en una convocatoria o en el documento de la propuesta. Hay algunas idas y venidas antes de obtener luz verde. Una vez aprobado, escribimos las historias de usuario (en rojo, una breve explicación escrita de lo que un usuario quiere y espera) y dividimos las tareas entre el equipo.
Caroline: El soporte ¿participa también en la redacción de las historias de usuario? Antes sólo lo hacía desarrollo.
Anna: "Depende de si se trata de una función o de un error. Siempre nos unimos para las nuevas características, para los errores no siempre es necesario. Escribir historias de usuario es relativamente nuevo para nosotros. Así que estamos trabajando para mejorar en ello."
"Lo que también hacemos es empezar inmediatamente a escribir el contenido relacionado para la nueva función. Los contenidos relacionados son las etiquetas para la interfaz del administrador o del participante o los artículos de ayuda. Además, tenemos que decidir qué comunicación con el cliente hay que hacer, como mensajes dentro del producto, mensajes directos al cliente, etc. Esto lo hacemos al mismo tiempo que se crea la función". Esto lo hacemos al mismo tiempo que se crea la función".
Caroline: Entonces, el principal cambio es que el soporte y el desarrollo eligen un problema y elaboran la solución juntos. Ambos tienen más influencia en el resultado final. ¿Cómo vive este nuevo proceso de trabajo?
Anna: "Sin duda fue un cambio acostumbrarse al nuevo estilo de trabajo en cuanto a horarios y a trabajar codo con codo con gente nueva. Lo que también fue una ventaja. Me gusta trabajar más estrechamente con los desarrolladores porque tienen perspectivas diferentes sobre qué construir y por qué. Ahora tomamos decisiones más equilibradas. Además, nos ayuda ver cómo trabajamos los unos de los otros. Antes, nos acomodábamos los problemas. Hacíamos más trabajo manual, y eso se convirtió en la norma. Los desarrolladores se dan cuenta fácilmente de si el trabajo manual puede automatizarse o racionalizarse. Está en su naturaleza pensar así. Su ayuda nos ha ahorrado ya mucho tiempo".
Ahora tenemos mucha más información sobre lo que está ocurriendo realmente
Joey: "Ahora tenemos mucha más información sobre lo que ocurre realmente. Cómo utilizan los clientes nuestro LMS, qué es importante para ellos y el razonamiento que hay detrás. Parece que estamos más en contacto con las necesidades del cliente. Antes, un problema nos llegaba después de haber pasado por varios niveles de la empresa. Estábamos al final del proceso, por lo que mucha información esencial se perdía por el camino, y muchas preguntas no se hacían. Conocemos mucho mejor el sistema desde el punto de vista técnico y abordamos los problemas de forma diferente. Contar con apoyo desde el principio nos permite hacer las preguntas que necesitamos para construir una solución eficaz y sostenible. Podríamos decir que se ha cerrado la brecha informativa".
Caroline: También estamos haciendo entrevistas a los clientes para entender mejor sus necesidades. Supongo que esto es muy valioso para el equipo de resolución de problemas?.
Joey: "¡Sí, lo es! Porque lo que los clientes quieren no siempre es lo que necesitan. Lo que creen que va mal no siempre es lo que hay que arreglar. Es muy difícil verlo desde fuera. Así que las entrevistas con los clientes son una herramienta valiosa para revelar los problemas subyacentes. También nos dan contexto".
Se comparten muchos conocimientos
Caroline: Bien, volvamos a la colaboración entre desarrollo y soporte. Cómo se complementan entre sí?.
Anna: "Se comparten muchos conocimientos. Además de que los consultores aportan la perspectiva del cliente, ambos sabemos cosas distintas sobre el LMS. Esto hace que a veces nosotros sepamos cómo funciona la herramienta y ellos no, y viceversa. Así, por ejemplo, algo es totalmente obvio para nosotros (rojo. soporte), mientras que los desarrolladores no pensaban que funcionara así o que la gente utilizara una función de esa manera. Del mismo modo, podemos pasar veinte minutos replicando un error, y si envío un mensaje sobre ello a un desarrollador, éste conoce la solución al instante. Así que hay un poco de eso en ambos lados, y ahora podemos compartirlo".
Caroline: ¿Hay algún inconveniente también en trabajar de esta manera?
Joey: "No, aunar desarrollo y soporte ha sido un buen paso. En general, cambiar de método de trabajo siempre tiene sus inconvenientes. Hay que acostumbrarse y eso puede generar frustraciones. Lleva tiempo. Pero son obstáculos que hay que superar. No es un impedimento. No queremos volver atrás".
Caroline: Puedes dar más detalles. Qué fue lo más difícil?
Joey: "El mayor reto fue averiguar cómo podíamos utilizar los puntos fuertes de cada uno de la forma adecuada y no hacernos perder el tiempo. Al principio, muchas veces había demasiada gente en las reuniones que no podía contribuir al debate. Era una pérdida de tiempo. Pero también ocurría lo contrario. Tuvimos las llamadas reuniones mis. La gente podría haber contribuido pero no estaba allí. Al final, nos las arreglamos comunicando nuestras experiencias y aplicando el método de ensayo y error".
Caroline: Anna, ¿qué aprendiste de los desarrolladores de tu equipo?
Aprendí a estructurar mejor mi trabajo diario con menos interrupciones
Anna: "Es difícil de decir. Es broma. En primer lugar, a un nivel más filosófico, el trabajo de los desarrolladores está mucho más estructurado que el trabajo de soporte. Aprendí a estructurar mejor mi trabajo diario con menos interrupciones. Los desarrolladores son muy estrictos con su tiempo, lo cual es lógico porque necesitan tiempo ininterrumpido para hacer su trabajo; ver eso me ayuda a llevarlo a mi jornada laboral. Así que aprendí a controlar mejor mi tiempo y mis límites. Luego, más en la práctica, los desarrolladores me dan muchos consejos para solucionar problemas y ayudar a los clientes".
Caroline: Y a cambio, Joey, ¿qué aprendiste de los asesores de apoyo de tu equipo?.
Joey: "Creo que es lo contrario de lo último que acaba de decir Anna. Siempre hemos tenido muchas ideas de cómo arreglar las cosas; lo único que podíamos hacer era confiar en nuestros conocimientos. Pero no utilizamos el sistema como lo hacen los clientes. Así que, al interactuar con el servicio de asistencia, aprendimos mucho sobre cómo utilizan realmente el sistema los clientes y qué soluciones les convienen. Antes nos limitábamos a adivinar y a hacer lo mejor que podíamos. Implicamos más la perspectiva del usuario final en lo que hacemos. Podemos imaginarnos mejor su situación".
Caroline: ¿Cree que ahora construimos mejores soluciones para nuestros clientes?
Joey: "¡Sí, sin duda! Un buen ejemplo de ello es nuestro sistema de pago totalmente nuevo."
Caroline: Como empresa, estamos continuamente mejorando y cambiando. Pero, después de ocho meses, ¿se siente cómodo con el nuevo proceso de trabajo?.
Anna: "Al principio, no estaba segura de cómo podía contribuir. ¿Realmente necesito estar aquí? ¿Cuál es mi valor? ¿Cuál es la razón de que esté aquí? Al menos, en esa parte, ahora tengo mucha más confianza. Veo que tengo valor y que tengo un sitio en el equipo".
