Cómo alineamos nuestro equipo de diseño y desarrollo y mejoramos la eficiencia
Si tuviera que describir la historia del equipo del sitio web de IMPACT, diría que es similar a la trama de su típica película o programa de televisión de Hollywood. Piensa en Steve Harrington y Dustin Henderson de Stranger Things. Buzz y Woody de Toy Story. Legolas y Gimli de El Señor de los Anillos. En todos estos escenarios, tienes a tus principales protagonistas que, en muchos sentidos, son opuestos completos. Al principio de la relación hay mucha fricción y tienen problemas para ver los ojos a los ojos. Sin embargo, a medida que la historia avanza, aprenden a dejar a un lado sus diferencias, formar una amistad poco probable y trabajar juntos para lograr una meta mayor. Los diseñadores y desarrolladores son un dúo. Ahora, mientras que nuestro mayor objetivo en IMPACT no implicaba destruir un anillo en los incendios del Monte del Destino o derrotar a un demogorgon; sí dependía de que encontremos una manera de alinear a nuestros diseñadores y desarrolladores, una tarea que algunas empresas dirían que es igual de difícil. Acortar la brecha entre nuestros diseñadores y desarrolladores fue algo con lo que luchamos durante años. Nuestros equipos no estaban alineados con cuáles eran los objetivos generales de nuestro equipo, la comunicación, y estábamos trabajando en un enfoque muy sitonado. Entonces, ¿qué causó la ruptura entre los dos equipos? Necesitábamos averiguar qué no funcionaba y por qué. Durante los meses siguientes, tuvimos una serie de reuniones retrospectivas donde hicimos una inmersión profunda en todos los aspectos de nuestro equipo. En última instancia, llegamos a la conclusión de que había tres problemas principales que causaban la ruptura entre diseñadores y desarrolladores. 1. Tratamos los proyectos del sitio web como una línea de montaje Cuando se trataba de cómo abordamos el diseño del sitio web, nos dimos cuenta en lugar de tratarlo como un proceso colaborativo, lo tratamos como una línea de montaje. Nuestros diseñadores trabajarían en un diseño y luego lo entregaban al desarrollo para ser codificado y pasar al siguiente proyecto. La única parte del proceso en la que hubo alguna comunicación entre los dos equipos fue durante la breve entrega, pero simplemente proporcionamos a los desarrolladores un enlace a nuestros archivos de proyecto y seguir adelante. La limitada cantidad de comunicación causó muchos malentendidos sobre cómo debe verse y funcionar el producto final, lo que llevó a rondas adicionales de revisiones. Terminamos necesitando empujar continuamente hacia atrás las fechas de lanzamiento de nuestros proyectos que perjudicaron la rentabilidad y tuvieron un efecto dominó en las fechas de inicio de los próximos proyectos que habíamos visto. La falta de colaboración también tuvo un efecto en la capacidad de nuestro equipo para innovar y crecer. La colaboración es un motor clave de la innovación. Cuando colaboras eficazmente, puedes ver cómo funcionan los diferentes equipos y abordas los problemas. Te introducen nuevos hábitos y obtienes comentarios externos que pueden ayudarte a crear nuevas ideas o mejorar los procesos. Desafortunadamente, trabajando en nuestro enfoque de silo, nos estancamos. Dejamos de innovar y pasamos más tiempo aferrándose a lo que sabemos en lugar de arriesgarnos y tratar de impulsar a nuestro equipo para estar por delante de las tendencias del sitio web. 2. Hubo grandes brechas de conocimiento entre los equipos Trabajar en un enfoque de línea de montaje no solo creó problemas de comunicación y colaboración, sino que también creó brechas de conocimiento entre los dos equipos. Los diseñadores y desarrolladores no tenían una comprensión de lo que estaba sucediendo en las partes del proceso del otro, así que las cosas en las que trabajamos no siempre eran cohesivas. Nuestros diseñadores hacían estos hermosos diseños, pero cuando se enviaban al desarrollo, no se traducían fácilmente en código. No teníamos una fuerte comprensión de qué tipos de cosas aumentan el tiempo de desarrollo. El trabajo adicional que nuestros desarrolladores tuvieron que poner para hacer que los diseños funcionaran causó retrasos importantes en los plazos de nuestros proyectos. En el otro lado de las cosas, nuestros desarrolladores no sabían cuáles eran los objetivos de una página. No sabían a qué estábamos tratando de construir con estos diseños. Esto les hizo difícil dar retroalimentación de funcionalidad a los diseñadores. Lidiar con estos problemas no sólo afectó el producto final que publicamos, sino que también tuvo un gran impacto en la moral de nuestro equipo. No conseguimos encontrar tu ubicación exacta. 3. No había una estructura de archivos unificada Por último, nos dimos cuenta de que no teníamos una estructura de archivos unificada para pasar el trabajo desde el diseño hasta el desarrollo. Todos nuestros diseñadores hicieron las cosas un poco diferente. Todos teníamos una estructura de nomenclatura de archivos diferente, una forma diferente de dejar notas de funcionalidad, y organizamos archivos a nuestra manera. Eso significaba que cada vez que nuestros desarrolladores consiguieron un nuevo proyecto necesitaban tiempo adicional para aumentar y familiarizarse con cómo se organizaba todo. Fue como empezar cada proyecto desde cero, de nuevo, extendiendo la longitud de nuestros proyectos y dejando más margen de error. Sabíamos que si íbamos a dar los saltos en el trabajo de nuestro sitio web que queríamos, tuvimos que rectificar estos problemas.
Cómo alineamos nuestros equipos de diseño y desarrollo
Estos problemas estaban creando una gran brecha entre nuestros diseñadores y desarrolladores que nos hacía casi imposible trabajar juntos. Sabíamos que a menos que arreglamos estos problemas, nunca íbamos a ser capaces de poner ese increíble producto final que sabíamos que éramos capaces de. Una vez que supimos lo que estaba causando la desalineación pudimos poner en marcha un plan para que nuestros equipos trabajaran de forma colaborativa y eficiente. Implementamos las siguientes iniciativas para empezar a descomponer esos silos: Tenemos nuestros equipos hablando el mismo idioma Una de las primeras iniciativas que abordamos fue llegar a una manera de hacer que nuestros equipos hablaran el mismo idioma. Nos dimos cuenta de que teníamos un montón de nombres diferentes para los mismos elementos del sitio web. En nuestro sistema de diseño llamaríamos a un elemento una cosa, entonces en nuestro marco de desarrollo se llamaría otra cosa. Si pudiéramos crear terminología común, eso ayudaría a empezar a mejorar esa comunicación entre equipos y reduciría los malentendidos. Para solucionar esto, tuvimos una reunión de equipo donde revisamos todos nuestros activos de diseño y desarrollo y decidimos un nombre propio para cada uno. A continuación, actualizamos nuestro sistema de diseño y el marco de desarrollo para usar los nombres para que se alinearan. Implementamos revisiones conjuntas de diseño A continuación, sabíamos que teníamos que cambiar nuestro proceso para ser más colaborativos. Para ello necesitábamos involucrar a nuestros desarrolladores en las primeras etapas del diseño y a nuestros diseñadores más involucrados en las piezas posteriores. Una de las formas en que hicimos esto fue mediante la implementación de revisiones de diseño que incluían nuestro equipo completo del sitio web. Durante estas revisiones, nuestros diseñadores pueden presentar diseños en los que están trabajando y obtener comentarios del desarrollo. Podemos ver rápidamente si lo que estamos diseñando se traducirá en código y se mantendrá dentro del presupuesto de un cliente. También podemos hacer una lluvia de ideas sobre la funcionalidad de una página y discutir las banderas rojas que los desarrolladores notan que pueden causar problemas cuando es el momento de desarrollarse. En general, esta es una manera efectiva de no colaborar, pero también cerrar cualquier brecha de conocimiento que podamos tener entre los dos equipos. Creado un proceso para las entregas de diseñador a desarrollador Muchas de nuestras comunicaciones erróneas y retrasos se debisó de no tener un proceso claro para pasar del trabajo del diseño al desarrollo. Así que, como equipo, se nos ocurrió una manera coherente de organizar y nombrar nuestros archivos, decidimos dónde queríamos que todas las notas de funcionalidad importantes para un diseño para vivir, y nos aseguramos de que todos los activos de un proyecto vivieran en algún lugar al que todos los desarrolladores pudieran acceder fácilmente. Esos pequeños cambios han hecho una gran diferencia, sin embargo, sólo para estar seguros, una vez que es el momento de una entrega, revisamos los diseños finales con los desarrolladores una última vez y nos aseguramos de que tengan todo lo que necesitan. Encontramos nuevas formas de aumentar la comunicación del equipo En general, lo más importante que necesitábamos mejorar era nuestra comunicación entre diseño y desarrollo. Nuestras revisiones de diseño conjunto comenzaron a hacernos hablar y ver las cosas desde el punto de vista del diseño y el desarrollo, pero queríamos mantener la conversación fuera de esas reuniones. Por lo tanto, creamos un canal en Slack para que los miembros de nuestro equipo se comuniquen. En el canal, podemos compartir problemas recurrentes que estamos notando en diferentes proyectos, inspiraciones de diseño y también victorias en equipo. Fuera de Slack, también hemos implementado un nuevo documento de hoja de ruta del proyecto que mantiene a nuestros equipos alineados con el presupuesto y el progreso del proyecto. En el documento, puede encontrar cosas como enlaces a los diseños de proyectos que se han completado y un desglose del presupuesto del cliente. Todo nuestro equipo es capaz de saltar fácilmente en cualquierhoja de ruta y ver hasta qué punto estamos en el diseño o cuánto presupuesto de desarrollo nos queda. Esto ayuda a mantener nuestros proyectos dentro del alcance y a tiempo. Realizó un entrenamiento en todo el equipo Una vez que teníamos un plan para alinear nuestro equipo, decidimos que la mejor manera de iniciar nuestras nuevas iniciativas era llevando a cabo una capacitación en todo el equipo. Realmente queríamos que todos se entusiasmaran por trabajar en un entorno más colaborativo y sentir un sentido de propiedad sobre el nuevo proceso. Queríamos que todos sintieran que tenían una mano en su creación y que hicimos algo de lo que todos pudiéramos estar orgullosos. Durante la capacitación presentamos todos los cambios importantes que estábamos haciendo en nuestro enfoque de diseño. Hablamos a través de cualquier pregunta o sugerencia que nuestro equipo tenía y nos aseguramos de que todos tuvieran una fuerte comprensión de nuestra visión. Cómo estos cambios afectaron a nuestro equipo En los tres primeros meses de la implementación de estos cambios, notamos una gran diferencia en la forma en que nuestro equipo funcionaba. Sentimos que estábamos trabajando juntos. Nuestros diseñadores y desarrolladores estaban entusiasmados con la educación mutua sobre sus especialidades y, como resultado directo, estábamos ideando ideas nuevas y emocionantes para nuestros sitios web de clientes. Desde el punto de vista de la rentabilidad y la fecha límite del proyecto, nos manteníamos dentro del presupuesto de nuestros proyectos y lanzamos a tiempo. Parece que cada semana estamos encontrando nuevas formas de ser más eficientes y proporcionar un mejor producto final para nuestros clientes. Ahora, si sientes que tu historia de diseñador-desarrollador está atascada en las primeras etapas en las que tus personajes principales aún no están viendo cara a cara, detente y echa un vistazo a cómo estás trabajando juntos. ¿Cómo se comunica su equipo? ¿Sienten sus diseñadores que entienden cómo funcionan los desarrolladores y viceversa? Alinear a sus desarrolladores y diseñadores no solo capacitará a su equipo para poner el mejor trabajo posible, sino que también hará que sea mucho más fácil mantener sus proyectos en el presupuesto y mejorar la moral general de su equipo. Nombre del autor: Joe Rinaldi
Contact Information:
Keywords: afds, afdsafds
