viernes, 20 de junio de 2008

Team Skill 2: Entendiendo las Necesidades del Usuario

Éste es el tercer post dedicado a Managing Software Requirements - A Unified Approach de Dean Leffingwell y Don Widrig (ISBN: 0-201-61593-2), el libro que propone una metodología ordenada para la Administración de Requerimientos. Hoy nos toca la Habilidad Grupal 2: Entender las necesidades del usuario. Ya pasamos por la Habilidad Grupal 1, en la que analizamos el problema, entendimos las causas principales mediante técnicas como el diagrama de Ishikawa, identificamos a los participales (stakeholders) y usuarios clave, definimos a grandes rasgos el alcance de la solución (diagramando la perspectiva del sistema con un gráfico parecido al diagrama de contexto del mundo de análisis de Yourdon) e identificamos las restricciones que serán impuestas en la solución. También hablamos un poco de Business Modeling, la primera de las disciplinas de RUP, que puede facilitarnos la tarea a la hora de especificar procesos y entender las reglas de negocio del mundo que estamos relevando.

Los síndromes

Managing Software Requirement propone entender el problema a ser resuelto antes de comenzar a desarrollar la aplicación. Todo de lo que habla el libro se orienta a una metodología orientada al proceso, como puede ser RUP por ejemplo, como puede ser CMMI. El libro es de 1999, por lo menos la edición que yo tengo, y en ese momento no eran para nada populares los ambientes ágiles.
El Team Skill 2 habla de tres "síndromes" que complican la obtención de requerimientos, que aumentan el desafío de entender las necesidades reales de los usuarios y stakeholders y que deben superarse:
  • El síndrome de "sí, pero": Se refiere a que el usuario no ha visto nada del sistema aún y probablemente no haya entendido lo que el desarrollador le explicó que sería. Después de una larga espera, al enseñarle una beta o una release candidate resulta que no era lo que esperaba, resulta que no obtuvo lo que necesitaba. Se debe obtener los PEROs lo antes posible.
  • El síndrome de los "Requerimientos Ocultos": Este síndrome se basa en que, a medida que el analista va encontrando requerimientos, otros muchos más quedan sin descubrir. Por eso, se debe identificar a todos los participantes del sistema. Ellos son en general la fuente de los "requerimientos ocultos". También es importante en algún momento decir: "basta, con lo que tenemos es suficiente, empecemos a construir".
  • El síndrome del "Usuario y Desarrollador": Parte de la idea de que el usuario y el desarrollador en general provienen de ambientes distintos y existe un gap comunicacional importante entre ellos. Esto implica que hablen distinto idioma, tengan distintos objetivos, intereses y motivaciones.
Estos síndromes son usados como metáforas para comprender el desafío de entender las necesidades del usuario y proveer un contexto para las Técnicas de Relevamiento que se desarrollarán más adelante en este mismo post.

Leffingwell y Widrig han descubierto que muy rara vez se obtienen especificaciones y requerimientos efectivos. En general, cuando se entrevista a los participantes respecto a sus necesidades o requerimientos para un nuevo sistema, éstos no describen ninguna de estas cosas, sino que se expresan en función del comportamiento que piensan tiene que tener el sistema para resolver la necesidad real. Así, sin darse cuenta, suelen reemplazar el qué ("yo necesito") por el cómo ("lo que creo que el sistema debe hacer para resolver mi necesidad").

Para aplacar los síndromes, se proponen varias Técnicas de Relevamiento, una variedad de técnicas que ayudarán a ganar una mejor comprensión de las necesidades reales del usuario y otros stakeholders.

Técnicas de Relevamiento

  • Entrevistas y Cuestionarios
  • Talleres de Requerimientos (workshops)
  • Brainstorming y Reducción de Ideas
  • Storyboarding
  • Role Playing
  • Prototyping
Aunque ninguna de estas técnicas es perfecta aplicada a cualquier circunstancia, cada una representa un medio proactivo de impulsar el conocimiento de las necesidades del usuario, convirtiendo aquellos requerimientos "difusos" en requerimientos "mejor conocidos".

1 - Entrevistas y Cuestionarios

La entrevista es una técnica simple y directa. Un cuestionario no es sustituto para una entrevista. Es muy importante el tener "cara a cara" al usuario y poder hacerle preguntas y prestar atención a sus modos de hablar y a sus gestos. Es importante establecer el perfil del participante, evaluar con él el problema, entender su entorno, relevar y validar supuestos.

En general, lo ideal sería que pudieran asistir a la entrevista dos analistas; uno para dialogar y observar al usuario trabajar en su ambiente, y el otro para que constantemente esté tomando notas textuales de todo lo que ve y oye.

2 - Talleres de Requerimientos

El libro la recomienda como una de las técnicas más poderosas para captura de requerimientos. Se trata de reunir a un grupo de usuarios clave, juntarlos con algún incentivo y extraerles información. En general, en este tipo de workshops hay un moderador experimentado, que se encarga de llevar a cabo la reunión de forma ordenada. Una técnica muy popular es la de Focus Group.

3 - Brainstorming y Reducción de Ideas

Suelen hacerse durante los talleres de requerimientos. En toda sesión de Brainstorming hay dos partes principales:
  • Generación de Ideas
  • Reducción de Ideas
Hay varias formas de hacer un Brainstorming. Una de ellas es ésta:

En la primera parte:
  • Se juntan los participantes
  • Se reparten post-it (o algo similar para anotar) y marcadores negros
  • Se explican las reglas
  • El moderador explica el objetivo del Proceso (por ejemplo: "mejorar la funcionalidad de X módulo del sistema")
  • Los post-it son escritos con las ideas
  • El moderador junta los post-it y los pega en la pared (Es muy importante que nadie critique ninguna idea. Lo importante es generar un número populoso de ideas sin importar su credibilidad o aplicación práctica.)
  • Esta parte termina cuando los participantes se quedan sin ideas
En la segunda parte:
  • Poda de ideas: discutimos cada una de las ideas y nos quedamos con las más viables
  • Agrupamiento de ideas: las podemos agrupar por categorías
  • Definición de funcionalidades: el creador de la idea puede desarrollar un poco más qué fue lo que se le ocurrió
  • Priorización de ideas
El Brainstorming es un tema muy interesante en el que otro día prometo explayarme más (quizá le dedique uno o más posts a esto). Un libro muy bueno, que trata este tema, es el de Edward Bono - El Pensamiento Lateral: Manual de Creatividad (libro fundamental sobre Pensamiento Lateral) (ISBN 978-950-12-9069-1).

4 - Storyboarding

El Storyboarding sirve mucho para mitigar el síndrome del "sí, pero". Es económico, user-friendly, fácil de crear y modificar. Permite una rápida revisión de las GUI y de la visualización de los datos.

El libro menciona tres tipos de Storyboarding:
  • Activos: Pueden ser slides. Lo que se intenta es mostrar la "película" aún no producida.
  • Pasivos: Cuentan una historia al usuario. Puedes ser sketch, fotos, impresiones de pantalla, etc.
  • Interactivos: Simulaciones, demos interactivos, etc... (Similar a un Prototipo.)

5 - Role Playing

Cada miembro del equipo toma el lugar del usuario y ejecuta las actividades laborales del cliente. Hay varias variantes de esto, por ejemplo: Recorrido Guiado o Tarjetas CRC (Clase-Responsabilidad-Colaboración), muy útil en el mundo de los objetos.

6 - Prototyping

Un prototipo es muy útil para mitigar los síndromes del "sí, pero" y de los "requerimientos ocultos". Lo ideal es escoger la funcionalidad más nebulosa, la más complicada de entender o la que más extraña parezca y prototiparla.

Principalmente hay dos tipos de prototipos:
  • Prototipos Desechables: Se usan y se tiran. Sólo se guarda el conocimiento adquirido.
  • Prototipos Evolutivos: El código se reutiliza para comenzar a construir el sistema encima de él.
Los prototipos son muy útiles para validar requerimientos o para establecer viabilidad de una tecnología.

Entradas Relacionadas