Cómo gestionar la construcción de un portal web (con Rebecca Germond de FCV Interactive)

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts mediante un programa de software. Por favor, disculpa cualquier error tipográfico ya que el bot no es 100% preciso.

Ben Aston:

Bienvenidos al podcast de DPM donde vamos más allá de la teoría para ofrecer consejos expertos de gestión de proyectos para liderar mejores proyectos digitales. Gracias por sintonizar. Soy Ben Aston, el fundador de The Digital Project Manager.

Las necesidades de los clientes están madurando, y el rol de las agencias digitales también está cambiando y evolucionando. A medida que el proceso de diseño y construcción de sitios web se ha convertido en algo más estandarizado, existe una necesidad creciente de agencias que puedan ser más que un socio web, sino un socio estratégico y técnico también, para construir no solo sitios web, campañas o landing pages. En el podcast de hoy, vamos a centrarnos un poco en la construcción de portales: qué son, cómo se crean y algunas conclusiones y lecciones aprendidas si vas a embarcarte en uno de estos proyectos. Sigue escuchando si quieres enterarte de la evolución de las agencias digitales y un enfoque de desarrollo de productos para la gestión del cliente.

Hoy me acompaña Rebecca Germond. Rebecca es la directora de servicios al cliente en FCV. Tiene una base sólida en gestión de proyectos y comunicación en medios. De hecho, Rebecca es alguien a quien contraté hace unos años. Recuerdo tu entrevista, cuando te traje a la sala y pensé: sí, claro, contrataré a esta chica. No recuerdo bien qué te pregunté, pero pensé que ni siquiera necesitaba entrevistarte. Estabas contratada. ¿Recuerdas la entrevista?

Rebecca Germond:

Sí que la recuerdo. Sentí que me interrogaron mucho. No, es broma. Es broma. La recuerdo muy bien porque recuerdo la vista desde la oficina y eso fue lo que me convenció, creo, de FCV y por supuesto, nuestra conversación.

Ben Aston:

No fui yo. Fue la vista.

Rebecca Germond:

Sí.

Ben Aston:

Rebecca, para aquellos que se preguntan qué haces cada día, ¿en qué consiste ser directora de servicios al cliente? ¿Es gestión de proyectos? ¿Gestión de cuentas? ¿Qué significa eso para ti en este momento?

Rebecca Germond:

Sí, es un poco de ambos, además de gestionar el propio equipo de PM, lo cual es genial. Es un rol nuevo para mí en el último año más o menos. Ya no me ensucio tanto las manos con los proyectos. Hay unos pocos que no quiero soltar, pero realmente trabajo directamente con los PMs para asegurarme de que puedan entregar y darles el apoyo que necesitan. También gestiono la mayoría de nuestros clientes, así que tengo una buena relación de gestión de cuentas con ellos. En realidad, empecé en cuentas antes de convertirme en productora y gestora de proyectos, así que es un pequeño regreso a mis raíces, y eso me gusta.

Ben Aston:

Genial. Para quienes estén interesados en este puesto de gestionar un equipo de gestores de proyectos, ¿cómo es ese día a día? ¿Cómo los gestionas? Porque no puedes estar en los detalles de todos sus proyectos a la vez. Cuando hablas con ellos, ¿qué es lo que haces realmente?

Rebecca Germond:

Sí, es una gran pregunta. Lo que hago, en su mayor parte, es revisar mucho trabajo o entregables que ellos quieren enviar. Por ejemplo, les doy feedback sobre un SoW o un cronograma. Si alguna vez hay algún problema o escalada, participo o ayudo a los PM a responder en situaciones delicadas. Me reúno con ellos individualmente una vez a la semana, pero también conectamos por Slack y me aseguro de que todos se sientan apoyados en el día a día. De vez en cuando, me uno a sus reuniones más importantes con el cliente. Es un poco de todo eso.

Además, participo mucho en el proceso de desarrollo de negocio en FCV. También trabajo día a día administrando cuánto facturaremos a nuestros clientes y asegurándome de que llevamos un buen control del proceso de gestión de cambios. Muchas otras cosas del día a día junto a los PMs.

Ben Aston:

Cuéntanos un poco sobre tu historia. Tu experiencia era en gestión de cuentas. Sé que empezaste en el Ministerio de Trabajo. ¿Cómo pasaste del Ministerio de Trabajo a una agencia digital y a la gestión de cuentas y proyectos? ¿Cómo fue ese proceso?

Rebecca Germond:

Totalmente. Cuando estaba en la escuela, mi tía tiene una agencia de trabajo temporal. Ella me encontraba trabajos cuando yo buscaba mi lugar. Sabía que quería trabajar en una agencia. Conseguí una colocación en el Ministerio de Trabajo. Era más un trabajo administrativo para el gobierno, pero estuvo bien. Aprendí muchos procesos del gobierno, lo cual después me ayudó en mi carrera porque la mayoría de los proyectos en mi primera agencia, y ahora en FCV, están relacionados con el sector público. Fue útil.

Una vez, me ubicó en una agencia, Manifest Communications en Toronto. Era solo para dos semanas en recepción mientras alguien estaba de vacaciones, y me pidieron que me quedara como becaria, lo cual era lo que yo buscaba. Estuve allí tres meses y luego me contrataron y trabajé allí cuatro años. Cuando empecé, era ejecutiva de cuentas, así que gestionaba clientes y menos proyectos digitales. Poco a poco fuimos entrando en eso. Después del primer año fui productora y el trabajo era probablemente un 60% digital, pero también llevé radio, transmisión y algo de prensa, lo cual era muy interesante.

Ben Aston:

Genial. Cuéntame. Todavía estamos en el primer trimestre del año. Desde tu perspectiva profesional o de crecimiento, hoy hablamos de portales y cómo eso es una evolución, pero ¿tienes algún objetivo personal de carrera que te hayas marcado para este año?

Rebecca Germond:

En realidad, es curioso. No quiero ponerme metas profesionales específicas este año. Suena raro. Estoy en mi último año de mis veinte, así que solo quiero vivir como Millennial. Tengo algunos objetivos de viaje. Eso es lo que me motiva ahora. En lo profesional, he disfrutado trabajar en este portal. Lo hemos convertido en un producto y constantemente hacemos lanzamientos y construimos algo nuevo. Me encanta. Me gustaría hacer más de eso.

Ben Aston:

Genial. Hablamos un poco de tu rol y lo que haces, pero ¿cuáles son los retos que enfrentas ahora o cuál es tu principal dolor de cabeza diario, algo de lo que estás tratando de salir adelante ahora mismo con algún proyecto en particular o en general?

Rebecca Germond:

Creo que en el día a día, estoy acostumbrada a estar muy encima del equipo de proyecto, si sabes a lo que me refiero. Todos, como gestores de proyectos, tenemos que lidiar con muchos egos o diferentes tipos de personalidad. Ahora, en una escala donde hay menos proyectos y en realidad toda la organización tiene diferentes necesidades y prioridades, estoy intentando equilibrar eso y asegurarme de que los PM tengan lo que necesitan, que es súper importante. Eso lo siento difícil. Además, a veces te involucras en cosas que no pensabas que serían tan relevantes como tareas administrativas. Es complicado llevar mi propia lista de pendientes estos días.

Ben Aston:

¿Cómo llevas el control de las cosas? ¿Cómo es tu lista de pendientes? ¿Tienes un sistema?

Rebecca Germond:

Uso Evernote principalmente, pero hemos agregado una nueva integración en Slack llamada Workast, donde puedes tener tu lista de tareas en un canal de Slack y asignarlas si quieres. También puedes escribir una nota para ti misma en Slack y allí aparece tu lista de tareas y te recuerda cuándo debe completarse algo. Aún estamos empezando a usarlo, pero de momento me gusta bastante.

Ben Aston:

¿Se llama Workast?

Rebecca Germond:

Workast. W-O-R-K-A-S-T.

Ben Aston:

Workast, ok. Nombre curioso, Workast.

Rebecca Germond:

Definitivamente. Por ahora va bien. El problema es que apenas reviso mi lista de pendientes antes de las 9:00 o después de las 5:00. Así lo siento porque el 70% de mi día son reuniones o responder emails y mensajes en Slack, lo que hace difícil ser productiva últimamente.

Ben Aston:

¿Qué más hay en tu kit de herramientas de PM? Ya tienes un sistema para tus tareas, que te ayuda a priorizar. ¿Qué más utilizas? ¿Cómo gestionas los proyectos?

Rebecca Germond:

Tengo bastantes herramientas. Hemos cambiado varias veces en los últimos años y ahora estoy contenta con lo que tenemos. Uso Evernote. Usamos Jira bastante en serio. Todos, incluidos UX, diseño y clientes, estamos en Jira, y eso facilita porque está todo en un solo sitio y podemos hacer seguimiento a los tickets. Uso Slack religiosamente.

Estamos probando Microsoft Teams en vez de Skype for Business, especialmente como línea de conferencia para nuestras reuniones con clientes. Funciona bien. Para planificar proyectos uso Merlin. Usábamos MS Project, pero solo utilizábamos un 15% de sus capacidades. Tenemos varias licencias de MS Project por si algún cliente lo pide. Spotify, eso definitivamente está en mi kit de herramientas. Lo necesito. Y Outlook, aunque el email es lo que más odiamos.

Ben Aston:

¿Aparte de Workast, hay otras herramientas que hayas encontrado recientemente o que hayan revolucionado cómo gestionas proyectos?

Rebecca Germond:

No mucho. Creo que cómo usamos Jira ahora, integramos notificaciones en Slack. Si un ticket se actualiza, cambia el estado o un cliente comenta, Jira te manda 40 correos al minuto, pero sólo las cosas clave se mandan al canal de Slack para saber quién ha hecho un comentario. Eso nos lo ha hecho muy fácil porque nadie lee los emails de Jira. MS Teams también es genial porque ahora muchos clientes han aceptado usar video, algo que antes no pasaba.

Ben Aston:

Genial. Hablemos de tu publicación, tu caso práctico, ¡el primero que publicas! Felicitaciones, Rebecca.

Rebecca Germond:

Gracias.

Ben Aston:

Hablemos de un portal. ¿Un portal es solo una web o es diferente? Si es diferente, ¿por qué y en qué se diferencia?

Rebecca Germond:

Para mí, los portales son bastante complejos porque suelen estar hechos a medida para muchos tipos de usuarios y cada usuario puede tener diferentes acciones, características o recorridos propios. Para este portal en concreto, había tres niveles distintos de usuario que había que considerar y cómo se relacionaban entre sí fue algo que subestimamos al principio. En general, los portales pueden volverse muy complejos por la cantidad de variables y particularidades que no encuentras en un sitio web habitual si solo llegas y navegas por la página de inicio.

Ben Aston:

Hablamos, entonces, de algo con mucha más interactividad en cuanto a funcionalidades basadas en roles que se habilitan o deshabilitan según lo que haces en el portal.

Rebecca Germond:

Exacto. Para nuestro portal en particular, si no tienes acceso, no puedes hacer mucho desde la página de inicio. Hay barreras para acceder y no es fácil incorporar nuevos clientes al portal. Hay muchos factores a considerar que no aplican a una web normal.

Ben Aston:

Interesante. Para concretar, danos una breve descripción de la funcionalidad de este portal.

Rebecca Germond:

Perfecto. Este portal... básicamente nuestro cliente es un minorista de electrónica y tiene clientes B2B, es decir, empresas que compran productos en grandes cantidades. Antes de tener el portal, básicamente tomaban el teléfono y llamaban a su gestor de cuentas para hacer el pedido de manera totalmente manual. Esto era una molestia para todos y también para los clientes, porque nadie quiere llamar por teléfono ahora. Lo que buscaban era un portal donde cada usuario pudiera acceder, ver un catálogo de productos asignados para su empresa y comprar solo esos productos. Además, hay un mecanismo complicado de descuentos porque sin el portal y ese sistema, cualquiera podría comprar por la web de consumidor. Como compran al por mayor, tienen descuentos personalizados según el volumen y tipo de producto que compran. Ese es un aspecto.

También tenemos un carrito de compras. Hay un panel donde ven los productos que piden con más frecuencia, sus pedidos abiertos y cualquier pedido hecho en los últimos 30 días. Hay herramientas útiles en el panel para ayudarles a ver todo lo que ocurre en su mundo dentro del portal.

Además, hay varios niveles de usuario. La mayoría puede hacer pedidos, pero un administrador del cliente debe aprobar la compra según la organización. Antes de que pase el pedido, el administrador debe aprobarlo o decirle que excede el presupuesto, así que no podemos procesar el pedido. Hay muchas idas y vueltas en ese sentido también.

Ben Aston:

Interesante. Es decir, si soy una organización grande, como Telus, y quiero pedir 2.000 monitores, ingreso al sistema, compro, pero hay aprobación en el proceso de compra y puedo seguir mi pedido.

Rebecca Germond:

Sí, exacto.

Ben Aston:

Es eCommerce a escala.

Rebecca Germond:

Exacto.

Ben Aston:

Genial. En tu artículo hablas de tecnología interesante. ¿Puedes contarnos brevemente sobre el stack tecnológico, la arquitectura y cómo se construye? ¿Qué lo hacía interesante?

Rebecca Germond:

Claro. Definitivamente nuestros desarrolladores pueden dar más detalles, pero te cuento un resumen general.

Ben Aston:

La versión de gestión de proyectos.

Rebecca Germond:

Sí. Lo que hacemos es que usamos .NET Core para los microservicios, y React en el front-end para dar la interfaz de esos microservicios. Básicamente, nos referimos a que esos microservicios son solo endpoints reutilizables para lo que quieras. Por ejemplo, los datos del volumen de pedidos; esa información la mostramos en el panel o podemos manipular los datos de distintas formas, lo cual es genial. React es emocionante para nuestros maquetadores y desarrolladores. Cuando usamos React, creamos una librería de componentes reutilizable para no reconstruir cosas una y otra vez y así mantener una experiencia consistente y acorde con su marca, sin que sea demasiado diferente de su web para consumidores.

Ben Aston:

Genial. ¿No hay CMS? ¿Cómo gestionasteis eso? Dentro de .NET ¿se puede agregar o editar productos? ¿Hay CMS? ¿Cómo funciona?

Rebecca Germond:

No. Lo bueno es que toda la información del producto nos viene de la API del cliente, la que usan en su web para consumidores. Toda esa información se actualiza constantemente. Hay un script que corre una vez al día para asegurarnos de tener el precio y los datos del producto más actualizados. Es un proceso completamente automatizado para añadir o actualizar productos, lo cual es genial.

Ben Aston:

Eso está genial. Era un desarrollo de producto, construir un portal, algo nuevo. ¿Cómo planificaste el desarrollo? ¿Cuál fue tu proceso para organizar la construcción?

Rebecca Germond:

Definitivamente optamos por un enfoque MVP, producto mínimo viable, que funcionó y a la vez no tanto porque a medida que avanzaba el proyecto, lo que era MVP iba creciendo y ya no era tan mínimo. Al principio, cuando planificamos la línea de tiempo y la estimación, el enfoque MVP nos ayudó mucho. Como teníamos un backlog bastante claro, empezamos enseguida con sprints de desarrollo. No nos detuvimos mucho en la recopilación de requisitos para este proyecto. Lo que hacíamos era abordar los requisitos en una reunión de planificación de sprint sobre las características que intentaríamos completar ese sprint.

Ben Aston:

Respecto al MVP, ¿teníais un presupuesto y una fecha límite para él? Con mucho backlog, ¿cómo decidisteis qué se incluía y qué quedaba fuera del presupuesto? ¿Cuándo definisteis el presupuesto? Creo que ese es uno de los principales retos.

Rebecca Germond:

Lo fue, en efecto. Lo difícil de trabajar en ágil en una agencia es que los clientes quieren ver el coste de todo. El ágil puro funciona quizá con un modelo de coste por sprint, pero puede que tras un sprint no tengas una funcionalidad terminada. Lo que intentábamos era cotizar por funcionalidad, para que supieran exactamente cuánto costaba cada feature y pudieran priorizar. Algunas funcionalidades dependían de otras. Cuando definimos el MVP, ahí pudimos establecer el coste y lo que hacía falta para todas las dependencias. Basándonos en ese precio a la carta, agrupábamos para que funcionara en modo sprint. Teníamos cinco meses para acabar el proyecto y un mes de UAT al final. Dos semanas de montaje de entornos. Creo que hicimos seis o siete sprints en total.

Ben Aston:

Mencionas en el caso que subestimasteis mucho algunas funcionalidades obligatorias, pero dices que eso lo hizo divertido. Entre líneas entiendo que subestimasteis esos elementos a la carta, ¿por qué?

Rebecca Germond:

Creo que la mayor la subestimada fue la construcción del catálogo y aplicar los descuentos. Pensamos que solo era añadir un descuento a ciertos productos, pero luego la lógica de su API y sus distintas categorías y particularidades hizo todo muy complejo. Había una capa más, porque querían excluir algunos productos, como Apple, ya que no ganan casi nada allí, así que no querían aplicar descuentos esos productos. Tuvimos que asegurarnos de que, si decían excluir Apple, se mostraban solo los productos con ciertas características, menos Apple, y se aplicaba el descuento. Eso lo complicó mucho.

Con este cliente era un proyecto a precio cerrado. Donde pudimos recuperar tiempo y dinero fue con solicitudes de cambio que añadieron durante el camino, incluso para funcionalidades ya incluidas. Hicimos todo lo posible por seguir con el proceso de gestión de cambios. Pero si uno mismo subestima algo, es difícil volver al cliente y decirle que nos equivocamos.

Ben Aston:

Parte de eso es porque los requisitos, parece que la complejidad de los descuentos no estaba clara desde el inicio, ¿verdad?

Rebecca Germond:

Exactamente. Al principio, cuando definimos los requisitos, el motor de descuentos o lo que fuera debía ser mucho más simple. Pero se complicó conforme avanzamos.

Ben Aston:

Creo que eso es común en proyectos más ágiles: todo el sentido del método es adaptarse a escenarios no del todo claros, pero requiere un modelo de costes que lo refleje. Aquí teníais precio cerrado frente a requisitos poco claros. Con lo que sabes ahora, ¿cómo lo planearías la próxima vez?

Rebecca Germond:

Creo que lo hicimos bien con los requisitos que había. Lo que me gustaría intentar con este cliente... tenemos una relación de trabajo genial, él lo entiende y forma parte de nuestro equipo, lo cual ayuda mucho. Intentamos vender el modelo de coste por sprint, aunque aún no lo logramos del todo, pero tenemos margen con el calendario y el cliente es comprensivo. Si empezara de nuevo, quizá daría un rango aproximado al inicio para que pueda conseguir que le aprueben el presupuesto. Luego, en cada sprint, estimaría lo planificado y daría un precio según el equipo necesario y lo que pretendíamos lograr. Por lo demás, no cambiaría mucho del equipo. Me gustó que fuésemos pocos. Si hay muchos involucrados del lado cliente, todo es más difícil, pero aquí quedaba el cliente clave y el stakeholder apropiado para la funcionalidad del sprint, eso fue genial.

Ben Aston:

Genial. Hablando del pequeño equipo, en el artículo dices que fue útil. Hablas de un enfoque ágil híbrido en desarrollo y diseño. ¿Cómo era el equipo? ¿Cómo conjugaste diseño y desarrollo?

Rebecca Germond:

Sí, es difícil. En agencia, en general, es muy complicado trabajar full ágil. Porque los clientes no suelen pagar por un equipo fijo cinco meses. Quieren saber el coste de cada funcionalidad. Así que cambiar esa visión es complejo. Si eres interno, con tu propio producto y equipo dedicado, es distinto. Con varios proyectos a la vez, es difícil hacerlo ágil.

En nuestro híbrido éramos dos de back-end, dos de front-end, un UX y diseñador a media jornada que entraba cuando hacía falta para revisar lo creativo y las funcionalidades, y un QA a media jornada o 50% en sprint. Sin analista de negocio, que creo no fue problema, porque sabíamos qué construir. Creo que un BA no hubiera identificado la lógica de la API ni nos habría facilitado la estimación. Tampoco tuvimos estratega porque el producto era claro y el cliente tenía una visión definida para el MVP y el caso de uso estaba claro. Ese era el equipo. Y yo, claro.

El enfoque fue: como era de cero, sin componentes previos, solo teníamos las reglas de marca y las features a construir. Diseño y UX iban un sprint por delante del desarrollo, lo cual no es ágil puro, pero el cliente nunca había visto nada nuestro, así que necesitábamos adelantar el look&feel y obtener su feedback antes que el desarrollo. El primer sprint de diseño y UX lo solapamos con la preparación del entorno y configuración del proyecto de los desarrolladores. El cliente, por suerte, sí trabaja ágil o lo intenta, así que fue fácil de entender y valoró el método. Aplicamos todas las ceremonias: daily, revisiones intermedias, demos, retrospectivas... y el cliente participaba en casi todas.

Ben Aston:

Muy bien. Hablemos del cliente. En este caso era el product manager, ¿verdad? No muchos stakeholders, solo uno. Dices que fue estupendo, pero también que soñaba con nuevas funcionalidades durante el proceso. Cuando te pagan un precio fijo pero usas enfoque ágil, donde pueden inventar nuevas funciones, ¿cómo lo gestionasteis?

Rebecca Germond:

Fue difícil, pero cada vez que proponía una nueva funcionalidad, entendía que era una solicitud de cambio y le cotizábamos la nueva feature. El problema era parar el trabajo del sprint para calcular la estimación, que necesitaba para aprobarla; eso era complicado. El cliente actuaba de product owner, con autonomía plena y preparado para el proyecto. Lo traían planeando tiempo antes de que entrásemos nosotros. Fue positivo porque nos permitió aportar feedback e ideas sobre nuevas funcionalidades que no habían considerado.

Trajo ideas interesantes en medio del proyecto, pero eran cosas importantes. Por ejemplo, al principio pensaron que darían de alta a los usuarios manualmente, enviándoles un PDF, pero después de la tercera iteración quisimos hacer un asistente de configuración para que los usuarios reciban su login por email, puedan cambiar la contraseña y descargar y subir los formularios necesarios. Eso facilitó mucho la gestión interna y mejoró el producto, aunque no estuviera previsto al principio.

Ben Aston:

Genial. Mencionas como aprendizaje que hay que mantener el equipo y cliente involucrados. Suena a que el cliente estuvo muy involucrado. ¿Qué consejos darías para asegurar y fomentar ese compromiso?

Rebecca Germond:

Para nosotros, la forma de trabajo era nueva en FCV porque muchos clientes son tradicionales o institucionales, llevan años y siguen en su metodología antigua. Pero aquí el compromiso e involucración del cliente fue gratificante porque descubrimos que sí quieren ese nivel de participación. También queríamos ese nivel de compromiso porque buscamos una fase dos del proyecto. Vimos que no era una web con un principio y un fin, sino algo vivo y en evolución. Así lo tuvimos involucrado.

El equipo estaba motivado porque podían elegir su stack, probar cosas nuevas, elegir herramientas. Además, les gustaba poder hablar directamente con el cliente, lo que no todos quieren, pero en nuestro caso el cliente estaba en Slack y podía comentar ideas directamente, así que todos estaban muy comprometidos al construir algo propio y que les hacía ilusión.

Ben Aston:

Sobre tus lecciones aprendidas, hablas de eliminar procesos innecesarios y abrazar los que sí aportan valor. Dices que uno de los beneficios fue refinar el proceso de gestión en la agencia. ¿Qué procesos eliminaste y cuáles refinaste luego?

Rebecca Germond:

Sí, tras la segunda retrospectiva de sprint decidimos dejarlas. Vimos que ya sabíamos lo que funcionaba y lo que no, así que invertir ese tiempo ya no sumaba y solo restaba tiempo al desarrollo, que no queríamos. Y el cliente, al estar tan involucrado, nos daba feedback en tiempo real si algo no iba bien. Así que las retrospectivas cayeron pronto.

También costaba hacer los daily o scrums porque medio equipo estaba en Toronto y otro en Vancouver. Intentamos hacer scrums de 15 minutos en vez de resolver por Slack durante una hora. Al principio fue a las 9:30, pero cuando cogimos ritmo, eran ad hoc o simplemente preguntas rápidas en Slack. Seguramente mantuvimos los daily formales tres sprints y luego los fuimos espaciando o trasladando a Slack.

Ben Aston:

¿Hubo algún proceso que suprimisteis porque parecía innecesario y luego volvisteis a añadir?

Rebecca Germond:

No realmente, aunque sé que lo que lamentamos es no haber introducido QA antes. No fue hasta el tercer sprint que tuvimos algo listo para testeo, y quizás deberíamos haber empezado antes. Recuerdo que en algunas demos estábamos trabajando hasta cinco minutos antes, comiteando código y esperando que todo funcionara. Era algo caótico al final, pero también divertido.

Ben Aston:

Muy bien. Rebecca, muchas gracias por acompañarnos. Ha sido un placer tenerte con nosotros.

Rebecca Germond:

Gracias. Cuando queráis.

Ben Aston:

Un placer. Si te interesa la construcción de portales, mira el caso práctico que escribió Rebecca, donde encontrarás mucha información útil. Si quieres conversar sobre construcción de portales, únete a nuestro equipo en Slack. Ve a digitalprojectmanager.com/slack donde hay muchas conversaciones interesantes sobre gestión digital. Y si te ha gustado el episodio de hoy, entra en Apple Podcast (antes iTunes) y déjanos una reseña. Nos encantaría recibir tu opinión, las valoraciones y comentarios ayudan mucho al programa. Hasta la próxima, gracias por escuchar.