miércoles, 10 de diciembre de 2008

Especialista en Desarrollo de Software EAFITENSE! :-D

Como explicar lo indescriptible... la maravillosa sensación de un sueño cumplido!

Hace 4 años me soñe esto, hace solo 2 empecé el camino para lograrlo.

Hoy veo mi nuevo horizonte, más amplio y con mayor claridad, se a donde voy y solo espero que Dios y mis seres amados me acompañen en el camino que me lleve a conseguirlo.

Hoy estoy supremamente feliz, todo lo valió, absolutamente todo lo sacrificado vale esta felicidad, que espero repetir pronto nuevamente, con la bendición de Dios.

martes, 25 de noviembre de 2008

jueves, 23 de octubre de 2008

Cualquier parecido con la realidad, es pura coincidencia

EL REMERO

Cuentan las crónicas que hace tiempo se acordó celebrar anualmente una competición entre los empleados de dos multinacionales, una japonesa y una española. El reto consistía en una carrera de traineras (como las de Oxford y Cambridge), con personal de cada una de las empresas.

El primer año, los japoneses prepararon una embarcación compuesta por un jefe de equipo y 9 remeros, mientras que los españoles dispusieron 9 jefes de equipo y un remero. Después de una "disputada" carrera, Japón gano con 6 horas de ventaja. La Dirección de la empresa española prometió tomar medidas para que no se repitiera semejante resultado.

Al año siguiente, el barco japonés volvió a tener un jefe de equipo y 9 remeros, mientras que el español se formó con cinco jefes de equipo, dos directores técnicos, un vicepresidente ejecutivo, un jefe de personal y el único remero del año anterior. El resultado esta vez fue la victoria japonesa por 11 horas de diferencia.

El Consejo de Administración de la multinacional española se reunió en la planta noble del edificio, con un único punto en el orden del día: cómo ganar a los japoneses el año siguiente. Tras muchas horas de arduas discusiones, se acuerda pasar el tema al Departamento de Investigación y Desarrollo, quien se responsabilizaría de los resultados.

Después de 12 meses de intenso trabajo desarrollando un complejo proyecto, llegó el día de la carrera. De nuevo los japoneses hicieron su equipo tradicional, con un jefe y 9 remeros, pero esta vez los españoles presentaron una embarcación revolucionaria: un jefe de equipo, un director de recursos humanos, dos jefes de proyecto, un auditor externo, un asesor de imagen y tres guardias de seguridad que no quitaban ojo al único remero de siempre, al que se le había suprimido el plus de productividad y los tickets restaurante.

La victoria japonesa fue por 18 horas de ventaja.

Ante tamaño desastre la Dirección de la empresa española tomó medidas drásticas: reestructurar el Departamento de I+D, redefinir a la baja la asignación de los complementos variables y por supuesto: despedir sin derecho a indemnización al remero causante de los continuos ridículos, por su nula implicación con la política y objetivos de la organización.

(Ya no hubo más carreras. El remero despedido fue inmediatamente contratado por la multinacional japonesa. Los directivos españoles se subieron el sueldo un 40 %, pero congelaron, por la crisis del sector, los del resto de trabajadores. Y el Departamento de I+D pasó a llamarse Departamento de I+D+I. En fin .... ).

Fuente: Desconocida (Pero no es mío)

jueves, 9 de octubre de 2008

Sobre la carta García

(Se republica por buena acogida :-P)

Bien, cuando tengo algo que decir y no lo puedo decir tal cual como suena por lo duro que resultaría para las personas implicadas, pues me busco la forma al menos, de quitarme el nudo en la garganta, este post es una de esas formas de hacerlo...

Esta lectura es todo un clásico y es usada por muchos, entre ellos, padres que dicen que los hijos deberian simplemente acatar todas las ordenes sin chistar, que de donde saque eso? de un foro y me parecio bastante absurdo, una cosa es la obediencia y otra diferente la falta de caracter, de criterio o hasta de independencia en algunas ocasiones, pero bien, ese no es la reflexión que pretendo hacer...

Si bien he utilizado alusiones a este texto algunas veces, incluso con mis alumnos, cuando preguntan y preguntan sin siquiera buscar una posible solución, hoy me voy en contra del texto, por que simplemente la posición opuesta, es decir, el no preguntar y asumirlo todo por cuenta propia, es extremadamente peligroso a mi de hecho me gustaria saber que pasaria, si el tipo de la historia hubiera salido de la selva despues de toda su travesía, pero le hubiera entregado de accidente la carta a otra persona que cumplia exactamente con las caracteristicas de la persona a quien iba dirigida en realidad... pues bien, habria sido muy diligente, pero habria fallado... y definitivamente así tampoco es...

Ahí esta mi punto.... pero antes de concluir, para quienes no la conozcan los invito a leer.
http://www.correvedile.com/literatura/parabolas/cartagarcia.html

Definitivamente el no preguntar es contraproducente, pienso que... la determinación y el ser diligente puede parecer una muy buena actitud, pero el definitivamente no saber de que forma es que la otra persona espera ser ayudado, es aun peor, en algunos casos uno preferiría que no intentaran ayudar, si van a ayudar mal... para aumentar el problema algunos lo que asumen es que mejor si ni se meten, ni preguntan, ni se ponen a la orden, o asumen que los demás quieren hacer todo el trabajo por ellos... pero bueno, como me ando llenando de sentimientos, lo dejaré de ese tamaño, creo que mi unica excusa era hacer alusión a la Carta a Garcia con respecto a esa parte que no me gusta, en la que la diligencia en asumir tanto en demasía como en nada, me parecen una mala posición.

Como dice mi abuelita...

"Ningun extremo es bueno mija, ninguno"

domingo, 21 de septiembre de 2008

Sobre la propiedad intelectual del material publicado

Saludos

Jamás en la vida pensé que me tocara hacer semejante aclaración, pero bueno... lo haré solo por si hace falta o alguna otra persona considera que estoy atropeyando la propiedad intelectual de los dueños de las diapositivas y documentos publicados en este blog.

Primero que nada aclaro, que cada cosa publicada en este lugar tiene un solo propósito, publicar cosas que me agradan, que me sorprenden o bien que pueden resultarle de utilidad a alguien, y que casi siempre ya se han publicado en muchos otros lugares.

Casi todo son simples trabajos academicos y jamas pensé aclarar tener que obviamente provienen de muchos lugares en internet y que nunca se han atribuido como propios.

Este un un simple BLOG (http://es.wikipedia.org/wiki/Blog), un sitio personal que para nada pretende suplantar a los autores de dicha información, si no por el contrario expresar bien sea mi opinión o admiración al respecto de algunos trabajos, en algunos casos incluso, valorar dicho esfuerzo y darles el reconocimiento debido.

La información contenida en este blog tiene muchisisimas fuentes, lamento no haber tenido la delicadeza de hacer enfasis en cada una de las frases resaltando de quien son, ademas por que muchas veces las tome de otras diapositivas o trabajos que tampoco lo decian, y como eso no es excusa, de hoy en adelante tendré mucho más cuidado en semejante cosa,...

Este post solo pretende ser unas disculpas o un desagravio para quienes se sientan ofendidos por la publicación de este material, como he colocado en todas las presentaciones de slideshare, si alguien tiene algun problema con que dicha información sea publicada me avisa, y si alguien requiere algun tipo de reconocimiento por algo que hay publicado, me avisa para yo quitarlo, por que aquí no estoy en plan de exaltar a nadie, pienso que el conocimiento no es algo que se pisotee por ser compartido, pero comprendo que existan leyes que protejan hasta quien dice una coma...

Asi que quienes sientan que tengo algo que deber, por favor, me lo hacen saber para evitar cualquier tipo de inconvenientes o comentarios en contra de mi persona, ya que son lios en los que no me interesa verme involucrada, por el momento y mientras sienta que no atento contra nadie continuaré realizando mis escazas publicaciones...

Y el día que tenga que darle reconocimiento a alguien por ello, reitero, prefiero retirarlo de mi blog, nada hay como admirar por querer y no por obligación.

Mis disculpas nuevamente.

miércoles, 17 de septiembre de 2008

No hay ingenieros de sistemas

Este articulo tuvo una respuesta de ACIS que puede leerse aquí.

Colombia está importando ingenieros de la India. Los disponibles son pocos, no saben inglés, no tienen la formación suficiente. Se trata de un enorme problema.


Las nuevas generaciones de colombianos estudian mercadeo, criminalística, gastronomía, decoración de interiores, diseño de modas o hasta producción de cine y televisión. Es una buena tendencia que muestra una diversificación en la oferta académica que no existía hace quince años.

Pero a la vez que aparecen nuevos campos que les interesan a los estudiantes, en el país perdió fuerza un área crucial para el crecimiento y para la competitividad nacionales. Hoy Colombia enfrenta un gran déficit de ingenieros de sistemas. No solo hay problemas de cantidad de profesionales, sino que muchos de ellos trabajan para compañías en el exterior y que otro gran grupo no tiene las calificaciones que se requieren.

El Presidente de InterGrupo, Darío Solórzano, la compañía nacional pionera en la prestación de servicios de consultoría, desarrollo de software e integración de productos y servicios en tecnología, dice que este tema es realmente preocupante para el país, porque usan la tecnología, saben de ella, pero no quieren aprenderla a desarrollar. La manipulan, pero no se interesan por ser parte de ella. "No sé qué es lo que pasa en el país. No sé si es que los muchachos no se están presentando en las universidades para estudiar esta carrera o será que se les hace muy difícil el tema. Esto lo que hace es que exista menos gente preparada, cuando la demanda es muy alta, pues sin duda, ésta es una carrera que siempre necesitará personas que creen, que inventen y que desarrollen cosas nuevas".

Sin duda el interés por los sistemas, junto con la pasión por las ciencias, las matemáticas y la tecnología han bajado drásticamente.

El gerente general de Microsoft Colombia, Jorge Silva, dice que "posiblemente el problema, sumado a las amplias ofertas de profesionalización, también puede estar generado desde los mismos colegios, ya que no existen incentivos, desde esa etapa, para que los jóvenes se interesen por las matemáticas y para que esa materia deje de ser vista como el 'coco' del bachillerato".
El problema de la escasez de estos profesionales no es solo de Colombia. Por la falta de ingenieros que trabajen en IT, Estados Unidos y el resto del mundo también están respirando preocupación frente al tema.

"La necesidad ha aumentado vertiginosamente porque cada decisión, cada paso, cada momento está impactado por la tecnología y todo lo que hay a nuestro alrededor. Un ejemplo claro puede ser el hecho de enviar un mensaje de texto o un e-mail. ¿Cuántas personas están soportando esta operación, cuánta gente participa en algo tan simple como esto? Si no hay gente capacitada vamos a tener serios problemas, cuando se presenten cosas complejas. El propio Bill Gates siempre decía que trajeran gente buena de cualquier parte del mundo porque no había suficiente gente preparada y eso es lo mismo que pasa en Colombia, no hay con quien", argumenta Silva.

Pero aunque el problema sea global, para Colombia este diagnóstico es aterrador. Esto no solo porque la formación de ingenieros es una de las condiciones para conseguir el avance que necesita el país para su crecimiento normal, sino porque además el desarrollo de software fue escogido por el ministerio de Comercio como uno de los ocho sectores que impulsará para convertirlos en áreas de trabajo de clase mundial. Porque lo escogió como una de las apuestas para impulsar el desarrollo competitivo del país.

La preocupación la comparten las universidades y Proexport, que se han reunido para estudiar el asunto.

Encuentran, por ejemplo, que el número de graduados en sistemas en los últimos 3 años cayó 5%. Algo similar ocurre con las matrículas. Este es un fenómeno que se observa más en las universidades privadas que en las públicas.

También identificaron que hay un problema de calificación de las personas. No solo hay menos ingenieros, sino que muchos no cumplen con el perfil que requiere la industria. "En muchas ocasiones la formación está dirigida a entrenar personas de soporte de sistemas de las organizaciones. Eso no le aporta nada a la industria", le dijo un experto en el tema a Dinero.com.

Así mismo, hay dificultades con la actualización de los profesionales y del enfoque de los programas académicos. Con la velocidad que se mueve la tecnología, un profesional que deje de actualizarse dos años pierde vigencia.

Al extranjero

El otro punto del problema, que también resulta definitivo, es que los pocos jóvenes mejor preparados están encontrando formas fáciles de engancharse con empresas extranjeras que les ofrecen una mejor remuneración que las nacionales.

Pero ahora los trabajadores no tienen que emigrar. Los empleadores que necesitan ingenieros de sistemas contratan colombianos pero no se los llevan del país. Los ingenieros trabajan desde sus casas con esquemas de oficina virtual. Ese fenómeno que es también cada vez más frecuente, reduce la oferta de profesionales disponibles para las firmas locales y encarece su remuneración

Para el gerente del Centro de Desarrollo de Software de Open Systems, Benito Pardini, la crisis por falta de gente preparada en Colombia es tan notorio, que ya han tenido que importar algunas veces personas de países como India, con el fin de suplir sus necesidades.

El directivo sostiene que el problema de falta de ingenieros calificados tiende a crecer con el paso del tiempo, además, porque el bilingüismo en el sector es muy bajo y en el mundo de hoy es prácticamente obligatorio el conocimiento de otro idioma.

Concuerda con los analistas en el sentido de que no se trata de estudiar para manejar los departamentos de sistemas de las empresas, sino de ir más allá para poder crear e innovar en el mundo de la tecnología.

En qué vamos

Por ahora Microsoft está trabajando desde una de las bases del problema, que es cerrar la brecha digital existente en el país y trabajar en conjunto con el Sena, para poner este tipo de educación en línea, totalmente gratis y lograr que cada vez más personas se interesen por aprender tecnología. Decenas de empresas en Colombia, también tienen programas específicos de formación, educación y profesionalización para cultivar y atraer a más jóvenes, sin dejar de lado indudablemente a las grandes universidades, a las que también les preocupa el futuro del país.
Algunos en el país, como la Asociación Colombiana de Ingenieros de Sistemas, no han visto el problema. En diálogo con Dinero.com, uno de sus directivos manifestó que encuentran que la situación en el mercado es normal.

Sin embargo, para los empresarios del sector, esta será una de las mayores talanqueras para el desarrollo de la actividad del desarrollo de software desde Colombia.

Para otras entidades como Proexport, una parte – quizás grande – de la solución, está en volver a entusiasmar a los colegiales con los sistemas como ocurrió en los setenta. Tal vez, hay que mostrar más en los últimos años de educación secundaria el potencial de la industria. Para ello servirían, los casos de las empresas nacionales que trabajan en temas divertidos e importantes en el mundo, como la que desarrolla programas de entretenimiento para ser usados en celulares que comercializa una compañía suiza, o la que elabora videojuegos para Xbox.

El tema crucial está planteado y la discusión abierta.

Fuente:
http://www.dinero.com/noticias-on-line/no-ingenieros-sistemas/52476.aspx

miércoles, 10 de septiembre de 2008

Trabajo en Equipo: El taller de herramientas

Ya tarde el carpintero apagó la luz y se retiró a descansar.

De pronto en el taller aconteció una Asamblea entre las herramientas para ajustar diferencias.

El martillo presidió la reunión, pero los participantes le notificaron que tenía que renunciar.

La causa? Hacía demasiado ruido, y además se pasaba todo el tiempo golpeando.

El martillo aceptó la culpa, pero pidió que fuera expulsado el tornillo. Según él,
daba muchas vueltas para conseguir algo.

Ante ese ataque, el tornillo se defendió, aceptó con la condición que también lo hicieran con la lija. Porque era muy áspera en su trato para con los demás, terminando siempre con roces.

La lija acató pero pidió que se echara al serrucho porque siempre cortaba las cosas y no servía para trabajar unido.

El serrucho reconoció su actitud pero dijo que entonces tampoco servía el metro, porque siempre medía a los otros según su propia medida, como si fuese el único perfecto.

Así continuaron debatiendo.

A la mañana siguiente entró el carpintero y comenzó a realizar su trabajo habitual.

Juntó el material
, tomó la madera, utilizó el serrucho, el martillo, el tornillo, la lija y el metro.

Finalmente de la madera rústica hizo un fino mueble.

Cuando la carpintería quedó nuevamente a oscuras y sola, la asamblea reanudó la discusión. Esta vez el serrucho tomó la palabra.

- Señores, quedó demostrado que todos tenemos defectos, pero el carpintero trabaja con nuestras cualidades, con nuestros puntos valiosos. Así que, no pensemos en nuestros puntos débiles y concentrémonos en nuestros valores.

Todos entendieron, que el martillo era fuerte, el tornillo unía, la lija era especial para limar y afinar los defectos de la madera, el serrucho a veces debía cortar para que no se fueran por las ramas y el metro era preciso y exacto para que todos pudieran ser criteriosos y equitativos. Se sintieron así un equipo capaz de producir muebles de calidad y se pusieron a trabajar con alegría.

Esta ilustración nos muestra lo que realmente sucede con los seres humanos. Basta observar y comprobarlo. Cuando una persona busca defectos en otra, la situación se vuelve negativa y tensa, por el contrario, cuando se busca con sinceridad las fortalezas y virtudes del otro, florecen las mejores conquistas humanas.

Es fácil encontrar defectos, cualquiera puede hacerlo, pero encontrar cualidades, eso es de buenas personas!

Dale Carnegie advierte a este respecto "Es fácil encontrar defectos, cualquier tonto puede hacerlo. Y la mayoría de ellos se empeña incesantemente en esto. Pero encontrar cualidades, eso es para los espíritus superiores que son capaces de inspirar todos los éxitos humanos".

sábado, 6 de septiembre de 2008

4 Años en Trebol Software

A hoy cumpliría, o cumplo 4 años en mi querido Trébol Software, ahora Axede.

A hoy, quiero continuar creyendo en lo que creí cuando llegué, y es que lo mejor que te puede pasar en la vida, es estar en el lugar donde de verdad quieres estar.

El balance a hoy es absolutamente positivo, la cantidad de personas que he conocido en el transcurso de estos años, han hecho de mi cada uno a su manera, la persona y el profesional que soy en este momento. A todos aquellos que ya se han ido, a todos aquellos que permanecen, les comparto un poquito de mi enorme felicidad por que hayan hecho parte de mi vida.

Hoy Trébol es para mí, un símbolo de fé, yo quiero seguir creyendo, de alguna forma, quiero seguir haciendolo, aunque no siempre me resulte tan fácil, aunque no todo sea lo que espero.

Y si el objetivo era que llegaramos donde estamos, quiero asumirlo mientras pueda, vivirlo de la mejor manera y dar lo mejor que tengo que de mí. Hoy, me despido de mis cumpleaños en Trébol, ya que de hoy en adelante empezaré a contar nuevos cumpleaños en Axede, sin olvidar jamás que no hubiese lo feliz que fui, lo que estoy siendo y lo feliz que quiero ser, si no hubiese estado en este maravilloso lugar.

Feliz Cumpleaños A mi. :-)

lunes, 18 de agosto de 2008

El Inolvidable Trébol Software

En una más de mis visitas al Blog de Rubi, me encontre con esta belleza de recuerdo... un tiempo de esos para no olvidar...!!! Por ahi estoy, menos de un segundo gracias a Dios!! :-D

sábado, 16 de agosto de 2008

Código de Ética de la Ingeniería de Software

Este es un documento que me encontré por ahi este semestre para mi clase de Ingenieria de Software, la verdad no lo conocia y pienso que debería conocerlo mucha más gente.

Espero les sea útil.

sábado, 26 de julio de 2008

Enseñando Orientación a Objetos con Cuentos Infantiles

Heme aquí de nuevo dando mi clase de Orientación a Objetos, ahora tengo un nuevo reto, mejorar el programa para los nuevos alumnos, procurando que no se me duerman en clase.

Pues bien, buscando, buscando me encontre con que los juegos y los cuentos son una excelente forma de enseñar orientación a objetos, aqui entonces publicaré las diapositivas de mis clases y un cuento como el que justo trabajamos hoy en clase.

Me ha resultado bastante interesante, ver a los chicos analizando el cuento, y al cuento haciendo el papel del dominio del problema, veamos que tal les parece a ustedes.

Cuento: Los Tres Cerditos


Análisis del Cuento
Se identifican los personajes y cosas representativas para el Cuento, Todos son Objetos, pero se toman solo los más representativos dentro del cuento

Los 3 cerditos
El lobo
Las 3 casas

Ahora bien, cuales son las clases en las que se abstraen estas cosas y personajes

Clase: Casa
Atributos: Material, Resistencia, Color, Dueño
Acciones: No tiene

Clase: Cerdo
Atributos: Personalidad, Casa, Instrumento
Acciones: Cantar, Bailar, Correr, Caminar, Huir, Gritar, Reir, Burlar, Escapar, Tocar Instrumento

Clase: Lobo
Atributos: Personalidad
Acciones: Soplar, Gritar, Hablar, Espiar, Empujar, Engañar, Mentir, Fingir, Reir
Ahora para dar un ejemplo de como son los objetos que provienen de estas clases, instanciemos a las cosas y personajes, solo es necesario asignar los valores a los atributos por que las acciones son comunes a todos los objetos que se crean a partir de la clase...

Instancias de la Clase Casa

Objeto: Casa 1
Material: Paja
Resistencia: Baja
Color: Amarillo
Dueño: Cerdo 1

Objeto: Casa 2
Material: Madera
Resistencia: Media
Color: Café
Dueño: Cerdo 2

Objeto: Casa 3
Material: Ladrillo
Resistencia: alta
Color: Roja
Dueño: Cerdo 3

Instancias de la Clase Cerdo

Objeto: Cerdo 1
Personalidad: Alegre
Casa: Casa 1
Instrumento: Flauta

Objeto: Cerdo 2
Personalidad: Alegre
Casa: Casa 2
Instrumento: Violín

Objeto: Cerdo 3
Personalidad: Hermano Menor
Carácter: Serio
Casa: Casa 3
Instrumento: Piano

Instancias de la Clase Lobo
Objeto: Lobo 1
Personalidad: Malo

Este ejercicio puede complicarse mucho más para incentivar el no pensar solo en lo obvio.

Actualizacion Feb/2013: Para terminar el ejercicio, los estudiantes deben realizar un gráfico de clases a través del cual se entienda el cuento. Los demás estudiantes durante la socialización, determinan si el diagrama cuenta el cuento efectivamente.

Para trabajar en línea los ejercicios de diagramas recomiendo http://www.gliffy.com



Fuente de la Métodologia:
http://lsm.dei.uc.pt/ribie/docfiles/txt20034242202146.PDF

domingo, 15 de junio de 2008

Antipatrones

Esto esta demasiado gracioso, me es inevitable no publicarlo. Disfrutenlo.

Antipatrón de DiseñoDe Wikipedia, la enciclopedia libre

Un antipatrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema.
Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.
El término se origina inspirado en el libro Design Patterns, escrito por un grupo de autores conocido como Gang of Four, y que aglutina un conjunto de buenas soluciones de programación.
Los autores bautizaron dichas soluciones con el nombre de "patrones de diseño" por analogía con el mismo término, usado en arquitectura. El libro Anti-Patterns (de William Brown, Raphael Malveau, Skip McCormick y Tom Mowbray, junto con la más reciente incorporación de Scott Thomas) describe los antipatrones como la contrapartida natural al estudio de los patrones de diseño. El estudio formal de errores que se repiten permite reconocer y reconducir los elementos involucrados hacia una mejor solución. Los antipatrones no se mencionan en el libro original de Design Patterns, puesto que éste es anterior.
Los antipatrones se consideran una parte importante de una buena práctica de programación. Es decir, un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible, dentro del ciclo del vida del software.
El concepto de antipatrón se puede aplicar a la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.
Algunos antipatrones de desarrollo de software

Antipatrones de gestión
Responsable ausente (absentee manager): Situación en la que el principal responsable o coordinador se ausenta o permanece en paradero desconocido o no localizable durante importantes períodos de tiempo.
Todo lo que tienes es un martillo (all you have is a hammer): Gestión gris y plana, incapaz de tratar a los subordinados de manera personalizada y acorde con sus necesidades particulares.
Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de "éxito a cualquier precio".
Dos caras (doppelganger): Coordinador o compañero que en un determinado momento puede ser agradable y de trato fácil, pero igualmente puede volverse irracional y despiadado de modo inesperado.
Rodeos improductivos (fruitless hoops): Gestor o coordinador que solicita grandes cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una decisión.
Niñito de oro (golden child): Situación en la que ciertas responsabilidades, oportunidades, reconocimientos o recompensas van a parar a un determinado miembro del equipo como consecuencia de una relación personal o en clara contradicción con su rendimiento real.
Pollo sin cabeza (headless chicken): Se aplica al gestor, coordinador o responsable que vive en una permanente situación de pánico y medidas desesperadas.
Líder pero no gestor (leader not manager): Un buen líder no tiene por qué ser necesariamente un buen gestor, coordinador o responsable.
Gestión clonada (managerial cloning): Situación en la que los coordinadores o gestores son contratados e instruidos para actuar y trabajar todos del mismo modo, a imagen y semejanza de sus propios jefes.
Gestor pero no líder (manager not leader): Un coordinador brillante en sus deberes administrativos y de gestión, pero que carece de habilidades de liderazgo.
Abuso de la métrica (metric abuse): Utilización manipuladora o incompetente de las medidas y las métricas.
Sr. Amigo de todos (Mr. Nice Guy): Se aplica al gestor que pretende convertirse en amigo de todos.
Héroe del proletariado (proletariat hero): El "empleado para todo" que siempre es puesto como ejemplo ante sus compañeros, pero que realmente es la excusa perfecta para demandas crecientes y constantes incrementos de expectativas.
Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresión profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y madurez.
Ejecutivo sin carácter (spineless executive): Gestor, coordinador o responsable que no tiene el coraje de enfrentarse a las situaciones, asumir las responsabilidades de los errores, o dar la cara por sus subordinados.
Caballero de tres cabezas (three-headed knight): Gestor indeciso, poco firme, dubitativo.
Arma definitiva (ultimate weapon): Individuos altamente competentes en los que la organización o sus compañeros confían tanto que se convierten en el canal por el que todo pasa.
Recién llegado (warm body): Trabajador que apenas cubre las expectativas mínimas y por tanto circula de proyecto en proyecto o de equipo en equipo.

Antipatrones de gestión de proyectos
Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad antes de que esté implementada.
Mala gestión (bad management): Gestionar un proyecto sin tener suficientes conocimientos sobre la materia.
Software inflado (software bloat): Permitir que las sucesivas versiones de un sistema exijan cada vez más recursos.

Antipatrones generales de diseño de software
Base de datos como comunicador de procesos (database as an IPC): Usar una base de datos para comunicar procesos en uno o varios ordenadores, cuando la comunicación entre procesos directa es más adecuada.
Blob: Véase Objeto todopoderoso.
BOMQ (Batch Over MQ): Abuso en el empleo de integración basada en mensajes en tiempo real para transferencias esporádicas de gran tamaño en segundo plano.
Botón mágico (magic pushbutton): Tender, desarrollando interfaces, a programar la lógica de negocio en los métodos de interacción, implementando los resultados de las acciones del usuario en términos no suficientemente abstractos.
Carrera de obstáculos (race hazard): Incapacidad de prever las consecuencias de diferentes sucesiones de eventos.
Entrada chapuza (input kludge): No especificar e implementar el manejo de entradas inválidas.
Fábrica de combustible (gas factory): Diseñar de manera innecesariamente compleja.
Gran bola de lodo (big ball of mud): Construir un sistema sin estructura definida.
Interfaz inflada (interface bloat): Pretender que una interfaz sea tan potente que resulta extremadamente difícil de implementar.
Inversión de abstracción (abstraction inversion): No exponer las funcionalidades implementadas que los usuarios necesitan, forzando a que se reimplementen a más alto nivel.
Punto de vista ambiguo (ambiguous viewpoint): Presentar un modelo sin concretar ciertos aspectos, postergando así decisiones conflictivas.
Re-dependencia (re-coupling): Introducir dependencias innecesarias entre objetos.
Sistema de cañerías de calefacción (stovepipe system): Construir un sistema difícilmente mantenible, ensamblando componentes poco relacionados.

Antipatrones de diseño orientado a objetos
Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado.
BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella.
Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que añade modificación alguna.
Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito.
Modelo de dominio anémico (anemic domain model): Usar un modelo del dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado.
Objeto sumidero (object cesspool): Reusar objetos no adecuados realmente para el fin que se persigue.
Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una única parte del diseño (clase).
Poltergeist: Emplear objetos cuyo único propósito es pasar la información a terceros objetos.
Problema del círculo-elipse (circle-ellipse problem): Crear variables de tipo pensando en los valores de posibles subtipos.
Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación.
Singletonitis: Abuso de la utilización del patrón singleton.
YAFL (yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

Antipatrones de programación
Acción a distancia (action at a distance): Provocar la interacción no prevista de componentes muy distantes de un sistema.
Acumular y arrancar (accumulate and fire): Establecer una colección de variables globales para ser usadas por un conjunto de subrutinas.
Ancla del barco (boat anchor): Retener partes del sistema que ya no tienen utilidad.
Bucle activo (busy spin): Utilizar espera activa cuando existen alternativas.
Código duro (hard code): Hacer supuestos sobre el entorno del sistema en demasiados lugares de la implementación.
Complejidad no indispensable (accidental complexity): Dotar de complejidad innecesaria a una solución.
Código espagueti (spaghetti code): Construir sistemas cuya estructura es difícilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación.
Código ravioli (ravioli code): Construir sistemas con multitud de objetos muy débilmente conectados.
Comprobación de tipos en lugar de interfaz (checking type instead of interface): Comprobar que un objeto es de un tipo concreto cuando lo único que se necesita es verificar si cumple un contrato determinado.
Confianza ciega (blind faith): Descuidar la comprobación de los resultados que produce una subrutina, o bien de la efectividad de un parche o solución a un problema.
Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar.
Fallo de caché (caching failure): Olvidar restablecer una marca de error cuando éste ya ha sido tratado.
Lava seca (lava flow): Entregar un componente de software antes de estar completo o completamente probado, de manera que la situación derive en el mantenimiento de sus características, buenas o malas (que tienden a quedarse fijas, como un río de lava que se seca por fuera).
Lógica super-booleana (superboolean logic): Emplear comparaciones o abstracciones de la lógica booleana innecesarias.
Manejo de excepciones (exception handling): Emplear el mecanismo de manejo de excepciones del lenguaje para implementar la lógica general del programa.
Manejo de excepciones inútil (useless exception handling): Introducir condiciones para evitar que se produzcan excepciones en tiempo de ejecución, pero lanzar manualmente una excepción si dicha condición falla.
Momento del código (code momentum) : Establecer demasiadas restricciones sobre una parte del sistema debido a la asunción de muchas de sus propiedades desde otros lugares del propio sistema.
Números mágicos (magic numbers): Incluir en los algoritmos números concretos sin explicación aparente.
Ocultación de errores (error hiding): Capturar un error antes de que se muestre al usuario, y reemplazarlo por un mensaje sin importancia o ningún mensaje en absoluto.
Packratting: Consumir memoria en exceso debido a no liberar objetos reservados dinámicamente una vez ya han dejado de ser necesarios.
Programación por excepción (coding by exception): Añadir trozos de código para tratar casos especiales a medida que se identifican.
Secuencia de bucle por casos (Loop-switch sequence): Programar un conjunto de pasos secuenciales usando un bucle en combinación con una estructura de control por casos.
Secuencias mágicas (magic strings): Incluir cadenas de caracteres determinadas en el código fuente para hacer comparaciones, como tipos de eventos, etc.

Antipatrones metodológicos
Bala de plata (silver bullet): Asumir que nuestra solución técnica favorita puede resolver un problema mucho mayor.
Desarrollo conducido por las pruebas (tester driven development): Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de los informes de errores.
Desfactorización (de-factoring): Eliminar funcionalidad y reemplazarla con documentación.
Factor de improbabilidad (improbability factor): Asumir que es improbable que un error conocido cause verdaderos problemas.
Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.
Optimización prematura (premature optimization): Realizar optimizaciones sin disponer de la información suficiente para hacerlo con garantías, sacrificando decisiones de diseño.
Programación de copiar y pegar (copy and paste programming): Programar copiando y modificando código existente en lugar de crear soluciones genéricas.
Programación por permutación (programming by permutation): Tratar de aproximarse a una solución modificando el código una y otra vez para ver si acaba por funcionar.
Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar los mismos problemas.
Reinventar la rueda cuadrada (reinventing the square wheel): Crear una solución pobre cuando ya existe una buena.

Antipatrones de gestión de la configuración
Conflicto de extensiones (extension conflict): Problemas con diferentes extensiones que tratan de gestionar las mismas partes del sistema (específico de Mac OS).
Infierno de dependencias (dependency hell): Escenario de problemas producidos por las versiones de otros productos que se necesitan para hacer funcionar un tercero.
Infierno DLL (DLL hell): Problemas con las versiones, disponibilidad o proliferación de DLLs (específico de Microsoft Windows)
Infierno JAR (JAR hell): Problemas con diferentes versiones o ubicaciones de ficheros JAR, típicamente causados por la falta de comprensión del modelo de carga de clases.

Algunos antipatrones organizacionales
Avance del alcance (scope creep): Permitir que el alcance de un proyecto crezca sin el control adecuado.
Bloqueo del vendedor (vendor lock-in): Construir un sistema que dependa en exceso de un componente proporcionado por un tercero.
Diseño de comité (design by committee): Contar con muchas opiniones sobre un diseño, pero adolecer de falta de una visión unificada.
Escalada del compromiso (escalation of commitment): No ser capaz de revocar una decisión a la vista de que no ha sido acertada.
Funcionalitis acechante (creeping featuritis): Añadir nuevas funcionalidades al sistema en detrimento de su calidad.
Gestión basada en números (management by numbers): Prestar demasiada atención a criterios de gestión cuantitativos, cuando no son esenciales o difíciles de cumplir.
Gestión champiñón (mushroom management): Tratar a los empleados sin miramientos, sin informarles de las decisiones que les afectan (manteniéndolos cubiertos y en la oscuridad, como los champiñones).
Gestión por que lo digo yo (management by perkele): Aplicar una gestión autoritaria con tolerancia nula ante las disensiones.
Migración de coste (cost migration): Trasladar los gastos de un proyecto a un departamento o socio de negocio vulnerable.
Obsolescencia continua (continuous obsolescence): Destinar desproporcionados esfuerzos a adaptar un sistema a nuevos entornos.
Organización de cuerda de violín (violin string organization): Mantener una organización afinada y en buen estado, pero sin ninguna flexibilidad.
Parálisis del análisis (analysis paralysis): Dedicar esfuerzos desproporcionados a la fase de análisis de un proyecto, eternizando el proceso de diseño iterando sobre la búsqueda de mejores soluciones o variantes.
Peligro moral (moral hazard): Aislar a quien ha tomado una decisión a raíz de las consecuencias de la misma.
Sistema de cañerías (stovepipe): Tener una organización estructurada de manera que favorece el flujo de información vertical, pero inhibe la comunicación horizontal.
Te lo dije (I told you so): Permitir que la atención se centre en que la desoída advertencia de un experto se ha demostrado justificada.
Vaca del dinero (cash cow): Pecar de autocomplacencia frente a nuevos productos por disponer de un producto legacy muy lucrativo.

Relación alfabética de otros antipatrones
Arrojar al otro lado del muro (thrown over the wall).
Billete lobo (wolf ticket): Declarar compatibilidad con un estandar cuando esta no existe.
Blowhard Jamboree.
Cadena sin longitud (string without length).
Cajas de diálogos en cascada (cascading dialog boxes).
Callejón sin salida (dead end): Encontrar un problema que impide continuar trabajando, pero la dirección no permite corregir el problema. El equipo queda estancado.
Caminar por un campo de minas (walking through a mine field): Trabajar con un componente pobremente probado (usualmente inestable), y por tanto poco confiable.
Chivo expiatorio (scape goat).
Codificación brutal: Presionar a los programadores a trabajar sobre una arquitectura sin diseñar y sin requisitos evidentes.
Comité designado (appointed team): Crear un comité o grupo de trabajo para resolver un problema y no ocuparse de lograr que el grupo funcione.
Compensación equitativa (egalitarian compensation): Compensar al personal por el trabajo individual hecho.
Contenedor mágico (magic container).
Cuerpos tibios (warm bodies).
Culto al carguero (cargo cult).
Cultura del miedo (fear culture)): Ambiente en el que cada empleado tiene miedo de mostrar el resultado de su trabajo por miedo a ser despedido por tener errores.
Cultura del héroe (hero culture).
Decisión aritmética (decision by arithmetic).
Desarrollo distribuido geográficamente (geographically distributed development).
Desarrollo marcado por las herramientas (autogenerated stovepipe): Preferir una solución generada automáticamente sobre la mejor solución.
Descomposición funcional (functional decomposition): Traducir un programa de un lenguaje estructurado a uno OO usando una sola clase y muchos métodos privados.
Diseñar por diseñar (design for the sake of design): Realizar un diseño excesivamente complejo sin necesidad real.
Diseño con arquitectura impuesta (architecture as requirement): Imponer que el diseño considere, obligatoriamente, el uso de herramientas o métodos no necesariamente idóneos.
Diseño de fregadero (kitchen sink design).
Diseñadores empíricos (architects don't code): Incapacidad del grupo de diseño para evaluar la complejidad del objeto diseñado.
El correo electrónico es peligroso (email is dangerous): Peligro de olvidar que detrás de los emails recibidos hay personas de carne y hueso.
El gestor controla el proceso (manager controls process).
El traje nuevo del emperador (emperor's new clothes): Temor a señalar los defectos de un producto o proceso que un gerente o manager cree que funciona bien.
El viejo gran duque de York (the grand old Duke of York).
Ellos me entendieron (they understood me): Explicar a programadores o diseñadores junior lo que se espera de ellos muy brevemente, y asumir que entendieron lo que se les pidió.
Embudo de excepciones (exception funnel): Atrapar una excepción e ignorarla, sin reportarlo.
Entrenar al entrenador (train the trainer).
Es un problema de operadores (it is an operator problem).
Esconder las armas (cover your assets).
Falsa economía (false economy): Permitir que los recortes de presupuesto afecten la eficiencia de los trabajadores (las pérdidas terminan siendo mayores que lo ahorrado).
Falso punto final subrogado (false surrogate endpoint).
Fechas en punto flotante (floating point times).
Haz tu propia base de datos (roll your own database).
Ingenieros compatibles e intercambiables (plug compatible interchangeable engineers).
Introducción de dificultad por analogía (analogy breakdown): Diseñar por analogía con problemas resueltos, posiblemente introduciendo dificultades no inherentes al problema, o descuidando dificultades propias del nuevo caso que se maneja.
Invocar a constructores con nulos (passing nulls to constructors).
La disputa familiar (the feud).
La experiencia mata el diseño (architecture by implication): Descuidar el diseño por confiar excesivamente en la experiencia previa.
Los clientes son tontos (customers are idiots): Pensar que uno sabe más que el cliente, y por tanto no es necesaria una investigación con el cliente.
Maníaco del control (control freak).
Máquina de Rube Goldberg (Rube Goldberg machine): Realizar implementaciones muy complejas para tareas sencillas.
Matar al mensajero (shoot the messenger).
Matar dos pájaros de un tiro (kill two birds with one stone).
Matrimonio sumarísimo (sumo marriage).
Mazorca de maíz (corn cob).
Mecanismos de recompensa discordantes (discordant reward mechanisms).
Mezclador de software (software merger).
Miedo al éxito (fear of success): Permitir que las únicas razones de que los trabajos no se completen sean de índole social.
Moneda en punto flotante (floating point currency): Utilizar una representación en punto flotante para valores que representan dinero, lo que puede provocar pérdida de precisión.
Morir planificando (death by planning).
Nacionalismo (national ism).
Navaja suiza (swiss army knife): Intentar crear un producto que solucione varios problemas poco relacionados entre sí.
No especificar (specify nothing).
No inventado aquí (not invented here).
Otra reunión más lo resolverá (yet another meeting will solve it).
Otro programador más (yet another programmer).
Presunto heredero (heir apparent).
Proceso a prueba de idiotas (idiot proof process).
Programador discordante (net negative producing programmer).
Proyecto del día de la marmota (ground hog day project): Discutir los mismos temas en todas las reuniones, sólo para llegar a la conclusión de que "algo debe hacerse".
Prueba incompleta (asynchronous unit testing): Descuidar en la etapa de pruebas, algunas unidades en todos los casos, o todas las unidades en algunos casos.
Quiero estimaciones ahora (give me estimates now): Dar estimaciones sin tener suficientes datos para hacerlas.
Requisitos esparcidos por la pared (requirements tossed over the wall).
Requisitos ocultos (Hidden requirements).
Si funciona, no lo toques (if it is working don't change).
Somos tontos (we are idiots): Pensar que el conocimiento interno del problema es peligroso (por riesgo de que sea pobre o equivocado), y pedir validación del cliente para cada característica o decisión mayor.
Tarjetas CRCI (CRCI cards).
Tormenta de reproches (blame storming).
Torre de vudú (tower of voodoo).
Trampa para osos (bear trap): Invertir mucho en una herramienta poco adaptada o factible, de manera que después es imposible deshacerse de ella.
Único punto de salida de función (single function exit point).
Valor por defecto indefinido (zero means null): Escoger un valor arbitrario para representar la indefinición, sin garantizar que ese valor no puede realmente ocurrir.
Violencia intelectual (intellectual violence).

Enlaces externos
C2.com (antipatrones) Portland Pattern Repository's Wiki

sábado, 14 de junio de 2008

Una historia sobre el cambio, Trébol Software

(Linda imagen no?)

Se que para más de a uno de mis colegas, compañeros y ex compañeros de trabajo, esta imagen representa buenos recuerdos y grandes cambios...

últimamente me ha dado por recordar y pensar en como fue todo esto, e intentar imitar un post que vi en el Blog de Rubi, donde habla de su historia en Trébol.

Pues bueno, esta es mi historia...

Yo hablaré de esto a grandes rasgos, o lo intentaré, por que me agobian los detalles. Igual estoy en una posición no compartida por muchos, pero al fin, una a la que ellos mismos me llevaron cuando me pidieron ser positiva, y confiar en todo saldría bien, y eso hago... aunque quienes me lo enseñaron, ya no lo sean...

Llegue a Trébol un 6 de Septiembre de 2004, casi recuerdo la sensación que tenia, iba a ese lugar feliz, dichosa de alcanzar lo que siempre soñé desde que adquirí conciencia de para qué estudiaba Ingeniería Informática.

Pues bien, todo empezó desde que me llamaron a mi entrevista de trabajo, no sabia quien era la persona que me hablaba en ese momento, solo sé que colgué el teléfono y le dije a mi mejor amiga, Dios mio! casi sale miel por la bocina... quizá me sentía así debido al ambiente hostil al que me hallaba enfrentada en mi primer empleo, sin embargo, saber que a pesar de que mi perfil no cumplía con la mitad de los requisitos que solicitaban, yo tenia la oportunidad de ir obtener lo que quería, me hacia muy feliz y me hacia ver todo de maravilla...

Recuerdo lo difícil que fue ir a presentar las entrevistas, sin permiso de mi jefe, con un miedo terrible... pero se hizo, las pruebas no fueron muy difíciles y el rostro mas frió que encontré es algo que me reservo debido a que sigo viéndolo a veces por los corredores, y a que lo veré aun mas a menudo muy pronto, pero como todo no podía ser perfecto eso a mi no me importaba, todo me parecía lindo, la gente una maravilla...

Un día me llamaron a mi celular, salí de la oficina a contestar la llamada y me dijeron, Bienvenida, queremos comunicarte que desde ahora haces parte de la familia Trébol Software, creo que se percibió que me quede en blanco, mi sorpresa fue mucha, puesto que a pesar de que tenia muchos deseos de pasar, pensé que mi perfil no me lo permitiría, ocho meses de experiencia no eran nada, pero yo ya tenia lo que quería. Lo mas duro fue decirle a mi jefe de ese entonces, después de ser la niña de sus ojos, pase a ser nadie, fueron los 15 días mas difíciles que he pasado, hasta que finalmente me fui... y deje a mi mejor amiga allí, con la promesa de llevarla conmigo un día... cosa que es de otra historia, pero que finalmente, ocurrió tal cual.

El día que lleve los papeles a Trébol fui recibida con un abrazo, un abrazo enorme de Bienvenida, para alguien que no conocían. Yo que poco estaba acostumbrada a ese tipo de afecto en el ámbito empresarial, me sorprendía, con cada cosa de esas que veía y me decía, Diosito, este es el lugar correcto. Nada más pensaba! Era demasiado feliz para pensar en otra cosa.

Después de unos días de leer la intranet como buena niña nueva, me asignaron a mi proyecto y oh sorpresa, iba para EPM, de repente tuve un dejavú, hacia no menos de 4 o 5 meses quizá, le había pedido a Dios pasando cerca al Edificio Inteligente, que me permitiera estar ahí dentro un día y saber que se sentía estar allí. Pues bien, Dios tiene sus propios caminos y además es bastante efectivo... así fue como dos de mis mayores deseos terminaron cumplidos.

Cuando llegué a EPM, me dí cuenta de la razón por la que termine en Trébol, la niña a la que iba a reemplazar estaba en embarazo y apunto de salir a su licencia y a usar un montón de vacaciones que tenia sin tomar. En fin, sea como fuere yo estaba ahí y haría todo lo posible por pasar mi periodo de prueba y hacer que me renovaran mi contrato que era de apenas 6 meses.

Bien, resulta que también llegue ahí por un "karma" que conserve por un tiempo, la Inteligencia de Negocios. Ese tema nunca fue de mis cosas favoritas en la universidad, recuerdo que fue a la unica materia en la que puedo decir, no con orgullo, pero puedo decir, que no asistí, si no para hacer talleres y exámenes, finalmente la pase en mas de 4 y me daba igual, por que jamás pensaba dedicarme a eso. Pues bien, mi primer trabajo, antes de Trébol, resulto ser un montón de cosas, pero entre ese montón estaba Inteligencia de Negocios, y Trebol vio en mi justo eso, por lo tanto termine trabajando en EPM en justo eso.

Aprendí montones de cosas, hasta dicte charlas técnicas en Trébol, aprendí a querer el dichoso tema, una vez casi me resigne a hacer eso por el resto de mi vida, pero gracias a Dios, Él no estuvo de acuerdo y no permitió que me quedara haciéndolo.

Bueno, en EPM, pase por Sistemas de información, en ALFA, también por EPM Aguas tambien en ALFA, y cuando después de 2.5 años se acabó el contrato y pensé que por fin era mi oportunidad de volver a casa (A la sede) y saber de verdad que era trabajar en una empresa de desarrollo; no mas Inteligencia de Negocios, muy linda, muy agradable, muy interesante, pero definitivamente no hay nada como hacer lo que uno quiere hacer. Pues bien, dirán ustedes, por fin lo logró. Pues no!... me enviaron a UNE, a seguir con el mismo proyecto, ALFA, después de que UNE hizo casa aparte.

Pasé por montones de cosas allí, mas quizá que las que pase en 2.5 años en EPM. Pero también conocí gente maravillosa y aprendí mucho, demasiado, en un año y algo que permanecí allí, cambio mi vida y mi forma de verla, mi forma de ser y un montón de cosas, recibí mucha fuerza, mucha ayuda, muchos consejos, y aprendí hasta a reírme de mi misma, cosa que no sabía hacer en ese momento.

Finalmente después de mucho tiempo de paciencia, algunas que otras lagrimas y desazón, me permitieron desarrollar aplicaciones después de unos meses en UNE, con el anunciado fracaso de mi proyecto del que tantas veces alerte, y que nunca me escucharon.

Para ese entonces, yo había estudiado por mi cuenta, y hasta profe me había hecho, de algo que nunca había trabajado de verdad, al menos no en un proyecto serio y para mi empresa.

Seguí aprendiendo, por fin disfrutando al máximo de las cosas que siempre quise hacer... un día, empezó el rumor, la sensacion sombría de que algo malo pasaba, y un correo que decía, reunión general... de improvisto, al día siguiente, cosa que jamas había pasado....

Era creo Julio de 2007, la noticia de que una nueva empresa nos complementaria, parecía un tanto confusa, nadie diga nada, todo es secreto, ... cuando por fin se hizo publico, también terminamos por entender o mejor, aceptar... que nos habían vendido..., que fuerte suena, pero así es, nos vendieron y nos compraron, la otra empresa, con mas dinero que la nuestra, había adquirido el 100% de Trébol... la confusión reinaba en el ambiente, la tristeza y la desazón son algo de lo que no creo que algunos sean consientes hoy en día...

La idea que quisieron transmitir de que las dos empresas seguirían adelante uniendo esfuerzos no termina aun de ser del todo clara... y cada vez tiene menos esperanzas de serlo.

Como les dije alguna vez, es como si hoy alguien llegara y me dijera, este no es tu papá y tu mamá, ahora tienes estos otros, que tienen dinero y a quienes no conoces...

No importa lo que digan, es difícil, fue difícil y sigue siendo difícil... la bajas por la falta de adaptación al cambio no terminan, si bien como ellos dijeron, ellos no pensaban deshacerse de nadie, cosa que tampoco fue del todo cierta, pues simplemente los cambios terminaron por afectar el corazón, la cabeza, por hacer daño a los sentimientos, al entusiasmo.... habíamos algunos que solo permanecíamos con paciencia por el enorme valor que le encontrábamos a Trébol... a pesar de las no siempre positivas condiciones y aunque los nuevos jefes dicen que saben y entienden lo que uno siente, yo sigo teniendo mis dudas al respecto... en realidad solo yo se lo que siento, y si ese es solo mi caso, hay casi 200 casos mas de esos, o hubieron, por que ya no somos los que estábamos....

Despedir a Doña Sandra, la primera de las bajas, fue el primer golpe a la moral, verla llorar y tener que llorar sin poder contenerse, ver a todos llorar de esa forma... es algo que creo que no termina de sanar... la resignación no siempre es tener nuevas fuerzas, a veces solo es resignarse...

Con el tiempo, también el jefe se fue, "H" el esposo de Doña Sandra, con el moría la admirable historia de dos novios que hicieron como Tesis un Proyecto de Empresa que dio enormes alegrías y triunfos...

Lamento no estar de acuerdo con lo que el nuevo jefe dice, para mi, para muchos, es como haberse ido a una nueva empresa, sin haberla buscado, del espíritu de Trébol, no queda mucho mas que un tanto de esperanza en algunas personas y muros que traen recuerdos... una razón social que no termina de cambiarse,... y algunos rezagos de papelería... quedamos aun bastantes, pero cada vez son menos las caras viejas y mas las caras nuevas,... yo no quiero pensar en si eso trae o no consecuencias para la organización,... con los anteriores post que les he colocado, sabrán que pienso acerca de eso...

El duelo fue bastante difícil,... tardo mucho tiempo, al principio estuve muy negativa, como les dije a mis compañeros de la especialización una vez que hablábamos del tema cuando todo era novedad para los extraños y curiosos, la actitud de la gente en cierto momento era como, tener un pie dentro y un pie fuera, listo para salir corriendo si algo malo pasaba, por que nadie esperaba nada bueno, y ahora... me parece a mi, que aunque muchos hicimos nuestro duelo y afrontamos el nuevo cambio, los directivos no terminan de notar que la actitud de esperar que pasa malo para salir corriendo, se adueñado de casi todos los espacios...

Para este momento mi catarsis esta lista, en AXEDE el nombre que tenemos ahora y que tan difícil fue sentir y aceptar, tuve la oportunidad de estar en I + D, hoy cumplo exactamente 2 mesesitos de eso, y eso me dio esperanza y aliento y nueva energía, no diré que siento el mismo amor que sentía por Trébol, si bien siento la responsabilidad necesaria para hacer mi trabajo lo mejor que puedo, siento que es como cuando tienes un novio nuevo, la relación al principio siempre es difícil, a veces uno recuerda lo que tuvo antes, aunque siempre quiere mirar al frente a continuar con lo que hay, pero es seguro que es difícil saber en que momento uno sabe que quiere a como quería, aunque a veces (como esta vez) uno sabe que eso que sintió, jamás volverá a sentirlo.... pues eso pasa, aunque de mi parte siento que la nueva organización hace o intenta hacer algunos esfuerzos por motivarnos, si bien sus sentimientos no son los mismos que sentíamos en Trébol, o al menos no los vemos de esa forma... pues hombre, al menos los están haciendo o intentando, supongo... y quizá muchas veces hemos mirado mas lo malo que el darles el beneficio de la duda, pero la verdad ha sido muy difícil pasar de ser los protagonistas a ser los nuevos de la empresa,...

Y es que así se siente a veces, la gente de la empresa que nos compro es la gente que de verdad lleva años, nosotros a pesar de que tenemos la continuidad, nos sentimos como los nuevos,... es extraño,... es como si no terminará de clavarse en el alma ese sentido de saber que haces parte de esto... si bien así se siente mientras luchas por algo, es como si obtuvieras triunfos para alguien que no eres tu... cosa que era diferente antes... cuando te sentías parte de algo...

Cuando Trébol era Trébol, cuando yo orgullosamente decía, trabajo en una de las mejores compañías de software de Medellín, muchos decían que con el tiempo había cambiado, no me imagino como seria de maravillosa antes de que yo llegara... pero cuentan muchas historias.... y este año, cuando cumplamos años.... o cumpliéramos... pues... ya no veremos la fotos de la casa blanca, y no veremos a los que se fueron.... y no brindaremos en casa por eso,... umm.... que difícil, ya decía que los detalles me agobian...

Pero es que por mas que ahora piensen que lo luchan, no lo están logrando, no sé si con la gente de la empresa anterior que tan acostumbrados parecen a los cambios, yo solo se que con la gente de la empresa que compraron, no están logrando generar el sentido de pertenencia que había antes, por el contrario, a pesar de que a veces yo intento inyectármelo asi sea de forma ficticia, me encuentro con frases del tipo, "No haré nada por esta empresa, lo haré por la próxima a donde vaya..." y eso me derrumba de cierta forma, escuchar en personas que daban mucho por la empresa que eramos, una actitud así, que si bien puede tener todas las justificaciones que quieran, es dura, es una expresión dura y no es buena bajo ningún punto de vista... uno debe dar lo que debe, y si esta en un lugar donde siente que no lo va a dar, busca otro...

Ha sido difícil, se debe notar hasta en lo que escribo, antes hablaba con profundo amor, ahora hablo con profunda racionalidad,... es como haberse atravesado un camino espinoso y haber dejado a muchas personas que adorabas y que hubieras deseado siguieran alli... pero que no están, y cada día siguen desapareciendo...

Jamas entendí si cuando hace unos años "H" dijo que quería que Trébol fuera una gran empresa, se refería a que de verdad desapareciera.... no sé si fue que no le entendimos... y no estamos muchos, del todo seguros, que esto que pasa, fuera lo que esperaba el que pasará... en unos años, Trébol ya no existirá mas que como un recuerdo... y eso no es llegar lejos, eso es desaparecer... igual que cuando la gente muere y se queda en el recuerdo... es meramente eso... por que alguien que logró algo tan maravilloso habría de querer eso? No logro entenderlo... quizá muchos tampoco lo logran, por que ademas una cosa es que te digan que tus papás son otros, y que la decisión de con quien te quedas es tuya, y otra diferente es que tus papás te lleven a donde otros y te dejen allí... creo que uno toda la vida se preguntaría que pasó...

Que pasó con esto por ejemplo?


Hoy no sé que significa futuro..., pero recuerdo muy bien que cuando escalé mi Everest en el Taller Outdoor me sentí plenamente comprometida con el futuro de Trébol...

Bueno... esta fue la historia de cambio, seguiremos cambiando todos los días, finalmente ni siquiera tenemos un año siendo AXEDE, muchas cosas buenas pasan, sobre todo desde el punto de vista de alguien que jamas haya conocido Trébol, muchas cosas no tan buenas pasan, desde el punto de vista de alguien que estuvo allí de verdad, con el corazón...

Quizá los que permanecemos solo guardamos la esperanza de que pase el temblor haber que queda,... quizá algunos pueden haberse resignado.... a otros quizá, ya no les importe,... y otros quizá lo hayan tomado mejor que todo esto... pero para todos, solo el tiempo dirá, quienes tomaron la decisión correcta, si los que se fueron o los que permanecieron...

Siempre pensé que escribiría la Historia de Trébol en las páginas de mi vida, lo que no tenia presupuestado es que la tuviera que escribir de esta forma...

Por el momento, solo queda esperar y hacer las cosas lo mejor posible... o lo mejor que nos dejen hacerlas...

Bueno y para los que aun piensan que la noticia es nueva. Aquí esta, de todas formas gracias por sus condolencias, muy amables, estamos bien gracias.

08/06/2007
e-Business Distribution integra a Trébol Software

Esta es la primera negociación que realiza e-BD luego de que Tribeca Partners adquiriera el 60% de sus acciones.

Bogotá.- Con el ánimo de ofrecer un servicio más integral a sus clientes y ser cada día más innovadora en el mercado nacional e internacional, la compañía eBD, líder en la integración de soluciones de comunicaciones, adquirió la empresa antioqueña Trébol Software S.A.

Rentabilidad, gerencia visionaria, talento humano altamente calificado, liderazgo, gran reputación entre sus clientes y su proyección internacional, son los principales aspectos tenidos en cuenta por eBD para adquirir esta compañía.

Trébol Software S.A. es una empresa con más de 14 años en el mercado nacional, que tiene sedes en Medellín y Bogotá; y se concentra en: desarrollar soluciones de software a la medida, prestar servicios de outsourcing de ingeniería de software y diseño de productos genéricos.

La adquisición permitirá a eBD, ampliar el mercado y llegar a más clientes pertenecientes a distintos sectores de la economía entre los que se destacan el público, financiero, telecomunicaciones, energético, industrial y de transporte aéreo.

Aunque el 96% de los ingresos de Trébol Software S.A., provienen de empresas ubicadas en Medellín, esta compañía tiene presencia en Bogotá, y desde estas dos ciudades, atienden clientes de la importancia de ISA, UNE, Skandia, Sofasa, EPM y Avianca. Cuenta con alianzas y certificaciones de los principales proveedores de plataformas tecnológicas, así como certificación ISO 9001:2000 y CMMi nivel 3, que afianzan aún más su posicionamiento en el mercado.

Consolidación
Con esta negociación eBD inicia un proceso de consolidación nacional y genera el espacio para un crecimiento internacional, una meta que había sido fijada desde el pasado mes de abril, cuando Tribeca Partners adquirió el 60% de sus acciones.

Para Carlos Alberto Sierra, Gerente General de eBD, “la adquisición de Trébol Software S.A. obedece a los intereses tanto de nuestra compañía como de Tribeca, dirigidos al fortalecimiento del negocio principalmente, en Colombia y América Latina”.

Adicionalmente, con esta integración, las dos compañías reunen conocimientos y herramientas que serán utilizados para crear nuevos servicios que mejoren la productividad de sus clientes.



Aquí más por si hace falta: Tribeca Partners