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.

Sunday, April 1, 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

No comments: