Tercera «Ask, "What would the user do?" (You are not the user)»

Desde mi experiencia personal, considero que la obtención de requerimientos de parte del usuario (sea a través de casos de uso, historias de usuario, narraciones, o cualquier documento formal o informal) es una tarea ardua y se convierte en determinante para crear una especificación de requerimientos para la aplicación efectiva. Todo depende de qué tan cuidadosos y profesionales hayamos sido con la formulación, documentación de las necesidades del usuario/cliente durante la primera fase del ciclo de desarrollo de la aplicación.

Respecto al caso anterior, considero conveniente hacer un breve pero concienciado recorrido sobre este proceso. Leyendo a @GilesColborne me parece curioso explicitar:

«We all tend to assume that other people think like us»

Lo que el autor del artículo en [1] comenta sobre el efecto de falso consenso consiste en la visión sesgada del programador a la hora de formular, documentar y mantener los requerimientos de una aplicación software. Estoy de acuerdo, en lo personal, que un usuario no tiene conocimientos profundos de informática, tampoco posee conocimiento de lenguajes de programación, principios de ingeniería de software; en la mayoría de los casos sólo les interesa la aplicación de gestión que manipulan a diario u ocasional. 

En una de mis primeras experiencias (una pequeña aplicación Web que capturaba datos de usuario para la cotización de seguros), solicitaba a mi cliente los requisitos de una forma muy técnica (lenguajes de programación, IDEs, modularización de la aplicación, descripción de los formularios en términos de atributos de las etiquetas, etc.). No hacía más que mostrar un rostro de extrañeza, por lo que creo, singularidad, y además, de la manera poco convencional de la comunicación.

Con referencia a la experiencia de Gales Colborne, estoy de acuerdo con que observar al usuario es mucho más efectivo que pasarnos largos ratos haciendo preguntas, ejercicios monolíticos (i.e. llenando encuestas, formatos). Ya lo decía Peter Coad y Ed Yourdon en Object Oriented Analysis [2]:

The analyst needs to immerse himself in the problem domain so deeply that he begins to discover nuances that even those who live with air traffic control every day have not fully considered.

Lo que nos trata de inculcar esta frase es sobre la preocupación o enfoque que debe tomar el analista a la hora de obtener los requerimientos de los usuarios. Todo consiste en sumergirse en el problema de tal modo que se empiece a entender, en lo ideal, mejor las complejidades y casos que aquellos que viven el día a día en el mundo del negocio.

Por otro lado, enumero algunas recomendaciones que encontré en [3]:

• Asignar al usuario tareas sobre aplicaciones análogas a la que se quiere desarrollar. Por ejemplo, pasos para generar reporte de nómina, descargar listas de clientes, agregar un producto al inventario, etc. Lo que se debe comprender de este ejercicio es la forma en qué interactúa el usuario con la aplicación, detectar los errores y en los lugares donde se cometen.
  
  
• Mientras que se observa la actividad del usuario, hacerse las siguientes preguntas:
• ¿Por qué lo hace?
• ¿Por qué no toma otro camino?
  
  
• Observar al usuario elimina ambigüedades en la formulación de los requerimientos de los usuarios, dado que la fuente primaria de información es obtenida de las actividades de los sistemas de información manuales (o no automatizados).
• A tener en cuenta está lo que dice el usuario del proceso que realiza sobre el sistema de información actual o los procesos manuales, y lo que realmente ocurre en la realidad.
  
  
  
  
  
• Es preferible gastarnos unas cuantas horas observando lo que el usuario hace, en lugar de gastarnos un día completo adivinando lo que el usuario hace.

Conclusiones:

Se ha hablado sobre la importancia de entender al usuario a través de lo que hace en su lugar de trabajo y cómo lleva a cabo las actividades sobre los sistemas de información (automatizados/sistematizados, o manuales). De comprender que la fuente de requerimientos clara y precisa proviene de los actores. Finalmente algunas apreciaciones a tener en cuenta la hora de enfrentarnos a las complejidades de la definición, documentación y mantenimiento de los requerimientos de una aplicación software.

Glosario:

- Ciclo de desarrollo de software
- Especificación de requerimientos
- Ingeniería de requerimientos
- Sistema de información

Referencias:

[1]  97 Things Every Programmer Should Know.
[2] Object Oriented Analysis - http://www.amazon.com/Oriented-Analysis-Edition-Yourdon-Computing/dp/0136299814
[3] Ask "What Would the User Do?" (You Are not the User) - http://www.amazon.com/Oriented-Analysis-Edition-Yourdon-Computing/dp/0136299814

H