Cómo gestionar la construcción de un sitio web corporativo (con Rich Butkevic de Project Zendo)

Leer la transcripción:

Estamos probando la transcripción de nuestros podcasts utilizando un programa de software. Por favor, disculpen los errores tipográficos, ya que el bot no es 100% preciso todo el tiempo.

Ben Aston

Gracias por escucharnos. Soy Ben Aston, fundador de The Digital Project Manager. Bienvenidos al Podcast de DPM. Ya seas un gestor de proyectos experimentado, un productor digital, o algo completamente diferente, tal vez simplemente te encuentras de repente a cargo de gestionar proyectos, solo quiero que sepas que hoy, en tus auriculares, estás acompañado por miles de personas en la misma situación, haciendo todo lo posible por comenzar, planificar y entregar mejores proyectos.

En thedigitalprojectmanager.com estamos aquí para ayudarte a ser más seguro y competente como gestor de proyectos, y para conectarte con otros que también están gestionando y liderando proyectos. Si realmente quieres llevar tus habilidades de gestión al siguiente nivel, revisa nuestra DPM School y suscríbete a nuestra membresía profesional para obtener acceso a todos nuestros recursos seleccionados.

Finalmente, mientras escuchas este episodio, suscríbete y únete a nuestra lista de correo en thedigitalprojectmanager.com para mantenerte al día con todo lo que sucede. Así que si alguna vez has trabajado en la construcción de un sitio web corporativo, sabrás perfectamente que son increíblemente difíciles de hacer bien. Parte de eso es porque no es algo que se haga muy a menudo, pero hay más razones: objetivos poco claros, un brief vago, esa maraña de interesados y mucha política interna.

Todo esto hace que terminar un sitio web corporativo, y hacerlo bien, sea increíblemente difícil. Añade algunos retos técnicos y esos proyectos de sitios web nuevos y relucientes pueden convertirse en un desastre absoluto. Así que, en el podcast de hoy, vamos a explicar cómo puedes construir sitios web corporativos correctamente; sigue escuchando para averiguar cómo puedes planificar, gestionar y controlar tus futuros proyectos de sitios web corporativos y lograr hacerlo bien.

Gracias por sintonizarnos. Soy Ben Aston, fundador de The Digital Project Manager, y bienvenidos al Podcast de DPM. Ya seas un project manager experimentado, un productor digital o estés por casualidad al frente de proyectos, debes saber que hoy te acompañan miles de personas en la misma situación intentando iniciar, planificar y entregar mejores proyectos. En thedigitalprojectmanager.com estamos para ayudarte a confiar más en ti mismo y mejorar como project manager, y para conectarte con otros que también gestionan y lideran proyectos.

Si realmente quieres mejorar y llevar tus habilidades de PM al siguiente nivel, explora nuestra DPM School y asegúrate de suscribirte a nuestra membresía pro para acceder a todos nuestros recursos seleccionados. Por último, mientras nos escuchas, suscríbete y únete a nuestra lista de correo en thedigitalprojectmanager.com para estar al día de todo lo que sucede.

Este podcast es patrocinado por Clarizen, el líder en Software Empresarial de Gestión de Proyectos y Portafolio. Visita clarizen.com para saber más. Hoy estoy acompañado por Rich Butkevic-

Rich Butkevic

Perfecto.

Ben Aston

¿Lo pronuncié bien?

Rich Butkevic

Lo dijiste perfecto.

Ben Aston

Ah, ahí lo tienes, lo practiqué. Rich es consultor de gestión de proyectos y autor del blog projectzendo.com. Así que échale un vistazo. Además, dirige talleres de gestión de proyectos por todo Texas. Consulta artofpmo.com si te interesa. Hablaremos de ello en un momento. Pero Rich posee una combinación única de experiencia en liderazgo en gestión de proyectos y productos, QA, análisis de negocio, marketing y formación. Utiliza Agile y Scrum, tiene todas las letras y certificaciones que uno podría desear: PMP, Certified Scrum Master, IBM Rational Unified Process, es una persona certificada por Amazon y E-Marketer. Lo tiene todo.

Hola Rich, gracias por acompañarnos hoy.

Rich Butkevic

Hola Ben, gracias por invitarme. Lo aprecio.

Ben Aston

Bueno, quiero empezar indagando en todas esas certificaciones y letras después de tu nombre. Hay quienes dicen "no me interesan las certificaciones", pero tú elegiste el camino opuesto y conseguiste todas las que existen. ¿Eso se basa en una pasión particular por el aprendizaje? ¿O qué te motivó a certificarte en todo?

Rich Butkevic

No sé si en todo, pero me apasiona aprender. Es algo que me gusta realmente. Pero creo que obtener una certificación en dirección de proyectos, o en cualquier cosa, demuestra lo serio que eres con la profesión y que te mantienes actualizado. Además de la PMP, las otras certificaciones las fui obteniendo según las necesidades de los proyectos.

Por ejemplo, con la certificación de AWS, si estaba en un proyecto usando Amazon Web Services, me gusta involucrarme a fondo en la tecnología para hacer mejor mi trabajo como PM. Y así, descubrí que me gustaba y quería aprender más, y ya que iba a aprender más de todos modos, es bueno tener un objetivo por el que esforzarse. Así que suelo ponerme como meta certificarme; por eso las he ido acumulando.

Ben Aston

Muy bien, cuéntanos cómo entraste por primera vez en el mundo de la gestión de proyectos. Claramente tienes perfil técnico. No conozco muchos PMs con una certificación técnica como AWS-

Rich Butkevic

Claro.

Ben Aston

Pero ¿cómo comenzaste y te metiste en la dirección de proyectos?

Rich Butkevic

En la universidad, trabajaba en soporte técnico, respondía llamadas cuando surgía el internet de banda ancha, así que me involucré desde el principio con lo técnico, en una época interesante. Luego de graduarme, fui analista de negocios en una gran empresa de telecomunicaciones en Chicago, donde vivía. Después pasé a QA, empecé a gestionar QA y luego pasé a la gestión de proyectos en esa empresa; después me certifiqué y así siguió la cosa.

Ben Aston

Genial, tengo curiosidad, porque pasaste por soporte técnico, QA y luego gestión de proyectos. Primer día como project manager, seguro aprendiste muchas lecciones. ¿Qué le dirías a tu "yo" más joven, en su primer día de gestión de proyectos, sabiendo lo que sabes ahora?

Rich Butkevic

Claro.

Ben Aston

Pensando en ese primer día con el título de project manager, ¿qué consejo te darías?

Rich Butkevic

Lo más importante sería que no se trata de la herramienta. Muchos project managers se enfocan demasiado en conocer todos los detalles de la herramienta de gestión de proyectos que usan. Pero en mi opinión, la herramienta es solo una manera de agilizar, automatizar y ayudar a gestionar un proceso que deberías saber hacer con un lápiz y un papel.

Si no te sientes cómodo gestionando un proyecto con solo un bolígrafo y un cuaderno —no digo que debas hacerlo así—, pero ser un buen project manager no es saber más de Microsoft Project o cualquier otro software. Es mucho más, más habilidades blandas y tener claro qué quieres lograr como PM, más allá de manejar el software.

Ben Aston

Totalmente. Pero hablando de herramientas, porque me gustan las herramientas.

Rich Butkevic

Sí, a mí también.

Ben Aston

Entonces, ¿qué tienes en tu kit de PM además del bolígrafo y la libreta que mencionaste?

Rich Butkevic

Claro. Aparte de la herramienta de gestión de proyectos que se use, lo que más diferencia ha marcado en mi kit es alguna herramienta de colaboración. Me encanta Slack. Lo encuentro simple y fácil de usar, y marca una gran diferencia frente a gestionar cosas por emails y archivos de Excel por toda la empresa en carpetas compartidas que nadie puede encontrar.

Me gusta Slack, aunque la idea detrás de la herramienta es más importante que la herramienta que elijas.

Ben Aston

¿Tienes integraciones en Slack que te ayuden especialmente? ¿Algo que permita más colaboración y te ayude a potenciar esas habilidades blandas?

Rich Butkevic

No se me ocurre nada aparte de integrar el seguimiento de tiempo que uso como consultor. Las empresas para las que trabajo suelen tener estándares a cumplir. Así que aunque cambie el software de gestión del tiempo que se integra con Slack, tener eso integrado es bueno, pero lo más útil en Slack ha sido aprender los atajos de teclado. Eso ha hecho una gran diferencia.

Ben Aston

Dinos tu atajo favorito.

Rich Butkevic

Vaya. Ahora me pones en un aprieto. No sabría decirte, parece que los sé por instinto, mis dedos los recuerdan…

Ben Aston

Seguro que sí.

Rich Butkevic

Pero no mi cerebro.

Ben Aston

No los puedes citar, pero sabes usarlos, sí.

Rich Butkevic

Sí, sí. Es como mi número de teléfono, a veces me cuesta decírselo a alguien, pero lo marco sin problemas si hace falta.

Ben Aston

Eso es gracioso. Pero volvamos a tu punto: no se trata de las herramientas, y ahora hemos empezado a hablar de herramientas. Así que volvamos a tu punto-

Rich Butkevic

Claro.

Ben Aston

Que es que la buena gestión de proyectos no depende de las herramientas. Cuéntanos más sobre lo que has descubierto de ese arte en la gestión y cómo usas esas habilidades blandas para entregar mejores proyectos.

Rich Butkevic

Por supuesto. Cuando hablo de habilidades blandas, me refiero a cosas como la comunicación, pero no solo eso. También es entender a nivel conceptual qué hace realmente un project manager y cómo debe funcionar un proyecto idealmente, para así centrarse en lo esencial y no en tareas que no sirven para nada.

A lo largo de un proyecto hay unos grandes bloques en los que debes enfocarte, y luego tareas más concretas dentro de ellos. Pero esencialmente debes identificar los requisitos, asegurarte de que el negocio y, si el proyecto es de TI o web, el equipo técnico, entiendan mutuamente los requisitos y necesidades. Debes garantizar las pruebas, la gestión de incidencias y estar pendiente de los sumarios de tareas en un plan de proyecto, entendiendo bien el objetivo mayor y el porqué de cada acción.

Si no puedes explicar en un tuit por qué estás rellenando un documento o haciendo una tarea, deberías parar y aclararlo, porque si no sabes para qué lo haces, no lo harás bien o quizá ni debas hacerlo.

Ben Aston

Totalmente. Entremos en el tema de gestionar la construcción de sitios web corporativos. Publicamos hace poco un artículo sobre por qué estos proyectos salen mal. Una guía para project managers que deberíais leer en thedigitalprojectmanager.com. La realidad es: es difícil. Son proyectos duros. Las empresas contratan agencias, consultores, buscan ayuda externa para actualizar, migrar a la nube, implementar un nuevo CMS o integrar herramientas. Pero, por la naturaleza de estos proyectos, normalmente no suceden a menudo, hay quien solo los gestiona una o dos veces en su carrera.

Eso lo hace desafiante, y como dijimos, hay muchos interesados, briefs poco claros, política interna y retos técnicos. Si no has leído el artículo de Rich, léelo. Hablemos del proceso, de cómo optimizarlo y sobre la conciencia de Rich de lo que debe pasar para el éxito. Empecemos explorando por qué es tan difícil, comparte un ejemplo o anécdota de cómo algo salió mal y luego yo compartiré una.

Rich Butkevic

Por supuesto. Una de las lecciones que aprendí temprano en mi carrera fue “confía pero verifica”. Muchas veces los recursos del proyecto decían que habían completado una tarea cuando en realidad querían decir que planeaban hacerlo o que estaba en su lista de cosas pendientes y, como suele pasar, lo postergaban o se olvidaba. A veces esto no se revela hasta llegar a producción, lamentablemente.

Así que eso es algo que aprendí pronto. Además, colaborando con equipos grandes y distribuidos geográficamente, eso ha sido clave, especialmente porque en proyectos grandes ya no puedes confiar en el esfuerzo heroico de una o dos personas.

Como dijiste, en proyectos web corporativos, un consultor como yo puede hacerlo varias veces al año, pero un administrador de red puede que solo lo haya hecho una o dos veces en su carrera de más de 15 años.

Así que, aunque para mí sea más o menos de rutina, para el recurso corporativo no lo es en absoluto.

Ben Aston

Sí. Compartiré una anécdota de cuando salió mal. Hace unos años en un proyecto web corporativo, el gran reto fue alinear el brief, relacionado con la gestión de interesados. Quien gestionaba el proyecto internamente no consiguió recabar todos los inputs de su equipo.

Hizo un brief sin aprobaciones reales y seguimos adelante. Cuando estuvimos a punto de lanzar descubrimos que había una capa adicional de validación que no conocíamos. Nos dijeron: “Ahora solo falta la aprobación del fundador y presidente”. Y nunca lo mencionaron antes. Resultó que esa persona era la “jefa de verdad”.

Rich Butkevic

Así es.

Ben Aston

Tenía ideas muy claras sobre lo que quería o no, y eran fundamentales para todo el proyecto.

Rich Butkevic

Claro.

Ben Aston

Tuvimos una conversación difícil: “Esto no estaba incluido, firmaste durante todo el proceso y ahora el presidente no está contento y nadie más lo está”. Tuvimos que emitir un cambio masivo y estuvieron molestos. No sé si por tener que pagar más, pero eso tensó la relación.

Rich Butkevic

Claro.

Ben Aston

También fue culpa nuestra, por no profundizar en la estructura de gobernanza al principio. Deberíamos haber verificado a fondo cada aprobación antes de avanzar.

Rich Butkevic

Sí, especialmente en grandes empresas donde identificas 12 interesados pero todos tienen un jefe, y esos jefes tienen a su vez un jefe, y si un jefe suficientemente grande ve un cambio que no le gusta, puede revertir todo.

Ben Aston

Una de las lecciones fue explicar las consecuencias de eso. Ahora procuro mapear a los interesados y hacer un RACI por hitos. Y aclaro: “Si luego descubrimos que otro tiene la última palabra, habrá impacto en costos y tiempos. Así que aclarémoslo desde ya.”

Suele pasar que el marketing encarga el proyecto a alguien junior, que luego dice: “Pues aviso a mi jefe”.

Rich Butkevic'

Exacto.

Ben Aston

“Quizá debamos avisar a más gente.”

Rich Butkevic

Sí.

Ben Aston

Cuéntanos ese proceso de alto nivel: ¿cómo pasamos de “quiero un sitio corporativo” a “Listo, está hecho”?

Rich Butkevic

Claro.

Ben Aston

Hablabas de grandes bloques, sumarios de tu plan de proyecto. ¿Cómo se ve eso para ti? Sé que eres fan de Agile, tienes certificación Scrum. ¿Cómo afecta esto a un sitio web corporativo, donde a veces es mejor un enfoque más tradicional por los procesos de aprobación?

Rich Butkevic

A alto nivel, lo primero es identificar los objetivos reales del proyecto o el sitio web. Puede ser por fusión, rediseño, rebranding, implementación de un nuevo sistema de gestión de contenido, y según eso se definen muchas tareas. Luego paso a las historias de usuario, cosa que muchos proyectos web olvidan. Normalmente hay varios “avatares de usuario” o tipos de clientes que visitarán el sitio: compradores, quienes buscan información, clientes recurrentes... Cada grupo tiene metas distintas y formas diferentes de interactuar.

Entonces se redacta por qué cada uno visita el sitio y qué esperan hacer. Eso guía la arquitectura del sitio, buscando que todo sea lo más accesible posible y limitar los clics. Evita tener la información importante a 20 clics de distancia, porque nadie la encontrará o se frustrará —lo cual afecta negativamente incluso al SEO. Así que después de identificar usuarios, se diseña la estructura del sitio.

Luego, ya con la jerarquía clara, revisamos el contenido y su gestión. Si son menos de 50 páginas puedes manejarlo fácil, pero en un rediseño de un sitio empresarial con miles de páginas, hay que decidir qué contenido se mantiene, actualiza, fusiona o elimina. Aquí las herramientas ayudan mucho, porque no quieres tener miles de documentos de Word sueltos en una carpeta.

Ben Aston

Sí.

Rich Butkevic

Solo después de esto empiezo a preocuparme por lo técnico, porque suele ser estable. Hay diferencias por infraestructura, CMS y demás, pero puedes tener perfectamente resuelto lo técnico y aún así fracasar si no se cumplen los objetivos, la UX y el contenido adecuado. Lo técnico no importa si lo de más alto nivel falla.

Ben Aston

Perfecto. O sea que para ti lo principal es definir el brief, los objetivos del sitio, los perfiles clave y crear la arquitectura y el IA para que los usuarios puedan usarlo eficientemente, luego la fase de diseño y wireframes. ¿Haces eso en paralelo? Alguien podría pensar que suena largo: descubrimiento, planificación, diseño antes de construir. ¿Tienes trucos para paralelizar y agilizar sin perder calidad?

Rich Butkevic

Trato de no usar demasiados trucos, porque para mí la planificación marca la diferencia en la agilidad posterior. Si no tienes tiempo para hacerlo bien, menos lo tendrás para rehacerlo. Pero sí se puede trabajar en paralelo: mientras defines objetivos, si la empresa existe ya se conoce a los clientes y puedes trabajar en las historias de usuario y la estructura del sitio. Si rediseñas un sitio, parte de la estructura existente. Luego los equipos internos como ventas, RRHH, etc., pueden empezar a revisar y actualizar su contenido.

Todo puede avanzar simultáneamente. ¿Y Agile o Scrum? Ayuda mucho en la gestión de interesados. Conviene mostrar algo tangible a los tomadores de decisiones lo más pronto posible. Los líderes quizá no quieran involucrarse a diario, pero asistirán si muestran avances y pueden visualizar el sitio; y ahí aportarían feedback valioso y temprano, mejor así que detectar errores al final. A veces un enfoque tradicional es mejor, pero no suele ser mi caso.

Ben Aston

Una cosa muy útil es el testeo de usuarios. En sitios corporativos identificamos los perfiles al inicio: ¿Para quién lo hacemos? A veces el sitio sirve también para halagar el ego de alguien, y hay que codificar ese objetivo. Definir arquetipos ayuda a alinear expectativas y justificar el porqué del contenido y la estructura.

Luego hacemos test con esos perfiles: “Quieres un paquete de internet de 50€ al mes, encuéntralo”. Mostramos el sitio y decimos “Intenta encontrar tu paquete”. Y si solo ves al CEO celebrando 15 años pero no la opción que buscas, ya tienes argumentos para sugerir cambios al cliente. Así evitamos que las prioridades de los interesados desvíen el objetivo real.

Rich Butkevic

Totalmente. Lo importante es asegurarse que las personas que testeas sean verdaderamente representativas de tus clientes. Si vendes seguros de hogar, no pongas a adolescentes ni empleados internos a probar el sitio. Los empleados conocen mucho el negocio y la jerga, pero el público general puede perderse con términos técnicos; por ejemplo, “banda ancha” puede ser confuso para quien solo entiende “internet rápido”.

Ben Aston

Totalmente. Hemos hablado mucho del descubrimiento, diseño, etc. Ahora hablemos de la construcción. Sé que tienes mucha experiencia en la parte técnica. La verdad es que diseñar sitios es complicado y debe cumplir objetivos. Si queremos conversiones, el diseño debe ser correcto, pero que cumpla en diseño y en lo funcional puede ser complicado. ¿Cuáles son tus consejos para gestionar la construcción de un sitio web corporativo? ¿Qué debe tener en cuenta un PM al manejar un equipo de desarrollo?

Rich Butkevic

Creo que lo más importante, como dijimos, es que los desarrolladores casi nunca tienen mucha experiencia en migrar un sitio corporativo. Quizá sepan gestionarlo en producción, pero no en cambios mayores. Algunas cosas que suelo vigilar, porque suelen pasarse por alto, son:

Una es la redirección HTTPS. Todos los sitios corporativos deben ser seguros; debes asegurarte que toda petición llegue a la versión segura, porque si no Google verá dos sitios distintos y tendrás problemas de contenido duplicado y analítica separada.

Otra es la actualización de DNS al lanzar el sitio. DNS traduce el nombre del sitio a dirección IP, y muchas veces en go-live descubres que la persona encargada no tiene acceso al registro. Eso es información muy sensible y debe estar controlada. Verifica que la persona correcta tenga acceso anticipadamente, y también que los líderes del proyecto entiendan el concepto de propagación DNS, para evitar falsas alarmas post-lanzamiento de que la web “no funciona” cuando solo falta esperar unos minutos.

Ben Aston

Consejos esenciales para el go-live. Muchas veces solo pensás en actualizar DNS el día antes y resulta que nadie sabe el acceso, o la persona se va de vacaciones. Pensar en eso con antelación es clave.

Ahora, en cuanto a la gestión de desarrolladores: hay PMs poco técnicos que manejan bien la UX pero no a los desarrolladores. Si no entiendes de código, y el desarrollador te dice “sí, está listo” pero quizás no lo esté, ¿cómo gestionas ese trabajo cuando no puedes verlo directamente?

Rich Butkevic

Ahí es donde un enfoque iterativo es especialmente útil: así puedes ver presentaciones funcionales frecuentes, detectar problemas rápido y verificar avances. También me parece fundamental no dejar mucho espacio entre reuniones o actualizaciones. No solo por reunirse, pero al menos, si no son diarias, cada dos días haz una reunión rápida para mantener el ritmo, típico del Scrum, pero válido para cualquier marco. Cuanto más cortos sean los ciclos de feedback y supervisión, mejor.

Ben Aston

Muy cierto. El ritmo es importante: demos frecuentes, mostrar avances, hacer builds regulares para evaluar, detectar errores temprano y evitar sorpresas en la entrega final. Así se evita también la “niebla de desarrollo” en la que los developers trabajan solos semanas y luego el resultado no es el esperado.

Resumamos: para los que medio escuchan y piensan que es mucho, ¿cuál es la clave para que estos proyectos sean exitosos en su gestión y control, más allá de arrancarlos bien? ¿Un consejo que siempre te funcione?

Rich Butkevic

Creo que es la suma de todo lo anterior: buena colaboración, usar herramientas que la faciliten, standups diarios que ayuden a prevenir problemas, y acortar el ciclo de feedback lo más posible. Lo mejor del Agile es que ese loop se reduce a ciclos de dos semanas con demos, pero se puede acortar aún más con reuniones diarias cortas y comunicación abierta por Slack u otra herramienta; así no tienes que esperar a la siguiente reunión para señalar un problema.

También añadiría que antes del go-live hagas un “crawl” del sitio para buscar enlaces rotos. Es sorprendente lo poco que se hace y los problemas que resuelve. La semana antes de lanzar, como PM, revisa los enlaces rotos; así detectas muchos errores técnicos y organizativos fácilmente.

Ben Aston

¿Consejos de herramientas para crawling?

Rich Butkevic

No especialmente, todas funcionan parecido. Solo busca una “herramienta de revisión de enlaces” y elige la que se adapte a si necesitas ejecutarla dentro o fuera de la red interna. Lo importante es ¡hacerlo!

Ben Aston

Fantástico. Rich, muchísimas gracias por acompañarnos. La clave que destacamos hoy es la importancia de la fase inicial del proyecto: definir bien el brief, los objetivos y expectativas. Si tenemos esos objetivos claros todo el resto fluye, y aunque hoy no lo tratamos, tras el lanzamiento viene la evaluación: si durante el proyecto los objetivos se mantuvieron claros, los resultados llegarán y el ROI será real. Así que empezar bien es vital. Muchas gracias Rich.

Rich Butkevic

Gracias Ben, ha sido un placer estar contigo.

Ben Aston

Un placer tenerte aquí. Nos interesa saber vuestros trucos y experiencias: ¿cuáles son tus hacks para construir sitios? ¿Qué ha funcionado o no? Si tienes historias de fracasos o éxitos, cuéntanoslas en los comentarios. Si quieres aprender más y avanzar en tu carrera, únete a nuestra comunidad con la membresía DPM. Encontrarás muchos recursos útiles, planes de proyecto de grandes sites en distintas metodologías: sprints o un enfoque más en cascada.

Obtendrás acceso a nuestro equipo de Slack, plantillas, talleres, sesiones, eBooks y más. Si te gustó este episodio, suscríbete y deja un comentario honesto. Gracias por escucharnos. Hasta la próxima, cuídate.