Refactoring and technical debt
Codebases tend to accumulate junk over time. This comes in the form of disorganized code, "temporary" fixes that have become permanent when no one was paying attention, things that work but could use performance tweaks, and modules included in the codebase that are no longer used.
Previous update cycles allowed messes to pile up in a closet somewhere. When the migration or replatforming occurred, everything in that closet could safely be taken out and set on fire. Easy cleaning.
With an alternative model, you can't afford to keep pushing things around. Over time, that closet will have to be so big that it will take up the entire house.
Start taking inventory of things that need to be cleaned and start adding them as tasks for your team. Maybe your goal is to complete two technical debt tickets per month. Maybe it starts to smell gross and needs an entire sprint dedicated to a refactor. Perhaps a new feature will be easier to implement if some other code is reorganized, so add that task as a prerequisite.
However you do it, do it with intention and planning. That closet isn't going to clean itself.
With an iterative model, you can't afford to keep pushing things.
Allocate development resources
You have planned the release cycle. You have a constantly growing list of new feature requests thanks to your increased communication with stakeholders. And you have identified good targets for refactoring.
Now what?
Prioritize and assign. This, of course, depends on the size of your team and the number of stakeholders involved in the work. Your project managers have their work cut out for them because they also have to worry about appropriately assigning within the shifting tides of priorities.
You can give each stakeholder a team that they work with exclusively. This helps people feel comfortable working together and builds rapport. You're less likely to need project kick-offs every time you start something.
You can also rotate developers and teams so everyone has experience doing a little bit of everything. That way, there is some overlap in case of emergencies or rotation. It also keeps things fresh and can help prevent burnout. Let the developers talk and tell you what they are thinking and, if possible, cater to their preferences.
It can be helpful to have the same person in charge of the publishing schedule day after day, month after month. But does anyone really want that job on a day-to-day basis? Maybe they do. But you need to be sure.
For smaller teams, you may need to break things down by month or quarter. Maybe November and December are the months when everyone focuses on technical debt. Perhaps the first quarter of the year is reserved for new design initiatives and higher priority feature rollouts.
But don't let security and software updates get lost in the shuffle. Don't get lost in the weeds of overzealous refactoring. Don't ignore the needs of your stakeholders. This may seem like a juggling act, but your organization must master it to keep your website secure, relevant, and successful.
Celebrate
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.
- A mix of both paradigms. There are no hard and fast lines to draw, and being flexible has its advantages. For example, after a team has completed a specific initiative, they move on to another, or the team splits up and disperses to other internal teams so that domain knowledge can be spread. Or perhaps they move into a support role.
brave new world
Despite not having a major replatforming effort on the horizon, web development in a Drupal 9 world still requires planning, thought, and intention. Release cycles need to be managed. New work needs to be planned and developed. Stakeholders need to be kept happy.
Drupal 9 makes it easier to take advantage of new features while keeping your site secure, successful, and relevant, but you can't move on anymore. No more waiting for the big migration to get rid of technical debt or rework your information architecture.
New habits need to be formed. New cadences need to be implemented. Exciting times are ahead as we juggle this new reality.
Por: Matt Robinson