Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

domingo, 1 de abril de 2018

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

jueves, 21 de septiembre de 2017

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

domingo, 21 de mayo de 2017

El Emperador Está Desnudo

                                                                                                                                                                                                       




Desde hace algún tiempo, me he enterado que en varias instalaciones en Suramérica y en parte de América Central (Chile y El Salvador, por ejemplo) persiste el RPG III como lenguaje único para realizar nuevos desarrollos. Esto se entiende cuando en algunos equipos no tienen incorporado el RPG IV,  el RPG Free ni el ILE. Otros no tienen SQL ni DB2.

Sin embargo, hay varios centros informáticos que, teniendo en el Iseries todas las herramientas disponibles para desarrollar sistemas de una forma más sencilla y actualizada, se resisten a abandonar el RPG III en los nuevos desarrollos.

Programadores más jóvenes que conocieron el Iseries y el AS400 programando con RPG IV y que se han ido actualizando con  las siguientes versiones de la plataforma, se encuentran en las entrevistas de trabajo con una pared que les obliga a obedecer a una tecnología más vieja a la cual deben someterse. Esta necesidad de -hacer una carpa en RPG III y quedarse durmiendo allí- anula la posibilidad de realizar desarrollos eficientes y de responder a la necesidad de información de los usuarios y clientes de manera más rápida y oportuna.

En una experiencia personal que tuve  hace un par de años se me pidió convertir un programa de RPG II a RPG IV. Para ello solicité a los mas entrenados programadores de RPG II que me enviaran el algoritmo del programa para desarrollar el modulo en RPG FREE-ILE en base  a dicho algoritmo.

Recibí en Word  tres versiones distintas del programa. Para mi sorpresa ninguna de ellas era un algoritmo. No eran capaces de extraer el concepto detrás de la programación y expresarlo en palabras. Repitieron el mismo programa con las mismas variables en el documento Word que cada uno me envió. Había una notoria incapacidad de extraer el concepto y la funcionalidad de las reglas de negocio formuladas en el código de programación.  Sencillamente fue imposible hacer reingeniería del software. Este es el resultado del empleo del cerebro en las mismas funciones repetitivas sin el interés de adiestrarse ni entrenarse en otro tipo de soluciones: Quedaron encerrados en su propia burbuja.

Desde mi experiencia, la preocupación principal en las instalaciones que tienen Iseries o AS400 se centra en la necesidad de control de los líderes de proyectos y desarrolladores que tienen años trabajando para la misma empresa o tienen años programando de la misma manera.

Se puede observar cómo los programadores más jóvenes que se encuentran aceptando, muy a su pesar,  un trabajo con programación exclusiva en RPG III, siguen enviando su Curriculum a otras empresas para no “quemarse” en un trabajo que no da opciones de desarrollo profesional. Esto ocasiona alta rotación de personal, costos de adiestramiento y costos sin retorno para la empresa.

Los viejos líderes que se resisten al cambio muchas veces tienen en sus manos el “know how” de la operativa de la empresa. Los directivos que no entienden de tecnología y a quienes no les interesa complicar sus vidas con estos detalles, resultan generalmente permisivos con estos líderes de la vieja ola a quienes les conviene convertirse en  indispensables. Estos profesionales que se resisten al cambio no confían en sus propias capacidades para adaptarse a nuevas tecnologías y tienen un miedo aterrador a quedarse sin empleo debido a su edad.  Por estas razones se han dedicado a “hacer una cama” en la organización impidiendo que sus colegas puedan acceder al conocimiento que tan celosamente guardan.

Administrativamente el poder se revierte en contra de los directivos quienes terminan siendo rehenes de  las decisiones caprichosas del único que sabe: “que hay allí adentro”. Estos personajes que son empoderados por la negligente supervisión de sus jefes, se convierten en unos capataces tiránicos que más temprano que tarde ocasionan la renuncia del resto de los desarrolladores. (Recuerda que cuando  cierras la puerta a otros eres tu quien queda encerrado del lado de adentro).

Mi intención con este artículo es motivar a mis colegas  a salir de su burbuja y a adentrarse al cambio. La programación es solo una herramienta operativa que debe obedecer a la dinámica del negocio y a las funcionalidades que se desean implementar. Puede que al principio parezca aterrador cambiar pero si tienen los conceptos claros no importa la plataforma ni el lenguaje: el objetivo se logra.

Si estos profesionales no realizan un esfuerzo de su parte quedaran fuera del mercado laboral así como los dinosaurios que se extinguieron del planeta por no poder adaptarse a los cambios climáticos. Lo mismo puede sucederle a la empresa para quienes trabajan. Lo que pasa por dentro de la empresa termina manifestándose hacia los clientes y hacia el entorno empresarial  en el cual hay que competir.


Sin ninguna duda, adentro y afuera, tarde o temprano se mostrará que el emperador está desnudo.


                                                                                                                                                                                                       

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