El objetivo de escribir un problema es comunicar una tarea. Debe ser lo suficientemente claro para que el responsable pueda realizarlo y también brindar suficiente contexto para que los compañeros de equipo que necesitan saber entiendan qué trabajo se está realizando. Entonces, el objetivo al escribir problemas debe ser hacerlo de la manera más efectiva y rápida posible.
En Romikya usamos un sistema llamado Linear, es bastante amigable y está orientado al desarrollador ya que provee diversos atajos (shortcuts) que aceleran el uso de la herramienta.
Por qué las historias de usuario están obsoletas
Las historias de usuarios evolucionaron hace más de veinte años como una forma de comunicar lo que un cliente quería en los requisitos del producto que un equipo de software podía ofrecer. Muchas cosas han cambiado sobre cómo construimos software al día de hoy. Los clientes son lo suficientemente expertos en tecnología como para articular los requisitos básicos del producto. Hemos desarrollado estándares para funciones comunes, como carritos de compras, listas de tareas pendientes y notificaciones, por lo que no es necesario explicar cómo deberían funcionar.
Los mejores equipos de producto e ingeniería entienden profundamente a sus usuarios y están familiarizados con el funcionamiento de su producto.
Las historias de usuarios se han convertido en un ritual de culto de carga que se siente bien pero desperdicia muchos recursos y tiempo. Son una forma indirecta de describir tareas, oscureciendo el trabajo a realizar. Las historias de usuarios requieren mucho tiempo para escribir y leer y pueden aislar a los ingenieros en un rol mecánico donde codifican los requisitos del problema en lugar de pensar en la experiencia del usuario de manera integral a nivel del producto. Una de las razones por las que las historias de usuarios son complicadas y difíciles de abarcar es porque traen lo que deberían ser detalles a nivel de producto al nivel de tarea. Y, francamente, no coinciden con la forma en que nos comunicamos sobre el software en conversaciones reales.
Una mejor manera de agregar problemas a resolver
- Escribir problemas claros y sencillos que describan tareas en un lenguaje sencillo.
- Escribir problemas propios.
- Discutir la experiencia del usuario a nivel de producto y función, no a nivel de tarea.
En lugar de dedicar tiempo a crear historias de usuarios, hay que dedicar tiempo a hablar con los usuarios y pensar en las funciones antes de crearlas.
Describir tareas o problemas concretos
Un problema debe describir una tarea con un resultado claro y definido. Esto podría ser una pieza de código, diseño, documento o acción a tomar. Si no es una tarea, entonces no pertenece al rastreador de problemas. Tal vez sea una idea de proyecto que debe desarrollarse en un documento o una conversación, o una característica más grande que debe dividirse en piezas de trabajo más pequeñas y tangibles.
Habrá excepciones a esta regla. Por ejemplo, antes de trabajar en una función, hay que dedicar tiempo a explorar el diseño y el enfoque técnico. Se pueden crear problemas en el registro de actividades en estos casos para desglosarlos más tarde (p. ej., Explorar diseño) o enmarcarlos como entregables (p. ej., Escribir especificaciones del proyecto).
Escribir clara y directamente
Escribir títulos de problemas cortos y simples que indiquen directamente cuál es la tarea. El título debe ser fácil de escanear, ya que la mayoría de las personas lo leerán en una lista o tablero en el contexto de otros temas. Las descripciones deben ser opcionales, no obligatorias, y pueden incluir pensamientos o contexto relevantes, así como enlaces a discusiones más profundas. Escriba solo lo que necesite compartir para realizar la tarea y comunicar información relevante al equipo.
Cuando comparta una solicitud de función o un informe de error, cite los comentarios de los usuarios directamente en lugar de resumirlos. A menudo, un cliente describe el punto de dolor de manera más auténtica de lo que podría resumirlo y también es más rápido copiar y pegar. Enlazar a la conversación del cliente para que, si se necesita más información, sea fácil de obtener.
Escribir problemas propios
Todos en el equipo deben escribir sus propios problemas. Es más rápido y más fácil para la persona que entiende cómo hacer el trabajo escribir problemas que lo describen. También prepara a su equipo para hacer un mejor trabajo. Cuando se escriben problemas propios, te obliga a pensar en el problema a un nivel profundo. Esto crea espacio para encontrar enfoques aún mejores y facilita la detección de atajos o partes faltantes en el plan. La práctica también reformula la forma en que abordas el trabajo por completo. En lugar de construir para marcar una tarea completada o marcar una lista de requisitos, su atención se centra en el producto o entregable del proyecto.
En algunos casos, tiene más sentido escribir problemas para otros, como cuando se presenta un informe de error. Esto debe alentarse con la advertencia de que los problemas se escriben de manera ligeramente diferente. Cuando se escriba el problema, hay que enmarcarlo como una pregunta o describir el problema. Dejar que el responsable encuentre la solución y luego reescriba el problema como una tarea.
Mantener las discusiones sobre la experiencia del usuario a nivel de producto
Hay que analizar la experiencia del cliente a nivel de producto cuando se especifiquen los proyectos y crear su hoja de ruta (road map). Involucrar a todo el equipo en estas conversaciones (diseñadores, ingenieros y personas que tratan con el cliente) para que todos tengan una comprensión profunda de las necesidades, limitaciones y requisitos del producto del usuario. Luego, hay que delegar el trabajo a los equipos del proyecto y esperar que lo entreguen. Comprenderán la experiencia del usuario de manera intuitiva, por lo que no es necesario que se aclare a nivel de tarea.
