Gestión de producto: como planificar incrementos junto con los usuarios

Alejandro Lazcano — Tue, 02 May 2023 15:15:54 +0000

Cuando se trata de Gestionar Producto, en ciclos de desarrollo de software, basados en Scrum o alguna otra metodología ágil de ciclos e incrementos, tenemos el permanente desafío de planificar, priorizar y reorganizar el backlog y roadmap.

Hace tiempo un colega y amigo se refirió a su trabajo, por más apasionante que le resulta, como un tanto amor-odio-tóxico, en el sentido de que "muchas veces el desafío de priorizar nos consume la vida, el tiempo y la paciencia: queremos cumplir con todo y con todos", dijo.

¿Qué soluciones hay, entonces, a los incrementos y evolutivos de un producto de software?

Hay que liderar en base a necesidades propias de la plataforma o producto. Y esto compite con los servicios y necesidades del equipo comercial, y además contra reloj con los clientes, partners, project managers e implementadores.

Entonces, ya no solo alcanza con que el Product Manager tenga en claro el roadmap, y el Product Owner ordenado el backlog, y el Project Manager al día el proyecto, plazos, ceremonias y entregas.

¿Cómo podemos socializar el avance del proyecto y co-gestionar el avance de manera consistente?

Algunas sugerencias:

Disponibilidad a todas las partes involucradas los tableros de alto nivel, actualizados en vivo o de mínimo, al día.
Gantt abierto, visible, y cuestionable: debemos revisarlo regularmente con los equipos y estar disponibles a atender consultas, reclamos y feedback de todo, en especial sobre los plazos y prioridades.
El backlog debe entenderse como una gran pila de trabajo futuro, pero al mismo tiempo, limitarlo de forma clara a la capacidad disponible. ¿Por qué solo tomamos estas tareas o cuánto podremos abarcar en este Q? ¿Por qué no entra en sprint?
Transparentar cambios, prioridades y necesidades. Un comentario sencillo despeja especulaciones: "parece que esta tarea es una tontería, pero lo necesita urgente este proyecto estratégico que nos permitiría duplicar la facturación en el próximo Q", deja claro el por qué esto va sobre el resto.

Gestión del producto compartida con los usuarios y clientes

Recuerdo que hace una década sorprendía que HP tuviera foros donde los usuarios podían plantear consulta de productos, y había además de un equipo de soporte atento a todo ello, también muchos usuarios de diferente nivel de experiencia haciendo aportes, respondiendo, acompañando.

Pasa también con la recepción de ideas y sugerencia de mejoras con opción a voto. Atlassian, empresa detrás de Jira, Confluence, Bitbucket, y muchas otras, admiten que los usuarios y clientes puedan publicar features, necesidades. Esto queda muchas veces en revisión rápida del equipo de producto y luego se pone a votación.

A mí me gusta mucho como lo ha encarado Render:

Render es una plataforma de computación en la nube, que de forma moderna, descontracturada y acercándose a un público más de developers, está creciendo muy rápido y fuerte. ¿Cómo lo gestiona?

Tiene un apartado que denominan Feedback. Es sencillo, de interfaz simple y limpia, sin vueltas ni burocracia.

¿Lo bueno? Ya no depende de que un asistente de la cuenta, un newsletter llegue, sino que está publicado parcialmente el roadmap/backlog para que los diferentes stakeholders puedan interactuar, proponer, votar, priorizar.

También, además de las features, servicios de infraestructura, Render lo usa para proponer nuevas regiones de servicio, nuevos puntos de presencia de red:

¿Cómo gestionas tu o tus equipos el ciclo de incrementos y evolutivos? ¿Qué te parecen estas ideas?

Puedes ver más sobre product owner, scrum, project manager y analista funcional en mi blog, además de comprender formas de escalar proyectos ecommerce de manera consistente y con resultados increíbles en diferentes plataformas.

Mantenimiento de la base de datos en WordPress

Alejandro Lazcano — Fri, 26 Aug 2022 22:09:15 +0000

Tengo la suerte de mantener sitios web basados en WordPress con una década de trayectoria. Algunos con muchísimos post, además de abundante tráfico, y en consecuencia donde hay que darles cierta atención y mantenimiento regular.

Aquí una sugerencia pequeña pero poderosa y muy necesaria de atender con regularidad.

Tabla de contenidos

Mantener la salud de WordPress
Mantener la salud de la base de datos con un click
- Cuidar los datos: política de backup para la base de tu WordPress
- Cuidar la integridad de esos datos en la base de datos
Caso práctico: eliminando el overhead en una base de datos WordPress
- ¿Cómo limpiamos esos datos de overhead?
- Resumen y conclusiones:

Mantener la salud de WordPress

En el paso de los años es inevitable que, aún persiguiendo una cultura de «pocos plugins, sólo los necesarios», se vayan cambiando algunos por otros, se desinstalen los que ya no son útiles, etc. Y en ellos, muchas veces quedan tablas o configuraciones sin eliminarse completamente.

En contrapunto a esta buena práctica, de elegir los plugins, están quienes instalan decenas de complementos por cosas que podrían resolverse en 5 líneas de código. Incluso se ha popularizado la reventa de plugins pagos «crackeados» o denominados plugins nulled o plantillas truchas y/o clonadas para evadir la licencia, etc.

Para mantener la salud de WordPress, más allá de mantener al día sus actualizaciones, versión de PHP, etc; es oportuno pensar en tener una instalación de pruebas/sandbox que pueda romperse, reconstruirse, borrarse y volver a comenzar de cero o desde un backup o punto de restauración. Algo similar y más práctico son las instalaciones staging, que crean un clon del WordPress en el que vamos a trabajar y podemos romperlo sin problemas, luego replicar eso mismo sobre el original en caso de necesitarlo.

Mantener la salud de la base de datos con un click

Decía que mantengo como servicio freelance algunos WordPress que iniciaron conmigo hace más de 10 años, y en ellos hay que tener otros cuidados. Pero uno fundamental es el optimizar la base de datos, todo en cuanto tengamos a nuestro alcance.

Cuidar los datos: política de backup para la base de tu WordPress

El código de WordPress, de los plugins y plantillas, son relativamente sencillos de hacer backup y recuperar. Las bases de datos tienen otras implicancias: crecen en tamaño (peso) y longitud (cantidad de registros), cambian los motores de procesamiento, la codificación, etc… Sufren un poco más que «el código». Entonces, además de ser enfático en una buena política de Backups, vamos a una observación interesante.

De más decir que TODO backup que hagamos debe almacenarse en otro lugar, no en el mismo servidor. Puedes bajarlo o transferirlo automáticamente a Dropbox, GoogleDrive, un FTP o casilla de mails externa, bajarlo a tu computadora, tenerlos en un Pendrive o disco externo, etc. Si algo se daña gravemente en el hosting o servidor, no podrás luego conseguir los backups. Tremenda enseñanza que algunos aprendimos ante una urgencia.

Cuidar la integridad de esos datos en la base de datos

Las bases de datos son como un «excel», nada más que sin colores, ni negritas, ni nada que las haga bonitas. Son un archivo de texto que cumple cierto parámetro estandarizado y, a través de un «motor» cobra vida, es posible ejecutar consultas, procesar operaciones, etc.

Los archivos .sql son un archivos de texto plano (.txt) enorme, literalmente. También similar al CSV, que es un Excel pero sin superpoderes (estilos). Abajo un ejemplo de SQL, puro texto que sigue una sintaxis particular…

Dentro de taaanto texto, entre instalaciones, desinstalaciones de temas, plugins, actualización de post, de versiones, cambios en el motor, hay una especie de «polvillo» que se va juntando. Es un poco de residuo que no se borra de inmediato, además de que muchas veces en las bases de datos hay cosas que no se borrar, más sólo se ocultan al usuario…

También queda algo de ese «polvillo» y un poco de «estática» o suciedad por otras razones, como consultas en memoria, indexado, reproceso, etc. Todo esto técnicamente se denomina overhead.

Caso práctico: eliminando el overhead en una base de datos WordPress

Este sitio WordPress es antiguo, con más de 3000 post, algo más de 80.000 líneas en el archivo SQL si lo exportamos, y tomando de ejemplo dos tablas, encontramos una con un excesivo Overhead (22.2Mb de 57.3Mb) y otra con una acumulación importante.

PHP MyAdmin de una base de datos WordPress con elevado overhead

¿Cómo limpiamos esos datos de overhead?

En PHP MyAdmin es muy sencillo y basta ejecutar la «optimización» de las tablas, con 4 click lo tenemos resuelto.

Ingresamos a PHP MyAdmin
Seleccionamos la base de dato donde vamos a trabajar
Seleccionamos todas las tablas
Del desplegable buscamos «optimizar tablas»

Esto ejecutará de forma sencilla el comando OPTIMIZE TABLE table_name... y nos mostrará el resultado con un OK en caso que se haya logrado limpiar algo:

Resumen y conclusiones:

Mantener la salud de WordPress, más allá de los beneficios en velocidad, optimización de la experiencia de usuario, ahorro de espacio, etc, en algunos casos pueden ser notorios.

El eliminar el overhead en bases de datos, de forma regular, es parte de la limpieza necesaria. Como decía, es quitar el polvillo con un paño húmedo antes que se hagan cortezas gruesas de mugre y haga falta refregar con cepillo de alambre y espátula.

Es a veces difícil de «medir» el impacto inmediato en performance, pero de manera teórica te imaginas que en una base de datos de ~80/100Mb tener ~25Mb de basura, de seguro esforzará menos la búsqueda de datos.

Consulta a tu empresa de hosting cualquier duda adicional. Si buscas una empresa con excelentes prestaciones, diferentes localizaciones y un soporte de maravillas, puedes confiar en mi proveedor de hosting principal para proyectos propios y de clientes, WN POWER.

Forem: Alejandro Lazcano