Mitos, leyendas, tradiciones y otras cosas así (iv)
Un problema del lenguaje
Recuerdo una clase en la universidad cuando un profesor, que era de los buenos, decía con absoluta convicción que íbamos a estar en condiciones de desarrollar sistemas y aplicaciones para cualquier tipo de industria. Lo mismo podríamos hacer un sistema de información para un hospital, una agencia de viajes o un colegio; o por qué no para cualquier administración pública, por ejemplo, para una aduana o una administración tributaria. Y más o menos, así fue.
Por esa época, se hablaba de Gane & Sarson y todavía no aparecía UML. El desarrollo era en cascada del análisis al diseño, del diseño a la programación. Ni las iteraciones del RUP ni las historias de usuario de XP habían aparecido todavía. Los modelos de madurez simplemente todavía no habían madurado.
Y así, aún estudiante y por diversas razones, empezando por preguntarle a la gente sobre sus requerimientos para construir cosas sobre “negocios” que no entendía, construí o ayudé a construir: el sistema de notas para un colegio público de señoritas en FoxBase, unos programas que hacían cálculo estructural para una empresa de construcciones en Fortran , aplicaciones para una cooperativa de ahorro y crédito que tenía un Sistema 38 en RPG, consultas y reportes para una administración de aviación en un mini que corría en Wang OS, y más de una aplicación de nómina en diversas plataformas y lenguajes. En cuanto al “negocio”, conocía bien el tema del colegio, pues había sido alumno (aunque no de un colegio de señoritas), y las matemáticas para los cálculos no eran entonces un misterio. De lo demás, no tenía mucha idea, pero después del tercer sistema de nómina ya preguntaba poco.
Mis primeros pasos en una administración tributaria (o aduanera, para el caso) fueron también así, preguntando para levantar requerimientos que se plasmaron en sistemas de información y luego corrieron en MVS o Unix; en Oracle, Adabas, Informix o SQL Server; en sistemas multiusuarios con pantallas 3270 o 3151, en aplicaciones cliente-servidor, o en la Internet; en Natural, PowerBuilder, C++, Java, PhP o C#. De las pantallas de CICS a los Datawindows de PowerBuilder, a las transformaciones de XSLT. Casi ninguna de esas tecnologías estaba disponible cuando terminé mis estudios formales.
Con esas piezas de tecnología, no mucho tenían que ver los conceptos del registro de contribuyentes, de declaraciones, liquidaciones y ajustes; de la cobranza y de la fiscalización; del arancel o del valor en aduana.
Fue solo cuando me convertí “a la vez” en un técnico que entendía muy bien la parte del negocio y en alguien del negocio que entendía muy bien lo técnico; que finalmente comprendí que es verdad que un buen técnico podrá escribir software para cualquier industria, pero también es verdad que ese software será mejor cuando se conozca el negocio. Es esa diferencia entre realizar un frío levantamiento de requerimientos que no se entienden, a esa colaboración en la que se especifican requerimientos pero también se proponen innovaciones, se corrigen errores y se identifican vacíos.
Sobre eso, aunque de manera bastante más formal, en abril de 2009, hablé en la Asamblea General del CIAT, realizada en República Dominicana(1). Y tal vez por eso fue bien recibida la anécdota que, con la intención de mantener despierto al auditorio, conté sobre aquel desarrollador, cuyo nombre no menciono para proteger a inocentes, que entendió que suspender o interrumpir la prescripción eran exactamente lo mismo. Y aunque tenía al diccionario de sinónimos y antónimos de su lado, tuvo que ir al código (el tributario) para cambiar el código (el de los programas).
Saludos y suerte.
4,858 total views, 1 views today
9 comentarios
Excelente artículo Raúl. Puedo entener claramente lo que expresas en él. Saludos y éxito!
excelente el tema. Debería difundirse para la gente de Sistemas y otros afines. gracias por el comentario porque induce a estudiar mas ambos aspectos: el tributario y el software!
Y cuando se contrata el desarrollo por fuera de la administración a partir solo de casos de uso? Cómo se garantiza lo correcto de los desarrollos?
Muy ameno el post; esa es una vicisitud para quien pretenda conocer el negocio.
Ha costado mucho sudor y lágrimas, sobre todo estas últimas, aprender a conocer y dominar a fondo el tema de la interrupción y el de la suspensión de los términos, no solo para la prescripción de la acción de cobro o la de revisión, sino también cuando estos conceptos aplican sobre otros derechos del contribuyente como el de los términos para interponer recursos o para contestar requerimientos.
He visto alumnos llorar ante la pérdida de una materia por el tema mencionado y que decir de los funcionarios que no tienen claro el tema ante semejante responsabilidad, a repasar el código (o repetir la materia).
Una linda combinación junto a la temática del otro post titulado Reingenieria o proceso continuo, realmente conlleva hacer sesiones de terapias, para superar las crisis de cambios (valido tanto para nuestras administraciones públicas como para empresas privadas).
Y es claro que todo servicio de consultoría debe poseer ese conocimiento del “negocio”. Que en vez de venir en un combo de dos o más personas, lo encontremos sólo en una, se acerca más a un milagro que a un requisito de excelencia.
Así que Raúl, mis saludos por tu profesionalismo, que de acuerdo a la definición de la RAE, es el cultivo o utilización de ciertas disciplinas, artes o deportes, como medio de lucro. Excelente definición que aplica a tu post y a tu propia experiencia
Y que contagies a varios colegas!
Gracias a todos por sus comentarios generosos.
Eso sí Daniel, que los alumnos lloren (sobre todo las de un colegio de señoritas) , debería estar prohibido en cualquier código….je je. Un abrazo
Es super real… es la discusión de siempre en algunos círculos, el famoso «generalistas contra especialistas». Es que al final, despues de mucho batallar, entender del negocio y de la implementación es como la vieja propaganda de Mastercard: es de esas cosas que no tienen precio…
Digo, la cantidad de horas que ahorra alguien cuyo conocimiento – aunque no sea super especifico – da para entender el marco general es realmente tan grande que justifica por si solo su participacion… ya que su tarea es ni mas ni menos que armonizar la tarea de los especialistas de cada area.
La experiencia de Raúl en su proceso de conocimiento del negocio es el pan nuestro de cada día en los proyectos que son desarrollados. Cuando un «tributarista» encuentra un «informático» que conoce del negocio el desarrollo de la solución evidentemente es mucho mas rica en términos de calidad de la solución y profundidad de la misma. Esta simbiosis es altamente productiva y la experiencia me mostro que esta integración debe ser realizada con la mayor amplitud y humildad, nadie sabe todo realmente.
Trabajando 20 años con estos grupos humanos pude aprender que, las administraciones serán mucho mas productivas, en términos de actualización tecnológica (soluciones) si los tributaristas aprenden algo de informática y los informáticos aprenden algo del negocio. Mientras existan «absolutistas» será mas complicado avanzar.
Hola Raúl, da lugar la famosa frase “La practica hace al maestro”, pues bien el Ingeniero en Sistemas “ideal”, cuya orientación es la de creación de Sistemas de Información, termina dominando ambos lados, los procesos del negocio y la parte técnica, lo cual le da a él, un rol muy participativo, contribuyendo con interesantes ideas, que enriquecen y le dan un valor agregado al producto final que elabora. Por eso en lo personal para mí siempre ha sido muy interesante participar en los proyectos que diriges, con un excelente grupo de trabajo, donde todos aprendemos mucho de tus experiencias.