Todos los buenos proyectos tienen una cosa en común

Era una mañana de invierno. Siete meses habían transcurrido desde que me convocaron para formar parte del equipo de diseño de una plataforma que prometía muchos desafíos, exploraciones y sobretodo interrogantes.

Como era de costumbre, cada mañana comenzaba revisando las tareas pendientes de la semana y controlando de que cada tarea finalizada y revisada pase al equipo de desarrollo para su integración. Observo que una de las tareas más complejas del proyecto, el diseño de la funcionalidad más importante de la primera versión, finalmente había pasado los controles de revisión y estaba lista para su desarrollo. Paso la tarjeta al líder del equipo de programadores y continúo con mi agenda del día.

Al mes siguiente, treinta y un días después de aquella mañana, recibo un mensaje del responsable de darle vida a las pantallas que tanto trabajo nos llevó diseñar para notificarme que el módulo ya estaba listo y que necesitaba de mi aprobación para cerrarla y presentársela al cliente.

Era un completo desastre.

Los botones no coincidían con el diseño, los tamaños de las fuentes no eran los definidos, los márgenes y espaciados completamente inconsistentes con la propuesta y, en consecuencia, con el resto de las pantallas. Incluso la grilla se rompía porque en vez de haber cuatro bloques como se había definido en un principio se decidió a último momento que habría tres.

Estábamos desconcertados. Más de un mes de trabajo entre diseño y desarrollo tirado por la ventana.

¿Qué hicimos mal? ¿Qué se nos pasó por alto que nos terminó conduciendo hasta acá?

Aunque pueda sonar a una historia aislada, en la práctica este tipo de conflictos sucede más de lo que nos imaginamos. Personalmente lo llamo el “Síndrome de Cascada”.

Muchas startups y proyectos digitales en los que he trabajado se jactan de aplicar metodologías ágiles en sus procesos por el simple hecho de tener un método predecible para completar una tarea, reuniones diarias de status entre los líderes de cada equipo y los tan famosos “Sprint Planning”. Si bien es correcto que lo hacen, la vorágine del día a día, los deadlines y las innecesarias reuniones que interrumpen los estados productivos de la gente conducen a los responsables de cada tarea a adoptar una posición conservadora frente al resto de sus compañeros.

Llevando la problemática al ecosistema de las agencias el escenario podría ser de la siguiente manera:

  1. El director creativo, líder de desarrollo y encargado de la cuenta se reúnen con el cliente para conversar sobre el nuevo proyecto que la agencia llevará adelante.
  2. El director creativo se reúne con el equipo de diseño para introducirles el brief y los aspectos a considerar a la hora de trabajar.
  3. Luego de varias semanas de arduo trabajo los diseñadores ya están listos para pasarles todas las piezas al equipo de desarrollo. Se comunican con su líder y al día siguiente ya están trabajando en el nuevo proyecto.
  4. Al contrastar el brief con las piezas entregadas, los desarrolladores concluyen que, para que la aplicación cumpla con los estándares esperados, van a tener que utilizar una librería que limitará la integración de ciertos componentes que el equipo de diseño se esforzó tanto en crear. Para peor, detectaron de que la herramienta más importante del proyecto había sido diseñada de una manera tal que les llevaría el doble de trabajo estimado para su desarrollo. Por lo tanto, decidieron que había que simplificar el módulo.
  5. En consecuencia, los diseñadores tuvieron que destinar horas extras para adaptar sus piezas a los requerimientos, muy bien fundamentados, de los programadores. Todo esto obligó a que la entrega del proyecto se atrase dos semanas más.
  6. Finalmente, el/la responsable de QA es invitada al proyecto para realizar todos los controles de calidad y certificar de que la aplicación es 100% funcional. Para esta altura del proceso, la persona desconoce cuáles eran los requerimientos del proyecto y qué funcionalidades se habían decidido pasar para la próxima versión.

El escenario anterior es un claro ejemplo de lo que en la profesión conocemos como “Modelo de Desarrollo en Cascada”. Frente a los desafíos que día a día deben enfrentar las startups, un mecanismo que promueve la comunicación cerrada entre los equipos, resulta obsoleta.

Lo que digo no es nada nuevo y estoy seguro de que muchos de los que leerán este artículo serán conscientes de que incorporar metodologías ágiles a los procesos de trabajo ya no son una opción sino una necesidad. El problema, en realidad, radica en la falta de comunicación e integración de los equipos durante un proyecto.

No solo se trata de garantizar una correcta comunicación entre los miembros del equipo de diseño, desarrollo y cuentas, sino de hacer parte al conjunto de todas las conversaciones y decisiones que se tomaran a partir de ellas. Para lograr resultados extraordinarios debemos abrirnos a la posibilidad de compartir el problema con todos y no solo con la parte “competente”.

Las mejoras soluciones son aquellas que contienen el mejor condimento de cada equipo.

Las startups deben garantizar espacios de diálogo tanto dentro como fuera de los espacios de trabajo. Para ello pueden adoptar las siguientes estrategias:

1. Seleccionar a los participantes de la tarea durante el Sprint Planning.

Al conocerse con anticipación quiénes estarán a cargo del diseño y desarrollo de un módulo, los integrantes podrán coordinar entre ellos y compartir conocimiento para llevar la tarea al mejor resultado antes de comenzar la tarea.

2. Garantizar una comunicación constante y fluida con todas las areas involucradas en la tarea

Esperar hasta el último para que un programador garantice que una propuesta de diseño está en condiciones de desarrollarse es suicida. En cambio, es preferible trabajar con el equipo desde el armado del concepto hasta la definición final de la propuesta para garantizar un resultado compatible con los requisitos de desarrollo.

3. Ser lo más descriptivo posible con la tarea creada

Recuerdo las horas perdidas sin poder trabajar en una tarea porque no se había incluido una descripción clara. Ningún participante, salvo el creador de la tarea, sabía de qué se trataba. Esta falta de detalle por parte del Project Manager o responsable de cargar las tareas en el backlog, puede resultar contraproducente para el equipo a mediano plazo. Al ser más descriptivo con el problema y el resultado esperado, los equipos tendrán más autonomía y dependerán menos de sus líderes.

4. Documentar, documentar, documentar

Cuando se aprueba una propuesta de diseño, documentar. Cuando se termina de integrar un nuevo módulo al producto, documentar. Cuando se incorpora un nuevo proyecto, documentar. Así nos aseguraremos de que toda la información del producto estará disponible para el que necesite consultarla y se abrirá la posibilidad a que cualquier integrante del equipo pueda mejorar lo que ya está hecho. Para los diseñadores, ya lo había anunciado John Maeda en su “2017 Design In Tech Report


Si queremos construir una cultura de trabajo más flexible, abierta y ágil tenemos que garantizar que la comunicación sea la prioridad y responsabilidad número uno en todas las areas involucradas en el desarrollo de un producto.

Ya no basta con saber diseñar o programar bien sino en tener la habilidad de llevar una idea desde su concepción hasta su solución de la manera más completa y fiel posible a las expectativas de los usuarios, clientes y stakeholders. Y para llegar a esto, no se me ocurre mejor punto de partida que un trabajo en equipo basada en la integración y comunicación constante entre sus miembros.


Si disfrutaste de esta historia te invito a que lo valores 👏 y lo compartas para ayudar a otros a que lo lean. También podrás encontrarme en Twitter o Instagram.