Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Usuario Final. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Usuario Final. Mostrar todas las entradas

domingo, diciembre 15, 2019

El contexto de tu producto importa: aquí te cuento el porqué

Imagen tomada de Pixabay

Escucha el audio de este artículo aquí:

Los dueños de producto virtuosos utilizan una combinación de análisis de negocios, experiencia de usuario y habilidades de gestión de productos para determinar cuál es el siguiente producto correcto a diseñar y construir y para compartir con el equipo de desarrollo el entendimiento que tienen de su visión.

Mucho antes de la era ágil ya enseñaba y acompañaba a los gerentes de producto y líderes de equipos de producto a:
  • Entender mejor a los interesados, a los usuarios y a todo aquel que se viera impactado de una u otra forma por el producto y por su desarrollo
  • Comprender el contexto de su producto
  • Tener una percepción más íntima de las necesidades de sus consumidores
  • Entender y juzgar el producto derivado de su trabajo con el equipo
  • Organizar la información recopilada del aprendizaje del uso del producto, más del contexto de este.
El movimiento ágil me enseñó posteriormente que una técnica específica puede o no ser apropiada en cada situación. También me enseñó que el diseño y la elaboración de productos impresionantes es una forma de pensar, una mentalidad. De esta manera, el mensaje que llevo a los Dueños de Producto actuales para ayudarlos a determinar el momento adecuado para usar una u otra técnica y la forma más sencilla de aplicarla, es conocer en profundidad los diferentes escenarios, las circunstancias o condiciones bajo las cuales será usado el producto que tienen en mente, lo que casi siempre incluye conocer al detalle a los usuarios o consumidores.

Pero en el camino de establecer una comprensión compartida del problema y más allá, de la causa raíz, el problema detrás del problema, y de las mejores soluciones para resolverlo, nos encontramos con ciertos impedimentos como:
  • Muchos backlogs de producto
  • Dificultad en la priorización de cada uno de ellos y entre unos y otros
  • Poca percepción del valor de cada producto y de cada uno de sus componentes, el valor para el negocio
  • Muchas interdependencias entre unos y otros y hasta con productos que no están en el radar de nadie
  • Los equipos no necesariamente están trabajando en los productos correctos desde una perspectiva del negocio, aunque los Dueños de Producto no ayudan mucho en este sentido

Para sobrepasar estas dificultades ayuda conocer el contexto en el cual estamos trabajando. Es útil encontrar las respuestas a preguntas como:
  • ¿Quién necesitará o usará nuestro producto?
  • ¿Quién es nuestro consumidor final?
  • ¿A qué mercado o segmento de mercado queremos llegar?

Pero ya no estamos en el momento de quedarnos con las respuestas simples. Estamos en la era de la hiperpersonalización de productos. Cada consumidor o usuario quiere tener su propia experiencia, única, así es que dediquemos tiempo a conocer a muchos de ellos. No es que necesitemos salir con un MVP para cada uno, se trata de salir lo más rápido posible con un producto en excelentes condiciones, listo para usar o consumir y,  a partir de allí, incrementarlo y desplegarlo a más y más usuarios de manera frecuente.

Dediquemos un tiempo importante a repensar el producto. No caigamos en la trampa del “MVP muy temprano”. El mayor miedo de las organizaciones hoy es llegar al mercado con el producto incorrecto. Está bien lo de fallar rápido y barato pero no se trata de fallar por fallar. Nos enfrentamos a la paradoja de las organizaciones exitosas: solo queremos brindar productos que enamoren a las personas, pero no sabemos si el producto deleitará a nuestros clientes hasta tanto no lo hayamos entregado.

Las cosas así, llevar a cabo minuciosamente algunas de estas actividades, sino todas, ayuda:
  • Definir y defender la visión del producto.
  • Investigar la naturaleza y probar las necesidades del mercado
  • Identificar múltiples opciones de productos de alto valor.
  • Decidir las fechas de lanzamiento y el contenido. Sobre todo, lanzar con calidad.
  • Durante el desarrollo “a lo Scrum”, lograr que los elementos del backlog de producto estén "Preparados" para la planificación y desarrollo
  • En ese mismo orden de ideas, aceptar solo trabajo "Terminado"
  • Realizar demostraciones de productos y solicitar retroalimentación en vivo y en directo, tomar atenta nota e incorporar, de ser posible, las nuevas solicitudes

En mi artículo Las historias de usuario se cuentan con C de Contexto, enumeraba Algunas herramientas que nos ayudan a entender mejor el contexto de las historias de usuario y del producto en general. Puedes leer el artículo en:

Ahora bien, antes de pensar en la tecnología, pensemos en el negocio. Antes de salir a vender (o a producción), pensemos en el mercado. Antes de desarrollarlo, pensemos en el cliente o usuario. Antes de considerar sus componentes internos, pensemos en cómo se verá a los ojos, a los sentidos de las personas a las que queremos llevarle el producto.

Una técnica que estamos aplicando con éxito es esta del desarrollo de productos basado en experimentos: una forma de abordar el diseño del producto y el proceso de desarrollo para que la investigación, el descubrimiento y el aprendizaje (hacer preguntas y obtener respuestas útiles y confiables) tengan prioridad sobre el diseño y luego la validación de las soluciones propuestas. Pero sobre desarrollo de productos basado en experimentos hablaremos en otra oportunidad.

Imagen tomada de Pixabay
Mientras tanto, atención Dueños de Producto, Gerentes de Producto, deleguen completamente el diseño y la construcción del producto al equipo de desarrollo, ustedes dedíquense a explorar el mercado, a aprender de él, a pensar en nuevas formas de cambiar el estilo de vida de las personas y a conocer las necesidades de estas. Es lo que finalmente los conducirá al éxito en sus tareas habituales. ¡Escucha a tu usuario!

Finalmente, es solo a través de procesos efectivos de diseño, prueba, retroalimentación e iteración, que un Dueño de Producto y su equipo pueden validar el impacto de una idea en un contexto. Súmate a un equipo grandioso, porque un equipo estupendo hace productos fantásticos.

jueves, febrero 01, 2018

Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil


¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!
Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.
En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.
Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:

  • En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
  • A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
  • Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puerta al cambio.
  • En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.
Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata
Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.
Al principio del proyecto o del esfuerzo de desarrollo

En Cascada se toman o "levantan" (casi) la totalidad de los requisitos al principio del proyecto, y de muchos de ellos se hace con gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprints (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.
En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.
En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.
Más adelante, cuando el proyecto está en marcha
En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios) que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.
En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.
En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.
En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.
En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.
Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.
En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.
Y sobre medios o herramientas para “recolectar” y administrar requisitos
Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:
En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.
En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.
Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.



*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad

domingo, junio 26, 2016

¡El tamaño sí importa!


Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:


Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

Y este otro:

De historias de usuario, culturas y del arte de narrar historias


También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html

jueves, marzo 05, 2015

De historias de usuario, culturas y del arte de narrar historias

“Yo no sé muchas cosas, en verdad,

Digo tan solo lo que he visto.
Y he visto que la cuna del hombre
la mecen con cuentos,
que los gritos de angustia del hombre
los ahogan con cuentos,
que el llanto del hombre
lo taponan con cuentos.
Y que el miedo del hombre
ha inventado todos los cuentos…
Yo sé muy pocas cosas, es verdad,
pero me han dormido con todos los cuentos
y sé todos los cuentos ...”
[León Felipe, Aguaviva.]

La vida es una alegoría, los seres humanos no solo estamos configurados como cuerpos biológicos abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más universal, con nuestros semejantes. Pero además poseemos una visión personal para interpretar nuestra cotidianidad, tenemos ideales y pensamientos, emociones y aversiones que nos hacen actuar  de formas particulares al interpretar nuestra realidad.

En todo esto, la narración de historias juega un papel muy importante  en la construcción de conocimiento. La narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias permite a las culturas sobrevivir y progresar; es el camino más simple y más efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en el sistema sobre los mismos objetivos.” [1]

Las historias (de usuario) establecen una manera de organizar y comunicar experiencias. Las personas usan instintivamente la narración de historias para organizar un cúmulo de ideas que consideran disperso; además, gracias a ellas pueden organizar lo que saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las personas nos invitan de una forma u otra  a investigar sus pensamientos, sus sentimientos y sus intenciones. Finalmente, como oyentes y más tarde como lectores de las historias de usuario, adherimos a los acontecimientos, como una exploración de la experiencia de los usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre todo, comprendiendo su valor real.

Quienes transitamos a diario por el vasto universo del diseño y construcción de productos de software sabemos que es importante enfocarnos en el valor que estos prestarán a sus dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se usará el sistema que en las largas listas de funciones o características que ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la completitud de las historias y estas, a su vez, facilitan filtrar las formas potenciales de usar el sistema que ofrezcan poco o ningún valor real a los usuarios. Este foco constante en el valor permite asegurar que cada entrega del sistema sea tan pequeña como sea posible, a la vez que tenga valor real para los usuarios del sistema y para los interesados que financian el desarrollo.” [3]

Cuenta las historias, no las escribas

En su libro “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo mejorar el desempeño del equipo ágil usando la técnica de las historias de usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés actual sobre las historias y la supervivencia de las culturas. Esta idea es precisamente la del título de esta sección: cuenta historias, no las escribas.

Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos. Este malentendido conduce a situaciones en que las historias sean recolectadas en herramientas de gestión de actividades, con muchos detalles escritos o proporcionados por representantes del negocio.

Nada más alejado de una buena práctica. Las historias de usuario implican un modelo totalmente diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde la transferencia de conocimiento vía documentos “pesados” se reemplaza por involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos que la conversación cara a cara es la forma más efectiva de comunicar información y que una buena discusión entre los interesados y el equipo ágil lleva a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los requisitos se escriben, aun si los llamamos historias de usuario, estas discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo de experiencia en esto, pasé dos décadas escribiendo requisitos de software, todo tipo de requisitos, todo tipo de productos de software.

La recomendación es simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de tiquetes electrónicos, pero solo como recordatorios de esa conversación que tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles de las historias con anticipación. Compromete a los interesados del negocio e involucra a los miembros del equipo en una discusión, busca distintas perspectivas de la historia y explora opciones. Esta es la forma de acceder a los beneficios reales de trabajar con historias de usuario.

Beneficios clave de contar historias

Las discusiones permiten a los representantes del negocio, no solo explicar lo que quieren, sino también asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de los mayores problemas en los modelos tradicionales son los malos entendidos entre los distintos roles en el equipo y entre los interesados, entre quienes existen niveles heterogéneos de conocimiento acerca de las necesidades de cada uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento sobre la historia.

El segundo beneficio, apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo se involucra en una discusión, los vacíos funcionales, las inconsistencias y los requisitos no claros se descubren más rápidamente que cuando una sola persona (léase Analista del Negocio o similar), escribe los detalles.

Pero el beneficio más importante de la comunicación cara a cara, comparada con el paso de información vía documentos, es que la primera produce mejores soluciones, mejores productos. Para ser capaz de construir buenas soluciones, las personas necesitan conocer los planes y las oportunidades del negocio, entender el dominio del problema, tener un conocimiento profundo de las restricciones técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan servir. Involucrar a un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.

Como lograrlo

La excusa más común para llenarnos de documentación es la insistencia del negocio en la aprobación formal, las regulaciones legales o gubernamentales o las dependencias con terceros. Si es necesario “firmar” las historias hazlo a medida que las discutes. Es más, si el alcance final debe ser aprobado por varios interesados en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la reunión de planificación del Sprint donde se van a construir las historias. En cualquier caso, el Dueño de Producto juega un papel muy importante en la consecución de tales aprobaciones. Es una de sus responsabilidades directas.

Como siempre, ensaya distintos acercamientos y en cada retrospectiva analiza como le fue a tu equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el tema, recomiendo amplísimamente los libros que usé como referencia

Referencias

[1] [2] [3] Ivar Jacobson et all. Use Case 2.0. Ivar Jacobson International. 2011. Traducción de Luis Antonio Salazar y Carlos Mario Zapata.

[4] Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

[5] Conocido también en algunas culturas o regiones como el fenómeno o el juego del “teléfono descompuesto”

Para saber más de historias de usuario puedes leer mi serie de artículos en este mismo Gazafatonario:

http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU

miércoles, abril 17, 2013

¿Es usted la persona correcta para responder mis preguntas? O el síndrome del sujeto equivocado



En los proyectos de software estamos llenos de personas que no son “las adecuadas para responder nuestras preguntas”, para establecer las verdaderas necesidades del negocio, para darnos a conocer el problema que tienen, el problema detrás del problema, la causa raíz, el impacto de ese problema y las áreas impactadas. Estamos llenos de personas que constantemente no toman decisiones, que tienen que consultar con alguien más, que no entienden lo que nos están contando durante un proceso típico de educción de requisitos, es decir, durante las entrevistas, al responder cuestionarios o al analizar prototipos, entre otras actividades.

Por eso es que nuestros proyectos están repletos de supuestos, algo con lo que nunca debemos trabajar, sobre todo, porque son supuestos pasivos, que nunca evolucionan ni son gestionados con eficacia. Los supuestos le están haciendo mucho daño a la industria y conducen a la producción de software de baja calidad o que no satisface para nada las necesidades de nuestros usuarios y clientes. Hacemos suposiciones porque nuestra mente es muy sabia y siempre necesita respuestas, necesita comprender lo que pasa en nuestro entorno, y si no se produce la respuesta que requiere, entonces la presume.

Esta necesidad de hacer supuestos es inherente al ser humano: a lo largo de nuestras vidas hay cientos o miles de preguntas que no somos capaces de manifestar explícitamente y, por consiguiente, no conseguimos las respuestas adecuadas. De todas estas preguntas sin responder, hacemos suposiciones para llenar el vacío y la insatisfacción que sobreviene, es la única manera de sentirnos seguros. Si logramos respuestas a medias, hacemos suposiciones, si no obtenemos respuestas, también hacemos suposiciones, nos da lo mismo saber si la respuesta es la correcta o no, simplemente es suficiente con suplir el ansia de saber.

Debido a ello, cuando un interlocutor, un usuario u otra clase de interesado, nos está respondiendo preguntas vía entrevista y nos dice que no está seguro, que va a confirmar tal o cual asunto, que debe reunirse la próxima semana con una o más personas para aclarar un tema, etcétera, nosotros, ni cortos ni perezosos, hacemos supuestos. Es más, nuestros productos de trabajo tienen siempre una sección de Supuestos en la que registramos estas conjeturas y muchas veces no las volvemos a revisar. Mi primer consejo es eliminar esta sección de los documentos, son perjudiciales.

También es bien sabido que los usuarios típicamente no saben lo que el software puede hacer o no tienen las habilidades para sintetizar las soluciones basadas en software a sus problemas reales. Y nosotros muchas veces fallamos al preguntar porque somos propensos a creer que el problema de los usuarios es de índole tecnológica y no algo puramente del negocio. Incluso, antes de eso, fallamos al seleccionar y clasificar correctamente a los usuarios correctos o alguien más toma la decisión por nosotros, lo que deja el proyecto en una incertidumbre mayor que aquella con la que inició.

Los supuestos son atajos hacia la veracidad. El problema es que casi nunca acertamos al escoger el camino apropiado. Siempre que sea posible, reemplacemos esas hipótesis por hechos probados, por evidencias que soporten la toma de decisiones, seleccionando mejor nuestros usuarios, entrevistando al mayor número de personas en el menor tiempo posible, así estaremos en capacidad de verificar las fuentes, de contrastar respuestas y de saber cuándo hemos llegado a la definición correcta del sistema. Invite a varias personas a la sesiones de búsqueda de requisitos, la probabilidad de que una de ellas sea la adecuada aumenta.

Por eso, la siguiente ocasión que inicie un proyecto de software y le toque entrevistar por primera vez a un usuario, pregúntele: ¿Es usted la persona correcta para responder mis preguntas? Sí, ya sé lo que van a decir, en nuestra cultura este tipo de preguntas es fuerte y puede tomarse como una insolencia; es cierto. Por eso tenemos alternativas: ¿quién más cree usted que puede ayudarnos a resolver estas cuestiones? ¿Alguien más está interesado en esta situación? ¿Quién más tiene este problema? ¿Alguien más nos puede acompañar en la reunión? ¿A quién podríamos enviarle estas preguntas? ¿Alguien más puede tomar decisiones cuando usted no está?

¡Las posibilidades son infinitas!