Scrum – Comparte tu Backlog con el Cliente

Los mayores problemas que se producen en la gestión de proyectos se dan en el flujo de información, ocurre muchas veces que esta se tergiversa cuando pasa entre las diferentes personas que trabajan en el proyecto y al final se desarrolla algo que muchas veces no ofrece una solución para el problema presentado por el cliente. Esto hace que la relación con tu cliente se degrade y al final tu proyecto se demore haciendo que este tenga un mayor sobrecoste y perjudicando tu relación con el cliente.

Creo que todos conocéis la graciosa imagen que representa esto:

clip_image001

Un problema habitual se origina en el control de la entrada de información. Se dice, que normalmente debe existir una sola persona que trate con el cliente, yo pienso que esto es algo complicado de gestionar, sobre todo en grandes proyectos, en los que participan muchas personas, pues el cliente a veces, prefiere tratar con miembros del equipo de desarrollo con los que ha tenido mayor relación, con lo que la entrada de información puede originarse a través de los diferentes miembros del equipo y de esta forma las alteraciones con seguridad serán mayores, pues cada uno tendemos a interpretar la información a nuestra manera. Cuanto mas cercano se encuentra el equipo con respecto al cliente y mayor número de personas participan en el proyecto más difícil es controlar esta entrada de información.

Yo creo que la información debe introducirse solo por un sitio, y a ser posible sin interaccionar con más personas, para evitar filtros, modificaciones o interpretaciones personales y que esta sea fiel reflejo de los pensamientos del cliente, inclusive si esta presenta algún error para que posteriormente pueda ser analizada por todo el equipo. Pienso que debemos huir del pensamiento de que sea una sola persona la que hable con el cliente, que procese, filtre y finalmente traslade la información al equipo de desarrollo. Esto traslada toda la responsabilidad a una sola persona que puede cometer errores en la planificación y el diseño, al no contar con información relevante de otros miembros del equipo de desarrollo que seguramente conozcan a fondo áreas del cliente en las que han estado trabajando. Creo que deber ser el equipo al completo, el que analice la información y tome las decisiones en conjunto pues entre todos contaremos con una visión general mas completa para resolver el problema.

A veces el cliente llama directamente o la persona encargada del proyecto habla con el personalmente, el cliente traslada cualquier problema o necesidad con una prioridad determinada para resolverla. En este caso se producen varios problemas adicionales:

– Por un lado el cliente interrumpe el trabajo que estas haciendo y aquí se producen las mayores pérdidas de productividad, porque estas interrupciones nos obligan a veces a dejar tareas importantes. haciendo que la productividad decaiga en picado, no solamente se pierde el tiempo de la interrupción, si no que después obliga a que la persona tenga que volver a concentrarse para poder continuar el trabajo que estaban realizando. Debemos intentar eliminar estas interrupciones, cuando veo equipos de desarrollo en los que habitualmente hay una o dos personas hablando constantemente por teléfono suelo pensar que las cosas se están haciendo mal. Debemos eliminar estas interrupciones, las reuniones de scrum están para algo y debemos tratar de minimizar las conversaciones con el cliente, sobre todo aquellas que son por teléfono y que no quedan debidamente registradas o pueden sufrir diferentes interpretaciones y que además, afectan al rendimiento de las demás personas del equipo que se encuentra en el mismo entorno. Pienso que una buena solución aunque a algunos les suene un poco radical es simplemente descolgar el teléfono y bloquear las entradas de información como skype, en nuestro caso intentamos centrarnos solo en el email que nos permite estar al tanto de cualquier incidencia urgente que requiera una atención inmediata, las conversaciones con un cliente no aportan absolutamente nada, la información no queda registra y esta normalmente llega alterada al repositorio, lo que si puede aportar valor como veremos mas adelante es un diálogo con un cliente que quede registrado en el sistema y que no obligue a ninguna de las dos partes a interrumpir su trabajo.

– Puede ser además, que cuando el cliente llame le atienda una persona que no conozca a fondo su contexto de trabajo y de esta forma no sepa captar adecuadamente sus necesidades trasladando información incompleta o errónea al equipo de desarrollo.

– La información que nos traslada el cliente no queda registrada, con lo cual nunca sabremos si esta ha sufrido alguna alteración, es importante que todos los diálogos sobre un ítem determinado queden registrados y esta información sea accesible tanto por el propio cliente como por los miembros del equipo de desarrollo.

– Por otro lado a veces el cliente establece una prioridad determinada abduciendo que la necesidad es urgente y prioriza tu trabajo, de manera que esto nos obliga a dejar de lado aquello que estamos haciendo, para solucionar el problema lo antes posible, dejando aquello que teníamos planificado y que a veces puede tener una mayor prioridad.

– Muchas veces, parte del equipo de trabajo no cuenta con esta información a tiempo, ya que se comienza a desarrollar mucho antes de que el equipo pueda evaluar su solicitud. En estos casos a lo mejor no conocemos toda la información necesaria y ofrecemos una solución errónea debido a dependencias desconocidas y hacemos algo que debería haber sido correctamente planificado y estudiado.

Este y otros problemas son derivados del flujo de información y se convierte en una de las principales causas por la que muchos proyectos fracasan.

Una solución que a nosotros nos ha funcionado muy bien es la de intentar trasladar y compartir el backlog del proyecto con el cliente, con ello evitaremos la mayoría de estos problemas y lograremos varias ventajas:

– Se minimizan las interrupciones: Ya no tenemos que atender al cliente por teléfono o skype cada vez que nos llame, podemos visualizar las incidencias y requisitos que van llegando y pararnos solo si detectamos que estas requieren una atención inmediata, de esta forma podemos trabajar sin constantes interrupciones, el cliente también se beneficia del mismo sistema de trabajo, si tenemos que realizar alguna pregunta sobre un requisito en concreto utilizaremos el mismo sistema de dialogo con el, evitando interrumpirle en su trabajo y minimizando nuestro tiempo para contactar con el.

– Registro del flujo de información: Por un lado tanto el cliente como el equipo son los que escriben la información y esto queda registrado, con lo que evitaremos las alteraciones en la información cuando las filtra cualquier persona que hace de intermediario.

– Una mejor información disminuye los tiempos de desarrollo: Muchas veces una llamada no es suficiente para describir adecuadamente un problema, si el sistema de gestión del backlog permite adjuntar archivos, el cliente puede fácilmente introducir un documento, un gráfico o cualquier tipo de información que considere de interés para facilitar su comprensión, esto facilita mucho que la información este localizada en un lugar determinada y que el equipo entienda el problema adecuadamente evitando que perdamos el tiempo buscando o intentando entender mejor el proceso.

– Seguimiento del proceso: El cliente puede conocer en tiempo real la situación de su incidencia, mejora o el desarrollo de una nueva funcionalidad que haya solicitado, pudiendo además obtener información adicional, fecha de planificación, personas que lo desarrollaran, estado actual, etc, etc. Esto es muy importante pues evita constantes interrupciones con preguntas del tipo: ¿Ya has terminado aquello?, ¿Por qué no se ha hecho? ¿Qué problemas habéis tenido en el desarrollo?, de esta forma el cliente tiene constancia de las incidencias que ocurren, puede ocurrir que el desarrollo de un módulo tal y como propone el cliente afecte a otros módulos que el desconoce y es importante que si no se realiza como él ha solicitado pueda conozca las causas o los motivos por los que se ha realizado de otra manera.

– Por otro lado esta información va quedando almacenada en un histórico, de manera que otros usuario pueden acceder a esta información sobre problemas que ya tienen una respuesta determinada. Este debería ser un proceso que el cliente debe hacer antes de introducir una nueva incidencia, de manera que pueda beneficiarse de soluciones que ya hayan sido realizadas obteniendo una respuesta inmediata evitando requerir al equipo de trabajo.

– La información fluye hacia todos los miembros del equipo: Esto es fundamental en un equipo de desarrollo, algunos miembros del equipo desconocen como se han desarrollado otros módulos y las dependencias entre ellos, todo el equipo debe conocer el trabajo de los demás para así poder ofrecer la información relevante a otros miembros del equipo que la desconocen y lograr la solución mas adecuada.

– Filtrado de información: Normalmente no nos interesa compartir toda la información con toda la gente que participa del proyecto, nuestro sistema permite compartir solo aquellos ítems que deseemos con determinadas personas que trabajan en el cliente, de manera que el director financiero quizás no quiera visualizar información que solo es relevante para el responsable de nóminas, es importante que podamos controlar con quien queremos compartir esta información, no todas las personas que trabajan en el proyecto necesitan estar informadas de todos los aspectos de este. Con lo que logramos que la información fluya solo a aquellas personas relevantes evitando sobrecargar de información a otras que no la necesitan.

– El sistema de alerta nos avisa de cualquier incidencia urgente: Es importante que existan ciertos mecanismos que nos permitan notificar rápidamente una incidencia urgente, que se bloquee un servidor de BD requiere atención inmediata, nuestro sistema de alertas a través de email hace que estemos informados en tiempo real de cualquier incidencia grave y esto nos permite reaccionar con rapidez.

– El equipo de desarrollo planifica y prioriza: Somos nosotros los que debemos priorizar, no el cliente, el cliente no tiene toda la información relevante del desarrollo del proyecto y el equipo si, muchas veces ocurre que para el cliente es muy importante la realización de una tarea en concreto, pero en el proyecto pueden existir otras tareas que tengan una prioridad mayor, con un backlog compartido podemos cambiar la prioridad y notificar al cliente del porqué de estas decisiones, para justificar y hacerlo participe de nuestro trabajo.

Voy a poner un ejemplo de un ítem de un backlog para ver su funcionamiento, en este caso hemos implementado un pequeño programa para realizar esta operación, que notifica de forma automática a los usuarios a través del correo electrónico de cualquier cambio en el backlog, he leído en alguna parte que en la nueva versión del TFS, esto va a ser posible, seguro que El bruno puede avanzarnos algo sobre este tema.

1º – El cliente notifica un nuevo ítem.

Código: 4212 Fecha: 12/07/2012 9:12 Prioridad: Urgente

Usuario: Jose Angel García (Cliente – Agente comercial)

Descripción: Necesitamos que en el informe de facturación aparezca el número del agente de aduanas. Te adjunto un pdf con el informe de la factura para que veáis como debe quedar.

2 º – Hemos recibido su notificación con fecha 12/07/2012

3º – Respuesta de Ana Martínez (Responsable del proyecto) a la notificación nº 4212 el día 13/07/2012 10:00

La propuesta indicada será realizada por Julio Otero (Desarrollador).

Uno de los miembros del equipo comenta que las facturas pueden contener varios albaranes y estos podrían utilizar un agente de aduanas diferente, como procedemos en este caso.

4º – Respuesta de José Ángel García (Agente comercial) a la notificación nº 4212 el día 12/07/2012 11:45

Este caso no se puede dar, ya que antes de hacer la factura se comprueba que todos los albaranes tengan el mismo agente de aduanas, si existiesen albaranes con diferente agente se generarían varias facturas.

5º – Respuesta de Ana Martínez (Responsable del proyecto) a la notificación nº 4212 el día 12/07/2012 12:25

Bien, en este momento no podemos hacerla pues existen dos incidencias prioritarias que debemos resolver antes, cambio la fecha de planificación para el día 16/07/2012, para salir del paso podéis editar el PDF de la factura e introducirlo de forma manual.

6º – Respuesta de Julio Otero (Desarrollador) a la notificación nº 4212 el día 17/07/2012 10:25

La notificación 4212 ha sido resulta, te envió el pdf adjunto para que verifiques si todo esta correcto.

7º – Respuesta de José Ángel García (Agente comercial) a la notificación nº 4212 el día 17/07/2012 11:00

             Lo he verificado y funciona correctamente.

8º – Cerrada la notificación número 4212 por José Ángel García (Agente comercial)

De esta forma la información fluye sin que tengamos que controlar por donde entra y quien la procesa, ya que existe un solo punto de entrada (la aplicación que permite acceder a nuestro backlog), se disminuyen las interrupciones ya que no tenemos que hablar directamente con el cliente, la información sobre los cambios se distribuye de forma automática notificando al cliente por email de cualquier cambio que se produce, nos permite planificar y cambiar la prioridad de la tarea y estudiar mejor los cambios a aplicar, es el cliente quien escribe sus necesidades, y estas no se tergiversan, el registro guarda la información tal y como el cliente la ha introducido, el equipo trabaja como un conjunto en la planificación de tareas y la corrección de errores evitando errores en el diseño por el desconocimiento de las dependencias y ofrece entre todos sus miembros una solución mas adecuada y el sistema de alertas notifica en tiempo real de cualquier incidencia grave que pueda surgir para permitirnos reaccionar con rapidez.

He puesto Scrum porque es la metología que utilizamos, pero creo que este sistema de trabajo es trasladable cualquier metodología Ágil, si habéis llegado hasta aquí, espero vuestros comentarios.

2 comentarios sobre “Scrum – Comparte tu Backlog con el Cliente”

  1. En este post yo hablo del backlog por que entiendo que en el backlog se introducen todas las tareas, no solo las procedentes de historias de usuario, que en principio podrían ser mas o menos sencillas y que podrían descomponerse en pequeñas tareas que conforman el backlog, sino de los bugs y mejoras que puedan surgir a lo largo del proceso de desarrollo que pueden ser introducidas por el cliente o por el propio equipo de desarrollo y que además permiten realizar el seguimiento de cada una de ellas, entiendo que el backlog recoge toda la información sobre todas las tareas que conforman el proyecto y por ello la idea de compartirlo con el cliente e intentar que participe en su gestión.

    Un saludo y gracias por comentar.

Responder a soren Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *