El Bruno

Hola!

Ayer quedó claro que, si queremos tener resultados visibles, la primera distinción que debemos realizar no tiene que estar orientada hacia la tecnología (o arquitectura o roles de desarrollo) sino al contexto donde se creará la solucion; este contexto está formado por customers y por el equipo de trabajo. Una parte muy importante de la misma son los clientes o customers.

Ojo, no debemos confundir a estos roles con el Product Owner que conocemos de SCRUM. Según la guía el PO es el principal autor de las User Stories, maneja el Product Backlog, define la prioridad de las historias, define los tests de aceptación y aprueba el trabajo realizado por el Agile Team. Sin embargo, ese no es el “cliente”; el verdadero cliente es el que en un estadio inicial detecta un problema o necesidad y es el que utilizará la solución final creada por el equipo. En un Agile Team es muy importante involucrar a una persona con los conocimientos de negocio desde el día cero, pero siempre queda la pregunta: ¿es esta persona un real reflejo de un cliente?

Nota: Mi corta experiencia me ha enseñado que cuando más tiempo trabajamos con estos expertos de negocio, más comenzamos a conocer el negocio y podemos mejorar nuestra solución. La contrapartida es que estos SMEs también comienzan a conocer como funciona un Agile Team y se van adaptando a las prácticas del equipo. Esto no es malo, sin embargo puede resultar contraproducente si no se valida con los demas “clientes”.

La solución para conocer a un cliente final, no pasa por involucrar a todos los clientes dentro del equipo de desarrollo, pero si planificar algún tipo de actividad para obtener feedback de los mismos. El concepto de Agile Customer implica que trabajemos de forma parcial con un On-Site Customer (que a la larga se termina convirtiendo en el Product Owner y si tienes mucha suerte este trabajo no es en forma parcial sino full time). Como un adicional a este concepto me gustaría agregar las siguientes actividades

• En una Sprint Review, no solo incorpores las caras conocidas del proyecto; intenta involucrar a nuevas personas. En una reunión previa o al principio de la reunión, dedica un tiempo para explicarle el objetivo del Sprint Review y la dinámica de trabajo; e intenta obtener su feedback durante el mismo.
• Recuerda las 2 premisas fundamentales relacionadas con el trato con los clientes

• NO IMPLEMENTES NADA que no haya sido aprobado por un cliente
• NADIE puede sustituir a un usuario final de la aplicación

Para finalizar recuerda que si bien el cambio es una constante, una versión cerrada depende mucho de la capacidad que tengamos de manejar las expectativas de nuestros clientes. Se honesto y la solución seá un éxito.

Referencias: Si quieres saber más sobre Microsoft Feedback Client puedes ver mis posts aquí.

Saludos @ La FInca

El Bruno

Google