 |
| Reuniones según Dilbert |
Esta entrada forma parte de una serie cuyo índice es el siguiente:
- Identificación de usuarios finales clave.
- Entrevista a dichos usuarios finales.
- Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
- Presentación del prototipo a los usuarios finales, solicitando feedback.
- Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
- Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
- Utilizar el prototipo como la primera línea de base de los requisitos.
- Escribir una documentación de usuario detallada, basada en el prototipo anterior.
- Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.
Para poder identificar los requisitos preliminares, es habitual llevar a cabo entrevistas (reuniones) con los usuarios clave, principalmente. A partir de los requisitos que se identifiquen, se creará posteriormente un prototipo que permita identificar la interfaz de usuario, y el flujo de la aplicación.
Steve McConnell, en su "Software Project Survival Guide" ya avisa de que los programadores, la gente que nos dedicamos al desarrollo de software, no somos buenos diseñando software que realmente guste a los usuarios. La buena noticia, es que sí que podemos ayudar a los usuarios clave a descubrir lo que les gusta, gracias a que los propios usuarios tampoco suelen ser buenos diseñando software.
Cómo preparar las entrevistas: Fases
Fase 1: Preparación previa.- Fijar objetivos
- Seleccionar los asistentes (en realidad esto ya lo hemos hecho en el paso anterior de la toma de requisitos: seleccionar a los usuarios clave).
- Acordar con los asistentes el día, hora, lugar y duración de la reunión, al menos inicialmente.
- Hacer los deberes: obtener información previa de los usuarios clave que van a asistir, sus necesidades, su negocio, las aplicaciones o productos que utilizan, los proveedores de servicios actuales...vamos, auténtica labor de detective.
- Preparar un orden del día, así como los materiales necesarios.
- Comunicar el orden del día a los asistentes
- Enviar la convocatoria de la reunión a los asistentes, gestionando las confirmaciones, de forma que se replanifique la fecha, hora o lugar si es necesario.
- Crear expectativas. Esta es la parte más delicada: es posible manejar las expectativas de los usuarios clave desde antes de la propia entrevista de recogida de requisitos.
- Hacer preguntas claras. Honestidad y sinceridad. Queremos solucionar los problemas del cliente.
- No debemos obsesionarnos con la tecnología.
- No debemos obsesionarnos con el cómo ni el cuándo, sino con el qué. Debemos aclarar qué necesita.
- Humildad. Solemos intentar proponer sistemas maravillosos cuando en realidad el cliente ya tiene sistemas muy buenos que cubren un porcentaje grande de sus necesidades. Es importante empezar aprendiendo (además del trabajo previo que ya deberíamos haber hecho) de qué y cómo se hace actualmente.
- Una vez aclarado el qué, podemos pasar al cómo, pero siempre a nivel funcional, sin tecnicismos.
- Es importante usar un lenguaje no técnico, o en todo caso, hablar en el lenguaje de su profesión o negocio, no en el nuestro. Pocas cosas hay tan irritantes como un joven friki sacando constantemente temas técnicos que no vienen a cuento.
- Limitar lo que pide el cliente o usuario clave.
- Detectar dependencias con temas que ya hayan comunicado otros usuarios clave, y anotar todo lo que se diga, ya que pueden ser pistas para lo que se trate en próximas entrevistas con otros usuarios.
- Paciencia y respeto.
- Anotar todos los detalles.
- Los plazos no son importantes aún: no está definido el alcance, ni cómo vamos a implementarlo, por lo que los plazos no deben ser un bloqueo.
- No adelantar la solución técnica. No matemos a la gallina sin haber empollado aún el huevo.
- En esta fase la temática es simple: revisar todo lo que hayamos anotado y asegurarnos de que incluso lo no anotado en la reunión, se registra y no se pierde.
- Una vez que tenemos la documentación de la entrevista, habrá que consolidarla. Reducirla. Quitar lo redundante, lo que ya se haya obtenido en otras entrevistas. Quitar lo que corresponda a otras entrevistas (con otros usuarios clave), y completar su documentación allí.
- Revisar otras entrevistas, y actualizar las dependencias entre los resultados de las distintas entrevistas.
Problemas habituales en las entrevistas de toma de requisitos
- No se entiende lo que se pide.
- Se tiende a dar una solución inmediata, en la mayoría de las ocasiones una solución técnica conocida, sin esperar a asegurarse de que realmente el requisito ha sido entendido.
- Se pierden en los detalles.
- Mayor preocupación por los plazos que por los objetivos funcionales.
- Enfasis en la tecnología, perdiendo de vista los requisitos.
- Desconocimiento de la terminología del cliente.
- Falta de paciencia. Los usuarios saben lo que quieren y hay que ayudales a expresarlo. Por sí solos, es difícil que sepan expresar todo lo que necesitan de un producto.
- Hay dependencias. Raro es que una sola persona tenga toda la información. Lo normal es que tras cada reunión, se solventen dudas que habían aparecido en reuniones anteriores con otros usuarios clave, y surjan nuevas dudas que se resolverán en entrevistas posteriores.
- Falta de limitaciones. Los usuarios no tienen límite a la hora de pedir. Y esto es un arma de doble filo: si les bloqueamos muy pronto, obtendremos usuarios insatisfechos. Si tardamos mucho, es posible que los requisitos sean difíciles de cumplir, complejos, oscuros.
