/ blog
La dualidad del feedback, amargodon't
Una de mis luchas diarias suele ser decidir qué hacer por mis múltiples intereses. Es imposible abarcarlos todos, a tal punto de que hacer foco en uno termina “agotando” esa cuota diaria, por lo que vivo en un switch focus-mind constante. Cosa la cual, no me molesta, de hecho, me acostumbré.
Sin embargo, no puedo negar el aumento de eficiencia cuando el foco es más concreto, pero esta parte prefiero dejarla para los rangos de horario laborales.
Para mí, mis intereses, mis hobbies… prefiero hacer las cosas a mi modo.
Ahí fue que encontré en el homelab, primero, el abismo. Luego, la salvación. Algo casi tan poético como bíblico.
Entre la nostalgia reviví un juego de Dragon Ball online. Empezó self-hosted, para actualmente vivir en una VPS, dejando mi lab como algo meramente experimental. Sin embargo, este período me permitió algo que hasta ahora mis intentos fallidos de distintos productos no habían logrado tener.
Usuarios reales, dando feedback constante.
Los números de Grafana aumentaban poco a poco. Podía ver cómo algunos mapas eran más frecuentados que otros, dónde preferían subir de nivel, dónde lootear, dónde disfrutaban más en general. Era la primera vez que tenía datos reales sobre personas utilizando algo construido por mí, y, por primera vez también, dejé de pensar únicamente en qué quería hacer yo para empezar a preguntarme qué necesitaban ellos.
Y ahí, con esos datos, entendí algo triste. El juego, teniendo muchas cosas para hacer, muchísimo para explorar, un mapa adecuado a Dragon Ball… tenía un problema enorme.
El mundo no estaba vivo.
Empecé a conectarme con la cuenta GM a toda hora. Cada vez que veía un jugador online, me dirigía hacia él. Le pedía feedback. Todos pedían cosas distintas, cosas que extrañaban de otros juegos, cosas que les gustaría, cosas que ellos harían.
Me puse a analizar cada petición y me encontré con un choque de realidad. Estaba trabajando sobre una base 8.60, popular en su nicho, pero demasiado old-school para la actualidad. No permitía sistemas de monturas, ni volar, ni pescar, ni… ni… ni…
Solucionar esto requería migrar. Algo tan obvio como decir que mañana lo hago. Pero como toda migración, implicaba cambiar completamente mi estructura.
Para dimensionarlo, la versión 8.60 es del año 2010, y está siendo migrada a OTClient Redemption (Canary) 1525. Eso supone 16 años de optimizaciones, correcciones y una comunidad que siguió evolucionando mientras este proyecto permanecía congelado en el tiempo.
Y genial, lo puedo ir haciendo mientras aprendo este nuevo ecosistema. Lleva tiempo, pero es posible.
Pero había algo que seguía haciendo ruido.
Aun haciendo todo esto, seguiría con un problema mucho más radical.
El mapa.
Que si bien se ve bien, tiene un diseño que promueve los portales, zonas seguras por doquier, haciendo que la interacción entre los jugadores sea demasiado baja. Haciendo que el juego, incluso con jugadores, se sienta más muerto que vivo.
Y ahí entendí otra cosa.
El problema ya no era solamente técnico.
Era de diseño.
Dentro de los issues reportados por el portal había de todo. Gente siendo agresiva, mientras otros escribían steps para reproducir un problema con lujo de detalles.
Al principio me resultaba inevitable valorar mucho más a los segundos. Era fácil agradecer un reporte bien escrito, estructurado, casi listo para convertirlo en una tarea.
Pero, con el tiempo, empecé a notar un patrón.
Muchos de los reportes agresivos señalaban problemas reales. Estaban escritos de la peor forma posible, sí, pero seguían apuntando a algo que merecía atención.
A estos últimos, gracias.
A los primeros… también.
Porque incluso su falta de educación seguía dándome un input útil.
Si algo me dejó esta experiencia, fue entender que escuchar feedback no significa escuchar únicamente a quien sabe comunicarlo.
Significa intentar entender qué problema hay detrás de las palabras.
Y creo que eso aplica bastante más allá de un servidor de Dragon Ball.
En el trabajo.
En un proyecto personal.
En una startup.
Incluso en la vida.
La gente es otra detrás del telón.
Y aprender a separar el tono del mensaje, probablemente sea una de las habilidades más incómodas, pero también una de las más útiles que terminé desarrollando.
