No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Solución uno: llegar a acuerdos

3/9
Recursos

Aportes 19

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Un problema que tuve hace unos meses donde se vio afectado un proyecto, fue en la utilización de unidades diferentes a las que se usan en desarrollo, por ejemplo: Usamos pixeles para todos los elementos de la UI pero en desarrollo lo mejor es usar unidades de medida relativas como rem, vh y vw.

Si esto se hubiese acordado desde el principio, no se hubiera perdido tantas semanas en trasladar todas las unidades en px usadas en el proyecto.

Otro problema que considero que se podría al menos disminuir con acuerdos sería las diferencias entre el diseño y el código.

Que tanto el equipo de desarrollo como el de diseño lleguen a acuerdos en el tema de los tamaños, tipografías, colores, etc. Para que ambos equipos sepan cómo esta diseñado y construido el proyecto (si el programador sabe y aporto en que los tamaños son de 14, 18 y 24px o que los colores principales para las acciones son tal y tal pues en el futuro no habrá problemas con ese tipo de cosas).

Llegar a acuerdos

  • Diferencias en la estimación de tiempos de trabajo. Es un error en Diseño considerar muy bajo el tiempo que tardan en hacerse los desarrollos. ¿Cómo llegar a un acuerdo? Involucrar a desarrollo desde el inicio del proceso de diseño y valorar sus ideas y consejos. Así podrán estimar mejor sus tiempos de trabajo.
  • Backgrounds distintos: Un error común es el considerar quer son equipos separados con dinámicas y pensamientos muy diferentes, esto genera falta de comunicación. ¿Cómo llegar a un acuerdo? Diseño debe de tener conocimientos básicos de desarrollo y biceversa. Empatizar. El beneficio será entender mejor de dónde vienen y porqué toman ciertas decisiones.
  • Diferentes enfoques y prioridades: Un error común es el considerar que tu punto de vista y tu trabajo tiene mayor prioridad sobre las del resto del equipo. Ocasionando productos poco consistentes y procesos de trabajo tediosos. ¿Cómo llegar a un acuerdo? Encontrar un punto en común y que sean viables para ambas partes.

Problemas/soluciones típicos en espacios de trabajo

  1. Diferencia de tiempos. Solución: Involucrar al equipo de desarrollo desde el principio
  2. Background distintos. Solución: Aprender nociones básicas del otro equipo
  3. Diferentes enfoques:. Solución: Encontrar puntos comunes

Lo mejor de los acuerdos en beneficio del producto final es el de dar soluciones conjuntas para que desde Diseño se pueda cumplir con la promesa de venta y en Desarrollo se logre un resultado optimo en el producto.

Básicamente es el principio de empatía, ponerse en el lugar del otro y considerarlo para las decisiones que tomemos.
Coincido mucho con el punto de aprender lo básico de desarrollo o diseño.

Las diferencias nutren.

Un problema recurrente que observe en empresas dedicadas al e-learning era precisamente la estimación de tiempos, la primera etapa que era diseño instruccional solía tomar mas tiempo del estimado reduciendo el tiempo para diseño grafico y desarrollo, lo que resultaba en proyectos funcionales pero de baja calidad en los cuales había que invertir un tiempo más.
Esto mantenía al equipo de Diseño grafico y Desarrollo con un animo decaído por que aunque se buscaban estrategias para optimizar y mejorar el producto en la mayoría de las ocasiones no era posible, la rotación de personal en esta área se volvió una constante.

Un problema común que veo cuando trabajo con el equipo de Devs es que es fácil criticar y opinar desde el Ego, cuando les mostramos nuestras propuestas de diseño ya definidas y validadas con usuarios, ellos empienzan a opinar “A mi no me gusta…”, “Yo como usuario…”, “Mi mamá no le gusto”. La solución más viable es involucrar al equipo de Devs desde el inicio y analizar sus opiniones siendo abiertos a validarlas con usuarios

Yo soy diseñador gráfcio hace años, hasta ahora incursiono en el mundo del diseño UX y creo fielmente en aprender a programar para entender el lado del código al momento de diseñar.

Llegar a mejores acuerdos debe de ayudar al salario emocional de ambas partes. Esto puede ser un factor que mejora el clima laboral y posiblemente el índice de rotación de personal.

Yo estoy en total desacuerdo en relación a que los desarrolladores aprendan a diseñar y viceversa. Decirlo suena bien, pero en la práctica, donde todos estan ocupados haciendo su trabajo, no hay tiempo para aprender algo que me aporte tan poco. Yo creo que un tech lead o talves un PM deberia ser el puente entre estos dos equipos y facilitar la comunicación. Es más eficiente tener una comunicación efectiva para llegar a acuerdos en lugar de que cada miembro del equipo aprenda algo que puede que no este muy interesado en

Gracias

involucrr al equipo de desarrollo desde el principio, se va a valorar sus ideas y consejos. Se podra estimar mejor los tiempos de trabajo.

Como diseñador UI/UX, he visto la gran necesidad de aprender a programar (aunque sea a un nivel básico) con el fin de entender mejor al equipo de Desarrollo y poder colaborar de mejor manera con ellos. Al mismo tiempo, que los desarrolladores aprendan los principios de diseño UX y de interacción resultaría muy provechoso a la hora de trabajar conjuntamente porque somos áreas muy estrechamente ligadas en cualquier empresa de desarrollo de software.

En mi trabajo, a veces, empezamos con el UX, se entrega al usuario y lo acepta y semanas después entra desarrollo y eso trae varios problemas de entendimiento y acuerdos entre el equipo.

Me encuentro en un proyecto, donde con regularidad se tienen reuniones para saber el estado de las actividades donde se pueden manifestar sobre bloqueantes, sugerencias, etc. A pesar de esto en ocasiones como Diseñadora siento que te parte del equipo de Dev no me prestan la atención suficiente, ya que al momento de entregar mis actividades para desarrollo (Después de un aprobado) el equipo me comunica que no pueden desarrollarlo.

La mejor ganancia, desde mi punto de vista, es el respeto y la admiración por el oficio del otro y el ambiente de colaboración que esto trae, genial para trabajar en equipo desde el principio del proyecto y mantener una comunicación abierta y clara.

Importante es que con un sistema de diseño se puede buscar mucho más rápido los estilos o comportamientos de un componente, haciendo que el equipo se vuelva ágil en las posibles soluciones que se lleguen a plantear, sin la necesidad de gastar más esfuerzo hombre en desarrollo.

La comunicación resuelve la mayoría delos problemas, el tip sobre que los de diseño sepan algo de programación y viceversa me parece fundamental