Definicion Inteligente de Indicadores de Pantalla.

 

Mejores Práctica para Rpg Ibm  en Pantalla Verde.

 

 

 

En esta oportunidad vamos a ver algo muy sencillo que facilita el mantenimiento y la compresnsión de un programa a los programadores que deban resolver alguna incidencia o falla que deba solucionarse. 

 

 

Supongamos que tenemos la siguiente pantalla:

 

        

Se distinguen seis botones al pie de página: Confirmar, Insertar, Modificar, Eliminar, Retornar, Salir.

Cada botón al ser presionado, debe ejecutar una función diferenciada y única dentro del programa. 

Tradicionalmente el programador debe:

1.- Abrir al código fuente de la pantalla y ver cual indicador corresponde a cual botón

2.- Abrir el código fuente del programa, ubicar donde se usa el indicador

3.- Corregir la lógica del programa en la sección donde las operaciones están fallando.

 Hay una manera de ahorrarnos el paso 1 y agilizar el paso 2.

En el archivo de pantalla las declaraciones permanecerán igual al estandard conocido.

 

En el código fuente del programa RPG está la diferencia.

 

Podemos ver en la hoja "F" la palabra clave INDDS que referencia una estructura de datos, asociada a los indicadores que a su vez estan relacionados con las teclas de función. 

La posición de inicio de cada campo dentro de la estructura de datos esta asociada con el número del indicador. Por ejemplo, INSERTAR que comienza en la posición  6, está relacionada al indicador 06.

Lo mismo aplica para el resto de los indicadores.  Seguidamente en lugar de preguntar con un IF:

IF *in01, *in03, *in06... etc estamos relacionando directamente la función que hace la tecla con el indicador y su significado.

Puedes descargar el código fuente en este enlace:

Codigo Fuente para descargar

             

     Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo o en el enlace de Linkedin que está encima de este mensaje.  El conocimiento es valioso, compártelo. 

    Autor: Ing. Liliana Suárez

Superar a la Competencia

Para este artículo hacemos referencia a tres “invitados” de lujo.  

Steve jobs, Henry Ford y Sun Tzu.

                                                                                                                                                                                                                                                               


 

Las áreas de negocio están conformadas por varias industrias, empresas o corporaciones que constantemente compiten entre si para captar mas clientes y lanzar nuevos productos basados en tecnologías de última generación.

Hay períodos cruciales cuando es necesario que los desarrolladores produzcan programas más rápido de lo normal porque hay que evitar que la competencia lance el mismo producto al mercado antes que nosotros.

Hay un dicho que reza: El que pega primero pega dos veces.

Ciertamente tiene una gran ventaja quién primero lanza una oferta al mercado pero también es necesario no perder de vista que no solo es importante salir de primero sino mantenerse en esa posición.

En general, la solución que se adopta para superar la brecha entre los desarrolladores disponibles y el tiempo limitado de desarrollo es contratar más desarrolladores.

Estos desarrolladores temporales  o contratados traen su experiencia y metodología de trabajo que puede ser  igual mejor o peor a la metodología disponible en la empresa que los recibe; si es que la empresa tiene metodología alguna.

Cuando mencionamos la palabra metodología inmediatamente la gente se orienta a metodologías como Agile, Rup o cualquier  otra orientada al desarrollo de proyectos. 

No se piensa en metodologías que estén relacionadas con el proceso de programación en si mismo. El método de desarrollo se deja al arbitrio y experiencia de cada desarrollador.

La palabra metodología, en general, produce rechazo a la gente de TI.

Eso de metodología suena a lento, limitado, incómodo porque parece restrictivo y además  da la impresión de queno  permite generar espacios creativos.

Lo que en realidad se oculta detrás de este concepto es un rechazo intenso al cambio.

La metodología genera cierta ansiedad ante la necesidad de adaptarse a otras maneras de trabajar que no coinciden con la experiencia profesional del desarrollador aunque esa otra manera de trabajar sea más eficiente.

Henry Ford se hizo invencible creando un sistema de ensamblaje de automóviles que requería menos trabajadores y producía más autos en menos tiempo.

Las  ruedas, los frenos, el tren delantero, el volante y los demás componentes del auto ya están listos para ser ensamblados. No hay que fabricar cada componente una y otra vez.

Si extrapolamos este ejemplo de Henry Ford a metodologías para el desarrollo de software, podemos establecer como meta  construir un línea base tecnológica contentiva de programas, prototipos, procedimientos, módulos, enlaces y componentes que han sido previamente fabricados, probados y codificados y sobretodo 'enlazados entre sí ' en forma eficiente y efectiva. Esta base tecnológica no es contraria a la creatividad; todo lo contrario.

Los desarrolladores no tendrían que ocuparse de buscar códigos estándar y repetitivos para  desarrollar sus programas. 

El tiempo que se ahorra con esta base tecnológica crea un espacio para la propuesta, el ingenio y la creatividad. 

Nuestra línea base tecnológica  debe ser actualizada cada cierto tiempo y ademas documentada con un mínimo de contenido para dar idea al programador del uso que se le puede dar a cada elemento que la integra. 

Para aquellos que les disgusta documentar,  la documentación puede ser sustituida por la creación de prototipos  que pueden ser ejecutados para que el desarrollador pruebe su funcionalidad y decida cómo utilizar el prototipo que está evaluando.

Alrededor del año 2011 me tocó trabajar con un desarrollador Hindú. Cabe destacar que, se considera a los hindues los mejores programadores del mundo.

Los prototipos sobre los cuales se basaba el estilo de programación de este compañero hindú fueron modernos, dinámicos y fáciles de entender. Eso me permitió en esa época trabajar a una mayor velocidad. Incluso se me ocurrió un desarrollo que generaba información en forma dinámica para generar un pdf en windows.

 El tiempo que me hubiese gastado en desarrollar por mi cuenta, sin contar con el soporte de un propotipo eficiente, no hubiese dado cabida para generar ideas y propuestas en el desarrollo de otras aplicaciones para ofertar en el mercado.

Una vez aceptado el hecho de que se necesita una linea de ensamblaje de programas, hay otro problema que solucionar: Quién, cómo donde y cuando se desarrollará esta repositorio tecnológico que  será la plataforma de despegue para la línea de ensamblaje. Este asunto puede verse sencillo pero no lo es.

Por una parte, los programadores están dotados de un ego extraordinario con el cual cada uno piensa que su estilo de programación es el mejor para desarrollar software.

Por otro lado, el asunto tiene que ver con la aceptación de que algunas veces los trabajadores temporales o consultores contratados que vienen a ayudarnos tienen mas y mejores recursos para montar una línea de ensamblaje mucho mejor que la nuestra.

El ego es, definitivamente un obstáculo intangible pero real. El territorio del programador es sagrado y cualquiera que demuestre intencionalmente o no,  una calidad superior de desempeño es generalmente atacado y dejado de lado.

Se  contrata a los mejores programadores del mundo para que se adapten a nuestra metodología de trabajo (si es que la tenemos) cuyos estandares no son tan optimos, ni por asomo, a la que nos traen nuestros huespedes.

Esto genera un inmenso desperdicio de talento, y no genera ningún valor agregado en nuestra fábrica de software. Además, estos consultores o desarrolladores nos abandonan mas temprano que tarde al verse forzadamente sumergidos en una dinámica de trabajo inferior al estándar óptimo al cual están acostumbrados.

Como dijo Steve Jobs:

Una solución salomónica a este asunto, dado el poco tiempo que se tiene para lanzar el producto y a la vez integrar ambos metodologías (o para mejorar la que tenemos)  es dejar a nuestros huespedes trabajar con su metodología para aprender algo de ellos y quedarnos con sus códigos.

Nuestra base tecnologica debe ser actualizada posteriormente con estos modelo mas eficientes integrandolos con los nuestros. Antes de derrotar a la competencia hay que derrotarse a si mismo.

Como dice Sun Tzu en su manual  El arte de la guerra:

                            "Cada Batalla se gana antes de haber peleado"

          

Otra frase de Sun Tzu para recordar:

“La invencibilidad está en uno mismo; la vulnerabilidad en el adversario”.

                    

     Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo. 

    Autor: Ing. Liliana Suárez

Procesos de Cierre: Las Peores Practicas

En este post voy a llevar la contraria al tópico recurrente de “Las mejores prácticas en…”.  

Voy a exponer  lo que hacemos repetidamente de manera incorrecta sin darnos cuenta de eso.     


                                                                                                                                     

¿Que es un proceso de cierre?

                                         

Una vez  finalizados los procesos operativos del  día, las instituciones requieren ejecutar procesos de cierre automatizados para actualizar sus bases de datos con  las  transacciones realizadas durante el periodo diario, mensual o anual que corresponda.

Los procesos de cierre que he revisado a lo largo de mi carrera profesional han sido sumergidos en las siguientes “peores practicas gerenciales” aplicadas en el área de sistemas que se resumen en esta frase:

Nadie entiende verdaderamente lo que sucede allí adentro y lo que es peor: a nadie le importa.

Peores Practicas Gerenciales en la Gestión de los procesos de Cierre

·         El software no tiene documentación ni técnica ni funcional.

     Una pésima práctica que se repite una y otra vez consiste en no exigir a los proveedores de software una documentación técnica y funcional de los procesos desarrollados.

    Algunos proveedores engañan al cliente argumentando que el software esta autodocumentado. Ni los analistas de Organización y métodos ni lo analistas funcionales son involucrados en el proceso de evaluación del software antes de adquirirlo.

    Por otra parte, los desarrolladores de la empresa no están dispuestos ni preparados para dedicar tiempo ni esfuerzo a documentar los desarrollos o los ajustes que realizan.

·         Rotación de recursos sin transferencia de conocimientos.

  

     En un taller mecánico dedicado a la reparación de automóviles, cuando se va quien repara los frenos, se sustituye por otro empleado mecánico que realiza el mismo trabajo que el anterior casi inmediatamente. Sin embargo, en productos donde está implicada la propiedad intelectual, como ocurre en el área de sistemas, es un error aplicar ese mismo concepto de la sustitución inmediata sin transferencia de conocimientos.

    En una institución para la cual trabajé hace algún tiempo, era de carácter obligatorio la planificación de una sesión de transferencia de conocimientos a la cual debía asistir todo el personal de IT, independientemente del lenguaje de programación, del equipo o de la funcionalidad del producto desarrollado.

    Los desarrolladores debían explicar técnica y funcionalmente la aplicación instalada así como sus conexiones con otras aplicaciones y con las áreas funcionales de la institución. Además debía entregarse una documentación detallada que debía ser almacenada en una carpeta compartida de acceso controlado para que  todo producto desarrollado e instalado por el área de sistemas quedase como patrimonio intelectual de la institución. 

     Este caso, a mi entender, ha sido una excepción en mi carrera profesional en el marco del “deber ser” institucional. Esta falta de procedimientos para el área de sistemas tiene múltiples causas que serían tema para otro post. Quien esté interesado en el desarrollo de este tema puede solicitármelo  por el blog y con gusto redactare otro artículo con este punto en particular.      

·         Subestimación de la importancia de un proceso de cierre.

     Los procesos de cierre son importantes cuando fallan, cuando no fallan no son el centro de atención de nadie en la organización. Esto es como el paso de los huracanes: importan cuando suceden o si se presenta un escenario que hace probable que sucedan. De resto, casi nadie revisa los reportes del clima.

·         No hay una división óptima de las funciones del personal y  además hay falta de recursos calificados.

    La dinámica de los procesos diarios y la urgencia por resolver las incidencias que exige la operativa del negocio y a falta de recurso humano disponible para realizar esta tarea de análisis y revisión de los desarrollos de la empresa.

    En mi opinión se necesitan dos grupos de personas en el área de IT. Aquellos que gestionan las soluciones de las incidencias diarias y aquellos que piensan, analizan, revisan y auditan los desarrollos realizados y gestionan los próximos desarrollos. Prácticamente ninguna organización en la que he estado tiene identificadas estas dos funciones.

    Por otra parte hay personas más calificadas para atender incidencias y otras para ocuparse de los procesos de gestión de soluciones de desarrollo importantes a mediano y largo plazo. El ejercicio del pensamiento creativo a veces se confunde con hacer arte, poesía, literatura, etc. Sin embargo, la creatividad es un término mucho más amplio que implica el ejercicio consciente y repetido de las funciones del lado derecho del cerebro. En su libro “El pensamiento Lateral” Edward de Bono expone varios ejercicios prácticos para desarrollar el cerebro derecho. La expansión de estos atributos no se restringe solo al área del arte sino a cualquier disciplina, oficio o tarea.

·         Lemas que hemos practicado culturalmente durante mucho tiempo.

     “Si no está roto no lo arregle”. Esto último se enfrenta a los nuevos conceptos disruptivos presentados en el libro de Robert Kriegel  y Louis Patler titulado: “Si no está roto, rómpalo”. Estos conceptos obsoletos que atentan contra el cambio y la innovación mantienen a las instituciones lejos de la curva de crecimiento puesto que el recurso humano es empleado recurrentemente en resolver los problemas de siempre sin dejar espacio para preparar estrategias operativas alternas de crecimiento a mediano y largo plazo.

    Puedes leer la presentación del libro resumida en slides en este enlace