Negative job
4. Poor remuneration: Possibly symptomatic of other problems, low uncompetitive remuneration is nonetheless often reported as one of the components that detracted
2.11 STRATEGIES FOR IMPROVING JOB SATISFACTION
Originalmente las actividades relacionadas con la incorporación o mejora de la usabilidad del software se asignaban específicamente a especialistas en el área del diseño de la interfaz. Las actividades relacionadas con técnicas y prácticas HCI únicamente podían realizarlas expertos en usabilidad ya que teóricamente únicamente ellos cuentan con el conocimiento necesario para desarrollarlas con eficacia. En los últimos años dentro de la IS se ha estudiado y reconocido la importancia de involucrar a otros elementos del equipo para lograr un nivel de usabilidad adecuado del software que se está desarrollando. El hecho de que el concepto de usabilidad se atribuya únicamente a los expertos en la materia se considera un obstáculo para una mejor comprensión de la importancia de este factor como atributo fundamental de la calidad del software (Seffah A et al., 2004). Por falta de conocimiento de todos los elementos del equipo sobre usabilidad muchas veces un nivel adecuado para este atributo no se alcanza o definitivamente no se considera para el software.
0 5 10 15 20 25 Interaction design first Minimal Up front design Implicit Interaction Design Overlapped Track Not Specified Usability Testing Scenarios Persona Contextual Inquiry Protoypes Contextual Design Story Boarding Heuristic evaluation
Independientemente de la metodología utilizada en un proyecto de software los desarrolladores tienen la relación más cercana con el diseño o quien lo realiza ya que les impacta en primera instancia en la implementación. Por lo anterior se han generado varias recomendaciones HCI enfocadas a involucrar a estos elementos del equipo en el tema de usabilidad (Juristo et al., 2007) (Seffah et al., 2009). Uno de los factores que se señalan para mejorar la percepción de la importancia de la usabilidad en el desarrollo de software es que todos los elementos del equipo cuenten con la preparación o información necesaria sobre el tema. Por medio de talleres, preparación profesional o guías que les proporcionen suficiente información que les permita entender e incluso utilizar técnicas de usabilidad durante el proceso de desarrollo aunque no sean especialistas o expertos en HCI (Juristo et al., 2007) (Seffah et al., 2009) (Carvajal L. et al., 2013).
Tomando en cuenta lo puntualizado anteriormente la situación se observa también en los equipos ágiles principalmente por la característica de multifuncionalidad y auto organización. En caso de no contar con un experto en HCI y con el conocimiento necesario, todo el equipo de desarrollo ágil tiene la capacidad para desempeñar actividades de diseño relacionadas con usabilidad. Los resultados obtenidos hasta el momento a través del análisis de la literatura proporcionan información que permite identificar factores y definir recomendaciones. A continuación se describen las diferentes clasificaciones que identificamos en cuanto a quién aplica las técnicas HCI y cómo se organizan los equipos ágiles durante el proceso de desarrollo en el que se incorporaron éstas.
En relación con el responsable del diseño de la interacción y por ende aplicar las técnicas de usabilidad en el equipo ágil identificamos los siguientes roles:
Experto, representa aquellos especialistas de diseño como los expertos UX, expertos en usabilidad, expertos HCI, expertos UCD y diseñadores gráficos expertos.
No experto, se refiere a aquellos miembros del equipo sin formación como especialistas HCI que están enfocados a diseñar la interacción. Los desarrolladores pueden representar este rol en el proceso ágil.
En cuanto a la división de actividades de diseño e implementación se identifican las siguientes formas de organización en los equipos ágiles:
Equipos independientes. Donde un equipo – grupo de especialistas en HCI, elementos que desempeñan el rol de diseñadores, un especialista HCI o un elemento que desempeña el rol de diseñador - desarrolla las actividades de diseño y otro equipo las tareas de implementación. Hay dos posibles situaciones en este caso. El primero es el que se da cuando existe una colaboración cercana entre estos dos equipos. Durante todo el proceso de desarrollo ambos equipos participan en el diseño de la interfaz y durante la etapa de implementación, un constante feedback entre ambos equipos es un punto medular. La otra situación que se observa es la que se presenta cuando la comunicación entre los dos equipos únicamente se da durante la entrega del diseño a implementar por el equipo de desarrollo y posteriormente no existe mayor comunicación durante el resto del proceso.
Equipo cross-functional. El equipo está conformado por desarrolladores, diseñadores UI, expertos UCD, stakeholders y Project managers. Todos los elementos del equipo se involucran durante el diseño y durante la etapa de implementación.
Las figuras C2-21 y C2-22 muestran las distribuciones obtenidas de acuerdo al tipo de organización de los equipos ágiles al aplicar técnicas HCI. Los resultados se obtuvieron durante nuestra revisión de literatura a partir de la información recabada de aquellos proyectos en donde se tenía información suficiente para identificar este dato. Aquellos estudios donde no se mencionaba específicamente colaboración entre los equipos se clasificaron en la categoría “Not specified”. De manera similar a los apartados anteriores presentamos los resultados considerando las dos etapas de búsqueda. La figura C2-21 muestra la distribución
obtenida en la revisión para el período 2000 – mid 2013 publicada en (Caballero et al., 2016) y la figura C2- 22 muestra la distribución actualizada incluyendo hasta el primer trim. 2017.
Figura C2-21 Organización de los equipos ágiles trabajando HCI en el proceso de desarrollo. Período de análisis 2001 – primera mitad de 2013 (Caballero et al. 2016)
Figura C2-22 Organización de los equipos ágiles trabajando HCI en el proceso de desarrollo. Período de análisis 2001 – primer trimestre de 2017
Se observa en ambas distribuciones que los equipos mantienen su preferencia por trabajar sus tareas de diseño e implementación de manera independiente pero colaborando cercanamente durante todo el proceso de construcción del software. Incluso incluyendo el análisis de las publicaciones para el período actualizado de búsqueda se muestra un ligero incremento en el número de proyectos donde se utilizó este tipo de organización para su desarrollo. Lievesley y Yee notaron que es esencial que el equipo de diseño trabaje independientemente del equipo de desarrollo en las etapas creativas tempranas con el objetivo de preservar las valiosas distinciones en los estilos de trabajo Lievesley (2006). Posteriormente se requiere estar en continua comunicación para asegurar una cadena paralela de trabajo. Ferreira et al. (2007) describen como las iteraciones contribuyen a mejorar la comunicación y relaciones de trabajo entre los diseñadores y los
0 5 10 15 20 25 30 35 40 45 Cross-functional team Independent / Close collaboration Independent / No collaboration Not specified 0 10 20 30 40 50 60 Cross‐functional team Independent Close collaboration Independent None collaboration Not specified
desarrolladores de software. En su modelo de bloques paralelos Sy (2007) sugiere que durante los ciclos iniciales los desarrolladores deben iniciar trabajando sobre la arquitectura que tendrá la codificación del software o en características importantes que solamente necesiten mínimo diseño. De esta forma los diseñadores en esas etapas tempranas tienen tiempo para realizar las actividades necesarias de diseño y preparar las interfaces a ser implementadas en los ciclos posteriores. Una vez iniciados los ciclos de implementación a los diseños previos es importante que los diseñadores trabajen de manera cercana con los desarrolladores para responder preguntas sobre el diseño que está siendo desarrollado.
Siguiendo este mismo enfoque de equipos independientes con cercana colaboración Coatta et al. (2010) señalan que el equipo UCD y el equipo de desarrollo necesitan ayudarse mutuamente. Los equipos involucrados en el proceso de desarrollo participan tanto en la definición de historias de usuario como durante todo el proceso de desarrollo Coatta (2010).
Ferreira et al. (Ferreira et al., 2007a) reportan un caso de estudio donde el equipo de desarrollo trabajó separadamente del equipo de diseño al inicio del proceso. El diseño de la interfaz de usuario fue proporcionado al equipo de desarrollo una vez que estuvo completa. Posteriormente los diseñadores realizaban pruebas diarias desde la perspectiva de diseño y apoyaban a los desarrolladores con explicaciones más amplias a dudas que estos consultaban respecto al diseño propuesto. Ferreira et al. (2007) observaron que trabajando de esta forma puede tener ventajas como mejorar las pruebas de usabilidad y la relación entre los diferentes equipos. Los grupos de desarrollo de software de las dos compañías observadas por (d. Silva et al., 2015) están conformados por diseñadores UX y desarrolladores. Independientemente de la ubicación física en la que se encuentren (algunos se integran en uno solo espacio como equipo) tienen una cercana colaboración durante todo el proceso de desarrollo. En una de las compañías los elementos que se encargan del diseño UX trabajan en varios proyectos mientras que en la otra compañía el equipo UX apoya a un solo proyecto. Las actividades de usabilidad se desarrollan principalmente por los elementos expertos HCI. En (McGinn et al., 2013) el equipo UX trabaja de manera cercana con el equipo de desarrollo durante los sprints dedicados a la implementación de código de las funcionalidades respondiendo preguntas, proporcionando retroalimentación y ajustando el diseño en caso de ser necesario.
Los proyectos que reportan haber trabajado de manera independiente el diseño y la implementación con mínima o ninguna colaboración entre los equipos responsables de cada actividad generalmente observaron algunas complicaciones durante el proceso de desarrollo. Trabajar por separado puede representar problemas para los equipos, principalmente por falta de comunicación y coordinación entre las actividades que realizan. En (Chamberlain et al., 2006) los autores reportan la experiencia de trabajo con dos equipos independientes y además ubicados en diferentes lugares. La ubicación de los equipos resultó un factor que interfirió en la colaboración de los dos equipos generando problemas. El equipo de diseño decidió no utilizar la metodología ágil, en este caso SCRUM, para llevar la gestión de sus actividades.
En el caso de los equipos cross-functional uno de los principales beneficios observados es una mejor comunicación dentro del equipo sin embargo también pueden darse situaciones en donde ésta no se produzca de manera eficiente. Najafi et al. (Najafi et al., 2008) comparan los resultados de dos equipos cross-functional trabajando proyectos de software con metodologías ágiles. Uno de los equipos presentó problemas debido a que los roles del diseñador HCI y el desarrollador se distanciaron durante el proceso. Los diseñadores no estaban informados sobre las características que estaban siendo implementadas en los sprints lo que impactaba en actividades clave como las pruebas con el usuario, generando constante cambio en los requerimientos. En el segundo proyecto el equipo encargado de las actividades relacionadas con la experiencia de usuario fue considerado durante todo el proceso de desarrollo utilizando artefactos HCI en cada actividad.
Una de las estrategias utilizadas por Cho (2009) para identificar las metas de los usuarios y mejorar la comunicación del equipo fue usar el equipo cross-functional. Conformado de esta manera todos los elementos del equipo intercambian ideas sobre la manera en la que deben construirse las características a ser implementadas. En las reuniones los diseñadores de interfaz presentan especificaciones de diseño de baja fidelidad con el objetivo de construir un consenso de equipo. Se identifican dependencias externas, requerimientos funcionales adicionales así como necesidades del negocio. Los roles HCI son parte del equipo y apoyan a los desarrolladores durante el sprint.
Tzanidou y Ferreira (2010) apoyan la creación de equipos cross-functional para garantizar la continua participación del diseñador de interfaz durante todo el proceso de desarrollo. De esta manera se asegura que los desarrolladores mantienen la consistencia en la interfaz de usuario como fue especificada por la guía de estilo o maqueta definida. Parson et al. (2007) identifica la cercana colaboración entre un equipo cross- functional como uno de los factores clave para una integración exitosa de las técnicas HCI en el enfoque ágil. Los elementos del equipo además de los conocimientos propios de su rol cuentan con conocimientos suficientes que les permiten compartir ideas en conjunto sobre el diseño durante todo el proceso de construcción del software. En (de Freitas et al., 2016) parte del equipo ágil se encargaba de diseñar los prototipos cuya usabilidad sería evaluada utilizando el método AGILUS mientras otros elementos del equipo implementaban el código de aquellas funcionalidades aprobadas previamente.
El equipo de desarrollo del estudio presentado por (de Carvalho et al., 2016) no contaba con especialistas UX, sin embargo ejecutaron sin problema las evaluaciones de usabilidad. El equipo aplicó durante una etapa inicial antes de los ciclos de desarrollo e incluso durante éstos técnicas HCI como persona, prototipos y heurísticas.