Los Malentendidos entre Desarrolladores y Usuarios de Sistemas de Información (y II)
Como ya comentaba en el post anterior Los malentendidos entre desarrolladores y usuarios de Sistemas de Información (I), se han investigado muy poco, de manera directa, los factores que causan los malentendidos entre desarrolladores y usuarios de sistema de información.
Algunos de los factores que se han analizado con más frecuencia son:
Habitualmente se utilizan documentos basados en papel para capturar y transmitir los requerimientos, lo que puede favorecer la ambigüedad, las omisiones y las malas interpretaciones
Usuarios y desarrolladores no comparten un marco común de referencia y no invierten tiempo elaborando un lenguaje compartido para dialogar
En muchas ocasiones los usuarios no comprenden los requerimientos reales hasta que han interactuado con versiones tempranas del sistema de información
Incluso cuando se comprenden los requerimientos, el tiempo que transcurre entre la determinación de los mismos y el despliegue del sistema de información puede que haya hecho que cambien dichos requerimientos
En el esquema siguiente hemos agrupado otros factores adicionales de gran importancia en cinco categorías:
Factores relacionados con los sesgos de los desarrolladores
La literatura sobre determinación de requerimientos está repleta de modelos, marcos, técnicas y procedimientos escritos por desarrolladores para desarrolladores y contiene muy pocos concebidos para capturar la perspectiva del usuario.
Cuando los desarrolladores se enfocan en los requerimientos aplican técnicas de modelado y análisis propias de su dominio:
Casos de uso
Diagramas entidad-relación
Análisis orientados a objetos
Lenguajes formales de especificación
Pero los usuarios conciben los requerimientos en unos términos diferentes, ya que no están interesados en cómo funciona el sistema, sino en lo que el sistema hará por ellos.
No están familiarizados con los métodos de análisis y modelado utilizados por los desarrolladores y no están interesados en aprender, por lo general, sobre objetos, actores, casos de uso, dependencias y otros conceptos propios de esos métodos.
Algunos expertos señalan que los desajustes entre las perspectivas de los desarrolladores y de los usuarios provienen de los modelos SDLC.
Estos modelos han sido creados desde la perspectiva del desarrollador, como herramientas para desarrollar una idea y convertirla en un sistema operativo y mantenible.
Muchos modelos SDLC tratan la interacción con los usuarios como una caja negra, aceptando una serie de inputs de los mismos (por ejemplo, los requerimientos) y produciendo unos outputs que se les entregan (por ejemplo, entregables, el sistema final).
De acuerdo con algunos autores, estos paradigmas son probablemente la causa principal de las experiencias insatisfactorias de los usuarios, al enfatizar las actividades de los desarrolladores.
Los modelos genéricos SDLC – cascada, prototipos evolutivos y desarrollo rápido de aplicaciones (RAD) – presuponen que los usuarios han llevado ya a cabo un análisis para determinar sus requerimientos para un sistema de información. Es debido a esta suposición que los desarrolladores esperan que se les proporcionen los requerimientos y que asumen que los mismos están completos y que no van a cambiar.
Factores relacionados con los sesgos de los usuarios
Por desgracia, el enfocar la determinación de los requerimientos en los usuarios no rectifica las diferencias entre perspectivas entre usuarios y desarrolladores. Si tanto los requerimientos (el “qué”) como el diseño (el “cómo”), se enfocan desde la perspectiva del usuario, el problema sigue siendo el conseguir la implicación de los usuarios en el diseño y como traducir dicha implicación en la construcción de un sistema de información.
Existen tres factores que crean una brecha entre requerimientos y diseño:
Inexistencia de procedimientos de desarrollo transparentes y trazables
No existen “lenguajes” comunes que hagan posible la comprensión mutua, acoplando la ingeniería de software con una perspectiva enfocada en el usuario para crear procesos de desarrollo de sistemas
No hay colaboración con éxito entre los usuarios que ejecutan las tareas y los desarrolladores, basada en unos procesos transparentes y en un entendimiento común
Las diferencias en cuanto a comunicación y comprensión entre usuarios y desarrolladores a las que apuntan estos factores, hacen necesario un marco de relaciones comunes entre ambas partes.
El problema es que, como no existen esos marcos de relaciones comunes, una o ambas partes deberían aprender algo que está fuera de su base general de experiencia.
Los desarrolladores podrían convertirse en expertos en técnicas de investigación etnográfica para mejorar su comprensión sobre el contexto del usuario y su entorno de trabajo.
Los usuarios podrían aprender uno o varios lenguajes de modelización, como el Unified Modeling Language para diseñar el sistema de información.
Naturalmente, tales consideraciones no son prácticas. La mayor parte de usuarios y desarrolladores no tienen tiempo para esas actividades o, lo que es aún más importante, disposición alguna para aprenderlas.
Otras investigaciones han demostrado que los usuarios prefieren técnicas de obtención y especificación de requerimientos tan discretas como sea posible y mantener su participación en niveles mínimos. Prefieren métodos, en definitiva, que no interfieran con su trabajo.
Puede afirmarse, por tanto, que los usuarios son tan reacios a trabajar con los desarrolladores, como estos últimos con los usuarios aunque, posiblemente, por razones diferentes.
Factores relacionados con los diferentes mundos de desarrolladores y usuarios
Usuarios y desarrolladores ven el mundo a través de marcos conceptuales, modelos mentales y perspectivas diferentes. Una interpretación de dichas diferencias es la que explica que los desarrolladores deben comprender el contexto y el entorno de trabajo de los usuarios y que los usuarios deben disponer de medios para formular sus necesidades.
Otros indicadores de que usuarios y desarrolladores operan en mundos diferentes, tiene que ver con sus metas y motivaciones:
Las metas de los usuarios están asociadas al desempeño de una función y pueden considerarse como imperativos organizativos
Las metas de los desarrolladores están relacionadas con la implantación de un sistema con calidad (en términos técnicos) y puede considerarse como imperativos tecnológicos
Desarrolladores y usuarios también tienen perspectivas diferentes sobre cuáles son los 10 primeros factores críticos de éxito para el desarrollo de un sistema (Havelka, D. & Lee, s. (2002). Critical success factors for information requirements gathering. Information Strategy, 18(4), 36):
Factores relacionados con los procesos
Una de las situaciones más habituales es enfocarse en la solución antes de que se haya comprendido verdaderamente el problema, desaprovechando oportunidades para obtener soluciones más valiosas.
La introducción de una nueva tecnología influye en las necesidades de los usuarios de maneras no previstas. Debido a que esas necesidades no se comprenden bien, se desperdician muchas oportunidades.
A medida que la comprensión del problema evoluciona en el tiempo, el concepto de los usuarios sobre las soluciones posibles también lo hace. De esta forma, pedir a los usuarios que definan sus requerimientos, firmen un contrato que creen completo y preciso y esperar que los requerimientos no cambien a medida que la comprensión de los usuarios mejora, es asegurar problemas de desarrollo.
Muchas veces los desarrolladores interpretan esta evolución natural de la comprensión del problema como una debilidad de los usuarios. Una creencia muy extendida entre los desarrolladores es que los usuarios no saben lo que quieren hasta que lo ven.
El problema no es que los usuarios no lo sepan, sino la dificultad – característica de la conducta humana – para articular lo que quieren debido a que:
Están inseguros de lo que es posible
Tienen dificultades para describir el problema
no comprenden el problema suficientemente
Cuando los desarrolladores tienen que trabajar con una información incompleta por parte de los usuarios, suelen llenar los vacíos basándose en su propia comprensión del problema, modelos mentales y experiencia, en lugar de pedir más información a los usuarios.
Factores relacionados con la comunicación
Es posible identificar cuatro tipos de problemas que pueden dificultar la comunicación durante fase de obtención y especificación de requerimientos:
Falta de pruebas, feedback y aclaraciones:
Los usuarios expresan sus necesidades con insuficiente feedback por parte de los desarrolladores para aclarar su comprensión de las mismas. No se crea una comprensión compartida de los requerimientos y la visión general. Se intenta resolver el problema equivocado. Por ejemplo, los usuarios piden a los desarrolladores que hagan que un proceso existente sea más rápido/mejor/más barato, cuando lo que se requiere es un nuevo proceso.
Brecha entre las perspectivas de desarrolladores y usuarios y sus métodos de resolución de problemas:
Los usuarios prefieren discutir el problema desde el punto de vista del negocio mientras que los desarrolladores desde el punto de vista de su modelización. Desarrolladores y usuarios operan en mundos diferentes, utilizan una terminología diferente, tienen diferentes motivaciones y no se valoran entre sí.
Incongruencia entre el problema y los interesados:
No se ha implicado a los interesados adecuados en la obtención y especificación de requerimientos y/o no están disponibles para las negociaciones oportunas o cuando es necesario resolver problemas. La cultura organizativa y el politiqueo pueden dificultar la implicación de los interesados o crear puntos de vista sesgados.
Facilitador formado, experimentado e independiente:
El facilitador suele ser el Director de Proyecto o un Analista de Negocios. Sin una formación adecuada y experiencia en la facilitación para la obtención y especificación de requerimiento, los problemas de comunicación recién descritos pasarán inadvertidos y/o no se resolverán. Si el facilitador tiene, además, vínculos con los usuarios o con los desarrolladores, se le considerará parcial y no se confiará en él.
Seguiré analizando las causas de los malentendidos entre usuarios y desarrolladores, presentaré un modelo explicativo y propondré algunas posibles soluciones en siguientes posts.
El contenido de esta entrada forma parte de mi Curso sobre La Relación Usuarios - Desarrolladores en los Proyectos de TI
SUSCRÍBETE A MI BOLETÍN DE INFORMACIÓN
Información periódica sobre mis actividades de formación y recursos de información relacionados con las mismas. Análisis de las Simulaciones de Empresa y los Juegos Serios como Tecnología Disruptiva para la Capacitación Corporativa y el Desarrollo Directivo.
[newsletter_form]