Demo vs Review

Dos miradas sobre cómo presentarle a los clientes en qué se estuvo trabajando.

Random Google Image

Antes de comenzar quiero aclarar que en este artículo no estoy hablando puntualmente de una “Review meeting” tal cual plantean frameworks como SCRUM. Simplemente son dos formas de llevar a cabo una demostración del trabajo realizado a un tercero.

Es razonable que cada tanto nuestros clientes quieran ver el progreso, así como también lo es, que nosotros, orgullosos desarrolladores, queramos mostrar en lo que hemos estado trabajando.

No importa la metodología utilizada: si es ágil o no; si es por iteraciones cortas o largas; en algún momento debemos interactuar con el cliente para que éste pueda ver “lo nuevo”.

El ejemplo que voy a usar, si mal no recuerdo, lo usó Freddy Alegre en el AgileOpenCamp de este año en uno de sus charlas de openspace, así que el crédito es para él :).

Para ilustrar el ejemplo, supongamos que el cliente pidió que se le construya una silla. Vamos a mostrarle al cliente cómo avanza su producto con una demostración, utilizando dos miradas diferentes : la “demo” y la “review”.

Demo

Empecemos con una demo. Esta reunión suele ser un ambiente controlado, en donde una persona del equipo le muestra a los demás qué se hizo. Empieza contando como pusieron un cosa por acá, otra por allá y cómo es el flujo de trabajo.

El problema de las demo es que en general uno evita hacer cosas que potencialmente puedan generar un fallo durante la demostración (como ingresar letras en un campo solo numérico), por miedo a quedar en evidencia.

Random Google Image

Haciendo el paralelismo con la silla, uno al mostrarle la silla se la muestra de lejos, se sienta despacito y quizás solo en una parte procurando no cargar la pata que sabemos que está mal encolada para que no se rompa. Le contamos lo suave que es la madera y lo bien que siente al sentarse.

Si alguna vez fueron a comprar un sillón sabrán que se siente cuando te dicen “son de muestra, no te podes sentar”. E imaginen que siente el cliente cuando ve su producto andando en una pantalla.

Este tipo de reunión nos suele dejar poco feedback útil al equipo de desarrollo. Yo personalmente las veo más para cubrirse y decir “¿ves que avanzamos un montón?” que para generar un valor real al producto y por ende a los usuarios.

El mayor feedback que podemos obtener de una demo es visual : “¿podemos cambiar el color de ese botón?”, “¿podemos alinear eso a la derecha?”, etc.

Review

La review va un paso más. Los que se reúnen son los mismos que estaban para la demo, pero en lugar de mostrar una pantalla, lo que se hace es darle al cliente la opción de interactuar con el software, y a medida que le vamos contando los avances, que él vaya teniendo la posibilidad de descubrir cómo se hacen las cosas.

La ventaja de permitir al cliente utilizar el software es que puede darnos
un feedback mucho mas rico respecto a cómo se organizaron, las posiciones
de los elementos, los textos, etc. Como usuario uno puede detectar si es cómodo trabajar con el sistema o no.

Podemos ir un paso más y no explicarle siquiera las cosas, solamente decirle cosas como “ahora podes crear un usuario nuevo, y luego darle permisos de administrador” que que él deba hacerlo con la menor asistencia posible. Esto nos permite probar nuestras si la experiencia de usuario es como la pensamos o si le dificulta encontrar donde se realiza cada tarea.

En el caso de la silla podría descubrir que su peso es demasiado y pedir que se refuercen las patas; o que la madera elegida se ve linda y suave pero haría falta un almohadón ya que después de 10 minutos sus posaderas se sienten incómodas usando el producto :).

Random Google Image

Existen muchas posibles ramificaciones para un review y generalmente las empresas de servicios les escapan porque el control está más del lado del cliente. Pero los beneficios para el cliente son infinitamente mejores.

También hay que tener en cuenta que aunque es el cliente quién usa el software, está todo el equipo de desarrollo durante la reunión para guiar al usuario que hace la prueba del sistema. La reunión debe ser igualmente planificada y estar alineada con los objetivos de la iteración. No es una reunión aleatoria que va para donde quiere.

Cerrando

Como se dijo antes, una review permite al usuario final o cliente tener un contacto real con el software, pudiendo detectar mejoras con mayor rapidez que el caso en donde es observador pasivo.

Si bien hay mayor riesgo de que algo salga mal, ese riesgo puede ser mitigado de muchas otras formas durante el desarrollo y las ganancias son aún mayores que el riesgo de aceptar que algo no salió bien.

Sea cual sea el método que elijan, algunos pequeños consejos:

  • Todos para uno: Que participe todo el equipo tanto en la preparación como en la reunión. Escuchar el feedback de primera mano es mucho más eficiente que jugar al teléfono descompuesto.
  • Planificar: Elegir en que orden van a presentar las cosas y armar un guión para seguir un orden.
  • Preparar: Crear de antemano todo lo que sepamos que necesitamos en el ambiente donde vamos a probar. Usuarios, imágenes, reportes, datos de prueba, etc.
  • Practicar: Al menos una vez para ver que van a decir en cada caso de no quedar balbuceando mientras piensan “¿Cómo era esto?”.
  • Documentar: Todo lo que se dice en la reunión que de valor al producto.

Los invito en su próxima entrega a hacer una review en lugar de una demo y contarme cómo les fue :).

Anuncios

Lo que quiero vs Lo que obtengo

¿Cuántas veces recibiste algo y te diste cuenta que no es lo que pediste?, o tal vez debería decir ¿… y te diste cuenta que no es lo que esperabas?

Random Google Image

Cuando uno avanza en su carrera es normal que le den la responsabilidad de coordinar o revisar el trabajo de otros. Este trabajo por hacer son los requerimientos del sistema en el que estamos trabajando y dependiendo de cómo sea el entorno de cada equipo, estos requerimientos pueden estar mejor o peor definidos, o más bien, mejor o peor documentados.

Últimamente me suele pasar que lo que yo esperaba ver en el momento de la revisión no era lo que recibía. Lo primero que empecé a pensar es que estaba siendo muy exigente y que debía bajar mis expectativas.

Lo importante no es lo que dices sino lo que la gente entiende. Words That Work, Dr. Frank Luntz.

La respuesta “fácil” es pensar que el programador hizo lo que quiso; que no entendió lo que le pedí; o que tiene poca experiencia y por eso interpreta mal las cosas (hay ejemplos reales de todas esas afirmaciones pero no vienen al caso :D). Pero hay un factor clave que no estaba teniendo en cuenta: como comunico lo que quiero a los demás. Haciendo una retrospectiva me di cuenta de que prácticamente les estaba tirando tickets por la cabeza sin mayor contexto.

A partir de estas observaciones es donde comencé a preguntarme qué es lo que estaba haciendo mal y la respuesta a la que llegué se puede resumir como la “maldición del conocimiento”.

La maldición del conocimiento: Una vez que conocemos algo, nos resulta muy duro imaginarnos cómo era no conocerlo.

En el momento en que cae un problema nuevo y uno comienza a definir cómo lo resolvería, ya comienza a tener un pre-concepto de qué es lo que espera uno ver. Si cuando le pedimos a otra persona que resuelva el problema por nosotros, no le transferimos ese conocimiento, es cuando se genera este “roce” que nos hace doler la panza y pensar “¡¿por qué lo implementó de esta manera?!”; o darse cuenta de que hay ciertos casos que no estaban contemplados por la persona que resolvió el problema. Quizás ni siquiera estaban claros que esos faltantes eran un problema.

El efecto que observo de este tipo de problemas es que el proyecto “está atrasado”. “¿No entregábamos ayer?” podría preguntar alguien. Quizás de haber estado bien comunicado de entrada ser podía prever que “ayer” no era posible entregar. Quizás de haber comunicado de manera diferente, la persona que realizó el trabajo podría haber sido más efectiva.

Soluciones a este problema hay varias, según cada equipo y organización puede que una u otra se adapte mejor.

La primer opción y quizás la más tradicional es contar con un Analista Funcional que se encargue de especificar al detalle cada problema de cada proyecto de cada cliente. Si bien no estoy en contra de esto, creo que no escala para el día a día. En nuestra industria los requerimientos cambian muy rápido y dejan obsoleta muchas veces cualquier planificación. Sí nos suele servir, a nosotros como empresa, para el kickoff, donde se puede recolectar una primera aproximación de lo que quiere el cliente.

Una segunda opción es que alguno de los empleados más experimentados haga de “Analista” y se pase horas escribiendo lo que pretende que hagan los demás desarrolladores. Es lo que en general hago ahora, salvo en algunos casos, pero no me funciona por un par de razones.

La primera razón es porque la cantidad de tickets pueden ser decenas o cientos. Y especificar cosas que ni el cliente ni yo sabemos cómo las haríamos (o si siquiera se quieren hacer) carece de sentido práctico y termina siendo una pérdida de tiempo. Además nada garantiza que pueda ver todos los ángulos del problema para dejar claro que quiero.

La segunda razón y tal vez la más importante, es que para que esto sea útil lo tendría que hacer bajo demanda, es decir, cada vez que alguien va a empezar un ticket, agarrarlo, pensarlo, documentarlo y delegarlo. ¿Se imaginan cuánto tiempo les quedaría además para hacer algo realmente productivo?. Cero!. Eso sin contar que pasaríamos a ser el cuello de botella de todos los proyectos.


En el último post hablé de buscar mejores formas de construir software, y si algo me han enseñado mis años participando en comunidades de software libre es que compartir el conocimiento y la responsabilidad es beneficioso para todos.

Los frameworks ágiles, como Scrum, plantean este cambio de conducta. Es por eso que existe la Planning meeting o el refinamiento del backlog, momentos en el que el equipo se reúne completo, junto con el dueño del producto (puede o no ser el cliente real) a entender las tareas pendientes, hacer preguntas y documentar que se va a hacer en cada caso.

Está claro que la premisa fundamental para “estar todos en la misma página” es eliminar los intermediarios y que los temas se discutan abiertamente.

Evitemos le teléfono descompuesto

Como ganancia extra, involucrar a las personas les da un sentido de pertenencia que genera una responsabilidad en ellas, y por lo tanto un mayor compromiso hacia su trabajo siendo un beneficio tanto para ellos como para el cliente. Pueden leer más al respecto en Equipos Estables por sobre Pool de Recursos escrito por Martin Alaimo.

Para ir cerrando, les dejo una lista de tareas con cosas que creo que deberían ayudar y que tengo intención de ir mejorando :

  • Involucrar a todos, siempre.
  • Hacerlos participar, es decir, dejarlos hablar y escucharlos.
  • Incentivar el debate, tener dos ideas es mejor que tener una :).
  • Analizar pro y contras de las opciones y dejar documentado lo que se decida.

Para terminar, me gustaría cerrar con una pregunta para seguir aprendiendo: ¿Qué hacés en tu equipo/empresa para mejorar la forma en que se comunican?

Ser ágil es …

Si hay algo que aprendí en el último año es que la frase con la que titulé esta entrada es una de las cosas más difíciles de explicar que me encontré en el último tiempo.

Estas semanas estuvimos hablando mucho en el trabajo sobre agilidad, equipos, ser ágiles, Scrum, etc; y algo que he notado es que cada uno interpreta diferentes cosas sobre el qué y el cómo. Y en general me es muy difícil explicar la “particular” mirada que tengo actualmente de lo que entiendo por “ser ágil”.

Sacada de http://pragmaticprojectleadership.com/agile-mindset-deciding-work/

Hasta hace poco mi definición más corta para responder a esta pregunta era “ser ágil es responder rápido al cambio”. Después de largas horas de charlas durante el Agile Open Camp de este año, me di cuenta que mi respuesta no me dejaba satisfecho.

¿Somos ágiles porque hacemos iteraciones?, ¿somos ágiles porque hacemos entregas continuamente?, ¿somos más rápidos por ser ágiles?, ¿somos ágiles porque usamos Taiga, Jira, Trello?. Hay ejemplos y contra ejemplos a montones que responden estos interrogantes en varios blogs.

Para mi “ser ágil” representó un cambio mental, un enfoque diferente a lo que estaba acostumbrado a hacer. Y ese cambio mental es simplemente la búsqueda de la agilidad, no el ser ágil en sí. Ágil es un ideal. Un lugar donde queremos llegar. El camino para ir a ese lugar es lo que creo que nos convierte en agilistas. Y en ese camino no hay solo procesos y herramientas, hay personas. La forma en que interactuamos con las personas es la que nos acerca al objetivo.

El ser ágil plantea una perspectiva, una dirección hacia donde queremos ir. El Manifiesto ágil lo plantea muy bien en sus primera palabras

We are uncovering better ways of developing software …

Ser ágil se trata simplemente de eso. Buscar mejores formas. ¿Scrum te funciona? Genial usalo! ¿Kanban es más lo tuyo porque no podes planificar por iteraciones? Excelente, usalo! Experimentá, buscá tu espacio y tratá de ir evaluando y mejorando constantemente en busca de ese ideal ágil.

En uno de los proyectos donde estoy involucrado estamos atravesando justamente esta transformación. No usamos Scrum; no usamos Kanban; no hacemos XP; ni RUP :D. Pero sí implementamos varios cambios que buscan mejorar la forma en la que creamos el producto para el cliente.


Hablamos entre todos

El primer cambio que acordamos fue dejar de lado los chats uno a uno y nos ‘forzamos’ a hablar en el canal de Slack del proyecto.

Lo que nos venía pasando es que caía un ticket a resolver, lo tomaba alguien del equipo, consultaba con otra persona del equipo, llegaba un pedido para que se revise el código y acto seguido quien revisaba preguntaba : “¿pero no podemos hacerlo de esta otra forma que es más simple?”.

En general uno encuentra que siempre había una alternativa menos costosa que uno no pensó. Nos estábamos perdiendo la parte de la interacción de las personas :).

Esto está ayudando mucho porque todos, aunque no estemos 100% del tiempo en el proyecto, podemos estar al tanto de lo que está pasando, opinar cuando ve que otro tiene un problema, o simplemente ofrecer otra perspectiva.

Un lado “negativo” que se genera es que gente que está de paso por el canal vea que hay “mucho ruido”. Si esto pasa recomiendo tener varios canales para el proyecto: uno de cosas casual / novedades y otro más movido donde se hable de todo, los bots peguen los resultados de las tareas automáticas, etc. También podemos sugerirle a esta gente la “regla de los dos pies” virtual :).

https://www.flickr.com/photos/planeta/3311035191

Y como cierre de este punto: hablen entre Uds a ver qué es lo mejor para este equipo en este proyecto. Júntense una o dos horas en una sala de reunión, plaza, bar, o donde les pinte y traten de encontrar el mejor canal para intercambiar información de manera efectiva.


Eliminamos distracciones.

El Manager, antes de los cambios, solía interrumpir por cada consulta del cliente a los desarrolladores para atacar diferentes tareas: dejar lo que se estaba haciendo para empezar una tarea nueva (dejando la actual por la mitad); investigar un bug para ver si es un problema grave; o simplemente para hacer de proxy con alguna pregunta del cliente.

Esto hacía que el cambio de contexto sea constante y la productividad y el ánimo decaía.

Para atacar este punto lo que hicimos fue co-crear una matriz de Eisenhower que nos permite priorizar las cosas en urgente / importantes. Para tener un criterio común y evitar ambigüedad definimos que lo importante es lo que el cliente quiere. Mientras que lo urgente es lo que afecta al usuario del sitio.

Con esta categorización pudimos acordar que solo lo urgente e importante puede ser tratado fuera de las reuniones de sincronización. Éstas reuniones las hacemos dos veces por semana : lunes y miércoles sobre las 14 hs (el horario es flexible).

Entonces, si llega un pedido del cliente, el Manager puede decidir si es necesario interrumpir el trabajo normal o si puede esperar a la próxima reunión, que en el peor de los casos es dentro de 48 hs.

Recién estamos viendo los primeros resultados y fueron en semanas bastante relajadas, pero me animo a decir que el equipo está más feliz, el cliente obtiene más cosas “terminadas” por semana y seguramente empecemos a bajar la tasa de tickets reabiertos por hacerlos apurados o desconcentrados.


A simple vista pueden parecer cambios triviales, pero el proceso de llevarlos a cabo no lo es. El trabajo que hace el equipo día a día para mejorar estos mismos puntos es increíble.

Me animo a decir que este es uno de los proyecto más ágiles en los que he trabajado últimamente :). Ah, y todo usando solo Redmine y Slack :D, las mismas herramientas que usábamos antes.

Encontrar el punto de equilibro no es fácil, sobre todo en una software factory. Quizás cuando trabajás en un producto se da todo más natural, pero no es imposible. Mi consejo acá es ir con cambios pequeños que no sean muy disruptivos a lo que ya está instaurado como cultura en la empresa y luego a medida que se vayan dando los resultados la gente se va a ir contagiando sola.

Para cerrar quiero dejarles algunas recomendaciones que he recibido y que busco aplicar en mayor o menor medida y que creo que pueden ayudar a cualquiera a empezar en el camino del agilista :

  • Comunica tus intenciones, con todos y a todos.
  • Trata de evitar las reuniones donde no esté todo el equipo, si hay algo anti-ágil para mi, es tener sub-equipos (si jugaron de chicos al teléfono descompuesto, sabrán de qué hablo :).
  • Mantené tu equipo en un tamaño razonable. Tampoco es útil reuniones de 200 personas :).
  • Introducí cambios que mejoren el equipo, el proyecto va a mejorar por el solo hecho de que el equipo esté más contento.
  • No te centres en las herramientas, centrate en las personas.