¿Cuál es la parte más difícil de automatizar con éxito un sistema?

Creo que la parte más difícil es convencer a la gente de que el sistema no debe automatizarse de la forma en que funciona y que debe cambiarse. Tengo 2 ejemplos de la vida real para eso:

Me asignaron a automatizar el procedimiento de mantenimiento de la empresa. Los pasos que tienen para solicitar una pieza de repuesto para una máquina fueron:

Rellene un formulario de solicitud con los datos de la máquina y los datos de la pieza solicitada; pedir aprobación al gerente; verifique el inventario para ver si esa parte estaba allí, si no fue así, una orden de compra tuvo que ser completada y aprobada (nuevamente) por el gerente, esos 2 formularios irán a personas de compra que obtendrán una aprobación de presupuesto para su gerente , todas esas aprobaciones fueron escritas a mano, los formularios en papel tuvieron que “caminar” de una oficina a otra.

Esto fue solo una parte simple de todo el proceso, pero aquí hay una discusión real (simplificada) que tuvimos:

  • necesitamos poder imprimir ese informe para poder obtener las aprobaciones
  • no, ya no necesitas hacer eso. El gerente tendrá una lista de aprobaciones que solo necesita para ingresar al software y hacer clic en “aprobado”
  • Pero necesitamos la firma
  • No, necesita la aprobación, no la firma real. Solo el gerente puede aprobar eso.
  • ¿Y cómo sé que fue aprobado?
  • Recibirá una alerta en el software y también, según lo solicitado, un correo electrónico informándole que ha sido aprobado.
  • Y qué pasa si el sistema falla, ¿dónde obtengo el historial de aprobación?
  • ¿Con qué frecuencia necesita ver el historial de aprobación? ¿Alguna vez ha abierto su archivo de formulario aprobado para buscar una aprobación?
  • No, pero puedo … y si se borra la base de datos, perderé todo ese historial.
  • Sí, lo hará, por eso tenemos una copia de seguridad diaria. Qué sucede si hay un incendio y se queman todas sus aprobaciones. ¿Tienes un respaldo?

En pocas palabras, el tipo descubrió que podía guardar una captura de pantalla de la aprobación y luego imprimirlas … Y ponerlas en el archivo.

Segundo ejemplo: automatización de pruebas. Tuvimos 8000 casos de prueba y querían automatizar una parte importante de ellos. Tuvimos casos de prueba para “verificar el nombre es obligatorio”, “verificar el nombre puede ser editado”, “verificar el nombre no se puede eliminar”, “verificar el nombre está presente en la vista de detalles”. Lo mismo para el apellido, segundo nombre, teléfono, etc. etc. ¿Cómo quería nuestro jefe implementar todo eso?

Inicie sesión, cree un usuario, verifique que se pueda editar el nombre, cierre la sesión.

Eso, repetido para cada caso de prueba. Sí, iniciar sesión, crear y cerrar sesión para CADA campo. Propuse revisar todos los campos a la vez. ¿La cuestión? El nombre, el apellido, el segundo nombre, el teléfono, etc. representan 34 casos de prueba separados para editar, otros 34 para eliminar, otros 34 para crear, otros 34 para ver. Un total de 34 * 4 = 136 casos de prueba. Después de automatizarlos, solo teníamos 4 (edición de prueba, eliminación de prueba, creación de prueba, vista de prueba).

Y eso se ve muy mal en números. “Ejecutamos 4 casos de prueba todos los días” frente a “ejecutamos 136 casos de prueba cada dos días” (debido al retraso que implica el inicio / cierre de sesión). Entonces, adivinen cómo esos fueron re-implementados. Si, separados. Irónicamente, los probadores manuales hicieron exactamente eso, probar todos los campos a la vez y no uno por uno. Por lo tanto, las pruebas manuales tomaron menos tiempo que las pruebas automáticas y menos propensas a errores.

Y es por eso que creo que la parte más difícil de la automatización es hacer que las cosas NO se realicen manualmente.

La respuesta de Rodrigo de que la automatización requiere que cambie de opinión acerca de cómo se hacen las cosas ‘manualmente’ a cómo se hacen ‘automáticamente’ es realmente el problema. Mi experiencia es en la automatización de procesos físicos, pero se aplica la misma lógica. Cuando un humano hace un trabajo, tiende a rodearse de los objetos que necesita para llevarlo a cabo, luego busca cada pieza o herramienta en una secuencia para llevar a cabo el trabajo. Ven el trabajo como “poner la parte A en la parte B, utilizando la herramienta I, y luego realizar el trabajo 2”. No entienden que “recoger la parte A” es el primer trabajo, “mover la parte A es el segundo trabajo”, “dejarlo” es el tercer trabajo. Para que la automatización funcione, cada movimiento, función o acción por separado debe verse como separado, y se le debe aplicar la herramienta, la máquina, el proceso o el sistema de control adecuados. Una queja común de la administración es “¿Tiene que ser tan complicado?” Por supuesto, la respuesta es SÍ. Nosotros, como humanos, damos por sentado tantas cosas en la forma en que realizamos funciones simples, que siempre nos sorprendemos cuando las cosas se descomponen en las partes componentes más simples. Las cosas más simples, como “reconocer un objeto”, son difíciles de manejar para los sistemas informáticos y requieren que se incorpore la “complejidad” para que cualquier cosa funcione. Hacer que todo sea repetible es otra forma de superar parte de esta dificultad, pero tratar de explicar por qué los objetos SIEMPRE tienen que estar en el MISMO LUGAR, AL MISMO TIEMPO, en la MISMA ORIENTACIÓN, para CADA CICLO, parece estar por encima de las cabezas de algunas personas.

En conclusión, su capacidad de dividir el problema en sus componentes, averiguar el equipo y / o los procesos para resolver cada problema, vincularlos y luego transmitir esta información a las personas con las que tiene que trabajar.

Para comprender cuál es la parte más difícil de una automatización exitosa, primero necesitaremos enumerar todas las partes, independientemente de la dificultad. A un nivel alto:

Mapa del sistema

La definición de procesos puede ser difícil, pero en general no obtendrá mucho rechazo de las personas cuando intente mapear sus procesos y flujos de trabajo.

Construir automatización

Desarrollar la tecnología automatizada puede ser difícil, pero con una práctica de ingeniería disciplinada, los componentes se pueden dividir en piezas lo suficientemente pequeñas como para hacer de este un conjunto de problemas manejables y bien definidos.

Cambie el proceso de supervisión manual a gestión automatizada

Quizás sorprendentemente, la parte más difícil tiende a ser lograr que varias partes interesadas cambien a usar el sistema automatizado. Descubrirá que las personas están retrocediendo debido a los incentivos integrados en el sistema que ni siquiera sabía que existían, descubrirá que el sistema en sí tiene fallas de diseño, y descubrirá que las personas tienen miedo de perder su trabajos para la gran máquina nueva que ha construido y empujar activamente contra ella.

Generar confianza en los sistemas automatizados es extremadamente difícil. Afortunadamente, escribí una publicación de blog para ayudarte. Aquí hay 10 pasos para construir una automatización confiable.

Humanos

Creo que la parte más difícil es lograr un proceso paso a paso para que funcione bien, también significa probarlo todo el tiempo todo el tiempo (también conocido como hacerlo).

More Interesting

¿Cuáles son los diferentes pasos para diseñar diseños de un sitio web / software y organizar un sitio web / software?

¿Cuál es la mejor manera de motivar a un equipo de inicio no remunerado a tiempo parcial?

¿Cuáles son los buenos libros sobre las mejores prácticas del diseño de lenguajes específicos de dominio (DSL)?

¿Es cierto que la Ingeniería de Software tiene una gran demanda?

¿Cuáles son los comentarios de revisión de código más frecuentes?

¿Cómo maneja la responsabilidad que ha acumulado en un rol de ingeniería?

Me abruman los plazos de TI, pero me encanta la ingeniería de software, ¿qué debo hacer?

Como científico de datos, ¿cómo puedo aprender y adoptar las mentalidades de piratas informáticos de los ingenieros de software?

¿Es la capacidad de identificar casos de esquina en una función de software una habilidad de enseñanza?

Ingeniería de software: ¿Por qué la gente generalmente odia administrar el código de otras personas (en lugar de escribir el suyo)?

¿Cuánta codificación podría hacer un gerente de programa técnico en Amazon?

¿Qué debe saber todo programador sobre seguridad?

¿Qué arquitecturas o información específica necesito saber para crear una gran aplicación web con tráfico alto o medio?

¿Cuáles son sus tres criterios principales de "desactivación" al considerar trabajar para Google? ¿Cuáles son sus 3 criterios principales de "desactivación" al considerar trabajar para una startup?

¿Qué esperan los ingenieros de software de un increíble gerente de producto (en tecnología)?