Añádelo como fuente preferida en Google
Estás listo para probar una actualización de una extensión de WooCommerce. La IA te ayuda a repasar las notas de la versión y tienes abierto un borrador del plan de pruebas. Entonces, un compañero te pregunta si la actualización afecta a alguna regla de pago personalizada. Sabes que algunas tiendas de clientes las tienen. Pero, ¿cuáles?
Lo preguntas en Slack. El desarrollador que conoce esas tiendas está en reuniones hasta la hora de comer, así que te pones con otro ticket mientras esperas.
Otra agencia usa la misma herramienta de IA, pero su desarrollador puede encontrar las excepciones de pago en las notas de cada tienda. Hay un pedido de prueba para hacer el test, con el descuento esperado escrito al lado. Así pueden empezar con la comprobación.
A medida que la IA reduce el tiempo que dedicas a preparar los cambios, estos pequeños detalles del día a día tienen cada vez más influencia en la cantidad de trabajo que consigues terminar. Analizaremos cómo hacer que el conocimiento que tiene tu equipo sobre el sitio sea más fácil de usar y cómo proporcionar a los desarrolladores la información que necesitan para evaluar las sugerencias de la IA. También veremos cómo saber si esas mejoras te permiten ahorrar tiempo en todo tu portfolio de clientes.
Cuando el trabajo empieza a acumularse
Con la ayuda de la IA, terminas un parche en veinte minutos y lo envías para que lo revisen. Tu jefe técnico tiene que comprobar si esa misma personalización funciona en el sitio de otro cliente, pero no podrá hacerlo hasta el jueves. Tú sigues trabajando. Para cuando abra ese primer ticket, ya tendrás cuatro parches más esperándole.
Puedes ver el problema en las marcas de tiempo de los tickets. Escribir lleva minutos, pero esperar lleva días. Contratar otra suscripción a IA no cambia ese retraso.
En el estudio de Atlassian sobre la experiencia de los desarrolladores en 2025, el 50 % de los desarrolladores afirma perder al menos diez horas a la semana en tareas que no tienen que ver con la programación, en gran parte debido a ineficiencias organizativas. La encuesta abarca a 3.500 desarrolladores y responsables de seis países. Buscar información figura entre las principales causas de pérdida de tiempo. Se trata de experiencias relatadas, no de registros de tiempo medidos, pero ofrecen a las empresas un punto de partida útil para investigar.
Puede que alguien de tu equipo se pase parte de cada revisión buscando enlaces al repositorio o recordando a sus compañeros en qué sitios se comparte una personalización. Incluso alguien que esté listo para hacer una prueba en ese mismo momento podría tener que esperar a que le den acceso.
Esto se evita si mantienes esos detalles en el registro del proyecto y te aseguras de que los desarrolladores que se encargan de ello tengan el acceso que necesitan. Un compañero debería poder encontrar las instrucciones de prueba existentes y ponerse manos a la obra. El responsable aún puede intervenir cuando un cambio se comporta de forma inesperada, sin tener que responder cada vez a la pregunta: «¿Dónde está el código?».
El conocimiento del sitio que tu equipo acumula se vuelve más valioso
El endpoint de precios personalizados de una tienda mayorista tarda varios segundos en responder. Cuando le preguntan cómo acelerarlo, un asistente de IA sugiere almacenar la respuesta en la caché durante diez minutos. Así, tu sitio no tendría que calcular el precio en cada solicitud.
Sin embargo, cada cliente tiene una tarifa negociada. Si envías una respuesta guardada a la cuenta equivocada, un comprador puede ver los precios de otra empresa. El desarrollador que programa el endpoint sabe por qué se salta la caché compartida. Alguien que se haga cargo de un ticket de rendimiento seis meses después puede ver una oportunidad de acelerar el sitio sin darse cuenta de lo que supone ese cambio.
El comentario que aparece junto al endpoint puede ser sencillo, claro. Algo como: «Cada cuenta de distribuidor tiene su propio precio negociado. No guardes esta respuesta en la caché compartida», serviría perfectamente.
En el registro del sitio, indica a tus compañeros dónde está el código e identifica dos cuentas de prueba con precios diferentes. Tras un cambio, pueden iniciar sesión con cada cuenta y comparar el precio que se muestra con la tarifa que debería recibir el comprador.
Eso le da a tu compañero un motivo para cuestionar un cambio propuesto en el almacenamiento en caché de WordPress. Además, le proporciona al asistente de IA un contexto más útil cuando le pides que revise alternativas.
Piensa en lo que dirías al entregar un sitio web a un compañero:
- «El departamento de compras va a usar este informe en la reunión del lunes. Tiene que estar listo antes de esa fecha».
- «Las fechas de la importación siguen la zona horaria del proveedor».
- «Estamos a la espera de que se resuelva este problema del plugin antes de eliminar la solución provisional». Incluye el enlace del problema.
Cuando una actualización del plugin solucione el problema, deberías anotarlo y añadir la fecha. Las instrucciones antiguas pueden quedarse tal cual, y es posible que el resumen de la IA siga recomendando una solución alternativa que tu sitio ya no necesita.
Usa la herramienta de IA aprobada por tu empresa y elimina las credenciales de todo lo que pegues en ella. Los datos de los clientes también deberían quedar fuera; inclúyelos solo si la pregunta lo requiere. Añade un enlace al código o a la configuración correspondiente junto a la respuesta para que el próximo desarrollador pueda comprobar si coincide con lo que hay en el sitio.
Un buen diagnóstico permite a los desarrolladores evaluar las sugerencias de la IA más rápido
«A veces el proceso de pago va lento» deja mucho margen para las conjeturas. Un asistente de IA puede generar al instante una lista plausible de posibles causas. Unos diagnósticos útiles te permiten empezar a descartarlas.
Los pedidos pequeños se procesan sin problemas. Pero si añades doce productos diferentes al carrito, el sistema tarda seis segundos en volver a calcular el total. Un análisis de la herramienta de monitorización del rendimiento de la aplicación apunta a la función de descuento personalizada. Por cada línea del carrito, esta función vuelve a la base de datos y recupera de nuevo el historial de pedidos del mismo comprador.
Ahora tienes una pregunta concreta: ¿puede la función recuperar ese historial una vez y reutilizarlo durante el mismo cálculo? Puedes pedirle a la IA que te ayude a revisar el código teniendo en cuenta esa restricción.
Después de modificarlo en el entorno staging, repite la prueba con los doce productos y comprueba el número de consultas. Asegúrate de que el descuento sigue siendo correcto cuando cambies las cantidades. Un tiempo de respuesta más corto no sirve de mucho si el cliente recibe un total incorrecto.
Si alguien del equipo se encarga de investigar el problema a la mañana siguiente, tendrá el historial, pero ¿sabrá que hiciste la prueba en el entorno staging con una cuenta para distribuidores? Tendrás que incluir ese detalle en el ticket. En cuanto a los registros de errores de WordPress, indícales el intervalo de tiempo y la zona horaria correspondientes para que puedan encontrar las entradas de esa misma prueba.
Esto también es importante cuando la IA ayuda en la investigación. El informe State of Observability 2025 de Splunk recoge las opiniones de 1.855 profesionales de la observabilidad, y el 48 % señala que la mala calidad de los datos es su principal obstáculo para estar preparados para la IA. Si no se indica qué cuenta activa la regla de descuento, el asistente tiene menos información con la que trabajar, por muy detallado que parezca el rastro.
Además, mejora la comunicación con tu cliente. Puedes explicarle que los carritos grandes cargan repetidamente el mismo historial de pedidos y describir la prueba con la que compruebas tu corrección. El cliente recibe una explicación del retraso, en lugar de otro mensaje diciendo que estás probando varias cosas.
Los entornos coherentes hacen que las mejoras sean útiles en todo el portfolio
Una sola solución de rendimiento puede ahorrarte trabajo en varios sitios web, siempre que sepas dónde más buscar.
Imagina que un plugin de informes vuelve a calcular los totales de pedidos de un año cada quince minutos. El cliente solo abre ese informe para una reunión semanal. Te das cuenta de que esos cálculos repetidos consumen recursos de la base de datos y cambias la programación para que se adapte al uso que el cliente hace del informe.
Tu agencia instala el mismo plugin en otras once tiendas. Con un inventario actualizado, puedes identificarlas y comprobar su configuración. Sin él, alguien tiene que abrir los paneles de control uno por uno o buscar el nombre del plugin en las facturas.
La pregunta «¿Dónde guarda este sitio su código personalizado?» se vuelve pesada enseguida cuando gestionas varios sitios de WordPress. Saber dónde están los archivos ahorra a tus compañeros tiempo de búsqueda, al igual que los registros que usan el mismo nombre para la misma configuración. Las notas de programación pueden aclarar dudas que la configuración del plugin no resuelve, como si el servidor activa los cron jobs de WordPress.
«El equipo revisa este informe a lo largo del día» debe ir junto a la configuración de actualización en las notas del sitio. Si copias el horario semanal de otra tienda, acabarían trabajando con datos desactualizados. Incluye también la versión del plugin instalado en ese registro. Un desarrollador puede perder el tiempo buscando un control de programación que existe en una versión más reciente, pero que no aparece por ningún lado en la configuración de esta tienda.
La IA puede ayudarte a comparar los ajustes exportados o a preparar una lista de posibles coincidencias. Revisa esa lista comparándola con los sitios web reales antes de aplicar el cambio. El mero hecho de que los nombres de los plugins coincidan no garantiza que los clientes utilicen la funcionalidad de la misma manera.
Añade «¿Con qué frecuencia usa el cliente este informe?» a las notas de configuración del plugin. El desarrollador que lo instale en la siguiente tienda podrá ajustar la programación durante la puesta en marcha. Un informe que el cliente abre los lunes por la mañana difícilmente necesita actualizarse cada quince minutos durante toda la semana. Tu equipo ya ha investigado ese problema una vez; la siguiente instalación se beneficiará de la respuesta.
Incorpora la IA a las revisiones que ya realizas
La revisión de plugins del martes puede suponer pasar mucho tiempo con los registros de cambios abiertos. Para cada sitio web, alguien tiene que comparar la versión instalada con la nueva versión y determinar qué cambios merecen un análisis más detallado. Por ejemplo, una tienda con una regla de descuento personalizada necesita prestar especial atención a cualquier cosa que altere la forma en que el proceso de pago calcula los precios.
Eso le da a un asistente de IA una tarea concreta. Con la versión instalada y una explicación de la regla de descuento, puede detectar los cambios que podrían afectar al cálculo. El resumen tiene que incluir enlaces a las notas de la versión, para que el desarrollador pueda leer esas entradas en su contexto. Siguen siendo ellos quienes deciden si una actualización afecta a la tienda, pero tienen menos información que revisar primero.
«Revisa todos nuestros sitios y dinos qué requiere atención» le da mucho menos con lo que trabajar. Puede generar un informe que parezca impresionante, pero que omita ese detalle de compatibilidad que tu desarrollador necesita.
Prueba con una tarea más concreta en unos cuantos sitios que conozcas bien. Compara el resultado con tu propia revisión. ¿Distingue entre una corrección propuesta y una ya publicada? ¿Trata un número de versión que falta como desconocido o rellena el hueco con una suposición?
El script compara la versión del plugin instalado en cada sitio web con la versión disponible. También señala las exportaciones de configuración que faltan.
Cuando un sitio no devuelve su configuración, el informe dice: «Revisión incompleta. Falta la exportación de la configuración de este sitio». Esta entrada hace que el sitio se mantenga en la lista de tareas pendientes del revisor. Una fila vacía podría parecerse fácilmente a un sitio que ha superado la comprobación.
Mide la capacidad que ganas
Una tarde sin un sinfín de mensajes del tipo «¿Dónde encuentro esto?» le da tiempo a tu responsable técnico para terminar el trabajo del cliente. Podrás ver los beneficios mucho antes de aceptar otra cuenta.
Tus tickets de proyecto y de soporte pueden mostrar si los retrasos que intentas acortar realmente se reducen. Dependiendo de lo que siga retrasando el trabajo, podrías hacer un seguimiento de:
- Tiempo de espera para el lanzamiento: ¿Cuánto tiempo pasa un cambio terminado antes de que alguien pueda verificarlo y lanzarlo?
- Tiempo de investigación: ¿Cuánto tiempo tarda el desarrollador en determinar la causa de un problema notificado?
- Tickets reabiertos: ¿Con qué frecuencia vuelve a aparecer el mismo problema después de que el equipo haya marcado la solución como completada?
- Horas de soporte no planificadas: ¿Cuánto tiempo del proyecto programado se dedica a reparaciones inesperadas?
Por ejemplo, imaginemos que hay seis incidencias de mantenimiento similares en las que, en cada una, el responsable del proyecto tiene que buscar los detalles de configuración. Una vez que hayas mejorado los registros del sitio, revisa las siguientes seis incidencias que lleguen. Si los miembros del equipo pueden resolver cinco de ellas sin esa interrupción y las soluciones se mantienen, tendrás pruebas de que las notas ayudan.
Cuando alguien cierra un ticket y le pasa la investigación pendiente a un compañero, el equipo sigue teniendo que dedicar tiempo a esa reparación. Además, los desarrolladores suelen subestimar las horas de soporte técnico al no incluir en sus hojas de asistencia las interrupciones de cinco minutos. Esas interrupciones siguen fragmentando su jornada, las registren o no.
Si tienes datos de tickets comparables de varias semanas, tendrás una mejor base para valorar si hay alguna mejora. El volumen de tickets es importante en este caso. Una semana tranquila, como es lógico, te deja más tiempo para trabajar en el proyecto, independientemente de los cambios que haya en tu documentación o en tus herramientas de IA.
Tu responsable tiene ahora dos tardes libres para proyectos de clientes. Una semana ajetreada en el servicio de soporte te permitirá saber si puedes contar con ese tiempo. Si termina el trabajo programado sin tener que dejar la mitad para la semana que viene, tendrás una base más sólida para decir que sí a otro cliente.
Una configuración de alojamiento que tu equipo conozca
«Revisa los registros» supone que tu compañero sabe dónde encontrarlos. Si cada cliente usa un proveedor de alojamiento diferente, puede que pase la primera parte de un ticket de soporte buscando en un panel de control que no conoce. Una configuración familiar le permite ponerse manos a la obra con la investigación.
Kinsta integra esas tareas en MyKinsta. Cuando una tienda se ralentiza, un desarrollador puede activar Kinsta APM durante un periodo de investigación y examinar las transacciones relacionadas con PHP, las consultas a la base de datos y las solicitudes externas. También puede ver los registros disponibles del sitio desde el panel de control.
El desarrollador puede recrear ese carrito lento con 12 productos en un sitio staging de WordPress usando una cuenta de prueba para mayoristas. Sabe cuál debería ser el descuento, así que puede comprobar el cálculo revisado sin tocar los pedidos en producción. Comparar la velocidad requiere un poco más de cuidado. Si el entorno staging usa una configuración de caché diferente o tiene menos recursos que el de producción, los tiempos no te darán una comparación fiable.
«¿Me puedes dar acceso?» no debería ser el primer mensaje que recibas cuando un compañero se encarga del soporte técnico. La gestión de usuarios de MyKinsta te permite darles acceso al entorno staging con antelación, reservando el acceso al entorno de producción para quien implemente la corrección. Si ese compañero trabaja habitualmente en los sitios de tus clientes, puedes asignarle un rol a nivel de empresa en lugar de gestionar el acceso para cada sitio por separado.
Cuando varias tiendas usan tu extensión de descuentos, las etiquetas de los sitios facilitan la búsqueda de esas instalaciones. Puedes abrir el grupo cuando haya que probar una corrección y, a continuación, consultar el registro del proyecto de cada tienda para ver sus reglas de precios. Eso sí, la etiqueta tiene que reflejar lo que realmente hay en el sitio. Una tienda que ya no usa la extensión no debería seguir apareciendo en esa lista.
Dónde invertir primero
El comentario «Aún esperando acceso al entorno staging» puede quedarse ahí en un ticket medio día mientras se espera a que se pruebe una corrección del checkout. Si ese comentario sigue apareciendo en tus tickets recientes, tienes un problema concreto que resolver. Los desarrolladores que se encargan de esas tiendas necesitan cuentas que les permitan hacer su trabajo sin tener que esperar a que el titular de la cuenta vuelva a estar online.
Si alguien de tu equipo prueba a iniciar sesión con sus propios datos, te dará más información que una simple lista de permisos asignados. Puede que llegue al panel de control y aún así no tenga acceso al entorno que necesita. Descubrirlo entre un ticket y otro te da tiempo para solucionarlo sin que el cliente tenga que esperar.
«Ejecuta la prueba de pago habitual» da por hecho que tu compañero conoce la tienda tan bien como la persona que escribe el código de descuento. Puede que no tenga ni idea de qué cuenta cumple los requisitos para los precios al por mayor. Incluir esa referencia de cuenta junto al enlace a la regla de descuento les ahorra tener que esperar a que el autor responda.
«Ya he iniciado sesión. ¿A cuánto debería ascender el total del carrito?» Un comentario así en el siguiente ticket muestra en qué aspectos los miembros del equipo aún necesitan ayuda. Deberías indicar el importe esperado junto a la referencia de la cuenta cuando respondas. De lo contrario, quien se encargue del proceso de pago la semana que viene podría preguntarte lo mismo. Otra vez.
Haz que la próxima web sea más fácil de mantener
Volviendo a las dos agencias, los dos desarrolladores ya tienen listos para las diez los borradores de prueba generados por IA. El equipo que tiene documentada la excepción de checkout ya puede poner en práctica su borrador. El otro todavía necesita que alguien le dé una respuesta en una reunión.
Esas pequeñas ventajas cobran más valor a medida que la IA ayuda a tu equipo a preparar más trabajo. Te permiten aprovechar el trabajo extra sin tener que enviar todas las preguntas a la misma persona.
Elige un retraso recurrente y elimínalo. Después, dale al siguiente desarrollador la información suficiente para que se beneficie de la solución. El alojamiento administrado para WordPress de Kinsta ofrece a tu equipo un entorno familiar para investigar y probar cambios a medida que crece tu portfolio de clientes.
