Archive for the ‘Informática e Internet’ Category

h1

Las herramientas y tecnologías más usadas en Java

29 noviembre, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El aprendiz evita todo uso de clases en Java. El profesional, acepta las clases de Java. El maestro sabe qué clases aprovechar y cuáles evitar.

— Michael Fogus, programador y escritor Estadounidense. Autor del libro The Joy of Clojure.

Regularmente, un proyecto desarrollado en el lenguaje de programación Java incluye librerías de terceros. Esto ocurre porque en estricta teoría, los APIs del core del lenguaje poseen toda la funcionalidad que necesitamos, mientras que en realidad, generar este middleware por nuestra cuenta requiere demasiado esfuerzo, por lo que podemos minimizar esta tarea con la ayuda de librerías que nos permiten enfocarnos en lo que realmente importa: la lógica de negocio. Así, desde las tareas tan pedestres como los logs, hasta las más esotéricas como el procesamiento de lenguaje natural, tenemos a nuestra disposición un sinfín de herramientas y frameworks generados por otros desarrolladores que nos permitirán resolver el problema en cuestión sin necesidad de reinventar la rueda. Por otro lado, con el explosivo crecimiento de Java y las plataformas que la componen, incluyendo desktop, web y móvil, existen literalmente cientos de librerías para una misma función que pueden generarnos ansiedad por indecisión, porque debemos elegir entre frameworks “de moda” – los que pueden impresionar a los clientes, cerrando un trato – y aquellas herramientas que ya son consideradas maduras y por lo tanto, “aburridas”. Esto es razonable, ya que el éxito o fracaso de un proyecto desde el punto de vista técnico se debe en gran medida al uso de tecnologías inmaduras o aquellas que tienen una pronunciada curva de aprendizaje.

Así entonces, hace algún tiempo se publicaron dos análisis que describen las herramientas y frameworks más utilizados por la comunidad Java. El primero fue generado por el staff de Takipi, un startup que ha basado su estudio en las estadísticas que arrojaron más de 10,000 proyectos de Java hosteados en GitHub. El segundo fue desarrollado por ZeroTurnaround, otra compañía que realizó su análisis a través de encuestas publicadas en el reconocido sitio The Server Side. Los resultados se muestran a continuación:

Pic: Tools & Tech - 1 of 2
Pic: Tools & Tech - 2 of 2

Herramientas y tecnologías más comunes en la comunidad Java. En la gráfica se muestra el porcentaje de proyectos en los que los desarrolladores han utilizado una tecnología específica, de acuerdo a su categoría.

A partir de estos números, obtenemos algunos hallazgos interesantes:

• En este momento, la versión de Java más usada es la 6, publicada en Diciembre de 2006. Puesto que la versión 5 tiene poco más de 9 años de existencia (Septiembre 2004) y la versión 7 apenas tiene un par de años de haber sido liberada (Julio 2011), estos porcentajes proporcionan el tiempo aproximado para que una versión de Java se generalice: 3 años y 4 meses.

• Debido a su tremenda potencia, relativa facilidad de aprendizaje y extensa documentación, Eclipse, Maven, Ant, Jenkins/Hudson, Subversion, SLF4J, Spring, Hibernate y JUnit se han vuelto los estándares de facto en la industria, al grado en que no existen implementaciones de Java que no usen alguno de estos frameworks y herramientas.

• Adicionalmente, Spring MVC y Java Server Faces se han convertido en los frameworks de mayor uso para cualquier implementación web. Apache Struts sigue apareciendo entre los primeros lugares, aunque no está claro cuál de las dos versiones es la más popular. Lamentablemente, otros frameworks como Wicket o Tapestry – que personalmente me parecen mucho más accesibles que JSF o Struts – se han quedado rezagados.

• En cuanto a los servidores de aplicaciones, vale la pena mencionar cómo Tomcat está presente en casi cualquier despliegue web, mientras JBoss es el “servidor empresarial” con mayor uso por la comunidad. Por otro lado, vemos cómo los millones de dólares que respaldan a los servidores de aplicaciones comerciales no han servido de mucho para incrementar su participación. Sin embargo, esto es sólo relativo, ya que con frecuencia, Tomcat y Jetty son utilizados para ambientes de desarrollo, mientras el servidor en el que se deja la producción termina siendo un Websphere o un Weblogic.

• Finalmente, de acuerdo a las estadísticas, el desarrollo orientado a pruebas está cambiando la manera de hacer los proyectos, con casi uno de cada tres utilizando JUnit: Ahora, las pruebas unitarias ya son prácticamente un requerimiento que nosotros como desarrolladores debemos conocer y saber cómo llevar a cabo.

Conclusiones

Los resultados pueden no ser sorprendentes, pero son un buen punto de referencia para saber hacia dónde se está dirigiendo Java, mientras que para los desarrolladores novatos éstos pueden servir como guía para conocer qué frameworks y herramientas deben dominar si quieren ser competitivos en el ambiente laboral presente. Adicionalmente, podemos darnos cuenta que con muy marcadas excepciones, el desarrollo en Java depende casi exclusivamente de iniciativas open source, lo que ciertamente democratiza esta disciplina, evitando que un sólo jugador sea el que defina el futuro de la especialidad, tal como aquella otra tecnología que opera bajo el (poco ético) lema de “adoptar, extender y extinguir“.

h1

Conservando la lealtad de los empleados: dos puntos de vista

27 septiembre, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La administración consiste en hacer las cosas bien; el liderazgo consiste en hacer lo correcto.

Peter Drucker (1909 – 2005), consultor, educador y autor austriaco.

¿Qué es lo que la mayoría de nosotros espera de su trabajo? ¿Qué requerimos para prosperar y crecer en el mismo? ¿Qué necesitamos para “ponernos la camiseta” y dar nuestro máximo esfuerzo? Algunos responderán sueldos altos y prestaciones; otros se irán por el tema del ambiente laboral y los que ya lo han experimentado, tal vez mencionen home office y flexibilidad de horario. Sin embargo, resulta que nada de esto es cierto: dos de las empresas globales con más prestaciones, apapachos y número de iniciativas de calidad de vida hacia sus trabajadores, tienen índices de rotación enormes, con una permanencia promedio de apenas un año. No, no se tratan de Walmart y sus historias de horror; tampoco de Samsung, con capataces que imponen castigos corporales a sus empleados. Estas empresas son ni más ni menos, que Google y Amazon.

Así es: una de las grandes realidades de la vida moderna, es que sin importar las prestaciones, ingresos o ambiente laboral, la verdadera satisfacción de nuestro trabajo depende de un sólo factor: nuestro jefe. Si es una persona con dotes de liderazgo que nos trata como seres humanos, nos informa adecuadamente qué es lo que espera de nosotros y nos proporciona una retroalimentación de forma positiva y continua, seremos trabajadores felices, incluso si el sueldo no es del todo competitivo, la naturaleza del puesto es estresante o las jornadas laborales llegan a ser excesivamente largas. Esto puede ser algo inesperado para algunos de nosotros, pero si nos ponemos a pensar, nos daremos cuenta que es verdad: habitualmente cuando cambiamos de trabajo de manera voluntaria, se debe a que estamos abandonando al jefe, no a la empresa. Recuerdo una entrada en este mismo blog, donde describía que la interacción entre las personas siempre debe basarse en humildad, respeto y confianza, pues al faltar alguno de estos valores, tarde o temprano tendremos un conflicto que desembocará en una ruptura.

Qué hacer como empleado

En algunas ocasiones me he topado con jefes que no están preparados para serlo. Ya sea porque los lanzaron al ruedo sin entender plenamente sus funciones, o son acting – sí, aquello de sigues ganando el sueldo de supervisor, pero trabaja como ‘acting manager’ por cierto tiempo y si eres bueno, te damos el puesto. Lo malo es que con regularidad, ni siquiera se dan cuenta de que se están metiendo en un batidillo, y a menos que exista retroalimentación por parte de sus subalternos, no podrán identificar dónde se encuentran las áreas de oportunidad. Una buena forma de arreglar esto es hablar con ellos para corregir el rumbo. Pareciera que esto es de sentido común, pero muchas veces, el ego se interpone en el camino – el típico “que se joda” – sin darnos cuenta que en última instancia, al tener un supervisor ya somos parte de un equipo de trabajo; si él falla, nosotros fallamos también. Algunos expertos en la materia nos recomiendan ciertas acciones a tomar en caso de que nuestro manager no tome la iniciativa:

• Qué espera de nosotros. Aunque muchos damos por hecho cuál es nuestra función, a menudo los jefes esperan algo muy diferente de lo que nosotros creemos. Por ello vale la pena dejar en claro las expectativas de ambos.

• Mayor comunicación. Pedir una retroalimentación periódica independientemente de si creemos que vamos bien o no, permitirá a ambas partes identificar sus respectivas áreas de oportunidad. La clave aquí es la humildad: el diálogo debe darse no para acorralarlo o ponerlo en evidencia, sino para darle a entender que estamos ahí para apoyarlo.

• Explicar nuestras capacidades. Muchos jefes no tienen idea de qué skills poseen los miembros de su equipo; esto ocurre sobre todo en organizaciones donde el manager tiene muchas personas bajo su cargo. Siempre es sano recordarle al jefe – y recordarnos a nosotros mismos – que él no está ahí porque sepa más que nosotros, sino porque puede coordinar profesionales que saben hacer su trabajo.

• Consistencia. ¿A cuántos no nos ha pasado aquella situación en la que el jefe solicita un trabajo con urgencia, obligándonos a salir tarde por entregarlo antes de la fecha límite, para que después de algunos días nos salga con que ‘ehh… ni siquiera lo he revisado’? Este tipo de inconsistencias se convierten en “una raya más al tigre”, y de ahí, en resentimiento y la eventual separación. La mejor opción es hablarlo de inmediato, solicitando compromiso y respeto de su parte.

Y qué hacer como manager

Ahh… pero el que debería buscar la lealtad del empleado debería ser el jefe, pues la razón de ser de un manager es básicamente la de coordinar personas y retener buenos trabajadores; de nueva cuenta, humildad, respeto y confianza deben ser los valores que debemos mostrar hacia nuestros subordinados. En este caso, existen algunos tips que nos pueden ayudar a mejorar la experiencia de nuestra gente y mejorar la eficiencia general del equipo de trabajo:

• Escuchar atentamente lo que nos dicen. Es necesario hacer preguntas, mantener contacto visual, sonreír; nada de checar el celular, el reloj o el monitor de la laptop. Debemos mostrar a nuestra gente que estamos realmente interesados en lo que tienen que decir, pues debemos hacerlos sentir que son alguien importante en nuestro equipo de trabajo.

• Comunicación. Evitando revelar información clasificada o entregarnos a la juntitis crónica, es muy importante que nuestros equipos estén informados sobre el estatus general del proyecto, área e incluso de la compañía. Esta política inclusiva de all hands meetings tiene sus beneficios; especialmente el sentido de pertenencia y de que somos un equipo, tanto en las buenas como en las malas.

• No hacerse el importante. Uno de los rasgos característicos de algunas personas es lo fantoches que pueden llegar a ser; este comportamiento es especialmente notable en la cultura Latina, donde existen muchos jefes que todavía aplican la de quién es el macho con sus subordinados. Esto puede servirnos cuando tengamos reuniones entre iguales o participemos en una negociación con un cliente, para hacerles saber que somos parte del club. Pero cuando se trata de nuestra gente, tenemos que reflejar la convicción de que “mi confianza es tal que NO es necesario apantallarte con mis posesiones materiales, viajes o grados académicos”.

• No discutir las fallas de otros. ¿A quién no le gusta un poco de chisme de vez en cuando? Después de todo, es un buen tema de conversación que hace amena cualquier plática. Sin embargo, perdemos enormemente el respeto de los demás si ventilamos los trapitos de alguien en público. Y esto también incluye las evaluaciones: los elogios y reconocimientos siempre son en público; los reproches y críticas, en privado.

En resumidas cuentas, para conservar la lealtad de nuestros empleados, como managers debemos demostrarles que sinceramente nos preocupamos por ellos y que los consideramos no sólo como recursos, sino como colaboradores sin los cuales nosotros no podríamos llegar a ningún lado. Como elocuentemente describió un gerente en una plática dada por Jeff Haden, consultor y columnista de la revista electrónica Inc.com:

… Sí, nosotros estamos a cargo y sí, hablamos acerca de objetivos, metas y visiones, pero a nuestros empleados no les importa nada de eso. Podemos comunicarnos y conectarnos con ellos todo lo que queramos, pero nadie nos escucha realmente. Sólo sonríen y asienten con la cabeza; luego vuelven a hacer sus trabajos de la misma manera que siempre lo han hecho.

Nuestros empleados en realidad no se preocupan por lo que queremos que hagan, hasta que se dan cuenta de lo mucho que nos preocupamos por ellos. Cuando los empleados saben – realmente saben – que te preocupas por ellos, es entonces cuando ellos se preocupan por ti. Y cuando saben que te importan, te escucharán… y harán lo que sea por ti.

h1

Implementando Scrum: un caso de la vida real (Parte 2)

14 julio, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La suerte no es un factor. La esperanza no es una estrategia. El miedo no es una opción.

James Cameron (n. 1954), director, guionista, productor de cine y explorador marino canadiense.

En el post pasado mostré un ejemplo de la vida real, con algunos de los tropiezos con los que podemos toparnos durante una implementación de Scrum. En resumidas cuentas, el usuario es nuevo en el paradigma ágil y por la premura de cerrar el contrato, a nosotros nos falló conseguir al personal adecuado, así como capacitarlos correctamente en las mejores prácticas de desarrollo ágil. Sin embargo, esto sólo es la punta del iceberg, ya que durante las siguientes iteraciones y para los demás equipos, tendremos que incluir una serie de medidas de control para asegurar la efectividad y eficiencia del proceso, así como de la calidad de los entregables.

Uno de los requerimientos más importantes para el cliente es una elevada productividad por cada Sprint, así que nos decidimos por un esquema de “trabajo especializado en paralelo”:

Tiempo (día) Planeación Análisis Diseño y Codificación Pruebas Despliegue
Planeación del Sprint
1 Recolectar reqs. del backlog        
2 Transf. de conocimiento de analistas hacia resto del equipo

Atomización de reqs. en tareas

Reunión de Sprint planning

     
3        
Ejecución del Sprint
4 – 13   Análisis para crear/insertar nuevos reqs. en backlog (siguiente Sprint) Diseño Ágil

Codificación

Pruebas Unitarias

Pruebas Funcionales

 
Cierre del Sprint
14         Reunión de Sprint review
15 Retro.        

Ciclo de “especialización en paralelo” con Scrum. Nótese cómo mientras una parte del equipo se enfoca a desarrollar los entregables del Sprint actual, otra parte (dos analistas) se dedica a realizar el análisis de requerimientos del siguiente Sprint.

Este modelo de tres semanas con análisis en T+1 es posible ya que cada célula incluye dos analistas de sistemas. Ciertamente esto contradice el paradigma ágil, ya que en teoría, todos los integrantes del equipo deben ser milusos o como dicen nuestros vecinos del norte, jack of all trades. Sin embargo, la misma figura literaria también dice: jack of all trades, master of none o lo que es lo mismo: quien mucho abarca, poco aprieta. Es decir, en algunas ocasiones es recomendable tener gente especializada en la célula que nos ayude a maximizar la eficiencia del equipo, pues por citar un ejemplo, un desarrollador promedio puede conocer PL/SQL y obtener buenos resultados, pero un DBA experimentado, “creará magia”.

Cabe recalcar que este esquema resultó exitoso en cuatro células pero falló catastróficamente en una de ellas. La manera más objetiva de demostrarlo es a través de números fríos: mientras la célula más productiva ha generado 819 story points durante las últimas 13 semanas, la peor ha generado tan sólo 130 que aun así, están siendo impugnados por el cliente. Esta falta de productividad fue achacada inicialmente a una falta de seguimiento en el proceso Scrum, sin embargo en términos generales, dicho proceso fue seguido al pie de la letra; el problema derivó en no implementar correctamente la construcción de los entregables. Este proceso, separado de Scrum, es conocido como el ciclo de vida de desarrollo de software (Software Development Life Cycle o SDLC).

El desarrollo de software se compone de dos procesos

Cualquier proyecto de desarrollo de software está compuesto por dos familias de procesos fuertemente ligados que atacan aspectos muy diferentes del proyecto:

• El proceso de gestión de proyectos, que de acuerdo al Project Management Body of Knowledge (PMBOK), se compone por diez áreas de conocimiento: integración, alcance, tiempo, costos, calidad, recursos humanos, comunicación, riesgo, adquisición y stakeholders.

• El proceso de desarrollo de software o SDLC, enfocado a la entrega del producto y conformado por las disciplinas ya conocidas por todos: análisis de requerimientos, diseño, construcción, pruebas, despliegue, mantenimiento y gestión de la configuración.

El problema es que los neófitos en el paradigma ágil creen que cualquier metodología define ambos procesos, algo que es tan FALSO como que el PMBOK nos indique cómo implementar un plan de pruebas. Scrum está enfocado al proceso de gestión de proyectos, dejando que el equipo decida cómo implementar a nivel operativo sus desarrollos; por el contrario, metodologías como Extreme Programming (XP) se enfocan de lleno a la ingeniería de software y por ende, a la entrega y calidad del producto. Es así como una de las metodologías híbridas más utilizadas en la industria es la mancuerna Scrum/XP, ya que ésta permite una combinación ganadora:

↑ Prácticas de gestión de proyectos Gestión de Costos Gestión de adquisiciones Gestión del tiempo

Sprint

*40 Hrs./Semana

Gestión de RRHH

Scrum master

*Propiedad colectiva del código

*Cliente on-site

*Coach, no PM

  Alcance y reqs.

Product Owner

Product Backlog

*Juego de planeación

*Cliente on-site

*Historias

Gestión de la comunicación

Scrum diario

Reunión de Sprint planning

Reunión de Sprint review

*Cliente on-site

*Historias

Gestión de la integración

Sprint

Reunión de Sprint planning

Sprint backlog

*Juego de planeación

*Liberaciones cortas

Gestión del riesgo

Reunión de Sprint planning

Reunión de Sprint review

Scrum diario

*Juego de planeación

*Liberaciones cortas

*Programación orientada a pruebas

*Cliente on-site

↓ Prácticas de desarrollo de software Diseño de software

*Metáforas

*Diseño simple

Construcción de software

*Programación por pares

*Refactoring

*Propiedad colectiva del código

*Estándares de codificación

Gestión de la configuración

Build diario

*Integración continua

Gestión de la calidad

Reunión de Sprint review

*Programación orientada a pruebas

*Refactoring

*Cliente on-site

*Estándares de codificación


Combinación de metodologías de gestión de proyectos y desarrollo de software. En este caso, Scrum y Extreme Programming. Nota: las prácticas con (*) pertenecen a XP. (Fuente: just-another-blog-for-kicks @ blogspot.com)

Esta combinación incluye controles entre las disciplinas de gestión de proyectos y desarrollo de software, dejando fuera sólo la gestión de adquisición y costos, que podrían ser llevadas a cabo de forma adecuada por una Oficina de Proyectos o PMO. Como opinión personal, este ejercicio debería ayudarnos a entender que Scrum por sí solo no resolverá nuestros problemas, ya que no hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos. Por ello la necesidad de complementarlo con mejores prácticas de otras metodologías o frameworks enfocados al nivel operativo.

Asegurando que todos hacen lo que dicen que hacen

Es así como hemos decidido verificar el seguimiento de estas prácticas a través de un checklist aplicado por un experto en la materia (Subject Matter Expert o SME) en colaboración con el resto del equipo, incluyendo el líder técnico (TL), los analistas (BA), los desarrolladores (DEV), el tester (TE) y el Scrum master (SCM):

Fase Punto de revisión Responsable Evidencia Resultado
Análisis Documentación elaborada por analistas está completada al 100% y están de acuerdo al objetivo de las historias de usuario seleccionadas para el presente Sprint. BA/TL Documento
Análisis La documentación aprobada está publicada, distribuida y disponible para todos los miembros del equipo. BA/ TL/ SCM TFS/ Sharepoint
Diseño Modelo de persistencia y modelo conceptual cumplen con alguno de los tres enfoques ORM: esquema primero, modelo primero, código primero. TL TFS/RSA
Diseño La arquitectura ya ha sido definida y comprendida por todo el equipo: cliente-servidor, N-capas, SOA. TL TFS/RSA
Construcción Los estándares de código han sido aplicados a todo artefacto de software construido de acuerdo a la filosofía de codificación adoptada. TL TFS/RSA
Construcción El ambiente de desarrollo está correctamente instalado y configurado en las instalaciones del cliente y si aplica, en las laptops de los desarrolladores. TL Ambiente verificado
Pruebas Unit tests para cada artefacto de software. TE/DEV Artefactos de software
Pruebas Matriz de pruebas actualizada con todos los casos y escenarios de prueba. TE Documento
Despliegue Obtener la documentación con los procedimientos de instalación y configuración de los entregables de software en los ambientes de QA, PERF y PROD TL Documento
Despliegue Verificar que existan procedimientos de gestión de cambios para los ambientes de QA, PERF y PROD. TL Documento

Lista de verificación para mejores prácticas del SDLC ágil.

Este es sólo un ejemplo, ya que dependiendo de la madurez del equipo o empresa que está implementando el proyecto, la lista puede tener más de 150 controles. De momento, nosotros no requerimos tantos (sólo 50-60 dependiendo de la tecnología usada), pero nuestra área de SQA ya nos adelantó la noticia que dentro de 6-8 meses certificaremos la cuenta en CMMI-5. Por ello, muy probablemente, acabaremos con una lista muy extensa, comprobada no sólo por nuestros SMEs, sino también por SQAs calificados o los appraisers que otorgan la certificación CMMI.

Conclusiones

El SDLC es el proceso que empleamos para desarrollar nuestros entregables. Y sin importar la metodología que ocupemos, si nuestro SDLC es inmaduro o deficiente, estamos en serios problemas. Sin embargo, NO existe un proceso único que pueda ser implementado por todos; incluso, debería ser lo suficientemente flexible como para cambiarlo de acuerdo a las necesidades de negocio o conforme va creciendo el alcance de nuestro proyecto. La situación es que siempre es necesario tener un proceso formal y comprendido por todos los involucrados, que pueda seguirse de forma sustentable. La alternativa es trabajar de forma desorganizada, o confiar ciegamente en que el equipo sabe lo que hace. Así que, nuestra mejor opción al adoptar ágil, consiste en adherirse al proceso de gestión, definir un SDLC formal, y hasta que estemos seguros que ambos procesos sean llevados a cabo de forma natural y repetible, es necesario introducir medidas de control para asegurarnos que todo funciona correctamente.

h1

Implementando Scrum: un caso de la vida real (Parte 1)

5 julio, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El éxito no es definitivo; el fracaso no es fatal: lo que cuenta es el coraje para continuar.

Winston Churchill (1874-1965), político y estadista británico.

Ahora que ya tenemos un par de meses implementando Scrum con un cliente relativamente inexperto en esta metodología, nos hemos llevado un par de chascos que seguramente pueden ocurrir en cualquier implementación donde no exista una definición concreta de expectativas, cuáles son sus procesos y artefactos, o aquellos que ejecutan el desarrollo no cuentan con los skills necesarios.

Pero empecemos por el principio: de entre cinco células ágiles, un equipo de desarrollo en Java “falló espectacularmente” de acuerdo al cliente. Esto provocó alerta entre nuestro “high management”, ya que el incidente puso en duda nuestra capacidad para trabajar con Scrum así como para generar los entregables de alta calidad que nos fueron solicitados. Aunque al principio esto se achacó a falta de conocimiento en los procesos ágiles, elaboramos un RCA en el que encontramos la verdadera causa del problema:

• Primero, el cliente se acercó a nuestra empresa solicitando células de desarrollo ágil. Inicialmente, pidió dos de “altísima urgencia”, advirtiéndonos que si no se conformaban e iniciaban los trabajos inmediatamente, encomendaría el proyecto a alguien más. Esto claramente fue para presionarnos, pues hasta la fecha, NO existe otro proveedor que esté ofreciendo este tipo de servicio a nuestro cliente.

• Luego, lo que el cliente solicitó fueron “células en Java y .Net”. Ni más ni menos. El requerimiento no incluyó un conjunto de tecnologías o perfiles específicos, ni en qué tipo de proyecto se estaría trabajando. Esto, aunado a la presión por iniciar de inmediato, significó que nuestra área de reclutamiento se limitó a buscar candidatos genéricos: “Hola, soy de la empresa X. ¿Sabes Java o .Net? ¿Sí? Te espero mañana para firma de contrato.” En el equipo .Net tuvimos muchísima suerte de contar con un desarrollador que ya conocía el tipo de arquitectura a implementar (Model-View-View-Model). En el equipo Java no tuvimos tanta suerte, pues el proyecto no sólo consistía en conocer el core del lenguaje, sino también en dominar una variada multitud de frameworks, herramientas y tecnologías como Spring, Hibernate, Websphere, JPA, JAX-WS o JSF.

Toy Stories: Noel (Texas, USA) ~ Gabriele Galimberti


Stack Tecnológico del equipo original. Como puede apreciarse en la tabla, las habilidades prácticas de las personas tendían a medio o bajo – sólo 16% de la experiencia podía ser considerada como “alta”. Sin un liderazgo técnico adecuado, el equipo estaba condenado desde un principio. (Dar click en imagen o aquí para ver a mayor escala)

• Dos semanas después de iniciado el delivery nos dimos cuenta que los skills requeridos eran muy especializados, ya que el proyecto se trata de implementar un SOA con todo y web services, flujos de trabajo, validaciones de negocio y colaboración constante con otros proveedores. Es decir, aparte de no contar con las habilidades necesarias para realizar su tarea, la gente tampoco tenía el “colmillo” para defenderse ante los demás proveedores o el mismo cliente, pues a la primera oportunidad, culparon de cualquier retraso a nuestro equipo.

• Después de otro par de semanas, tuvimos que cambiar de líder técnico y Scrum Master. ¿La razón? No supieron hacer “click” con el responsable del lado del cliente o Product Owner (PO), quien además de ser una persona bastante difícil de tratar, también tiene altos skills técnicos y funcionales – el típico “YO lo haría en dos horas. ¿Por qué TÚ vas a tardar un día en hacerlo?” Esto acentuó los problemas con el equipo, quienes presenciaban constantes discusiones a nivel técnico y administrativo con este personaje, además que se desmoralizaron al ver cómo sus líderes dejaban el proyecto con las piernas por delante.

• En la iteración tres ocurrió el desastre. Teniendo que entregar cuatro web services, el líder técnico cometió el error de “entrar al ruedo”, programando uno de éstos, pero desatendiendo el avance de los desarrolladores. Por otro lado, el Scrum Master no tomó suficiente ownership del equipo, pues cuando preguntaba “¿Cómo vas?” todos respondían “Bien”, sin que éste indagara más al respecto. Lo triste del asunto es que en realidad no iban nada bien – de hecho, algunos jamás probaron su código. Este exceso de confianza hacia los desarrolladores significó el principio del fin, ya que como cereza del pastel, nuestro tester jamás hizo las pruebas correspondientes sobre el código “terminado”.

• Durante la demostración al final del Sprint, todo reventó en nuestras manos: algunos desarrolladores sólo probaron en sus laptops; otros jamás probaron en absoluto. Sin embargo, nadie probó en el ambiente del cliente, así que durante la revisión de la demo, nada funcionó. El cliente, enfurecido, nos dijo que a partir de ese momento, su propia gente desarrollaría estos web services. Por lo pronto, esta célula estaba cancelada.

Y es así como hemos estado la última semana y media tratando de “salvar el honor”, pues aunque sabemos que el cliente ya está desarrollando los componentes por su cuenta, nosotros tenemos que entregar algo funcional para solicitar el pago por estas semanas de trabajo. A raíz de este incidente, hemos podido generar un plan de acción con el afán de que esto no se vuelva a repetir en el resto de las células, incluyendo controles para asegurar la efectividad de todos nosotros:

• Desde un inicio, contar con los recursos adecuados. Ahora, en las células nuevas, primero se presenta un líder técnico que “mide las aguas” para obtener el stack tecnológico y los perfiles requeridos. Posteriormente, dicho líder debe estar presente durante el proceso de reclutamiento, ya que la mejor manera de asegurar un buen recurso es contestando afirmativamente la pregunta: “si esta persona va a estar bajo mi responsabilidad, ¿me conviene traerlo a bordo?”

• Por otro lado, es necesario mejorar el liderazgo, pues no se ha dado una comunicación efectiva entre en líder técnico y el Scrum Master, además de que ha faltado ownership por parte de ambos. Básicamente, evitar la práctica de estarse pasando el mono.

• El cliente tiene un conocimiento muy bajo en metodologías ágiles. Es decir, ellos sólo recibieron el curso de dos días para convertirse en Scrum Master. Por ello, es necesario crear un par de workshops: el primero dirigido hacia los POs para que conozcan cuál es la verdadera función de un Product Owner y cuáles son las expectativas y entregables que deben estar manejando con el resto del equipo; el segundo debe estar dirigido hacia los ejecutivos del cliente (gerentes y directores) para que se den cuenta que ágil no es la “bala de plata”, al mismo tiempo que mostramos cuáles son las métricas con las que nos deberían estar midiendo, pues algunos entregables que nos están solicitando como “reportes de horas” y “cartas de aceptación” son algunos esquemas de control que se contraponen a la ideología de ágil.

• Finalmente, darnos cuenta que este problema no se debió a falta de conocimiento en ágil, sino a temas más pedestres como poco ownership, un líder técnico que quiso ser héroe, exceso de confianza entre el Scrum Master, el líder y el equipo así como poca experiencia por parte del equipo, puntualmente en el proceso de desarrollo de software (SDLC), y sus disciplinas más importantes, como integración continua, refactoring y pruebas de concepto. De hecho, el cliente mismo mencionó que el problema no era Scrum, sino los skills, actitud y experiencia de la gente. Después de todo, código entregado sin haber sido probado es un tema preocupante que no tiene que ver con conocimiento en (o la falta de) Scrum. Por ello estamos reforzando el proceso SDLC a través de dos expertos, uno en Java y uno en .Net, quienes asegurarán el correcto seguimiento de las prácticas de desarrollo ágil a través de las herramientas y procesos más adecuados.

De momento, sólo hemos visto un pequeño ejemplo de lo que puede pasar durante una implementación de ágil en un ambiente inmaduro. En el próximo post veremos que Scrum “de la vida real” no sólo consiste en leer los papeles de Ken Schwaber y esperar lo mejor: la realidad es que es necesario contar con el apoyo de una buena gestión de proyectos, un governance bien estructurado y hasta que no estemos seguros que el proceso está siendo seguido por todos los involucrados, deben existir algunos puntos de control para asegurar que todo marcha sobre ruedas.

h1

Los comentarios más chuscos encontrados en el código fuente

23 mayo, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

Los programas deben escribirse para que la gente los lea, y sólo incidentalmente para que las máquinas los ejecuten.

Hal Abelson (n. 1947), profesor y codirector estadounidense del Instituto Tecnológico de Massachusetts (MIT), cofundador de Creative Commons.

Hace algún tiempo, en el sitio técnico Stack Overflow apareció un hilo de discusión que decía: ¿Cuál es el mejor comentario en el código fuente que has encontrado? Aunque sale por completo de los temas que normalmente tratan en dicho sitio, la pregunta tuvo una respuesta de tal magnitud, que uno de los administradores tuvo que bloquear el hilo para evitar que éste dejara a sus servidores fuera de combate. Honestamente, en la actualidad se le conserva más por el enorme tráfico que origina, que por las “razones históricas” que justifican su permanencia entre preguntas más valiosas, aunque menos populares. Sin embargo, recomiendo mucho leer este hilo de discusión, porque nos permite entrar en la psique de aquellos valerosos programadores que cayeron en el cumplimiento del deber:

// if i ever see this again i’m going to start bringing guns to work

Traducción: Si veo esto de nuevo voy a empezar a traer armas al trabajo.

/**
For the brave souls who get this far: You are the chosen ones,
the valiant knights of programming who toil away, without rest,
fixing our most awful code. To you, true saviors, kings of men,
I say this: never gonna give you up, never gonna let you down,
never gonna run around and desert you. Never gonna make you cry,
never gonna say goodbye. Never gonna tell a lie and hurt you.
*/

Traducción: Para las almas valientes que han llegado hasta aquí: Ustedes son los elegidos, los caballeros valerosos de la programación que trabajan duro, sin descanso, corrigiendo nuestro terrible código. A ustedes, verdaderos salvadores, reyes de los hombres, les digo esto: (letra de la canción Never Gonna Give You Up de Rick Astley; efectivamente aplicándole al lector un Rickroll).

// I dedicate all this code, all my work, to my wife, Darlene, who will
// have to support me and our three children and the dog once it gets
// released into the public.

Traducción: Dedico todo este código, todo mi trabajo, a mi esposa Darlene, quien tendrá que mantenernos a mí, a nuestros tres hijos y al perro una vez que esto sea liberado al público.

try {
  …
} catch (Exception e) {
  //silent as a ninja
}

Traducción: Silencioso como un ninja.

// Dear maintainer:
//
// Once you are done trying to ‘optimize’ this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 16

Traducción: Querido encargado (de mantenimiento): Cuando hayas terminado de intentar “optimizar” esta rutina y te hayas dado cuenta del terrible error que esto significa, por favor incrementa el siguiente contador como aviso al tipo que venga después de ti: total_horas_desperdiciadas = 16

// I will give you two of my seventy-two virgins if you can fix this.

Traducción: Te daré dos de mis setenta y dos vírgenes si logras arreglar esto.

//Dear future me. Please forgive me.
//I can’t even begin to express how sorry I am.

Traducción: Querido yo del futuro. Por favor perdóname. Ni siquiera puedo empezar a expresar cuánto lo siento.

// If you’re reading this, that means you have been put in charge of my previous project.
// I am so, so sorry for you. God speed.

Traducción: Si estás leyendo esto, significa que te han puesto a cargo de mi anterior proyecto. Lo siento mucho por ti. Buena suerte.

/**
* If you don’t understand this code, you should be flipping burgers instead.
*/

Traducción: Si no entiendes este código, deberías estar volteando hamburguesas en su lugar.

try {
  …
}
catch (SQLException ex) {
  // Basically, without saying too much, you’re screwed. Royally and totally.
}
catch(Exception ex)
{
  //If you thought you were screwed before, boy have I news for you!!!
}

Traducción 1: Básicamente, sin decir mucho, estas jodido. Real y totalmente.

Traducción 2: Si antes pensabas que estabas jodido, oh muchacho, tengo noticias para ti!!!

Dependiendo de la situación en la que nos encontremos, estas joyas de comicidad ingenieril pueden hacernos recordar esos duros momentos en que la noche era larga y el café, barato.

h1

Cambio de hábito

18 abril, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

Durante los últimos 33 años, me he visto en el espejo cada mañana y me he preguntado: “¿Si hoy fuera el último día de mi vida, ¿querría hacer lo que voy a hacer hoy?” Y cada vez que la respuesta ha sido “No” por demasiados días consecutivos, sé que necesito cambiar algo.

Steve Jobs (1955 – 2011), empresario e inventor estadounidense, cofundador, presidente y director ejecutivo de Apple, Inc.

Estas últimas semanas han estado bastante complicadas, ya que decidí cambiar de empresa. En la anterior estaba muy a gusto, pero los proyectos, clientes y línea de trabajo se habían vuelto rutinarios pues el desarrollo de software – que es la actividad que más me llama la atención – había disminuido al mínimo mientras cada vez más de mi tiempo lo dedicaba al soporte de nuestras aplicaciones desktop y soluciones de hardware.

Ahora bien, gracias a mis conocimientos en Scrum adquiridos a lo largo de estos últimos años, aunados a una certificación como Certified Scrum Professional que obtuve este pasado 2012, pude saltar con relativa facilidad. Y digo relativa, porque la empresa donde ahora me encuentro hace unos filtros bárbaros, con background checks que incluyen una fuerte entrega de documentos oficiales así como entrevistas remotas, en inglés y a deshoras – como a las 9:30 PM, por dar un ejemplo.

Ahora formo parte de un equipo de cuatro células de desarrollo con un promedio de 9 personas cada una… y puedo confirmar que el trabajo es una verdadera joda. Más porque estaba acostumbrado a proyectos con duración y staffing pequeños – 2 a 4 personas por 3 a 6 semanas – cuando en este momento, estamos llevando a cabo seis proyectos de 6 a 8 meses de duración entre 40 personas. En este momento le estoy entrando al quite operativo, recibiendo requerimientos mientras vamos definiendo las prácticas de Scrum que estaremos implementando con los equipos – como planning poker o el formato de las historias de usuario. Ya que soy “el nuevo”, me estoy apoyando mucho en los ScrumMasters veteranos pero aun así, los días se me van como agua entre juntas, definiciones y visitas customer-face.

En fin, uno de los retos principales de este proyecto tiene que ver con que el cliente ha adoptado un Scrum personalizado, o ScrumBut. Por ejemplo, para un proyecto están requiriendo en la iteración cero, entregar un plan de trabajo para revisar fechas de liberación con el usuario de negocio; en otro equipo, no se realizan demos de la funcionalidad terminada en el sprint transcurrido porque “no hay quien los revise”. En ambos casos, estamos contradiciendo el espíritu de Scrum con customizaciones que al final, pueden llevar a resultados nefastos.

Dilbert: ScrumBut


[Jefe Pelopunta]: Vamos a intentar algo llamado programación ágil. Eso significa que ya no haremos planeación ni documentación. Sólo empiecen a codificar.
[Wally]: Me alegro que tenga un nombre.
[Jefe Pelopunta]: ESE fue su entrenamiento.


(Fuente: domin8k.com)

Sin embargo, con todo y estos temas de índole más humana que técnica, creo que vamos por buen camino. Durante las próximas semanas estaremos levantando estos múltiples proyectos, que tienen una gran variedad tecnológica: algunos son aplicaciones de escritorio en .Net; otros son aplicaciones web en Java y otros más tienen que ver con implementaciones SOA para nuestro cliente. En fin, estos días serán pesados pero muy entretenidos, pues como alguna vez me dijo un ex-jefe: si no existieran problemas, nosotros no seríamos necesarios.

h1

Sueldos IT en México 2013: Veteranos al poder

20 febrero, 2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

(Última actualización: 22/03/2015)

En este momento ya contamos con la última versión de este estudio, con cifras actualizadas para el año 2015 que incluyen entre otras cosas, desglose por entidad federativa, género, tipo de empresa contratante y nivel de inglés así como un comparativo contra el sueldo del estudio anterior (2013).

El problema con los programadores es que nunca se sabe lo que están haciendo hasta que es demasiado tarde.

Seymour Cray (1925 – 1996), ingeniero eléctrico y arquitecto de hardware estadounidense, considerado el padre de las supercomputadoras.

Desde hace ya algunos años he publicado posts relacionados a los sueldos del personal IT en México, apoyándome en los resultados de la encuesta de salarios y factores de la revista Software Guru, complementados con información de sitios como Payscale u OCCMundial. En términos generales, este 2013 no se ven demasiados cambios con respecto al reportaje anterior, sin embargo el detalle de sueldos sí presenta algunas sorpresas:

El promedio

El sueldo promedio del personal IT en México es de aproximadamente MXN 25,049 brutos (anualizado: USD 23,799 con un tipo de cambio de 12.63 pesos por dólar al 19.02.2013). Esto significa que durante los últimos dos años, el sueldo se ha mantenido a la par de la inflación y ha conservado prácticamente la misma paridad con respecto al dólar: el sueldo “dolarizado” en 2011 era de USD 23,736, por lo que ha tenido un incremento neto de 63 dólares. Aunque parece estancado en términos del billete verde, de acuerdo a la paridad de poder adquisitivo o PPP, el sueldo promedio de un sistemólogo en México equivale a ganar USD 35,975 en los Estados Unidos; aunque seguimos ganando menos de lo que ganaría un estadounidense (USD 90,279 con todo y prestaciones), de nueva cuenta los sueldos siguen convergiendo poco a poco, ya que la proporción es de 2.51 mientras hace dos años era de 2.97 (USD 70,536 vs. USD 23,736 en 2011). De seguir esta tendencia, en diez años o menos los sueldos de ambas naciones tendrán diferencias mínimas; idea que no es del todo descabellada, sobre todo para empresas que exportan servicios de consultoría hacia el exterior.

Por otro lado, vale la pena recordar que este promedio varía considerablemente. De hecho, de acuerdo a nuestra locación geográfica éste puede variar en más del 30%:

Estado Salario Promedio Mensual (MXN) Salario Promedio Anualizado (USD)
Querétaro $ 32,668.61 $ 34,383.71
Nuevo León $ 30,634.32 $ 32,242.62
Distrito Federal $ 29,025.53 $ 30,549.37
Jalisco $ 24,963.37 $ 26,273.95
Estado de México $ 24,461.17 $ 25,745.38
Promedio Nacional $ 25,049.00 $ 23,799.00
Aguascalientes $ 22,486.96 $ 23,667.53
Guanajuato $ 19,040.36 $ 20,039.98
Puebla $ 18,470.67 $ 19,440.38
Veracruz $ 14,190.00 $ 14,934.98

Sueldo bruto promedio por entidad federativa. Mensual en pesos Mexicanos, anual en dólares Americanos (Tipo de cambio al 19.02.2013)

Me parece interesante cómo han evolucionado de forma independiente lo sueldos por cada estado de la república: Querétaro se está posicionando como una Meca en el desarrollo de software, con una variación de poco más del 30% por encima del promedio nacional y un crecimiento bianual de casi el 33%. Esto no es de sorprenderse ya que dicho estado se ha esforzado en diversificar su economía: por poner un ejemplo, con la excepción de Baja California (estado tradicionalmente maquilador), Querétaro es la entidad con más empresas relacionadas a la industria aeroespacial (32) en el país.

Por otro lado, Veracruz es el mayor perdedor en esta edición, con un magro crecimiento de 3.75% anual que ni siquiera sobrepasa la inflación de estos dos años. Creo que mucho tiene que ver nuestra guerra contra las drogas, que ha hecho de éste uno de los estados más inseguros debido al conflicto; más cuando resulta que el personal IT – especialmente aquellos relacionados con las telecomunicaciones – son el objeto de secuestro por parte de los grupos criminales para crear sus propias redes de comunicaciones.

Sueldos por función

Los sueldos por función reflejan las actividades, que de acuerdo a la encuesta original, se traslapan con bastante regularidad:

pic: Mexico IT salaries by function


Sueldos por función de acuerdo a actividades desempeñadas. Cifras en pesos Mexicanos, sueldo bruto mensual.

• De nueva cuenta, el diseño gráfico resulta ser el peor pagado con un sueldo extraordinariamente bajo con respecto al promedio general.

• También me llama la atención lo bajo que es el sueldo de un DBA “genérico”; sin embargo no nos desanimemos pues cuando existe una especialización en una base de datos y/o existen certificaciones de por medio (como veremos más adelante), el panorama cambia radicalmente.

• De acuerdo a la Organización para la Cooperación y el Desarrollo Económico (OCDE), un profesor sin maestría o doctorado con 15 años de experiencia gana aproximadamente USD 25,905 anuales (con PPP incluido) en México. Esto en pesos equivale a MXN 18,037 mensuales. Así que hace mucho más sentido dedicarse a dar cursos de capacitación IT que ser maestro en nuestro pobremente pagado sistema educativo.

• El grueso de las actividades IT que va desde el análisis de datos hasta pruebas y Quality Assurance no varía demasiado (MXN 5,288 mensuales); la arquitectura de soluciones y gestión de proyectos siguen siendo las actividades operativas mejor pagadas con MXN 28,183.30 y MXN 32,018.29, respectivamente.

• Aunque en la edición pasada los habían eliminado, en esta versión volvemos a ver puestos que en realidad no nos dicen mucho del panorama IT, como ventas y dirección. Esto porque he notado que estos puestos se mueven más por conceptos ajenos a IT como ventas o desarrollo de negocios, por lo que hay gente en estas posiciones que llegan al extremo de no tener ni idea de lo que significa IT.

• Finalmente, de nueva cuenta los ingenieros de preventa barren con los sueldos. Sin embargo, creo que esto se debe a que en muchos casos, operan con una cuota y por lo mismo, en caso de “llegar al número” tienen bonos adicionales que se ven reflejados en el sueldo mostrado.

Sueldos por género, experiencia y nivel de Inglés

Es sorprendente ver cómo nuestro nivel de Inglés o género influyen en nuestro sueldo. No tanto la experiencia, pues a mayor exposición ante diferentes tecnologías, proyectos o lenguajes, más experto se vuelve uno y por consiguiente, el sueldo se ve incrementado:

pic: Mexico IT salaries by English level, gender and experience


Sueldos por género, experiencia y nivel de Inglés. Cifras en pesos Mexicanos, sueldo bruto mensual.

• Uno de los grandes indicadores de que seguimos siendo un país en desarrollo es la inequidad de género. De acuerdo a las estadísticas, una mujer gana en promedio 30% menos de lo que hace un hombre con los mismos conocimientos y experiencia profesional. Sin embargo, esto también se debe a que esta industria ha sido tradicionalmente dominada por varones: de acuerdo a la misma OCDE, la proporción de hombres y mujeres dedicados a las matemáticas y ciencias de la computación en nuestro país es de 62% y 38% respectivamente.

• Asimismo, los años de experiencia dictan mucho qué tanto podremos percibir. Los dos extremos me llaman mucho la atención: un veterano con más de 20 años en la industria estará siempre por encima de los MXN 41,000, lo que significa que mientras encuentre trabajo, éste será muy bien recompensado. Por el contrario, me resulta doloroso ver cómo sin importar si terminó la carrera universitaria, un “becario” con menos de un año de experiencia puede ganar casi lo mismo que un “maestro albañil” que no ha terminado siquiera la escuela secundaria: MXN 11,299.38 vs MXN 10,000. Para aquellos que se encuentran en este predicamento, les doy la siguiente recomendación: certificaciones, certificaciones, certificaciones.

Sueldos por conocimientos, habilidades, tecnologías y certificaciones

A principios del 2013, éstos eran los sueldos promedio en México de acuerdo al nivel de conocimientos, tecnologías y certificaciones:

pic: Mexico IT salaries by knowledge, skill, tech, certifications (1)pic: Mexico IT salaries by knowledge, skill, tech, certifications (2)


Sueldos por conocimientos, habilidades, tecnologías y certificaciones. Cifras en pesos Mexicanos, sueldo bruto mensual. Leyenda: (P) Plataforma, (L) Lenguaje, (DB) Base de Datos, (C) Certificación/Conocimiento.

• En esta versión del estudio, Adobe AIR va de último, sin embargo es lógico ya que es prácticamente una paquetería al estilo Adobe Flash o Adobe Flex: usada generalmente por diseñadores web.

• PHP como lenguaje, MySQL como base de datos y Android como plataforma son los peores pagados en la industria; una certificación en Linux sigue siendo poco deseable debido al poco retorno de inversión (apenas 151 pesos por encima del promedio de un IT “genérico”).

• Java ha visto una pequeña mejora con respecto a años anteriores, ya que vuelve a estar por encima de Visual Basic, .Net y C#. Cuando hay certificaciones de por medio, ambas plataformas (Oracle J2EE y Microsoft .Net) permiten obtener prácticamente el mismo ingreso.

• Los sistemas legados siguen siendo los mejor pagados: Mainframe, Cobol, Informix y DB2 aseguran un sueldo por encima de los MXN 30,000 mensuales.

• Certificaciones muy recomendables incluyen la de SQA/ISTQB, UML, ScrumMaster e ITIL, ya que además de lo relativamente económicas de adquirir (no cuestan arriba de USD 300 o MXN 3,800 y los cursos de certificación no están por encima de los USD 1,200 o MXN 15,000), no requieren demasiado tiempo o esfuerzo para obtenerlas. Esto las hace muy atractivas ya que poseen un alto retorno de inversión.

• Por otro lado, las certificaciones “top” incluyen la de Project Manager certificado por el PMI o la de Enterprise Architect certificado ya sea por el Software Engineering Institute (SEI) o la IT Architect Association (IASA). Dichas certificaciones pueden ser relativamente baratas (USD 600 o MXN 7,600) pero en algunos casos requieren de 3 a 6 meses de estudio constante para pasar el examen, así como un número de horas comprobables realizando el rol a certificar. Dicho sea de paso, certificaciones no incluidas en el estudio como PMI-ACP (Agile Certified Practitioner) o CSP (Certified Scrum Professional) son equivalentes a la de PMP, pero para metodologías ágiles: de hecho, cuestan lo mismo y el tiempo requerido para estudiar y pasar el examen es muy parecido.

• Finalmente… ¿Websphere en MXN 57,000? ¡Pero si eso es un sueldo de director de operaciones! De hecho, un puesto similar en los Estados Unidos (Websphere Administrator) se paga en casi el mismo monto que la media de un ingeniero de software estándar (USD 91,450 vs. USD 91,271). Así que o tienen contratado a un gringo que está sesgando la curva, o alguien está presumiendo una certificación que del otro lado ya es considerada más bien “del montón”.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 37 seguidores