Satisfacción del cliente más allá del entregable

Hace un tiempo comenté que estaba muy contento con mi experiencia como Producto Owner. Dicha experiencia positiva no se debió solamente a que recibí un producto acorde a mis expectativas, sino que también resultó fundamental la forma en que se desarrollo el proyecto. Yo suelo referirme a esto como «experiencia de cliente» y es lo que muchas veces hace la diferencia entre un proveedor de servicios de software y otro. Esta «experiencia de cliente» tiene que ver con cuán fácil le resulta al cliente trabajar con el proveedor y dado que me es difícil dar una definición concreta comparto algunas cuestiones que para mi son importantes para tener una buena experiencia de cliente:

  • El proveedor me da visibilidad contínua del estado del proyecto y los siguientes pasos
  • Cuando tengo inquietudes el proveedor me responde en tiempos razonables para mi negocio
  • El proveedor siempre está bien predispuesto a incorporar el feedback que le doy
  • El proveedor entiende las necesidades de mi negocio y sabe adaptarse a los cambios que este requiere

Todas estas cosas se cumplieron durante el desarrollo de SEAL y por ello mi experiencia como Product Owner fue muy positiva.

Creo que en parte, el haber cumplido con los puntos mencionados tuvo que ver en gran medida con metodologia de trabajo utilizada. Usamos un proceso tipo Scrum con las siguientes particularidades:

  • Iteraciones semanales
  • Una reunión de Demo/Planning semanal, de 1 hora, en la que primero repasábamos el trabajo realizado en la iteración pasada y luego planificábamos la iteración siguiente.
  • Luego de cada reunión de Demo/Planning el equipo enviaba dos mails:
  • Una retrospectiva cada X cantidad de iteraciones para mejorar dinámica de trabajo
  • Todo el tiempo el producto estaba disponible en un ambiente de prueba donde podía entrar a ver/probar funcionalidades
  • Ante cada situación que pudiera implicar un retraso o un desvio de expectativas el equipo me informaba para que tuviera la chance de repriorizar
  • Usamos una herramienta de gestión para administrar el backlog de proyecto
  • Utilizamos burndown charts para tener una visión del estado actual de la iteración y proyectar evolución

Sinceramente me he sentido muy cómodo trabajando de esta forma y por ello espero volver a trabajar así en futuros proyectos.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.