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

Lee la transcripción:

Estamos probando transcribir nuestros pódcasts mediante un programa de software. Perdona cualquier error tipográfico, ya que el bot no acierta el 100 % de las veces.

Ben Aston

Gracias por escucharnos. Soy Ben Aston, fundador de The Digital Project Manager. Te doy la bienvenida al pódcast de DPM. Tanto si eres un gestor de proyectos experimentado como si eres productor digital o cualquier otra cosa —quizá simplemente te encontraste de alguna manera a cargo de gestionar proyectos—, debes saber que hoy, desde tus auriculares, te acompañan miles de personas que están en la misma situación, intentando hacer todo lo posible para iniciar, planificar y entregar mejores proyectos.

En thedigitalprojectmanager.com estamos aquí para ayudarte a adquirir más confianza y habilidades como gestor de proyectos, y también para conectarte con otras personas que gestionan y lideran proyectos. Si realmente quieres subir de nivel y llevar tus habilidades de gestión de proyectos al siguiente nivel, descubre nuestra Escuela DPM y asegúrate de registrarte en nuestra membresía profesional para acceder a todos nuestros recursos seleccionados.

Por último, mientras escuchas el programa, suscríbete y únete a nuestra lista de correo en thedigitalprojectmanager.com para mantenerte al día de todo lo que ocurre. Si alguna vez has construido un sitio web corporativo, sabrás perfectamente que es increíblemente difícil hacerlo bien. En parte, se debe a que no es algo que se haga muy a menudo, pero hay mucho más: objetivos poco claros, un encargo impreciso, una maraña de partes interesadas y grandes dosis de política interna.

Todo ello hace que terminar un sitio web corporativo —y mucho más hacerlo correctamente— sea increíblemente difícil. Si añadimos algunos desafíos técnicos, esos proyectos de sitios web nuevos y relucientes pueden convertirse en un desastre total. Por eso, en el pódcast de hoy vamos a explicar cómo construir correctamente sitios web corporativos. Sigue escuchando para descubrir cómo puedes planificar, gestionar y controlar tus próximos proyectos de sitios web corporativos y terminarlos correctamente.

Gracias por escucharnos. Soy Ben Aston, fundador de The Digital Project Manager, y te doy la bienvenida al pódcast de DPM. Tanto si eres un gestor de proyectos experimentado como si eres productor digital o cualquier otra cosa —quizá simplemente te encontraste de alguna manera a cargo de gestionar proyectos—, debes saber que hoy, desde tus auriculares, te acompañan miles de personas que están en la misma situación, intentando hacer todo lo posible para iniciar, planificar y entregar mejores proyectos. En thedigitalprojectmanager.com estamos aquí para ayudarte a adquirir más confianza y habilidades como gestor de proyectos, y también para conectarte con otras personas que gestionan y lideran proyectos.

Si realmente quieres subir de nivel y llevar tus habilidades de gestión de proyectos al siguiente nivel, descubre nuestra Escuela DPM y asegúrate de registrarte en nuestra membresía profesional para acceder a todos nuestros recursos seleccionados. Por último, mientras escuchas el programa, suscríbete y únete a nuestra lista de correo en thedigitalprojectmanager.com para mantenerte al día de todo lo que ocurre.

Este pódcast cuenta con el patrocinio de Clarizen, líder en software de gestión de proyectos y carteras empresariales. Visita clarizen.com para obtener más información. Hoy me acompaña Rich Butkevic-

Rich Butkevic

Perfecto.

Ben Aston

¿Lo he pronunciado bien?

Rich Butkevic

Lo has pronunciado perfectamente.

Ben Aston

Ahí está, he practicado. Rich es consultor de gestión de proyectos y autor del blog projectzendo.com. Visítalo, y además organiza talleres de gestión de proyectos por todo Texas. Consulta artofpmo.com si te interesa. Hablaremos de ello dentro de un momento. Rich posee una combinación única de cargos de liderazgo en gestión de proyectos y productos, control de calidad, análisis empresarial, marketing y formación. Utiliza Agile y Scrum, y tiene todas las letras y certificaciones que puedas imaginar: PMP, Certified Scrum Master, IBM Rational Unified Process y certificaciones de Amazon y de marketing electrónico. Lo tiene todo.

Hola, Rich, y gracias por acompañarnos hoy.

Rich Butkevic

Hola, Ben, gracias por invitarme. Te lo agradezco.

Ben Aston

Quiero empezar profundizando en todas esas cualificaciones y letras que tienes después de tu nombre. Algunas personas adoptan la postura de que no les importan realmente las certificaciones, pero tú has seguido claramente el camino contrario y has conseguido prácticamente todas las que existen. ¿Se debe a una pasión concreta por aprender? ¿Qué te llevó a certificarte en tantas cosas?

Rich Butkevic

No sé si en todas, pero sí tengo pasión por aprender. Es algo que realmente me gusta hacer. Creo que obtener una certificación en gestión de proyectos o, en realidad, en cualquier ámbito, demuestra la seriedad con la que te tomas la profesión y el esfuerzo por mantenerte al día. Así que, aparte del PMP, las demás certificaciones las fui adquiriendo más o menos según las necesidades de los proyectos.

Por ejemplo, con la certificación de AWS, si participaba en un proyecto que utilizaba Amazon Web Services, siempre me gustaba profundizar en la tecnología para poder desempeñar mejor mi trabajo como gestor de proyectos. Al hacerlo, descubrí que me gustaba y quería aprender más; y si iba a aprender más de todos modos, era agradable tener un objetivo que alcanzar. Así que convertí en mi objetivo obtener una certificación, y así es más o menos como las conseguí [inaudible 00:05:30].

Ben Aston

Muy bien. Cuéntanos cómo entraste en la gestión de proyectos. Está claro que tienes una orientación técnica. No creo que haya muchos gestores de proyectos que conozca con una certificación técnica como AWS-

Rich Butkevic

Claro.

Ben Aston

Pero ¿cómo empezaste y llegaste a la gestión de proyectos?

Rich Butkevic

Durante la universidad trabajé como técnico de soporte, así que respondía al teléfono justo cuando comenzaba a aparecer la banda ancha. Entré técnicamente desde el principio en una época bastante emocionante. Después, justo cuando terminé la universidad, me convertí en analista empresarial para una gran empresa de telecomunicaciones de Chicago, donde vivía entonces. A partir de ahí pasé al control de calidad, empecé a gestionarlo y después entré en la gestión de proyectos en esa empresa. Obtuve mi certificación y las cosas continuaron desde entonces.

Ben Aston

Muy bien. Me interesa saber qué aprendiste durante ese recorrido técnico, de soporte y control de calidad hasta llegar a la gestión de proyectos. El primer día como gestor de proyectos aprendiste muchas lecciones. Sabiendo ahora lo que sabes, ¿qué le dirías a tu yo más joven en su primer día en la gestión de proyectos?

Rich Butkevic

Creo que lo más importante sería entender que no se trata de la herramienta. Muchos gestores de proyectos se concentran demasiado en conocer todos los matices y detalles de la herramienta de gestión de proyectos que utilizan como ayuda. Pero, desde mi punto de vista, todo lo que haces con la herramienta es simplemente una forma de agilizar, automatizar y ayudar a gestionar un proceso que realmente deberías poder realizar con un lápiz y una hoja de papel.

Si no te sientes cómodo gestionando un proyecto con nada más que un bolígrafo y un cuaderno, no estoy diciendo que eso sea lo que debas hacer. Pero ser un buen gestor de proyectos no consiste en ser quien más sabe sobre Microsoft Project o cualquier otra herramienta o programa de gestión de proyectos. Es mucho más que eso: muchas más habilidades interpersonales y, sobre todo, comprender bien qué intentas lograr como gestor de proyectos, en lugar de ser un experto en el software.

Ben Aston

Sí, sin duda. Hablando de herramientas, porque me gustan las herramientas.

Rich Butkevic

Sí, a mí también.

Ben Aston

¿Cuáles son las herramientas de tu equipo de gestión de proyectos, aparte del bolígrafo y el bloc de notas que mencionaste?

Rich Butkevic

Creo que lo que más ha cambiado mi conjunto de herramientas, además de la herramienta de gestión de proyectos que utilicemos, sería algún tipo de herramienta de colaboración. Me encanta Slack. Me parece muy sencillo y fácil de usar para la gente, y creo que marca una enorme diferencia frente a intentar gestionar las cosas mediante una avalancha de correos electrónicos y documentos de Excel almacenados y dispersos por la empresa en unidades compartidas que nadie consigue encontrar.

Me gusta Slack, pero la herramienta concreta, al igual que ocurre con la herramienta de gestión de proyectos, es menos importante que el concepto y la idea que hay detrás de utilizarla.

Ben Aston

Sí. ¿Utilizas integraciones con Slack que te resulten especialmente útiles para facilitar la colaboración y aprovechar mejor esas habilidades interpersonales?

Rich Butkevic

Sí. No se me ocurre nada aparte de alguna integración de seguimiento que quizá utilice como consultor. Las empresas para las que trabajo suelen tener estándares que debemos respetar. Aunque el programa de gestión del tiempo que integres con Slack pueda cambiar, tenerlo integrado de alguna manera es positivo. Pero lo que realmente me ha resultado beneficioso en Slack es conocer los atajos de teclado; saber utilizarlos ha marcado una diferencia enorme.

Ben Aston

Dinos cuál es tu atajo favorito.

Rich Butkevic

Vaya. Ahora me pones en un aprieto. No lo sé. Parece que los conozco instintivamente, como si mis dedos los supieran-

Ben Aston

Seguro que sí.

Rich Butkevic

Pero mi cerebro no.

Ben Aston

No puedes citarlos, pero sí conoces los gestos con las manos.

Rich Butkevic

Sí, sí. Es como mi número de teléfono. A veces me cuesta decirle a la gente cuál es, pero no tengo problemas para marcarlo porque lo necesito.

Ben Aston

Sí, es gracioso. Volvamos a tu idea: no se trata de las herramientas, aunque ahora hemos empezado a hablar de ellas. Regresemos a tu punto: la buena gestión de proyectos no depende de las herramientas. Cuéntanos más sobre lo que has descubierto acerca del arte de gestionar proyectos y cómo utilizas esas habilidades interpersonales para entregar mejores proyectos.

Rich Butkevic

Cuando hablo de habilidades interpersonales, por supuesto que la comunicación y aspectos similares son importantes. Pero, además de esas habilidades, quizá sería mejor decir que hay que comprender a nivel conceptual qué debe hacer un gestor de proyectos y cómo debería desarrollarse idealmente un proyecto, para poder concentrarse en lo esencial y no en tareas que solo hacen perder el tiempo.

Durante el desarrollo de un proyecto hay varios grandes grupos de aspectos en los que deberías concentrarte. Después hay tareas que debes o puedes realizar dentro de ellos. Primero necesitas identificar cuáles son tus requisitos y asegurarte de que tanto la empresa como el equipo técnico, si se trata de un proyecto de TI o de un sitio web, tienen un entendimiento común de esos requisitos, de lo que son y de lo que necesitan. También debes garantizar que se realicen las pruebas y que los defectos se gestionen de alguna manera. Se trata de comprender las actividades de nivel superior que normalmente aparecerían como tareas de resumen en un plan de proyecto, así como el objetivo general y la razón por la que haces cada cosa.

Suelo decir que, si no puedes escribir un tuit explicando por qué rellenas un documento o por qué haces lo que estás haciendo, probablemente deberías detenerte y aclarar la razón. A menudo, si no sabes por qué haces algo, no puedes hacerlo bien y quizá ni siquiera deberías hacerlo.

Ben Aston

Sí, totalmente. Profundicemos en el tema de la gestión de proyectos de construcción de sitios web corporativos. Acabamos de publicar un artículo sobre cómo salen mal estos proyectos, una guía rápida para gestores de proyectos. Consúltalo si aún no lo has leído en thedigitalprojectmanager.com. La realidad es que es difícil. Los proyectos de sitios web corporativos son realmente complejos. Por eso las empresas contratan agencias y consultores: necesitan ayuda externa para realizar una actualización importante, migrar a la nube, implementar un nuevo CMS o integrar herramientas de marketing digital. Sin embargo, por la naturaleza de estos proyectos, normalmente no se realizan con frecuencia. Una gran construcción de un sitio web quizá se haga cada tres o cinco años, lo que significa que las personas implicadas no suelen tener mucha experiencia y quizá solo gestionen algo así una o dos veces en toda su carrera.

Es un desafío y, como mencioné al principio, hay muchas partes interesadas, encargos poco claros, política interna y desafíos técnicos. Si todavía no has leído el artículo de Rich, hazlo. Quiero hablar de este proceso: cómo podemos simplificarlo y aprovechar lo que Rich decía sobre conocer los aspectos que deben ocurrir para que el proyecto tenga éxito. Pero empecemos por entender por qué resulta tan difícil. Quizá puedas compartir un ejemplo o una historia de terror sobre algo que te haya salido mal en el pasado, y yo haré lo mismo.

Rich Butkevic

Creo que una de las grandes lecciones que aprendí al principio de mi carrera fue confiar, pero verificar. Muchas veces los recursos del proyecto decían que habían completado una tarea, cuando en realidad querían decir que planeaban completarla o que estaba en su lista de pendientes. Después aparecían otras cosas, se olvidaba o se escondía bajo la alfombra, y algunos de esos elementos no resultaban evidentes hasta que, por desgracia, se llegaba a producción.

Esa fue probablemente una de las mayores lecciones que aprendí al principio. Además, como mencioné antes sobre Slack, colaborar bien con equipos grandes, especialmente en proyectos importantes o con recursos distribuidos geográficamente, ha sido fundamental para mí. Cuanto mayor es un proyecto, menos puedes depender de que una o dos personas hagan esfuerzos heroicos para resolverlo todo al final.

En un proyecto de sitio web corporativo, un consultor como yo puede acudir a varias empresas al año y trabajar en proyectos de este tipo. Probablemente he trabajado en un par de docenas. Pero un administrador de sistemas o de redes de una empresa que lleva allí 15 años quizá solo haya hecho algo parecido una vez, como mucho dos, durante la década o década y media que lleva en la organización. Aunque para algunas personas parezca rutinario, para muchos recursos corporativos no lo es en absoluto.

Ben Aston

Sí. Compartiré una historia sobre algo que salió mal. Hace unos años trabajaba en un proyecto de sitio web corporativo y el desafío se reducía a la falta de alineación en el encargo. Esto está muy relacionado con la gestión de las partes interesadas. La persona encargada internamente de gestionar el proyecto no había recopilado necesariamente todas las aportaciones que debía obtener de su equipo.

Había redactado un encargo, pero no lo había aprobado o, si lo había aprobado, no se había revisado adecuadamente. Seguimos adelante, diseñamos el sitio web y lo construimos. Justo antes de publicarlo descubrimos que, dentro del proceso y de la estructura de gobernanza del proyecto, existía una capa adicional de aprobación que no conocíamos. Entonces nos dijeron que el fundador y presidente debía aprobarlo antes de la publicación. Resultó que esa persona era el verdadero jefe y tenía ideas muy claras sobre lo que quería y lo que no quería, ideas fundamentales para todo el proyecto.

Rich Butkevic

Así es.

Ben Aston

Tuvimos que mantener una conversación complicada y explicar que aquello no estaba en el encargo, que todo se había aprobado durante el proyecto y que ahora el fundador y presidente no estaba satisfecho. Tuvimos que emitir una solicitud de cambio enorme, lo que molestó a la empresa y deterioró la relación. En parte también fuimos responsables, porque no insistimos lo suficiente desde el principio en conocer la estructura de gobernanza. Deberíamos haber ralentizado el proyecto y haber conseguido la aprobación en toda la cadena hasta llegar a la máxima autoridad.

La gran lección para mí fue descubrir exactamente qué debía ocurrir antes de publicar el sitio y comprender todos esos pasos.

Rich Butkevic

Eso puede ser muy difícil, especialmente en una empresa grande, donde quizá haya una docena de partes interesadas identificadas en el proyecto, pero todas tienen un jefe, y esos jefes suelen tener a su vez otro jefe. Cuando un jefe suficientemente importante ve un cambio en el sitio web que no le gusta, puede anular decisiones anteriores. Eso puede complicar bastante las cosas.

Ben Aston

Una de las lecciones para mí fue explicar las consecuencias. Ahora digo: “De acuerdo, tracemos el mapa de las partes interesadas y hagamos una matriz RACI según los distintos hitos del proyecto. Pero seamos claros: si esta persona es quien aprobará el trabajo, y después descubrimos que debemos volver atrás para obtener una aprobación superior, habrá un impacto en los costes y en el calendario. Digámoslo ahora o tendremos consecuencias después”.

Así que hay que ser muy claro. A menudo el equipo de marketing es responsable, asigna la tarea a una persona junior y esa persona piensa que solo tiene que incluir a su jefe.

Rich Butkevic

Claro, así es.

Ben Aston

Probablemente deberíamos incluir a algunas personas más.

Rich Butkevic

Sí.

Ben Aston

Explícanos el proceso general. ¿Cómo pasamos de que un cliente corporativo diga “Necesito un sitio web corporativo nuevo” a “Ya está terminado”?

Rich Butkevic

A alto nivel, lo primero que quiero asegurarme de hacer es identificar cuáles son realmente los objetivos del proyecto o del sitio web. A veces hay una fusión o adquisición y se integran dos sitios; otras veces se trata de un rediseño o cambio de marca, o de implementar un nuevo sistema de gestión de contenidos. Según los objetivos, se definirán muchas de las tareas posteriores. Una vez identificados, me gusta pasar a las historias de usuario, algo que muchos proyectos de diseño o sitios web pasan por alto.

La mayoría de las empresas no atienden a todo el mundo. Normalmente pueden identificar varios perfiles de clientes. Son diferentes tipos de personas que visitarán el sitio: algunas realizarán una compra, otras buscarán información y otras serán clientes existentes que quieran volver a pedir. Cada tipo de usuario tendrá objetivos distintos, buscará información diferente, tendrá un nivel de conocimiento diferente y seguirá recorridos distintos por el sitio. Por eso es fundamental identificar esos perfiles.

Redactar por qué visitan el sitio y qué esperan hacer ayuda a impulsar la siguiente parte del proyecto: diseñar la jerarquía y la estructura del sitio. Hay que limitar el número de clics necesarios para llegar a un lugar; no conviene enterrar la información a 20 páginas de profundidad porque nadie la encontrará o los usuarios se frustrarán. Esa estructura también es importante por razones de optimización para motores de búsqueda. A continuación, utilizamos las historias de usuario para definir la estructura del sitio.

Después analizamos el contenido y cómo se gestionará. En un sitio pequeño, de menos de 50 páginas, no suele ser un problema importante. Pero en un rediseño o cambio de CMS de un sitio corporativo empresarial puede haber miles de páginas. Hay que determinar qué contenido se conserva, cuál se actualiza, elimina o combina. Es una tarea significativa y aquí las herramientas pueden ayudar mucho.

Solo después de eso empiezo a preocuparme por los aspectos técnicos, porque son relativamente estáticos. Puedes hacer todo lo técnico perfectamente, pero si no se han pensado los objetivos, no se atienden las necesidades de los clientes, el sitio no está organizado de forma intuitiva o no contiene el contenido adecuado, los aspectos técnicos no importan.

Ben Aston

Así que lo importante es definir desde el principio el encargo y los objetivos, identificar las personas o perfiles principales y crear la arquitectura del sitio y la arquitectura de la información para que los usuarios puedan utilizarlo eficazmente. Después viene la fase de diseño, en la que creamos las estructuras alámbricas y los componentes de diseño. ¿Sueles hacerlo como un flujo de trabajo paralelo? Para quienes piensan que la fase de descubrimiento, planificación y diseño puede llevar mucho tiempo antes de construir, ¿qué consejos tienes para trabajar en paralelo, acelerar las cosas y hacerlas bien?

Rich Butkevic

Intento no utilizar demasiados trucos porque, en mi opinión, la planificación influye enormemente en la rapidez con la que avanzará el proyecto después. Si no tienes tiempo para hacerlo bien, tampoco tendrás tiempo para repetirlo. Dicho esto, muchas actividades pueden hacerse en paralelo y, en cierta medida, deberían hacerse así.

Mientras se trabajan los objetivos generales del sitio, en una empresa existente normalmente ya se sabe quiénes son los clientes y qué tipos de personas lo visitarán. Se pueden empezar a redactar las historias de usuario y tomar notas sobre la estructura. Si se rediseña un sitio existente, tiene sentido usar su estructura actual como punto de partida y ver cómo puede mejorar. Un equipo de contenidos puede revisar el material de ventas, recursos humanos y otros departamentos para decidir qué combinar, eliminar o actualizar.

Todo puede avanzar de forma coordinada. En cuanto a Agile, Scrum y los enfoques iterativos, ayudan especialmente con la gestión de las partes interesadas. Conviene ofrecer cuanto antes algo que estas personas y quien toma las decisiones puedan ver con sus propios ojos. Los líderes de la organización quizá no quieran participar en el día a día, y probablemente sea adecuado que no lo hagan. Pero asistirán a una sesión en la que puedan ver el progreso y el sitio en una pantalla. Ahí obtendrás comentarios valiosos. Cuanto antes los recibas, mejor, porque no quieres tomar una decisión de diseño que se extienda por todo el sitio y descubrir al final que no era lo que quería una persona de nivel ejecutivo. A veces conviene un enfoque más estructurado por etapas, pero en mi experiencia normalmente no.

Ben Aston

Las pruebas con usuarios también pueden ayudar mucho. En una construcción de un sitio web corporativo identificamos desde el inicio las personas para las que estamos construyendo. En estos proyectos puede mezclarse el objetivo real del sitio con la necesidad de satisfacer el ego de alguien. Ese puede ser un objetivo implícito, pero debe formalizarse de alguna manera.

La creación de perfiles al inicio permite alinearnos con el cliente sobre la razón y el objetivo del proyecto. Alguien puede decir que lo más importante de la página de inicio es contar que el director general acaba de hacer algo excelente. Pero si la empresa es de banda ancha, quizá el usuario necesite configurar un paquete, no leer sobre el director general.

Los objetivos explícitos e implícitos existen, y las personas nos ayudan a orientar las decisiones sobre la ubicación de los elementos. Después podemos probar lo creado con usuarios reales y asignarles tareas concretas. Si no encuentran cómo configurar su paquete porque la página está dominada por información sobre el director general, tendremos pruebas para volver al equipo corporativo y cambiar el diseño.

Rich Butkevic

Ese tipo de cosas ocurre constantemente. En las pruebas de usuario es muy importante que las personas seleccionadas representen realmente a los perfiles de clientes identificados. Si vendes seguros para propietarios de viviendas, no debes probar con personas que no tienen vivienda o con adolescentes. Los participantes deben ser una muestra adecuada de quienes utilizarán el sitio.

Muchas empresas utilizan a sus propios empleados para las pruebas, lo que suele ser una mala idea. Los empleados conocen mejor el funcionamiento de la empresa, sus objetivos y la jerga del sector. No quieres concluir que todo está perfecto y que el sitio es fácil de usar para descubrir, después de publicarlo, que el público general no entiende términos técnicos como “banda ancha”. Es posible que no pulse ese enlace y termine acudiendo a un competidor que utiliza una expresión más clara, como “internet de alta velocidad”.

Ben Aston

Hemos hablado mucho de descubrimiento, planificación y diseño. Ahora hablemos de la construcción. Diseñar sitios y lograr que cumplan los objetivos definidos al principio es complicado. El diseño es fundamental para aumentar las conversiones y alcanzar los indicadores clave de rendimiento, pero existe una diferencia entre que el diseño sea correcto y que el sitio funcione técnicamente como debe.

¿Cuáles son tus principales consejos para gestionar la construcción de un sitio web corporativo? ¿Qué debería tener en cuenta un gestor de proyectos que realiza este trabajo por primera vez al gestionar un equipo de desarrolladores?

Rich Butkevic

Lo principal es recordar que los desarrolladores del proyecto quizá no tengan mucha experiencia en esta área concreta, especialmente en migraciones. Probablemente sepan gestionar un sitio cuando ya está funcionando, pero no necesariamente todos los detalles técnicos del proceso. Hay varias cosas que vigilo porque suelen pasarse por alto.

Una es la redirección HTTPS. Casi todos los sitios, especialmente los corporativos, deben ser seguros para cifrar el tráfico. Hay que asegurarse de que si un cliente escribe HTTP, omite HTTPS o llega mediante un enlace, la solicitud se dirija a la versión segura de la página. También hay que comprobar que la URL se reescriba correctamente. De lo contrario, los motores de búsqueda pueden considerar que existen dos versiones del sitio, una HTTP y otra HTTPS, lo que puede causar problemas de contenido duplicado. Además, los análisis pueden registrar ambas versiones por separado, dificultando relacionar las conversiones.

Otro aspecto aparece al publicar el sitio, cuando hay que actualizar el DNS. El DNS es el sistema que traduce un nombre como Google en una dirección IP para que pueda localizarse en internet. A veces la persona responsable de actualizarlo no tiene acceso al registrador. Es información muy restringida, pero hay que asegurarse de que quienes necesitan realizar el trabajo tengan los permisos adecuados. También hay que explicar al equipo, especialmente a los líderes, que después de un cambio de DNS habrá un periodo de propagación mientras los cambios se reflejan en servidores de todo internet. Así se evita anunciar que todo está actualizado y recibir mensajes de que el sitio está roto cuando, en realidad, funcionará en unos minutos.

Ben Aston

Esos consejos para el lanzamiento son importantes y deben planificarse mucho antes del día de publicación. A menudo estamos inmersos en el desarrollo y sabemos que faltan dos semanas para salir en vivo, pero esperamos hasta el día anterior para comprobar si podemos actualizar el DNS. Entonces descubrimos que nadie conoce las credenciales o que la persona que las tiene se ha ido de vacaciones.

Volvamos al proceso de desarrollo y a la gestión de desarrolladores. Un gestor de proyectos no técnico puede tener mucha experiencia gestionando el proceso de diseño de experiencia de usuario, pero sentirse menos seguro al gestionar desarrolladores. ¿Cómo los gestionas cuando no puedes ver realmente lo que están haciendo?

Rich Butkevic

Ahí es donde un enfoque iterativo resulta especialmente útil, porque permite ver algo funcionando o no funcionando en una demostración. Esa sería probablemente mi primera recomendación: ayuda a detectar problemas y permite comprobar rápidamente si el trabajo avanza como debería.

También es importante no dejar grandes intervalos entre reuniones y actualizaciones. No quiero organizar reuniones solo por reunirme, pero hacer una breve reunión diaria o cada dos días ayuda mucho a mantener el rumbo. Es algo habitual en Scrum, aunque no es exclusivo de ese marco. Cuanto más se mantengan los asuntos presentes, se revisen con frecuencia y se resuelvan los problemas, más probabilidades habrá de que el trabajo siga el rumbo correcto.

Ben Aston

El impulso es importante. Hay que mantener las demostraciones y construir algo que pueda evaluarse. Al final de la semana podemos mostrar una construcción funcional. El desarrollador quizá diga que solo ha creado la barra de navegación; está bien, veámosla funcionando. Tal vez funcione en su ordenador, pero no en un teléfono. Detectar esos problemas pronto es fundamental. También ayudan las demostraciones periódicas del sprint y las reuniones diarias para preguntar qué se hizo ayer, cuál es el plan de hoy y qué obstáculos podemos ayudar a resolver.

Para quienes escuchan esto mientras conducen y piensan que hay mucho que recordar —descubrimiento, planificación, diseño, desarrollo y publicación—, ¿cuál sería una conclusión sencilla? Si estás a punto de gestionar una construcción de un sitio web corporativo o ya estás en medio de una, ¿qué deberíamos recordar para que el proyecto tenga éxito y podamos controlar el presupuesto y el calendario?

Rich Butkevic

Es una combinación de todo lo que hemos hablado: buena colaboración y una herramienta que la facilite, si es posible. Las reuniones diarias son importantes y ayudan a anticipar muchos problemas. Cuanto más rápido sea el ciclo de retroalimentación, mejor.

La ventaja de Agile es que ese ciclo se divide en bloques de, por ejemplo, dos semanas en los que se demuestra algo real. Después puede dividirse aún más mediante reuniones diarias en las que no se muestran elementos terminados, pero se reciben actualizaciones y comentarios. Con Slack u otra herramienta de colaboración se pueden abordar los problemas de inmediato, sin esperar al día siguiente o a la siguiente iteración.

Otra cosa importante antes de publicar es rastrear el sitio para encontrar enlaces rotos. Es una forma sencilla de descubrir problemas que muchas personas no detectan. Como gestor de proyectos, la semana anterior al lanzamiento ejecuto un rastreo del sitio para comprobar si hay enlaces rotos. Esto puede revelar problemas de codificación, de organización o técnicos.

Ben Aston

¿Tienes algún consejo sobre qué utilizar para rastrearlo?

Rich Butkevic

No especialmente; todos funcionan más o menos igual. Buscaría en internet una herramienta de comprobación de enlaces. Depende de si estás construyendo un sitio completamente nuevo o rediseñándolo, y de si necesitas una herramienta que funcione dentro o fuera de la red. Hay algunos matices, pero lo importante es asegurarte de hacerlo porque aporta mucho valor.

Ben Aston

Muchas gracias por acompañarnos, Rich. Lo más valioso de lo que hemos hablado es la importancia de la primera parte del proyecto: definir correctamente el encargo, los objetivos y las metas desde el principio, porque todo lo demás surge de ahí. También existe una fase posterior al lanzamiento en la que evaluamos el rendimiento. Si hemos mantenido la atención en los objetivos durante todo el proyecto, será mucho más fácil comprobar que ofrece resultados, retorno de la inversión y valor. Empezarlo bien es realmente importante.

Rich Butkevic

Gracias, Ben. Ha sido estupendo estar contigo.

Ben Aston

Ha sido genial contar contigo. ¿Qué trucos, consejos y técnicas utilizas para construir sitios? ¿Qué te ha funcionado y qué no? Si tienes historias de fracasos o éxitos, cuéntanoslas en los comentarios. Si quieres aprender más y avanzar en tu trabajo, únete a nuestra comunidad mediante la membresía de DPM. Encontrarás todo tipo de recursos, incluidos planes de proyecto para grandes construcciones de sitios que utilizan diferentes metodologías, sprints o un enfoque más secuencial. Visítanos en thedigitalprojectmanager.com/membership.

Tendrás acceso a nuestro equipo de Slack, plantillas, talleres, horas de consulta, libros electrónicos y mucho más. Si te ha gustado lo que has escuchado hoy, suscríbete. Dedica un par de minutos a dejarnos una reseña sincera y gracias por escucharnos. Hasta la próxima, cuídate.