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:
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:
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
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
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.
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:
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.
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
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.
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:
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.
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
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:
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:
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]
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
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]
Publicar un comentario
Quiero dejar un comentario