Definición de roles y responsabilidades de UX en el desarrollo de productos: el patrón RACI

En nuestro curso de asociación de productos y UX, las personas tanto en roles de UX como de productos a menudo preguntan: “¿Quién hace qué entre UX y gestión de productos?” y “¿Cómo podemos definir mejor los roles y responsabilidades?”

En este artículo, cubriremos cómo establecer roles y responsabilidades de UX a lo largo del desarrollo del producto, teniendo en cuenta los aportes de otros socios. Debido a que el desarrollo de productos Agile es colaborativo e iterativo, la matriz RACI ágil, también conocida como matriz de asignación de responsabilidades, sirve como un marco útil para planificar cómo se realizará el trabajo.

¿Qué es RAKI?

La participación en el desarrollo de productos varía según la organización y el equipo. Los profesionales de UX a menudo se preguntan quién hace qué y cuándo incorporar otros roles, como la gestión y el desarrollo de productos. RACI ayuda a los equipos a tomarse un descanso del trabajo para ver dónde deben participar otros roles.

Definición: PERO RAKI, también conocido como matriz de distribución de responsabilidaddescribe cómo las personas con diferentes especializaciones participarán en tareas tales como pasos de trabajo (como descubrimiento), actividades (como pruebas de usabilidad) y entregables (como escribir una proyección o desarrollar un prototipo).

Un ejemplo de RACI en el desarrollo de productos
El diagrama RACI, también conocido como Matriz de asignación de responsabilidades, ayuda a los profesionales a delinear sus roles y responsabilidades durante las diversas etapas del desarrollo del producto para garantizar la participación, la colaboración y la asociación con otros roles. “X” indica donde los roles no están involucrados.

Cada persona o función tiene su propia columna y cada paso, acción o resultado tiene su propia fila. Cada celda de la matriz indica la participación de la parte respectiva en la tarea. La participación se indica a través de una de cuatro letras R (Responsable), A. (Responsable, C. (consultado), tanto como yo (informado)— Como consecuencia abreviatura RAKI. Por ejemplo, en el RACI anterior, el gerente de producto es responsable de la tarea de definir objetivos y resultados clave, mientras que se debe consultar a los equipos de ingeniería y diseñador de producto/UX. La participación general del rol a nivel de fase se basa en el tipo de participación que es más evidente en las acciones y sus resultados.

Los cuatro niveles de participación del rol para cualquier tarea determinada (ya sea una fase de desarrollo de un producto, una actividad o la creación de un resultado final) se definen de la siguiente manera:

  • P= Responsable: Los roles o miembros del equipo realizan la tarea. Más de una persona puede ser responsable de cualquier tarea de desarrollo de productos. Por ejemplo, un investigador de usuarios puede ser responsable de realizar una prueba de usabilidad cuantitativa como parte de la fase de iteración y optimización del desarrollo del producto.
  • A = Responsable: Esta persona proporciona la revisión final y determina si se completará la tarea y cuándo. Debe haber una sola persona responsable para cada tarea. La rendición de cuentas es importante para la organización y el equipo. Sin ella, es difícil lograr que las personas asuman la responsabilidad y hagan las cosas. En algunos casos, la persona responsable también es responsable de la finalización del trabajo o resultado. Por ejemplo, al realizar una prueba de usabilidad, el administrador o investigador de UX puede ser responsable de la finalización general del estudio, así como de reclutar participantes, preparar el protocolo del estudio, realizar sesiones y analizar los resultados. Durante cada sesión de prueba, el gerente de producto y el ingeniero pueden ser responsables de tomar notas.
  • C= Consultado: Los roles brindan información y experiencia en una tarea. Suele haber varias personas de diferentes disciplinas y niveles marcadas con el icono DE en RACI, dependiendo de la fase de desarrollo del producto y las actividades involucradas. En nuestro ejemplo de prueba de usabilidad, el líder de UX podría consultar con el administrador de UX para obtener comentarios sobre el protocolo del estudio y ver si hay otros colegas en el equipo de UX que se beneficiarían de los resultados del estudio.
  • yo = informado: Los roles reciben información de progreso a medida que avanza la tarea. De manera similar a los roles de responsabilidad y consulta, a menudo hay muchos roles que están informados, incluidos los interesados, la gerencia y otros equipos de desarrollo que pueden verse afectados por el trabajo. Las partes informadas también pueden incluir Servicio al Cliente, Asuntos Legales, Operaciones, Marketing, Recursos Humanos y, en organizaciones más pequeñas, el Director Ejecutivo.

Los RACI son flexibles: puede definir sus propios roles y tareas de acuerdo con las necesidades de su equipo.

Ejemplos de roles de UX para incluir en RACI:

  • Diseñadores de productos (haciendo tanto investigación como diseño de UX)
  • Investigadores de experiencia de usuario
  • diseñadores de experiencia de usuario
  • Redactores y redactores de contenido
  • Arquitectos de información
  • Roles de experiencia del cliente
  • administradores de experiencia de usuario

Ejemplos de roles de socios clave para incluir en RACI:

  • Gerentes de producto
  • Propietarios de productos
  • Ingenieros
  • Maestros Scrum
  • Inteligencia de negocios

Ejemplos de tareas a incluir en RACI (agrupados por hitos de desarrollo de productos)

  • Establecer el contexto estratégico:
  • Apertura:
  • Diseño:
    • ocurrencia
    • creación de prototipos
    • Pruebas de usabilidad
  • Entrega:
    • Planificación de lanzamiento
    • Pruebas de calidad
    • Manifestación

Aunque los RACI se usan comúnmente en proyecto gestión (ejecución de tareas), que es diferente de producto gestión (entrega de valor), funcionan bien en ambos contextos para evaluar si están involucrados los roles correctos y proporcionar información donde sea necesario. El propósito de usar RACI no es planificar un gran proyecto en cascada, sino respaldar la entrega eficiente de valor a los usuarios finales.

Por qué y cuándo usar RACI

No revisar y discutir abiertamente lo que sucede en el proceso de desarrollo del producto y quién hace qué es una receta para el caos, la confusión, la duplicación de trabajo no saludable y otros problemas como:

  • Excluir roles requeridos
  • Es demasiado tarde para involucrar a la gente
  • Olvidarse de comunicar el impacto de una actividad en los demás
  • Suposición incorrecta de quién está trabajando (o no trabajando) en qué

Este comportamiento, aunque generalmente no es intencionado, sucede y es una pérdida de tiempo, ya que los equipos tienen que reconstruir más tarde. Hay 2 buenos momentos para implementar RACI en el desarrollo de su producto:

  1. Después de cualquier retrospectiva en la que la gente discutiera roles o individuos que se quedaron fuera o se presentaron demasiado tarde.
  2. Al comienzo de un nuevo sprint Scrum, incremento de producto o proyecto

Todo el equipo debe completar el RACI en conjunto, ya sea a través de un taller virtual o una reunión presencial. Los profesionales de UX pueden iniciar la idea de probar RACI como un experimento y abogar por su uso.

Según nuestra investigación con equipos de productos, RACI es especialmente útil cuando los equipos establecen el contexto estratégico y planifican la investigación exploratoria. En estas fases de desarrollo de productos, es muy común que se pasen por alto los roles y las responsabilidades no estén claras. RACI puede aclarar problemas comunes como:

  • ¿Quién está involucrado en el desarrollo de la visión, los objetivos, la estrategia y la hoja de ruta?
  • ¿Cómo podemos influir en la priorización y secuenciación?
  • ¿Podemos participar en la planificación del producto?
  • ¿Quién es responsable de entrevistar a los usuarios o partes interesadas?
  • ¿Quién debería participar en el análisis competitivo y las pruebas de usabilidad?
  • ¿Quién dirige este taller o sesión de ideas? ¿Quién más debería estar involucrado?
  • ¿Quién toma las decisiones finales de diseño? ¿Quién necesita ser pesado?

Consideraciones de rol para la responsabilidad y la rendición de cuentas

Asignar un nivel de compromiso a una tarea específica implica más que solo ver el trabajo o las descripciones del trabajo. En general, los colaboradores de UX deben ser Responsable tanto como Responsable para pasos, actividades y entregables relacionados con la investigación y el diseño del usuario. Los administradores de UX a menudo consultado en tal actividad. Otros factores que ayudan a determinar cómo se involucra un rol en el proceso de desarrollo del producto incluyen conjuntos de habilidades, relaciones con otros, conocimiento histórico del producto u organización, tiempo disponible y niveles de ambición e interés.

Por ejemplo, un gerente de producto que esté bien versado en técnicas de entrevista podría ser Responsable tanto como Responsable para entrevistas con usuarios o partes interesadas en varias etapas del desarrollo del producto. Sin embargo, en este caso, el líder de UX aún puede considerarse Responsable, si están colaborando para realizar una entrevista con un gerente de producto, o Consultas, si dan consejos sobre las preguntas de la entrevista.

Si el UX no puede participar en la entrevista por falta de tiempo, al menos algunos miembros del equipo de UX deben etiquetarse como informado en RACI para asegurarse de que el gerente de producto comparta los hallazgos y las ideas de la entrevista, ya que afectará la experiencia de UX.

Cómo saber cuándo asociarse

Roles que Responsable tanto como Responsable para una tarea determinada, debe trabajar en conjunto en una asociación de colaboración para realizar el trabajo. La persona responsable debe asegurar cómo y cuándo consultado tanto como informado Los roles están incluidos en el proceso.

Por ejemplo, un líder de UX que Responsable tanto como Responsable para realizar una investigación exploratoria, decide cuándo consultar con su administrador de UX y cuándo hablar con las partes interesadas y los líderes sobre el progreso. Si bien UX puede y debe colaborar con el producto y los ingenieros en esta tarea, siempre que compartan la responsabilidad, la responsabilidad final recae en UX.

Una vez que se establecen los roles y las responsabilidades, no significa que puedan ignorarse por completo hasta que llegue el momento de revisar los resultados o lanzar el diseño. Compruébense unos a otros en el camino. Visualizar el trabajo a realizar con RACI evita la transferencia de resultados de un equipo a otro y promueve una cultura de diseño como proceso en lugar de una cultura de diseño como servicio.

Un ejemplo de dónde puede colaborar en el desarrollo de productos.
Los roles que comparten un nivel de participación R (responsable) para una tarea determinada deben cooperar y definir claramente quién hará qué.

Conclusión

Tomarse el tiempo para discutir abiertamente lo que sucede y quién hace qué en el desarrollo de productos permite a los equipos identificar brechas en sus procesos y evitar inconsistencias comunes que restan valor a los resultados del producto. RACI puede servir como una rueda de aprendizaje para una conversación abierta sobre roles y responsabilidades.

Una vez que su equipo haya establecido puntos en común, puede terminar terminando con RACI. La colaboración frecuente a lo largo del tiempo ayuda a los miembros del equipo a comprender cuándo y cómo incorporar otros roles y deja en claro quién debe rendir cuentas, consultar e informar durante el desarrollo del producto. La colaboración no siempre será perfecta, pero el uso de herramientas como RACI puede ayudar a los equipos a mejorar tanto las asociaciones como los resultados de los productos. Use nuestra plantilla del enlace a continuación para comenzar con su equipo.

Previous post Recursos esenciales para el diseño 3D en 2022 | Shantanu Kumar | junio 2022
Next post Las 3 principales tendencias de diseño de junio de 2022

Deja una respuesta