Sumario

Debate iniciado en el grupo de discusión Análisis Funcional, comunidad de analistas funcionales dentro de la red LinkedIn, para discutir acerca de las distintas motivaciones por parte del usuario para leer los casos de uso diseñados. Título del Debate: Qué motiva a mis usuarios a leer nuestros casos de uso?

Casos de Uso, Motivación

Les dejo aquí parte del debate que se ha generado desde el grupo de discusión en LinkedIn: Análisis Funcional, administrado por Daniel Mónaco

Enunciado de la discusión principal:

Si los usuarios no leen los casos de uso, no importa qué tan buenos sean, qué tan bien escritos estén, estos no servirán de nada.

¿Pero basta con que los casos de uso estén bien escritos o estructurados para motivar a nuestros usuarios a leerlos?

¿Basta con que sean fáciles de entender? ¿Influye el nivel de detalle con que estén escritos los casos de uso para que sean recibidos y leídos con prontitud por los usuarios?

De hecho, ocurre mucho que un caso de uso bien está bien detallado es porque contiene aspectos que no son “aptos” para usuarios u otros interesados y en cambio son apropiados para otros miembros del equipo del proyecto.

Así que, ¿cuáles son esos estímulos que le podemos dar a un usuario para que tome tiempo de calidad y lea los casos de uso? ¿Qué aspectos pueden motivarlos a participar más de esta tarea?

¿Y qué podemos hacer para introducir estos incentivos en nuestro proceso de construcción de software?

Autor de la discusión: Luis Antonio Salazar Caraballo – Consultor Senior en Metodologías y Arquitectura de Software – Colombia (acceso al perfil público en linkedin)

Algunos comentarios dejados por los miembros del grupo:

Comentario 1
La motivación para leer un caso de uso viene siempre por el interés del usuario de conocer cierta funcionalidad del sistema. Luego el caso de uso debe estar lo suficientemente claro y simple para que sirva de medio de comunicación entre los participantes del proyecto.

Comentario 2
Depende desde que empiezas a definir cual será tu caso de uso y su enfoque, muchas veces un solo caso de uso puede ser tan extenso, detallado, y ademas rebuscado, que es difícil que nuestros usuarios puedan entenderlo.

Comentario del Autor
Maximiliano, lo que ocurre es que siempre damos por hecho que las demás personas están motivadas en el proyecto y muchas veces tenemos que darles un “empujoncito”, ayudarlos a “meterse al agua”. Y aunque son dos aspectos importantes de motivación, la claridad y la simplicidad son dos atributos difíciles de lograr, sobre todo, si no tenemos la experiencia suficiente como escritores técnicos, cosa usual en los Analistas Funcionales. En este sentido, una presentación formal de los casos de uso ayuda antes de dejárselos para su lectura.

Comentario del Autor
Norma, lo ideal es que los casos de uso nunca sean “tan” extensos ni rebuscados. Cuando esto ocurre quizás nos encontramos antes más de un caso de uso y es allí donde los usuarios se confunden. En este sentido, los casos de uso deben ser indivisibles, en el sentido de “especializados”. Es decir, deben representar una funcionalidad simple para el actor, para el usuario.

Comentario 3
Sin dudas el usuario tiene que estar comprometido desde el principio con la generación y validación de la documentación funcional. Eso generalmente viene condicionado por un entorno de negocio en donde nosotros no solemos tener injerencia.
Pero en donde sí tenemos injerencia es en el formato y contenido de la documentación que confeccionamos. En este sentido nunca debemos olvidar que lo más importante es que los usuarios comprendan correctamente las características del producto que las personas de IT están por crear. Tenemos todo un arsenal de herramientas a nuestro alcance: prototipos de interfaz de usuario, narrativas desestructuradas, planillas de cálculo o los diversos diagramas UML.
Por supuesto, no tenemos que incluir detalles técnicos como consultas SQL por ejemplo. Pero es imperativo que incluyamos las funcionalidades COMPLETAS. Esto es, no se debe omitir detalles funcionales solo para hacer más simple una especificación. Si el dominio del problema es complejo, la especificación será cuanto menos igual de compleja. De lo contrario nos estamos dejando algo en el tintero. Por ejemplo, si estamos especificando una consulta de clientes por pantalla, detalles como la forma en que los datos van a estar ordenados y los filtros que podrán ser usados son sumamente importantes, porque afectan a la usabilidad final de la aplicación. Entonces no podemos obviarlos con el pretexto de que son datos “muy técnicos” o que extienden demasiado las especificaciones y dejarlos de lado así nada más. Porque tarde o temprano, alguien va a tomar una decisión con respecto a esas cuestiones que no quedaron bien definidas y en esa instancia ya el usuario ni siquiera va a ser consultado sobre el asunto.

Comentario 4
Comparto mucho con las opiniones vertidas. Como se señala con anterioridad, influye directamente la forma de realizar la documentación para que esta sea de rápida aprobación por el usuario o se tarde más en analizarla y comprenderla.
No debemos olvidar que una documentación sencilla y simple no es sinónimo de malo o ambiguo.
Una gran carácteristica de un buen analista es interpretar de manera sencilla, ágil y en el lenguaje del cliente sus requerimientos.
Además, desde mi perspectiva una motivación importante para un stakeholder en la revisión de los Casos de Uso es hacerlo participe, hacerlo sentir que el Caso de Uso es producto de su conocimiento sobre el negocio.

Comentario del Autor
Germán, para lograr lo que dices es necesario involucrar, en el sentido de “hacer que se interese”, al usuario desde el comienzo hasta el final del proyecto. No debe haber ningún instante durante el ciclo de vida en que dejemos que el usuario se distraiga. El enfoque iterativo nos da pistas sobre cómo podemos alcanzar esta meta. Además de lo que mencionas, están los tableros de historias (storyboards), simuladores, proyecciones, prototipos funcionales y no funcionales, escenarios, los casos de prueba. Pero se necesita integrar al usuario al ADN del proyecto, como parte imperativa del equipo. Acaso sean necesarias sesiones de estimulación para trabajo en equipo, sesiones de “terapia” de cómo juntos todos podemos lograr más que separados y cosas de esas.

Comentario 5
Hola Luís Antonio.

A decir verdad, hacia los usuarios nunca utilizo el término ‘caso de uso’, ya que este término es tecnológico; así como los es el término ‘usuario’.

Yo evito que ‘mis usuarios’ lean los ‘casos de uso’ del sistema. Si el objetivo es que ‘mis usuarios’ comprendan perfectamente qué hará el sistema, a mí siempre me ha funcionado las exposiciones, donde se explica (1) el objetivo del proceso del negocio particular; (2) lo que integrará, automatizará y dará inteligencia el sistema el proceso del negocio, ilustrados con diagramas de flujo; (3) los resultados que el sistema debe generar; y, (4) la ejecución de todos los casos prácticos, o casuística, del proceso del negocio haciendo análisis de resultados.

Antes de continuar, quiero aclarar que yo no utilizo los términos ‘usuarios’ y ‘casos de uso’; en vez de esos utilizo los términos ‘ejecutivos del negocio’ y ‘procesos del negocio’. Inclusive, cuando tengo que hacer la misma exposición con el equipo de desarrollo también utilizo los términos ‘ejecutivos del negocio’ y ‘procesos del negocio’. En otra oportunidad, si me lo permiten, expondré mis argumentos por el uso de estos términos.

Los ejecutivos del negocio realmente se sientes motivados en las exposiciones, ya que se sienten muy entusiasmados al ejecutar sus casuísticas en los flujos propuestos para el sistema, y siempre están con los cuadernos y apuntes haciendo sus análisis de resultados. Esta práctica sirve de mucho en las expectativas del futuro sistema.

Además, siempre termino satisfecho al término de cada exposición cuando los ejecutivos del negocio se dan cuenta de cuán rentable será la solución respecto a cuánto cuesta ahora el proceso del negocio. Los negocios siempre están buscando la rentabilización con sus soluciones, sea para aumentar sus ingresos o para reducir sus costos de operaciones.

Comentario del Autor
Gerardo,

Interesante tu enfoque de “ejecutivos del negocio” y “procesos del negocio”, sin embargo, sobre esta última expresión, ¿cómo distingues entonces un “proceso de negocio”, es decir, algo que ocurre en el negocio con o sin el “apoyo” de herramientas automatizadas”, y “procesos del sistema”, es decir, algo que ocurre puramente en un sistema de software?

Acuerdo contigo en lo que tiene que ver con la exposición a los usuarios o ejecutivos del negocio, como los llamas. Es una excelente práctica y normalmente arroja muy buenos resultados. En cualquier caso, los requisitos (expresados como casos de uso o no), nunca deben ser enviados al usuario “en frío”, siempre viene bien una reunión, o varias, de presentación de todos estos requisitos, una reunión bien ambientada, donde todas las partes estén motivadas, conozcan bien el objetivo de la sesión y que se den los debates a que haya lugar para que al final todos salgamos con la misma Visión, ese es precisamente el objetivo final, que haya consenso entre todos los interesados sobre lo que hará y no hará el sistema.

Escuchamos atento tu aproximación de “ejecutivos de usuario” y “procesos del negocio”.

Comentario 6
Luis, yo tengo la firme convicción de que si el usuario no se hace partícipe de la elaboración de los casos de uso estos no terminan sirviendo para nada, recordemos que estos son esenciales como materia prima de todo lo que se hará de ahí en adelante y como elemento que permite validar si el software si cumplió con el alcance.

Evidentemente, lo difícil es hacer que el usuario se involucre, para esto lo que hago es dejarle bien claro al usuario que el caso de uso será el elemento con el que al momento de hacer la entrega el podrá validar si lo que se le está entregando es lo que él acordó con el equipo de desarrollo.

Para esto, de forma coloquial, les relato lo que yo hago:

Hago una lista de todos los “deseos” que el usuario tienen para con el sistema,

A partir de estos elaboro un modelo de casos de uso que cubran todos los deseos que el usuario planteó en un principio, si es del caso se deja evidencia que algunos de estos “deseos” no serán cubiertos,

Este modelo se lo presento al usuario y con él procedo a recorrer la lista de deseos y que en conjunto deje registro cual o cuales casos de uso cubren cada uno de sus deseos (trazabilidad), evidentemente yo tengo previamente dicha trazabilidad, pero dejo que el usuario participe de dicho ejercicio y así este termina conociendo el entorno en que van a “vivir” los casos de uso que posteriormente van a ser detallados en conjunto con él.

Con este modelo de casos de uso validados me “encierro” a agrupar y ordenar dichos grupos de modo tal que pueda desarrollar el detalle de cada grupo incrementalmente. Aquí quedan medianamente definidas la iteraciones en lo que tiene que ver con la disciplina de requisitos, si el proyecto involucra las demás disciplinas entonces valido con los líderes de todas estas la pertinencia de dichos grupos.

De aquí en adelante hago lo mismo con cada grupo de casos de uso:

Planeo una reunión con el usuario para recibir el detalle necesario para desarrollar el conjunto de casos de uso. Para esto le envío previamente la porción del modelo a analizar y un conjunto de preguntas al respecto. Mientras yo preparo a partir de los documentos de que disponga material para ilustrar al usuario respecto al alcance de cada caso de uso del grupo.

En la reunión pregunto al usuario sobre los detalles respecto al conjunto de casos de uso, presento un diseño de pantalla tentativo, si es del caso elaboro un prototipo con los elementos esenciales. En esta reunión llego a acuerdos con este respecto a cada uno de los elementos que constituyen cada caso de uso, cuales son los flujos básicos y alternos, restricciones, elementos esenciales de pantalla, subsistemas involucrados, necesidades que quedaran por fuera de la solución o que serán implementadas en otro(s) caso de uso…

Con la información recopilada en la reunión, elaboro el detalle de cada caso de uso, hago el diseño detallado de pantallas, defino la trazabilidad entre los “deseos” y los casos de uso y hago una validación de viabilidad con el resto del equipo de desarrollo respecto al alcance.

Una vez tengo el detalle le envío la documentación al usuario para que la analice y presente sus observaciones al respecto

Una vez tengo retroalimentación del usuario lo cito para presentarle el grupo de casos de uso en detalle y así poder aclarar las dudas y obtener el visto bueno de este para pasar a la siguiente etapa del desarrollo. Aquí viene la frase “cualquier cambio en este conjunto de casos de uso, de aquí en adelante, conlleva el levantamiento de un control de cambios”.

Así en cada etapa del proceso involucro al usuario, pero dejando claro, que este debe obtener para poder involucrarse la visión del “conjunto” y del “detalle” del modelo, además que este es documento que define el acuerdo entre él y el equipo de desarrollo.

Quedo atento a sus observaciones respecto a mis tácticas para “motivar” al usuario.

Comentario 7

Hola José García,

Acabo de leer tu comentario sobre este debate, y déjame compartir que coincido contigo cuando dices: “Hago una lista de todos los “deseos” que el usuario tienen para con el sistema…”. Sin embargo, permíteme iniciar un debate contigo, y con quienes apoyan tu argumento y con los que apoyarían el mío; y es cuando afirmas: “… tengo la firme convicción de que si el usuario no se hace partícipe de la elaboración de los casos de uso estos no terminan sirviendo para nada, recordemos que estos son esenciales como materia prima de todo lo que se hará de ahí en adelante y como elemento que permite validar si el software si cumplió con el alcance…”

Importante: Pido por favor, a experiencia propia en debates, aquí en LinkedIn, que se tome los comentarios, fundamentos, argumentos, discrepantes como un aporte a la discusión o debate sobre un tema. Ya que en varias oportunidades dichas discrepancias muchos lo toman a modo personal o de ‘ataque’. Sería genial que en este grupo y en este en tema, en particular, las cosas sean alturadas y profesionales.

Empiezo con lo primero. Me encanta, al igual que a José García, invitar a los ejecutivos del negocio a que visionen su solución ideal. Inclusive, me gusta ampliar o aportar ideas nuevas sobre sus ideales. Me fascina ver los ojos brillosos de aquellos ejecutivos cuando les dices que sí se puede hacer lo que ellos desean.

Claro que todo con suma cordura y con los pies bien puestos sobre la tierra. Siempre acomodo los deseos de los ejecutivos del negocio, sobre su futura solución, a lo que uno, como especialista en soluciones de negocio, puede hacer por ellos. Siempre aterrizo sus ideas en situaciones reales; pero siempre acompañando el sueño de los ejecutivos del negocio.

Como experiencia les cuento que uno de mis últimos proyectos, me invitaron a una convocatoria a participar en una propuesta de solución. El negocio tenía un proceso muy caro; además, era un proceso distintivo del negocio (core_business). En cifras redondeadas, el proceso costaba cerca de un mes y medio en realizarlo, con más de 10 personas involucradas. Si hacemos una multiplicación simple, el proceso era muy costoso. Por otro lado, solo se podía hacer un proceso a la vez. Los especialistas en proceso de negocio hicieron un análisis, y prepararon un documento de alcance, donde, principalmente, tenían como objetivo reducir ese tiempo a la mitad; es decir, más o menos a dos semanas, haciendo re-ingeniería y simplificación de procesos.

Cuando nos tocó a nosotros, y con la modestia que corresponde, quien les escribe lideró dicho proyecto. Luego de que la analista de procesos del negocio hizo su exposición sobre la situación actual y de la solución que ellos habían concluido, pues me puse súper atrevido con las ideas y aportes. Recuerdo con mucho agrado cuando les decía: “… para soluciones este problema en particular, yo les propongo tal solución…”, luego continué con: “… y para este problema específico, recomendamos esta solución…”. Y así, continué con más aportes a la iniciativa de solución de ellos.

Luego me vi sorprendido con las siguientes preguntas de los ejecutivos del negocio: “… Gerardo, ¿y se puede hacer esto, y lo otro?”, y lo les respondía, con los pies sobre la tierra: “… por supuesto; inclusive, podríamos hacer esto, y además este otro…”. Lo cierto es que los ejecutivos de negocio quedaron estupefactos con las soluciones que nosotros ofreceríamos como valor agregado a la alternativa de solución que ellos habían determinado.

¡Ha! Pero no todo fue de color de rosas. Los ejecutivos de negocio, a las iniciativas nuestras, de muy optimistas con nuestras soluciones, nos pidieron un prototipo demostrando que todo los que nosotros ofrecíamos era cierto. Y así fue. A los dos días, volvimos a visitarlos con nuestro prototipo, y ellos quedaron más que entusiasmados con los resultados.

El beneficio de toda esta pro-actividad en propuestas de solución d negocios, el cliente de sistemas nos adjudicaron el proyecto. Al pasar los meses que duró el desarrollo, ahora el negocio cuenta con una solución de que no solo logró reducir los tiempos a la mitad del tiempo; sino que se logró reducir el tiempo de, proceso del negocio en un promedio de 10 minutos, sobre el mes y medio que les tomaba a ellos hasta entonces.

Con esta experiencia quiero corroborar que los negocio no necesariamente tienen la solución ideal en el documento de alcance que ellos elaboran; sino que es muy importante la habilidad, la experiencia y, principalmente, la creatividad que podemos tener al momento de replantear las alternativas de soluciones con otras mucho mejores.

Sin embargo, discrepo con José García cuando afirma que los usuarios (finales) (ejecutivos del negocio) son esenciales como materia prima para solución. Como siempre digo: “Los usuarios no siempre tienen la razón.”. Y la explicación, en base a la experiencia, es bastante simple. Y aquí otra anécdota.

Antes de compartir mi experiencia, debe recordar, o recalcar, la razón de ser de las tecnologías de información en los negocio. Todo negocio, con fines de lucro, siempre están en la constante búsqueda de la rentabilización de sus procesos. Es decir, reducir los costos y aumentar los ingresos. Y las tecnologías de información son un pilar para este objetivo.

Una vez me tocó automatizar un proceso de un negocio. Utilicé, cuando era aún muy joven en esta profesión, el tradicional método de entrevistar a los usuarios finales (ejecutivos del negocio) para ‘levantar información’, y a partir de eso diseñar la solución.

Lo cierto es que los usuarios nunca tenían la visión del negocio. Dichos ‘usuarios finales’ solo requerían que los sistemas tengan lo que a ellos les parecía ventajoso para el negocio. Es decir, pedían muchos reportes con indicadores de gestión y de análisis, pero eran reportes que ellos les habían enseñado en las escuelas. Pero ninguno de aquellos reportes estaban vinculados con la estrategia del negocio: Menos costos, y más ingresos. Simplemente, cada gerente y jefatura, hacían sus requerimientos como a ellos mejor les parecía.

Está claro que en esta oportunidad, al negocio le faltaba mucha integración de sus objetivos gerenciales con los del negocio, pero así funcionaba este negocio, y así funciona muchos de los negocios también.

Al final, terminé diseñando una solución que no aportaba ningún valor al negocio. A pesar que estaban estrictamente a la medida de los ejecutivos del negocio. Y dicho sea verdad, ´nunca generó valor el sistema al negocio, ya que, al contrario, generó sobre costos al negocio, ya que se requería invertir en infraestructura tecnológica, contratar más personal.

Esta experiencia me enseñó que los usuarios finales no siempre tienen la razón. Y para sortear esto, y ser más efectivos en nuestra propuesta de solución, debemos conocer mucho más el negocio y su modelo, sin necesidad de entrar en la dependencia de los ejecutivos del negocio del momento.

A partir de esa experiencia, antes de tener mi primera entrevista con mi cliente de sistemas, averiguo exhaustivamente sobre su modelo de negocio. Consulto con colegas y amistades profesionales sobre los problemas típicos que tienen ese tipo de negocio, planteamos las posibles soluciones, y finalmente llego a esa primera entrevista con una solución ideal sobre ese negocio. El beneficio de este ejercicio es el caso de la primera anécdota que les mencioné en la segunda parte de mi comentario.

Comentario 8
Si algo tengo claro es que a la hora de “modelar una solución” el usuario, cliente, stakeholder… casi nunca tiene la razón, para eso están los analistas funcionales o arquitectos funcionales. Para soportar esta afirmación tengo múltiples anécdotas que algún día les contaré.

Pero este modelo debe ser presentado a los usuarios para poder validar su alcance, para que este pueda posteriormente tener claro el marco en que funcionan las diferentes opciones de la solución.

Hay que tener cuidado con validarlo contra “lo que el sistema debe hacer”, no dejarse llevar por el usuario hacia “como el sistema lo debe hacer”, y esa es una de las competencias que se debe tener: expresar los deseos del cliente en términos de lo que el sistema debe hacer, sobre los objetivos del sistema, no sobre como el sistema debe implementar estos deseos. Así es posible ser creativo al momento de modelar y se hace factible la validación de los deseos.

El asunto es, ¿cómo expresar el modelo que enmarca la solución?, yo lo plasmo en un modelo de casos de uso + modelo de clases, para poder posteriormente hacer un seguimiento detallado del alcance planteado al usuario (cronograma, tiempos, esfuerzos, funcionalidad…), no he encontrado otra herramienta más adecuada que los casos de uso. En un punto no son más que la descripción del alcance de cada uno y posteriormente se detalla cada uno de estos, en este proceso es que el usuario debe participar, validando el alcance, definiendo las características de los campos que se incluyen en cada especificación de pantalla.

Con esto se garantiza que las expectativas del usuario con respecto al sistema son formales, que no se tengan ambigüedades, para que al momento de hacer entrega no se presenten malos entendidos.

Comentario 9

De acuerdo contigo con los primeros argumentos, José García. Respecto a lo segundo, que utilizas casos de uso y modelos de clases, allí hago una excepción, ya que son documentos (en las formas) más tecnologías o proyectos, que lenguaje de negocio. En ese caso, cuando tengo que presentar a los usuarios (ejecutivos de negocio) las propuestas, siempre trato de hacerlo con leguaje e ilustraciones de negocio, como diagramas de flujos; ya que los otros no comprenden. Ellos (ejecutivos de negocio) ven a su negocio como un flujo de información, donde ven procesos, documentos, datos, cálculos, reportes, reglas del negocio, etcétera. Los casos de uso son ilustraciones más técnicas (de tecnología) que de negocio. Los modelos o diagramas de clases son más de arquitectura, que de negocio. Y lo más importante es que los ejecutivos del negocio comprendan de una mejor forma lo que su futuro sistema hará por ellos. Otra alternativa son los diagramas de dominio, que contienen elementos de casos de uso más flujos de procesos.

Pueden seguir la discusión, accediendo al grupo Análisis Funcional en la red LinkedIn de mi amigo quien lo administra: Daniel Mónaco.