Análisis de implicados (stakeholders)

Una consulta adecuada, a tiempo y efectiva a los implicados relevantes es de vital importancia en el proceso de desarrollo de la ingeniería de los requisitos [SHA99].Veamos primero una serie de definiciones para entender que se entiende por el término implicado y cuál es su relevancia en el contexto del desarrollo de sistemas interactivos:

Un implicado en una organización es (por definición) cualquier grupo o individuo que puede afectar o puede ser afectado por la consecución de los objetivos de la organización [FRE84].

Los implicados son esos participantes (en el proceso de desarrollo) junto a cualquier otro individuo, grupo u organización cuyas acciones pueden influenciar o ser influenciados por el desarrollo y uso del sistema, ya sea directa o indirectamente [POU99].

La la imagen anterior está tomada de la Guide to Experience Mapping de adaptivepath.
Los implicados son personas u organizaciones que serán afectadas por el sistema y que tienen influencia directa o indirecta en los requisitos del sistema [KOT97].
El implicado es cualquier persona cuyo trabajo será alterado por el sistema, aquél que proporciona u obtiene información de él o incluso aquél cuyo poder o influencia dentro de la organización variará con su puesta en funcionamiento [DIX93].

Clasificación de los implicados

Existen varias propuestas para clasificar los implicados de un sistema interactivo, siendo la más simple la que se basa en dividirlos entre aquellos que utilizaran el sistema directa o indirectamente [NEW95]:

• Directamente:
  • Ingenieros de software responsables del desarrollo.
  • Usuarios finales.
  • Etc.
• Indirectamente:
  • Directores de los usuarios que son responsables del trabajo de éstos y los que están relacionados con el desarrollo del sistema.
  • Socios y/o proveedores tecnológicos.
  • Etc.

Hasta propuestas tan detalladas como la propuesta en [MAC94], que identifica cuatro categorías de implicados:

• Los responsables del diseño y el desarrollo.
• Los que tienen un interés financiero o económico (responsables de la venta o compra).
• Los responsables de su implantación y mantenimiento.
• Los que tienen interés acerca de su uso (los usuarios).
• Y aunque existen otras clasificaciones -que no vamos a mostrar- el aspecto que en todas ellas queda perfectamente definido es que el usuario final del sistema es un implicado más; un implicado directo y muy especial. De ahí que en nuestro modelo, como a continuación veremos, se trate el análisis de las características del usuario de forma separada del resto de los implicados.

Identificación de los implicados

Los implicados normalmente, aunque no siempre, se identifican por sus roles más que a nivel individual y son tan importantes los que están principalmente interesados en el problema a resolver (usuarios finales, etc.) como los interesados en la solución (diseñadores del sistema, etc.).

Su identificación no es una tarea obvia, más bien todo lo contrario (aunque cierta literatura de los sistemas de información así lo cree), y con este objetivo existen varias aproximaciones metodológicas.

Seguramente por esta falsa creencia durante mucho tiempo las propuestas de la Ingeniería de los requisitos olvidaron este aspecto. Por poner un ejemplo, en el Método de la Ingeniería de Requisitos KAOS [LAM91] no menciona nada acerca de la identificación de los implicados, los asume de forma «natural».

En todo proyecto existe un grupo de implicados «elementales», obvios, cuya identificación resulta muy fácil, pero deberemos realizar un esfuerzo especial para la identificación de los que no son tan elementales.

El objetivo es encontrar todos los implicados, incluso aquellos que pueden influir negativamente en el proyecto.

Una de las propuestas metodológicas que explica cómo identificar los implicados en un sistema interactivo es la que proponen tres autores del Center for HCI Design y Computer Science Department (UK) [SHA99], que a partir de una particular clasificación de las diferentes categorías de implicados centralizados en una línea base -baseline- proponen explorar la «red de implicados» a partir de dicha línea base.

La particular clasificación identifica los siguientes implicados en la línea base usuarios, desarrolladores, legisladores y los que toman decisiones. Para su identificación proponen cuatro puntos clave: (i) utilizar técnicas participatorias como la Observación de Campo o el Prototipado Contextual, puesto que no es lo mismo intentar identificar dichos usuarios en el lugar donde la acción se realiza que fuera de ella; (ii) estar muy atentos, los implicados pueden ser internos al equipo, internos a la organización o externos a cualquiera de ellos; (iii) considerar el ciclo completo de las actividades de negocio (pueden aparecer implicados «por sorpresa» que aparecen en momentos que no habíamos previsto), y (iv) considerar el ciclo de vida completo del desarrollo y no hacerlo sólo en la fase inicial.

Reunión con implicados

Una vez identificados los implicados, debe procederse a obtener toda la influencia relativa al proyecto que éstos pueden aportar al mismo. Una de las formas más habituales de obtener esta información es la realización basándose en la planificación de una serie de reuniones de implicados (Stakeholders Meetings).

Niegel BEVAN propone el siguiente método para realizar una «reunión de implicados» [BEV00b]:

Planificar una reunión de un solo día, invitando a los implicados que tienen conocimiento sobre las intenciones de los usuarios y de su uso, incluyendo:

• Responsable del negocio (business manager).
• Responsable del proyecto (project manager).
• Usuario/s representativo/s.
• Responsables de marketing.
• Desarrollador/es.
• Responsables de la formación.
• Responsables del mantenimiento.
• El miembro del equipo de desarrollo encargado de esta reunión preparará una lista con todas las cuestiones a ser tratadas durante la reunión.

Las principales recomendaciones para preparar esta reunión son:

Antes de la reunión:

• Identificar puntos clave que necesitamos explorar.
• Proporcionar la agenda y el listado con los puntos a tratar a todos los participantes.
• Durante la reunión:
• Una vez discutidos los puntos clave deberemos intentar obtener un consenso en aquellos puntos donde haya habido incertidumbre o disconformidad.
• Si se ha echado en falta información, deberá acordarse cómo se obtendrá.
• Realizar una discusión sobre temas «menores».

Después de la reunión:

• Obtener toda la información que faltaba.
• Si la información no es fácil de obtener, organizar un estudio de campo para observar a los usuarios en su ambiente de trabajo. Por ejemplo, en un sistema educativo investigar cómo se realizan la enseñanza, el aprendizaje y las actividades de soporte actualmente.

Proporcionar a todos los participantes un resumen con las conclusiones de la reunión.

Objetivo de la reunión

Durante la preparación de la reunión y mientras dura ésta no podemos olvidar el verdadero objetivo para el cual realizamos dicha reunión, que no es otro que recoger y acordar información sobre:

• ¿Por qué se desarrolla el sistema?, ¿cuáles son los objetivos a cumplir?, ¿cómo se medirá el éxito del mismo?.
• ¿Quiénes serán los usuarios del sistema y cuales son sus objetivos?, ¿Cuáles de ellos usarán el sistema?, ¿cuál es su nivel de experiencia?.
• ¿Cuáles son las restricciones tecnológicas y del entorno?.
• ¿Qué funcionalidades serán claves para satisfacer a los usuarios?.
• ¿Cómo se usará el sistema?, ¿cuál es el flujo de trabajo global?, ¿cuáles son los escenarios típicos de cómo y por qué los usuarios interactúan con el sistema?.
• ¿Cuáles son los principales objetivos de usabilidad?.
• ¿Cuán importante es la facilidad de uso y de aprendizaje?.
• ¿Cuánto tiempo debe suponerles a los usuarios completar determinadas tareas del sistema?.
• ¿Es importante minimizar el número de errores?.
• ¿Qué estilo de Interfaz Gráfico debe seguirse?.
• ¿Cómo recibirán asistencia los usuarios?.
• ¿Existen algunos conceptos iniciales a tener en cuenta en el diseño?.
• ¿Hay competencia? (algún otro sistema que realice lo mismo).

Beneficios de la reunión

Los beneficios directos posteriores a dicha reunión son:

Asegurar que se han identificado todos los factores relativos al uso del sistema antes de empezar con el diseño del mismo.
Juntar todas las personas relevantes al desarrollo para crear una visión común.
Proporcionar las bases para las posteriores pruebas de usabilidad.

Recomendaciones

Si es posible, deberá realizarse esta reunión antes de que los requisitos funcionales hayan finalizado, aunque la reunión es importante incluso si el diseño centrado en el usuario se ha introducido tarde en el proceso de desarrollo (este caso, como ya se ha visto con anterioridad, el impacto en el proyecto será mayor cuanto más tarde se produzca este hecho).
Todos los implicados deben asistir a la primera reunión. Posteriores reuniones suelen ser sólo con los directamente relacionados con detalles concretos.
Si no fuera posible realizar la reunión con los implicados la información puede recogerse mediante entrevistas a los implicados identificados. En este caso, el principal inconveniente es que no tendremos ninguna oportunidad de establecer un consenso entre todos ellos.
La identificación de implicados ha sido un factor verdaderamente fundamental en varios de los proyectos realizados. Por poner un ejemplo, en el caso del proyecto de la recepción si no se hubiesen identificado los implicados precisos y no se les hubiese incluido en varias de las sesiones de evaluación el proyecto habría fracasado totalmente. A continuación podemos ver los implicados identificados y su importante en el sistema:

• Director comercial:

Dispone de toda la flota de agentes comerciales que con sus visitas a clientes y obras realizadas serán una de las principales fuentes de donde el sistema nutrirá la base de datos multimedia.
Conoce a todos los clientes, sus preferencias y en muchas ocasiones cuando visitarán la empresa.

• Agentes comerciales:

Son una fuente de datos para el sistema
Deben tener un buen conocimiento de qué información está disponible en el sistema para hacer el mejor uso de ella.
Gerente:
En definitiva, es quien ha decidido la filosofía del sistema, por tanto, debe seguir su manera de pensar para que refleje sus necesidades.
Instalador del sistema audio-visual
La instalación precisa de equipamiento adicional como la propia pantalla o el proyector, y si hubiésemos obviado al socio tecnológico hubiese resultado imposible casar la tecnología con el sistema.