«Todo el mundo tiene un plan hasta que le dan un puñetazo en la boca», dijo el polémico púgil Mike Tyson. Eso describe cómo nos sentimos en el Equipo de Innovación cuando llega un error de los equipos de apoyo.
Tras finalizar recientemente nuestra hoja de ruta de desarrollo e iniciar nuestros primeros sprints para las mejoras previstas en 2020, teníamos un plan, pero mantener el software existente significa que no se puede grabar en piedra. Recibir un ticket de soporte es siempre un arma de doble filo en el que uno se siente decepcionado porque se ha encontrado un error, pero intrigado porque una fábrica de afilado de mangos de la República Democrática de Manufacturistán utiliza nuestro producto.
Los inicios de la programación informática
Al dedicarnos a la innovación, necesitamos experimentar y movernos con rapidez. Por supuesto, esto nos hace especialmente susceptibles a posibles problemas de calidad.
Esto me trae a la memoria la historia de Ada Lovelace, considerada la primera persona que escribió un programa informático. No es por desviarme demasiado, pero es una historia tan interesante que creo que merece que le dediquemos tiempo.
Ada era hija del infame poeta Lord Byron (famoso mujeriego y bebedor). Su madre la empujó hacia las matemáticas y la ciencia para aislarla de los mujeriegos artísticos como su padre.
Fue en estos círculos donde conoció a Charles Babbage y su propuesta de máquina analítica. Fue la primera persona que intentó aplicar algoritmos a esta máquina en lugar de utilizarla simplemente para realizar cálculos. Su primer algoritmo intentaba producir Números de Bernoulli (una secuencia de números racionales que aparecen regularmente en la teoría numérica) utilizando la máquina, un problema que en aquella época tendría que haberse calculado manualmente para cada número. Nunca llegó a ejecutar el programa porque Babbage nunca pudo completar la construcción de la máquina analítica por falta de financiación, y Ada falleció sólo 10 años después, pero el programa permanece en sus notas de la época.
Incluso el primer programa tenía errores
Recientemente, los académicos tradujeron el programa escrito a partir de las instrucciones originales al lenguaje moderno C en un intento de ejecutarlo finalmente. Es aquí donde finalmente volvemos al tema de esta entrada del blog. Cuando ejecutaron el programa, se descubrió que tenía un error. Al menos a mí me reconforta saber que incluso el primer programa tenía un error. Después de todo, ¿no es humano equivocarse?
Los errores ocurren, pero en innovación estamos abordando este problema desde todos los ángulos posibles en un intento de evitar el mayor número posible, pero también de asegurarnos de que, cuando ocurran, las consecuencias para nuestros clientes sean las menores posibles. Además de los enfoques habituales de desarrollo ágil e incremental, pruebas unitarias y pruebas automatizadas.
Hay otras opciones inesperadas que estamos investigando para ayudar en este sentido:
- La creación de software se parece en muchos aspectos a un proceso de fabricación físico convencional, así que ¿por qué no utilizar el aprendizaje automático de , creado específicamente para este fin? Si se puede predecir dónde se manifestarán los problemas, se pueden añadir controles de calidad adicionales en esos puntos. Como parte de esto, podríamos incluso predecir el riesgo de cambios en ciertas partes del producto y luego añadir pasos como la revisión por pares o la supervisión adicional para cualquier cosa que supere un cierto nivel de riesgo.
Proporcionar otros medios de apoyo. Soy un gran fan del foro de por el mero hecho de que está a disposición de todo el mundo y permite el debate directo. Ofrecer un foro transparente para debatir sobre no solo permite acceder directamente a nosotros en el desarrollo, sino que también deja constancia de cómo se resolvieron problemas anteriores para que todos los usuarios puedan consultarlo en el futuro.
Nuestro objetivo para la próxima versión es asegurarnos de que la documentación esté disponible y sea exhaustiva para todas las nuevas funciones que hemos introducido recientemente. Los clientes y nuestros socios de canal deben estar informados sobre todos nuestros productos para que, cuando surjan problemas, estén preparados para resolver la mayoría de ellos.
Errores significativos Esto es algo que puede ser difícil de hacer en la práctica, pero nuestros errores deben ser significativos para los usuarios. No deben decir lo que salió mal, sino lo que el usuario debe hacer al respecto. De nuevo, estamos haciendo todo lo posible para añadir esto a la experiencia de usuario de las nuevas funciones lanzadas por la innovación.
Por supuesto, todo esto es parte de un viaje para nosotros aquí, pero me encantaría escuchar cualquier otra idea sobre cómo mitigar estos problemas.
¿Busca un proveedor de servicios software de química para su empresa? Galdón Software puede ayudarle.