Tickets y Feature Requests: el diálogo como parte del producto
Cómo abrir un ticket en Narraya, cómo proponer una función y por qué el diálogo con los autores forma parte integrante del producto. Tiempos honestos, respuestas humanas.
Existen dos experiencias opuestas cuando algo en un software deja de funcionar. La primera: abre un ticket, recibe un correo automático, después silencio, después (al cabo de cinco días) una respuesta vaga que le pide «reiniciar el navegador». La segunda: abre un ticket, recibe una respuesta humana en uno o dos días, el problema se toma en serio, y a veces incluso se resuelve. La diferencia entre ambas experiencias no es técnica: es de cultura.
Narraya es un proyecto joven, pequeño, construido por unas pocas manos. No nos podemos permitir el lujo de la primera experiencia. Y, a decir verdad, tampoco la queremos.
El canal de Tickets, para cuando algo va mal
Los tickets en Narraya sirven para dos cosas: notificar un bug (algo que no funciona como debería) y pedir ayuda (algo que no entiende o no consigue hacer). Se abren desde un botón presente en casi todas las páginas de la aplicación, en el menú «Ayuda». La respuesta llega por correo electrónico, con la traza interna del ticket siempre accesible desde su cuenta.
Sin chatbot entrenado para hacerle rebotar. Sin FAQ que recorrer antes de llegar al formulario. El primer contacto es humano: al menos mientras el tamaño del proyecto lo permita, y nos comprometemos a hacer que siga siéndolo el mayor tiempo posible.
Cómo abrir un ticket que recibe una respuesta de verdad
-
Describa qué estaba haciendo.
«Estaba escribiendo un capítulo» no basta. «Estaba exportando el tercer capítulo a DOCX» es mejor. Una frase de contexto.
-
Cuente qué ha pasado.
El comportamiento observado: mensaje de error exacto, paso que no se activa, función que responde de forma extraña. Lo que ha visto, no lo que ha deducido.
-
Diga qué esperaba en su lugar.
Sencillamente: «esperaba recibir el archivo DOCX en descarga, recibí una página de error». Eso nos ayuda a entender si es un bug o un malentendido.
-
Si es posible, adjunte una captura de pantalla.
Vale más que mil palabras. El botón de adjuntos está en el formulario del ticket. Archivos hasta 10 MB.
-
Vigile su correo.
La respuesta llega ahí y puede pedirle más detalles. Responda desde el mismo correo: el hilo permanece ordenado.
No prometemos respuesta en 24 horas. Un proyecto pequeño no puede sostener ese nivel de servicio sin sacrificar otra cosa, como el desarrollo del producto que todo el mundo espera. Respondemos, de media, en 2-4 días laborables para tickets no urgentes, y mucho más rápido para bugs que bloquean por completo una función. Es una promesa realista, que podemos cumplir. Las promesas que no podemos cumplir las evitamos, porque son una forma de engaño.
Las Feature Requests: la voz de los autores
Hay otro canal, distinto e importante: las Feature Requests. Son propuestas públicas de nuevas funciones (o mejoras de las existentes) que cualquier usuario puede abrir. Cada feature request es visible para todos los usuarios de Narraya y se puede votar: un «+1» si la idea le sirve, un comentario si quiere añadir su punto de vista.
No es democracia directa: al final somos nosotros quienes elegimos qué desarrollar, equilibrando prioridades, esfuerzo y coherencia del producto. Pero tampoco es teatro: leemos cada petición, los votos pesan de verdad, y muchas funciones lanzadas en los últimos meses nacieron precisamente ahí.
Tres tipos de retorno que nos ayudan de verdad
Un bug reproducible
«Cuando hago clic aquí, ocurre esto, cuando debería ocurrir aquello». Con pasos que cualquiera puede repetir. Es el tipo de ticket que resolvemos antes, porque es el menos ambiguo.
Una función ausente bien argumentada
No «sería bonito tener X», sino «cuando hago Y, me veo obligado a pasar por un paso externo y pierdo treinta minutos». La motivación hace la petición evaluable. Sin motivación, sigue siendo un deseo abstracto.
Una mejora de UX
«La ficha de personaje está a tres clics de donde escribo, ¿podría ser un botón al lado del capítulo?». Pequeñas sugerencias operativas que mejoran días de trabajo reales. A menudo las más valiosas, porque nacen del uso real.
Lo que NO es una feature request útil
Digámoslo claramente: «hacedlo como [otro software]» no es una feature request. Cada producto tiene una filosofía, y Narraya tiene la suya. Si le falta algo, lo que nos interesa saber es por qué le falta (el problema real que resolvería) y no una referencia genérica a una herramienta competidora. La misma función, pensada dentro de una filosofía distinta, puede convertirse en otra cosa.
Y otra aclaración: las peticiones que contradicen nuestra filosofía de fondo (por ejemplo, «quiero que la IA escriba el capítulo en mi lugar») las leemos con respeto, pero no las realizaremos. No por terquedad: porque Narraya ha tomado una posición explícita sobre lo que quiere y no quiere ser, y traicionar esa posición para satisfacer peticiones aisladas equivaldría a traicionar a quienes nos han elegido precisamente por ella.
El diálogo como parte del producto
Recibimos tickets y peticiones cada día. Algunos nos hacen sonreír (en el buen sentido), otros nos hacen pensar, otros señalan problemas cuya existencia jamás habríamos sospechado sin el usuario que los vivió. Este intercambio no es un «extra» del producto: es parte del producto. Sin usted, Narraya sería un software peor.
Para abrir un ticket o proponer una función, entre en Narraya y busque el menú «Ayuda» en la esquina inferior izquierda. La primera respuesta llega a mano: en todos los sentidos del término.