Cómo resolver conflictos entre su equipo de diseño y los equipos de ingeniería.

Los golpeamos en la cabeza y los hombros con nuestros diseños hasta que reconocen nuestro brillo … um, está bien, tal vez no.

La respuesta real es “depende”. Principalmente depende de las personas involucradas, pero también depende de las relaciones de las dos organizaciones, la antigüedad, la cultura corporativa, etc. ¿Sus diseñadores e ingenieros informan al mismo gerente? ¿Cuántos niveles suben antes de que eso suceda? ¿Son esos gerentes buenos defensores de sus organizaciones? ¿Ayudan a construir respeto y entendimiento mutuo? ¿La cultura de su empresa tiene una actitud de “el dinero se detiene aquí” o una actitud de “pasar el dinero”?

¿Cuál es la cultura de ingeniería en esta organización? ¿Es inclusivo y colaborativo o “programador” y grosero? ¿Existe un choque de personalidades o estilos que se hace pasar por “diseño versus ingeniería” cuando, de hecho, el diseñador principal rechazó una fecha para el desarrollador principal?

¿Qué tipo de ciclo de vida de diseño de software existe en su organización? ¿Cómo se incluyen la UI, UX y la usabilidad en ese ciclo? ¿Quiénes son los decisores, quién es responsable / responsable y quién puede comentar? Muchas cosas que parecen conflictos de equipo son en realidad luchas de poder sobre quién puede hacer qué dentro de un ciclo de desarrollo. ¿Quién es invitado a tus scrums diarios? ¿Quién tiene la capacidad de preparar historias? ¿Quién tiene que firmar los documentos o las revisiones de fase?

¿Cuál es el proceso de revisión de su empresa? ¿Hay revisiones periódicas de diseño? ¿Quién los llama y quién es invitado? ¿Existen revisiones periódicas de código y revisiones “implementadas” para los artefactos de diseño? ¿Cómo se realiza el seguimiento de los resultados de estas revisiones y quién es responsable de garantizar que haya seguimiento?

¿Cómo se manejan los conflictos de recursos? ¿Es diferente cuando los recursos involucran personas y no solo tiempo o dinero? ¿Cómo se asignan las personas a los proyectos? ¿Están haciendo malabares con múltiples prioridades y los mismos desarrolladores trabajan con los mismos diseñadores en múltiples productos y ciclos de vida?

Podría seguir y seguir en este sentido, pero espero que comprendan el mensaje tl; dr, que es que no pueden resolver conflictos sin comprender a las personas involucradas, sus objetivos y el contexto en el que se desarrolla el conflicto. Algo así como un diseño UX en primer lugar.