Hace 4 años terminé la carrera de Ciencias de la Computación en la UNAM. Habiendo aprendido a programar de manera autodidacta desde la secundaria y siendo un apasionado de la programación desde entonces, yo creía que tendría mucho que aportar a la industria de desarrollo de México. 4 años más tarde, sin embargo, he decidido salirme definitivamente de esta industria y dedicarme a crear un perfil que me pueda dar empleo en el extranjero. En este post he decidido juntar lo que he aprendido en este tiempo acerca de esta industria, con la esperanza de que a los recién egresados de carreras informáticas en México les resulte útil.

Antes de comenzar, debo aclarar que no a cualquiera le va a resultar útil este post. Existen muchas personas haciendo una carrera exitosa en esta industria. Este post está dirigido a los buenos programadores recién egresados. En particular a los que se consideran hackers. Por otro lado, mi experiencia es sobre todo en proyectos empresariales grandes.

1. En la industria de desarrollo de software en México nadie sabe de desarrollo.

Esencialmente ninguna empresa de desarrollo tiene una estructura interna de expertos en desarrollo de software. Arriba de ti, se encontrarán analistas, diseñadores, líderes de proyecto y arquitectos. Ninguno de ellos sabe programar. Casi todos programaron cuando comenzaron, pero lo más probable es que hayan sido malos y, encima, ahora tienen varios años ya sin escribir una línea de código. Alguien que cree en este tipo de estructuras, argumentaría que no es la función de estos roles el saber de programación. Desde mi punto de vista es absurdo tener a tantas personas sin conocimiento real de cómo se desarrollan los sistemas, tomando decisiones continuamente acerca de lo que se va a hacer y cómo se va a hacer. El rol que más me ha sorprendido es el del arquitecto. Más de una vez me encontrado con arquitectos totalmente incompetentes, cuyo único aporte al proyecto son diagramas que los desarrolladores ignoran abiertamente. En el último proyecto en el que estuve cuando llegué mis compañeros me dijeron: “Debes saber que aquí los arquitectos no son lo que tu esperarías que fuera un arquitecto. Aquí realmente no hacen nada mas que revisar documentos.”, lo que no sabían es que yo ya estaba acostumbrado a este tipo de arquitectos y realmente no estaba esperando mucho.

Dilbert.com

2. Las principales fuerzas que moldean a la industria

Entender a la industria de desarrollo me ha tomado mucho tiempo. Lo que ahora puedo concluir es que existen al menos 3 fuerzas contundentes que la definen.

• Hay mucho dinero. Hay muchas empresas grandes, con MUCHO DINERO, demandando servicios de desarrollo de software. Por esta razón es tan fácil encontrar proyectos de desarrollo capaces de mantener nóminas gigantes formando estructuras burócratas con facilidad.
• Muy pocas personas quieren programar. Esto puede ser cultural (el desarrollo es considerado mano de obra) pero creo que existen otros factores involucrados. Cualquiera que sea la razón, la consecuencia de esto es que existen muy pocos programadores activos y con experiencia disponibles para tomar roles de liderazgo. Esencialmente nadie de los que toman decisiones sabe programar y esto es algo que explica muchas cosas.
• La mayoría de los proyectos son un tipo de ABC (altas, bajas y cambios). Por ello las empresas de desarrollo se mantienen. Por ello no es necesario para las empresas volverse eficientes. Por ello a pesar de un mal análisis, diseño, arquitectura y manejo del proyecto, los programadores pueden lograr que el sistema se levante y funcione como pueden. Es bien sabido que los estándares de la industria son pésimos.
• Las empresas de desarrollo varían mucho en su forma de trabajar y su visión, no todas son burácratas desde el inicio, hay algunas que incluso trabajan con metodologías ágiles. A menudo los que las crean son buenos desarrolladores, sin embargo, desde mi punto de vista estas fuerzas son contundentes y hacen que casi cualquier empresa de desarrollo termine volviéndose una clásica consultoría de software genérica.

3. Se puede ganar bien

Esta es la buena noticia. Vas a ganar más que todos tus amigos de la preparatoria que estudiaron otras carreras. Aunque los salarios de los desarrolladores en México son bajos comparados con los de otros paises de primer mundo, si los comparas con lo que ganan tus amigos de otras carreras resulta que estamos muy bien pagados. Dedicándote, por ejemplo, a Java EE, es posible llegar a ganar, digamos unos \$35,000 mxn con tan solo aguantar unos años en la industria para volverte mágicamente “senior”. Volviéndote arquitecto sube fácilmente a \$50,000 o más (En el último proyecto en el que estuve los arquitectos ganaban más de \$100,000 mxn).

4. No te dediques a PHP!

Ok, Tal vez acabas de salir de la carrera y te salió un cliente por ahí que te pidio algo con PHP. ¡No lo hagas!. Si quieres aprovechar lo único bueno que tiene la industria (el dinero) debes dedicarte a lo que las empresas con dinero demandan. Por ejemplo:

• Java EE.
• .NET
• SAP
• SOA
• COBOL / Mainframes (yeak)

Esto es importantísimo: La demanda que tienen los perfiles es lo que realmente hace que puedas ganar bien. No el que tan bueno seas (¡Debes recordar muy bien eso!). Para ejemplificar esto, consideremos el caso de un compañero que trabajaba en un proyecto en el que estuve. Era recién egresado y, dado que no habían podido conseguir especialistas en Documentum, le ofrecieron un curso para capacitarlo. Como era recién egresado su consultora le pagaba \$8,000 mxn al mes (¡muy poco incluso para recién egresados!). Después de unas semanas, se hartó, consiguió una mejor oferta por otro lado y se fue. Al poco tiempo “los jefes” presionaron a esta consultora para que les diera a un especialista de Documentum y como no conocían a nadie más preguntaron si el serviría, a lo que respondieron que sí. Resulta que a la consultora le ofrecieron aprox. \$100,000.00 al mes por este perfil por lo que terminaron haciéndolo regresar ahora ganando más que la mayoría de los que trabajábamos ahí. Si consideran lo que cuestan las licencias de software propietario para empresas, podrán entender por qué alguien “capacitado” para manejarlas puede ganar tanto. En fin, así es cómo un recién egresado, habiendo tomado un cursito, y con conocimientos triviales de una herramienta puede llegar a ganar más que el 99% de la población.

5. Para ganar bien tienes que cambiar de empresa

Lo que uno cree, ingenuamente, al salir de la carrera es que si eres bueno y te mantienes mucho tiempo en una empresa, vas a crecer. Esto tal vez es posible si crecer para ti significa volverte manager y dejar de programar. Si no quieres caer tan bajo y lo que quieres es hacer una carrera como programador, simplemente no funciona así. Los desarrolladores mejor pagados que he conocido han trabajado en muchos lugares y saben bien como funcionan las cosas. En todos lados hay empresas urgidas por desarrolladores (o mejor dicho por “perfiles”). Si te quedas en una empresa te sales de este mercado y no es muy fácil enterarse de cuánto eres capaz de ganar. Si te cambias de empresa conoces mejor el mercado y puedes elegir modificar tu perfil para ser mejor pagado (ej. tomando un cursito del grandioso “SOA” ). Es muy común que desarrolladores que pensaban que no ganaban mal terminen duplicando su sueldo con solo cambiarse de empresa. Nunca he visto aumentos que se puedan comparar con eso.

6. Las certificaciones solo sirven para crear perfil

Si llevas unos años trabajando con Java, ya tienes un perfil de desarrollador senior Java. No necesitas una certificación de java programmer. Si estás en una posición similar, te recomiendo hacer certificaciones que puedan cambiar tu perfil a uno mejor pagado (de nuevo, el dinero es lo único bueno que hay en la industria y es la única forma de justificar el dedicarte a ella). En esta posición recomendaría una certificación de arquitecto o de SOA.

Para la industria tu eres tu perfil. Nadie se va a molestar en averiguar si realmente tienes el nivel del programador senior que se supone que eres, o si eres mejor. Simplemente: si llevas mas de 3 años trabajando en lo mismo eres senior.

Dilbert.com

7. Muchos proyectos grandes nunca llegan a nada

Es muy común trabajar en proyectos que entran en una marcha de la muerte y terminan no llegando nunca a nada habiendo gastado una cantidad exagerada de dinero en la nómina de los 50 consultores que han trabajado en él durante más de 1 año. Aquí es cuando nos damos cuenta de la ineficiencia de la industria y de la cantidad exorbitante de dinero que tienen las empresas.

El por qué sucede esto con los proyectos grandes es fácil de entender cuando has trabajado en uno: Existe una tendencia muy marcada a que se creen burocracias en ellos. El por qué se crean burocracias en ellos es más difícil de entender. Desde mi punto de vista esto tiene que ver con que los humanos estamos condicionados a crear estructuras de poder político en cualquier grupo social al que pertenezcamos, es decir, la mayoría nos volvemos “seguidores” del grupo (o de los líderes) de una manera natural e inconsciente. Esto se traduce en que “confiamos” demasiado en los demás, y dejamos de hacerle caso a nuestro propio juicio. En grupos pequeños, es más fácil tener confianza en tu juicio y también mucho más fácil que los demás te escuchen.

Dilbert.com

8. Entrar a un proyecto nuevo es un volado (no sabes qué te va a tocar)

Es muy común que tus amigos te hablen de cómo los explotan en la empresa en que están. No todos los proyectos son así, pero sí son comunes. El problema es que siempre que cambias de equipo o de proyecto, no es posible saber de antemano cómo saldrán las cosas en el futuro. En el peor caso, el proyecto se retrasará y existirán presiones primero del cliente y luego de los gerentes para que el proyecto salga, por lo que tendrás a todo mundo encima de ti obligándote a trabajar a marchas forzadas. A casi todos nos han tocado estos proyectos. Desde luego el desarrollador (el único que tiene que hacer funcionar las cosas) es el que tiene toda la presión encima. Tal vez esto contribuya a que nadie quiera ser programador.

Por otro lado, es muy difícil hacer estimaciones de tiempo de desarrollo. Aunque de cualquier forma, en la mayoría de los proyectos esto ni siquiera importa ya que el tiempo de desarrollo es fijado comúnmente con el objetivo de lograr un contrato!. El saber si tendrás buenas condiciones de trabajo o no, es algo que difícilmente está a tu alcance a menos de que trabajes continuamente con el mismo equipo y en la misma empresa.

9. Confía en los que hacen, no en los que hablan (¡ja! casi en nadie)

En esta industria vas a trabajar con personas que llevan mucho tiempo en esto y que creen saber mucho. Confía en mi: “casi nadie tiene idea de nada”. Si eres un buen desarrollador te darás cuenta de esto en poco tiempo. Bastará con entrar a una junta en donde algunos hablan mucho pero que, cuando termina, te das cuenta de que realmente no se dijo nada. Cuando tengas una posición de responsabilidad, confía en los que realmente hacen las cosas, no en los que hablan mucho. Existen algunas personas muy buenas en lo que hacen. El problema es que existen muchos otros que son mejores para hablar y hacer creer a todos, incluyendo a ellos mismos, que son brillantes. Lo peor es que estos son los que consistentemente acaban siendo managers.

Dilbert.com

10. En la industria eres “commodity”

En otras palabras eres intercambiable (al menos para los que tienen el dinero). Aunque ganes bien, las empresas te ven así. Las empresas que contratan tus servicios te ven como alguien ajeno a ellos. No eres una parte central de su negocio por lo tanto eres intercambiable, tu sueldo se da en función a tu perfil y no en función a tu capacidad; solo tienes que cumplir ciertos estándares para ser considerado (experiencia, estudios), una vez que cumples el perfil que imponen ellos, eres igual a todos los demás. El negocio de ellos se basa en poder hacer predecibles y repetibles los proyectos y esto no puede ocurrir si el éxito de un proyecto depende de un programador rockstar. Por lo tanto, no hay lugar en la industria para que los buenos programadores sean reconocidos (aparte de que es difícil reconocerlos!).

De aquí viene el término de “fábrica de software”. ¡Las empresas quieren ver el desarrollo de software como una fábrica!: Implementar procesos repetibles y predecibles que les permita contratar trabajadores intercambiables, ponerlos a trabajar, y obtener resultados.

Uno podría pensar que tal vez era de esperarse que para los clientes seamos commodity, pero que en las empresas que se dedican a desarrollar (las consultorías de software), no debería ser así. El problema es que las consultorías también son commodity. Para las empresas que contratan sus servicios, estas son intercambiables. Tal vez de vez en cuando identifiquen a una y logren confianza en ella, pero siempre va a existir presión dentro de la empresa para darle los proyectos a otra consultoría que cobre menos o que diga que lo puede hacer en menos tiempo. Existe muy poca distinción entre las consultorías. Tal vez la única distinción real que tienen sea la cantidad de programadores “con un cierto perfil” que son capaces de poner a trabajar en un nuevo proyecto. Y por esta razón las consultorías en México terminan funcionando como empresas de recursos humanos: su función principal es contratar recursos con un perfil arbitrario que puedan colocar en proyectos de sus clientes. Realmente ninguna tiene una estructura interna de expertos.

Conclusión

La realidad de la Industria de Desarrollo de Software en México es que no existe. Existen programadores, pero las empresas que dicen ser de desarrollo de software, realmente son más parecidas a empresas de recursos humanos.

Si te consideras un hacker, apasionado del software libre, etc. que quiere mejorar sus habilidades como programador y profesionalizarse, definitivamente esta no es la industria para ti. Yo te recomiendo buscar empresas reales y establecidas de desarrollo (¡si hay alguna de estas en México díganmelo!) en donde el desarrollador sea una figura prominente. Ej. Microsoft, Google y un muchas de startups extranjeras en donde el desarrollo realmente es considerado algo importante.