The 1990's Called, quieren recuperar su proceso de informe de errores

El desarrollo de software ha mejorado 100 veces desde que se inventó Internet, pero la forma en que las personas informan errores no ha cambiado desde la década de 1990. ¿Alguna vez has experimentado esto? Un ingeniero recoge un ticket y, después de investigar un poco, determina que funciona bien por su parte y que no tiene suficiente información para reproducir el error. Agregan un comentario al ticket, cambian a una tarea diferente y esperan a que el informador de errores les proporcione más información. Este ciclo se repite varias veces, y cada vez que hay nueva información en el ticket, el ingeniero tiene que recordar dónde lo dejó e intentar retomar el hilo. Los cambios de contexto como este son dolorosos para los ingenieros, y el típico proceso de informe de errores parece ser el ejemplo perfecto de este tipo de problemas. La vida real de un bicho Imagine que un compañero de trabajo informa un problema de inicio de sesión en el canal de Slack de ingeniería y un par de ingenieros dejan todo para investigar. A pesar de sus mejores esfuerzos, no pueden replicar el problema. Solicitan más información como el tipo de navegador y dispositivo. Luego, le indican al empleado que pruebe varios pasos de solución de problemas, como borrar el caché y actualizar la página. Los chats asíncronos de ida y vuelta a menudo consumen una hora o más. Eventualmente, el equipo de ingeniería tiene que programar una llamada de depuración con el empleado para tratar de identificar el problema en su computadora. Durante la llamada, el empleado comparte su pantalla y los ingenieros lo guían sobre cómo abrir la consola y las pestañas de red en las herramientas de desarrollo para discernir lo que está sucediendo. Finalmente, los ingenieros ven que hay un error 401 en la pestaña de red, que dice "contraseña incorrecta". En esencia, el problema no era que el inicio de sesión se rompiera, sino que la interfaz no pudo mostrar el mensaje de error de "contraseña incorrecta" y mostrárselo al usuario. Un simple error de front-end que debería haber tomado cinco minutos para identificar y resolver costó la tarde a un par de ingenieros. Tiempo para cambiar El proceso actual de notificación de errores sigue siendo arcaico. Desde la década de 1990, el mundo inventó la mensajería instantánea como Slack y las videollamadas como Zoom, y adoptó el trabajo remoto a nivel mundial. La comunicación de errores se ha vuelto digital. El seguimiento de errores pasó de los archivos escritos a los tickets de Jira. Y, sin embargo, el informe de errores todavía está lleno de molestos intercambios que desperdician tiempo de ingeniería. Todos hemos experimentado la frustración de lidiar con informes de errores poco claros que carecen del contexto necesario para resolver el problema. Es por eso que hace un año, algunos de nosotros comenzamos a imaginar una mejor manera. ¿Qué pasaría si pudiéramos crear una nueva herramienta que modernizara el informe de errores y pudiera resolver el problema de los informes de errores poco claros, reducir la necesidad de comunicación de ida y vuelta y ahorrar tiempo y energía a los ingenieros? Y así, la idea de nació. Una herramienta diseñada para hacer que el proceso de informe de errores sea más productivo y eficiente. Queríamos crear una solución que ayudara a los ingenieros a resolver errores técnicos, no problemas de comunicación. Mermelada Por lo tanto, nos propusimos crear una herramienta que permitiera a cualquier persona, sin importar su experiencia técnica, capturar datos técnicos contextuales completos sobre errores, para que los ingenieros pudieran identificar y resolver problemas rápidamente. Queríamos crear una herramienta que facilitara la vida de los ingenieros y, al mismo tiempo, ayudara a las personas que les informan problemas a ser más eficaces. A medida que desarrollamos y probamos Jam a principios del año pasado, vimos el potencial que tenía para acelerar la forma en que trabaja nuestro propio equipo. Por ejemplo, tome este atasco de un error en nuestro propio código. En lugar de tener que atender una llamada para depurar en vivo, nuestros ingenieros pudieron ver cuál era el problema, directamente desde el informe de errores. Empezamos a compartir Jam con otros equipos de ingeniería y la respuesta nos entusiasmó mucho. Ramp, T-Mobile y Dell estuvieron entre los primeros en adoptar Jam y brindaron comentarios invaluables que nos ayudaron a dar forma al producto. Repitiendo sus aportes, ahora nos enorgullece decir que Jam tiene más de 14 000 usuarios y contando. Pero nuestro trabajo está lejos de terminar. Sabemos que el proceso de informe de errores puede ser una gran fuente de frustración para los ingenieros y estamos comprometidos a cambiar eso. Si está harto de los informes de errores poco claros, lo invitamos a probar Jam y decirnos lo que piensa. Tenemos la misión de construir un futuro mejor para la ingeniería y necesitamos sus comentarios para hacerlo realidad. Puede comunicarse conmigo personalmente en dani@jam.dev y unirse a nosotros en este viaje.