Para dar un poco de contexto, he trabajado en varias compañías que se mostraron ágiles (principalmente SCRUM) con sus equipos de desarrollo. He sido entrenador de SCRUM. También soy un gran admirador de Lean para DEVelopment y UX. Creo que Agile y Lean proporcionan buenos marcos para la productividad. Pero, el enfoque clave aquí es la productividad.
El equipo de diseño es el bloqueo y la lucha de los ingenieros.
Uno de los aspectos más importantes de Agile es el empoderamiento del equipo de desarrollo para decir que una historia (solicitud) no tiene suficiente definición. En mi experiencia, la falta de definición de requisitos es, con mucho, el mayor riesgo de productividad en un proyecto. Cuanto más distraigas y cambies de contexto a tu equipo de desarrollo, mayor será la ineficiencia.
El mejor uso de los recursos de diseño es actuar como socios con el equipo comercial para crear diseños y que satisfagan los requisitos antes de que la solicitud llegue al equipo de desarrollo. Esto permite que los equipos de ingeniería se concentren en el sprint actual.
- ¿Qué consideraciones deberían incluirse en el diseño de un logotipo para una campaña política?
- ¿Mi experiencia con el diseño gráfico sería útil si aprendiera Python?
- Cómo ser bueno dibujando
- ¿Cómo afecta aprender a codificar a un diseñador de experiencia de usuario en términos de salario adicional y oportunidades de trabajo?
- ¿Por qué elegiste el diseño como carrera?
En una compañía, llegamos al extremo de prohibir a las partes interesadas hablar con los ingenieros.
Mida dos veces, corte una vez
Otra consideración es que cuanto más avanzas en el proceso de desarrollo, los cambios se vuelven mucho más caros. Por lo tanto, si bien un diseñador por hora puede ser lo mismo que un recurso de desarrollo, si realiza un cambio cuando la solicitud solo ha pasado de un actor clave a un diseñador, es mucho menos costoso que si hubiera ido a su equipo de desarrollo. Por lo tanto, la fase de diseño con carga frontal debe ser donde elimine cualquier ambigüedad, permita que los requisitos cambien o evolucionen. Y en última instancia, trate de bloquearlos.
Además, recomiendo encarecidamente que sus diseñadores creen prototipos. Este es un método mucho mejor para obtener la aprobación, ya que el diseño es más representativo del producto final. Además, esto puede reducir la cantidad de documentación requerida para sus ingenieros.
Reconocer que los criterios de aceptación son más abstractos.
Por último, no intentes aplicar todos los aspectos de Agile a tus diseñadores. No se pueden colocar las mismas expectativas en el proceso de diseño, ya que gran parte de este es subjetivo y depende de la aprobación del negocio. Por ejemplo, si le pide a un ingeniero que haga una tarea, es probable que él / ella pueda proporcionar una estimación y decir que se hará en un sprint o dos. Cuando el código funciona y está libre de errores, está hecho / aprobado. Es muy binario Pero, para un diseñador, la tarea de diseño se realiza cuando la parte interesada clave está satisfecha. Si dice rediseñar la página de inicio, puede estimar cuánto tiempo llevaría hacerlo una vez. Pero no puede decir cuántas iteraciones tomará antes de que se apruebe.
He visto muchos proyectos donde se produjeron entre 50 y 100 diseños que eran todas opciones de calidad, pero la parte interesada nunca estuvo satisfecha.