Administrador de redes

Anoche agregué "Networking" (y Splunk!), a mi profile de Linkedin después de 8 años de carrera en infraestructura informática. Es algo un tanto simbólico, hace tiempo que me toca gestionar redes LAN chicas aquí y allá, pero hasta ahora no había tenido la oportunidad de trabajar como administrador de redes y llevar a la práctica la teoría aprendida años atrás (y olvidada, y hace poco re-leída y recordada). No poner "Networking" como skill era una especie de "respeto a la etiqueta", habiendo tantos amigos y conocidos administradores de red experimentados, con tanta experiencia y práctica, era un poco pretencioso a mi parecer decir que sabía administrar redes si nunca lo había hecho en la práctica, en redes de nivel empresarial, por más que me sintiera plenamente capaz de asumir esa tarea (y un desafío, al no tener práctica previa), hasta ahora :-D

Creo que ya puedo decir "soy administrador de redes" desde el punto en que puedo -fácilmente- diseñar  e implementar una arquitectura de red desde cero, que permita interconectar centenares de usuarios, anticipando necesidades de tráfico y escalabilidad por áreas, por edificio, que la escalabilidad de la solución sea de un par de cientos de usuarios a varias decenas de miles de usuarios y múltiples locaciones remotas (edificios diferentes, en diferentes ciudades inclusive), planificando conectividad mediante links WAN diversos (VPNs, MPLs,etc.); y más aún si lo podés implementar en varias plataformas de hardware y software diferente (3Com, Cisco, Fortigate, Linux, Windows Server, etc.).

Más allá de eso, ya teniendo que llevar el trabajo en una especialidad a un buen nivel dentro de ella, me doy cuenta que trabajar al límite tiene un costo, en 8 años adquirí varias especialidades y tuve que implementar soluciones complejas*, cuando normalmente se trabaja solo en una o en dos (tres máximo). Dicha eventualidad laboral me brindó profesionalmente las siguientes especialidades: administración de sistemas (Linux: Debian, SLES, RHEL, Ubuntu, etc. ;Windows Server 2003/2008/2012), adm. (Vmware vSphere, Openstack, Hyper-V, XenServer, KVM, etc.), adm. de Storage Area Networks y adm. de redes (3Com, Cisco, Fortigate, etc.); agrego adm. de infraestructura de Monitoreo (que es algo de lo que en años de trabajar en Ctes. y Resistencia no ví ni siquiera un diseño en Visio, o un comentario tipo "che tengo esta infraestructura de monitoreo", y ojo, no hablamos acá del Nagios montado en el fondo del datacenter).


["Solución Compleja": esas de las que no se encuentra tutoriales/howtos en Internet, cuando un especialista con experiencia te dice "ah, no sabía que s podía hacer eso", sí le decís, se puede y funciona 100% bien.]

El costo es que 8 años son pocos para tantas especialidades, tuve la suerte de tener las ofertas para trabajar en ellas (y poder hacerlo bien), y que me haya brindado un nivel técnico alto (o muy alto, en 3 de esas especialidades), en varias cosas. 

Al ser 8 años muy poco tiempo, estuve saltando de una especialidad a otra, más o menos bimensualmente (excepto Monitoreo que lo hice durante 2 años como especialidad completa), no tuve tiempo de aprender todos y cada uno de los detalles de cada especialidad, mucho menos tuve tiempo de sentarme a estudiar y probar una sola cosa, luego rendir y certificar en eso. Por ejemplo, mientras ahora estoy haciendo un refresh/update/upgrade de skills en Windows Server, estoy dedicado al momento al 100% a la administración de red, por un oído escucho "GID" y por el otro estoy viendo cual es la - gran, jodidamente importante diferencia - entre un DHCPNAK y un DHCPACK, y para qué lo podemos usar en la práctica (increíblemente útil por cierto), configurando que eso pase en la red.

El tener múltiples especialidades difiere de ser un generalista en el nivel técnico necesario para realizar el trabajo, un especialista tiene que poder sentarse y emprender un trabajo en esa especialidad como si fuera que nunca trabajó en otra cosa, no es "hacer el mejor esfuerzo", sino "hacer que las cosas pasen, con seguridad, y 100% de fiabilidad". Y se paga y se cobra por eso, claro.

Tener múltiples especialidades es algo que no cambiaría en mi carrera, aún si pudiera haber tenido una sola especialidad durante varios seguidos a futuro, inclusive lo probé un tiempo trabajando en Hewllet Packard (HP Enterprise Services), y todo el tiempo estaba como queriendome "salir de la vaina", hablando con administradores linux, wintel, storage, metiendo la cuchara cuando estaba en una reunión y alguien mencionaba algo de networking, cuando se estaba instalando un server (físicamente), y había algun problema, yo metía la cuchara y aportaba un par de ideas (un par de veces sirvieron :-D ).

Plus, si querés montar tu propia consultora de soluciones IT :-D, no te hace falta tener un equipo de 5 especialistas para poder diseñar una solución empresarial. No digo "implementar", porque saber diseñar no "fabrica" más de 24 hs. al día, y una solución compleja puede necesitar implementarse muy rápido, y allí hace falta varias personas trabajando en paralelo (al menos dando apoyo logístico a la implementación).


Y sí, esto es mitad marketing personal (gracias por leer hasta acá y por tu tiempo por cierto), mitad consultoría de carrera laboral, espero que le sirva a algunos de mis amigos y contactos en el ambiente informático, que sé que pide mucho estudio y laburo, pero nadie quiere enseñar ni mostrar nada, al contrario se suele intentar ocultar información (se encuentra quienes no quieren compartir la URL de un sitio web o un .pdf que consiguieron de algun curso que hicieron, que tienen buen material para aprender :-), engañar para impedir que otros aprendan algo que uno sabe (una lástima, cuando hay tantas cosas que enseñar que no se puede hacer en 5 años de carrera, ni se termina de aprender luego en años de práctica profesional), y otras bufonerías similares. 

Si tienen la oportunidad de enseñar algo, háganlo (no dejen de cobrar si es un curso/training importante claro! el laburo no se regala), cuantos más seamos en informática, más se valoriza la profesión, cuanto más profesionales y mejor nivel técnico tengan los trabajos entregados, más todavía crece la profesión; los clientes, los empleos bien pagados, la plata y el éxito vienen justo atrás de todo eso.

Sysadmin: Es parte del trabajo o se cobra aparte?

El límite del trabajo de administrador de sistemas en grandes proyectos IT

La teoría de administración de empresas más básica dice que si un empleado toma grandes responsabilidades en una organización - y si tiene éxito en ello especialmente - debería ser adecuadamente retribuído.

Entonces, cuando trabajamos como administradores de sistemas en un ambiente y proponemos un gran proyecto de infraestructura, suele ocurrir en Argentina que:

a) Si la empresa lo acepta, se lo añade a la lista de responsabilidades del administrador de sistemas, pero antes, durante y después de la toma de nuevas responsabilidades, no se lo compensa/retribuye mejor de lo que se hacía antes del proyecto.

o

b) La empresa lo acepta, pero lo terceriza, un tercero interviene y realiza exactamente el mismo trabajo que hubiera realizado el administrador de sistemas, pero cobra un precio significativo por haberlo hecho (mucho mayor que el sueldo mensual del administrador).

c) La opción menos habitual es que la organización, entendiendo la nueva importancia de las tareas a realizar, re-categorice apropiadamente - funcionalmente y/o económicamente - al empleado.


Límites
Entonces, la empresa/organización evidentemente tiene límites concretos de cuanto va a retribuir/pagar a su administrador por su trabajo...¿Por qué no debería tener límites también el trabajo del administrador de sistemas?

La definición formal de las responsabilidades laborales en Argentina para sysadmins, vía contrato de trabajo, contrato de obra o locación de servicios, etc. no suele servir para determinar los límites prácticos de las responsabilidades de un administrador de sistemas. Esto es porque la definición de cuál es el trabajo concreto que debe realizar suele estar muy indefinida (o convenientemente indefinida en algunos casos).

[Una solución en principio, sería intentar proveer a RR.HH. de un modelo de contrato laboral apropiado, luego de haber leído un contrato de trabajo "general", el habitual presentado al candidato en Argentina para puestos de administración de sistemas (que no incluye definiciones precisas ni límites de responsabilidad en gral.). Los que tenemos experiencia laboral, sabemos que en el 99% de los casos y en organizaciones/empresas que no se dedican a IT específicamente, esto no va ser viable por diversas razones]

El contra-ejemplo lo tenemos en otros puestos profesionales internos a la organización, por ejemplo, cuando se contrata un arquitecto para que se encargue de dibujar planos, controlar especificaciones normativas, legales, etc. El arquitecto típicamente va a ejercer también su profesión por cuenta propia, y la empresa/organización no le suele asignar trabajo adicional o de mayor responsabilidad sin previa consulta, porque por ese trabajo, el profesional "va a querer cobrar aparte", por ejemplo, pedirle al mismo arquitecto del primer ejemplo, que se haga cargo del proyecto de 3 edificios de 20 pisos..y por el mismo sueldo.

Otro contra-ejemplo, a un contador contratado (y pagado dentro de esas limitadas responsabilidades), para realizar trabajos de gestión impositiva, no se le puede pedir en gral. y "automáticamente" que se encargue de realizar tareas de auditoría general para 3 sucursales provinciales completas (incluídos los viajes necesarios). Es obvio que si se le pide al contador un trabajo de tal responsabilidad y adicional a lo que es su trabajo puntual, va a haber que retribuirlo apropiadamente, en sueldo o pagándole el trabajo como una tercerización.


Cuales son los límites: empleado estándar
Si los límites no están formalizados, entonces es tarea del propio administrador de sistemas como profesional, el poner los límites a sus responsabilidades, luego de ese límite, cualquier responsabilidad y trabajo adicional debe ser adecuadamente satisfecho en sus expectativas retributorias.

En otras palabras, no hay que regalar el laburo.

Muchas organizaciones no son conscientes institucionalmente de la importancia del trabajo de administración de sistemas para la organización y tienen la grave tendencia de equipar la responsabilidad y trabajo de los administradores de sistema con el trabajo de soporte técnico y/o posiciones de helpdesk.

Evidentemente esa equiparación no resiste la mínima comparación con la realidad de las responsabilidades y desafíos técnicos de los administradores de sistemas.


Cuales son los límites: empleado público / estatal
Si nos manejamos por el típico ciclo organizacional estatal en Argentina, casi siempre hay que ganar el puesto por un mérito previo, es decir, hay que trabajar en un puesto por X retribución, haciendo un trabajo que vale X+Y, y luego, si se dan bien las cosas, se obtendrá el nuevo puesto donde se va a cobrar Z=X+Y.

[La excepción clara son los puestos asignados por influencia política, donde se da lo que es - debería ser al menos - habitual en empresas privadas, el puesto antes que los méritos]

Sabido/entendido lo anterior, el puesto estatal promedio tiene ciertos beneficios laborales, "ciertos" implica que son beneficios reales y concretos:

- Estabilidad laboral a largo plazo
- Mayor cantidad de días de vacaciones (entre 30 y 60 días de vacaciones por año)
- Sueldo auto-ajustable anualmente y automáticamente (vs. tener que re-negociar con una empresa o cambiarse de empresa).
- Menor cantidad de horas de trabajo (5 a 7 horas por día, de lunes a viernes).
- etc.

Hay varios beneficios más en general (en el ámbito del Poder Judicial - hasta ahora - no se paga Ganancias por ejemplo).


Esos beneficios extraordinarios corren a cuenta del Estado para que, otorgada una posición laboral determinada, y  a la vez, estando el empleado de acuerdo con las condiciones básicas (sueldo y categoría, posibilidades ciertas o ninguna de ascensos, mejoras, etc.); todo ello le brinda el marco para aceptar responsabilidades extraordinarias.

"Estar de acuerdo" implica una simple noción, si se le paga al empleado por ejemplo AR$ 7000 mensuales en bruto, desde lo personal el empleado no debería tener objeción para emprender determinados proyectos de gran magnitud.

Si en cambio tenemos un empleado estatal en planta que cobra AR$ 2500 en bruto y se le quiere asignar compulsivamente la responsabilidad de gestionar y administrar un centro de cómputos completo, probablemente no habrá un acuerdo - realmente - en el fuero interno del empleado (aunque políticamente "acepte" las circunstancias). "Compulsivamente" sería compatible con la noción de "apriete" por cierto.

La realidad dicta que muchos IT guys van a aceptar ciertas condiciones desfavorables para poder acceder a una fuente de trabajo - en Corrientes especialmente - y/o mantener los beneficios del trabajo estatal (al tiempo que se dedican en su tiempo libre al libre ejercicio de la profesión). Esto no implica necesariamente tener que regalar el trabajo, claro (ver el siguiente título).

Por ejemplo, hace pocos meses atrás escuchaba a un prestigioso y conocido Ingeniero de la zona comentar:

"Por AR$ 5000 ¿qué màs querés? que el tipo te instale X y te configure todo eso encima?"

:-D

Nos reímos un rato después de eso, era una conversación respecto al montaje de una solución de infraestructura de nivel intermedio que un tercer profesional había cobrado AR$ 5000, cuando en el mercado correntino se está cotizando desde empresas a costos de al menos AR$ 10000 y se le había pedido además proveer una solución mucho más sofisticada que lo pre-acordado.

Nota: el cliente había quedado inconforme con el trabajo, esperaba que el contratista le proveyera más trabajo, que había agregado a último momento, luego de pre-acordar el precio del trabajo. El contratista no proveyó el trabajo agregado solicitado y quedó a la espera de una reconsideración de precios, que proveyó oportunamente.


[Por cierto: en Corrientes un sueldo IT estatal en planta permanente oscila entre AR$ 4.000 en bruto (queda unos 3600-3700 de bolsillo), y AR$ 17.000 (Jefe IT) ]

[ Los contratos de locación y obra para sueldos estatales - provinciales, municipales, nacionales en Ctes. -  mensuales IT están entre AR$ 1500 (menos descuento de costos de Monotributo), y AR$ 5000, con raras excepciones - políticamente viabilizadas - por mayores importes.]

[ El sueldo base de contrato IT suele estar equiparado con el contrato y/o sueldo en planta más bajo que paga el ente estatal, en gral. está equiparado con lo que cobran los ordenanzas, personal de limpieza y empleados administrativos no profesionales]

El profesionalismo vs. la ilegalidad laboral y los aprietes
La recomendación si nos encontramos con la necesidad de explicar que un trabajo de adm. de sistemas está fuera del rol laboral (de vuelta, recordemos el ejemplo de grandes proyectos de mucho presupuesto, responsabilidad, a misma retribución y que si se terceriza, el proveedor se hace cargo cobrando importantes precios, muy por encima de la retribución típica del adm. de sistemas), es:

"Comunicar apropiadamente esta circunstancia a los responsables jerárquicos."

Ahora bien, es claro que la realidad laboral en Argentina para los empleados informáticos no es muchas veces positiva. El gerenciamiento informático y las jerarquías superiores suelen valerse del trabajo de los empleados para tener "proyectos éxitosos" que ofrecer a la organización, y en este caso sí, la organización suele proveer al gerente y las jerarquías, mejoras retributivas importantes por "su" éxitoso proyecto.

En estos casos no compatibles con la posibilidad de actuar con total apertura y sinceridad y poder esperar no recibir "aprietes" laborales no éticos e inapropiados, la recomendación es guardar la debida discreción y (auto)limitarse estrictamente a cumplir con las responsabilidades laborales al nivel en que está siendo retribuídas/pagadas, ni más, ni menos. 

[Otra idea por ejemplo, podría ser plantear la circunstancia y ver si el gerente/nivel jerárquico actúa con el nivel de ética adecuado, y de no ser así, el administrador ya se podría ir planteando una búsqueda laboral.]

Además de lo anterior, ejercer por cuenta propia la profesión sigue siendo perfectamente viable y pertinente.

Cómo NO medir la eficiencia en el trabajo remoto IT

Tengo bastante experiencia en ese tema justamente y un comentario del link de más abajo me llamó la atención:

All you need is a method to accurately measure productivity.

"Todo lo que necesitás es un método para medir precisamente la productividad."

Exacto, es así de simple.

El método tiene que tener sentido, por ejemplo, si se le da trabajo a un empleado remoto, y tenemos hiperproductividad, es posible que ese empleado trabaje 2 horas, complete todas sus tareas, y luego no tenga nada que hacer (esto es muy habitual en IT por cierto). La hiperactividad se llega a lograr en bastantes tareas IT luego de automatizar debidamente el flujo de trabajo (con scripting, con técnicas de workflow muy efectivas, etc.), pero puede que algunas tareas no se puedan realizar en poco tiempo (típicamente son aquellas relacionadas con burocracia IT: escribir informes, comunicaciones, documentación, etc.), y eso genera un patrón de "irregularidad" en los sistemas que registran la actividad habitual de los empleados.

Por ejemplo, el método clásico de tomar screenshots de pantalla aleatorios a diversas horas del día, va a fallar consistentemente en proveer información certera en un escenario como el anterior. Día de por medio, va a reportar "falta de actividad" cuando en realidad estamos en presencia de "hiperproductividad".

Queda en la gerencia interpretar adecuadamente la información de los sistemas de auditoría/control y cotejarlos contra la realidad de los objetivos logrados por el empleado. Esto no siempre se logra, ya que mucha gerencia se respalda ciegamente en los sistemas de control, sin considerar sus altos niveles de falibilidad si la información que proveen no se pone en el contexto de la realidad operacional de la empresa.

Una opción típica en presencia de hiperactividad suele ser que la empresa no asigna más trabajo al empleado, entonces una muy mala interpretación de la información de los sistemas de auditoría indicaría que el empleado solamente trabaja dos (2) horas por día. Luego, se está ignorando:

- Carga de trabajo asignada
- Hiper eficiencia laboral


Por esos motivos, es sumamente relativa la interpretación que hacen Yahoo y otros respecto de los datos de logs de actividades obtenidos de las VPN de acceso remoto para empleados off-site. Realmente hay que tener acceso a información mucho más consistente - y privada posiblemente - para poder realizar una evaluación fehaciente de qué tan productivos/improductivos pueden ser los empleados, en vez de meramente estimar productividad en base a qué tanto tráfico genera su actividad en los enlaces VPN (bastante obvio debería ser, y es un método de evaluación de performance bastante torpe, más que simple.


http://developers.slashdot.org/story/13/03/07/1826212/former-mysql-ceo-mrten-mickos-talks-about-managing-remote-workers-video

Administradores Linux: Salarios crecen al ritmo de mayor demanda global

Los sueldos de 2013 para la gente con training en Linux están casi doblando el ratio crecimiento de las demás especialidades (a nivel "global" > es resultado de una muestra de 2600 personas, irregularmente distribuídas en cuanto a lo geográfico...), y las perspectivas laborales son fuertes también: algo así como el 93% de los gerentes de RR.HH. planean contratar talento Linux en los próximos seis meses.

Más allá de la muestra bastante tendenciosa, es un buen indicador para LATAM el que en mercados IT intensivos (US y EU), se dé una mayor demanda de especialistas en Linux.

El reporte incluye la metodología utilizada para estudiar la muestra que devolvió la estadística antes mencionada y mucha más información relevante para la carrera de especialistas en Linux (aparte de la información sobre salarios).

El reporte lo tienen aquí:
https://www.linuxfoundation.org/publications/linux-foundation/2013-linux-jobs-report


Jim Zemlin, director ejecutivo de la Linux Foundation explica por qué Linux "importa" (es un poco "panfletera" la explicación, pero bueno, es cierta en 90% al menos, en mi opinión):

"El costo total de propiedad es uno de los grandes motivadores, especialmente en la economía de hoy. Linux hoy corre en todo, desde dispositivos móviles, sistemas de gestión empresarial, a electrónica de consumo. Con el advenimiento del desarrollo de nubes abiertas y la omni-creciente avalancha de Big Data que las empresas deben manejar en tiempo real, es inevitable que personal IT y administradores experimentados en Linux serán muy buscados."

Fuente: La noticia en Slashdot y su fuente en Dice.

Management Gris: Por qué no deberías permitir la incompetencia en tu equipo IT

Hay una postura común entre líderes y gerentes IT y es que siempre hay alguien incompetente que va a terminar trabajando dentro de su equipo IT y hay que manejar ese tema, "hacer limonada con los limones", aunque no se pueda inmediatamente retirarlo del equipo de trabajo. 

De todos modos, hay un par de cosas a considerar si se decide mantener la incompetencia puertas adentro del equipo IT.

Miedo Laboral
"Incompetente" significa "que no compite", en un equipo IT, el incompetente típico incorpora un factor impensado en la dinámica de trabajo diario: el miedo.

El incompetente no suele tener la capacidad profesional necesaria para ser una competencia real para sus compañeros de equipo ni para otros especialistas IT fuera de su equipo de trabajo, dentro del ámbito de su especialidad (en la que no es competente completamente/realmente, redundo). El "miedo laboral" se presenta así como una constante en el desempeño laboral del incompetente, miedo a: 
- al despido por no realizar su trabajo
- quedar afuera de los aumentos por falta de performance
- no desempeñarse bien si lo incluyen en proyectos técnicamente complejos
- ser sancionado laboralmente si es que lo ponen en posición de realizar un trabajo y no llega a poder hacerlo
- ser comparado en desempeño con sus compañeros de trabajo e identificado como poco apto - en realidad - para las tareas que debería desempeñar,
etc.


En contraste, los empleados competentes no tienen "miedo laboral" y se suelen desempeñar tomando riesgos, encarando proyectos técnicamente muy complicados y con moderadas chances de no tener éxito (por cuestiones ajenas a la capacidades técnicas propias por supuesto); laboralmente también tienden a tomar riesgos: piden (y obtienen): aumentos, promociones en el puesto de trabajo, mayores beneficios, etc.

Conspiración y Consecuencias
Las consecuencias del miedo laboral del incompetente son variopintas, pero principalmente añade a la dinámica social/organizacional del equipo IT típico un ambiente de conspiración permanente.

La incompetencia se suele asociar automáticamente con la falta de inteligencia, astucia, sagacidad, etc. No es correcto en realidad, un empleado IT incompetente tal vez no pueda realizar el trabajo técnico que se le encarga, sin embargo sí puede ser bastante inteligente, astuto y sagaz para realizar otras actividades (dentro del ambiente de trabajo), lamentablemente, en gral. no son actividades que sean útiles para el objetivo del equipo de trabajo.

El incompetente IT siempre está intentando salir bien parado de todas las situaciones laborales donde podría ser identificado (y probablemente despedido y/o desplazado de sus funciones). Para ello no puede utilizar la herramienta laboral básica que serían sus propias habilidades técnicas profesionales (y así desempeñarse bien laboralmente y evitar cualquier consecuencia negativa). Lo que tiene disponible como herramienta básica es la creación de conflicto dentro del equipo, en el caos laboral, el incompetente tiende a pasar desapercibido, y hasta tiene la posibilidad de perdurar y llegar a tener éxito sobre sus compañeros de trabajo realmente mucho más capaces que ella/él.


El engaño, las medias verdades, el llevar y traer rumores, la calumnia e infamia, son moneda corriente que el incompetente utiliza para crear el caos que necesita para perdurar en el puesto laboral.

En gral. el ocultamiento de información lo utiliza como una herramienta de relación laboral con el resto de la organización (empezando con su propio equipo de trabajo), de modo de crear artificialmente a la organización la necesidad de contar con la presencia del incompetente, porque "es la persona que sabe, que está al tanto de todo".

El ambiente de trabajo técnico, el que está fuera del caos generado por el/los incompetentes, sufre un impacto serio y efectivo debido al accionar antes explicado: el grueso del trabajo típico no permite al resto de los empleados ni a la organización "mantener la guardia alta" para resistir los embates constantes de las actividades del o los incompetentes, que terminan haciendo mella en el equipo de trabajo, eventual, pero inevitablemente.

Los empleados más capaces - en serio - son generalmente rápidamente desplazados en primer lugar mediante argucias diversas; los más empleados más resilientes a las actividades de los incompetentes tienden a tener que dedicar mucho tiempo a realizar las mismas acciones, solo para poder sobrevivir organizacional y laboralmente; mucho del trabajo técnico del equipo suele encontrarse que funciona bajo premisas técnicas falsas, ya que los proyectos técnicamente más complejos tienden a encontrar fortísima resistencia a la aceptación de parte de los incompetentes, y de hecho trabajan activamente para "hacer lo más fácil" (no lo más "simple como solución" sino lo más fácil de entender desde el punto de vista técnico para la limitada capacidad profesional del/los incompetentes); etc.

Conclusión
La conclusión es que si se cuenta con uno o varios empleados incompetentes más en un equipo IT, más allá de solamente analizar qué tanto buen desempeño se puede obtener de él ("hacer limonada con los limones", etc.), hay que analizar otras dinámicas negativas que esos empleados pueden generar, que tienden a crear graves inconvenientes a la consecución de los objetivos laborales del equipo de trabajo y por ende, a tener la capacidad de sabotear su éxito.

Cambiar de empleo es lo mejor que te podría pasar

Bueno, ya me tocaba hablar del cambio de trabajo y voy a recordar esos artículos que leía al respecto de que perder el empleo, renunciar al empleo, cambiar de empleo cuando estás en un muy buen puesto laboral inclusive puede ser lo mejor que te pueda haber pasado.

Normalmente los leía sopesando las peripecias necesarias para realizar efectivamente el cambio - muchas, bastantes, implicando planificación a varios meses sino más de un año por delante de los acontecimientos al menos -  y no les daba mayor atención a esos artículos: un buen empleo, por más que no sea el ideal, tiende a crear la inercia de querer seguir haciendo las cosas igual porque "todo" funciona muy bien así.

Sin embargo, como en todo, siempre hay una mejor manera de hacer las cosas, hay un modo nuevo y  mejor de lograr los mismos resultados, una optimización, menos tiempo, menos esfuerzos, menos recursos a gastar y se logra un resultado similar o igual al que se lograba haciendo las cosas del modo original.  Eso es lo que sucede - idealmente - cuando se cambia de trabajo, en lo posible, siempre con una adecuada planificación y ya viendo y sopesando diferentes opciones disponibles.

Realmente, un empleo en una empresa, siempre debería conducir al empleado a considerar qué debería hacer si ya no quiere seguir trabajando en ese lugar, o si lo despiden, o si la empresa se cierra (no es una opción muy aventurada esta última, en un año y en 4 pcias. diferentes, conocí al menos 5 IT guys que estaban trabajando antes en empresas que cerraron), etc.

Volviendo al tema de "lo mejor que me pudo pasar es cambiar/perder el empleo", es una realidad. La inercia habitual del día a día normalmente nos cierra los ojos a las diferentes - mejores, más rentables, más óptimas - posibilidades que están a nuestro alcance, y algunas de esas posibilidades, con algo de empeño, suerte, oportunidad,  preparación/training adecuado, están dentro de lo que se puede llegar a considerar un trabajo sino ideal, una opción mucho más satisfactoria que el empleo actual (y considero en ellos todas las facetas: familiar, profesional, laboral, económica, etc.).

Piensenlo, planeen un poco, si es una opción viable, bien puede valer la pena correr el riesgo.

El cínico IT

La generación X y luego la generación Y en Argentina crecieron en un marco sociocultural crítico de la sociedad, descreídos de las instituciones, tradiciones, etc. básicamente descreyendo de todo. Con varios motivos, de peso e importancia.

Sin embargo hay un límite práctico: cuando el descreimiento y el cinismo ya son una actitud por defecto, racionalizada como "lo que hay que pensar, porque es así", pero sin que esa actitud cínica tenga realmente asidero en la realidad práctica, ni mucho menos en alguna idea con fundamento. Lo vemos todos los días en las redes sociales, Twitter, Facebook, Google+, rezuman de comentarios cínicos diversos, casi en miles por minuto. Por ejemplo:

- "Será tan bueno este programa? mmm"
- "El opensource es muy abierto, no es por nada pero por qué tanta apertura?"
- "El software privativo es cerrado, no sé si confiar en algo que no veo claro?"
- "Esa empresa es demasiado buena para ser verdad, ya le va a tocar fracasar"
- "Ese team de desarrollo anda demasiado bien, ya se van a pelear todos y cada uno por su lado"
- "Ese novato parece que sabe todo, o te hace creer que sabe todo"
- "Ese experto parece que sabe todo, o te hace creer que sabe todo"

¿Ven el patrón? Ni de un lado ni del otro, ni opinando a favor, ni opinando en contra, el cínico IT acepta ni concuerda con nada en gral.

El problema se da cuando el cínico que descree de todo se topa con algo que es real, que existe de verdad.

La actitud cínica en IT se contradice con la actitud neutral y profesional, "sin expectativas", que es tán útil para trabajar en casi todas las especialidades informáticas. El negar en principio un posible camino de solución, ser cínico al respecto, genera una actitud mental en el profesional IT, que claramente puede afectar su juicio y su claridad al realizar el trabajo que tiene que hacer.

No es lo más recomendable. Los especialistas IT de experiencia y buen nivel técnico no ven con buenos ojos a los cínicos en gral., ya que son un punto de fallo potencial importante, inclusive aunque algo (un equipo IT, una empresa IT, sistemas, programas, infraestructura, redes, algun compañero de trabajo, algun jefe IT, etc.) en algun punto esté funcionando bien, un profesional IT cínico tiene la capacidad de crear una falla que tira abajo el sistema, sin que haya existido como causante un problema técnico real de fondo.

Cuando se daban esos casos, de un viejo profesional IT escuché

"Era el indio y no la flecha"

Por eso es tan importante mantener las opciones abiertas, tener una actitud positiva y abierta, en vez de sostener un punto de vista cínico como actitud profesional en informática.

Links:
http://es.wikipedia.org/wiki/Escuela_c%C3%ADnica

Expansión del trabajo remoto IT en Argentina

Las grandes empresas IT tercerizadoras en Argentina dan la impresión de ser la norma o la regla a la cual responde todo el mercado laboral IT argentino, como si fueran un patrón a seguir.

Sin embargo las más grandes tercerizadoras IT de Argentina solo llegan a ocupar a una parte relativamente pequeña del total de todos los empleados IT en el mercado. Así que mirando las ofertas laborales de Linkedin, Bumeran, y demás lugares donde se publica masivamente búsquedas laborales de grandes tercerizadoras IT, cualquiera puede pensar que la tendencia en el empleo es la única que se ve mayormente en esas búsquedas. Es un error.

El empleo remoto en IT crece sin parar desde hace un par de años y cada vez es más común encontrar amigos y ex-compañeros de trabajo que nos cuentan cómo están trabajando para empresas de Chile, para alguna consultora en Brasil o en Israel.

Cómo se accede a estas ofertas? Mayormente NO están disponibles en Linkedin ni en otros portales frecuentados por recruiters de grandes tercerizadoras IT. Hay que ir a buscar estas ofertas a los foros/listas de correo especializados de las herramientas, y con mucha menos frecuencia, se los encuentra en grandes portales de trabajo freelance.

De yapa, los recruiters de grandes tercerizadoras normalmente están baneados de participar en foros/listas de correo, por el volumen de spam que generarían, y las ofertas de trabajo (incluídas las de trabajo remoto), que se encuentran allí suelen ser de muy buen nivel (premium) y/o fáciles de verificar en reputación por crowdsourcing (preguntarle a los demás qué saben de X empresa que está buscando programadores, por ejemplo).


Por ejemplo, para buscar empleo remoto en Python o Ruby en Argentina (lo que quiere decir, poder trabajar en forma remota y en español en lo posible), el lugar indicado es acercarse a las listas de correo de PyAr (Python Argentina), y RubySur (Ruby en LATAM).

PyAr
http://listas.python.org.ar/listinfo/pyar

RubySur
http://groups.google.com/group/rubysur/subscribe

De seguro lo mismo puede decirse de listas de correo especializadas en PHP, Java, Security, Devops (Web Operations), Linux, Wintel, DB, Networking, etc. 

Por supuesto, EL requisito primario para un empleo remoto en IT es saber googlear tu camino hasta la oferta de trabajo.

RR.HH. gris: el truco de pedir requisitos excesivos para bajar el pretendido

La cosa funciona así, en una búsqueda laboral piden muchos más requisitos que los que va a necesitar el empleado para trabajar en la posición.

De ese modo, se espera que se inscriban candidatos que tienen menos requisitos que los pedidos, pero claro, estos son perfectos para posición, sin embargo al momento de fijar el sueldo ofrecido se justifica un sueldo bajo porque al candidato le "falta requisitos".

O sea, es una "viveza criolla", "avivada" (o como le digan en otros países), para poder intentar pagar menos sueldo a un candidato.


La base de que funcione es que el candidato no conozca bien el valor de sus conocimientos, y si así es, suele aceptar trabajar por menos plata.

La contramedida para esto es: conozcan su nivel efectivo real de preparación para un puesto y cuanto se paga por ese trabajo. Si se presentan para un puesto y les dicen que "tienen menos skillset que lo buscado, pero los van a aceptar igual, pero por un poco menos de plata", no agarren la oferta y plantense en su sueldo pretendido mínimo.


Por ejemplo, piden:

Administrador de sistemas Linux Sr., 6 años de experiencia, conoc. de bases de datos Mysql, Postgresql, Oracle, etc.

Y uds. se presentan con:

Adm. de sistemas Linux, 4 años de experiencia, conoc. de bases de datos Mysql (sin experiencia en Postgresql ni Oracle).



En realidad, en el caso de que el "truco de requisitos excesivos" se esté usando, no van a tomar ningun sysadmin de 6 años de experiencia, y normalmente ni siquiera tienen previsto pagar los niveles de sueldo que piden esos skillsets. Pero...

Cuando aparezca un sysadmin con 2 a 4 años de experiencia, y que tenga experiencia con administración básica de cualquier DB (supongamos, dumpeandolas para hacer backups), lo van a querer tomar, pero le van a ofrecer menos plata porque "no cumple" los requisitos pedidos, claro, en realidad estaban buscando justo lo que el candidato tiene de requisitos.

RR.HH. gris: el truco del derecho de piso

El derecho de piso es otro truco usado para hacer trabajar a la gente de IT por poca plata o por nada inclusive.

Los únicos motivos para trabajar por poca plata o por nada es que no tengan otra oferta laboral mejor, fuera de eso, por simple "gravedad lógica", van a ir a parar a un trabajo con mejores condiciones.

La clave para que funcione el derecho de piso es que Uds. lo crean y dejen de buscar mejores trabajos para aceptar "pagar" el derecho de piso.


El derecho de piso normalmente consiste en que tienen que laburar meses, años, etc. por muy poca plata o gratis., y si dejan de buscar mejores laburos, de seguro que va a ser así.


El "derecho de piso" únicamente es válido cuando están arrancando en una especialidad nueva y/o no tienen suficiente preparación para sentarse y hacer el trabajo que pide el puesto por el que cobran.

O sea, si Uds. saben hacer todo lo que el puesto de trabajo pide que hagan para cobrar, no hay motivo para pagar "derecho de piso".

Cuando digo "hacer todo" me refieron a la parte técnica, al laburo técnico, que de repente Uds. no sepan la dirección ip de un server o la clave de un ftp para subir código no es en absoluto "no saber hacer el laburo técnico". Por otro lado, si no saben usar un cliente ftp para subir código a un server, bueno eso es "no saber hacer todo" en muchos casos.


Ojo, si les piden muchos requisitos y luego ven que en el puesto de trabajo usan poco y nada todo lo que les pidieron, estamos en presencia de otra avivada clásica: pedir requisitos de más para pagar menos (lo cuento en otro posteo).

El caso de los 500 pesos

500 pesos. AR$ 500

En ningun momento hasta ahora pensé que fuera a escribir sobre lo que sigue a continuación, sin embargo creo que puede aportar una experiencia / visión de cómo funciona a veces - curiosamente - la cultura del trabajo IT,  tanto para empleados IT como para empresas IT.

Cifra mágica

500 pesos es una suma "mágica" para los aumentos de sueldo porque es (o era hasta hace poco) - para los sueldos medios a bajos - una cifra realista en relación con pedidos de aumento de sueldo. Es realista en dos sentidos: el empleador debería poder pagarla sin mucho problema, y al empleado le suele servir al menos para cubrir parcialmente algunos aumentos de precios por inflación.

* En realidad, la suma "mágica" que cubre aumentos por inflación hoy, estaría en mi opinión en AR$ 1000 de aumento anual.

La historia repetida

Lo que sigue como una explicación genérica es algo que me ocurrió - en algún momento - y desde entonces, he compartido la experiencia - negativa - con muchos IT guys, y para mi sorpresa, muchos de ellos me respondieron que vivieron exactamente la misma experiencia en algun momento. 

Los "500 pesos" son reales, es la cifra que se suele o solía pedir de aumento para sueldos y presupuestos IT en los últimos años (3 años?), buscando una razonable muy pequeña mejora para un sueldo o un presupuesto.

Acción y reacción

Al parecer es un proceso de aprendizaje sociocultural-económico que se divide en tres estadíos, cada uno visto desde una perspectiva analítica de acción-reacción se ve así:

1) La incultura

2) El rebote

3) La cultura

1) La incultura

Acción

Empleado/Empresa/proveedor IT que trabaja o vende servicios IT a un empleador/cliente pide un aumento de AR$ 500 (quinientos pesos), ello es en gral. un pedido moderadamente razonable en la mayoría de los casos, ya sea por desfasaje del sueldo respecto a la inflación o porque bajarle AR$ 500 a un presupuesto es ir a un precio irrisorio por un servicio a realizar.

Reacción

- El empleador y/o cliente se niega a pagar los razonables AR$ 500. 

- Adicionalmente, aquí suele ocurrir un "repudio" hacia el empleado/empresa o proveedor IT, que recibe motes de - mínimo - "querer aprovecharse de la situación", ello por haber solicitado un sueldo de AR$ 500 mayor a lo que esperaba pagar el empleador.

- El empleado no sigue trabajando en la empresa, renuncia, o empieza a buscar a donde ir, luego se va eventualmente.

- La empresa o proveedor de servicios IT no realiza el trabajo, retira la oferta y se va a buscar otros clientes que sí paguen los AR$ 500 adicionales que pide.

2) El rebote

Acción

El empleador o cliente sale a buscar a la calle a alguien, persona o empresa, que provea el trabajo/servicio IT que el IT guy o empresa del estadío anterior no quiso proveer.

Reacción

- Aparece otro empleado/proveedor de servicios IT y ofrece lo que el empleador/cliente está buscando, por un precio de AR$ 1000 (mil pesos).

- El empleador/cliente acepta el nuevo precio felizmente, dando la bienvenida al nuevo empleado/provedor.

3) La cultura

Acción

- El empleador/cliente aprende y/o descubre que pagar los AR$ 500 era una opción sumamente razonable.

Reacción

- El empleador/cliente debe pagar (y paga), desde esta instancia un aumento sobre el precio inicial que pensaba pagar, NO de AR$ 500, sino de AR$ 1000.

Conclusión

La cuestión repetida se da curiosamente en cómo los empleadores/clientes suelen rechazar casi espectacularmente en gral. la posibilidad de pagar AR$ 500 más de lo que pensaban pagar en principio, para luego terminar pagando exactamente el doble, AR$ 1000.

Nota: Ambas cifras que menciono en el texto, 500 y 1000, se presentaron hasta ahora en al menos 7 casos de pedidos de aumento de sueldo y presentaciones de presupuesto de las que conozco personalmente en los últimos 3 años.

El horario partido debilita mucho la actividad económica en Corrientes (y desalienta otras actividades sociales muy buenas)

El horario partido vs. horario corrido:
- Partido: de 8.00 a 13.00 (5 horas) + de 17.00 a 20.00 (3 horas)
- Corrido: de 9.00 a 18.00 (8 horas, 1 hora para comer, usualmente entre las 12 y las 15 horas)

Puedo contar sobre la experiencia de tener una ciudad completa (prácticamente), trabajando en horario corrido. La actividad económica es fuertísima durante la semana, porque la gente tiene tiempo libre, luego de las 18.00, todo el mundo sale a pasar el tiempo libre, como mínimo se gasta en colectivos, taxis, remises, etc.

Es habitual que los lugares de trabajo estén relativamente cerca de los centros comerciales y de entretenimiento: cines, librerías, cafés, shoppings, paseos de compra, supermercados, etc. Luego las 18,00 mucha gente sale de su trabajo y se dedica a sacar a pasear sus hijos, sus mascotas, a encontrarse con amigos y parejas, todo eso implica gastos y actividad económica fuerte.

La mayoría de mis conocidos hace sus compras (comida, etc.), para el fin de semana, desde el miércoles en adelante. Y a veces se "come" todo antes, y el viernes hay que comprar de vuelta :-D

Hobbies: la ciudad revienta de clubes de todo tipo, tamaño y color (deportes, gimnasios, aerobics, danza, baile, artes marciales, etc.), cursos de alfarería, artesanía con isopos, etc.  Lo importante a mencionar es que estos lugares trabajan intensamente de 18.00 a 23.00 hs., es decir, tienen mínimo, unas 5 clases por día de una hora, de lunes a viernes.

Es una costumbre de la ciudad de Córdoba (un par de cientos de miles de personas por día lo hacen), salir del trabajo, irse para el depto. / casa propia, darse una ducha, merendar (con "criollitos" obviamente), y luego al rato, 19,30 o 20,30, salir hacia algun café, restorán, depto./casa de amigos para juntarse y pasarla bien un par de horas.

Gracias a que se descansa desde las 18.00 horas, los pubs y boliches trabajan desde los miercoles en adelante y normalmente con muy buena asistencia. Da para mucho salir a las 21.00 horas, comer algo, luego ir a un pub y quedarse hasta las 1 o 2 de la mañana. Luego de eso se duerme, mínimo 5 horas (de 3 a 8 de la mañana), y se entra a trabajar a las 9 de la mañana. etc.

Todo ese conjunto de actividades que se realizan en el tiempo libre de la gente movilizan fuertemente la actividad económica.

Es una premisa muy básica, si la gente tiene tiempo libre va a gastar dinero, los negocios van a ganar más plata, van a tener más demanda y contratar más empleados, es un ciclo y funciona, lo veo a diario.

---

La comparación que hago es personal, recuerdo que las compras de fin de semana en Ctes., las hacía el sábado, si es que me levantaba antes de las 13.00 hs. (hora en que cerraban la panadería, la carnicería, el quiosco, y el mini-super). Durante la semana trabajaba hasta las 20.30, creo que salía con amigos durante la semana...casi nunca (o sea, no gastaba nada en cafés, cines, pizzerías, librerías, etc.)
En Ctes. el horario partido crea un solo día de actividad económica fuerte, el sábado, ese día todo el mundo sale a hacer compras (comida, ropa, etc.), a gastar en entretenimiento (cines, cafés, etc.), pasear los hijos, salir con amigos, ir a pasear de noche (restoranes, pubs, boliches de vuelta).

Son 24 hs. para permitirles a los negocios intentar captar clientes, y en realidad muchos trabajan medio día, hasta el sábado a las 13 o 14 horas., así que se van a descansar (durante la siesta) y luego solo tienen unas 5 a 7 horas para gastar antes que llegue el domingo y se cierren casi todos los comercios.

En fin, en mi experiencia, el horario corrido no solamente es un beneficio para el empleado, sino para los negocios, la actividad económica se fortalece en grado sumo, y el horario partido en cambio debilita fuertemente la actividad económica. Pienso que traería grandes beneficios (y no solamente económicos), a la sociedad y la actividad económica en la ciudad de Corrientes (y la pcia.), si se masificara el horario corrido en vez de predominar el horario partido como es al momento.

Hay varios factores más que no comenté, los dejo para el debate si alguno quiere aportar ideas: el perder la siesta, el cansancio por los varios viajes ida y vuelta vs. el cansancio por no poder tomar la siesta, los costos de transporte ida y vuelta, el cansancio de los tiempos de viaje - son 4 viajes por día, 20 viajes por semana - mínimo, etc.

Publicar la tesis (la de la facultad) para reforzar la marca personal?

Estaba viendo el trabajo de Mariano Reingart para su tesis y me pregunté, ¿Por qué no se ve tanto la (auto)promoción en forma de ir subiendo y publicando el trabajo que tantos estudiantes hacen en camino a su tesis?

Como mínimo, la tesis debería ser un trabajo informativo, y el grado de minuciosidad típico exigido me lleva a pensar que pueden ser muy interesantes de ver y analizar. Me refiero no solo al documento terminado (que tal vez lo lleguen a encontrar en alguna página en la red, pero no muy fácil de localizar), sino al trabajo, el día a día, que en gral. está plasmado en documentos en formato electrónico (.doc, .pdf, .jpg, etc.).

Este tipo de información puede dar lugar a una muy buena - previa - apreciación del perfil profesional de alguien va a estar - probablemente, proximamente - buscando empleo (fijénse qué buena imagen que les queda de Mariano luego de leer los dos docs que publicó sobre su tesis y ahí lo entienden).

Más allá de publicar el trabajo sobre la marcha, tampoco sería mala idea mostrar algo ya completo y que representa tanto trabajo y esfuerzo en blogs propios, o escribiendo subiendo algun artículo relacionado a la red.

El programador como artista

Conversé con Diva de la Comunidad TIC del tema de si programar es un arte, cuanto cobro? si las horas de laburo son mejores si estoy de buen humor, cuanto se puede cobrar? etc. Todo muy relacionado con el mail que mandé con el artículo de Zach Halman de "Las horas son basura".

Para mi - parece raro en principio tal vez - pero el caso de "cuanto cobrar si es que es un arte" es el mismo del skillset+experiencia.

Se cobra lo que vale el laburo, un consultor especialista, viene y hace el laburo, en 48 hs., te cobra $10000 por ese laburo, o pagás un sueldo a un SSr y te hace el laburo en un mes. Contratás un Sr. y te hace el laburo en 48 hs. también, capaz te cobre 7k de sueldo mensual, y tendrás 18 días laborables más de su calidad de laburo disponible. En principio, está eso, la velocidad para laburar bien, pero hay otras cosas.

Al momento de pedir el sueldo y las condiciones laborales, el tema del "arte" tambien se debería evaluar (muchos lo valoran implícitamente de hecho), si vos podés aportar X calidad al trabajo y al proceso IT en gral., decís, "fijáte, todo mi expertise vale esto", así es como con más seniority se puede pedir: horarios más relajados, más días de vacaciones, más plata, mejores beneficios, etc.

Es bueno recordar que desde el punto de vista laboral, somos todos iguales en los derechos de beneficios mínimos (vacaciones, días feriados, cant. fija de horas de trabajo máximas por día, derecho a días libres pagos por enfermedad, etc.), por otro lado en los beneficios máximos no somos iguales: hay gente que puede pedir más beneficios y mayores sueldos.

Veamos un ejemplo para que se note bien: si tuvierámos por ejemplo, a un Larry Page de un supuesto Google quebrado buscando laburo en mi empresa, hay cosas que Larry va a poder hacer y otros tipos no, así que Larry tal vez pida un lingote de oro por hora como sueldo y muy posiblemente lo valga.


En el NEA
* NEA (Nordeste de Argentina, Región geográfica de la Rep. Argentina)

Esto del "programador como artista" es interesante para ver este tema real:

en el NEA en particular, ví algo respecto de los perfiles altos (potenciales "grandes artistas IT"): no son aprovechados. Tener un perfil alto se lo ve mucho desde el punto de vista "horas/hombre", es decir el clásico "va a dar menos vueltas para terminar su trabajo", "me va a hacer el trabajo que necesito", etc. Un high profile puede cambiarlo todo si se lo aprovecha. Es vital ver eso desde el management, versus la visión limitadísima de que un high profile es el que puede terminar más rápido un laburo o que puede realizar un trabajo puntual.


Los grandes artistas
Siguiendo la analogía inicial, creo que si algunos lograran ver este tema de contratar high profiles en IT más como contratar "grandes artistas", verían mejor el potencial de emplear a gente así, no solo para lo que necesitan, sino para darles lugar a que lleven las cosas al máximo posible. En una empresa resulta en ganancias adicionales; en una organización, es éxito, organizacional y para el jefe, quien lo trajo al tipo "clave".

Recordemos que artistas famosos de la historia fueron arquitectos e ingenieros (Miguel Angel, Da Vinci, etc.), y muchos trabajos que hacían requerían habilidades técnicas comunes a las de otros colegas en su profesión, sin embargo, sus skillsets y visiones artísticas particulares les permitía distinguirse y llevar un simple "trabajo" a la valoración de "obra".

http://es.wikipedia.org/wiki/Leonardo_da_Vinci
http://es.wikipedia.org/wiki/Miguel_%C3%81ngel

Ahora, ya que estamos, creo que la analogía de artista IT se ajusta muy bien al desarrollador, esta visión del programador como artista creó "cosas" como las metodologías de desarrollo ágiles por ejemplo y que se ven sumamente similares a las metodologías de trabajo de "taller", "atelier" típica de escultures, pintores, etc.,

http://agilemanifesto.org/iso/es/
http://es.wikipedia.org/wiki/Taller

http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
http://es.wikipedia.org/wiki/Scrum


En lo personal ví que en infraestructura también podemos ver verdaderos artistas, y mucho de lo dicho fácilmente se les aplica a sysadmins, dbas, devops (especialmente en este caso), netadmins, etc.

Cómo se trabaja en GitHub: Las horas son basura

Traducción libre del original:

How GitHub Works: Hours are Bullshit
http://zachholman.com/posts/how-github-works-hours/

de Zach Holman

------------------------
Frederick Winslow Taylor escribió el gran análisis de management y eficiencia en 1911 con "Los Principios Científicos de la Administración". El tuvo el primer punto de vista científico en cuanto a maximizar la eficiencia en trabajos de manufactura. Tiempo es dinero. Rápido es mejor. Más horas son mejor trabajo.


Las horas son basura
Las horas son un gran modo de determinar la productividad en muchas industrias, pero no en la nuestra. Trabajar en una startup es una muy diferente experiencia respecto de trabajar en una fábrica. No puedes dedicarle más tiempo a un problema y esperar llegar a resolverlo. El código es un esfuerzo creativo. Tienes que estar del humor apropiado para crear código de alta calidad.

Recuerdas la última vez que estuviste depresivo o enojado. Qué tan productivo fuiste? Ahora piensa en la última vez que fuiste realmente productivo. El código volando desde la punta de tus dedos. No solo la pura cantidad, sino la pura calidad de ese código. Cuando estás en el estado de ánimo correcto, tu mejor día de programar puede ganarle a semanas de frustrante tipeo de teclado.

Queremos que los empleados estén en la zona tan a menudo como sea posible. Disponer de horarios específicos para que estén en la oficina hace daño a esa cuestión. Forzarme a estar en la oficina a las 9AM no me va a llevar a la zona nunca, pero la mitad de GitHub podría muy bien trabajar mejor durante la mañana.

Al permitir un horario de trabajo más flexible, creas una atmósfera donde los empleados pueden estar contentos acerca de su trabajo. Al final ello llevará a más horas de trabajo, y que esas horas sean incluso más productivas. Trabajar semanas se vuelve trabajar noches y ello se vuelve trabajar fines de semana, ya que ninguno se siente como si fuera "trabajo".


Un Día
Cada día en GitHub es diferente. Realmente no tengo un día "promedio", pero esto es una buena aproximación:

- Despertar alrededor de las 10am, revisar los logs de Campfire (N.deT. Es un chatroom masivo para los empleados de GitHub), limpiar los tickets de soporte de la noche.
- Tomar el colectivo al trabajo y desayunar cerca del mediodía o las una.
- Trabajar desde las 1pm hasta algo así como las 6-9pm en la oficina
- Ir a casa y trabajar/relajarme en mi sofá hasta las 2am, o
- Salir y tomar algo con mis compañeros de trabajo (más sobre esto luego)

Tenemos un grupo de gente (loca) que viene a trabajar alrededor de las 7am, tenemos algunos que vienen a las 3pm. Tenemos otros que son más productivos trabajando desde su casa. No hace falta que vengas a la oficina todos los días, si no tenés ganas (aunque la mayoría del tiempo todos vienen).

Por qué nuestro día es tan "libre"? Porque
1) Trabajar en chatrooms nos permite trabajar cuando y donde querramos y
2) queremos crear un ambiente donde la gente sea más productiva. No hay un solo "día de trabajo" que se acomode a las horas productivas de todos, así que no forzamos uno.


Forzandolo
Tenemos actualmente 35 empleados y creciendo, y este punto de vista funciona muy bien, pero los managers aman asignar horas de trabajo por una razón: les da la ilusión de que las horas pueden medir el rendimiento.

Si no le prestás mucha atención a las horas, te hace falta mirar métricas diferentes: Qué tan bueno es su código? Están arreglando bugs? Están metidos en el trabajo o la mayor flexibilidad no está motivandolos?

Es difícil hacer esos juicios cualitativos, pero aún así son más valiosos que "este tipo hoy trabajó 10 horas". Porque tan pronto como tú lo vuelves una cuestión de "horas", su trabajo se vuelve menos acerca de código y más acerca de "horas".

Como descubrir un mal jefe antes que sea demasiado tarde

Traducción libre de
how-to-spot-a-bad-boss-before-its-too-late/



Vas a una entrevista de trabajo, respondes todas las preguntas y luego está el inevitable momento: tenés alguna pregunta para nosotros? Este es tu momento de enterarte si querés el trabajo y en particular, que clase de persona podría ser tu potencial jefe. Así que ¿cuales son las preguntas que van a mostrar las cosas como son?

1. De toda la gente con que trabajaron, de quienes están más orgullosos y por qué?

Querés trabajar con quien te ayude a crecer, desarrollarte y avanzar. Si este jefe no ha ayudado a la gente a progresar, esto podría indicar que tiene miedo de rivales, en cuyo caso, vos vas a ser frenado. También podría sugerir que no vas a recibir ningun mentoring ni coaching significativo, en cuyo caso, qué cosa, aparte del sueldo, ganarás en ese trabajo? Por otra parte, si el jefe puede mencionar personas que han obtenido amplias oportunidades, podrías estar en presencia de un ganador.

2. Podrías describir algun desacuerdo que hubiera habido dentro de un proyecto, trabajo o departamento y cómo fue resuelto?

Todos los departamentos saludables discuten: es así como la organización "piensa". Si no hay debate, nadie está pensando.  Lo que querés discernir de la respuesta es si hay niveles de confianza profesional alrededor de desacuerdos saludables. Si no hay esos niveles de confianza, tus puntos de vista no serán bienvenidos, y es un signo seguro de que las políticas triunfan sobre la inteligencia. Evíta estos trabajos.

3. Hay alguna oportunidad formal para ser mentor o coach de empleados con talento dentro de la empresa?

Si no podés ser vos mismo un mentor, es altamente probable que no vayas a recibir mentoring alguno tampoco. Muchos candidatos dudan en preguntar si van a recibir mentoring o coaching (porque creen que los hace ver como candidatos débiles), así que este podría ser un buen modo de ver al respecto sin que se note lo que están preguntando en realidad.

4. Qué le pasó a la persona que estuvo antes en el puesto de trabajo que ofrecen y cómo era como empleado?

La información de fondo de una posición vacante siempre es interesante. Si la persona anterior se fue en malas circunstancias, algo de ese oprobio va a venir con el trabajo , en cuyo caso, ya están advertidos.  Si avanzaron dentro de la empresa, implica que vos también podrías avanzar. Si nadie sabe que pasó con el empleado anterior, están mientiendo y vos deberías pensar dos veces respecto a esta oferta de trabajo. Es de mucha ayuda saber cómo era el trabajo que antes se hacía, aunque solo sea porque es más fácil imitar a alguien que es diferente; en cambio si los anteriores empleados en el puesto trabajaban de modo muy similar, puede que te sea difícil destacatar tu propio trabajo.

5. Qué tanto cambiaron las expectativas y requerimientos del puesto de trabajo desde que fue creado por primera vez?

Si no cambió para nada, es muy probable que sea una organización bastante estable, pero posiblemente rígida. Si eso es o no de tu gusto, es decisión tuya. Pero vos deberías saber antes de tomar el empleo si estás entrando en un puesto muy variable, "caliente" o en un puesto tipo estanque de aguas calmas.

Ninguna de estas preguntas te va a meter en problemas, pueden evitar que te metás en un lugar donde no querés estar.

Salarios IT 2011 - Coming Soon

Estos datos son casi de fin del 2010: Cuales son los perfiles IT más buscados y que salarios se pagan hoy en el mercado

Puntualmente en la imagen se ven los nros.

Más o menos y comparando con el año pasado, se puede ver que hay pocos cambios, sin embargo falta considerar que más allá de los ciclos internos de las empresas, la gente suele elegir cambiarse de empresa luego de volver de sus vacaciones de verano.

Por otra parte, se ve desde hace un par de meses y continúa durante el verano: hay un intenso movimiento en la gente de IT que ya ha decidido buscar mejoras laborales; de vuelta es independiente de cómo procedan los ciclos de reclutamiento y ejercicios económicos de las empresas en general.

Así que las negociaciones se están dando ahora mismo, se pide, se ofrece, se negocia, etc.

La conclusión es que vamos a ver los nuevos sueldos 2011 más o menos entre finales de febrero y antes de abril.

Si tienen un buen nivel de seniority, algo que se busca todo el año y casi no tiene bajas en la oferta de puestos, lo mejor es esperar a que todos los deptos. de RR.HH. se acomoden y consigan el OK de management para ofertar los nuevos niveles de sueldo de 2011.

Claro, los mejores RR.HH. ya van un paso adelante y ya tienen el OK de management y están ofreciendo los sueldos 2011 hoy (y por el momento parecen sueldos altísimos comparados con lo que hay ahora). Otros intentan "acomodar" la mayor cantidad de puestos posible antes de las actualizaciones de sueldos.

Un buen site para consultar (si quieren dejar su input, mejor):

Encuestas IT: Salarios y condiciones laborales

Tips para buscar empleo IT en multinacionales

Gente que debería quedar, no queda

El buscar empleo en una multinacional puede en principio reducirse a simplemente presentar el CV, obtener una entrevista, pasar el proceso de selección e ingresar.

Sin embargo, hay factores que hacen que muchos candidatos viables, que tienen todos los requisitos necesarios para acceder a una posición, no lo logren.

CV

El CV pasa un análisis en general muy rápido, a veces automatizado, por lo cual se debe tener un buen CV. El tip más rápido es conseguir varios CVs de gente que ya accedió a posiciones en multinacionales y copiar la estructura y la jerga (esto es muy importante, usar las mismas palabras que son estándar en la industria: por ejemplo, en vez de "programador", usar "desarrollador", etc.).

Es decir, hagansela fácil a la gente de RR.HH. (Recursos Humanos), recuerden que el CV llega a gente que no tiene casi nunca real entendimiento de lo que están leyendo, sino solamente una aproximación interpretativa porque son profesionales RR.HH., y casi nunca son profesionales IT. Un lugar donde esto se puede hacer es buscando ejemplos en Linkedin.

Qué se busca y qué hace falta saber

Buscando en Linkedin también van a poder ver esto, vayamos al principio del tema: En sitios de búsqueda de trabajo en línea como Bumeran, Universobit, etc. pueden encontrar las posiciones ofertadas, pero en gral. y si es el primer empleo en una multinacional, casi de seguro no van a saber con seguridad si las skills propias "sirven" o no para postularse. Un modo de verificar eso es ir a Linkedin, buscar y ver perfiles de gente que ya trabaja en posiciones similares, y van a ver realmente si lo que tiene podría permitir o no acceder a la posición.

Lo que piden y lo que el postulante oferta

El postulante también ofrece sus servicios y skillset: el conjunto total de cosas que sabe y el potencial de lo que podría crecer. Es importante entender esto pues muchas ofertas de empleo listan los requisitos óptimos para el candidato buscado, pero NO listan casi nunca los requisitos mínimos para el puesto. Para ubicarse en este tema, la información también la pueden obtener de Linkedin (después de analizar un poco los perfiles).

Lo de los requisitos mínimos es interesante para el primer empleo en una multinacional porque si no se llega al "óptimo" presente en la oferta, igualmente se podría acceder al puesto, tal vez con cambios en la prestación (menor sueldo, horarios poco habituales, etc.).

Si llegan a obtener la entrevista, es muy importante preguntar y verificar que no existe alguna confusión o expectativa (apuesta), de parte del entrevistador de recursos humanos (RR.HH.): a veces llaman para ver si un "nivel intermedio" de inglés podría ser en realidad un "bilingüe". Cabe también la posibilidad de hacer la contra-apuesta y probar si pueden pasar las pruebas, de hecho si las pasan van a corroborar la apuesta de RR.HH. de que en realidad el perfil del candidato era mejor de lo que mostraba el CV.

¿Como saber si me llaman por una "apuesta" o porque cumplo los requisitos? Le pueden preguntar al entrevistador, directamente, también es claro si les falta totalmente alguna de las skills solicitadas para el puesto ( por ej. piden un año de experiencia en Java y Uds. tienen 2 años de experiencia en .NET, pero no tienen nada de Java).

Lo de la apuesta no es algo relacionado con el azar, sino con el potencial de crecer del candidato.

Las posiciones Jr. / Trainee

La importancia de los puestos Jr. / Trainee es que le permiten al candidato ingresar en la empresa y empezar a empaparse literalmente de la cultura corporativa y de un modo de trabajo bastante diferente de los empleos en PyMEs y por cuenta propia.

El aspecto técnico en gral. suele ser bastante poco interesante (por ej., trabajar casi exclusivamente agregando cuentas de correo), pero es un comienzo y al ingresar el novato, las posibilidades de carrera IT mejoran sustancialmente ya que es mucho más fácil a futuro acceder a otras posiciones más interesantes; de hecho las multinacionales "esperan" que eso suceda, nadie - que entienda la realidad profesional IT - pretende que un profesional IT se pase 5 años, por ej., creando cuentas de correo exclusivamente.

Cuanto tiempo se la tienen que bancar? En gral., un año, al cabo del cual si no piden nada incluso (es MUCHO mejor pedir), suele haber mejoras en el propio trabajo (les piden hacer cosas más interesantes), y/o surgen posibilidades laborales internas (dentro de la misma multinacional) y/o externas.

Logística económica y social de la mudanza

Casi todo empleo en una multinacional implica mudarse a Bs.As., Cordoba, Rosario, etc.

En gral. los entrevistadores averigüan muy rápido si un candidato tiene lo que hace falta para mudarse a otra ciudad y trabajar normalmente, por eso es que hace falta pensar bien la logística de cómo se va a tratar la mudanza: alquiler, gastos, viajes, muebles, ropa, transporte.

Es importante tener todo esto en claro y ser serios, porque si el RR.HH. elige un candidato que tiene que mudarse por sobre otros que ya viven en la ciudad, debe justificarlo muy bien, es decir tiene que confiar en el candidato casi personalmente.

La otra faceta es la social, no se puede estar en una ciudad sin tener contacto con nadie más que la gente que se conoce en el trabajo (que de por sí, no suele ser un lugar de extenso intercambio social, aunque a veces sí).

Lo óptimo es intentar vivir, o compartir de cerca al menos, con otra persona la experiencia de estar en una ciudad lejos de la familia y amigos.

Es vital entender que fuera del trabajo DEBE haber actividades que permitan a la persona sobrellevar mejor las emociones que vienen con un gran cambio; en este sentido es VITAL hacer ALGO: cursos, inscribirse en lugares para aprender algo (hobbies, cosas IT que
interesen, etc.), inscribirse en un gimnasio, hacer algun deporte de equipo. Lo importante es intentar rodearse de conocidos habituales y socializar, eso suaviza mucho cualquier situación devenida de estar lejos del lugar de origen.

En la realidad práctica, llegar al punto de tener algun conocido con quien tomar un mate un sábado por la tarde es casi tan importante como encontrar donde alquilar.

Ciclo profesional-laboral IT en Corrientes

Bien, no pensé que iba a estar escribiendo estas líneas en algun momento así que si todavía no llegaron a hacerse preguntas como las que plantea/intenta responder este artículo sean comprensivos...y esperen un tiempo que ya van a llegar a esto.

Cuando se empieza a estudiar IT, LSI, ISI y carreras afines de la ciudad de Ctes. normalmente - y lo veo en muchos - pocos se imaginan donde va a ir a trabajar y aplicar todo ese conocimiento...es el por qué de este texto. Mi idea es contarles a los interesados un par de cosas al respecto.

Empleado IT == mi_propia_micro_pyme

Antes de seguir les recuerdo que si bien muchos IT pro se ven como "empleados", hoy en día ser "empleado" no consiste ni más ni menos en que tenemos nuestra propia "micro-pyme" donde buscamos la rentabilidad apropiada para generar ingresos que la sostengan (al profesional...y familia normalmente).

Vamos rápidamente al nucleo del artículo: en algún momento cercano de tu vida profesional IT en Ctes. te vas a plantear migrar de ciudad para progresar profesional y económicamente. En la ciudad no hay demasiada oferta de trabajo IT real, llámese así a un empleo efectivo - tambien conocido como "en planta permanente"- no por contratos ni facturando como monotributista.

Cálculo de rentabilidad para contratos y monotributo

Este cálculo sería que trabajar vía monotributo y/o contratos hace ganar menos al empleado al NO PAGAR POR: extra por permanencia en el puesto/antiguedad, días de vacaciones, días no trabajados por enfermedad y no retribuir el extra del aguinaldo y medio aguinaldo, adicional de gastos médicos por precariedad de prestaciones de obras sociales para monotributistas.

Sumen todo eso y van a ver que estando efectivo se cobra aproximadamente entre un 10% y 30% ADICIONAL - de dinero en efectivo - AL SUELDO TIPICO POR CONTRATO O MONOTRIBUTO al no tener que pagar días de vacaciones, enfermedad, gastos médicos no cubiertos por obras sociales precarias y sumando los ingresos de aguinaldos y antiguedad.

Es costumbre fuera de Ctes. que cualquier sueldo pagado vía monotributo y/o contrato sea más elevado que el ingreso total en bruto que se tendría como trabajador efectivo (incluyendo todo lo antes mencionado), típicamente un contratista independiente cobra entre 10% y 30% adicional por encima del valor de un empleado efectivo. Así el contratante retribuye al contratista por sus servicios y por el beneficio en ahorro de costos fijos que conlleva no tomar un nuevo empleado efectivo.

Trípode de carrera del profesional IT

La oferta que hay al momento en la ciudad de Ctes., incluyendo necesariamente contratos y monotributo - sino casi no habría posibilidad de mencionar que existe - incluye empleos de nivel inicial e intermedio a nivel de conocimientos IT, igualmente en lo económico.

La cuestión se da en que la mayoría de los profesionales IT dejan de ser de nivel inicial al cabo de un par de años de estar en el mercado laboral, luego de eso ya se aspira a mejorar en el nivel de conocimientos/capacitación, en la experiencia profesional y en la rentabilidad económica.

Como ven es un trípode que sostiene la planificación de la carrera profesional: Capacitación, Experiencia profesional y Rentabilidad. Idealmente el estudiante universitario planifica racionalmente cómo compaginar estos tres factores para ubicarse profesionalmente y progresar.

Los 3 factores en Corrientes

En la ciudad de Corrientes los tres factores (capacitación, experiencia profesional y rentabilidad), casi no existen más allá de los primeros pasos como junior/novato/principiante:

* En cuanto a la capacitación (cursos, certificaciones, educación formal), la oferta es muy limitada. En capacitación hay cierta oferta en la zona (Proydesa en Resistencia, carreras IT en la UNNE, Siglo XXI y UCP), pero los IT pro encuentran rápidamente el dilema económico del "huevo o la gallina". No están capacitados, así que no pueden cobrar mucho; no pueden pagar capacitación porque no cobran mucho...

Casi nadie capacita o paga por capacitación en los empleos IT en la ciudad de Ctes., lo que encuentren son excepciones a la regla.

* En cuanto a la experiencia profesional (qué tecnología manejamos, hasta que punto, tamaño y complejidad técnica de los proyectos IT en que nos desenvolvemos, etc.); la oferta es muy limitada.

La mayoría de los empleos de la ciudad de Ctes. que representan una buena experiencia IT ya están tomados y no es muy frecuente que haya nuevas vacantes. Las posibilidades de conseguir un puesto que brinde una experiencia profesional valiosa están limitadas a lo que ofrecen no más de 20 organizaciones estatales y empresas...contrastar esto con el número típico de egresados PUA, LSI, Analistas, ISI e idóneos que están en búsqueda laboral en la ciudad en un momento dado...

* En cuanto a la rentabilidad: Como pudieron haber leído antes en el blog, muchos experimentados profesionales IT locales son retribuídos y catalogados de principiantes, muchas veces al solo efecto de sostenerlos en su posición actual, con baja rentabilidad económica que se autojustifica porque no tienen suficiente experiencia/conocimiento/excusa similar. En cualquier caso, los sueldos IT son bajos para el costo de vida típico de Ctes.

Como conclusión y tal vez consejo, veo que la alternativa práctica es buscar empleo IT en otros lugares, empezando por Resistencia. En la búsqueda hay que recordar y considerar en todo momento los 3 factores clave en el desarrollo de la carrera profesional propia (capacitación, experiencia profesional y rentabilidad).

Problema y soluciones para capacitación insuficiente

Algunos me han planteado que no tienen suficiente nivel profesional, no están suficientemente capacitados, para buscar empleo fuera de Ctes. y adicionalmente no tienen recursos para capacitarse (recordar el "huevo y la gallina").

En este caso veo dos posibilidades:
* Viajar primero y emplearse como traineé/junior buscando que la empresa que los tome los capacite o que al menos se pueda obtener experiencia técnica/laboral valiosa; o en su defecto,
* Emplearse en la mejor alternativa local disponible, siempre siguiendo los 3 factores clave, y reinvertir conciensudamente el ingreso en capacitación, para esto particularmente me inclino a recomendar los cursos de Proydesa/UTN en Resistencia, CCNA, Oracle DBA, y otros, recomiendo estos dos porque brindan un nivel de capacitación técnica muy rentable y sumamente reutilizable independientemente de la especialidad IT de nuestra preferencia.

Puede haber otras según el caso particular de cada persona, pero todos los casos la fuerza de voluntad es clave para lograr los objetivos profesionales. No dejen de buscar la oportunidad, y si aparece hay que tomarla.

Conclusiones

Comentando con conocidos IT pro locales de muy buen nivel (se sorprenderían si menciono nombres), veo que muchos de ellos han migrado en epocas anteriores, obtenido un buen nivel en los tres factores clave (capacitación, experiencia y rentabilidad), y luego han regresado a Ctes. a montar empresas propias o a emplearse localmente en posiciones muy buenas...es otra posibilidad.

Espero que estas ideas/consejos/conclusiones les sean de utilidad a los lectores IT pro que están comenzando, a los que comenzaron y están viendo qué pasa que ya tienen una titulación universitaria hace meses/años y no ven progresos ni los esperan a corto plazo, y para muchos de los que emplean profesionales IT en la zona, para que vean que si bien hoy pueden conseguir RR.HH. baratos y capacitados, no los van a retener mucho tiempo si no se da una retribución adecuada en capacitación, experiencia profesional y rentabilidad económica.