ERROR!
Sistemas de informacion implica definir procesos de conversion de datos a informacion pero no siempre llega a automatizarse a traves de un programa informatico.
Un error comun que ocurre en los analistas, es que cuando tienen una herramienta que resuelve un problema les parece infinitamente modificable para ajustar a otras necesidades similares.
Existen casos de sobreautomatizacion, donde generar un programa es 10000 veces mas complicado y problematico que definir un buen proceso manual.
Expongo algunos items de los que fui viendo
La pluma es mas poderosa que el click: No todo es automatizable, existen validaciones que solo se pueden dar manualmente.
La revision humana es factible de errores, los data entries tambien. Hay veces que los circuitos humanos bien definidos pueden funcionar de manera mas segura que un sistema y la revision por ojo humano no puede ser reemplazada por un sistema complicado pasible de ataques.
Ejemplo: en el caso de alta de nuevos usuarios en un sistema remoto, que no debe ser accesible por cualquiera y cuando se posee un centro de atencion, podriamos eliminar los workflows asociados al alta y crearlos via formularios y back-office (una persona que los da de alta), siempre que el volumen y la demanda sea acotada. No informaticemos todo de entrada.
Es asi como una compañia gano en tiempo de salida al mercado en su phonobanking y otra en numeros amigos... pero shhhh no digan nada jeje
Otra mas simple, cosas que se pueden hacer manualmente si se pregunta el costo beneficio
Herramienta Martillo: Cuando nuestra herramienta es un martillo, todo parece un clavo. No todo se ajusta a nuestro problema, algunas veces, tenemos que pensar mas alla de los sistemas (y mas alla aun de los sistemas existentes). Debemos pensar si es viable el esfuerzo de hacer un sistema.
Ejemplo: por algo que es poco usable y complicado de mantener....
El usuario quiere que se le automice el proceso de borrado de archivos basura en su maquina a traves de un conjunto de regla que definira mensualmente. El proceso de borrado se efectuara una vez al mes, la definicion de reglas se hara en un XML parseable y la cantidad de archivos mensuales a borrar son todos los que cumplan un filtro de nombre en un directorio.
Podriamos plantearnos si el usuario en vez de definirnos toooooodo esto no hace un schedule del sistema operativo o directamente lo borra el. Cuanto esfuerzo de analisis, desarrollo, versionado conlleva esto y cuanto beneficio aporta????? Seguramente luego de esto va a querer mas cosas, lo que lleva al siguiente punto:
Reingenieria infinita: Los programas no son infinitamente modificables, ya que terminarian en una reingenieria constante (hasta los chicles tienen limites)... y reingenieria es una palabra magica que soluciona todo lo que fue un caos, pero... al no corregir nunca la actitud se puede caer en infinitas reingenierias.
Otro problema tipico en la especificacion de requerimientos
Detalles tecnicos de diseño y desarrollo en los requerimientos: ok ok, puede pasar... pero, es un problema cuando llegan requerimientos del estilo: el usuario escribe un XML con el pedido a hacer y blablabla...
Por favor, escribanlo puro y que la gente tecnica decida como va a ser el formato. No lo atemos a la idea del cliente... especialmente si va a terminar realizandose con un programa o una interfaz que va a hacer la implementacion transparente.
Hoy escribi esto porque por enesima vez, por desconocimiento de las herramientas existentes, me choque con un requerimiento que como programador tuve decir que se puede hacer y como arquitecto dije que es en vano realizarlo y que va en contra de toda logica.
El requerimiento era modificar un script de shell de traspazo de repositorios (o sea, algo para un problema puntual y salir del paso) para que se adapte a un conjunto de reglas a definir sobre la reestructuracion de directorios, para hacer automaticamente y la primera vez que se sube ese proyecto al nuevo repo.
Estas reglas debian documentarse en un xml que seria parseable por el todavia simple script de shell. Estas reglas eran validadas por un circuito de UAT (user aceptance test).
Digo yo... los analistas.... no deberian decirle al usuario lo que le dije yo a ellos:
1- que suban las cosas como estan y hagan los cambios despues para que sea traceable dentro del mismo repo y comparable con el anterior (querian que se mantenga la misma revision aunque en la reestructuracion los paths cambien). No manchemos la pelota por favor.
2- shell script es para un problema puntual, esto ya es un programa que lee un pseudocodigo de reglas (es cualquiera :P)
3- si solo se va a hacer una sola vez, que lo reestructuren manualmente y no pierdan tiempo con XML's. Los clientes de repositorios pueden hacerlo
4- No digan XML, no saben como va a ser. Denme las reglas.
5- que no hagan un proceso de sistemas de una solucion puntual que puede resolverse con herramientas existentes --> no reinventen la rueda y lean la documentacion de las herramientas.
Esta tarea puede realizarse con clientes pesados que manejan filtros... pero al no conocer este tipo de herramientas, el usuario pidio informatizar y modificar una que existia....
Regla de oro conclusiva:
"When your only tool is a hammer, everything looks like a nail"
No hay comentarios:
Publicar un comentario