Planificación de proyectos WordPress enterprise que termina en un backlog que aprobaste

Se puede, y el modo de falla es siempre el mismo. El objetivo real del sitio se lee mal. El equipo técnico trabaja sin saber qué prioridades de negocio importan. Las decisiones de arquitectura y de diseño se toman sin nada abajo que las sostenga.

Lo que llega en cambio es una seguidilla de cambios de alcance no planificados ni presupuestados. La versión más común arranca con el supuesto silencioso de que el sitio nuevo es el viejo con mejor pintura, que es exactamente el supuesto que el descubrimiento existe para poner a prueba.

Reservá una a dos semanas en el calendario de tu equipo. El descubrimiento no funciona como tarea de fondo, porque cada una de sus partes depende de que tu gente esté accesible.

Necesitamos tres cosas:

• Acceso a tus referentes de contenido, marketing y tecnología.
• Acceso al sitio actual, o a la documentación de requerimientos que exista.
• Un kickoff planteado alrededor de objetivos claros y no como una presentación general.

La calidad del kickoff le pone un techo a la calidad de todo lo que viene después.

Cuatro cosas:

• Un mapa de tu contenido tal como existe hoy y tal como proponemos que sea.
• Un inventario de funcionalidades.
• Recomendaciones técnicas.
• Los riesgos que detectamos.

Trabajamos los sitemaps en Octopus.do, los flujos de usuario y de contenido en Miro, y entregamos el material escrito en Notion o Google Docs. Después el documento pasa a una revisión conjunta donde se define y se aprueba el backlog mínimo viable, y esa aprobación es la que habilita la etapa siguiente.

Podríamos, y sería más rápido. También corre el riesgo de llegar incompleto, o filtrado por la mirada de una sola persona sobre un proyecto que involucra a cinco áreas.

Hay cuatro formas de reunir esta información y cada una tiene un costo:

• Los workshops y las entrevistas dan la mayor profundidad y son las que más tiempo te consumen.
• Un formulario es rápido, pero queda incompleto o subjetivo.
• Una auditoría de tu sitio actual parte de algo real, y puede reforzar en silencio prácticas que no deberían sobrevivir a la reconstrucción.
• El acceso a tus datos internos, Analytics o Hotjar, es el insumo más objetivo disponible, y solo sirve si ya lo tenés funcionando.

Las combinamos en lugar de elegir una, y las ponderamos según lo que tu organización pueda darnos de verdad.

El sitio en sí, su analítica, las herramientas conectadas y la arquitectura de contenido que está debajo. Después mapeamos los tipos de contenido que manejás: blog, reportes, webinars, casos, productos, equipos, junto con los tipos de usuario, sus niveles de acceso y cómo se mueve cada uno por la plataforma.

Ese mapeo es el insumo de dos líneas de trabajo posteriores: arquitectura de contenido, donde se implementan los tipos de contenido, los campos y las taxonomías, y migración de contenido, donde la biblioteca que sobrevive se mueve a esa estructura sin perder relaciones ni autoridad de SEO.