Naiz es la plataforma de contenidos digitales en formato periódicos y revistas del País Vasco, y agrupa contenido de noticias e información general constantemente actualizadas, 24/7.

Naiz agrega distintos medios: algunos que también se imprimen en formato papel (GARA, GAUR8, ZAZPIKA, MEDIABASK), algunos de retransmisión de formatos audiovisuales (INFO7 IRRATIA) y otros con solamente versión digital (KAZETA).

Naiz

Naiz es una plataforma digital masiva, que agrega múltiples publicaciones - desde revistas locales hasta periódicos de tirada nacional - y, por ende, todo su contenido. Naiz tiene detrás un gestor de contenidos hecho a medida llamado Ubiquo, que fue desarrollado por una empresa de Barcelona llamada GNuine. Ubiquo está hecho en Ruby on Rails.

Cuando GNuine cerraron la empresa, Naiz nos contactó para que pudiéramos darles soporte y continuar el desarrollo de su plataforma. Desde Enero del 2015 que estamos dando servicio de manera continuada a Naiz, y se han convertido no solamente en nuestro cliente más longevo, sino en nuestro cliente favorito.

¿Qué hacemos para Naiz? Muy fácil, les damos varios servicios, entre los cuales destaca el desarrollo full-stack, pero lo complementamos con consultoría de producto, auditorías varias (performance, código, seguridad...) y formaciones para su equipo interno.

Durante los dos primeros años del proyecto, nos dedicamos a mantener la plataforma y a evolucionarla poco a poco. Un proyecto de estas magnitudes requiere precisión quirúrgica para eliminar funcionalidades que ya no se usan, o librerías que han quedado desfasadas. Hemos ido añadiendo nuevas funcionalidades y reemplazando módulos enteros desde un approach largoplacista, para asegurar la mantenibilidad del código y que la plataforma siga funcionando el 100% del tiempo.

El primer año, sin embargo, lo empleamos para arreglar los bugs existentes y para añadir las funcionalidades más criticas que faltaban en la plataforma, mientras íbamos agarrando confianza y expertise en el manejo de una plataforma tan compleja. Por ello, empleamos la máxima de "siempre dejar el código mejor que lo has encontrado". Así, siempre dedicamos una parte de tiempo a añadir cobertura de código y refactorizar el mismo al mismo tiempo que desarrollamos.

Durante el mismo año, 2016, tuvimos que enfrentarnos al upgrade de la plataforma a la nueva versión de Ruby. Durante esta empresa, la dificultad mayor fue no romper ninguna funcionalidad existente, con el agravante que esta plataforma la heredamos de un proveedor que cerró, por lo que no teníamos el conocimiento histórico de ciertas decisiones, ni tampoco la posibilidad de acudir a ellos en caso de necesitarlo.

En paralelo con las actualizaciones de Ruby y Rails, pudimos incluso añadir nuevas funcionalidades, como por ejemplo el sistema de newsletter, o cuando tuvimos que cambiar todo el frontend de la plataforma para hacerlo responsive - inclusive sus más de 150 widgets.

Naiz responsive

Naiz en dispositivos móviles

En proyectos así de grandes, la comunicación es clave. Ahora os contamos cómo nos coordinamos con el equipo de Naiz cada semana.

Primero: el cliente y su equipo técnico crean las tarjetas con las tareas de la semana en un board de Trello compartido con nosotros. Con Naiz, usamos Trello para coordinar las tareas y los milestones (hitos) del proyecto, así como las prioridades entre las tareas. Adicionalmente, usamos Basecamp para centralizar las conversaciones con ellos y mantener todas las decisiones archivadas en una sola plataforma.

Una vez hecho esto, nos citamos para una llamada semanal de media hora con el cliente, para discutir el alcance de las tareas y su priorización. De acorde con el resultado de la llamada, organizamos las tareas en los distintos hitos.

Es importante mencionar que se requiere mucha coordinación cuando dos equipos de desarrollo trabajan en el mismo proyecto, así que hemos definido un conjunto de reglas para separar responsabilidades:

  • El equipo del cliente se encarga de definir las nuevas funcionalidades y de crear las tarjetas en la lista de Trello Inbox.
  • Nosotros desarrollamos solamente en el entorno de development, y cuando terminamos una tarea, hacemos el merge en la rama de develop.
  • Nosotros nos encargamos de mantener al día el estado de las tareas y de mantener el orden en Trello, moviendo las tarjetas de un estado a otro, de un milestone a otro, o a Done cuando las hemos terminado.
  • El cliente y su equipo se encargan de controlar las pull request y de mergearlas a la rama master.
  • El cliente y su equipo se encargan de mover las tarjetas de Done a los diferentes entornos (staging, production, etc.)
  • El cliente y su equipo se encargan de hacer los despliegues y de crear una pull request por cada uno de ellos.

Esta distribución de responsabilidades ha ayudado hasta ahora a evitar situaciones de bloqueo, asegurando que cada parte tiene claro qué tiene que hacer y cuándo lo tiene que hacer. Ambos equipos sabemos donde empiezan y donde acaban nuestras responsabilidades.

Este workflow se hizo a medida para el cliente: ellos querían que desarrolláramos la plataforma, mientras retenían el control de los despliegues. Es por ello que les configuramos Capistrano para que pudieran ser los únicos con permisos para hacer despliegues en sus servidores.

David gomez
David GómezDesarrollador Full-Stack

Trabajar en un proyecto así de grande viene con sus retos, especialmente cuando desplegamos la versión responsive de todo el site. Gracias a este workflow de trabajo, pudimos coordinarnos bien con el equipo de Naiz y testeamos más de 150 widgets y todas sus configuraciones posibles en cuestión de días.

Además de los workflows descritos anteriormente, compartimos una cuenta de Slack con el equipo de Naiz. Esto lo hacemos para los clientes que nos contratan más de 40 horas a la semana de nuestros servicios, para poder tener una comunicación más directa y efectiva cuando lo necesiten.

En este caso, configuramos una cuenta ad hoc con ellos, con distintos canales, cada uno para un tema específico (#deploy, #general, #developers, etc.). Esta cuenta de Slack asegura estar siempre ahí en horario de oficina, y especialmente en los momentos de los despliegues, donde hace falta comunicación instantanea.

Javier artero
Javier ArteroUI/UX Specialist

El reto principal, para mi, fue tener que heredar el código CSS del anterior proveedor. Decidimos que todas las partes que tuviéramos que crear desde cero, las haríamos responsive por defecto, y de manera progresiva fuimos adaptando el resto de componentes existentes a medida que trabajábamos con ellos, para evitar romper la base de código existente.

Trabajar en un proyecto de estas dimensiones está siendo una experiencia harto positiva. Así hemos podido demostrar que podemos lidiar con plataformas de alcance nacional, con miles de contenidos agregados, y alta concurrencia de visitas y operaciones.

Además, en el aspecto personal, hemos desarrollado una relación muy especial con el cliente, lo cual ayuda a explicar por qué llevamos años trabajando con ellos sin que parezca que vaya a haber un final.