Toma de Requisitos - Paso 1: Usuarios clave

Los usarios clave deben aportar valor

Los usuarios clave nos van a permitir definir los requisitos principales del producto, y nos van a guiar en las fases posteriores.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Éstos usuarios deben seleccionarse de forma que sean:

• Abiertos
• Capaces de aportar
• Conocedores del negocio
• Involucrados en la solución
• Sin motivaciones ocultas
• Variados funcionalmente

Abiertos

Deben ser abiertos, para que estén dispuestos a contar libremente lo que necesitan. Deben estar abiertos a dar sus necesidades actuales, abiertos a incorporar en su negocio las posibilidades tecnológicas.

Capaces de aportar

Han de ser capaces de aportar, de expresar lo que necesitan. Un usuario puede ser conocedor del negocio y abierto, pero si no es capaz de expresar lo que quiere...tenemos un problema.

Conocedores del negocio

El motivo de ser conocedores del negocio, está claro: han de aportar las cosas de forma que si un usuario clave dice que una característica es necesaria, o que debe cumplirse de una forma específica, sepamos que lo que dice es importante, y que realmente es necesario. Al contrario, si un usuario clave te dice claramente que algo puede no implementarse, y que dicha característica no es necesaria, créeme que es mejor que la quites, y que la quites ya.

Involucrados

La involucración es fundamental. Los usuarios clave han de estar dispuestos a dar su tiempo. Y nosotros debemos respetar ese tiempo, valorarlo, agradecerlo, y demostrarlo.

Motivados

El tema de la motivación es complejo. Muchas veces, a pesar de concurrir todas y cada una de las características anteriores, un usuario tiene motivaciones ocultas. Si es así, y dichas motivaciones no están alineadas con el negocio corporativo, es posible que surjan aplicaciones con funcionalidades contradictorias, o que sin tener apariencia contradictoria, hagan que su uso no sea consistente. Las motivaciones ocultas las he visto siempre más orientadas a las luchas internas de poder en las empresas, entre departamentos o áreas de negocio. Pero pueden producirse otros casos similares, y hay que vigilarlos.

Variados funcionalmente

¿A qué me refiero con variados funcionalmente? Pues que los usuarios clave deben abarcar el conocimiento de toda la funcionalidad del sistema a construir. Esto es muy fácil de decir, porque hasta que no esté construido el sistema, y se pruebe que es el adecuado, no sabremos quién tenía el conocimiento. Aquí de nuevo, entra la experiencia: lo obvio son las áreas funcionales del tipo "compras", "ventas", "almacén", etc. Donde ya no es tan obvio es en la definición de interacciones (requisitos de interfaz), u otros requisitos no funcionales.

En proyectos internos, es posible que los responsables recluten y proporcionen usuarios reales que estén involucrados en el proyecto y quieran dar sus visiones. Pero en proyectos llave en mano, o  externos, también es posible utilizar estas técnicas.

En cualquier caso, es importante planificar y estructurar adecuadamente el tiempo que dedican los usuarios clave. Esto lo veremos más adelante, en los pasos siguientes de la toma de requisitos.

Volver al Índice de pasos para la Toma de Requisitos.