Mejora tu proceso de desarrollo con la colaboración entre diseñadores, desarrolladores y QA

Share:

Antes de comenzar un proyecto, a menudo tratamos de averiguar a quién debemos incluir y en qué momento deben unirse al equipo. Es decir, el diseñador, el desarrollador y el control de calidad. Nos preocupamos por lo que puede hacer un desarrollador sin el diseño, qué hará el control de calidad sin una aplicación… y qué es primero: ¿el huevo o la gallina?

Por lo general, termina con roles específicos que se unen al proyecto en momentos completamente diferentes en el proceso de desarrollo. ¿Es este el enfoque óptimo para crear un excelente trabajo en equipo entre diseñadores, desarrolladores y QA, o deberías repensar este proceso?

Primeros pasos con el proceso de diseño y desarrollo

La colaboración en equipo es muy importante, por lo que un buen enfoque (¡el mejor!) es cuando el diseñador, el desarrollador y el control de calidad (y cualquier otro miembro del equipo) pueden trabajar juntos desde el principio. Pero, ¿tendrán todos algo que hacer? ¡Por supuesto!

El trabajo en equipo y el enfoque les permitirá lograr una muy buena calidad de creación de software/aplicaciones. El producto será refinado, ameno, atractivo, completo y libre de errores.

Cuando se moviliza un equipo completo, los miembros del equipo se complementarán entre sí desde el principio, lo que permitirá obtener resultados aún mejores que cuando empiezas a agregar personas al proyecto a mitad del camino.

A menudo, los problemas se resolverán incluso antes de que comiencen, y se ahorrará tiempo en resolución de problemas y podrán poner en desarrollo el sitio web real, diseño de UX (sin mencionar que se tiene más tiempo para todo el proceso de diseño), pruebas de arquitectura, y mucho más.

¿Cómo trabajan juntos los equipos de principio a fin? ¿Cómo encajan?

Todo el equipo importa, no solo los desarrolladores y diseñadores.

Cuando todo el equipo trabaja en conjunto, todos conocen los parámetros del proyecto y las expectativas del cliente. El equipo está formado por especialistas que realizan el trabajo en varias etapas, pero se apoyan mutuamente durante todo el proceso del proyecto.

El equipo completo consta de un gerente de proyecto, diseñador, desarrolladores, DevOps y control de calidad; por supuesto, puede suceder que los equipos no tengan todos los grupos, pero un “conjunto” como este permite el desarrollo eficiente de un software de alta calidad. .

Todos se conectan entre sí y, a veces, con el cliente a través de una plataforma de gestión de proyectos de tu elección, como Jira, Slack, Asana entre otros.

Este artículo está dedicado a la colaboración QA – DEV – DESIGNER en particular.

El diseñador es responsable de la preparación del diseño de la aplicación  de acuerdo con el proceso de diseño, es decir, investigación realizada previamente, análisis del material recopilado, reuniones con el cliente y discutiendo todos los detalles, como la creación de una persona, el viaje del cliente, etc. Básicamente, asegurándose de que el equipo de diseño y el cliente estén en la misma página.

Luego, el diseñador participa activamente en todo el resto del proceso e introduce todos los cambios necesarios de forma continua, brindando información completa sobre cualquier tema o consulta del lado del desarrollo/prueba para que todo sea lo más claro y comprensible posible para cada miembro del equipo.

Diseñadores y desarrolladores.

Los desarrolladores son responsables de los asuntos de programación y, según sus habilidades, se ocupan del front-end (lo que ve el cliente) o del backend (lo que sucede detrás).

Los desarrolladores front-end tienen la tarea de implementar la interfaz de usuario de acuerdo con las expectativas del cliente (esta interfaz debe ser diseñada por un diseñador profesional), conectar la aplicación con el servidor, sitios web externos y darle vida a la aplicación con animaciones interesantes.

“La precisión y la consistencia al codificar un diseño son características extremadamente importantes para un usuario frontend.”

Los diseñadores de Drago’s House son personas expertas en su oficio y hacen un trabajo increíble. Nuestros desarrolladores tienen una tarea desafiante: deben reflejar lo que el diseñador ha creado de la mejor manera posible.

El equipo del proyecto no solo está formado por un desarrollador que implementa el frontend, sino también por los desarrolladores responsables del backend, es decir, de todo lo que sucede dentrás (por supuesto, pueden ser full stacks que barren el frontend y el backend ????).

Trabajar con ellos también es muy importante. Una aplicación implementada correctamente es la interacción entre las partes front-end y back-end.

En este caso, nuestro desarrollador backend puede indicar áreas de aplicación, validaciones que deben ser manejadas por el front-end, por lo que el diseñador debe preparar vistas para esto y tenerlo en cuenta en tus proyectos.

El rol de control de calidad

El QA es responsable de probar el software y verificar si cumple con los requisitos y solicitudes del cliente. Los QA reportan errores, supervisan el proceso de prueba e informan tanto al equipo como al cliente sobre el estado de la aplicación después de la prueba.

Sin embargo, antes de comenzar con las pruebas, analizan los requisitos y verifican si los diseños preparados se han realizado de acuerdo con las maquetas y arreglos. En este punto, están en contacto constante con los diseñadores, informan errores y ven las cosas desde el punto de vista del usuario. Sus informes contienen comentarios y mejoras, y cuando todo se hizo muy bien… dicen: “Bien hecho, diseñador!”

No se trata solo de comentarios secos (esperemos que nunca sean secos), sino más sobre conversaciones y búsqueda de soluciones juntos, a lo largo de todo el proceso de diseño. Obtener comentarios holísticos es lo que hace que estos equipos de desarrollo sean tan efectivos.

El control de calidad a menudo regresa al diseñador durante las pruebas, mostrando cómo los desarrolladores implementaron vistas en la aplicación. Esto ya muestra cómo los tres roles trabajan juntos. El control de calidad hace preguntas, busca soluciones comunes, compromisos y, en general, se lleva bien.

Gracias al trabajo en equipo, todo el proceso de diseño se desarrolla muy rápido, encontramos errores que se comunican instantáneamente a los programadores que ya han tenido la oportunidad de ver dónde ocurre el error.

En Drago’s House, nos gusta más incorporar a todos los miembros del equipo. Gracias a esto podemos evaluar diversas especializaciones como análisis del negocio, pruebas de rendimiento o seguridad y, finalmente, las pruebas de usuario, que son capaces de identificar deficiencias en la documentación, requisitos, definir partes interesadas, brindar orientación sobre el rendimiento y la seguridad de la aplicación y, por supuesto, nosotros consultamos todo esto con nuestro equipo.

Esto es lo que nos distingue de los demás: nos encanta el equipo multifuncional.

¿Cuáles son los beneficios para un cliente que utiliza un equipo multifuncional?

  • Desarrollo de un software de alta calidad
  • Se detectan errores rápidamente y se pueden corregir rápidamente.
  • El equipo se conoce y sabe qué esperar el uno del otro y la comunicación es fluida.
  • Confianza en que el producto diseñado de acuerdo con los datos recopilados previamente se implementará correctamente (desarrollo) y se probará para cumplir con los supuestos comerciales y de diseño establecidos
  • Un punto de vista “triple” en prácticamente todos los aspectos del proceso porque, a menudo, el control de calidad con mucha experiencia puede recoger o proponer algunos elementos en términos de diseño y desarrollo. Lo mismo es cierto para un diseñador y desarrollador.
  • Lo que está arriba, es decir, la comunicación: el flujo fluido de información le permite minimizar el riesgo de tiempos de inactividad en el proceso de diseño, como que de repente resulta que la sección diseñada es demasiado compleja, por lo que su implementación llevará más tiempo del que debería. o el caso de que la implantación “en promedio” coincida con el diseño previamente aprobado.

¿Podemos imaginarnos trabajando en un equipo parcial?

Admito que hace años pensé que el enfoque de “ejército de un solo hombre” era el único enfoque correcto para el desarrollo, pero como con todo, con el tiempo este enfoque tuvo que ser verificado de manera bastante drástica.

Especialmente cuando una plataforma entra en escena y es un poco más avanzada que un conversor de divisas de una sola pantalla.

Personalmente, no soy capaz de imaginar un proceso de tipo “cascada” en el que primero paso 4 meses en un diseño que, después de la inspección del “desarrollador”, se destruye por varias razones, como limitaciones tecnológicas, mucho tiempo de implementación, etc.

O que al probar la aplicación, aparecen un millón de errores que podrían haberse evitado si los desarrolladores monitorearan el proceso de manera continua y lo supervise el departamento de control de calidad.

¿Qué puede salir mal?

¿Trabajar con un dream team (Diseño, QA, Dev) es garantía de éxito?

Después de leer la información anterior, puede parecer que sí, pero el cliente debe ser consciente de que no siempre es así.

Entonces, ¿qué pasa si decidimos poner a Ronaldo, Lewandowski y Messi en un solo equipo, si no podrán trabajar juntos? Exactamente. Lo mismo ocurre con los equipos de proyecto.

¡La combinación inadecuada de un equipo cuyos miembros no se entienden entre sí es el primer paso hacia el fracaso! Esto podría deberse a diferentes antecedentes, ya sean profesionales o personales, la falta de una excelente comunicación y tener una perspectiva completamente diferente.

Mientras escribo esta sección del artículo, me viene a la mente una situación, mucho antes de llegar a Drago’s House. Digamos que hubo muchos malentendidos en los proyectos.

¡Tres cabezas piensan mejor que una!

Un equipo de control de calidad/desarrollador/diseñador bien coordinado es una fuerza imparable contra los comentarios de los clientes, a menudo densamente imprevistos. El argumento sustentado por tres personas del lado de desarrollo tiene mucho más poder, sobre todo si es discutido previamente por el equipo para que se presente al cliente desde todos los lados.

Es cierto al revés: los comentarios que no están completamente pensados por parte del cliente (y sucede muy a menudo) pueden ser “refutados” con relativa facilidad y tacto, siempre que el equipo de desarrollo prepare una versión superpuesta para presentarla en la reunión.

Por lo tanto, es del interés de cada miembro del equipo estar totalmente de acuerdo. Además, trabajar con un equipo que no está en desacuerdo entre sí se ve muy bien desde la perspectiva de los clientes, y todo el proceso no se ve obstaculizado ni se pierde tiempo por puntos de vista opuestos sobre los aspectos técnicos del proyecto.

Herramientas: “¿Quizás necesite una herramienta en la que todos puedan intercambiar información?”

Miro o Whimsical o cualquier pizarra similar serían perfectos para la colaboración (no solo de los diseñadores sino también de otros miembros del equipo) porque así todos tendrán una idea del proceso de desarrollo, y podrán dejar sus comentarios en forma de cualquier nota adhesiva, comentar, dejar un emoji, etc.

Gracias a herramientas como esta, todos estarían al día con el proyecto, lo que aumentaría la calidad de la comunicación del equipo.

Sin un flujo eficiente de información entre los miembros del equipo, todo el proceso puede verse interrumpido, provocar retrasos o incluso detenerse por completo.

La gran lección de trabajar juntos

Como podemos ver, a los desarrolladores, los QA y los diseñadores de proyectos les encanta trabajar juntos; es un buen proceso en general.

Reciben más comentarios, están más abiertos a los cambios cuando realmente es necesario hacerlos (a nadie le gusta trabajar en algo durante una semana y solo luego le dicen que les falta un aspecto crucial o que es imposible implementarlo).

La clave aquí es una colaboración puntual y según sea necesario con miembros del equipo que estén totalmente comprometidos con el proyecto de principio a fin.

Están contentos, el cliente está contento (y mejor informado) y el producto final siempre se ve y funciona mejor que cuando lo produce un equipo temporal fraccionado o organizado al azar.

Si bien dividir este equipo parece tentador cuando se trata de presupuestar, a la larga, el presupuesto habla de mantenerlos juntos de principio a fin.