Refactorización y deuda técnica
Las bases de código tienden a acumular basura con el tiempo. Esto viene en forma de código desorganizado, arreglos "temporales" que se han vuelto permanentes cuando nadie estaba prestando atención, cosas que funcionan pero que podrían usar ajustes de rendimiento y módulos incluidos en la base de código que ya no se usan.
Los ciclos de actualización anteriores permitían que los líos se amontonaran en un armario en algún lugar. Cuando se produjo la migración o el cambio de plataforma, todo lo que había en ese armario podía sacarse con seguridad y prenderle fuego. Fácil limpieza.
Con un modelo alternativo, no puede permitirse seguir empujando las cosas . Con el tiempo, ese armario tendrá que ser tan grande que ocupará toda la casa.
Comience a hacer un inventario de las cosas que deben limpiarse y comience a agregarlas como tareas para su equipo. Quizás su objetivo sea completar dos tickets de deuda técnica por mes. Tal vez empiece a oler asqueroso y necesite un sprint completo dedicado a un refactor. Quizás una nueva característica sea más fácil de implementar si se reorganiza algún otro código, por lo que agregue esa tarea como un requisito previo.
Sin importar cómo lo hagas, hazlo con intención y planificación. Ese armario no se va a limpiar solo.
Con un modelo iterativo, no puede permitirse seguir empujando las cosas.
Asignar recursos de desarrollo
Ha planificado el ciclo de lanzamiento. Tiene una lista de solicitudes de nuevas funciones que crece constantemente gracias a su mayor comunicación con las partes interesadas. Y ha identificado buenos objetivos para la refactorización.
¿Ahora que?
Priorizar y asignar. Esto, por supuesto, depende del tamaño de su equipo y del número de partes interesadas involucradas en el trabajo. Sus gerentes de proyecto tienen mucho trabajo por delante porque también tienen que preocuparse por asignar adecuadamente dentro de las mareas cambiantes de prioridades
Puede darle a cada parte interesada un equipo con el que trabajen exclusivamente. Esto ayuda a las personas a sentirse cómodas trabajando juntas y crea una buena relación. Es menos probable que necesite arranques de proyectos cada vez que comienza algo.
También puede rotar desarrolladores y equipos para que todos tengan experiencia en hacer un poco de todo. De esa manera, existe cierta superposición en caso de emergencias o rotación. También mantiene las cosas frescas y puede ayudar a prevenir el agotamiento. Deje que los desarrolladores hablen y le digan lo que están pensando y, si es posible, satisfaga sus preferencias.
Puede ser útil tener a la misma persona a cargo del programa de publicación día tras día, mes tras mes. Pero, ¿alguien realmente quiere ese trabajo en el día a día? Quizás lo hagan. Pero debes estar seguro.
Para equipos más pequeños, es posible que deba dividir las cosas por mes o trimestre. Quizás noviembre y diciembre sean los meses en los que todo el mundo se centra en la deuda técnica. Quizás el primer trimestre del año esté reservado para nuevas iniciativas de diseño y despliegues de funciones de mayor prioridad.
Pero no permita que las actualizaciones de seguridad y software se pierdan en la confusión. No se pierda en las malas hierbas de la entusiasta refactorización. No ignore las necesidades de sus partes interesadas. Esto puede parecer un acto de malabarismo, pero su organización debe dominarlo para mantener su sitio web seguro, relevante y exitoso.
Celebrar
No hay más "gran revelación" y lanzamiento de un nuevo sitio web . Es de esperar que los altibajos, las victorias y el estrés se aplanen a picos y valles más manejables. Sin embargo, eso no significa que no pueda celebrar la finalización de iniciativas más pequeñas. Absolutamente deberías. Anunciarlos, trátalos como grandes hitos, haz que te duela la mano de tantos choques y palmaditas en la espalda.
Esto puede hacerse de muchas maneras.
- Reconocimiento público en reuniones y boletines internos.
- Demos y jornadas de aprendizaje donde los responsables del trabajo muestran lo que han hecho y aprendido.
- Pequeñas fiestas que ocurren inmediatamente después del almuerzo.
Lo que sea que se ajuste a tu cultura, hazlo.
Dado que cada iniciativa y función se sostiene más por sí misma, no se ahoga en la emoción de una “gran revelación” en la que el brillo de tantas funciones nuevas puede cegar a las personas para que no vean determinadas partes del trabajo que se ha realizado.
Los lanzamientos iterativos permiten un mayor enfoque. Y dan más oportunidades para felicitar. Aprovecha de ellos.
Revisando la arquitectura y el contenido del sitio
Históricamente, muchas organizaciones han utilizado las principales migraciones de versiones de Drupal como una cadencia para revisar la arquitectura de la información. En parte, esto se debe a que las migraciones de contenido en las versiones principales no siempre han sido migraciones 1: 1, por lo que las organizaciones han tenido que realizar un trabajo de arquitectura de información (IA) para decidir qué migrar y adónde debe ir.
El otro aspecto de esto es que en migraciones más complejas , podría haber sido más rápido eliminar el contenido antiguo y los tipos de contenido obsoletos que dedicar tiempo a migrarlos, especialmente en el caso de una migración personalizada.
La ventaja de migrar de Drupal 8 a Drupal 9 y más allá es que no hay migración de contenido. La desventaja es que las organizaciones ahora necesitan otro ritmo para emprender proyectos de arquitectura y estrategia de la información . Esto es similar a crear un nuevo patrón de trabajo de desarrollo web, y muchos de los consejos para el desarrollo también se aplican aquí.
De hecho, la arquitectura y la estrategia deberían impulsar la mayoría de los nuevos trabajos de desarrollo . Adquiera el hábito de realizar auditorías periódicas de IA y de contenido . Cada año o cada seis meses. Todo lo que tenga sentido para su organización. Es parte de tener una casa bien cuidada.
Algunas preguntas de ejemplo que podría comenzar a hacer:
- ¿El contenido histórico sigue satisfaciendo sus necesidades? ¿Se puede actualizar, mover a otro tipo de contenido o archivar?
- ¿El sitio contiene campos de un solo uso que deberían quedar obsoletos?
- ¿Es necesario recortar los tipos de contenido?
- ¿Han cambiado las necesidades de navegación del sitio?
- ¿Nuestra estructura de taxonomía sigue satisfaciendo nuestras necesidades y objetivos?
- ¿Hemos agregado nuevos departamentos o consolidado los más antiguos? ¿Están representados correctamente?
- ¿Ha cambiado nuestra audiencia? ¿Hemos comenzado a apuntarnos a nuevas audiencias?
- ¿Cómo ha cambiado nuestro negocio? ¿Los nuevos competidores nos han obligado a pensar en diferentes enfoques y objetivos?
A veces, su AI puede requerir un cambio importante, y ese cambio debe ocurrir en un sitio web que debe permanecer en funcionamiento. Por ejemplo, consolidar dos tipos de contenido en un nuevo tipo de contenido .
La buena noticia es que las herramientas de migración sólidas y bien probadas que lo habrían ayudado durante una actualización completa están ahí para ayudarlo a lograr un cambio más pequeño. Las herramientas de migración de Drupal son excelentes para importar contenido y verter ese contenido en diferentes estructuras. Aprovéchala, incluso si al principio puede parecer una exageración.
La arquitectura y la estrategia deberían impulsar la mayoría de los nuevos trabajos de desarrollo.
Traer ayuda externa
Las grandes actualizaciones y los esfuerzos de migración exigieron experiencia y más horas de desarrollador, pero sin esta demanda tradicional, ¿todavía hay espacio para contratar ayuda externa?
Sí hay. Puede tener mucho sentido, dependiendo de su situación. En muchas circunstancias, establecer una relación a más largo plazo con un proveedor puede generar aún más ganancias, ya que el equipo externo no está solo durante seis meses a un año, y luego pasa a lo siguiente. La confianza tiene tiempo para crecer. La comunicación se instala en ritmos familiares. Todos los involucrados se sienten más cómodos entre sí.
Hay muchas formas en que se puede utilizar la experiencia externa más allá de la crisis de un gran proyecto. Tenga en cuenta que las líneas entre las siguientes categorías son confusas, pero son buenos lugares para comenzar cuando se trata de determinar si desea contratar a un proveedor externo.
Soporte y mantenimiento
Si desea que su propio equipo se concentre en nuevas funciones o trabajos que considere de mayor valor, el uso de ayuda externa para el soporte y el mantenimiento de su infraestructura existente puede proporcionar un nivel de coherencia que le permita avanzar.
Ponga un equipo especializado a cargo de administrar su ciclo de lanzamiento. Ellos administran las actualizaciones de software y trabajan dentro de su horario.
Un equipo de soporte capacitado también puede ayudar a administrar las correcciones de errores. Esto libera el tiempo de sus desarrolladores, por lo que no están rebotando entre tareas, perdiendo un poco de productividad cada vez. Ayúdalos a evitar el latigazo de concentración.
¿Cómo sabe que podría necesitar ayuda con el apoyo?
- Asignar la responsabilidad del ciclo de lanzamiento es como un juego de patatas calientes. Ningún desarrollador lo quiere realmente.
- La acumulación de errores "urgentes" crece mes tras mes en lugar de reducirse. Las quejas de las partes interesadas comienzan a crecer.
- Su software está continuamente desactualizado durante meses y requiere la atención de todos para rectificar la situación.
Llenar las lagunas de experiencia
Incluso si tiene un equipo de desarrollo grande y diverso, probablemente tenga algunas lagunas de experiencia. La tecnología es complicada. Es difícil para un equipo mantenerse actualizado con todo lo que está sucediendo todo el tiempo, y puede ser útil contar con algunos especialistas.
Auditorías de seguridad. Auditorías de accesibilidad. Auditorías de desempeño. Estas son buenas oportunidades para que alguien entre, te dé algunos artículos prácticos y se adentre en la puesta de sol. Cada ronda de estos también ayuda a educar a su personal. Dependiendo de la escala de su sitio web, podría tener sentido aumentar su equipo con este tipo de experiencia para un compromiso a largo plazo en lugar de auditorías periódicas.
DevOps y la integración continua también es algo que puede beneficiarse de un recurso dedicado. Un buen experto en esta área puede ayudar a que todo su equipo sea más productivo. Pueden configurar y mantener la implementación y las pruebas automáticas de código, administrar las configuraciones de desarrollo local y ayudar a hacer cumplir las mejores prácticas.
La estrategia y el diseño de contenido son áreas que pueden beneficiarse de perspectivas externas. El buen talento en estas áreas puede ayudar a que sus proyectos internos sean más exitosos al obligarlo a aclarar las prioridades.
Incrementar la velocidad de desarrollo
A veces, simplemente no tiene los recursos necesarios para alcanzar sus objetivos. Demasiadas iniciativas con demasiada gente exigiendo su libra de carne. Todas estas solicitudes y requisitos podrían canalizarse a través del departamento de marketing, o tal vez su empresa tenga varios departamentos, cada uno de los cuales posee una sección del sitio web.
De cualquier manera, necesita más ayuda, y necesita esa ayuda para comenzar a funcionar. Un equipo de expertos puede integrarse de varias formas.
- Pueden aumentar el equipo actual sin cambios en la estructura. Con este modelo, se convierten en miembros adicionales del equipo para su uso, ya sean gerentes de proyectos, estrategas de contenido, diseñadores o desarrolladores. El objetivo es aumentar la velocidad general de su trabajo de desarrollo.
- Pueden entrar con una intención más enfocada como un equipo diferenciado. Se asignan a una parte interesada o una iniciativa específica, por lo que el trabajo importante puede avanzar sin interrumpir su flujo de trabajo de desarrollo normal. Aún puede ocurrir una estrecha colaboración, pero el equipo externo tiene diferentes prioridades en las que se enfocarán.
- Una mezcla de ambos paradigmas. No hay líneas rígidas y rápidas para dibujar, y ser flexible tiene sus ventajas. Por ejemplo, después de que un equipo ha completado una iniciativa específica, pasa a otra, o el equipo se divide y se dispersa en otros equipos internos para que se pueda difundir el conocimiento del dominio. O tal vez pasen a un rol de apoyo.
Nuevo mundo valiente
A pesar de no tener un gran esfuerzo de cambio de plataforma en el horizonte, el desarrollo web en un mundo Drupal 9 todavía requiere planificación, pensamiento e intención. Es necesario gestionar los ciclos de lanzamiento. Es necesario planificar y desarrollar nuevos trabajos. Las partes interesadas deben mantenerse felices.
Drupal 9 hace que sea más fácil aprovechar las nuevas funciones mientras mantiene su sitio seguro, exitoso y relevante, pero ya no puede seguir adelante. No más esperas a la gran migración para deshacerse de la deuda técnica o reelaborar tu arquitectura de información.
Es necesario formar nuevos hábitos. Es necesario implementar nuevas cadencias. Se avecinan tiempos emocionantes mientras hacemos malabares con esta nueva realidad.
Por: Matt Robinson