Dar vida a los diagramas de Gantt: la perspectiva del desarrollador

¿Qué imagen pasa por tu cabeza cuando piensas en el desarrollo de una nueva funcionalidad de software? Es normal imaginar que ocurre en un vacío: juntas algunos requisitos, los envías a los desarrolladores y, tras semanas o meses de silencio, recibes una notificación: “Vale, ya está hecho”.

Sin embargo, en el caso de la creación de nuevas funciones Gantt de Redbooth, el proceso de desarrollo ha sido intensamente colaborativo y se ha basado continuamente en las necesidades de los clientes de Redbooth. Y, como equipo de desarrollo que crea software de productividad, los desarrolladores de Redbooth también incorporaron procesos y las mejores prácticas a su flujo de trabajo para aumentar la eficiencia.

Esta es la tercera entrega de nuestra serie sobre el seguimiento del proceso de creación de una funcionalidad de diagramas de Gantt fácil de usar e increíblemente útil para todos los usuarios de Redbooth (puedes acceder al primer y al segundo artículo, si no lo has hecho ya).

Sigue leyendo para descubrir cómo el equipo de desarrollo de Gantt de Redbooth, de Barcelona, estudió detenidamente los requisitos de los usuarios y se centró en la comunicación y la iteración.

También descubrirás las 5 mejores prácticas que les han permitido para colaborar de forma más eficiente y verás cómo aplicarlas a los proyectos en los que estás trabajando ahora mismo.

Comprender lo que desean los usuarios de Redbooth

Los desarrolladores que trabajaron en Gantt observaron detenidamente las necesidades y las experiencias de los clientes que posteriormente utilizarían las funcionalidades Gantt de Redbooth. Irwin Kwan, responsable de productos, y Sarah Tanner, diseñadora de productos, grabaron y compartieron las entrevistas que realizaron para que el equipo de desarrollo pudiera ver exactamente quién iba a utilizar Gantt y qué era lo más importante para ellos.

“Ver los vídeos de los clientes fue como un recordatorio del motivo por el que estábamos creando Gantt”, comentó el desarrollador backend Pau Pérez. “Estamos creando una herramienta que tendrá un impacto importante sobre el trabajo diario de nuestros usuarios”.

Ver los vídeos de los clientes también ofreció una perspectiva sobre las necesidades únicas de las empresas de distintos sectores, según destacó Jorge Morante, desarrollador frontend.

“Por ejemplo, para una empresa de construcción, la duración de los proyectos es enorme si se compara con los nuestros, ya que hablamos de proyectos que duran años”, comentó. “Y eso es algo que tenemos en mente durante el desarrollo del nuevo Gantt”.

“Los vídeos me ayudaron a comprender mejor las necesidades de los usuarios de Redbooth y el motivo por el que estamos creando la funcionalidad Gantt”, añadió Jorge. “Este tipo de visión global de la totalidad del proceso durante el desarrollo de las funcionalidades nos permite remar en la misma dirección como equipo”.

El equipo también trabajó para asegurarse de poder ofrecer la mejor experiencia posible a los clientes. Por ejemplo, el desarrollador full stack Ilia Zayats sacó algo en claro al ver las entrevistas con los clientes: menos es más.

“La idea principal con la que me quedé tras ver los vídeos es que la mayoría de las herramientas Gantt actuales del mercado pueden abrumar al usuario con una enorme cantidad de funcionalidades”, afirmó Ilya.

“Por esta razón, desde el inicio adopté una actitud muy escéptica, intentando cuestionar cada pequeña parte de las funcionalidades Gantt y su necesidad. En mi mundo ideal, deberíamos entregar un MVP (producto viable mínimo) realmente sólido y, posteriormente, iterar rápidamente tras recibir la información de nuestros usuarios reales. Y eso es lo que estamos haciendo”.

Y con los usuarios de Redbooth ansiosos por comenzar a utilizar las funcionalidades de diagramas de Gantt lo antes posible, fue importante que el equipo se mantuviera coordinado y trabajara con rapidez. La clave fue el modo en el que el equipo de desarrollo enfocó su trabajo.

Coordinación del trabajo e iteración rápida

Volviendo a las entrevistas de Irwin y Sarah con los usuarios en diciembre, el equipo de desarrollo seguía esperando los resultados de esa investigación. Entretanto, se dedicaban a preparar el terreno para un marco técnico que respaldara una iteración rápida.

“Incluso en las fases más tempranas, pudimos plantear suficientes supuestos para comenzar la investigación de la tecnología subyacente en Gantt”, comentó Jorge. “Así, pudimos decir: ‘De acuerdo, sabemos que queremos ofrecer cuadros coloridos y sexis, colocarlos según las fechas y la experiencia de arrastrar y soltar debe ser perfecta’”.

El proceso de iteración rápida y temprana era esencial.

"El equipo estaba desarrollando prototipos ‘desechables’ incluso antes de la creación de las simulaciones iniciales”, comentó Ilya. "Esa fue la clave para la paralelización futura de nuestro trabajo: significaba que ya teníamos colocadas todas las ideas y cimientos subyacentes y que el equipo ya hablaba ‘un mismo idioma’ a la hora de describir los conceptos relacionados con Gantt".

También fue importante permanecer conectados con regularidad, dentro del equipo de desarrollo de Barcelona y con Irwin y Sarah en California. Las charlas diarias fueron un ingrediente clave en ese proceso.

“Cada mañana, lo primero que hace el equipo es celebrar una reunión rápida e informal en la que explicamos el trabajo realizado el día anterior y lo que hay planificado para el día de hoy. En una palabra: comunicación”, afirmó el desarrollador frontend Andrés Gutiérrez.

Y esa reunión de la mañana era solo el primer punto de contacto de un día cualquiera, lo que resultaba especialmente importante para el proceso iterativo. “En este tipo de proyectos grandes, es importante iterar en partes pequeñas”, añadió Andrés.

“Realizamos una sincronización activa muchas veces al día”, comentó Ilya. “Nos comunicábamos con Irwin y Sarah en el espacio de trabajo específico de Gantt que teníamos en Redbooth y entre nosotros dentro del espacio de trabajo de nuestro propio equipo, solo para asegurarnos de que se mantuviera la coordinación”.

A medida que los desarrolladores de Barcelona identificaban nuevos retos y oportunidades, continuaba el diálogo intenso con el equipo de productos de Silicon Valley (utilizando la función de videoconferencia de Redbooth, por supuesto). En lugar de ser un proceso descendente, la combinación de perspectivas transversales aportó lo mejor de varios mundos al proceso de creación de Gantt en Redbooth.

“Los debates dieron muy buenos resultados”, confirmó el responsable de productos Irwin Kwan. “Gracias al intercambio constante de ideas, junto con la capacidad de ‘jugar’ con los primeros prototipos y obtener una sensación real del producto desde el inicio, fuimos capaces de representar lo que oíamos de nuestros clientes. Esto significó poder estar seguros de estar de obtener los resultados también desde una perspectiva técnica”.

5 procesos de productividad que marcaron la diferencia

El equipo continúa utilizando diferentes técnicas para maximizar la eficiencia y la productividad durante el proceso de desarrollo. No es necesario crear software para aprender de estas moralejas. Incluso si trabajas en un tipo de proyecto muy diferente, es probable que exista una estrategia que te funcione.

[1] No distraerse con los detalles

Al optimizar el proceso de revisión de códigos, el equipo pudo centrarse en el todo, en vez de en los pequeños detalles.

“Estamos leyendo activamente los códigos de los demás y tenemos reglas internas estrictas con relación a la descripción de peticiones ‘pull request’, además de un grupo de herramientas aún más estrictas que comprueban los errores más comunes de los desarrolladores de forma totalmente automática”, dijo Ilya. “Esto nos permite no centrarnos en detectar comas o paréntesis mal colocados, sino en intentar comprender la idea subyacente y el razonamiento que hay detrás del código”.

Moraleja: libera energía mental automatizando la mayor parte posible del proceso. Si te distraes con detalles triviales, no podrás concentrarte en decisiones importantes.

[2] Mantener sprints cortos y centrados

En un flujo de trabajo de desarrollo basado en un enfoque Scrum, los “sprints” son periodos de tiempo que el equipo reserva para el trabajo dedicado a resultados definidos. Al final de cada sprint, los miembros del equipo se reúnen, reflexionan sobre su progreso, establecen objetivos claros para el siguiente e incorporan sus opiniones. Para el equipo de desarrollo de Gantt, la duración de los sprints marcó una diferencia importante.

“Los sprints cortos fueron de gran ayuda,” comentó Ilya. “También las sesiones de planificación de sprints fueron muy cortas: cuando el equipo realmente entiende lo que está creando, no se necesitan largas discusiones”.

Moraleja: ¿trabajas con un equipo? Analiza cuidadosamente el lapso de tiempo que transcurrirá antes de una nueva reunión de revisión e información. Cuando se pisan nuevos terrenos, puede ser necesario reunirse con más frecuencia.

[3] Cazar los problemas rápidamente (también conocido como Spike It!)

Convertir el diseño de una función en algo completamente funcional siempre será un proceso complicado, y los desarrolladores de Gantt sabían que podían esperar lo inesperado. Desde las limitaciones tecnológicas a los problemas de compatibilidad, ayudó contar con un proceso que busca activamente sacar a la luz esos retos, para que puedan abordarse con prontitud.

“En nuestro equipo, hacemos lo que denominamos ‘spikes’ para superar los desafíos”, comentó Eduardo Lanchares, desarrollador full stack.

“Un spike es una prueba de concepto de la viabilidad de una funcionalidad. Con esa investigación profundizamos en la funcionalidad y podemos entonces detectar posibles limitaciones de los problemas. Posteriormente, esta información se comparte con el equipo de producto y diseño, de modo que puedan pensar en una solución alternativa para resolverlo o dedicar más tiempo para encontrar una mejor solución técnica. Se trata de trabajo en equipo: todos intentamos encontrar el equilibrio entre lo que queremos y lo que es posible”.

Moraleja: antes de sumergirte en una nueva idea, compruébala e informa de ello. Si todas las partes implicadas pueden mantener una mente abierta, se logrará identificar los problemas graves con más rapidez y con mínimos costes irrecuperables. El proceso puede incluso llevar a soluciones creativas que funcionen mejor que el concepto original.

[4] Dividir los trabajos estratégicamente

La división de un proyecto grande en partes permitió a los miembros del equipo de Gantt realizar más trabajo, pero solo porque pusieron más cuidado en hacerlo de forma autónoma, lo que también evitó posibles conflictos durante el proceso, y con tareas de tamaño correcto para garantizar que la carga de trabajo fuera razonable.

“El trabajo en paralelo es la clave para un desarrollo más rápido”, dijo Andrés. “La tecnología utilizada y el modo en el que se estructura el código son importantes. Si tu código está bien organizado y las cosas se pueden dividir en componentes independientes, puedes comenzar a trabajar en determinadas partes de la funcionalidad mientras los miembros de tu equipo trabajan en otras”.

La elección de tecnología compatible con este enfoque hace mucho más fácil una implementación eficiente.

“Utilizamos un marco denominado React.js, que reproduce la idea de componentes aislados que se pueden colocar juntos”, dijo Ilya. “Por ello, no estamos solucionando un enredo. Es más como trabajar con un árbol: todo el mundo toca diferentes ramas, pero hay un tronco central”.

Moraleja: presta atención a la hora de dividir el trabajo. Muchos equipos se dividen los proyectos de forma espontánea en las reuniones: “Vale, yo haré esto y tú harás lo otro”. Tómate tiempo para asegurarte de que la forma en la que se está asignando el proyecto tiene sentido y se mantiene coordinada.

[5] Explicar el “porqué,” no solo el “qué”

El equipo se aseguró de mantener una visión clara del motivo por el que estaban creando Gantt. Sabían que la finalidad no era trivial cuando se trata de mantener el compromiso y el progreso de un equipo de desarrollo. Comprender el impacto de un proyecto lo cambia todo.

“Es increíble la importancia que tiene la motivación en el desarrollo, y el éxito, de una nueva funcionalidad”, dijo Pau. “Hace posible superar retos como la utilización de tecnología totalmente nueva y la creación de interacciones completas de experiencia de usuario, al mismo tiempo que se siguen logrando hitos de acuerdo al calendario”.

Moraleja: sobre todo si tienes miembros del equipo orientados a un propósito, presenta el “porqué” de forma clara y convincente. Para algunas personas, supone una ayuda poder personalizar lo que están haciendo; para otras, es importante comprender el “porqué” técnico. Podemos tener la tentación de omitir este paso, pero es una oportunidad increíble para aumentar la participación desde el principio.

Entonces, ¿cuándo puedes probar Gantt?

La funcionalidad oculta que permite una utilización intuitiva a los usuarios es sorprendentemente compleja y va mucho más allá de la propia funcionalidad de Gantt hasta la plataforma que hace funcionar las cuatro aplicaciones principales de Redbooth (navegador, escritorio, iOS y Android). Los desarrolladores de Redbooth trabajan intensamente para garantizar que todo funcione de forma correcta e intuitiva.

En la actualidad, estamos planificando una versión beta cerrada en las próximas semanas para realizar pruebas y recabar opiniones. ¿Cuándo se lanzarán los diagramas de Gantt de Redbooth para todos los clientes? Tenemos prevista una versión para primavera y ofreceremos información más detallada a medida que se acerquen las fechas. No pierdas de vista el blog, ya que en próximos artículos facilitaremos más información sobre el progreso de Gantt.

Ilustraciones de Sarah Tanner